* bug#12916: 24.2; Completion for "C-x b" does not include current buffer
@ 2012-11-17 15:44 Richard Copley
2012-11-19 14:22 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Richard Copley @ 2012-11-17 15:44 UTC (permalink / raw)
To: 12916
In older Emacs versions (*), to switch buffer, I could type "C-x b",
followed by a unique prefix of the desired buffer's name, then "TAB
RET". This routine no longer works. Specifically, the completion fails
when the desired buffer is already the current buffer. So before I can
switch, I first have to work out which window is selected and whether
its buffer is the one I want.
In my opinion this was a bad decision, and I think we should go back
to using "B" as the interactive spec for switch-to-buffer. Others
might disagree, so would it be possible to add a custom variable to
control whether the current buffer is included in the list of completions?
(*) (I think the behaviour changed on the trunk in
revisions 86915 and 86916, in April 2008.)
In GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601)
of 2012-08-29 on MARVIN
Major mode: Lisp Interaction
Recent input:
C-x b * s c r a t c h <tab> <tab> <tab> <tab> C-g
M-x r e p o r t - e m a c s - b u g <return>
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12916: 24.2; Completion for "C-x b" does not include current buffer
2012-11-17 15:44 bug#12916: 24.2; Completion for "C-x b" does not include current buffer Richard Copley
@ 2012-11-19 14:22 ` Stefan Monnier
[not found] ` <CAPM58ogCn5hi6qskV9XTqJoqm23fanS661ajPkRdfES6_Hg=-A@mail.gmail.com>
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Stefan Monnier @ 2012-11-19 14:22 UTC (permalink / raw)
To: Richard Copley; +Cc: 12916
> In older Emacs versions (*), to switch buffer, I could type "C-x b",
> followed by a unique prefix of the desired buffer's name, then "TAB
> RET". This routine no longer works. Specifically, the completion fails
> when the desired buffer is already the current buffer. So before I can
> switch, I first have to work out which window is selected and whether
> its buffer is the one I want.
Hmm... I'd expect the user to know in which buffer she is when she hits
C-x b. Can you give us a few more hints about your use-case to try and
help me understand why you don't know in which buffer you are when you
hit C-x b?
> In my opinion this was a bad decision, and I think we should go back
> to using "B" as the interactive spec for switch-to-buffer. Others
> might disagree, so would it be possible to add a custom variable to
> control whether the current buffer is included in the list of completions?
I'm not sure this deserves such a customization variable. But in any
case, in the mean time, you can get back the previous behavior with the
following hack:
(defadvice internal-complete-buffer-except (around rc-all-buffers activate)
(setq ad-return-value #'internal-complete-buffer))
Maybe a cleaner workaround might be:
(put 'switch-to-buffer 'interactive-form
'(interactive "BSwitch to buffer: "))
-- Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAPM58ogCn5hi6qskV9XTqJoqm23fanS661ajPkRdfES6_Hg=-A@mail.gmail.com>]
* bug#12916: Fwd: bug#12916: 24.2; Completion for "C-x b" does not include current buffer
[not found] ` <CAPM58ogCn5hi6qskV9XTqJoqm23fanS661ajPkRdfES6_Hg=-A@mail.gmail.com>
@ 2012-11-19 20:10 ` Richard Copley
0 siblings, 0 replies; 6+ messages in thread
From: Richard Copley @ 2012-11-19 20:10 UTC (permalink / raw)
To: 12916
Stefan, sorry I replied to you personally without replying to the tracker.
On 19 November 2012 14:22, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> In older Emacs versions (*), to switch buffer, I could type "C-x b",
>> followed by a unique prefix of the desired buffer's name, then "TAB
>> RET". This routine no longer works. Specifically, the completion fails
>> when the desired buffer is already the current buffer. So before I can
>> switch, I first have to work out which window is selected and whether
>> its buffer is the one I want.
>
> Hmm... I'd expect the user to know in which buffer she is when she hits
> C-x b. Can you give us a few more hints about your use-case to try and
> help me understand why you don't know in which buffer you are when you
> hit C-x b?
The short answer is, when I've just killed a buffer (and I'm reading
Wikipedia, talking to a co-worker and watching TV).
The longer answer is: when there are two windows visible, I've just
killed a buffer, the two windows are now showing the same buffer (and
by the way, who ordered that?!), I want both windows to show the same
buffer, and there's a family of ducklings walking past the window and
they're really cute.
My mental map of recently-used buffers is not per-window, so to me it
is now unpredictable what other buffer will be shown after I kill a
buffer. Now that I come to think about it, perhaps this is really my
problem.
>> In my opinion this was a bad decision, and I think we should go back
>> to using "B" as the interactive spec for switch-to-buffer. Others
>> might disagree, so would it be possible to add a custom variable to
>> control whether the current buffer is included in the list of completions?
>
> I'm not sure this deserves such a customization variable. But in any
> case, in the mean time, you can get back the previous behavior with the
> following hack:
>
> (defadvice internal-complete-buffer-except (around rc-all-buffers activate)
> (setq ad-return-value #'internal-complete-buffer))
>
> Maybe a cleaner workaround might be:
>
> (put 'switch-to-buffer 'interactive-form
> '(interactive "BSwitch to buffer: "))
Thank you! That seems to behave just as I want.
> -- Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12916: 24.2; Completion for "C-x b" does not include current buffer
2012-11-19 14:22 ` Stefan Monnier
[not found] ` <CAPM58ogCn5hi6qskV9XTqJoqm23fanS661ajPkRdfES6_Hg=-A@mail.gmail.com>
@ 2012-11-19 21:32 ` Richard Stallman
2012-11-21 8:14 ` Richard Stallman
2 siblings, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2012-11-19 21:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: rcopley, 12916
Hmm... I'd expect the user to know in which buffer she is when she hits
C-x b.
I often switch to a buffer without noticing I am already in it.
I have not made a note of the specific circumstances. If you really
want to know, I will start noting that down.
I think one case is after some other command that switched buffers,
such as C-x k, or C-c C-c in a mail buffer. In that situation I start
typing C-x b R TAB RET before my mind recognizes which buffer it left
me in.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12916: 24.2; Completion for "C-x b" does not include current buffer
2012-11-19 14:22 ` Stefan Monnier
[not found] ` <CAPM58ogCn5hi6qskV9XTqJoqm23fanS661ajPkRdfES6_Hg=-A@mail.gmail.com>
2012-11-19 21:32 ` Richard Stallman
@ 2012-11-21 8:14 ` Richard Stallman
2 siblings, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2012-11-21 8:14 UTC (permalink / raw)
To: Stefan Monnier; +Cc: rcopley, 12916
I'm not sure this deserves such a customization variable. But in any
case, in the mean time, you can get back the previous behavior with the
following hack:
(defadvice internal-complete-buffer-except (around rc-all-buffers activate)
(setq ad-return-value #'internal-complete-buffer))
Thanks. Must better!
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#9598: 24.0.50; completion goes too far
@ 2011-09-25 17:34 Richard Stallman
2011-09-25 18:47 ` Drew Adams
0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2011-09-25 17:34 UTC (permalink / raw)
To: 9598
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org. Please check that
the From: line contains a valid email address. After a delay of up
to one day, you should receive an acknowledgement at that address.
Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.
Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug. If you can, give a recipe
starting from `emacs -Q':
I typed C-b R TAB, not noticing I was already in RMAIL,
and it completed to ` *message-viewer RMAIL*'.
This is totally surprising and unhelpful.
I created a buffer called faUlt and found that U TAB completes
to faUlt. This sort of thing will only confuse people
When in the *mail* buffer, I found that C-x b *ma TAB offered me
*Shell Command Output* les-luthiers.xmail
maintainers.bypkg rmail.el
summary
and did not mention *mail* at all. That is confusing and unhelpful
too, for it to offer buffers that did not have the *'s.
I surmise it is treating the input as a wildcard pattern.
I think that is a misguided feature. The *'s should be
treated literally. And the current buffer should not be
excluded from a completion list, when a completion list is displayed.
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/home/rms/emacs-bzr/trunk/etc/DEBUG.
In GNU Emacs 24.0.50.4 (mips64el-unknown-linux-gnu, GTK+ Version 2.12.12)
of 2011-09-22 on theobromine2
configured using `configure 'CFLAGS=-g -O1''
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: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
shell-dirtrack-mode: t
diff-auto-refine-mode: t
gpm-mouse-mode: t
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
Recent input:
C-b C-b - C-f C-f - C-e , t DEL DEL . h t m l . C-x
C-s C-x b o t g TAB DEL DEL u t g TAB RET g ~ x y e
s RET C-x b g n u p TAB RET C-s s h n e C-s C-s C-s
y C-s C-a C-s c h n e C-s ESC < C-s C-s C-n C-n C-n
C-n C-n C-n C-a C-p C-@ C-e ESC w C-x 4 m C-y C-n C
o n v e r g e n c e SPC i n s t e a SPC DEL d SPC o
f SPC C A s C-n C-n C-n W h a t SPC d o SPC y o u SPC
t h i n k SPC o f SPC C o n v e r g n c e DEL DEL DEL
e n c e ? C-c C-c C-x b o u t g TAB RET C-g C-x b C-g
g ~ C-x b R TAB RET g C-l C-x 1 n n n d d x n n p n
n p n d u n n n n n n n d d d x d d x n x n d x d x
n d x o u e f TAB RET d x o e u r o p e . x TAB RET
d x ESC x l y n x RET C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v
C-v C-x b R TAB RET C-x b R TAB C-g C-h l ESC x r e
p o r t SPC e m a c s SPC b u g RET
Recent messages:
Expunging deleted messages...done
Expunging deleted messages...done
Expunging deleted messages...done
Expunging deleted messages...done
Expunging deleted messages...done
Added to /home/rms/xmail/uefi.xmail
Expunging deleted messages...done
Added to /home/rms/xmail/europe.xmail
Expunging deleted messages...done
Wrote /home/rms/foo.html
Quit
Load-path shadows:
None found.
Features:
(shadow emacsbug compare-w log-view parse-time mule-util quail ispell
speedbar sb-image ezimage dframe assoc ind-util edmacro kmacro
dired-aux rmailout sgml-mode ansi-color shell pcomplete grep qp
dabbrev newcomment warnings cl byte-opt compile comint bytecomp
byte-compile cconv macroexp find-func help-mode view help-fns cc-mode
cc-fonts cc-guess cc-bytecomp cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs whitespace diff-mode log-edit easy-mmode
ring pcvs-util vc-sccs vc-svn vc-cvs vc-rcs vc-dir ewoc vc ediff-merg
ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init
ediff vc-dispatcher add-log multi-isearch vc-bzr mailalias rmailmm
message sendmail format-spec rfc822 mml easymenu mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231
rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired
regexp-opt t-mouse time-date battery paren cus-start cus-load tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd 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 loaddefs 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 dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#9598: 24.0.50; completion goes too far
2011-09-25 17:34 bug#9598: 24.0.50; completion goes too far Richard Stallman
@ 2011-09-25 18:47 ` Drew Adams
2011-09-26 1:00 ` Richard Stallman
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2011-09-25 18:47 UTC (permalink / raw)
To: rms, 9598
> This is totally surprising and unhelpful.
> ...and did not mention *mail* at all. That is confusing
> and unhelpful too...
>
> I surmise it is treating the input as a wildcard pattern.
> I think that is a misguided feature. The *'s should be
> treated literally. And the current buffer should not be
> excluded from a completion list, when a completion list is displayed.
1+
Yes, the default matching uses wildcard patterns. In fact, the default matching
uses several different matching schemes, in sequence, until one of them results
in matches.
See my reply to your post today about bug #9591.
And we have been over this before[*]. People, including you, have pointed out
the user-oriented problems with this UI design, but Stefan really wants it this
way. So you and other users will continue to be surprised.
[*] I cannot find appropriate emacs-devel threads to cite here, because it is
impossible to search at http://lists.gnu.org/archive/html/emacs-devel/ etc. for
`+from:rms@gnu.org', because of too many hits. That limitation sounds
reasonable at first, until you realize that you cannot even combine such a
filter by ANDing it with a small set of hits from another pattern - e.g.
`:subject:complet' (regardless of AND order). Similarly, I couldn't find a way
to search at http://debbugs.gnu.org/ for bug-list postings (not submittals) from
rms@gnu.org with subject-line matches. Poor GNU.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#9598: 24.0.50; completion goes too far
2011-09-25 18:47 ` Drew Adams
@ 2011-09-26 1:00 ` Richard Stallman
2011-09-26 6:09 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2011-09-26 1:00 UTC (permalink / raw)
To: Drew Adams; +Cc: 9598
And we have been over this before[*]. People, including you, have pointed out
the user-oriented problems with this UI design, but Stefan really wants it this
way. So you and other users will continue to be surprised.
I think we should poll the users about this question. That way we can
resolve the disagreement based on something more objective.
IOW, let users choose at completion time which completion style(s) to use, on
demand. Each time they change methods they can complete anew and find out
whether there are matches using that method.
This might be too complicated an interface to be good to use.
But you could try implementing it and we could judge based
on experience.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#9598: 24.0.50; completion goes too far
2011-09-26 1:00 ` Richard Stallman
@ 2011-09-26 6:09 ` Eli Zaretskii
2011-09-26 10:42 ` Richard Stallman
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2011-09-26 6:09 UTC (permalink / raw)
To: rms; +Cc: 9598
> Date: Sun, 25 Sep 2011 21:00:28 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: 9598@debbugs.gnu.org
> Reply-To: rms@gnu.org
>
> And we have been over this before[*]. People, including you, have pointed out
> the user-oriented problems with this UI design, but Stefan really wants it this
> way. So you and other users will continue to be surprised.
>
> I think we should poll the users about this question. That way we can
> resolve the disagreement based on something more objective.
I find arguments about defaults a waste of time. So I think instead
of arguing and polling, we should just make sure there's a completion
style that closely resembles what you want, i.e. candidates are found
by matching their beginning with what the user typed. Currently, I
find no such style in what minibuffer.el offers, or maybe there's a
bug (see my other mail for bug #9591).
(Btw, why do we have 2 separate bug reports about the same issue?)
> IOW, let users choose at completion time which completion style(s) to use, on
> demand. Each time they change methods they can complete anew and find out
> whether there are matches using that method.
>
> This might be too complicated an interface to be good to use.
I agree.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#9598: 24.0.50; completion goes too far
2011-09-26 6:09 ` Eli Zaretskii
@ 2011-09-26 10:42 ` Richard Stallman
2011-09-26 11:34 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2011-09-26 10:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9598
I find arguments about defaults a waste of time.
Defaults are very important issues, because they affect how good Emacs
is for new users.
This kind of completion surprise is something that, by default,
should not happen.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#9598: 24.0.50; completion goes too far
2011-09-26 10:42 ` Richard Stallman
@ 2011-09-26 11:34 ` Eli Zaretskii
2011-09-26 21:12 ` Richard Stallman
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2011-09-26 11:34 UTC (permalink / raw)
To: rms; +Cc: 9598
> Date: Mon, 26 Sep 2011 06:42:44 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: drew.adams@ORACLE.COM, 9598@debbugs.gnu.org
> Reply-to: rms@gnu.org
>
> I find arguments about defaults a waste of time.
>
> Defaults are very important issues, because they affect how good Emacs
> is for new users.
I didn't say they were not important, just that arguing about them is
a waste of time. Nothing good ever comes out of these arguments.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#9598: 24.0.50; completion goes too far
2011-09-26 11:34 ` Eli Zaretskii
@ 2011-09-26 21:12 ` Richard Stallman
2022-02-06 0:05 ` bug#12916: 24.2; Completion for "C-x b" does not include current buffer Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2011-09-26 21:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9598
> Defaults are very important issues, because they affect how good Emacs
> is for new users.
I didn't say they were not important, just that arguing about them is
a waste of time. Nothing good ever comes out of these arguments.
Rather than just argue about good defaults, I plan to poll the users.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use free telephony http://directory.fsf.org/category/tel/
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#12916: 24.2; Completion for "C-x b" does not include current buffer
2011-09-26 21:12 ` Richard Stallman
@ 2022-02-06 0:05 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-06 0:05 UTC (permalink / raw)
To: Richard Stallman; +Cc: 12916, 9598
Richard Stallman <rms@gnu.org> writes:
> > Defaults are very important issues, because they affect how good Emacs
> > is for new users.
>
> I didn't say they were not important, just that arguing about them is
> a waste of time. Nothing good ever comes out of these arguments.
>
> Rather than just argue about good defaults, I plan to poll the users.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I think the conclusion here was that the buffer completion defaults are
fine, so I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-02-06 0:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-17 15:44 bug#12916: 24.2; Completion for "C-x b" does not include current buffer Richard Copley
2012-11-19 14:22 ` Stefan Monnier
[not found] ` <CAPM58ogCn5hi6qskV9XTqJoqm23fanS661ajPkRdfES6_Hg=-A@mail.gmail.com>
2012-11-19 20:10 ` bug#12916: Fwd: " Richard Copley
2012-11-19 21:32 ` Richard Stallman
2012-11-21 8:14 ` Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2011-09-25 17:34 bug#9598: 24.0.50; completion goes too far Richard Stallman
2011-09-25 18:47 ` Drew Adams
2011-09-26 1:00 ` Richard Stallman
2011-09-26 6:09 ` Eli Zaretskii
2011-09-26 10:42 ` Richard Stallman
2011-09-26 11:34 ` Eli Zaretskii
2011-09-26 21:12 ` Richard Stallman
2022-02-06 0:05 ` bug#12916: 24.2; Completion for "C-x b" does not include current buffer Lars Ingebrigtsen
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).