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:15:07 +0100 Message-ID: References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1147fa52257de10524c3054d X-Trace: ger.gmane.org 1447794984 7064 80.91.229.3 (17 Nov 2015 21:16:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 21:16:24 +0000 (UTC) Cc: 19576@debbugs.gnu.org, Alan Mackenzie To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 17 22:16: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 1Zynbo-0001QU-AH for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 22:16:12 +0100 Original-Received: from localhost ([::1]:60674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zynbn-0001Jc-G8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Nov 2015 16:16:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zynbh-0001I3-P4 for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:16:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zynbe-0007lu-FS for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:16:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zynbe-0007lq-CF for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zynbd-0007Kk-MR for bug-gnu-emacs@gnu.org; Tue, 17 Nov 2015 16:16:01 -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:16:01 +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.144779492928082 (code B ref 19576); Tue, 17 Nov 2015 21:16:01 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 17 Nov 2015 21:15:29 +0000 Original-Received: from localhost ([127.0.0.1]:42049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zynb5-0007Im-NU for submit@debbugs.gnu.org; Tue, 17 Nov 2015 16:15:28 -0500 Original-Received: from mail-yk0-f170.google.com ([209.85.160.170]:34553) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zynal-0007Hr-KA for 19576@debbugs.gnu.org; Tue, 17 Nov 2015 16:15:26 -0500 Original-Received: by ykfs79 with SMTP id s79so29828287ykf.1 for <19576@debbugs.gnu.org>; Tue, 17 Nov 2015 13:15:07 -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=ySETw/+Xh0b0DkEXbqQOTOwM5cK0zFu8Ahyiw2xAyK4=; b=E9uc+k1D1BVdqt5Qm2VYCDNjVRYeNZ70zXbiy53mLBcXUGDn9dbZWudxZJw+Ksp14r jTu88ttX001J8J5VprBe2SbpVj9oCE6SUfXWR3Uj+S9okup8ECMFI7ogMUJ+WbMYnOHQ Xa4juI7AWQ7H/JXz/6GYPAYduxzFrez+8C+zYdiYqKt5gDEc5nf7nGPnGVSwumX2N/6N wW19iQUVoJcNNZY97OC6ySidCXnTwXYFAQPDrlIkXvYNCfvmtgmpLLTACepY+V3V40Zw esD8N3EwC0bPOFXglJmI6RcFEv+dGjz5kGOuFtc2gpg0reHaV7KFV5M5gkWLZyH407h3 LaXw== X-Received: by 10.129.80.138 with SMTP id e132mr41847086ywb.90.1447794907116; Tue, 17 Nov 2015 13:15:07 -0800 (PST) Original-Received: by 10.31.210.133 with HTTP; Tue, 17 Nov 2015 13:15:07 -0800 (PST) In-Reply-To: <87fv05phpw.fsf@mail.linkov.net> 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:108840 Archived-At: --001a1147fa52257de10524c3054d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everybody! (I took the liberty to add Eli to this as well, as this involves the display engine.) Meanwhile, I'm taking an opportunity to ask you about your intriguing > comment > in follow.el: > > ;; Almost like the real thing, except when the cursor ends up outside > ;; the top or bottom... In our case however, we end up outside the > ;; window and hence we are recentered. Should we let `recenter' handle > ;; the point position we would never leave the selected window. To do > ;; it ourselves we would need to do our own redisplay, which is easier > ;; said than done. (Why didn't I do a real display abstraction from > ;; the beginning?) > > What a real display abstraction would you create if you designed > follow-mode today? > Unfortunately, I haven't got a clue what my twenty-years younger me was thinking when writing this... However, here are some thoughts on follow-mode I have accumulated over the years: * The core of follow-mode call `redisplay' and does all sorts of tricks to keep up the illusion that a number of windows form a very tall windows. I would like to do some investigations if this can be done more efficiently. Keith David Bershatsky (a.k.a. lawlist) has analyzed under which circumstances Emacs calls the different hooks and functions using a tool he named `test-mode'. Maybe this information can be used to write a better implementation of follow-mode. (Of course, one alternative would be to implement this in the Emacs display engine, but I don't see that happening anytime soon.) * The Emacs display engine tries to recenter windows when window-start =3D= =3D buffer-end, to ensure that no window would appear empty. When follow-mode is enabled, this is not what we want (except for the leftmost window). To counter the recentering efforts of Emacs, follow-mode sets window-start whenever it gets a chance. I would prefer if it was possible to tell the display engine to leave some windows alone, preferably with some kind of buffer-local `recenter-window-functions' variable. It could be made generic so that the return value would be an integer telling Emacs to show this many lines (if positive) or place the last line X lines from the bottom (when negative). If such hook existed, follow-mode could return 0 for all (except the leftmost) windows. Note that the user can change the content of any window at any time, so this property isn't static. * Make it easier for other packages to use it. By this I mean packages that display information, like "grep", should be able to use follow mode to display a buffer using side by side windows. Concretely, in font-lock-studio (a debugger for font-lock keywords I wrote a while ago) I do this, but I had to call `follow-post-command-hook' explicitly. Follow mode should need a better interface for this, alternatively this should be built into `display-buffer' so that it happens automatically. * When follow-mode is enabled, there is a noticeable lag when updating the region. You can see this by pressing C-c SPACE and holding the up or down key. When follow-mode is disabled, the region is updated as fast as the cursor moves, when enabled, it is updated in chunks. * When written in the Emacs old era, the region was always highlighted in all windows. Follow-mode went to great lengths to place the cursor in the non-selected windows so that the region would look good. Today, one could get the same effect by setting `highlight-nonselected-windows' (except that the region is visible on the last line of windows to the left of the selected window.) I would love to give the user the option to 1) automatically set this variable and move the cursor in the non-selected windows or 2) don't move the cursors at all. (Alternatively, invent a new way to highlight the region of the selected windows in the other windows, without the cursor in the non-selected windows affecting it.) * isearch: If I recall correctly, isearch used to worked across follow-mode windows. Of course, this was before isearch highlighted matches etc. It would be great if this could be restored once again! * Process output: In early versions of follow-mode, it could be used with any process. This was accomplished using `defadvice' on a handful of process-related functions. At some point in time, this system was replaced with a system specific to comint and compilation buffers -- as part of the great defadvice sweep. Personally, I would like to Emacs to provide `pre-process-output-functions' and `post-process-output-functions', allowing packages like follow-mode to perform whatever action they would like to the output of any process. * If a user have columns with different widths, follow-mode can't correctly display long lines stretching from one window to the next. The reason for this is that the start position can't be placed at an arbitrary location on a long line, only on positions that are a multiple of the column width. I don't see any way to solve this without modifying the display engine. * Automatic tests: These should verify the basic functionality, that the windows are aligned properly. That moving the point down in one window would move it to the next. All follow-mode-specific commands etc. Anyway, this is a dire wish-list and I feel that I, unfortunately, presently can't contribute to it. When it comes to Emacs responsibilities, I have taken over the NextStep port after Jan Dj=C3=A4rvs resignation, and = on a personal level I have a full time job and I have two small children and a third due in about a week (if all goes well). Anyway, I'm glad that Alan has taken this bull by the horn. However, feel free to ask questions or discuss implementation ideas regarding this. Sincerely, Anders Lindgren --001a1147fa52257de10524c3054d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Everybody!

(I took the liberty to add Eli to t= his as well, as this involves the display engine.)


Meanwhile, I'm taking an opportunity to ask= you about your intriguing comment
in follow.el:

;; Almost like the real thing, except when the cursor ends up outside
;; the top or bottom...=C2=A0 In our case however, we end up outside the ;; window and hence we are recentered.=C2=A0 Should we let `recenter' h= andle
;; the point position we would never leave the selected window.=C2=A0 To do=
;; it ourselves we would need to do our own redisplay, which is easier
;; said than done.=C2=A0 (Why didn't I do a real display abstraction fr= om
;; the beginning?)

What a real display abstraction would you create if you designed
follow-mode today?


Unfortunately, I haven't got a clue what my twenty-ye= ars younger me was thinking when writing this...


However, here are some thoughts on follow-mode I have accumulated over= the years:

* The core of follow-mode call `redisplay' and does all sorts of = tricks to keep up the illusion that a number of windows form a very tall wi= ndows. I would like to do some investigations if this can be done more effi= ciently. Keith David Bershatsky (a.k.a. lawlist) has analyzed under which c= ircumstances Emacs calls the different hooks and functions using a tool he = named `test-mode'. Maybe this information can be used to write a better= implementation of follow-mode. (Of course, one alternative would be to imp= lement this in the Emacs display engine, but I don't see that happening= anytime soon.)

* The Emacs display engine tries to recenter windows when win= dow-start =3D=3D buffer-end, to ensure that no window would appear empty. W= hen follow-mode is enabled, this is not what we want (except for the leftmo= st window). To counter the recentering efforts of Emacs, follow-mode sets w= indow-start whenever it gets a chance. I would prefer if it was possible to= tell the display engine to leave some windows alone, preferably with some = kind of buffer-local `recenter-window-functions' variable. It could be = made generic so that the return value would be an integer telling Emacs to = show this many lines (if positive) or place the last line X lines from the = bottom (when negative). If such hook existed, follow-mode could return 0 fo= r all (except the leftmost) windows. Note that the user can change the cont= ent of any window at any time, so this property isn't static.
=

* Make it e= asier for other packages to use it. By this I mean packages that display in= formation, like "grep", should be able to use follow mode to disp= lay a buffer using side by side windows. Concretely, in font-lock-studio (a= debugger for font-lock keywords I wrote a while ago) I do this, but I had = to call `follow-post-command-hook' explicitly. Follow mode should need = a better interface for this, alternatively this should be built into `displ= ay-buffer' so that it happens automatically.

* When follow-mode is enable= d, there is a noticeable lag when updating the region. You can see this by = pressing C-c SPACE and holding the up or down key. When follow-mode is disa= bled, the region is updated as fast as the cursor moves, when enabled, it i= s updated in chunks.

* When written in the Emacs old era, the region was always= highlighted in all windows. Follow-mode went to great lengths to place the= cursor in the non-selected windows so that the region would look good. Tod= ay, one could get the same effect by setting `highlight-nonselected-windows= ' (except that the region is visible on the last line of windows to the= left of the selected window.) =C2=A0I would love to give the user the opti= on to 1) automatically set this variable and move the cursor in the non-sel= ected windows or 2) don't move the cursors at all. (Alternatively, inve= nt a new way to highlight the region of the selected windows in the other w= indows, without the cursor in the non-selected windows affecting it.)
=

* isearch: = If I recall correctly, isearch used to worked across follow-mode windows. O= f course, this was before isearch highlighted matches etc. It would be grea= t if this could be restored once again!
* Process output: In early versions of fo= llow-mode, it could be used with any process. This was accomplished using `= defadvice' on a handful of process-related functions. At some point in = time, this system was replaced with a system specific to comint and compila= tion buffers -- as part of the great defadvice sweep. Personally, I would l= ike to Emacs to provide `pre-process-output-functions' and `post-proces= s-output-functions', allowing packages like follow-mode to perform what= ever action they would like to the output of any process.

* If a user have colu= mns with different widths, follow-mode can't correctly display long lin= es stretching from one window to the next. The reason for this is that the = start position can't be placed at an arbitrary location on a long line,= only on positions that are a multiple of the column width. I don't see= any way to solve this without modifying the display engine.

* Automatic tests: T= hese should verify the basic functionality, that the windows are aligned pr= operly. That moving the point down in one window would move it to the next.= All follow-mode-specific commands etc.


=
Anyway, this is a dire wish-list and I fee= l that I, unfortunately, presently can't contribute to it. When it come= s to Emacs responsibilities, I have taken over the NextStep port after Jan = Dj=C3=A4rvs resignation, and on a personal level I have a full time job and= I have two small children and a third due in about a week (if all goes wel= l). Anyway, I'm glad that Alan has taken this bull by the horn. However= , feel free to ask questions or discuss implementation ideas regarding this= .

Sinc= erely,
=C2=A0 =C2=A0 Anders Lindgren
<= div class=3D"gmail_extra">
--001a1147fa52257de10524c3054d--