GNU bug report logs - #16453
24.3.50; Motion functions not respecting field boundaries as documented

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16453 in the body.
You can then email your comments to 16453 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Motion functions not respecting field boundaries as
 documented
Date: Wed, 15 Jan 2014 08:17:19 -0800 (PST)

(elisp) `Introduction to Minibuffers' says this:

 The text in the minibuffer always starts with the "prompt string",
 the text that was specified by the program that is using the minibuffer
 to tell the user what sort of input to type.  This text is marked
 read-only so you won't accidentally delete or change it.  It is also
 marked as a field (*note Fields::), so that certain motion functions,
 including `beginning-of-line', `forward-word', `forward-sentence', and
 `forward-paragraph', stop at the boundary between the prompt and the
 actual text.

So I would expect that `backward-word' and `backward-sexp' would stop at
the field boundary, which is the end of the prompt.  `beginning-of-line'
does indeed do this, as the doc suggests.  But `backward-word' and
`backward-sexp', at least, do not - they move backward into the prompt.

Seems like this is the wrong behavior, and the doc describes the right
behavior.  But perhaps it is the other way around and this is a doc bug.

FWIW, I noticed this because I use a different Lisp symbol completion
function in the minibuffer.  It moves `backward-sexp' and later tries to
delete the text corresponding to the symbol prefix to be completed.  If
that prefix is empty then it raises the error of attempting to modify
read-only text.  If `backward-sexp' did what the doc says then it would
not leave the field and enter the prompt.  This is not important to the
bug report - just mentioning how I happened to notice this.



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-01-07 on ODIEONE
Bzr revision: 115916 bzg <at> gnu.org-20140107233629-du2solx6tmxnx0np
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

Message #8 received at 16453 <at> debbugs.gnu.org (full text, mbox):

From: Bastien Guerry <bzg <at> altern.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16453 <at> debbugs.gnu.org
Subject: Re: bug#16453: 24.3.50;
 Motion functions not respecting field boundaries as documented
Date: Fri, 24 Jan 2014 17:15:03 +0100

[Message part 1 (text/plain, inline)]

Drew Adams <drew.adams <at> oracle.com> writes:

> (elisp) `Introduction to Minibuffers' says this:
>
>  The text in the minibuffer always starts with the "prompt string",
>  the text that was specified by the program that is using the minibuffer
>  to tell the user what sort of input to type.  This text is marked
>  read-only so you won't accidentally delete or change it.  It is also
>  marked as a field (*note Fields::), so that certain motion functions,
>  including `beginning-of-line', `forward-word', `forward-sentence', and
>  `forward-paragraph', stop at the boundary between the prompt and the
>  actual text.
>
> So I would expect that `backward-word' and `backward-sexp' would stop at
> the field boundary, which is the end of the prompt.  `beginning-of-line'
> does indeed do this, as the doc suggests.  But `backward-word' and
> `backward-sexp', at least, do not - they move backward into the prompt.
>
> Seems like this is the wrong behavior, and the doc describes the right
> behavior.  But perhaps it is the other way around and this is a doc
> bug.

The attached patch let `forward-word' does what the docstring says.
It uses `t' as the value for the ESCAPE-FROM-EDGE parameter within
the call to `constrain-to-field'.

I agree this seems the correct behavior in the minibuffer.

But I'm often frustrated by such constraints for `beginning-of-line'
(e.g. hit G c on a Gnus group and get stuck in a non-selected field
anyone?).

So perhaps the nil value for ESCAPE-FROM-EDGE is intentional here.

In any case, this is just to bring attention to the problem and
a possible solution: I don't know C so I won't commit this myself.

[syntax.c.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

-- 
 Bastien

Message #11 received at 16453 <at> debbugs.gnu.org (full text, mbox):

From: Bastien Guerry <bzg <at> altern.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16453 <at> debbugs.gnu.org
Subject: Re: bug#16453: 24.3.50;
 Motion functions not respecting field boundaries as documented
Date: Mon, 27 Jan 2014 12:07:20 +0100

Hi Drew,

Bastien Guerry <bzg <at> altern.org> writes:

> The attached patch let `forward-word' does what the docstring says.
> It uses `t' as the value for the ESCAPE-FROM-EDGE parameter within
> the call to `constrain-to-field'.

While I'm waiting for a core maintainer to have a look at this,
can you test the patch and report any side-effect?

Thanks,

-- 
 Bastien

Message #14 received at 16453 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Bastien Guerry <bzg <at> altern.org>
Cc: 16453 <at> debbugs.gnu.org
Subject: RE: bug#16453: 24.3.50; Motion functions not respecting field
 boundaries as documented
Date: Mon, 27 Jan 2014 06:55:04 -0800 (PST)

> While I'm waiting for a core maintainer to have a look at this,
> can you test the patch and report any side-effect?

No, sorry.  I don't build Emacs from C sources.  I would test
a Lisp patch if one were available.  But you don't really need
me to test it.  I think the bug report is pretty clear, and I'm
sure you understand it OK.  If you are unsure, let me know.
And thanks for working on this.

Message #19 received at 16453-done <at> debbugs.gnu.org (full text, mbox):

From: Bastien <bzg <at> altern.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 16453-done <at> debbugs.gnu.org
Subject: Re: bug#16453: 24.3.50; Motion functions not respecting field
 boundaries as documented
Date: Wed, 05 Feb 2014 11:32:21 +0100

Hi Drew,

Drew Adams <drew.adams <at> oracle.com> writes:

>> While I'm waiting for a core maintainer to have a look at this,
>> can you test the patch and report any side-effect?
>
> No, sorry.  I don't build Emacs from C sources.  I would test
> a Lisp patch if one were available.  But you don't really need
> me to test it.  I think the bug report is pretty clear, and I'm
> sure you understand it OK.  If you are unsure, let me know.
> And thanks for working on this.

I committed the patch.  Now closing this bug.
Thanks for reporting this,

-- 
 Bastien

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.