From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#19576: write-file writes the wrong buffer Date: Tue, 17 Nov 2015 22:52:53 +0100 Message-ID: References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <20151117200204.GA5054@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11473d2c38ae340524c38c76 X-Trace: ger.gmane.org 1447797270 11666 80.91.229.3 (17 Nov 2015 21:54:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 21:54:30 +0000 (UTC) Cc: 19576@debbugs.gnu.org, Juri Linkov To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 17 22:54:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZyoCa-0003Ae-2H for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 22:54:12 +0100 Original-Received: from localhost ([::1]:60815 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyoCZ-0004gi-AV for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 16:54:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyoCU-0004gb-3z for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:54:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyoCQ-0000UB-Py for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:54:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyoCQ-0000U6-MV for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZyoCQ-0000Zn-Bh for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Nov 2015 21:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19576 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19576-submit@debbugs.gnu.org id=B19576.14477971952093 (code B ref 19576); Tue, 17 Nov 2015 21:54:02 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 21:53:15 +0000 Original-Received: from localhost ([127.0.0.1]:42070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyoBe-0000Xd-Ma for submit@debbugs.gnu.org; Tue, 17 Nov 2015 16:53:15 -0500 Original-Received: from mail-yk0-f182.google.com ([209.85.160.182]:34881) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZyoBJ-0000WW-QO for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 16:53:13 -0500 Original-Received: by ykba77 with SMTP id a77so31327189ykb.2 for <19576@debbugs.gnu.org>; Tue, 17 Nov 2015 13:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MHifz/ctnsI+Bp5Il1ZldjaJo/AJIgUhvW/ZYf0NWOw=; b=suUVthCGOVcJIMls90an1WNAHI4ZZH15uUkA7RCxDeoSVor/PfkffuE/+I1hG1dJgs s+TDwv3arjArFYzv/ACS/XX3fK/G4HgdsUPFXQOlz110pkO7EnXxFyx8btcyKPpod43N SyMJAbExrp8ZWJrxT9TdNSxzXY6R03Klr1aAuZyJ9otMjcZcLMZRn259DyBE8RNjWV9G r09Ej9v16qrYz40KCKlxGUrwja7jCpBFYXIqB5Il8aJsNLdaYXNIO3NUXaMjuhTPh9MS C5sf+2jgXtCCwpbIVkWXn1f+XVwa3Y/CJmKg+jCnyWV24QdIsQtMYqfZ7WoRGVsOHx1J UQrw== X-Received: by 10.129.116.85 with SMTP id p82mr43011367ywc.158.1447797173298; Tue, 17 Nov 2015 13:52:53 -0800 (PST) Original-Received: by 10.31.210.133 with HTTP; Tue, 17 Nov 2015 13:52:53 -0800 (PST) In-Reply-To: <20151117200204.GA5054@acm.fritz.box> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.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:108842 Archived-At: --001a11473d2c38ae340524c38c76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alan (and the rest of you)! First, I'm really glad that you have taken on the challange to modernize follow mode! On Tue, Nov 17, 2015 at 02:55:39AM +0200, Juri Linkov wrote: > > >> Conceptually it should be easy to do that. Save/restore current > buffer, > > >> selected window and frame. But Alan (concerned about =E2=80=98follo= w-mode=E2=80=99), > > >> Pip (who unfortunately disappeared) and Eli are currently discussing > how > > >> to fix =E2=80=98window-size-change-functions=E2=80=99 in various oth= er ways as well. > > I have a fix for the `window-size-change-functions' problem, which I > posted just over an hour ago (see bug #21869 or #21333). The fix > consists of only invoking w-s-c-f after any change to the echo area size > has been done. This might have some relevance for the current bug. (I > haven't followed the current bug, I'm afraid.) I really need the > go-ahead from Eli before I can commit the fix to the emacs-25 or master > branch. > Today Martin sent me a patch that solved the window-size-change-functions problem i reported in bug#19576. I think this is different from the varying echo area problems of the other bugs, though. In general, follow mode is wonderful (I use it all the time), I'm glad to hear it! I use it evert day too, and every time I do I'm glad that I invested the time to write it. but > (i) is not sufficiently integrated with the rest of Emacs, and > (ii) is too difficult to use in an emacs -Q. > > By (ii), I mean that manually creating the side by side windows and > doing M-x follow-mode is too cumbersome. > follow-delete-other-windows-and-split is not bound to any key sequence > by default. I have my own private commands bound to C-c 2, C-c 3, C-c > 4, which enable follow mode in 2, 3, and 4 windows. I also have C-c 0, > which disables follow mode. I think Emacs should have something like > these in its global key map, say on C-x w f. Maybe for Emacs 25.2, or > 26.1. > I agree, I use an Emacs frame with six columns spread out across two monitors, and it feels like many of the basic functions are missing. I while a go I put together a companion program for follow mode which I named "multicolumn". It provides functions to set up the frame to accommodate a number of side-by-side windows. It also resizes the frame (down to the pixel) for this. Also it defines a number of keys like "C-x <" and "C-x >" for going to the leftmost and rightmost window, respectively. You can find this at https://github.com/Lindydancer/multicolumn. By (i), I mean that other lisp programs cannot use follow mode. For > example, many programs use `window-start' to get the start of the area > they want to work on, when really what they should get is the start of > the "lowest" follow window. > Agreed. One thing that disturbs me (which I haven't fixed yet) is when a new buffer is displayed in the middle of a group of follow-mode windows. It would be a good idea to teach `display-buffer' to pick another window, like one the first or last instead. I have, as yet, two > alternative implementations for this: > (i) New functions with names like window*-start (notice the "*"), > written in lisp in window.el; > Maybe "window-group-start"? The "*" disappears easily and a window group could actually be something else than a follow-mode group. (ii) Adding an extra parameter to the primitives (mainly in window.c), > so that instead of calling (window-start win), a function would call > (window-start win t). > > Buffer local variables to perform the redirection are initialised at > follow-mode start up, and removed at follow-mode termination. > > Of the above alternatives, Eli prefers (ii), but I think Juri prefers > (i). I can't say that it matters, really, but I think that I would prefer (i) since 1) it's stands out more in the source and 2) it's an all-lisp implementation. Sincerely, Anders Lindgren --001a11473d2c38ae340524c38c76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alan (and the rest of you)!

