GNU bug report logs -
#26360
26.0.50; ido-mode doesn't enable IDO for C-x 4 d
Previous Next
Reported by: Philipp Stephani <p.stephani2 <at> gmail.com>
Date: Tue, 4 Apr 2017 12:22:02 UTC
Severity: minor
Found in version 26.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
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.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Tue, 04 Apr 2017 12:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Philipp Stephani <p.stephani2 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 04 Apr 2017 12:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Tue, 04 Apr 2017 12:29:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 26360 <at> debbugs.gnu.org (full text, mbox):
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...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Thu, 20 Apr 2017 13:46:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 26360 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Fri, 21 Apr 2017 03:29:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 26360 <at> debbugs.gnu.org (full text, mbox):
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.
Added tag(s) patch.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 21 Apr 2017 03:29:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Sat, 22 Apr 2017 19:25:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 26360 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Sat, 22 Apr 2017 21:39:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 26360 <at> debbugs.gnu.org (full text, mbox):
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.
Reply sent
to
Philipp Stephani <p.stephani2 <at> gmail.com>
:
You have taken responsibility.
(Sun, 23 Apr 2017 16:45:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Philipp Stephani <p.stephani2 <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 23 Apr 2017 16:45:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 26360-done <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Sun, 23 Apr 2017 18:00:03 GMT)
Full text and
rfc822 format available.
Message #30 received at 26360 <at> debbugs.gnu.org (full text, mbox):
> 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
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 25 Apr 2017 19:02:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Mon, 01 May 2017 11:26:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 26360 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#26360
; Package
emacs
.
(Thu, 10 Feb 2022 08:02:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 26360 <at> debbugs.gnu.org (full text, mbox):
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
bug closed, send any further explanations to
26360 <at> debbugs.gnu.org and Philipp Stephani <p.stephani2 <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 10 Feb 2022 08:02:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 10 Mar 2022 12:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 124 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.