From: Alan Mackenzie <acm@muc.de>
To: Anders Lindgren <andlind@gmail.com>, emacs-devel@gnu.org
Subject: The future of Follow Mode - a proposal.
Date: Thu, 18 Feb 2016 19:56:30 +0000 [thread overview]
Message-ID: <20160218195630.GA2697@acm.fritz.box> (raw)
Hello, Anders and Emacs.
Although Follow Mode has served extremely well for several decades, it has
several shortcomings which make it less good than it might be:
(i) It is not particularly fast - synchronising the several pertinent windows
can take several tenths of a second, even on modern hardware. One reason
for this is that Follow Mode and the display engine fight eachother, and
several strategems which are necessary for FM to win (such as explicitly
calling `redisplay' from the post-command-hook) are nevertheless suboptimal.
(ii) Where adjacent windows are of unequal width (this is the normal case), a
continued line is displayed incorrectly when it straddles two windows:
either one or more characters are displayed twice, or they are not displayed
at all (depending on which window is the wider one). This is
extraordinarily difficult to fix with the current display engine and
follow.el.
(iii) Each Follow Mode window has its own individual mode line, although
Follow Mode's aim is to create the illusion of a single multi-column window.
Often important info is truncated, due to the narrowness of a typical FM
window. It would be better to have a single mode line stretching across the
entire screen.
I propose moving much of Follow Mode's mechanism into our C code, in
particular, into window.c and xdisp.c.
In window.c/h would appear a new `struct wgroup' which would administer Follow
Mode window groups. It would contain details of the buffer it's
administering, the frame, and pointers to the first and last of the FM
windows. `struct window' would be amended to contain forward and backward
links, allowing us to create a chain of the FM windows, also to contain a
pointer to the wgroup. In addition, `struct wgroup' would note which of its
windows is the current/active one.
Also in window.c would come infrastructure for creating and administering
`struct wgroups'. Such functions as `pop-to-buffer' would typically need to
remove a window from the `struct wgroup' before repurposing it for the new
buffer.
The first shock: `select-window' would be amended, such that attempting to
select any window in a wgroup would result in the current/active window in the
group actually being selected instead. This would go a long way towards
maintaining the illusion of a single multi-column window. An additional
&optional parameter would be given to `select-window' meaning "select THIS
window, no matter what", for the use of lower level routines.
`vertical-motion' would need a substantial rethink, since it would have to
work in a "window" whose width varies. There will likely be several other
such functions needing amendment. But not many.
Most of the difficult work would be within xdisp.c. Any form of scrolling is
going to be tricky to implement, as indeed it is in follow.el. Moving over
the boundary of two windows will mean (?)xdisp.c having to select-window where
it currently scrolls a window. More generally, the scrolling/point-moving
bits would need to be amended.
Creating a unified mode line seems tricky, given the way it's currently done
in xdisp.c. (It merely reserves the final line of the window, and writes
there.) There may be better ways to achieve the single mode line, but one way
would be to implement mode lines as windows in their own right, thus giving
them scope to be somewhere else other than squashed up into a window's last
line. This would also enable several FM windows to share a single mode line.
Comments?
--
Alan Mackenzie (Nuremberg, Germany).
next reply other threads:[~2016-02-18 19:56 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 19:56 Alan Mackenzie [this message]
2016-02-18 20:24 ` The future of Follow Mode - a proposal Eli Zaretskii
2016-02-19 14:25 ` Alan Mackenzie
2016-02-19 14:34 ` martin rudalics
2016-02-19 16:12 ` Eli Zaretskii
2016-02-19 16:08 ` Eli Zaretskii
2016-02-19 18:18 ` Alan Mackenzie
2016-02-19 18:45 ` Eli Zaretskii
2016-02-20 12:44 ` Alan Mackenzie
2016-02-20 13:05 ` Eli Zaretskii
2016-02-23 23:11 ` Alan Mackenzie
2016-02-24 3:57 ` Stefan Monnier
2016-02-24 17:14 ` Eli Zaretskii
2016-02-24 18:57 ` Stefan Monnier
2016-02-24 19:19 ` Eli Zaretskii
2016-02-24 20:10 ` Stefan Monnier
2016-02-24 20:21 ` Eli Zaretskii
2016-02-25 0:30 ` Stefan Monnier
2016-02-25 16:28 ` Eli Zaretskii
2016-02-25 16:46 ` Stefan Monnier
2016-02-25 17:29 ` Eli Zaretskii
2016-02-25 20:30 ` Alan Mackenzie
2016-02-25 20:57 ` Alan Mackenzie
2016-02-25 21:10 ` Stefan Monnier
2016-02-25 22:17 ` Alan Mackenzie
2016-02-28 16:40 ` Stefan Monnier
2016-02-24 18:34 ` Eli Zaretskii
2016-02-25 20:18 ` Alan Mackenzie
2016-02-19 14:56 ` Anders Lindgren
2016-02-19 16:30 ` Eli Zaretskii
2016-02-19 18:45 ` Alan Mackenzie
2016-02-18 20:41 ` John Yates
2016-02-19 16:21 ` Alan Mackenzie
2016-02-19 16:32 ` Eli Zaretskii
2016-02-19 19:25 ` John Yates
2016-02-19 20:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160218195630.GA2697@acm.fritz.box \
--to=acm@muc.de \
--cc=andlind@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).