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&gt; 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?