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 19:52:35 +0200 Message-ID: <83h9kj9ov0.fsf@gnu.org> References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447869211 5147 80.91.229.3 (18 Nov 2015 17:53:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2015 17:53:31 +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 18:53:16 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 1Zz6uw-00074L-72 for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 18:53:14 +0100 Original-Received: from localhost ([::1]:37324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz6uv-00054v-EU for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 12:53:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz6un-00053V-TL for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:53:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz6uk-0001oP-MG for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:53:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz6uk-0001oK-In for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zz6uk-00070E-2o for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 12:53:02 -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 17:53: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.144786916426882 (code B ref 19576); Wed, 18 Nov 2015 17:53:02 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 17:52:44 +0000 Original-Received: from localhost ([127.0.0.1]:43616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6uS-0006zV-1b for submit@debbugs.gnu.org; Wed, 18 Nov 2015 12:52:44 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:37845) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz6uP-0006zM-WC for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 12:52:43 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NY000200UVCGH00@a-mtaout20.012.net.il> for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 19:52:40 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NY0002OHUZR9370@a-mtaout20.012.net.il>; Wed, 18 Nov 2015 19:52:40 +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:108867 Archived-At: > Date: Tue, 17 Nov 2015 22:15:07 +0100 > From: Anders Lindgren > Cc: martin rudalics , Alan Mackenzie , 19576@debbugs.gnu.org, > Eli Zaretskii > > * The Emacs display engine tries to recenter windows when window-start == > 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. 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? > * 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. But Follow is a minor-mode, right? So why cannot Grep etc. just turn it on? > * 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. I guess follow-mode's post-command-hook interferes with pre-redisplay-functions used to display the region nowadays. Please look into this, it would be good to fix this before Emacs 25.1 is out. > * 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? > * 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. This is a tough nut, and the real problem is not necessarily obvious. The real problem is that the display engine _assumes_ the lines above and below the window edge are of the same pixel width. It uses this assumption in its layout code and decisions. But when follow-mode us used in windows of unequal width, that assumption breaks. This is a very serious problem, because the basic design of the Emacs display engine is that it does its job one window at a time, i.e. it assumes that displaying a window is possible by examining only the data of that single window, and its associated buffer.