* bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
@ 2013-11-26 17:11 Drew Adams
2014-01-07 12:04 ` Bastien Guerry
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-11-26 17:11 UTC (permalink / raw)
To: 15980
Seems like the behavior is wrong in this case, but I see that the same
behavior is found for Emacs 20 through 24. So I cannot say for sure
whether this is a bug. At least the behavior does not seem to follow
the doc.
The doc ((emacs) `Completion Commands') says that SPC does this:
Complete up to one word from the minibuffer text before point
(`minibuffer-complete-word').
emacs -Q
(defun cmd\ \ \ \ w\ ith\ spaces () (interactive) (message "SPACES"))
(defun cmd-without-spaces () (interactive) (message "NOPE"))
M-x cm SPC ; correctly completes to `cmd'
SPC ; completes to `cmd '
Since SPC is supposed to complete a word at a time, and since both ` '
and `-' are word separators, I would expect that there are two
word completions for the prefix `cmd': `cmd ' and `cmd-'.
So I would expect to see *Completions* displayed, showing the two
candidates `cmd w ith spaces' and `cmd-without-spaces'.
Admittedly, this is a corner use case.
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-11-20 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
2013-11-26 17:11 bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly Drew Adams
@ 2014-01-07 12:04 ` Bastien Guerry
2014-01-07 17:06 ` Drew Adams
0 siblings, 1 reply; 6+ messages in thread
From: Bastien Guerry @ 2014-01-07 12:04 UTC (permalink / raw)
To: Drew Adams; +Cc: 15980
Drew Adams <drew.adams@oracle.com> writes:
> Seems like the behavior is wrong in this case, but I see that the same
> behavior is found for Emacs 20 through 24. So I cannot say for sure
> whether this is a bug. At least the behavior does not seem to follow
> the doc.
>
> The doc ((emacs) `Completion Commands') says that SPC does this:
>
> Complete up to one word from the minibuffer text before point
> (`minibuffer-complete-word').
>
> emacs -Q
>
> (defun cmd\ \ \ \ w\ ith\ spaces () (interactive) (message "SPACES"))
>
> (defun cmd-without-spaces () (interactive) (message "NOPE"))
>
> M-x cm SPC ; correctly completes to `cmd'
> SPC ; completes to `cmd '
>
> Since SPC is supposed to complete a word at a time, and since both ` '
> and `-' are word separators, I would expect that there are two
> word completions for the prefix `cmd': `cmd ' and `cmd-'.
>
> So I would expect to see *Completions* displayed, showing the two
> candidates `cmd w ith spaces' and `cmd-without-spaces'.
See the first comment in `completion--try-word-completion':
the function considers that either a space *or* an hyphen will
be used to separate words. The "or" is exclusive.
> Admittedly, this is a corner use case.
Yes -- note that TAB works fine here instead of SPC.
The only place I can think of where this could be a problem
is the info manual (`g' or `i' to go to a node or to find an
index entry.) Still, you're not like to stumble on such case.
I'm for closing this bug until it really hit someone.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
2014-01-07 12:04 ` Bastien Guerry
@ 2014-01-07 17:06 ` Drew Adams
2014-01-07 17:14 ` Bastien
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2014-01-07 17:06 UTC (permalink / raw)
To: Bastien Guerry; +Cc: 15980
> > Since SPC is supposed to complete a word at a time, and since both
> > ` ' and `-' are word separators, I would expect that there are two
> > word completions for the prefix `cmd': `cmd ' and `cmd-'.
> >
> > So I would expect to see *Completions* displayed, showing the two
> > candidates `cmd w ith spaces' and `cmd-without-spaces'.
>
> See the first comment in `completion--try-word-completion':
> the function considers that either a space *or* an hyphen will
> be used to separate words. The "or" is exclusive.
`completion--try-word-completion' is an *implementation*. If that's
what it does then it does not do what the doc says, right? So either
the doc needs to be fixed to fit the implementation or vice versa, no?
> > Admittedly, this is a corner use case.
I meant corner case for command names. It is not a corner case
to have space chars in completion candidates.
> Yes -- note that TAB works fine here instead of SPC.
>
> The only place I can think of where this could be a problem
> is the info manual (`g' or `i' to go to a node or to find an
> index entry.)
Why is that the only place you can think of? Are you saying that
because those completion candidates contain space chars? There
are *lot* of places where Emacs can use completion for candidates
that contain space chars. `completing-read' is completely
general. Emacs should make no assumptions about whether completion
candidates happen to contain spaces.
> Still, you're not like to stumble on such case.
What makes you say that?
> I'm for closing this bug until it really hit someone.
That's not right. The product and the doc do not agree, as you
have pointed out. That alone is a bug. One way or another it
should be fixed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
2014-01-07 17:06 ` Drew Adams
@ 2014-01-07 17:14 ` Bastien
2014-01-07 17:50 ` Drew Adams
0 siblings, 1 reply; 6+ messages in thread
From: Bastien @ 2014-01-07 17:14 UTC (permalink / raw)
To: Drew Adams; +Cc: 15980
Drew Adams <drew.adams@oracle.com> writes:
>> > Since SPC is supposed to complete a word at a time, and since both
>> > ` ' and `-' are word separators, I would expect that there are two
>> > word completions for the prefix `cmd': `cmd ' and `cmd-'.
>> >
>> > So I would expect to see *Completions* displayed, showing the two
>> > candidates `cmd w ith spaces' and `cmd-without-spaces'.
>>
>> See the first comment in `completion--try-word-completion':
>> the function considers that either a space *or* an hyphen will
>> be used to separate words. The "or" is exclusive.
>
> `completion--try-word-completion' is an *implementation*. If that's
> what it does then it does not do what the doc says, right? So either
> the doc needs to be fixed to fit the implementation or vice versa, no?
`completion--try-word-completion' does not have a docstring.
>> > Admittedly, this is a corner use case.
>
> I meant corner case for command names. It is not a corner case
> to have space chars in completion candidates.
Agreed.
>> Yes -- note that TAB works fine here instead of SPC.
>>
>> The only place I can think of where this could be a problem
>> is the info manual (`g' or `i' to go to a node or to find an
>> index entry.)
>
> Why is that the only place you can think of?
Because my thinking is limited.
> Are you saying that
> because those completion candidates contain space chars? There
> are *lot* of places where Emacs can use completion for candidates
> that contain space chars.
My point is that there is little chance that *many* non-contrived
strings can be completed either as xxx- or as xxx\ (wich a space.)
> `completing-read' is completely
> general. Emacs should make no assumptions about whether completion
> candidates happen to contain spaces.
Agreed. I couldn't find a fix.
>> Still, you're not like to stumble on such case.
>
> What makes you say that?
Instinct. But I can be proven wrong, of course.
>> I'm for closing this bug until it really hit someone.
>
> That's not right. The product and the doc do not agree, as you
> have pointed out. That alone is a bug. One way or another it
> should be fixed.
So let's keep this open and find someone that can fix it properly.
--
Bastien
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
2014-01-07 17:14 ` Bastien
@ 2014-01-07 17:50 ` Drew Adams
2014-01-07 23:37 ` Bastien
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2014-01-07 17:50 UTC (permalink / raw)
To: Bastien; +Cc: 15980
> >> See the first comment in `completion--try-word-completion':
> >> the function considers that either a space *or* an hyphen will
> >> be used to separate words. The "or" is exclusive.
> >
> > `completion--try-word-completion' is an *implementation*. If
> > that's what it does then it does not do what the doc says, right?
> > So either the doc needs to be fixed to fit the implementation or
> > vice versa, no?
>
> `completion--try-word-completion' does not have a docstring.
I meant the doc I cited earlier. It's not about whether that
function's behavior matches its code comment. It's about whether
Emacs behavior matches what we tell users that behavior is.
> > Are you saying that because those completion candidates contain
> > space chars? There are *lot* of places where Emacs can use
> > completion for candidates that contain space chars.
>
> My point is that there is little chance that *many* non-contrived
> strings can be completed either as xxx- or as xxx\ (wich a space.)
OK.
> > `completing-read' is completely general. Emacs should make no
> > assumptions about whether completion candidates happen to contain
> > spaces.
>
> Agreed. I couldn't find a fix.
Then perhaps leave it open until someone can.
One possible fix is to document the actual behavior instead of
saying what we say now.
> >> I'm for closing this bug until it really hit someone.
> >
> > That's not right. The product and the doc do not agree, as you
> > have pointed out. That alone is a bug. One way or another it
> > should be fixed.
>
> So let's keep this open and find someone that can fix it properly.
OK. But again, if you can describe the actual behavior, perhaps
it is enough to correct what we say currently.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly
2014-01-07 17:50 ` Drew Adams
@ 2014-01-07 23:37 ` Bastien
0 siblings, 0 replies; 6+ messages in thread
From: Bastien @ 2014-01-07 23:37 UTC (permalink / raw)
To: Drew Adams; +Cc: 15980-done
Hi Drew,
Drew Adams <drew.adams@oracle.com> writes:
> OK. But again, if you can describe the actual behavior, perhaps
> it is enough to correct what we say currently.
This is now fixed in trunk. Please test and report any problem.
--
Bastien
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-07 23:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-26 17:11 bug#15980: 24.3.50; `minibuffer-complete-word': case where it does not work correctly Drew Adams
2014-01-07 12:04 ` Bastien Guerry
2014-01-07 17:06 ` Drew Adams
2014-01-07 17:14 ` Bastien
2014-01-07 17:50 ` Drew Adams
2014-01-07 23:37 ` Bastien
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).