First, I= 'm really glad that you have taken on the challange to modernize follow= mode!


<= div class=3D"gmail_quote">
On Tue, Nov 17,= 2015 at 02:55:39AM +0200, Juri Linkov wrote:
> >> Conceptually it should be easy to do that.=C2=A0 Save/restore= current buffer,
> >> selected window and frame.=C2=A0 But Alan (concerned about = =E2=80=98follow-mode=E2=80=99),
> >> Pip (who unfortunately disappeared) and Eli are currently dis= cussing how
> >> to fix =E2=80=98window-size-change-functions=E2=80=99 in vari= ous other ways as well.

I have a fix for the `window-size-change-functions' problem, whi= ch I
posted just over an hour ago (see bug #21869 or #21333).=C2=A0 The fix
consists of only invoking w-s-c-f after any change to the echo area size has been done.=C2=A0 This might have some relevance for the current bug.=C2= =A0 (I
haven't followed the current bug, I'm afraid.)=C2=A0 I really need = the
go-ahead from Eli before I can commit the fix to the emacs-25 or master
branch.

Today Martin sent me a patch th= at solved the window-size-change-functions problem i reported in bug#19576.= I think this is different from the varying echo area problems of the other= bugs, though.


In gener= al, follow mode is wonderful (I use it all the time),

=
I'm glad to hear it! I use it evert day too, and every time = I do I'm glad that I invested the time to write it.


but
(i) is not sufficiently integrated with the rest of Emacs, and
(ii) is too difficult to use in an emacs -Q.

By (ii), I mean that manually creating the side by side windows and
doing M-x follow-mode is too cumbersome.
follow-delete-other-windows-and-split is not bound to any key sequence
by default.=C2=A0 I have my own private commands bound to C-c 2, C-c 3, C-c=
4, which enable follow mode in 2, 3, and 4 windows.=C2=A0 I also have C-c 0= ,
which disables follow mode.=C2=A0 I think Emacs should have something like<= br> these in its global key map, say on C-x w f.=C2=A0 Maybe for Emacs 25.2, or=
26.1.

I agree, I use an Emacs frame wit= h six columns spread out across two monitors, and it feels like many of the= basic functions are missing.

I while a go I put t= ogether a companion program for follow mode which I named "multicolumn= ". It provides functions to set up the frame to accommodate a number o= f side-by-side windows. It also resizes the frame (down to the pixel) for t= his. Also it defines a number of keys like "C-x <" and "C= -x >" for going to the leftmost and rightmost window, respectively.=

You can find this at https://github.com/Lindydancer/multicolumn.<= /div>


By (i), I mean that ot= her lisp programs cannot use follow mode.=C2=A0 For
example, many programs use `window-start' to get the start of the area<= br> they want to work on, when really what they should get is the start of
the "lowest" follow window.

A= greed.

One thing that disturbs me (which I haven&#= 39;t fixed yet) is when a new buffer is displayed in the middle of a group = of follow-mode windows. It would be a good idea to teach `display-buffer= 9; to pick another window, like one the first or last instead.

=C2=A0 I have, as yet, two
alternative implementations for this:
(i) New functions with names like window*-start (notice the "*"),=
written in lisp in window.el;

Maybe &qu= ot;window-group-start"? The "*" disappears easily and a wind= ow group could actually be something else than a follow-mode group.


(ii) Adding an extra parameter to the primitives (mainly in window.c),
so that instead of calling (window-start win), a function would call
(window-start win t).

Buffer local variables to perform the redirection are initialised at
follow-mode start up, and removed at follow-mode termination.

Of the above alternatives, Eli prefers (ii), but I think Juri prefers
(i).

I can't say that it matters, reall= y, but I think that I would prefer (i) since 1) it's stands out more in= the source and 2) it's an all-lisp implementation.

Sincerely,
=C2=A0 =C2=A0 Anders Lindgren

--001a11473d2c38ae340524c38c76--