[Top][All Lists]

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

bug#4041: 23.0.92; Emacs 23: buffer point is no longer frame-local

From: Eli Zaretskii
Subject: bug#4041: 23.0.92; Emacs 23: buffer point is no longer frame-local
Date: Sat, 08 Oct 2011 16:12:54 +0200

> Date: Sat, 08 Oct 2011 15:23:29 +0200
> From: martin rudalics <address@hidden>
> Cc: Lars Magne Ingebrigtsen <address@hidden>, address@hidden
> Having "two or more windows open to the same buffer" sounds like a
> reasonable condition.  The problem is that you might have no window
> showing the buffer and still want to restore the previous window
> position.  That's why `switch-to-prev-buffer' is superior to any
> `switch-to-buffer' changing solution.  Notwithstanding Lars' argument
> that people are used to C-x b, tell me why `switch-to-prev-buffer'
> (combined with `switch-to-next-buffer') doesn't do what you want.

It doesn't do what I want because it doesn't accept a buffer
argument.  So I'm forced to try the previous buffers one by one, in
the LIFO order, until I find the one I have in mind.  And if I then
want to go back to one of those I visited on the way, I need either
use switch-to-next-buffer (if I happen to remember how far "forward"
that buffer is) or make the full circle, including *scratch* and
*Messages*, before I get there.

So I don't think switch-to-next/prev-buffer can be a convenient
solution to this problem.

What is necessary is a way to switch to a buffer by name and have the
window remember its previous window-point.  If the buffer was never
displayed in this window, "C-x b" should choose some value of
window-point that was used before and is not already displayed in some
other window.  (If there's a window for every possible value of
window-point for the buffer, i.e. the user opens yet another window
with the same buffer, just choose one of the values, e.g., the first
or the last.)  For the important use case of having 2 windows with the
same buffer, this strategy will do _exactly_ what the user wants.

>  > The problem with today's "existing-window" behavior is that if you
>  > have window T displaying buffer B on frame F at buffer position P,
>  > then you can not sustain a *persistent* working location P' in any
>  > other window U on F.  By "persistent", I specifically mean that in
>  > window U, if I switch temporarily away to another buffer and then
>  > back, I want to go back to P'.  Today it takes me to P:   I have lost
>  > my working location in U.
> Not with `switch-to-prev-buffer' ;-)

Yes, but it works satisfactorily only if you switch between 2 buffers
in the same window.  Switch to a third, and you are screwed.

(And, btw, why aren't those 2 functions documented in the user

reply via email to

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