[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16453: 24.3.50; Motion functions not respecting field boundaries as
From: |
Bastien Guerry |
Subject: |
bug#16453: 24.3.50; Motion functions not respecting field boundaries as documented |
Date: |
Fri, 24 Jan 2014 17:15:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
Drew Adams <drew.adams@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
Description: Text Data
--
Bastien