From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19576: write-file writes the wrong buffer Date: Thu, 19 Nov 2015 17:31:58 +0200 Message-ID: <83vb8y80pd.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> <8337w39gj9.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447947218 10623 80.91.229.3 (19 Nov 2015 15:33:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 15:33:38 +0000 (UTC) Cc: juri@linkov.net, 19576@debbugs.gnu.org, acm@muc.de To: Anders Lindgren Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 19 16:33:26 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 1ZzRDB-0005D4-Qk for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 16:33:26 +0100 Original-Received: from localhost ([::1]:42514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRDB-0003lj-Am for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Nov 2015 10:33:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRCs-0003Pq-Rl for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 10:33:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzRCo-0004Mv-3d for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 10:33:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRCo-0004Mr-0b for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 10:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZzRCn-0000fk-Nz for bug-gnu-emacs@gnu.org; Thu, 19 Nov 2015 10:33:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Nov 2015 15:33: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.14479471392524 (code B ref 19576); Thu, 19 Nov 2015 15:33:01 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 19 Nov 2015 15:32:19 +0000 Original-Received: from localhost ([127.0.0.1]:45085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRC6-0000ee-Hv for submit@debbugs.gnu.org; Thu, 19 Nov 2015 10:32:19 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:63463) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZzRC3-0000eU-P2 for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 10:32:17 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY200B00IUH6S00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Thu, 19 Nov 2015 17:32:14 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY200A2DJ5PQFB0@a-mtaout20.012.net.il>; Thu, 19 Nov 2015 17:32:14 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il 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:108909 Archived-At: > Date: Thu, 19 Nov 2015 07:54:32 +0100 > From: Anders Lindgren > Cc: Juri Linkov , martin rudalics , Alan Mackenzie , > 19576@debbugs.gnu.org > > 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. I could only understand that if whatever you do following a call to set-window-start includes resizing of windows or creation/deletion of windows. Or maybe you meant editing in that window? Even then at least the simple commands I tried don't do that. The display engine generally doesn't do anything unless the screen should change. So if you work outside of the window whose starting point you forced, Emacs should never do anything with that window. > 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. The display engine doesn't recenter because it needs recentering. Recentering is a means to achieve a specific goal, it isn't the goal itself. The goal is to determine the window's starting point when the previous starting point cannot be used for some reason. This is a crucial part of the display of each window -- without determining window-start, the display engine cannot proceed with displaying the window. So you cannot tell the display engine not to recenter, because it won't know how to proceed. I could understand if you'd ask for a way to tell the display engine not to try redisplaying a certain window. But disabling just the recentering is not in general possible, AFAIU. (Actually, Emacs doesn't necessarily recenter: user options like scroll-conservatively dictate how it finds a good candidate for window-start, and recentering is just the simplest and the fastest method. But this doesn't seem to matter for the purposes of this discussion, since you'd like to suppress _any_ kind of scrolling, I believe.) > 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. I'm not sure I understand: how many lines are visible is determined by the window height and the height of the font(s) used by the text displayed there. Once these parameters are fixed, you cannot control the number of lines visible in a window, except by changing the window height. What am I missing? > 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. ispell and gdb-mi come to mind, and there are probably more examples. > 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. Thanks.