[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelw
From: |
Eli Zaretskii |
Subject: |
bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise |
Date: |
Sat, 29 Sep 2018 16:47:16 +0300 |
> 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.
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Allen Li, 2018/09/26
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/27
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/27
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Alan Mackenzie, 2018/09/28
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/28
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Alan Mackenzie, 2018/09/29
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/29
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Alan Mackenzie, 2018/09/29
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise,
Eli Zaretskii <=
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/29
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Alan Mackenzie, 2018/09/29
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/29
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Alan Mackenzie, 2018/09/29
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/30
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/30
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Alan Mackenzie, 2018/09/30
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/30
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Alan Mackenzie, 2018/09/30
- bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise, Eli Zaretskii, 2018/09/30