From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steve Yegge Newsgroups: gmane.emacs.bugs Subject: bug#4041: 23.0.92; Emacs 23: buffer point is no longer frame-local Date: Fri, 7 Oct 2011 14:09:14 -0700 Message-ID: References: <20090805001735.1CC041E844E@localhost> <4E745DAE.5040808@gmx.at> <4E8EA522.9090300@gmx.at> <4E8F3040.1060409@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd4cda283c67204aebbda66 X-Trace: dough.gmane.org 1318021807 28052 80.91.229.12 (7 Oct 2011 21:10:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 7 Oct 2011 21:10:07 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , 4041@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 07 23:10:02 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RCHg8-0003un-Hp for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Oct 2011 23:10:00 +0200 Original-Received: from localhost ([::1]:45072 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCHg1-0001FR-WF for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Oct 2011 17:09:54 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCHfw-0001F8-Tg for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2011 17:09:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RCHfu-0003di-TL for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2011 17:09:48 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36610) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCHfu-0003db-MD for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2011 17:09:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RCHgA-0005O6-HL for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2011 17:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Steve Yegge Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Oct 2011 21:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 4041 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 4041-submit@debbugs.gnu.org id=B4041.131802178320678 (code B ref 4041); Fri, 07 Oct 2011 21:10:02 +0000 Original-Received: (at 4041) by debbugs.gnu.org; 7 Oct 2011 21:09:43 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RCHfq-0005NS-FS for submit@debbugs.gnu.org; Fri, 07 Oct 2011 17:09:43 -0400 Original-Received: from smtp-out.google.com ([74.125.121.67]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RCHfn-0005NG-Oo for 4041@debbugs.gnu.org; Fri, 07 Oct 2011 17:09:41 -0400 Original-Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p97L9HH9024312 for <4041@debbugs.gnu.org>; Fri, 7 Oct 2011 14:09:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318021757; bh=J1RI/yCw5h7hqGxa0TlbelM6XqU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=wuj6Qdplc8bp6TukbhpOoA+W2dT3mVnCB3UsxUJM8uKL4Y7Jm+5ka5wKTw5b3iXsf T6iKvIejPpNrMm6VJ0+qg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=kMp480sUlne/eQxKvNsYoG9vMrv6obePLCQQUz2iK6KSqS4VuQjZhBJL38LqzUGnW S7iDl9XVFty4jrZ7i61fA== Original-Received: from qyk34 (qyk34.prod.google.com [10.241.83.162]) by hpaq1.eem.corp.google.com with ESMTP id p97L9Fuo021729 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <4041@debbugs.gnu.org>; Fri, 7 Oct 2011 14:09:16 -0700 Original-Received: by qyk34 with SMTP id 34so5527219qyk.10 for <4041@debbugs.gnu.org>; Fri, 07 Oct 2011 14:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IfI8/EDV712InVwaKj4Hj49xXhqtbopGphlVHuuUISM=; b=digaoxvkM5fF5XGH897+hFVEEF6rxIxjCpSCMKIIto5nSBcZffuYqmxKzEOJls4mOq eB44IbMgqClerwZqNWWg== Original-Received: by 10.150.131.11 with SMTP id e11mr1939115ybd.162.1318021755235; Fri, 07 Oct 2011 14:09:15 -0700 (PDT) Original-Received: by 10.150.131.11 with SMTP id e11mr1939105ybd.162.1318021755028; Fri, 07 Oct 2011 14:09:15 -0700 (PDT) Original-Received: by 10.151.43.13 with HTTP; Fri, 7 Oct 2011 14:09:14 -0700 (PDT) In-Reply-To: <4E8F3040.1060409@gmx.at> X-System-Of-Record: true X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 07 Oct 2011 17:10:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:52404 Archived-At: --000e0cd4cda283c67204aebbda66 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 10:00 AM, martin rudalics wrote: > >> Whatever we did here, it would make `switch-to-buffer' behave > >> inconsistently. > > > > But it'd be the natural thing to do, I think. > > I can't tell because I'm a single-frame user. The main argument in > favor of a "retain the previous point" strategy is that it makes no > sense to go to the same position already shown in another frame. But > then what about doing C-x b in a window below another one already > showing the buffer I want to switch to? This is an interesting question. The behavior today closely parallels the multi-frame behavior, so I can see how you feel that making my proposed change would make `switch-to-buffer' inconsistent. But you have reminded me that I have for many years wished for the multi-window-one-frame behavior to be different -- and in essentially the same way I've proposed that the multi-window-multi-frame behavior be changed. Assume you have buffer B open on frame F in windows T, U and V, respectively displaying B at positions P1, P2 and P3. Now in window W, also on F, you C-x b to switch to B. Today it takes you to P1, assuming T is next in the window-list. If no window were currently showing B, then W would display point-min. Let's call this the "existing-window" behavior, as for a new window W it will choose a position from an existing window. If you were to make my proposed multi-frame change, I think you could reasonably choose to retain the existing-window behavior within a frame, as it preserves the current intra-frame buffer-switching semantics. However, over the decades I have noticed that when I have two or more windows open to the same buffer on the same frame, it is almost always because I want to establish N > 1 persistent working locations within that buffer. In fact it is rarely useful to have two windows open to the same buffer location, as they merely echo each other. So I would posit that my "multiple persistent working locations" use case is likely to be the most common reason for users to have N > 1 windows displaying the same buffer in a given frame. 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. I have long found this behavior most unfortunate. Ironically, the best workaround is to visit B in window X on a second frame G. Then no matter what happens to the window configuration in F, X will retain its window point at your second working location P'. Trying to work around it within F requires that you disturb your window configuration, or attempt to track your working locations with the mark ring, or some other relatively unnatural workflow. At least, I find it unnatural compared to my desired workflow: - open a window T and display buffer B at position Pt - in window U switch to buffer B (it defaults to Pt, which is fine) - then in U: * move to a different position Pu in B * switch to any other buffer C (e.g. Info, shell, ...) * switch back to buffer B * continue working at Pu This workflow, which I think of as "persistent window positions", would actually be closest to how Emacs works in the most common use case of all: single-frame, single-window. If you are visiting B at position P, and you switch away, then back, you will return to P. It is easy to think of this as the window remembering where you last were in B. If you think of it this way, as I do, then you are constantly surprised that windows suffer from amnesia whenever more than one of them is displaying the same buffer. It feels to me that they should behave as if they are independent. Thus I would be happiest if there were an option such that every window tracks the buffer positions of every buffer that it visits, and when switching back to a buffer B that it has already visited, each window displays B at the same position it last displayed B. If you kill a window, its position list goes away. New windows would start with a nil position list, and the first time they visit a buffer they would use the "existing-window" semantics: use the position of the next window currently displaying the buffer, or else point-min. (It might be confusing to have them choose from the position-list of a window that has previously visited the buffer but is not currently displaying it, so I'd not do that.) Similarly if you kill a buffer, then it is removed from the position lists for all existing windows. If it is recreated, e.g. by opening the file again for file buffers, all windows would initially begin viewing it at point-min. I think "per-window visited-buffer last-position lists" would solve the multi-frame problem (4041). I believe they would also clean up the IMO rather unfortunate existing semantics for same-buffer, same-frame, multiple windows, since the current behavior (a) doesn't parallel the current single-frame, single window behavior, and (b) doesn't allow for multiple temporary "persistent" working locations in multiple windows in a single buffer on a single frame. At the very least it'd be a nice global configuration option. I'm sure you could probably do all this with a package, but it's fairly fundamental -- it would be nice, for example, to be able to enable it by setting a single variable on someone else's Emacs instance while debugging something for them. I have done an exhaustive survey of everyone sitting near me right now, and they both agreed that buffer positions should be "window-local", and that they've been annoyed by it forever as well. Just wanted to cover my bases! ;) -steve --000e0cd4cda283c67204aebbda66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2011 at 10:00 AM, martin rudalics <rudalics@gmx.at> wrote:
>> Whatever we did here, it would make `switch-to-b= uffer' behave
>> inconsistently.
>
> But it'd be the natural thing to do, I think.

I can't tell because I'm a single-frame user. =A0The main argument = in
favor of a "retain the previous point" strategy is that it makes = no
sense to go to the same position already shown in another frame. =A0But
then what about doing C-x b in a window below another one already
showing the buffer I want to switch to?

Thi= s is an interesting question. =A0The behavior today closely parallels
=
the multi-frame behavior, so I can see how you feel that making my
proposed change would make `switch-to-buffer' inconsistent.
<= div>
But you=A0have reminded me that I have for many years wi= shed for the
multi-window-one-frame behavior to be different -- a= nd in essentially
the same way I've proposed that the multi-window-multi-frame behav= ior
be changed.

