* 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-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
* 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
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).