From: "Ilya N. Golubev" <gin@mo.msk.ru>
Cc: Michael Kifer <kifer@cs.stonybrook.edu>, Jerry James <james@xemacs.org>
Subject: checking for fields
Date: Thu, 24 Aug 2006 21:15:29 +0400 [thread overview]
Message-ID: <13lkpeawcu.fsf@mo.msk.ru> (raw)
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@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?
next prev reply other threads:[~2006-08-24 17:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-06 20:32 comint loses prompt boundary Ilya N. Golubev
2006-09-06 20:41 ` comint loses prompt boundary in cvs, too Ilya N. Golubev
[not found] ` <E1GLRDD-0000mS-2D@fencepost.gnu.org>
[not found] ` <59ejumjzz2.fsf@mo.msk.ru>
[not found] ` <E1GLjTm-0000cp-DO@fencepost.gnu.org>
[not found] ` <843bazvd1b.fsf@mo.msk.ru>
[not found] ` <comint_field_movement_fix@mo.msk.ru>
2006-12-12 18:07 ` shell completion documentation [Re: comint loses prompt boundary] Ilya N. Golubev
2006-12-12 18:08 ` field movement fix " Ilya N. Golubev
2006-12-15 16:11 ` field movement fix: `NEWS' change Ilya N. Golubev
2006-12-14 5:29 ` shell completion documentation [Re: comint loses prompt boundary] Richard Stallman
2006-12-14 17:51 ` shell completion documentation Ilya N. Golubev
2006-12-15 21:24 ` Richard Stallman
2006-12-15 23:48 ` bug reports vs manuals [Re: shell completion documentation] Ilya N. Golubev
2006-12-16 20:04 ` shell completion documentation Richard Stallman
2006-12-18 19:06 ` Ilya N. Golubev
2006-12-20 13:00 ` Richard Stallman
2006-12-20 20:59 ` what makes read it? [Re: shell completion documentation] Ilya N. Golubev
[not found] ` <mailman.1817.1166000505.2155.bug-gnu-emacs@gnu.org>
2006-12-13 15:39 ` shell completion documentation [Re: comint loses prompt boundary] Miles Bader
2006-12-13 18:07 ` Ilya N. Golubev
2006-12-14 3:49 ` Miles Bader
2006-12-15 23:48 ` comint loses prompt boundary Ilya N. Golubev
2006-08-24 17:15 ` Ilya N. Golubev [this message]
2006-08-25 20:25 ` checking for fields Richard Stallman
[not found] ` <02473b3c6f4154-gin@mo.msk.ru>
[not found] ` <02473b40868335-gin@mo.msk.ru>
2006-08-28 17:47 ` Ilya N. Golubev
2006-08-29 11:47 ` Richard Stallman
2006-08-29 20:30 ` pretest downloads [Re: checking for fields] Ilya N. Golubev
2006-08-30 17:58 ` Richard Stallman
2006-12-18 15:56 ` customizing inhibit-field-text-motion [Re: comint loses prompt boundary] Ilya N. Golubev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13lkpeawcu.fsf@mo.msk.ru \
--to=gin@mo.msk.ru \
--cc=james@xemacs.org \
--cc=kifer@cs.stonybrook.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).