Re: Jumping to C source from *Help*

[Stefan Monnier]

>>> switch-to-buffer means "I specifically want the buffer in THIS window."
>>> It should get an error if it can't do that.  To display the buffer
>>> in another window would be failing to do the intended job.

>     Obviously we need to distinguish between "switch-to-buffer the command"
>     and "switch-to-buffer" the function.  I don't care about the behavior
>     of the command, but of the function.

> They are the same.  We could make it do something different,
> then specially restore the old behavior for interactive calls only.

Yes.  E.g. we could add an argument `noother which says: don't try to use
another window if the current one can't be used.  This arg would be set to
non-nil in interactive calls.

> But I think it would be a change for the worse to do this.

Why exactly?

>     And the problem is made worse because there is currently no function that
>     does what we want in such case, i.e. "show buffer B, preferably in the
>     current window".

> Perhaps the right thing is to define a new function which does that.
> It could be called select-buffer, or switch-to-buffer-somewhere.
> It could leave you with that buffer visible in the selected window,
> which would be the previously current buffer if that is possible.

Problem is: many packages (bundled or not with Emacs) use switch-to-buffer
as if it were that new function (i.e. they don't take into account the fact
that switch-to-buffer might fail).

So I'd rather change the behavior of the switch-to-buffer function and
restore it for interactive cases or create a new command (which we'd bind to
C-x b).  Note that for most people, if they call switch-to-buffer instead of
the new command, they won't notice the difference because they never have
any dedicated window and they never use the command when the minibuffer is
the currently selected window.


        Stefan