GNU bug report logs - #32848
26.1; follow-mode cursor move breaks with frame-resize-pixelwise

Previous Next

Full log

Message #31 received at 32848 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 32848 <at> debbugs.gnu.org, andlind <at> gmail.com, darkfeline <at> felesatra.moe
Subject: Re: 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 <at> felesatra.moe, andlind <at> gmail.com, 32848 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.