* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
@ 2018-07-19 17:55 Stephen Berman
2018-07-19 18:19 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2018-07-19 17:55 UTC (permalink / raw)
To: 32215
0. emacs -Q
1. C-x d / ~ TAB
This pops up a *Completions* buffer showing directory names of all
members of (system-users), e.g. steve/
2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
completes to steve/
The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
TAB' here completes to ~/Downloads/
I tried debugging but only got as far as completion--some; when stepping
through that after '/~stev TAB' *Messages* shows this:
Result: (closure ((metadata metadata (category . file) (completion--unquote-requote . t)) (point . 6) (pred . file-exists-p) (table . completion-file-name-table) (string . "/~stev") (n . 1) t) (style) (funcall (nth n (assq style completion-styles-alist)) string table pred point))
[2 times]
Result: (substring basic partial-completion emacs22)
Result: (substring basic partial-completion emacs22)
Result: substring
Result: nil
In contrast, with '/~steve TAB':
Result: (closure ((metadata metadata (category . file) (completion--unquote-requote . t)) (point . 6) (pred . file-exists-p) (table . completion-file-name-table) (string . "~steve") (n . 1) t) (style) (funcall (nth n (assq style completion-styles-alist)) string table pred point))
[2 times]
Result: (substring basic partial-completion emacs22)
Result: (substring basic partial-completion emacs22)
Result: substring
Result: ("~steve/" . 7)
In GNU Emacs 27.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.22.28)
of 2018-07-18 built on rosalinde
Repository revision: 04a32fa60bead4359bc9353af67f26958c795593
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux From Scratch
Recent messages:
scroll-up-command: End of buffer
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-vnhsiy-ephemeral...done
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-L5CVOB-ephemeral...done
scroll-up-command: End of buffer
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-GXyYYJ-ephemeral...done
Contacting host: debbugs.gnu.org:443
Opening nndoc server on /tmp/gnus-temp-group-x4tMir-ephemeral...done
Configured using:
'configure 'CFLAGS=-Og -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY ACL
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 THREADS LCMS2
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-19 17:55 bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name> Stephen Berman
@ 2018-07-19 18:19 ` Eli Zaretskii
2018-07-19 20:11 ` Stephen Berman
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2018-07-19 18:19 UTC (permalink / raw)
To: Stephen Berman; +Cc: 32215
> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Thu, 19 Jul 2018 19:55:18 +0200
>
> 0. emacs -Q
> 1. C-x d / ~ TAB
> This pops up a *Completions* buffer showing directory names of all
> members of (system-users), e.g. steve/
> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
> TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
> completes to steve/
>
> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
> TAB' here completes to ~/Downloads/
Doesn't happen here, FWIW. Strange.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-19 18:19 ` Eli Zaretskii
@ 2018-07-19 20:11 ` Stephen Berman
2018-07-20 1:02 ` Noam Postavsky
2018-07-20 6:39 ` Eli Zaretskii
0 siblings, 2 replies; 16+ messages in thread
From: Stephen Berman @ 2018-07-19 20:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 32215
On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>
>> 0. emacs -Q
>> 1. C-x d / ~ TAB
>> This pops up a *Completions* buffer showing directory names of all
>> members of (system-users), e.g. steve/
>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>> TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>> completes to steve/
>>
>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>> TAB' here completes to ~/Downloads/
>
> Doesn't happen here, FWIW. Strange.
Strange indeed, assuming you tested on GNU/Linux or another POSIX
system, since IIUC on MS-Windows system-users returns only
user-real-login-name (at least it does here on Emacs 25.3 under Windows
8). I also tested on another GNU/Linux system I have with Emacs 24.3
and see exactly the same behavior I described above.
Steve Berman
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-19 20:11 ` Stephen Berman
@ 2018-07-20 1:02 ` Noam Postavsky
2018-07-20 6:40 ` Eli Zaretskii
2018-07-20 8:31 ` Stephen Berman
2018-07-20 6:39 ` Eli Zaretskii
1 sibling, 2 replies; 16+ messages in thread
From: Noam Postavsky @ 2018-07-20 1:02 UTC (permalink / raw)
To: Stephen Berman; +Cc: 32215
Stephen Berman <stephen.berman@gmx.net> writes:
> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>>
>>> 0. emacs -Q
>>> 1. C-x d / ~ TAB
>>> This pops up a *Completions* buffer showing directory names of all
>>> members of (system-users), e.g. steve/
>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>> TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>> completes to steve/
>>>
>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>> TAB' here completes to ~/Downloads/
>>
>> Doesn't happen here, FWIW. Strange.
>
> Strange indeed, assuming you tested on GNU/Linux or another POSIX
> system, since IIUC on MS-Windows system-users returns only
> user-real-login-name (at least it does here on Emacs 25.3 under Windows
> 8). I also tested on another GNU/Linux system I have with Emacs 24.3
> and see exactly the same behavior I described above.
I see it on both Windows and GNU/Linux. I notice that the after typing
the first letter of the user name, the leading "/" is no longer in
shadow face, i.e., Emacs is looking for a directory starting with "~"
under the root directory.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-19 20:11 ` Stephen Berman
2018-07-20 1:02 ` Noam Postavsky
@ 2018-07-20 6:39 ` Eli Zaretskii
1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2018-07-20 6:39 UTC (permalink / raw)
To: Stephen Berman; +Cc: 32215
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 32215@debbugs.gnu.org
> Date: Thu, 19 Jul 2018 22:11:37 +0200
>
> >> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
> >> TAB' here completes to ~/Downloads/
> >
> > Doesn't happen here, FWIW. Strange.
>
> Strange indeed, assuming you tested on GNU/Linux or another POSIX
> system
I tested on GNU/Linux, yes.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 1:02 ` Noam Postavsky
@ 2018-07-20 6:40 ` Eli Zaretskii
2018-07-20 8:31 ` Stephen Berman
1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2018-07-20 6:40 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 32215, stephen.berman
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 32215@debbugs.gnu.org
> Date: Thu, 19 Jul 2018 21:02:11 -0400
>
> I see it on both Windows and GNU/Linux.
What did you type on Windows, exactly? If I type "C-x d / ~ TAB", I
get a single completion with my user-name, as expected. How did you
get more than one completion?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 1:02 ` Noam Postavsky
2018-07-20 6:40 ` Eli Zaretskii
@ 2018-07-20 8:31 ` Stephen Berman
2018-07-20 13:58 ` Noam Postavsky
1 sibling, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2018-07-20 8:31 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 32215
On Thu, 19 Jul 2018 21:02:11 -0400 Noam Postavsky <npostavs@gmail.com> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>>>
>>>> 0. emacs -Q
>>>> 1. C-x d / ~ TAB
>>>> This pops up a *Completions* buffer showing directory names of all
>>>> members of (system-users), e.g. steve/
>>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>>> TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>>> completes to steve/
>>>>
>>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>>> TAB' here completes to ~/Downloads/
>>>
>>> Doesn't happen here, FWIW. Strange.
>>
>> Strange indeed, assuming you tested on GNU/Linux or another POSIX
>> system, since IIUC on MS-Windows system-users returns only
>> user-real-login-name (at least it does here on Emacs 25.3 under Windows
>> 8). I also tested on another GNU/Linux system I have with Emacs 24.3
>> and see exactly the same behavior I described above.
>
> I see it on both Windows and GNU/Linux.
Like Eli, I'm surprised you see it on Windows.
> I notice that the after typing
> the first letter of the user name, the leading "/" is no longer in
> shadow face,
Yes, I didn't notice that when I tested before but I do now.
> i.e., Emacs is looking for a directory starting with "~"
> under the root directory.
I suppose so, though it's still surprising that it only completes to
/~steve/ when typing /~steve, not /~stev. Note that (at least here)
'/home/stev TAB' also completes to /home/steve/.
Steve Berman
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 8:31 ` Stephen Berman
@ 2018-07-20 13:58 ` Noam Postavsky
2018-07-20 14:28 ` Stephen Berman
0 siblings, 1 reply; 16+ messages in thread
From: Noam Postavsky @ 2018-07-20 13:58 UTC (permalink / raw)
To: Stephen Berman; +Cc: 32215
On 20 July 2018 at 04:31, Stephen Berman <stephen.berman@gmx.net> wrote:
> On Thu, 19 Jul 2018 21:02:11 -0400 Noam Postavsky <npostavs@gmail.com> wrote:
>
>> Stephen Berman <stephen.berman@gmx.net> writes:
>>
>>> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>>
>>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>>>>
>>>>> 0. emacs -Q
>>>>> 1. C-x d / ~ TAB
>>>>> This pops up a *Completions* buffer showing directory names of all
>>>>> members of (system-users), e.g. steve/
>>>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>>>> TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>>>> completes to steve/
>>>>>
>>>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>>>> TAB' here completes to ~/Downloads/
>>>>
>>>> Doesn't happen here, FWIW. Strange.
>>>
>>> Strange indeed, assuming you tested on GNU/Linux or another POSIX
>>> system, since IIUC on MS-Windows system-users returns only
>>> user-real-login-name (at least it does here on Emacs 25.3 under Windows
>>> 8). I also tested on another GNU/Linux system I have with Emacs 24.3
>>> and see exactly the same behavior I described above.
>>
>> I see it on both Windows and GNU/Linux.
>
> Like Eli, I'm surprised you see it on Windows.
Oh, I skipped the TAB in step 1. With that, all of the leading text
before the ~ is removed, so there is no problem (and it indeed
completes immediately to my current user on Windows).
>
>> I notice that the after typing
>> the first letter of the user name, the leading "/" is no longer in
>> shadow face,
>
> Yes, I didn't notice that when I tested before but I do now.
Ah, so when you hit TAB, the leading "/" is not removed?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 13:58 ` Noam Postavsky
@ 2018-07-20 14:28 ` Stephen Berman
2018-07-20 14:56 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2018-07-20 14:28 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 32215
On Fri, 20 Jul 2018 09:58:10 -0400 Noam Postavsky <npostavs@gmail.com> wrote:
> On 20 July 2018 at 04:31, Stephen Berman <stephen.berman@gmx.net> wrote:
>> On Thu, 19 Jul 2018 21:02:11 -0400 Noam Postavsky <npostavs@gmail.com> wrote:
>>
>>> Stephen Berman <stephen.berman@gmx.net> writes:
>>>
>>>> On Thu, 19 Jul 2018 21:19:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>>>>
>>>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>>>> Date: Thu, 19 Jul 2018 19:55:18 +0200
>>>>>>
>>>>>> 0. emacs -Q
>>>>>> 1. C-x d / ~ TAB
>>>>>> This pops up a *Completions* buffer showing directory names of all
>>>>>> members of (system-users), e.g. steve/
>>>>>> 2. Continuing from step 1, when I type any of 's TAB', 'st TAB', 'ste
>>>>>> TAB' or 'stev TAB', Emacs responds with [No match], but 'steve TAB'
>>>>>> completes to steve/
>>>>>>
>>>>>> The failure only happens with '/~<partial-name>', typing e.g. '~/Downl
>>>>>> TAB' here completes to ~/Downloads/
>>>>>
>>>>> Doesn't happen here, FWIW. Strange.
>>>>
>>>> Strange indeed, assuming you tested on GNU/Linux or another POSIX
>>>> system, since IIUC on MS-Windows system-users returns only
>>>> user-real-login-name (at least it does here on Emacs 25.3 under Windows
>>>> 8). I also tested on another GNU/Linux system I have with Emacs 24.3
>>>> and see exactly the same behavior I described above.
>>>
>>> I see it on both Windows and GNU/Linux.
>>
>> Like Eli, I'm surprised you see it on Windows.
>
> Oh, I skipped the TAB in step 1. With that, all of the leading text
> before the ~ is removed, so there is no problem (and it indeed
> completes immediately to my current user on Windows).
>
>>
>>> I notice that the after typing
>>> the first letter of the user name, the leading "/" is no longer in
>>> shadow face,
>>
>> Yes, I didn't notice that when I tested before but I do now.
>
> Ah, so when you hit TAB, the leading "/" is not removed?
Nothing is removed. To be explicit, when I start with -Q and type 'C-x
d', the minibuffer displays this:
Dired (directory): ~/
with point after '/'. When I now type '/', the face of '~/' changes to
shadow, and when I then type '~', the face of the second '/' also
changes to shadow. When I now type TAB, the minibuffer looks like this:
Dired (directory): ~//~
with '~//' in shadow face, and a *Completions* buffer pops up and shows
the directory names of all members of (system-users). When I now type
's TAB', the face of the second '/' changes from shadow to default
(black), '[No match]' appears after the cursor and the *Completions*
buffer disappears. I.e., the minibuffer looks like this on hitting TAB:
Dired (directory): ~//~s█[No match]
with '~/' in shadow face and '/~s' in default face, and after a couple
of seconds, '[No match]' disappears, leaving the rest.
Steve Berman
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 14:28 ` Stephen Berman
@ 2018-07-20 14:56 ` Eli Zaretskii
2018-07-20 15:06 ` Eli Zaretskii
2018-07-20 15:08 ` Stephen Berman
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2018-07-20 14:56 UTC (permalink / raw)
To: Stephen Berman; +Cc: 32215, npostavs
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 32215@debbugs.gnu.org
> Date: Fri, 20 Jul 2018 16:28:15 +0200
>
> Nothing is removed. To be explicit, when I start with -Q and type 'C-x
> d', the minibuffer displays this:
>
> Dired (directory): ~/
>
> with point after '/'. When I now type '/', the face of '~/' changes to
> shadow, and when I then type '~', the face of the second '/' also
> changes to shadow. When I now type TAB, the minibuffer looks like this:
>
> Dired (directory): ~//~
>
> with '~//' in shadow face, and a *Completions* buffer pops up and shows
> the directory names of all members of (system-users). When I now type
> 's TAB', the face of the second '/' changes from shadow to default
> (black), '[No match]' appears after the cursor and the *Completions*
> buffer disappears. I.e., the minibuffer looks like this on hitting TAB:
>
> Dired (directory): ~//~s█[No match]
>
> with '~/' in shadow face and '/~s' in default face, and after a couple
> of seconds, '[No match]' disappears, leaving the rest.
Ah, I think I understand why I couldn't reproduce the problem: it
seems to only happen if default-directory is "~/" before starting the
recipe. If it is something else, the problem doesn't happen. Can you
confirm?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 14:56 ` Eli Zaretskii
@ 2018-07-20 15:06 ` Eli Zaretskii
2018-07-20 15:08 ` Stephen Berman
1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2018-07-20 15:06 UTC (permalink / raw)
To: stephen.berman; +Cc: 32215, npostavs
> Date: Fri, 20 Jul 2018 17:56:12 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32215@debbugs.gnu.org, npostavs@gmail.com
>
> Ah, I think I understand why I couldn't reproduce the problem: it
> seems to only happen if default-directory is "~/" before starting the
> recipe. If it is something else, the problem doesn't happen. Can you
> confirm?
And I see this in Emacs 26, 25, and 24, so it isn't a new problem.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 14:56 ` Eli Zaretskii
2018-07-20 15:06 ` Eli Zaretskii
@ 2018-07-20 15:08 ` Stephen Berman
2018-07-20 17:22 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2018-07-20 15:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 32215, npostavs
On Fri, 20 Jul 2018 17:56:12 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 32215@debbugs.gnu.org
>> Date: Fri, 20 Jul 2018 16:28:15 +0200
>>
>> Nothing is removed. To be explicit, when I start with -Q and type 'C-x
>> d', the minibuffer displays this:
>>
>> Dired (directory): ~/
>>
>> with point after '/'. When I now type '/', the face of '~/' changes to
>> shadow, and when I then type '~', the face of the second '/' also
>> changes to shadow. When I now type TAB, the minibuffer looks like this:
>>
>> Dired (directory): ~//~
>>
>> with '~//' in shadow face, and a *Completions* buffer pops up and shows
>> the directory names of all members of (system-users). When I now type
>> 's TAB', the face of the second '/' changes from shadow to default
>> (black), '[No match]' appears after the cursor and the *Completions*
>> buffer disappears. I.e., the minibuffer looks like this on hitting TAB:
>>
>> Dired (directory): ~//~s█[No match]
>>
>> with '~/' in shadow face and '/~s' in default face, and after a couple
>> of seconds, '[No match]' disappears, leaving the rest.
>
> Ah, I think I understand why I couldn't reproduce the problem: it
> seems to only happen if default-directory is "~/" before starting the
> recipe. If it is something else, the problem doesn't happen. Can you
> confirm?
I'm afraid not:
0. emacs -Q
1. M-x cd RET /tmp/ RET
2. C-x d /~s TAB
results in this minibuffer display:
Dired (directory): /tmp//~s█[No match]
with '/tmp/' in shadow face and '/~s' in default face. Same thing with
any other value of default-directory I've tried.
Steve Berman
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 15:08 ` Stephen Berman
@ 2018-07-20 17:22 ` Eli Zaretskii
2018-07-20 17:30 ` Stephen Berman
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2018-07-20 17:22 UTC (permalink / raw)
To: Stephen Berman; +Cc: 32215, npostavs
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@gmail.com, 32215@debbugs.gnu.org
> Date: Fri, 20 Jul 2018 17:08:39 +0200
>
> > Ah, I think I understand why I couldn't reproduce the problem: it
> > seems to only happen if default-directory is "~/" before starting the
> > recipe. If it is something else, the problem doesn't happen. Can you
> > confirm?
>
> I'm afraid not:
>
> 0. emacs -Q
> 1. M-x cd RET /tmp/ RET
> 2. C-x d /~s TAB
>
> results in this minibuffer display:
>
> Dired (directory): /tmp//~s█[No match]
Try a subdirectory of your home directory.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 17:22 ` Eli Zaretskii
@ 2018-07-20 17:30 ` Stephen Berman
2018-07-20 19:03 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Stephen Berman @ 2018-07-20 17:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 32215, npostavs
On Fri, 20 Jul 2018 20:22:27 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@gmail.com, 32215@debbugs.gnu.org
>> Date: Fri, 20 Jul 2018 17:08:39 +0200
>>
>> > Ah, I think I understand why I couldn't reproduce the problem: it
>> > seems to only happen if default-directory is "~/" before starting the
>> > recipe. If it is something else, the problem doesn't happen. Can you
>> > confirm?
>>
>> I'm afraid not:
>>
>> 0. emacs -Q
>> 1. M-x cd RET /tmp/ RET
>> 2. C-x d /~s TAB
>>
>> results in this minibuffer display:
>>
>> Dired (directory): /tmp//~s█[No match]
>
> Try a subdirectory of your home directory.
Perhaps I'm misunderstanding what you're suggesting, but with the
following I still get the same behavior:
0. emacs -Q
1. M-x cd RET ~/Downloads/ RET
2. C-x d /~s TAB
results in this minibuffer display:
Dired (directory): ~/Downloads//~s█[No match]
Steve Berman
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 17:30 ` Stephen Berman
@ 2018-07-20 19:03 ` Eli Zaretskii
2018-07-20 21:46 ` Stephen Berman
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2018-07-20 19:03 UTC (permalink / raw)
To: Stephen Berman; +Cc: 32215, npostavs
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@gmail.com, 32215@debbugs.gnu.org
> Date: Fri, 20 Jul 2018 19:30:52 +0200
>
> > Try a subdirectory of your home directory.
>
> Perhaps I'm misunderstanding what you're suggesting, but with the
> following I still get the same behavior:
>
> 0. emacs -Q
> 1. M-x cd RET ~/Downloads/ RET
> 2. C-x d /~s TAB
>
> results in this minibuffer display:
>
> Dired (directory): ~/Downloads//~s█[No match]
The original recipe was different:
0. emacs -Q
1. M-x cd RET ~/Downloads/ RET
2. C-x d / ~ TAB s TAB
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name>
2018-07-20 19:03 ` Eli Zaretskii
@ 2018-07-20 21:46 ` Stephen Berman
0 siblings, 0 replies; 16+ messages in thread
From: Stephen Berman @ 2018-07-20 21:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 32215, npostavs
On Fri, 20 Jul 2018 22:03:21 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@gmail.com, 32215@debbugs.gnu.org
>> Date: Fri, 20 Jul 2018 19:30:52 +0200
>>
>> > Try a subdirectory of your home directory.
>>
>> Perhaps I'm misunderstanding what you're suggesting, but with the
>> following I still get the same behavior:
>>
>> 0. emacs -Q
>> 1. M-x cd RET ~/Downloads/ RET
>> 2. C-x d /~s TAB
>>
>> results in this minibuffer display:
>>
>> Dired (directory): ~/Downloads//~s█[No match]
>
> The original recipe was different:
>
> 0. emacs -Q
> 1. M-x cd RET ~/Downloads/ RET
> 2. C-x d / ~ TAB s TAB
I did not give, nor have I seen, this recipe in this bug thread. But I
see now that the recipe of my OP (which lacked the above step 1) could
be understood as consistent with the above. There is indeed a
difference between
Dired (directory): ~/~ TAB
or
Dired (directory): ~/Downloads/~ TAB
on the one hand, and
Dired (directory): ~//~ TAB
or
Dired (directory): ~/Downloads//~ TAB
on the other. But the bug I meant to report is about this:
Dired (directory): ~//~s TAB
or
Dired (directory): ~/Downloads//~s TAB
which both get '[No match]', whereas
Dired (directory): ~//~steve TAB
or
Dired (directory): ~/Downloads//~steve TAB
both complete, to '~//steve/' and '~/Downloads//steve/', respectively.
One thing I just noticed: in the latter two case, when I type '/', that
changes the face on '~/' or '~/Downloads/' to shadow, and when I then
type '~', the changes the face of the just typed '/' to shadow, but when
I continue and type 's', then the face of the last '/' returns to
default (but the face of the preceding characters remains shadow), and
stays like that when I add 't', 'e', 'v'; but as soon as I add 'e'
(which make TAB complete successfully), the face of the last '/' changes
back to shadow (and '~steve' keeps default face).
Steve Berman
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-07-20 21:46 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-19 17:55 bug#32215: 27.0.50; Minibuffer completion fails with /~<partial-name> Stephen Berman
2018-07-19 18:19 ` Eli Zaretskii
2018-07-19 20:11 ` Stephen Berman
2018-07-20 1:02 ` Noam Postavsky
2018-07-20 6:40 ` Eli Zaretskii
2018-07-20 8:31 ` Stephen Berman
2018-07-20 13:58 ` Noam Postavsky
2018-07-20 14:28 ` Stephen Berman
2018-07-20 14:56 ` Eli Zaretskii
2018-07-20 15:06 ` Eli Zaretskii
2018-07-20 15:08 ` Stephen Berman
2018-07-20 17:22 ` Eli Zaretskii
2018-07-20 17:30 ` Stephen Berman
2018-07-20 19:03 ` Eli Zaretskii
2018-07-20 21:46 ` Stephen Berman
2018-07-20 6:39 ` Eli Zaretskii
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).