bug#12916: 24.2; Completion for "C-x b" does not include current buffer

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Richard Copley]

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>

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Stefan Monnier]

> 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

bug#12916: Fwd: bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Richard Copley]

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

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Richard Stallman]

    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

bug#12916: 24.2; Completion for "C-x b" does not include current buffer

[Richard Stallman]

    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