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: Thu, 19 Nov 2015 07:54:32 +0100 Message-ID: References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1141b5f22591f40524df3b87 X-Trace: ger.gmane.org 1447916120 26807 80.91.229.3 (19 Nov 2015 06:55:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 06:55:20 +0000 (UTC) Cc: Juri Linkov , 19576@debbugs.gnu.org, Alan Mackenzie To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 19 07:55:12 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 1ZzJ7f-0000Vh-F6 for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 07:55:11 +0100 Original-Received: from localhost ([::1]:39909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzJ7e-0004Y2-Nl for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 01:55:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzJ7a-0004Wo-Vw for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 01:55:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzJ7V-0000ve-Uy for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 01:55:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzJ7V-0000v9-Rd for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 01:55:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZzJ7V-00031b-Id for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 01:55: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: Thu, 19 Nov 2015 06:55: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.144791607611593 (code B ref 19576); Thu, 19 Nov 2015 06:55:01 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 06:54:36 +0000 Original-Received: from localhost ([127.0.0.1]:44122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzJ75-00030u-6Z for submit@debbugs.gnu.org; Thu, 19 Nov 2015 01:54:35 -0500 Original-Received: from mail-vk0-f51.google.com ([209.85.213.51]:35502) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzJ72-00030m-TR for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 01:54:33 -0500 Original-Received: by vkha189 with SMTP id a189so11011213vkh.2 for <19576@debbugs.gnu.org>; Wed, 18 Nov 2015 22:54:32 -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=BnDnO+iBWsZWEX1OhqnmpRjFvMzgmzbaJEKDW9SxjLE=; b=VDDNIcQSwFqQX/d+zFebE1sZZDwFJs9JJu40K9COXvZgFr60LZVIYjaXDrhkPJgYmg NOFbOvnwDqa5bCOMcLgdLwHilfWcPq5kd8YMnh6CDYdHdFtvi3hQJKXvPuSYtbOBxcb1 bS2U5tqbTpGCKklQDEMs034vjRkdPkNS4+P0Xsw3NrpJukixmzCThvNz7u9OZbEqAXRo Gmq46GP32lbiALgN3b+Pyz1K6j+gzKkfnbxdSrzAEMiXY7auGOUUWImKhc1jYqNFX7Gj 6h0R5mY0xwodmr7gOC16SLn60Lj21JzbNmh0acu58mmd6MdKdr08IfnyMeF6jjwavnnb NCuA== X-Received: by 10.31.150.150 with SMTP id y144mr3089737vkd.70.1447916072175; Wed, 18 Nov 2015 22:54:32 -0800 (PST) Original-Received: by 10.31.210.133 with HTTP; Wed, 18 Nov 2015 22:54:32 -0800 (PST) In-Reply-To: <8337w39gj9.fsf@gnu.org> 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:108900 Archived-At: --001a1141b5f22591f40524df3b87 Content-Type: text/plain; charset=UTF-8 Hi, > I don't see any spontaneous recentering after that, so a reproducible > test case will be appreciated. Maybe something that makes the > difference hides behind "work with Emacs for a while", I don't know. > It's hard to give an exact recipe, because the recentering occurs stochastically. Sometimes, it occurs within a few seconds, sometimes within a minute and sometimes the window stays like it is for a long period of time. The fact remains that a window where window-start equals point-max (i.e. a window displaying nothing) do recenter itself from time to time. Today, follow-mode actively prevents this by updating window-start of "tail windows" whenever it gets a change (in the post-command-hook and in all display-related hooks). Clearly, this is not an elegant solution, but in practice it works. My proposal is to modify the display engine so that instead of simply recentering a window, it should call a hook to determine if the recentering should take place. This can be made more of less fancy -- a simple solution would be to return a boolean. A more advances solution could let a lisp function in packages to decide how many lines should be visible. Clearly, this is not something that would affect efficiency negatively as this would be called relative seldom, maybe once a minute, and only if the hook variable is non-nil. In fact, it will have a positive effect on efficiency as the current solution isn't very efficient. Anyway, this is not something that we have to change. The current solution, albeit clumsy, have been working for 20 years. > These all sound like application-level problems to me, not issues with > the display engine. At least not in the first approximation. Yes, I agree on this. The list I originally mailed contained all follow-mode related thoughts, not just the display-engine related. Doesn't this mean that you need a way to hook buffer text changes? > Hooking processes is not necessarily what you want, since a process > filter could eat up the output completely and not show it in any > window, in which case follow-mode shouldn't be bothered. Right? > Right. However, the difference is rather academic since it would probably few cases where a prior filter would eat all output. > However, one way to handle this is to respect an explicit > `set-window-start' > > position even if the column isn't a multiple of the screen width. > > Ask Alain how easy that is. > > I'm telling you: this is the tip of a huge iceberg. The display > engine was never designed to handle windows whose redisplay depends on > other windows. OK, lets leave it as it is for now. When it comes to bug#19576 (write-file saves the wrong buffer). As both John and Eli think this shouldn't be fixed in the Emacs core, I will correct the code in follow-mode and (if needed) update the documentation to warn others of the dragons in these waters. Anyway, I will pull out the this follow-mode discussion, partly because I feel it has taken the focus away from the work Alan is doing, and partly for personal reasons. The little time I have for Emacs-related work, I will focus on NextStep issues. Sincerely, Anders Lindgren --001a1141b5f22591f40524df3b87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
I don't see any spontaneous recentering after that, so a reproducible test case will be appreciated.=C2=A0 Maybe something that makes the
difference hides behind "work with Emacs for a while", I don'= t know.

It's hard to give an exact = recipe, because the recentering occurs stochastically. Sometimes, it occurs= within a few seconds, sometimes within a minute and sometimes the window s= tays like it is for a long period of time.

The fac= t remains that a window where window-start equals point-max (i.e. a window = displaying nothing) do recenter itself from time to time.

Today, follow-mode actively prevents this by updating window-start = of "tail windows" whenever it gets a change (in the post-command-= hook and in all display-related hooks). Clearly, this is not an elegant sol= ution, but in practice it works.

My proposal is to= modify the display engine so that instead of simply recentering a window, = it should call a hook to determine if the recentering should take place. Th= is can be made more of less fancy -- a simple solution would be to return a= boolean. A more advances solution could let a lisp function in packages to= decide how many lines should be visible.

Clearly,= this is not something that would affect efficiency negatively as this woul= d be called relative seldom, maybe once a minute, and only if the hook vari= able is non-nil. In fact, it will have a positive effect on efficiency as t= he current solution isn't very efficient.

Anyw= ay, this is not something that we have to change. The current solution, alb= eit clumsy, have been working for 20 years.


> These all sound like application-level problems to me, not is= sues with
> the display engine.=C2=A0 At least not in the firs= t approximation.

Yes, I agree on this. The list I = originally mailed contained all follow-mode related thoughts, not just the = display-engine related.


Doesn't this mean that you need a way to hook buffer text changes?
Hooking processes is not necessarily what you want, since a process
filter could eat up the output completely and not show it in any
window, in which case follow-mode shouldn't be bothered.=C2=A0 Right?

Right. However, the difference is rather= academic since it would probably few cases where a prior filter would eat = all output.


> = However, one way to handle this is to respect an explicit `set-window-start= '
> position even if the column isn't a multiple of the screen width.<= br>
Ask Alain how easy that is.

I'm telling you: this is the tip of a huge iceberg.=C2=A0 The display engine was never designed to handle windows whose redisplay depends on
other windows.

OK, lets leave it as it is f= or now.


When it comes to bug#19576 = (write-file saves the wrong buffer). As both John and Eli think this should= n't be fixed in the Emacs core, I will correct the code in follow-mode = and (if needed) update the documentation to warn others of the dragons in t= hese waters.

Anyway, I will pull out the this foll= ow-mode discussion, partly because I feel it has taken the focus away from = the work Alan is doing, and partly for personal reasons. The little time I = have for Emacs-related work, I will focus on NextStep issues.

Sincerely,
=C2=A0 =C2=A0 Anders Lindgren
<= /div>

--001a1141b5f22591f40524df3b87--