Assume you have buffer B= open on frame F in windows T, U and V,
respectively displaying B= at positions P1, P2 and P3. =A0Now in window
W, also on F, you C-x b to switch to B. =A0Today it takes you to P1,
assuming T is next in the window-list. =A0If no window were curren= tly
showing B, then W would display point-min.

Let's call this the "existing-window" behavior, as for a= new window W it
will choose a position from an existing window. = =A0If you were to make my
proposed multi-frame change, I think yo= u could reasonably choose to
retain the existing-window behavior within a frame, as it preserves th= e
current intra-frame buffer-switching semantics.

<= /div>
However, over the decades I have noticed that when I have two or<= /div>
more windows open to the same buffer on the same frame, it is almost
always because I want to establish N > 1 persistent working loc= ations
within that buffer. =A0In fact it is rarely useful to have= two windows open
to the same buffer location, as they merely echo each other. =A0So
I would posit that my "multiple persistent working locations&qu= ot; use case
is=A0likely to be the most common reason for users t= o have N > 1
windows displaying the=A0same buffer in a given frame.

<= /div>
The problem with today's "existing-window" behavior= is that if you
have window T displaying buffer B on frame F at b= uffer position P,
then you can not sustain a *persistent* working location P' in any=
other window U on F. =A0By "persistent", I specificall= y mean that in
window U, if I switch temporarily away to another = buffer and then
back, I want to go back to P'. =A0Today it takes me to P: =A0 I ha= ve lost
my working location in U.

