* bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list
@ 2012-02-05 3:53 Christoph Scholtes
2012-02-05 8:22 ` Leo
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Scholtes @ 2012-02-05 3:53 UTC (permalink / raw)
To: 10731
emacs -Q
M-x ido-mode
C-x b
C-j
I expected Emacs to show the *Messages* buffer upon issuing
C-j. However, it just exited the minibuffer and still showed the
*scratch* buffer. In this case, i.e. when the prompt is empty, I
expected the same behavior from C-j as from the Enter key,
i.e. selecting the buffer at the head of the list.
The help for (ido-select-text) says: Select the buffer or file named by
the prompt.
Wouldn't that be the head of the list in the minibuffer in this case?
In GNU Emacs 24.0.93.1 (i386-mingw-nt6.1.7601)
of 2012-02-04 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --with-gcc (4.6) --no-opt --enable-checking --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
-LD:/devel/emacs/libs/gnutls-3.0.9/lib'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
value of $XMODIFIERS: nil
locale-coding-system: cp1252
default enable-multibyte-characters: t
Major mode: Group
Minor modes in effect:
gnus-topic-mode: t
my-keys-minor-mode: t
erc-autojoin-mode: t
erc-track-mode: t
erc-match-mode: t
erc-pcomplete-mode: t
erc-stamp-mode: t
shell-dirtrack-mode: t
global-auto-complete-mode: t
gnus-undo-mode: t
desktop-save-mode: t
ido-everywhere: t
yas/global-mode: t
global-auto-revert-mode: t
tooltip-mode: t
mouse-wheel-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
size-indication-mode: t
column-number-mode: t
line-number-mode: t
Recent input:
C-x b C-j <down-mouse-1> <mouse-1> C-x b g n u <backspace>
<backspace> <backspace> C-g M-x g n u s <return> g
M-x C-g g <down-mouse-1> <mouse-1> M-x r e p o r t
- e m <tab> <return>
Recent messages:
Checking new news...done
No Gnus is good news
Quit
Checking new news...
nnimap read 0k from imap.gmail.com (initial sync of 1 groups; please wait)
nnimap read 32k from imap.gmail.com (initial sync of 1 groups; please wait)
Reading active file from archive via nnfolder...done
Checking new news...done
No Gnus is good news
call-interactively: End of buffer [8 times]
Load-path shadows:
c:/Users/Christoph/AppData/Roaming/.emacs.d/plugins/python hides d:/devel/emacs/emacs-bzr/trunk/lisp/progmodes/python
Features:
(shadow sort gnus-cite mail-extr emacsbug gnus-topic nndraft nnmh
nnfolder utf-7 gnutls network-stream starttls nnimap parse-time tls utf7
netrc gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig mailcap
nntp gnus-cache info make-mode cc-mode cc-fonts cc-guess cc-menus
cc-cmds add-log paredit vc-bzr my-zenburn-theme erc-join erc-track
erc-match erc-pcomplete erc-stamp erc-goodies erc erc-backend erc-compat
thingatpt tramp warnings tramp-compat auth-source eieio byte-opt
bytecomp byte-compile cconv macroexp password-cache shell pcomplete
tramp-loaddefs windmove auto-complete-config auto-complete popup
find-func ispell bookmark+ bookmark+-key dired-x dired bookmark+-1
gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start
gnus-spec gnus-int gnus-range message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems
nnheader gnus-util mail-utils mm-util mail-prsvr wid-edit bookmark+-bmu
help-mode view bookmark+-lit pp+ bookmark+-mac bookmark pp midnight
desktop ibuffer uniquify autopair google-c-style cc-styles cc-align
cc-engine cc-vars cc-defs grep-o-matic grep compile comint regexp-opt
ring browse-kill-ring+ browse-kill-ring ido yasnippet dropdown-list
derived easy-mmode edmacro kmacro easymenu assoc cl org-install server
advice help-fns advice-preload debbugs-autoloads package tabulated-list
autorevert time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list
2012-02-05 3:53 bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list Christoph Scholtes
@ 2012-02-05 8:22 ` Leo
2012-03-10 9:35 ` Chong Yidong
0 siblings, 1 reply; 6+ messages in thread
From: Leo @ 2012-02-05 8:22 UTC (permalink / raw)
To: 10731
On 2012-02-05 11:53 +0800, Christoph Scholtes wrote:
> emacs -Q
> M-x ido-mode
> C-x b
> C-j
>
> I expected Emacs to show the *Messages* buffer upon issuing
> C-j. However, it just exited the minibuffer and still showed the
> *scratch* buffer. In this case, i.e. when the prompt is empty, I
> expected the same behavior from C-j as from the Enter key,
> i.e. selecting the buffer at the head of the list.
I think this behaviour consistent i.e. not a bug.
If you C-x C-f and then hit C-j it does not assume you want to open the
file at the head instead it opens up dired i.e. the containing
directory.
Leo
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list
2012-02-05 8:22 ` Leo
@ 2012-03-10 9:35 ` Chong Yidong
2012-03-14 14:48 ` Daumantas Baltrusaitis
0 siblings, 1 reply; 6+ messages in thread
From: Chong Yidong @ 2012-03-10 9:35 UTC (permalink / raw)
To: Christoph Scholtes; +Cc: Leo, 10731
Leo <sdl.web@gmail.com> writes:
> I think this behaviour consistent i.e. not a bug.
>
> If you C-x C-f and then hit C-j it does not assume you want to open
> the file at the head instead it opens up dired i.e. the containing
> directory.
Christoph, any response? If not, I will close the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list
2012-03-10 9:35 ` Chong Yidong
@ 2012-03-14 14:48 ` Daumantas Baltrusaitis
2013-03-15 4:56 ` Leo Liu
0 siblings, 1 reply; 6+ messages in thread
From: Daumantas Baltrusaitis @ 2012-03-14 14:48 UTC (permalink / raw)
To: 10731
Leo <sdl.web <at> gmail.com> writes:
> If you C-x C-f and then hit C-j it does not assume you want to
> open the file at the head instead it opens up dired i.e. the
> containing directory.
While that is true, I believe that more relevant analogy is C-x b
C-f with ido-mode disabled. It opens the buffer at head of
list (default buffer).
I generally expect C-j to be interchangeable with <RET> in most
contexts since j is right under my index finger, thus easier to
press than <RET>. Especially in tasks used as often as
switching/killing buffers.
I guess that is the main point. Even with C-x C-f C-j example C-j
behaves like <RET> and that is the expected behavior.
Daumantas
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list
2012-03-14 14:48 ` Daumantas Baltrusaitis
@ 2013-03-15 4:56 ` Leo Liu
2013-07-11 16:10 ` Leo Liu
0 siblings, 1 reply; 6+ messages in thread
From: Leo Liu @ 2013-03-15 4:56 UTC (permalink / raw)
To: Daumantas Baltrusaitis; +Cc: 10731
On 2012-03-14 22:48 +0800, Daumantas Baltrusaitis wrote:
> While that is true, I believe that more relevant analogy is C-x b
> C-f with ido-mode disabled. It opens the buffer at head of
> list (default buffer).
>
> I generally expect C-j to be interchangeable with <RET> in most
> contexts since j is right under my index finger, thus easier to
> press than <RET>. Especially in tasks used as often as
> switching/killing buffers.
>
> I guess that is the main point. Even with C-x C-f C-j example C-j
> behaves like <RET> and that is the expected behavior.
>
> Daumantas
C-j is the key to let you get away from choosing a default item. It is
necessary (the only way) in a few cases. If you remap C-j to RET in ido
mode you will realise why you need it. The subtle but clear difference
between C-j and RET looks like a conscious decision from Kim.
I'll let the maintainer decide whether to close this bug.
Leo
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list
2013-03-15 4:56 ` Leo Liu
@ 2013-07-11 16:10 ` Leo Liu
0 siblings, 0 replies; 6+ messages in thread
From: Leo Liu @ 2013-07-11 16:10 UTC (permalink / raw)
To: 10731-done
Not a bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-07-11 16:10 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-05 3:53 bug#10731: 24.0.93; ido-mode: C-j does not select buffer at head of list Christoph Scholtes
2012-02-05 8:22 ` Leo
2012-03-10 9:35 ` Chong Yidong
2012-03-14 14:48 ` Daumantas Baltrusaitis
2013-03-15 4:56 ` Leo Liu
2013-07-11 16:10 ` Leo Liu
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).