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: Wed, 18 Nov 2015 22:52:26 +0200 Message-ID: <8337w39gj9.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447880007 25973 80.91.229.3 (18 Nov 2015 20:53:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2015 20:53:27 +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 Wed Nov 18 21:53: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 1Zz9j4-0003co-GJ for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 21:53:10 +0100 Original-Received: from localhost ([::1]:38362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz9j3-0003Tq-Qz for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 15:53:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz9iz-0003TN-84 for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 15:53:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz9iw-0000AC-1R for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 15:53:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz9iv-0000A4-Uq for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 15:53:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zz9iv-0006vy-NH for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 15:53: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: Wed, 18 Nov 2015 20:53: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.144787997726645 (code B ref 19576); Wed, 18 Nov 2015 20:53:01 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 20:52:57 +0000 Original-Received: from localhost ([127.0.0.1]:43789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz9iq-0006vg-VW for submit@debbugs.gnu.org; Wed, 18 Nov 2015 15:52:57 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:57540) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz9iV-0006uy-NB for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 15:52:55 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NY100A002W5D300@mtaout28.012.net.il> for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 22:51:28 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY1006KB39SB140@mtaout28.012.net.il>; Wed, 18 Nov 2015 22:51:28 +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:108886 Archived-At: > Date: Wed, 18 Nov 2015 20:23:42 +0100 > From: Anders Lindgren > Cc: Juri Linkov , martin rudalics , Alan Mackenzie , > 19576@debbugs.gnu.org > > I don't understand why > > (set-window-start WINDOW POS t) > > is not sufficient. It does force the display engine to honor the > window-start position requested by the call; no recentering will take > place. You say you "would prefer if it was possible to tell the > display engine to leave some windows alone", but that's exactly what > the above call does, wrt the starting position of the window. So why > isn't it sufficient? > > > If "pos" is point-max, the window will be recentered after a while. You can try > by entering the following in the *scratch* buffer: > > (set-window-start (selected-window) (point-max) t) > > Place the cursor at the end of the buffer and evaluate the expression using > M-C-x. > > If you work with Emacs for a while, you will notice that the content of the > *scratch* buffer will be visible after a while. Is the M-C-x part important? (I used M-: instead.) If it isn't, then 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. > As I have mentioned before, I would like to have a hook variable that the > display engine can call when doing this. When doing what? > Packaged like follow-mode can use this to override the default > behaviour. The default behavior in what aspect? > "Grep" does in fact do the right thing, the grep hit arrow move across the > visible windows nicely. > > A package like "ispell" behaves behaves worse since it, somehow, prevent > follow-mode from doing it's job. The effect is that the windows are no longer > aligned (i.e. some lines are visible in more than one window, or some lines > between two windows are no longer shown.) > > Another thing that makes things difficult is that the *selected* window group > is aligned by follow-mode. If a package wants to show (but not select) another > buffer, the windows of the other buffer will not be aligned automatically, and > there is no good interface for this. (In my package `font-lock-studio', a > control buffer is shown in the selected window, but I wanted the source buffer > to be displayed aligned (if follow-mode was active). I ended up calling > follow-post-command-hook directly, which really isn't a good practice.) These all sound like application-level problems to me, not issues with the display engine. At least not in the first approximation. > > * 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. > > Such hooks will be almost trivial to provide, I think. But I don't > think I understand what problems would such hooks solve. Could you > elaborate? > > > Follow mode can be used both in plain source buffers and in process buffers. > Concretely, you can have a *shell* buffer displayed in a number of side by side > windows, where the prompt is at the bottom of the rightmost one, and the rest > shows your recent activity. > > Normally, follow-mode use the post-command-hook to ensure that the windows are > aligned. However, when you type something like "ls -lR" in your shell, output > will be coming in through the process system, which is not seen by the > post-command-hook. 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? > 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. > > Thanks for working on this, Martin. However, I don't think we should > > install this change. We call Lisp hooks from many places, including > > maybe a dozen in the display engine. It makes little sense to make > > only one of them resistant to this kind of problems. OTOH, if we do > > this everywhere, I feel that we will unduly punish 99.999% percent of > > legitimate users of these hooks just because one of them had a bug. > > > > I think this is a clear bug in follow.el, and should be fixed there, > > and nowhere else. Perhaps we should also have some prominent warnings > > in the documentation about this gotcha, so that the probability this > > will happen again becomes lower. > > I don't agree with you on this but I respect your opinion. > > This is one of the most obscure bugs I have seen when working with Emacs -- > trying to figure out why on earth `write-file' would save the wrong buffer was > no easy task, even with many years of Emacs experience under my belt. > > There is a risk that other package writers will stumble upon similar problems > and give up, or write it of as "unexplainable". Ensuring that the caller saves > and restores the state is a very cheap life saver. It's cheap for the "perpetrators", but it distributes the cost among the "innocent". Sorry, I simply cannot agree to such "re-balancing" of guilt. And yes, I know how much time debugging a tricky bug can consume. been there, done that. Still, once the reason is identified, we must find the best place to fix it. Choosing that place frequently involves compromises.