From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: "... the window start at a meaningless point within a line."
Date: Thu, 1 Oct 2015 09:41:38 +0000 [thread overview]
Message-ID: <20151001094138.GA2515@acm.fritz.box> (raw)
In-Reply-To: <83mvw39dp3.fsf@gnu.org>
Hello, Eli.
On Thu, Oct 01, 2015 at 11:48:40AM +0300, Eli Zaretskii wrote:
> > Date: Wed, 30 Sep 2015 20:45:13 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > In the Elisp manual, page "Window Start and End", it's described how, if
> > in (set-window-start x) x is a position not at the start of a line, the
> > display engine will, instead of x, choose some value near x as the
> > window start. Is this really necessary?
> The reason for this is that we want the physical beginning of the line
> (i.e. the character after a newline or at bob) always be aligned at
> the left edge of the window's text area, even if it is currently out
> of view. This prevents annoying horizontal scrolling of long lines
> when the beginning of the line comes into view.
OK. But we're really talking here about where continuation lines start,
not physical BOLs.
> > The particular problem I'm looking at is with Follow Mode, where a pair
> > of adjacent windows are of unequal width. This is a very common
> > scenario - I frequently use Follow Mode with three side by side windows
> > of widths 79, 79, and 80 (as measured by window-body-width).
> > The problem occurs when there's a long line at the bottom of window 2
> > and its continuation line at the top of window 3. The display manager
> > chops off the line in W2 after 78 characters, and inserts a \ sign. It
> > then starts the continuation line in W3 at character 80 (counting from
> > 1), assuming as it does, that the previous line in this window would be
> > 79 characters long. So character 79 appears neither on the first
> > portion of the line in W2, nor in its continuation in W3. This is
> > suboptimal.
> > This problem would not occur if there were a flag to set-window-start
> > meaning "this value really is where I want the window to start, not some
> > beginning of line nearby".
> > How difficult would it be to relax the constraint on window start
> > positions and implement this flag?
> It's not difficult, at least in principle: the recalculation of the
> window-start point is done in a single function. Not sure if it will
> have adverse effects, though. You will surely have that horizontal
> scrolling, but I don't know what other effects will be caused.
I think scrolling such a window one screen line down would cause the
break in the line to have to be repositioned. So it wouldn't be trivial.
> But let me turn the table and ask you: how difficult would it be to
> make sure follow-mode never lets a window end in the middle of a
> continued line?
In the worst case, very difficult. Indeed, with three follow windows,
all of slightly different widths, and a fiendish specially constructed
file, it could be that when you scroll the buffer a single screen line to
deal with a break between W1 and W2, you create the same problem between
W2 and W3. In such a scenario, you might end up scrolling the buffer
quite a long way in the search for no "broken" continued lines at either
boundary. With such a file there might be NO position where there isn't
a break.
In real life? I imagine it's quite common to use Follow Mode with very
narrow windows (say, four at ~60 wide) when the annoyance of continued
lines is less important than seeing all of a long function on the screen
at once. There will then be lots of continued lines, and 3 window
boundaries, W1-W2, W2-W3, W3-W4.
If we were to go this route (of repositioning to avoid line breaks
between follow windows), there would have to be a limit on how far one
could scroll, with a value such as 3. This might have to be a
customisation variable.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2015-10-01 9:41 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 20:45 "... the window start at a meaningless point within a line." Alan Mackenzie
2015-10-01 8:48 ` Eli Zaretskii
2015-10-01 9:41 ` Alan Mackenzie [this message]
2015-10-01 10:16 ` Eli Zaretskii
2015-10-01 11:02 ` Alan Mackenzie
2015-10-01 12:03 ` Eli Zaretskii
2015-10-01 16:35 ` Alan Mackenzie
2015-10-15 18:16 ` Alan Mackenzie
2015-10-15 20:14 ` Eli Zaretskii
2015-10-16 9:55 ` Alan Mackenzie
2015-10-16 10:19 ` Eli Zaretskii
2015-10-16 15:19 ` Alan Mackenzie
2015-10-16 17:26 ` Eli Zaretskii
2015-10-16 20:46 ` David Kastrup
2015-10-17 7:15 ` Eli Zaretskii
2015-10-17 7:56 ` David Kastrup
2015-10-16 21:14 ` Alan Mackenzie
2015-10-16 17:35 ` Eli Zaretskii
2015-10-16 18:12 ` Alan Mackenzie
2015-10-16 18:23 ` Eli Zaretskii
2015-10-16 18:36 ` Eli Zaretskii
2015-10-16 20:12 ` Alan Mackenzie
2015-10-17 8:33 ` Eli Zaretskii
2015-10-17 11:57 ` Alan Mackenzie
2015-10-17 12:34 ` Eli Zaretskii
2015-10-17 13:31 ` Eli Zaretskii
2015-10-17 14:22 ` Eli Zaretskii
2015-10-18 15:00 ` Alan Mackenzie
2015-10-18 17:44 ` Eli Zaretskii
2015-10-19 10:27 ` Alan Mackenzie
2015-10-27 13:40 ` Alan Mackenzie
2015-10-27 17:35 ` Alan Mackenzie
2015-10-27 18:33 ` Eli Zaretskii
2015-10-27 18:23 ` Eli Zaretskii
2015-10-28 8:58 ` Alan Mackenzie
2015-10-28 13:15 ` Alan Mackenzie
2015-10-31 13:21 ` Eli Zaretskii
2015-10-31 21:17 ` Alan Mackenzie
2015-11-01 3:40 ` Eli Zaretskii
2015-11-01 14:45 ` Alan Mackenzie
2015-11-01 15:23 ` Alan Mackenzie
2015-11-01 17:45 ` Eli Zaretskii
2015-11-01 18:07 ` Eli Zaretskii
2015-11-01 18:46 ` Alan Mackenzie
2015-10-18 14:53 ` Alan Mackenzie
2015-10-18 17:46 ` Eli Zaretskii
2015-10-19 10:45 ` Alan Mackenzie
2015-10-19 10:56 ` Eli Zaretskii
2015-10-19 11:24 ` Alan Mackenzie
2015-10-19 11:28 ` Eli Zaretskii
2015-10-19 12:02 ` Alan Mackenzie
2015-10-19 12:33 ` Eli Zaretskii
2015-10-19 13:11 ` Alan Mackenzie
2015-10-19 13:27 ` Eli Zaretskii
2015-10-19 19:15 ` Alan Mackenzie
2015-10-27 13:46 ` Alan Mackenzie
2015-10-17 15:30 ` Alan Mackenzie
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151001094138.GA2515@acm.fritz.box \
--to=acm@muc.de \
--cc=eliz@gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.