GNU bug report logs - #26360
26.0.50; ido-mode doesn't enable IDO for C-x 4 d

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26360 in the body.
You can then email your comments to 26360 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Tue, 04 Apr 2017 14:20:49 +0200

M-x ido-mode

Then try
C-x C-f
C-x d
C-x 4 f
C-x 4 d

In the first three cases, IDO will be used, but not in the fourth case.
That's a weird inconsistency.


In GNU Emacs 26.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.10.8)
 of 2017-04-04 built on unknown
Repository revision: f4b50dad8d5eade04f495c693c0bca46060b25cb
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Ubuntu 14.04 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --without-pop --with-mailutils --enable-checking
 --enable-check-lisp-object-type --with-modules 'CFLAGS=-O0 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message puny seq byte-opt subr-x gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 95798 11364)
 (symbols 48 20179 1)
 (miscs 40 39 156)
 (strings 32 17662 4751)
 (string-bytes 1 576290)
 (vectors 16 14098)
 (vector-slots 8 483725 5397)
 (floats 8 48 68)
 (intervals 56 217 0)
 (buffers 976 12)
 (heap 1024 23372 1029))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Diese E-Mail ist vertraulich.  Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge.  Vielen Dank.

This e-mail is confidential.  If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments.  Thanks.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 26360 <at> debbugs.gnu.org
Subject: Re: bug#26360: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Tue, 4 Apr 2017 08:28:51 -0400

On Tue, Apr 4, 2017 at 8:20 AM, Philipp Stephani <p.stephani2 <at> gmail.com> wrote:
>
> M-x ido-mode
>
> Then try
> C-x C-f
> C-x d
> C-x 4 f
> C-x 4 d
>
> In the first three cases, IDO will be used, but not in the fourth case.
> That's a weird inconsistency.

Doing M-x ido-everywhere makes it consistent. Not sure if this is on
purpose or not...

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: 26360 <at> debbugs.gnu.org
Subject: Re: bug#26360: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Thu, 20 Apr 2017 13:45:09 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Di., 4. Apr. 2017 um
14:22 Uhr:

>
> M-x ido-mode
>
> Then try
> C-x C-f
> C-x d
> C-x 4 f
> C-x 4 d
>
> In the first three cases, IDO will be used, but not in the fourth case.
> That's a weird inconsistency.
>
>
Here's a patch (which includes a couple of other commands).

[Message part 2 (text/html, inline)]

[0001-Add-missing-remappings-for-Ido-mode.txt (text/plain, attachment)]

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

From: npostavs <at> users.sourceforge.net
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 26360 <at> debbugs.gnu.org
Subject: Re: bug#26360: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Thu, 20 Apr 2017 23:29:53 -0400

tags 26360 patch
quit

Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> Here's a patch (which includes a couple of other commands).

