From: Drew Adams <drew.adams@oracle.com>
To: 16453@debbugs.gnu.org
Subject: bug#16453: 24.3.50; Motion functions not respecting field boundaries as documented
Date: Wed, 15 Jan 2014 08:17:19 -0800 (PST) [thread overview]
Message-ID: <c28d0f8f-d0d5-4a50-889a-8f4e205234e2@default> (raw)
(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@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'
next reply other threads:[~2014-01-15 16:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 16:17 Drew Adams [this message]
2014-01-24 16:15 ` bug#16453: 24.3.50; Motion functions not respecting field boundaries as documented Bastien Guerry
2014-01-27 11:07 ` Bastien Guerry
2014-01-27 14:55 ` Drew Adams
2014-02-05 10:32 ` Bastien
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=c28d0f8f-d0d5-4a50-889a-8f4e205234e2@default \
--to=drew.adams@oracle.com \
--cc=16453@debbugs.gnu.org \
/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).