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: Wed, 18 Nov 2015 20:23:42 +0100 Message-ID: References: <564A3292.2050807@gmx.at> <87fv05phpw.fsf@mail.linkov.net> <83h9kj9ov0.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11415aca955b6e0524d594c6 X-Trace: ger.gmane.org 1447874663 31259 80.91.229.3 (18 Nov 2015 19:24:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2015 19:24:23 +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 Wed Nov 18 20:24:14 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 1Zz8Kz-0008Tp-CP for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 20:24:13 +0100 Original-Received: from localhost ([::1]:37903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz8Ky-0001pf-MI for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Nov 2015 14:24:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz8Kr-0001oy-ST for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 14:24:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz8Ko-0002eB-JN for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 14:24:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz8Ko-0002e6-GU for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 14:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zz8Ko-0002rl-7e for bug-gnu-emacs@gnu.org; Wed, 18 Nov 2015 14:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Nov 2015 19:24: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.144787462910995 (code B ref 19576); Wed, 18 Nov 2015 19:24:02 +0000 Original-Received: (at 19576) by debbugs.gnu.org; 18 Nov 2015 19:23:49 +0000 Original-Received: from localhost ([127.0.0.1]:43710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz8KZ-0002rD-37 for submit@debbugs.gnu.org; Wed, 18 Nov 2015 14:23:48 -0500 Original-Received: from mail-vk0-f42.google.com ([209.85.213.42]:34473) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zz8KV-0002r1-KO for 19576@debbugs.gnu.org; Wed, 18 Nov 2015 14:23:45 -0500 Original-Received: by vkfr145 with SMTP id r145so1972537vkf.1 for <19576@debbugs.gnu.org>; Wed, 18 Nov 2015 11:23:43 -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=guqVRJQ2SMkV2oIh++n+VQ1QnA969CQLMkymEVsqFPc=; b=uARnBFrb6HcqDB1bzu98K4ALLRbXuS8ubtjCekfWJEnBAn8RiwBilmHaBgbhjsYJuG lqXgEgBKg16nYlBIj8cLvZqi/mZ4WKDkViSFurpqMLtTfhKOF0xp6axvUWklhDwIQ6uC cuQKu9T9BdM1PyqmL55YTe9pYqnlue1iWHnii8j/0C3rlL01rg1eYCT6BPaRpNCTvwNF WaNw92zgB7qbaiviDXEXP6U2Da/7oELyjtANesHmOs056t/eiIGWf/rVZDdGNu1xvAHf 9vt+4UOzVyEGjhGQyW0ZAS38ifTJNKfLaBqjt1htbSY2dLI0YnkgJFEW4wV3ECUFJNEm 3ZNA== X-Received: by 10.31.169.142 with SMTP id s136mr447982vke.149.1447874623001; Wed, 18 Nov 2015 11:23:43 -0800 (PST) Original-Received: by 10.31.210.133 with HTTP; Wed, 18 Nov 2015 11:23:42 -0800 (PST) In-Reply-To: <83h9kj9ov0.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:108880 Archived-At: --001a11415aca955b6e0524d594c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! 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. This is what `follow-avoid-tail-recenter' is designed to avoid. (For follow-mode, this mean that the illusion of one tall window is broken, when the visible text doesn't reach the rightmost window.) As I have mentioned before, I would like to have a hook variable that the display engine can call when doing this. Packaged like follow-mode can use this to override the default behaviour. > > * 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? > A package should never turn follow-mode on, but it should respect it when it is activated in buffer! Effectively, if a package wants to display a line in a buffer, and that line is visible in any of the windows in a follow-mode window group, that window should be used regardless if it was the window that was selected before. "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.) > * When follow-mode is enabled, there is a noticeable lag when updating th= e > > region. You can see this by pressing C-c SPACE and holding the up or do= wn > > 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. > Unfortunately, I won't be able to work on this. We are expecting a baby any day now and when it comes to Emacs-related activitied I have picked up where Jan Dj=C3=A4rv left of regarding the NextStep port. Besides, this is more of a minor irritation point rather than showstopper, so it might just as well wait. > * 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 woul= d > > 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. In my original follow-mode implementation, the process filter functions were advices so that all process output were passed through follow-modes own filter functions that aligned the windows and passed the output the real filter functions. The effect was that all process buffer, regardless of which system they used, worked with follow mode. At some point in time it was decided that `defavice' should not be used and this system was replaced with a simpler system only working with compilation and comint buffers. If generic process output hooks follow-mode could once again work for all processes, and in a much cleaner way. I can see other packages taking advantage of this, like packages that would color output or strip away parts of the output etc. > * 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 f= or > > this is that the start position can't be placed at an arbitrary locatio= n > 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. > In most cases this is the sane thing to do, I guess. 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. > 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. -- Anders --001a11415aca955b6e0524d594c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

I don't understand why

=C2=A0 =C2=A0 (set-window-start WINDOW POS t)

is not sufficient.=C2=A0 It does force the display engine to honor the
window-start position requested by the call; no recentering will take
place.=C2=A0 You say you "would prefer if it was possible to tell the<= br> display engine to leave some windows alone", but that's exactly wh= at
the above call does, wrt the starting position of the window.=C2=A0 So why<= br> isn't it sufficient?

If "pos&q= uot; is point-max, the window will be recentered after a while. You can try= by entering the following in the *scratch* buffer:

=C2=A0(set-window-start (selected-window) (point-max) t)

Place the cursor at the end of the buffer and evaluate the express= ion using M-C-x.

If you work with Emacs for a whil= e, you will notice that the content of the *scratch* buffer will be visible= after a while. This is what `follow-avoid-tail-recenter' is designed t= o avoid. (For follow-mode, this mean that the illusion of one tall window i= s broken, when the visible text doesn't reach the rightmost window.)

As I have mentioned before, I would like to have a h= ook variable that the display engine can call when doing this. Packaged lik= e follow-mode can use this to override the default behaviour.

=C2=A0
&g= t; * Make it easier for other packages to use it. By this I mean packages t= hat
> display information, like "grep", should be able to use foll= ow mode to
> display a buffer using side by side windows.

But Follow is a minor-mode, right?=C2=A0 So why cannot Grep etc. jus= t turn
it on?

A package should never turn foll= ow-mode on, but it should respect it when it is activated in buffer!
<= div>
Effectively, if a package wants to display a line in a b= uffer, and that line is visible in any of the windows in a follow-mode wind= ow group, that window should be used regardless if it was the window that w= as selected before.

"Grep" does in fact = do the right thing, the grep hit arrow move across the visible windows nice= ly.

A package like "ispell" behaves beha= ves worse since it, somehow, prevent follow-mode from doing it's job. T= he effect is that the windows are no longer aligned (i.e. some lines are vi= sible in more than one window, or some lines between two windows are no lon= ger shown.)

Another thing that makes things diffic= ult is that the *selected* window group is aligned by follow-mode. If a pac= kage wants to show (but not select) another buffer, the windows of the othe= r 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 alig= ned (if follow-mode was active). I ended up calling follow-post-command-hoo= k directly, which really isn't a good practice.)


> * When follow-mode is e= nabled, there is a noticeable lag when updating the
> region. You can see this by pressing C-c SPACE and holding the up or d= own
> key. When follow-mode is disabled, the region is updated as fast as th= e
> 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.=C2=A0 Please look into this, it would be good to fix this before Emacs 25.1 is out.
<= /blockquote>

Unfortunately, I won't be able to work = on this. We are expecting a baby any day now and when it comes to Emacs-rel= ated activitied I have picked up where Jan Dj=C3=A4rv left of regarding the= NextStep port.

Besides, this is more of a minor i= rritation point rather than showstopper, so it might just as well wait.


> * Pr= ocess 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 repl= aced
> 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&= #39;,
> allowing packages like follow-mode to perform whatever action they wou= ld
> like to the output of any process.

Such hooks will be almost trivial to provide, I think.=C2=A0 But I d= on't
think I understand what problems would such hooks solve.=C2=A0 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 pr= ompt is at the bottom of the rightmost one, and the rest shows your recent = activity.

Normally, follow-mode use the post-comma= nd-hook to ensure that the windows are aligned. However, when you type some= thing like "ls -lR" in your shell, output will be coming in throu= gh the process system, which is not seen by the post-command-hook.

In my original follow-mode implementation, the process fil= ter functions were advices so that all process output were passed through f= ollow-modes own filter functions that aligned the windows and passed the ou= tput the real filter functions. The effect was that all process buffer, reg= ardless of which system they used, worked with follow mode. At some point i= n time it was decided that `defavice' should not be used and this syste= m was replaced with a simpler system only working with compilation and comi= nt buffers.

If generic process output hooks follow= -mode could once again work for all processes, and in a much cleaner way. I= can see other packages taking advantage of this, like packages that would = color output or strip away parts of the output etc.


> * 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 lo= cation 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 engi= ne.

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.=C2=A0 It uses this assumption in its layout code and decisions.=C2=A0 But when follow-mode us<= br> used in windows of unequal width, that assumption breaks.=C2=A0 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.

In most cases this = is the sane thing to do, I guess.

However, one way to handle this is to respect a= n explicit `set-window-start' position even if the column isn't a m= ultiple of the screen width.


> Thanks for working on this, Martin.=C2=A0 However, I= don't think we should
> install this change.=C2=A0 We call Lisp hooks fr= om many places, including
> maybe a dozen in the display engine.=C2=A0 It ma= kes little sense to make
> only one of them resistant to this kind of probl= ems.=C2=A0 OTOH, if we do
> this everywhere, I feel that we will unduly puni= sh 99.999% percent of
> legitimate users of these hooks just because one of t= hem had a bug.
>
> I think this is a clear b= ug in follow.el, and should be fixed there,
> and nowhere else.=C2=A0 Perhaps= we should also have some prominent warnings
> in the documentation about thi= s 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 o= f the most obscure bugs I have seen when working with Emacs -- trying to fi= gure out why on earth `write-file' would save the wrong buffer was no e= asy task, even with many years of Emacs experience under my belt.

<= /div>
There is a= risk that other package writers will stumble upon similar problems and giv= e up, or write it of as "unexplainable". Ensuring that the caller= saves and restores the state is a very cheap life saver.

=C2=A0 =C2=A0 --= Anders

--001a11415aca955b6e0524d594c6--