checking for fields

checking for fields

[Ilya N. Golubev]

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?

Re: checking for fields

[Richard Stallman]

      It signals that now it is <too late> to complain about
    release 21 bugs.

That is because we are getting close to pretesting Emacs 22.

		      Until 21 release, it was <too early> to do so.

Quite the contrary!  That was the best time to report them.  The whole
point of pretesting Emacs 21 was to fix its bugs before it was
released.

We continued fixing bugs in Emacs 21 for a while after it was
released.  But now we would rather focus on fixing whatever bugs
remain in Emacs 22.

Do these problems still exist in the CVS sources which will become
Emacs 22?  The basic idea of field handling is unchanged in Emacs 22,
but some details may be different, so I would really appreciate your
checking and reporting _specific_ Emacs 22 problems now.

Re: checking for fields

[Ilya N. Golubev]

> 		      Until 21 release, it was <too early> to do so.

> Quite the contrary!  That was the best time to report them.  The whole
> point of pretesting Emacs 21

It was *impossible* to do such a <pretesting> by users with no special
privileges.  Thought that said it quite clearly by the following.

> > from release 21 one.  But at that time emacs
> > cvs was not publicly readable.

Or, in the plainest way: emacs cvs containing release 21 development
sources was closed for anonymous reading for quite a long before
release 21.1.  On 2001-06-29, 2001-07-02 at least.


