GNU bug report logs - #32215
27.0.50; Minibuffer completion fails with /~<partial-name>

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Thu, 19 Jul 2018 17:56:01 UTC

Severity: minor

Found in version 27.0.50

Full log


Message #50 received at 32215 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32215 <at> debbugs.gnu.org, npostavs <at> gmail.com
Subject: Re: bug#32215: 27.0.50;
 Minibuffer completion fails with /~<partial-name>
Date: Fri, 20 Jul 2018 23:46:58 +0200
On Fri, 20 Jul 2018 22:03:21 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: npostavs <at> gmail.com,  32215 <at> 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




This bug report was last modified 7 years and 30 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.