Question about syntax-table and regexes in term.el

I'm using XEmacs 21.1.14 "Cuyahoga Valley" I'm very fond of using "tshell". But I've noticed a few problems with it... In particular, if you do something like prompt% !/ or prompt% !. you get stuck in an infloop with "Expanding history references..." in the echo area. I have tracked this down to the regexp on line 1478 in term.el: "!\\??\\({\\(.+\\)}\\|\\(\\sw+\\)\\)\\(:?[0-9^$*-]+\\)?" Breaking this down somewhat: ! literal "!" symbol \\?? zero or one literal "?" symbols \\( start group 1 { literal "{" symbol (why? - shouldn't this be optional?) \\( start group 2 .+ one or more chars \\) end group 2 } literal "}" symbol (why? - shouldn't this be optional?) \\| OR \\( start group 2 \\sw+ one or more characters with "word constituent" syntax \\) end group 2 \\) end group 1 \\( start group 3 :? zero or one colons [0-9^$*-]+ one or more digits or (^$*-) \\)? end group 3, one or more occurences of group 3 Anyway, the problem is - the code in term-replace-by-expanded-history-before-point, when it finds an expression starting with "!", goes through the string with the above regexp, repeatedly doing (goto-char (match-end 0)) until the string is exhausted. And if you do something simple like "!/" or "!." it gets stuck because the characters / and . are not word-constituent in shell-mode's syntax table. / is symbol-constituent and . is punctuation. So the above regexp fails to produce a match... I see two fixes - one would be to change the syntax table for tshell mode - there are some character classifications I'd tend to disagree with - e.g. I really can't see why "&" is symbol-constituent but "." is punctuation, when "." is a valid part of identifiers (file names) and "&" is not... Or why "<" is symbol-constituent... I hestitate to submit a patch to change this because maybe I'm not really understanding the meanings of symbol-constituent and word-constituent and punctuation correctly. The other fix would be just to change the offending regexp. I tried changing the `\\sw' to `.' without ill effect... but before submitting a patch to do this I wanted to get some idea of what the authorial intention was. Thanks in advance for any suggestions/insights, -Charles