From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
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 16:47:16 +0300 [thread overview]
Message-ID: <83r2hc5sbf.fsf@gnu.org> (raw)
In-Reply-To: <20180929112520.GA5008@ACM> (message from Alan Mackenzie on Sat, 29 Sep 2018 11:25:20 +0000)
> Date: Sat, 29 Sep 2018 11:25:20 +0000
> Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> > > 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.
It isn't anywhere near safe in my book, sorry. Futzing with
window-start and other related variables is a minefield we better not
go into on the release branch.
So if you don't think turning off make-cursor-line-fully-visible in
follow-mode buffers is an okay solution, the solution will have to
wait till Emacs 27, sorry.
> > > 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.
Users of follow-mode can choose whether they want the buggy behavior
we see now or give up fully-visible last line in the last window under
some rare situations (I couldn't even simulate those situations, btw).
> > 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)
The changes in xdisp.c are a no-brainer, we already call several Lisp
functions in several places, and there's infrastructure ready for
that.
> > 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.
This one won't be a "fight" in any sense, just a call to a Lisp
function from C, that's all. And it happens in only one place.
> > 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).
What, you mean you change the window-start and the text doesn't get
scrolled up to display starting from the new window-start? How can
that be?
Or maybe by "it" you meant move point? Then moving point is a side
effect I think we should avoid in this case.
> 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.
Fine with me, although saying in the docs that something doesn't have
to happen with 100% probability doesn't strike me as very helpful.
next prev parent reply other threads:[~2018-09-29 13:47 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
2018-09-29 13:47 ` Eli Zaretskii [this message]
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
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=83r2hc5sbf.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=32848@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=andlind@gmail.com \
--cc=darkfeline@felesatra.moe \
/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).