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

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Wed, 15 Jan 2014 16:18:02 UTC

Severity: normal

Found in version 24.3.50

Done: Bastien <bzg <at> altern.org>

Bug is archived. No further changes may be made.

Full log


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

This bug report was last modified 11 years and 170 days ago.

Previous Next


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