I have= long found this behavior most unfortunate. =A0Ironically, the
be= st workaround is to visit B in window X on a second frame G.
Then no matter=A0what happens to the window configuration in F,
<= div>X will retain its window point at your second working location P'.<= /div>

Trying to work around it within F requires that yo= u disturb your
window configuration, or attempt to track your working locations
=
with the mark ring, or=A0some other relatively unnatural workflow.
At least, I find it unnatural compared to my desired workflow:

=A0 - open a window T and display buffer B at position = Pt
=A0 - in window U switch to buffer B (it defaults to Pt, which= is fine)
=A0 - then in U:
=A0 =A0 * move to a differen= t position Pu in B
=A0 =A0 * switch to any other buffer C (e.g. Info, shell, ...)
=A0 =A0 * switch back to buffer B
=A0 =A0 * continue working a= t Pu

This workflow, which I think of as "pers= istent window positions",
would actually be closest to how Emacs works in the most
com= mon use=A0case of all: =A0single-frame, single-window. =A0If you are
<= div>visiting B at position=A0P, and you switch away, then back, you will
return to P. =A0It is easy to think of this as the window remembering
=
where you last were in B. =A0If you think of it this way, as I do, the= n
you are constantly surprised that windows suffer from amnesia
whenever more than one of them is displaying the same buffer.
It feels to me that they should behave as if they are independent.
<= div>
Thus I would be happiest if there were an option such th= at every
window tracks the buffer positions of every buffer that it visits,
and when switching back to a buffer B that it has already visited,
each=A0window=A0displays B at the same position it last displayed = B.

If you kill a window, its position list goes away. =A0N= ew windows
would start with a nil position list, and the first ti= me they visit a
buffer they would use the "existing-window&q= uot; semantics: =A0use
the position of the next window currently displaying the buffer,
=
or else point-min. =A0(It might be confusing to have them choose
=
from the position-list of a window that has previously visited
the buffer but is not currently displaying it, so I'd not do that.= )

Similarly if you kill a buffer, then it is remov= ed from the position
lists for all existing windows. =A0If it is = recreated, e.g. by opening
the file again for file buffers, all windows would initially begin
viewing it at point-min.

I think "per-= window visited-buffer last-position lists" would solve
the m= ulti-frame problem (4041). =A0I believe they would also
clean up the IMO rather unfortunate existing semantics for
s= ame-buffer, same-frame, multiple windows, since the current
behav= ior (a) doesn't parallel the current single-frame, single
window behavior, and (b) doesn't allow for multiple temporary
"persistent" working locations in multiple windows in a single
buffer on a single frame.

At the very lea= st it'd be a nice global configuration option.
I'm sure you could probably do all this with a package, but
<= div>it's fairly fundamental -- it would be nice, for example, to be
able to enable it by setting a single variable on someone
else's Emacs instance while debugging something for them.
I have done an exhaustive survey of everyone sitting near
=
me right now, and they both agreed that buffer positions
should be "window-local", and that they've been annoyed
=
by it forever as well. =A0Just wanted to cover my bases! ;)
=
-steve
--000e0cd4cda283c67204aebbda66--