Patch looks good, except the test seems redundant to me.  I don't think
it's useful to test that a command is defined, or testing that specific
keybindings have been set (i.e., no need to test again that `defun' or
`define-key' are working).  Also, it would fail if run from a
non-default emacs configuration that has changed the keybindings.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: 26360 <at> debbugs.gnu.org
Subject: Re: bug#26360: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Sat, 22 Apr 2017 19:24:05 +0000

[Message part 1 (text/plain, inline)]

<npostavs <at> users.sourceforge.net> schrieb am Fr., 21. Apr. 2017 um 05:28 Uhr:

> tags 26360 patch
> quit
>
> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
> >
> > Here's a patch (which includes a couple of other commands).
>
> Patch looks good, except the test seems redundant to me.  I don't think
> it's useful to test that a command is defined, or testing that specific
> keybindings have been set (i.e., no need to test again that `defun' or
> `define-key' are working).


I've used a bit of TDD for this patch, thus the verbose test. Unfortunately
the actual functionality is very hard to test :-(


>   Also, it would fail if run from a
> non-default emacs configuration that has changed the keybindings.
>

True, but the main use of the tests is for continuous integration, where
the environment is controlled.

[Message part 2 (text/html, inline)]

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

From: npostavs <at> users.sourceforge.net
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 26360 <at> debbugs.gnu.org
Subject: Re: bug#26360: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Sat, 22 Apr 2017 17:40:18 -0400

Philipp Stephani <p.stephani2 <at> gmail.com> writes:

> <npostavs <at> users.sourceforge.net> schrieb am Fr., 21. Apr. 2017 um 05:28 Uhr:
>>
>> Patch looks good, except the test seems redundant to me.  I don't think
>> it's useful to test that a command is defined, or testing that specific
>> keybindings have been set (i.e., no need to test again that `defun' or
>> `define-key' are working).
>
>
> I've used a bit of TDD for this patch, thus the verbose test.

I suppose my real objection is that 'make check' is already taking long
enough that it makes me reluctant to use it, so I don't really want to
see more tests of such marginal utility.  But any single test isn't
adding a significant amount of time, so I'm not going to insist.

In conclusion, feel free to push this; as far as I'm concerned, the
decision about the test is up to you.

Message #27 received at 26360-done <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: 26360-done <at> debbugs.gnu.org
Subject: Re: bug#26360: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Sun, 23 Apr 2017 16:43:59 +0000

[Message part 1 (text/plain, inline)]

<npostavs <at> users.sourceforge.net> schrieb am Sa., 22. Apr. 2017 um 23:38 Uhr:

> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> > <npostavs <at> users.sourceforge.net> schrieb am Fr., 21. Apr. 2017 um 05:28
> Uhr:
> >>
> >> Patch looks good, except the test seems redundant to me.  I don't think
> >> it's useful to test that a command is defined, or testing that specific
> >> keybindings have been set (i.e., no need to test again that `defun' or
> >> `define-key' are working).
> >
> >
> > I've used a bit of TDD for this patch, thus the verbose test.
>
> I suppose my real objection is that 'make check' is already taking long
> enough that it makes me reluctant to use it, so I don't really want to
> see more tests of such marginal utility.  But any single test isn't
> adding a significant amount of time, so I'm not going to insist.
>

Agreed that it takes very long, but I think good coverage is more important
(and the full suite should mostly be run on continuous integration, not
manually).


>
> In conclusion, feel free to push this; as far as I'm concerned, the
> decision about the test is up to you.
>

Thanks, pushed as a1f93c1dfa.

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philipp Stephani <phst <at> google.com>
Cc: 26360 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: [Emacs-diffs] master a1f93c1: Add missing remappings for Ido mode
Date: Sun, 23 Apr 2017 13:59:34 -0400

>     Add missing remappings for Ido mode
>     Among others, add a remapping for C-x 4 d, cf. Bug#26360.
    
This reduces the effect of ido-everywhere to the point where I wonder if
there's any point keeping it.

Alternatively, wouldn't it be preferable to not use this patch and
enable ido-everywhere by default instead?

What are the tradeoffs?


        Stefan

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Philipp Stephani <phst <at> google.com>
Cc: 26360 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#26360: [Emacs-diffs] master a1f93c1: Add missing remappings
 for Ido mode
Date: Mon, 01 May 2017 11:25:23 +0000

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> schrieb am So., 23. Apr. 2017 um
20:00 Uhr:

> >     Add missing remappings for Ido mode
> >     Among others, add a remapping for C-x 4 d, cf. Bug#26360.
>
> This reduces the effect of ido-everywhere to the point where I wonder if
> there's any point keeping it.
>

ido-mode and ido-everywhere are very different: ido-everywhere only changes
the completion function, ido-mode has semantic knowledge about the
commands. For example, C-x 4 f C-d visits the directory in another window;
that is impossible with ido-everywhere. On the other hand, ido-everywhere
works for other commands not explicitly covered as well.


>
> Alternatively, wouldn't it be preferable to not use this patch and
> enable ido-everywhere by default instead?
>

No, as described above, they are very different.


>
> What are the tradeoffs?
>

The installed patch solves a concrete problem now. Converging ido-mode and
ido-everywhere (and ido-ubiquitous, ibuffer, iswitchb, ...) is desirable,
but orders of magnitude more work, therefore infeasible.

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 26360 <at> debbugs.gnu.org
Subject: Re: bug#26360: 26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Date: Thu, 10 Feb 2022 09:01:34 +0100

Philipp Stephani <p.stephani2 <at> gmail.com> writes:

> M-x ido-mode
>
> Then try
> C-x C-f
> C-x d
> C-x 4 f
> C-x 4 d
>
> In the first three cases, IDO will be used, but not in the fourth case.
> That's a weird inconsistency.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Looks like this was fixed at the time (and I can't reproduce the problem
in Emacs 29), so I'm closing this bug report now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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