From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: all-completions DTWT for "" and non-nil HIDE-SPACES
Date: Fri, 12 May 2006 17:26:51 -0700 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICOEPLDFAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jeac9myiog.fsf@sykes.suse.de>
> The doc string for all-completions says that if the first arg
> doesn't start with a space then a non-nil 4th arg means ignore
> candidates that start with a space. "Start with a space" means
> that the first character is a space.
> This is undefined (ambiguous) if the string has no first
> character (doesn't start at all; is empty).
I don't follow. An empty string clearly does not start with a space.
What does it start with? All of the alligators on the moon are red. True or
false? Every character that the empty string starts with is a space, no? Or
is every such character a non-space? or a balloon?
To me, "start with a space" doesn't mean much for a string that does not
start at all. If it has no first character, then it doesn't start with
either a space or a non-space.
The real question, however, is what the `all-completions' functionality
should be for an empty string. If the first character of a string determines
some behavior, and the string can be empty, then the empty-string behavior
needs also to be defined (and documented). That is, it needs to be defined
separately from the first-character behavior - they are disjoint cases.
> I think the functionality should be changed
I don't agree. That would change the behaviour of buffer
completions: If you type TAB in the empty minibuffer when being
prompted for a buffer you don't want buffers starting with a space
in the list of completions.
That's true, but TAB is not bound to `all-completions'. I want to fix
`all-completions'; I don't want to change minibuffer completion. What you
correctly point out is that I was wrong in my assumption that no existing
code depends on this (bugged, IMO) behavior.
A quick look at the C code tells me that `all-completions' is used only once
(by Fminibuffer_completion_help), and then only with a non-nil value for
HIDE-SPACES. I could be wrong (I don't speak C well), but I think I'm right.
IOW, the C code does not use the possibility of providing different values
for HIDE-SPACES at all. The definition of `all-completion' wrt HIDE-SPACES
should not depend on a single use of it. If that were to be the case, then
we might as well eliminate the HIDE-SPACES argument and always give it the
non-nil behavior. `all-completions' is supposed to be more general than
that.
If we make the fix to `all-completions' that I propose, then, yes,
Fminibuffer_completion_help would need to be redefined to not simply call
all-completions with a non-nil HIDE-SPACES arg. It would itself need to
treat "" so as to avoid completions that start with a space. That behavior
is part of _its_ logic, not part of `all-completions' logic.
IOW, I'm suggesting that `all-completions' should return all of the
completions (including those that start with space) when given "", but
Fminibuffer_completion_help (hence also `minibuffer-complete', and
`minibuffer-complete-word', which call Fminibuffer_completion_help) should
keep the behavior it has now. It just wouldn't be able to rely on providing
a non-nil HIDE-SPACES to `all-completions' - it would have to treat the ""
case itself since it doesn't want all completions in the case of no typed
input.
My concern is using `all-completions' from Lisp. The unique use of
`all-completions' in the C code could be made to work with the fix I
suggested.
Since I was wrong about C code depending on the current behavior, perhaps
I'm also wrong about Lisp code depending on it. The fix would require first
checking all calls to `all-completions' that provide an explicit HIDE-SPACES
arg. I just spent a few minutes doing that, and guess what? (drum roll...) I
found zero (0) uses of an explicit HIDE-SPACES arg! The only place I found
this used anywhere in the Emacs code is in the C code, and then only in a
single call by Fminibuffer_completion_help.
`all-completions' should be for Lisp programmers, not just for
Fminibuffer_completion_help. The (all-completions "" ...) idiom should DTRT:
return _all_ completions. I don't see any reason not to fix this now.
next prev parent reply other threads:[~2006-05-13 0:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-12 21:27 all-completions DTWT for "" and non-nil HIDE-SPACES Drew Adams
2006-05-12 21:37 ` Drew Adams
2006-05-12 22:36 ` Andreas Schwab
2006-05-13 0:26 ` Drew Adams [this message]
2006-05-13 6:35 ` Andreas Schwab
2006-05-15 17:20 ` Kevin Rodgers
2006-05-13 14:57 ` Drew Adams
2006-05-13 8:27 ` Eli Zaretskii
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=DNEMKBNJBGPAOPIJOOICOEPLDFAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/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).