emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Jumping to C source from *Help*


From: Kim F. Storm
Subject: Re: Jumping to C source from *Help*
Date: 15 Apr 2004 18:27:37 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Stefan Monnier <address@hidden> writes:

> >> But I think it would be a change for the worse to do this.
> >     Why exactly?
> > It puts more complexity in something simple.
> 
> [ I don't see it, but let's put that aside for now. ]
> 
> OK, so you don't want a function that can either use pop-to-buffer or
> signal an error depending on an extra argument.  Fair enough.
> 
> Given that I think the problem is serious enough for users such as myself
> that I'd like to see this resolved, I have three alternatives (from least
> preferred to most preferred):
> 1 - Leave switch-to-buffer as is, but introduce a new function (call it
>     `pop-to-buffer-this-window').
> 2 - Change switch-to-buffer to call pop-to-buffer rather than signal an
>     error, and introduce a new command (call it
>     `switch-to-buffer-this-window') which we'd then bind to C-h b.
> 3 - Change switch-to-buffer to call pop-to-buffer rather than signal an
>     error and leave everything else unchanged.
> 
> Option 1 has the problem that it doesn't fix anything in itself and
> requires to change all the packages to use the new function.  In general,
> I can't change all those packages, so I'll still have to live with
> spurious errors every once in a while.
> 
> Option 3 is better because it's the simplest.  Now you might think that you
> don't like it because it changes the default behavior, but think again:
> it only changes the behavior in the case where you used to get an error
> "Cannot switch buffers in minibuffer window" or
> "Cannot switch buffers in a dedicated window".  When was the last time
> you saw such an error message?  Most users have never seen this message
> because they don't have dedicated windows and they never hit C-x b
> while they're in the minibuffer.

I see the "cannot switch buffers in minibuffer window" from time to time.
And it always annoys me -- of course I don't want to switch buffer in 
the minibuffer window, I obviously want to have the buffer I select to
appear in some ordinary window.

I'd vote for 3 as well.  

I don't see how that can surprise users -- quite the contrary.
Consider this:

(0) suppose we have one dedicated window showing a buffer

(1) enter C-x b
     (notice there is no warning at this point)

(2) enter the name of some other buffer

(3) => "cannot switch buffer in a dedicated window"

        SIGH!

(4) manually split current (dedicated) window, C-x 2
    Hey, no, wait -- that creates another window,
    but leaves the dedicated window selected, so

(5) select the other window, C-x o

(6) repeat step (1)

(7) repeat step (2)

(8) => the buffer you wanted to select is now present in a different window.



Compare this to [option 3]:

(0) suppose we have one dedicated window showing a buffer

(1) enter C-x b
     (notice there is no warning at this point)

(2) enter the name of some other buffer

(3) => the buffer you wanted to select is now present in a different window.



If we are discussing what is simple/non-confusing to the (novice) user, 
I would way that option 3 is much better than the current situation...

And then it solves some "odd" bugs in various packages as an added bonus.


-- 
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]