Fortunately, release 22 sources were readable anonymously last time I
checked.  Perhaps will even try them - in my copious free time
(<http://www.jargon.org/html/C/copious-free-time.html>).  Anyway,
please keep them open, do not duplicate your policy wrt release 21 on
them.

Re: checking for fields

[Richard Stallman]

    > Quite the contrary!  That was the best time to report them.  The whole
    > point of pretesting Emacs 21

    It was *impossible* to do such a <pretesting> by users with no special
    privileges.  Thought that said it quite clearly by the following.

I don't remember where the sources were kept back then, but we did
a series of pretests so that users could try it before release.
(We have done that for every Emacs release since 15 years ago or more.)
Anyone can get on the pretest list by asking me.

pretest downloads [Re: checking for fields]

[Ilya N. Golubev]

> Anyone can get on the pretest list by asking me.

Thanks for the invitation.  Still I'd rather download and try sources
anonymously, without any sort of registering or subscription.

Re: pretest downloads [Re: checking for fields]

[Richard Stallman]

    Thanks for the invitation.  Still I'd rather download and try sources
    anonymously, without any sort of registering or subscription.

Please don't be slow to start.

comint loses prompt boundary

[Ilya N. Golubev]

`comint.el' xemacs packages revision: 1.19.  emacs version - one
bundled with 21.4a.

`inhibit-field-text-motion' is `t', `comint-use-prompt-regexp' is
`nil', if it helps to reproduce.

In shell mode buffer with text already output and entered

user@host:~> COMMAND

(comint-bol nil)

does not skip past the prompt, as documented.  Instead, it goes to the
beginning of line.  `shell-backward-command' calls it, and goes to the
same location.  `shell-dynamic-complete-command' calls it to obtain
position of text already entered by user and incorrectly decides not
to try to complete it as command.

User may set up editor so that interactive generic text motion
commands (including `beginning-of-line', `forward-paragraph') notice
or not notice fields.  Regardless of this
(`inhibit-field-text-motion') setting, expecting commands explicitly
intended for comint mode buffers to distinguish between commands and
prompts properly.  Let alone always expecting command completion to
work.

It is always possible for comint to maintain, in addition to field
text properties, another ones of its own, specifically to distinguish
process outputs and user inputs.  After all, if it depends on text
fields that much, its commands can set `inhibit-field-text-motion'
temporarily (bind dynamically) to the value they expect.

comint loses prompt boundary in cvs, too

[Ilya N. Golubev]

Observing all of that the same way with cvs head version of emacs.

shell completion documentation [Re: comint loses prompt boundary]

[Ilya N. Golubev]

On Sun, 10 Sep 2006 21:37:04 +0400 in <Re: comint loses prompt
boundary> wrote about `comint-dynamic-complete' <test case>
(<843bazvd1b.fsf@mo.msk.ru>).

> It should be obvious from documentation; if it is not, it is bug in
> documentation.  Writing such a case is largely like writing a section
> of tutorial.  Will do so - in my copious free time.

Emacs manual actually only briefly mentions command completion,
without describing it in any useful way - both in version 21.4a and in
cvs head as of 2006-11-23.  So instead of writing tutorial, just
fixing this obvious documentation bug.

The patch is for cvs head as of 2006-11-23.  Note that it describes
command completion behavior as it *should* be, deliberately not saying
how it currently breaks if `inhibit-field-text-motion' is not `nil'.

	Document comint / shell completion properly.
	* misc.texi (Shell Completion): New node.
	(Shell Mode): Reference to it, instead of trying to describe all
	of completion features in place.
	(Shell):
	* emacs.texi (Top): Update node listings.

diff -ru man/emacs.texi man/emacs.texi
--- man/emacs.texi	2006-11-23 15:56:14.000000000 +0300
+++ man/emacs.texi	2006-12-06 05:36:22.710110720 +0300
@@ -762,6 +762,7 @@
 * Shell Prompts::       Two ways to recognize shell prompts.
 * Shell History::       Repeating previous commands in a shell buffer.
 * Directory Tracking::  Keeping track when the subshell changes directory.
+* Shell Completion::    Getting Emacs to do the typing for user.
 * Shell Options::       Options for customizing Shell mode.
 * Terminal emulator::   An Emacs window as a terminal emulator.
 * Term Mode::           Special Emacs commands used in Term mode.
diff -ru man/misc.texi man/misc.texi
--- man/misc.texi	2006-11-23 15:56:14.000000000 +0300
+++ man/misc.texi	2006-12-06 07:13:29.233344552 +0300
@@ -345,6 +345,7 @@
 * Shell Prompts::          Two ways to recognize shell prompts.
 * History: Shell History.  Repeating previous commands in a shell buffer.
 * Directory Tracking::     Keeping track when the subshell changes directory.
+* Completion: Shell Completion.  Getting Emacs to do the typing for user.
 * Options: Shell Options.  Options for customizing Shell mode.
 * Terminal emulator::      An Emacs window as a terminal emulator.
 * Term Mode::              Special Emacs commands used in Term mode.
@@ -521,18 +522,9 @@
 @item @key{TAB}
 @kindex TAB @r{(Shell mode)}
 @findex comint-dynamic-complete
-Complete the command name or file name before point in the shell buffer
-(@code{comint-dynamic-complete}).  @key{TAB} also completes history
-references (@pxref{History References}) and environment variable names.
-
-@vindex shell-completion-fignore
-@vindex comint-completion-fignore
-The variable @code{shell-completion-fignore} specifies a list of file
-name extensions to ignore in Shell mode completion.  The default
-setting is @code{nil}, but some users prefer @code{("~" "#" "%")} to
-ignore file names ending in @samp{~}, @samp{#} or @samp{%}.  Other
-related Comint modes use the variable @code{comint-completion-fignore}
-instead.
+Complete text before point in the shell buffer
+(@code{comint-dynamic-complete}); for details, see @ref{Shell
+Completion}.
 
 @item M-?
 @kindex M-? @r{(Shell mode)}
@@ -972,6 +964,54 @@
 alternative and more aggressive method of tracking changes in the
 current directory.
 
+@node Shell Completion
+@subsection Shell Mode Completion
+
+The @code{comint-dynamic-complete} command (@key{TAB} in Shell mode),
+like many other Shell mode commands, comes from general-purpose Comint
+mode (@pxref{Shell Mode}).  The exact set of completion features thus
+entirely depends on current buffer mode.  The only thing common
+between them is that completion command looks at text before point and
+attempts to complete it.  The rest of this section describes
+completion features in Shell mode only.  For completion features in
+other modes, see their respective descriptions, if any.
+
+@findex comint-replace-by-expanded-history
+@findex shell-dynamic-complete-environment-variable
+@findex shell-dynamic-complete-command
+@findex shell-replace-by-expanded-directory
+@findex comint-dynamic-complete-filename
+  Shell mode attempts completion treating text as history reference
+(@code{comint-replace-by-expanded-history}) (@pxref{History
+References}), environment variable name
+(@code{shell-dynamic-complete-environment-variable}), in turn.  If
+word before point is exactly at the beginning of shell command and
+does not contain directory separators, completion of command name is
+attempted (@code{shell-dynamic-complete-command}).  Directory stack
+references are expanded (@code{shell-replace-by-expanded-directory}).
+If none of these produces a match, file name completion is attempted
+(@code{comint-dynamic-complete-filename}).
+
+@vindex shell-completion-execonly
+  For purposes of command completion, the beginning of shell command
+is defined as where @code{shell-backward-command} (@pxref{Shell Mode})
+gets if @code{inhibit-field-text-motion} is @code{nil}.  Commands are
+searched in directories from @code{exec-path} (@pxref{Subprocess
+Creation,,,elisp, The Emacs Lisp Reference Manual}).  (Shell mode has
+no idea whatsoever of commands defined in shell subprocess itself,
+through functions, aliases and like.)  Unless
+@code{shell-completion-execonly} is @code{nil}, only executable files
+are considered as completion candidates.
+
+@vindex shell-completion-fignore
+@vindex comint-completion-fignore
+When attempting to complete file names, the variable
+@code{shell-completion-fignore} specifies a list of file name
+extensions to ignore.  The default setting is @code{nil}, but some
+users prefer @code{("~" "#" "%")} to ignore file names ending in
+@samp{~}, @samp{#} or @samp{%}.  Other related Comint modes use the
+variable @code{comint-completion-fignore} instead.
+
 @node Shell Options
 @subsection Shell Mode Options

field movement fix [Re: comint loses prompt boundary]

[Ilya N. Golubev]

Fixing what described on Thu, 07 Sep 2006 00:32:13 +0400 in
<16k64g20tu.fsf@mo.msk.ru> (<comint loses prompt boundary>) in emacs
cvs head (as of 2006-11-23) as follows.  This also makes comint, shell
conform to documentation as suggested in <87slflasys.fsf@mo.msk.ru>.

Cc-ing to Jerry James, <xemacs-beta> since the broken code from emacs
was merged into xemacs packages `comint.el' revision 1.14 of
2006/05/25 02:49:47 +0, and they were among recipients of the original
report.

lisp/ChangeLog

	* comint.el (comint-line-beginning-position): Fix undocumented
	dependency on `inhibit-field-text-motion' value: do the same
	regardless of how this user option is set.

etc/ChangeLog

	* NEWS (Fixed to respects fields): New.
	(Comint changes): In here.

--- lisp/comint.el	2006-11-23 15:55:54.000000000 +0300
+++ lisp/comint.el	2006-12-07 02:53:38.794286184 +0300
@@ -1953,7 +1953,8 @@
     ;; if there are two fields on a line, then the first one is the
     ;; prompt, and the second one is an input field, and is front-sticky
     ;; (as input fields should be).
-    (constrain-to-field (line-beginning-position) (line-end-position))))
+    (let ((inhibit-field-text-motion nil))
+      (constrain-to-field (line-beginning-position) (line-end-position)))))
 
 (defun comint-bol (&optional arg)
   "Go to the beginning of line, then skip past the prompt, if any.
--- etc/NEWS	2006-11-23 15:55:51.000000000 +0300
+++ etc/NEWS	2006-12-07 05:10:21.731250216 +0300
@@ -21,6 +21,39 @@
 so we will look at it and add it to the manual.
 
 \f
+* Incompatible Editing Changes in local gin branch.
+
+** Fixed comint commands to respect fields.
+
+As described in <Fixed `comint-line-beginning-position' to respects
+fields> section.  This includes, but not limited to `comint-bol',
+`comint-insert-previous-argument', `comint-backward-matching-input',
+`comint-bol-or-process-mark', `comint-previous-matching-input',
+`comint-send-input', `comint-copy-old-input',
+`shell-backward-command', `shell-dynamic-complete-command' (including
+inside `comint-dynamic-complete' in Shell mode).
+
+\f
+* Incompatible Lisp Changes in local gin branch.
+
+** Fixed `comint-line-beginning-position' to respect fields.
+
+As controlled by `inhibit-field-text-motion'.  This fixed myriads of
+other functions and commands that depend on it and that rely on it to
+always do so, regardless of `inhibit-field-text-motion' user option,
+at least when `comint-use-prompt-regexp' is `nil'.  Partial list of
+these commands is in <Fixed comint commands to respects fields>
+section.  However, other code certainly may rely on old behavior.
+Have not seen such a code to date.
+
+Introduced in upstream just after addition of (extant) field
+implementation of 2000-01-01.
+
+Other non- interactive functions calling it include
+`comint-replace-by-expanded-history-before-point',
+`comint-get-old-input-default'.
+
+\f
 * Installation Changes in Emacs 22.1
 
 ---
@@ -1461,6 +1494,37 @@
 that need to know whether they are started inside Emacs should check
 INSIDE_EMACS instead of EMACS.
 
+*** Fixed to respects fields.
+
+As controlled by `inhibit-field-text-motion'.  As bug fix, certainly
+incompatible with buggy behavior.
+
+**** Lisp changes.
+
+The core change is in `comint-line-beginning-position'.  This fixed
+myriads of other functions and commands that depend on it and that
+rely on it to always do so, regardless of `inhibit-field-text-motion'
+user option, at least when `comint-use-prompt-regexp' is `nil'.
+Partial list of these commands is in <Editing changes> section.
+However, other code certainly may rely on old behavior.  Have not seen
+such a code to date.
+
+Introduced in upstream emacs just after addition of (extant) field
+implementation of 2000-01-01.
+
+Other non- interactive functions calling it include
+`comint-replace-by-expanded-history-before-point',
+`comint-get-old-input-default'.
+
+**** Editing changes.
+
+Include, but not limited to `comint-bol',
+`comint-insert-previous-argument', `comint-backward-matching-input',
+`comint-bol-or-process-mark', `comint-previous-matching-input',
+`comint-send-input', `comint-copy-old-input',
+`shell-backward-command', `shell-dynamic-complete-command' (including
+inside `comint-dynamic-complete' in Shell mode).
+
 ** M-x Compile changes:
 
 ---

Re: shell completion documentation [Re: comint loses prompt boundary]

[Miles Bader]

"Ilya N. Golubev" <gin@mo.msk.ru> writes:
> The patch is for cvs head as of 2006-11-23.  Note that it describes
> command completion behavior as it *should* be, deliberately not saying
> how it currently breaks if `inhibit-field-text-motion' is not `nil'.

`inhibit-field-text-motion' is not intended to be a user settable
variable; it is for lisp code to temporarily bind to disable field
restrictions.  If you set it permanently, you are asking for trouble.

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: shell completion documentation [Re: comint loses prompt boundary]

[Ilya N. Golubev]

> If you set it permanently, you are asking for trouble.

I ask for behavior of comint that is not only compatible with its
versions, but very useful: to be able to move around comint buffer
with regular text movement commands, including search ones, and to
move that way in any place of buffer, whether it is user input or
process output.  By setting `inhibit-field-text-motion' user option
(as suggested by its docstring) or otherwise, but there should be a
way to do that.

> `inhibit-field-text-motion' is not intended to be a user settable
> variable;

If decide to change it this way, please document that, in its
docstring in the first place (never checked for other things to be
changed).  In this case please also document how does comint user have
particular comint buffer ignore comint fields in text movement
commands as described above.

Re: shell completion documentation [Re: comint loses prompt boundary]

[Miles Bader]

"Ilya N. Golubev" <gin@mo.msk.ru> writes:
> I ask for behavior of comint that is not only compatible with its
> versions, but very useful: to be able to move around comint buffer
> with regular text movement commands, including search ones, and to
> move that way in any place of buffer, whether it is user input or
> process output.

You might try `comint-use-prompt-regexp', but that code is likely
bit-rotted, as it doesn't get much use.

>  By setting `inhibit-field-text-motion' user option (as suggested by
> its docstring)

`inhibit-field-text-motion' is not a user option.  [Try to edit it with
`customize-option' -- you can't.]

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: shell completion documentation [Re: comint loses prompt boundary]

[Richard Stallman]

Thanks, but no.  This is too much detail, and too dense.

I think the existing text is ok.  It says that TAB completes shell
commands and file names.  I think that is enough.

Re: shell completion documentation

[Ilya N. Golubev]

> This is too much detail, and too dense.

That's the point.  Just as much as any <specific test case> for
`comint-dynamic-complete' bug report.


> I think the existing text is ok.

That is, requesting these details from *users* reporting bugs is ok,
but for *maintainers* to document the same user visible details is
unreasonable?

The description with exactly that much detail has to exist, so that
maintainers can quickly get to it and not ask users to educate them on
package they are supposed to maintain.  Perhaps the description is
indeed too detailed for regular user.  Then it just should be placed
not in user manual, but elsewhere in emacs distribution, with
reference to it from manual.

field movement fix: `NEWS' change

[Ilya N. Golubev]

In <82odq9aswt.fsf@mo.msk.ru> of Tue, 12 Dec 2006 21:08:34 +0300 the
emacs `NEWS' patch should be as follows.

The only change is removing references to any local development
branches, just as if the patch is applied to emacs cvs head version.
The rest of the message, including `etc/ChangeLog' entry, is the same.

--- etc/NEWS	2006-12-07 04:58:14 +0300
+++ etc/NEWS	2006-12-07 05:10:21 +0300
@@ -1494,6 +1494,37 @@
 that need to know whether they are started inside Emacs should check
 INSIDE_EMACS instead of EMACS.
 
+*** Fixed to respects fields.
+
+As controlled by `inhibit-field-text-motion'.  As bug fix, certainly
+incompatible with buggy behavior.
+
+**** Lisp changes.
+
+The core change is in `comint-line-beginning-position'.  This fixed
+myriads of other functions and commands that depend on it and that
+rely on it to always do so, regardless of `inhibit-field-text-motion'
+user option, at least when `comint-use-prompt-regexp' is `nil'.
+Partial list of these commands is in <Editing changes> section.
+However, other code certainly may rely on old behavior.  Have not seen
+such a code to date.
+
+Introduced in upstream emacs just after addition of (extant) field
+implementation of 2000-01-01.
+
+Other non- interactive functions calling it include
+`comint-replace-by-expanded-history-before-point',
+`comint-get-old-input-default'.
+
+**** Editing changes.
+
+Include, but not limited to `comint-bol',
+`comint-insert-previous-argument', `comint-backward-matching-input',
+`comint-bol-or-process-mark', `comint-previous-matching-input',
+`comint-send-input', `comint-copy-old-input',
+`shell-backward-command', `shell-dynamic-complete-command' (including
+inside `comint-dynamic-complete' in Shell mode).
+
 ** M-x Compile changes:
 
 ---

Re: shell completion documentation

[Richard Stallman]

    > This is too much detail, and too dense.

    That's the point.  Just as much as any <specific test case> for
    `comint-dynamic-complete' bug report.

Bug reports and manuals are not comparable.

    That is, requesting these details from *users* reporting bugs is ok,
    but for *maintainers* to document the same user visible details is
    unreasonable.

Absolutely.  To we debug a bug, we need the details; if they make the
bug report hard to read, we just have to roll up our sleeves and read
it anyway.

However, there is no obligation to make the manual so hard to read,
and it would be counterproductive to do so.

bug reports vs manuals [Re: shell completion documentation]

[Ilya N. Golubev]

> Bug reports and manuals are not comparable.

Only partially.  After all, they describe the related things, the
incorrect / correct behaviors of some tool.  And to state that the
behavior is incorrect, one has to have a definition of correct
behavior, which is normally supposed to be in documentation.  So bug
report normally relies on documentation.

> details; if they make the
> bug report hard to read, we just have to roll up our sleeves and read
> it anyway.

If something it hard to read, writing it is generally even harder.
And if something is hard to read even for maintainers, how can one
expect user to write that?

> there is no obligation to make the manual so hard to read,

Only in sense of no obligations for this program at all, as described
by C-h C-w.  Still one would normally expect documentation to answer
which behavior is correct and which is not.

> and it would be counterproductive to do so.

What is the alternative?  Not to document the correct behavior once
and forever, perhaps in some appendix, but instead to have users in
every discussion of software, bug reports or other, describe it again
and again.  Do you call this <productive>?


Anyway, for this particular issue, comint commands when
`inhibit-field-text-motion', have already described which behavior is
desired and why.

Re: comint loses prompt boundary

[Ilya N. Golubev]

> `inhibit-field-text-motion' is not a user option.

Confirming that it is not marked so, thus correcting the misstatemet
in my <887iwvis8x.fsf@mo.msk.ru>.  The rest of it, wrt why (the
equivalent of) it being user option is useful and desired, still
holds.  That is, it is at least very convenient to be able to
disregard fields in point movement commands, primarily big- block
ones, like `W' and other in viper vi state.  Still fields should be
honored in commands / functions specifically intended for comint mode,
for buffers with this particular field structure.

Re: shell completion documentation

[Richard Stallman]

    The description with exactly that much detail has to exist, so that
    maintainers can quickly get to it and not ask users to educate them on
    package they are supposed to maintain.  Perhaps the description is
    indeed too detailed for regular user.  Then it just should be placed
    not in user manual, but elsewhere in emacs distribution, with
    reference to it from manual.

Maybe you are right in this point.  Which are the maintainers that
need to know this information?  Is it maintainers of shell.el, or
maintainers of other parts of Emacs?  If just shell.el, let's
put it in a comment.  If maintainers of other parts, let's
put it in some doc string.

customizing inhibit-field-text-motion [Re: comint loses prompt boundary]

[Ilya N. Golubev]

`inhibit-field-text-motion', however, is marked as user option in
xemacs.  Was so since field (re-) implementation appeared in its
`xemacs-base' package on 2004/09/07 20:09:16 +0.  This is perhaps why
assumed that is is also user option in emacs.

On Thu, 14 Dec 2006 00:39:52 +0900 Miles Bader wrote in
<87lklbu7nb.fsf@catnip.gol.com> about it in comint mode buffers:

> If you set it permanently, you are asking for trouble.

This should also hold for comint in xemacs, now that it is largely
synched with emacs.  Maintainer(s) of fields in both in emacs and
xemacs, please clarify `inhibit-field-text-motion' status.

This does not necessarily mean stripping it of user option mark.
Setting it permanently to non-`nil' may certainly be useful as
described in other messages on the topic.  This is the primary reason
why I personally favor making / leaving `inhibit-field-text-motion'
user option.  This has nothing to do with compatibility with xemacs
implementation, which is even inconsistent in other ways as mentioned
in <13lkpeawcu.fsf@mo.msk.ru> of Thu, 24 Aug 2006 21:15:29 +0400
(<checking for fields>).


Note that `inhibit-field-text-motion' status issue is largely
independent of those described in <checking for fields>.  Most of them
remain even if `inhibit-field-text-motion' becomes officially
customizeable.  However, setting `inhibit-field-text-motion' is a way
around some of these issues.

Re: shell completion documentation

[Ilya N. Golubev]

> Which are the maintainers that
> need to know this information?

Part of the text in the documentation patch is about `comint.el' (and
thus of concern to all of innumerable modes based on it).  The other
text is specifically about `shell.el'.

> If just shell.el, let's
> put it in a comment.

What will make maintainers read it before sending (unnecessary)
questions to users?

Re: shell completion documentation

[Richard Stallman]

    Part of the text in the documentation patch is about `comint.el' (and
    thus of concern to all of innumerable modes based on it).

Can you find a suitable doc string to put that in?

							       The other
    text is specifically about `shell.el'.

Can you find a suitable doc string to put that in?
Or a good place in shell.el?

    What will make maintainers read it before sending (unnecessary)
    questions to users?

People normally read the comments in the vicinity of the code they are
working on.

what makes read it? [Re: shell completion documentation]

[Ilya N. Golubev]

> People normally read the comments in the vicinity of the code they are
> working on.

Remember, the case is that they feel that bug report (combined with
package documentation) is incomplete.  So most likely they will not
look at code at all.  Even if they do, what will be the <vicinity of
the code they are working on>?  Most likely just the place found by
`find-function', far from beginning of the file.

So the issue

    What will make maintainers read it before sending (unnecessary)
    questions to users?

remains.  It appears that at least a reference in manual is necessary.