bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19576: write-file writes the wrong buffer


From: Alan Mackenzie
Subject: bug#19576: write-file writes the wrong buffer
Date: Tue, 17 Nov 2015 20:02:04 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Anders and Juri.

On Tue, Nov 17, 2015 at 02:55:39AM +0200, Juri Linkov wrote:
> >> Conceptually it should be easy to do that.  Save/restore current buffer,
> >> selected window and frame.  But Alan (concerned about ‘follow-mode’),
> >> Pip (who unfortunately disappeared) and Eli are currently discussing how
> >> to fix ‘window-size-change-functions’ in various other ways as well.

I have a fix for the `window-size-change-functions' problem, which I
posted just over an hour ago (see bug #21869 or #21333).  The fix
consists of only invoking w-s-c-f after any change to the echo area size
has been done.  This might have some relevance for the current bug.  (I
haven't followed the current bug, I'm afraid.)  I really need the
go-ahead from Eli before I can commit the fix to the emacs-25 or master
branch.

> >> I'll try to get the fix of this bug applied there too.

> > This sounds good!

> > If Alan has any thoughts on follow mode, I'd be happy to discuss them. I
> > might need a bit of a refresher, though -- after all, I wrote it more than
> > twenty years ago.

In general, follow mode is wonderful (I use it all the time), but
(i) is not sufficiently integrated with the rest of Emacs, and
(ii) is too difficult to use in an emacs -Q.

By (ii), I mean that manually creating the side by side windows and
doing M-x follow-mode is too cumbersome.
follow-delete-other-windows-and-split is not bound to any key sequence
by default.  I have my own private commands bound to C-c 2, C-c 3, C-c
4, which enable follow mode in 2, 3, and 4 windows.  I also have C-c 0,
which disables follow mode.  I think Emacs should have something like
these in its global key map, say on C-x w f.  Maybe for Emacs 25.2, or
26.1.

By (i), I mean that other lisp programs cannot use follow mode.  For
example, many programs use `window-start' to get the start of the area
they want to work on, when really what they should get is the start of
the "lowest" follow window.

The most painful clash I know of is with Isearch.  It has several places
where it just doesn't work: for example, rather than point moving over
the entire set of windows when you input C-s / C-r, is stays in the one
window and scrolls that window.  I have fixed these problems in
isearch.el, and I gather Juri is reviewing these at the moment.  These
fixes depend on ....

I have enhanced follow mode with the six functions follow-window-start,
follow-window-end, follow-set-window-start,
follow-pos-visible-in-window-p, follow-recenter, and
follow-move-to-window-line, which do what their names suggest, but on
an entire follow mode group of windows.

The new follow-... functions need somehow to be connected with the rest
of the lisp world.  The idea is that another program can call just one
interface which will invoke either window-start or follow-window-start,
depending on whether follow mode is active.  I have, as yet, two
alternative implementations for this:
(i) New functions with names like window*-start (notice the "*"),
written in lisp in window.el;
(ii) Adding an extra parameter to the primitives (mainly in window.c),
so that instead of calling (window-start win), a function would call
(window-start win t).

Buffer local variables to perform the redirection are initialised at
follow-mode start up, and removed at follow-mode termination.

Of the above alternatives, Eli prefers (ii), but I think Juri prefers
(i).

> I hope Alan (Cc:ed) could explain in details all improvements he's doing
> in bug#17453.

> Meanwhile, I'm taking an opportunity to ask you about your intriguing comment
> in follow.el:

> ;; Almost like the real thing, except when the cursor ends up outside
> ;; the top or bottom...  In our case however, we end up outside the
> ;; window and hence we are recentered.  Should we let `recenter' handle
> ;; the point position we would never leave the selected window.  To do
> ;; it ourselves we would need to do our own redisplay, which is easier
> ;; said than done.  (Why didn't I do a real display abstraction from
> ;; the beginning?)

I must say, I've been intrigued by this comment for some while, too.

> What a real display abstraction would you create if you designed
> follow-mode today?

Indeed!

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]