checking for fields
Emacs version: 21.4a. Merged from emacs 21 to xemacs 21.5 with the
same bug, so cross- posting there.
`beginning-of-line' (in emacs only: another inconsistency of the
merge), `forward-paragraph' and many other commands by default refuse
to move across field boundaries. It is not even stated so in their
docstings, for `forward-paragraph' at least.
Other commands on top of them are also affected by that, and in an
obscure way. Viper vi state `f' command operate within paragraph
boundary as determined by `forward-paragraph' (which is also not
documented), and if the boundary is before the end of line due to
fields, then characters on that line are not found as expected.
It actually happens with default settings of `shell-mode', if point is
in shell prompt and character to find is in command being edited,
which are different fields set up by `comint'.
There is even no interactive commands to check for fields explicitly.
All of the field limiting only overloads existing point movement
commands. Some packages may set different faces for different fields,
like `comint' does (using `comint-highlight-prompt' face), or may set
nothing except fields themselves. It is entirely up to package. And
even if face with different foreground color (or other visual
attributes) is set, differences between it and text outside the field
may be visible or not visible on particular display / terminal.
(With xemacs `comint.el' after revision 1.14 of 2006/05/25 it is even
more complex. `comint-highlight-prompt' is used only for
`font-lock-face' extent property, so there is an additional unknown of
whether font lock mode is on. It is also not typical use of font lock
to denote otherwise hidden text areas across which regular editing
commands will refuse to move, and thus required in this case.
Normally it is used for syntax structures which may be easily
recognized otherwise, across which editing commands move freely, and
thus optional.)
Generally user has to resort to evaluating elisp expressions to figure
what is going on. Or, in emacs, work around it all by setting
`inhibit-field-text-motion t' locally. Can not do so in xemacs due to
bug in its comint.
For these reasons considering lack of interactive commands to check
for field boundaries a bug. These commands should do the same
regardless of minor modes, faces attributes and display capabilities
in particular emacs process.
Explicit error messages about hitting field boundary would be even
better.
** Why still report for emacs 21.
Limiting movements to fields as described appeared in 21 release
branch only, as 1999-10-17 Miles Bader <miles(a)gnu.org> change.
If users could have noticed that and complained about that in that
time, it would be reasonable now to recommend them just to switch to
new development branch from release 21 one. But at that time emacs
cvs was not publicly readable. Such a recommendation would be at best
unreasonable. It signals that now it is <too late> to complain about
release 21 bugs. Until 21 release, it was <too early> to do so. When
there was time to do so, then?