From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
Subject: bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise
Date: Sat, 29 Sep 2018 11:25:20 +0000 [thread overview]
Message-ID: <20180929112520.GA5008@ACM> (raw)
In-Reply-To: <83sh1s61mj.fsf@gnu.org>
Hello, Eli.
On Sat, Sep 29, 2018 at 13:26:12 +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Sep 2018 08:35:51 +0000
> > Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > > Follow-mode is special in this regard, because with it, showing a
> > > partial line is not a flaw, as that same line will be fully visible in
> > > the next window, and follow-mode actually switches to that next
> > > window. So we need to tell the display engine to behave specially in
> > > this case. I suggested 2 ways of doing that, the simple one actually
> > > does what you expected, i.e. the force_start flag will win.
> > This feels a bit like a workaround
> That's because it _is_ a workaround. But it's a safe one, so it can
> easily go into emacs-26, and solve most of this old bug. More complex
> solutions will have to go to master and wait till Emacs 27. WDYT
> about that?
I think my proposal from my last post is also safe and simple, it being
a mere 5 lines (not counting comments) in one place in follow.el, and
which is self contained. It ranks in complexity between your two
proposals.
> > Also, the user can change make-cursor-line-fully-visible at any
> > time, unlikely though this is.
> Users can shoot themselves in the foot in many ways, but that's their
> funerals. We can always tell them "don't do that".
Yes. This thing is a customisable option, however.
> > I propose the following solution: at the critical piece of code in
> > follow mode's post-command-hook, follow mode should check
> > make-cursor-...-p, and if non-nil, determine, using
> > pos-visible-in-window-p whether the cursor is in the last partial line.
> > If so, move it one line higher. In follow-mode, the positions of point
> > in the non-selected windows are fairly random anyway.
> Why is this better than what I proposed?
It is simpler than allowing m-c-l-f-v be a function (which would involve
amendments in xdisp.c, I think) yet still observes the intent of that
variable, particularly on the last follow-mode window.
> I proposed to allow make-cursor-line-fully-visible to have a value
> that is a function, and let follow-mode define that function
> accordingly, to make Emacs behave as if the last window in the group
> had make-cursor-line-fully-visible set to the default or what the user
> set it, and nil in all other windows under follow-mode. I think that
> every solution that lets the display engine do the job is cleaner than
> trying to force the display engine do that same job.
Maybe. But follow mode is already a big fight with the display engine.
(I can't see how it could be otherwise, except by enhancing the display
engine to support multiple windows natively.)
> Besides, your proposal has the annoying effect of causing a
> micro-scroll near the end of the window.
I don't see this (on GNU/Linux/X with GTK+ 3.22.30).
> > As an aside, make-cursor-...-p doesn't appear in either the Emacs manual
> > or the Elisp manual, and the documentation for set-window-position
> > doesn't mention it. I can feel a documentation writing urge coming on.
> We don't document every variable, and this one is unlikely to be
> modified from the default. So I see no reason for the urge.
I was also thinking of amending the doc for set-window-start, to alert
users to the possibility of a nil NOFORCE argument failing to prevent
scrolling. If make-cursor-line-fully-visible were to become,
optionally, a function there would be more reason to document it in the
manual.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2018-09-29 11:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 22:49 bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise Allen Li
2018-09-27 6:04 ` Eli Zaretskii
2018-09-27 8:06 ` Eli Zaretskii
2018-09-28 20:31 ` Alan Mackenzie
2018-09-28 21:27 ` Eli Zaretskii
2018-09-29 8:35 ` Alan Mackenzie
2018-09-29 10:26 ` Eli Zaretskii
2018-09-29 11:25 ` Alan Mackenzie [this message]
2018-09-29 13:47 ` Eli Zaretskii
2018-09-29 13:56 ` Eli Zaretskii
2018-09-29 14:48 ` Alan Mackenzie
2018-09-29 15:06 ` Eli Zaretskii
2018-09-29 20:25 ` Alan Mackenzie
2018-09-30 5:30 ` Eli Zaretskii
2018-09-30 11:16 ` Eli Zaretskii
2018-09-30 12:16 ` Alan Mackenzie
2018-09-30 12:56 ` Eli Zaretskii
2018-09-30 14:09 ` Alan Mackenzie
2018-09-30 17:00 ` Eli Zaretskii
2018-10-01 12:33 ` Alan Mackenzie
2018-10-01 13:47 ` Eli Zaretskii
2018-10-15 9:23 ` Alan Mackenzie
2018-10-15 15:07 ` Eli Zaretskii
2018-10-15 17:26 ` Alan Mackenzie
2018-10-15 18:02 ` Eli Zaretskii
2018-09-30 11:02 ` Alan Mackenzie
2018-09-30 11:24 ` Eli Zaretskii
2018-09-30 13:55 ` Alan Mackenzie
2018-10-17 10:17 ` 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=20180929112520.GA5008@ACM \
--to=acm@muc.de \
--cc=32848@debbugs.gnu.org \
--cc=andlind@gmail.com \
--cc=darkfeline@felesatra.moe \
--cc=eliz@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.