[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19576: write-file writes the wrong buffer
From: |
Eli Zaretskii |
Subject: |
bug#19576: write-file writes the wrong buffer |
Date: |
Wed, 18 Nov 2015 22:52:26 +0200 |
> Date: Wed, 18 Nov 2015 20:23:42 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: Juri Linkov <juri@linkov.net>, martin rudalics <rudalics@gmx.at>, Alan
> Mackenzie <acm@muc.de>,
> 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.
- bug#19576: write-file writes the wrong buffer, (continued)
- bug#19576: write-file writes the wrong buffer, martin rudalics, 2015/11/20
- bug#19576: write-file writes the wrong buffer, Eli Zaretskii, 2015/11/20
- bug#19576: write-file writes the wrong buffer, martin rudalics, 2015/11/20
- bug#19576: write-file writes the wrong buffer, Eli Zaretskii, 2015/11/20
- bug#19576: write-file writes the wrong buffer, martin rudalics, 2015/11/20
- bug#19576: write-file writes the wrong buffer, Alan Mackenzie, 2015/11/20
- bug#19576: write-file writes the wrong buffer, Eli Zaretskii, 2015/11/20
- bug#19576: write-file writes the wrong buffer, Anders Lindgren, 2015/11/17
- bug#19576: write-file writes the wrong buffer, Eli Zaretskii, 2015/11/18
- bug#19576: write-file writes the wrong buffer, Anders Lindgren, 2015/11/18
- bug#19576: write-file writes the wrong buffer,
Eli Zaretskii <=
- bug#19576: write-file writes the wrong buffer, John Wiegley, 2015/11/18
- bug#19576: write-file writes the wrong buffer, Anders Lindgren, 2015/11/19
- bug#19576: write-file writes the wrong buffer, Eli Zaretskii, 2015/11/19
- bug#19576: write-file writes the wrong buffer, Johan Bockgård, 2015/11/22
- bug#19576: write-file writes the wrong buffer, Johan Bockgård, 2015/11/22
- bug#19576: write-file writes the wrong buffer, Eli Zaretskii, 2015/11/22
- bug#19576: write-file writes the wrong buffer, martin rudalics, 2015/11/17
- bug#19576: write-file writes the wrong buffer, Anders Lindgren, 2015/11/17
- bug#19576: write-file writes the wrong buffer, Eli Zaretskii, 2015/11/18
- bug#19576: write-file writes the wrong buffer, martin rudalics, 2015/11/19