bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Allen Li]

Moving the cursor off the bottom of the window with follow-mode enabled
doesn't move to the other window properly if frame-resize-pixelwise is
set and a partial line is visible.

Reproduce:

0. (Must be running X and GUI Emacs.  A big/wide monitor helps.)
1. Save a long text file:

  for i in $(seq 1 300); do echo $i >> /tmp/tmp; done

2. emacs -Q
3. M-: (setq frame-resize-pixelwise t) RET
4. C-x 5 2 (new frame so it picks up the new frame setting)
5. C-x C-f /tmp/tmp RET
6. M-x follow-mode RET
7. C-x 3
8. Resize the frame so that half of a line is visible at the bottom of
the window.
9. Hold C-n to move the cursor down past the bottom of the current
window.

Expected:

The cursor/window focus moves to the next window per follow-mode.

Actual:

The cursor/window focus moves to the next window, then on the next C-n
jumps back to the previous window.  This appears to be because moving
the cursor onto the final half line in the window triggers both:

1. follow-mode to move the cursor/window focus to the next window.
2. The cursor moved off the edge of the current window, causing the
current window to scroll and recenter around the cursor.
3. This makes the position of the "shared" follow-mode cursor visible once
   again in the first window, causing focus to jump back to the first window.

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.24), modified by Debian
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Debian GNU/Linux rodete (upgraded from: Ubuntu 14.04 LTS)

Configured using:
 'configure --build x86_64-linux-gnu --build x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/google-emacs:/etc/emacs:/usr/local/share/emacs/26.1+gg1+9/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1+gg1+9/site-lisp:/usr/share/emacs/site-lisp
 --with-crt-dir=/usr/lib/x86_64-linux-gnu --disable-build-details
 --disable-silent-rules --with-modules GOOGLE_VERSION=26.1+gg1+9
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2
 -fdebug-prefix-map=/tmpfs/build-debs.ryDbLk/emacs-26.1+gg1+9=.
-fstack-protector-strong
 -Wformat -Werror=format-security -Wall' LDFLAGS=-Wl,-z,relro
 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'OBJCFLAGS=-g -O2
 -fdebug-prefix-map=/tmpfs/build-debs.ryDbLk/emacs-26.1+gg1+9=.
-fstack-protector-strong
 -Wformat -Werror=format-security''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES THREADS JSON LCMS2

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

unarchive 8390
reopen 8390
forcemerge 8390 32848
thanks

> From: Allen Li <darkfeline@felesatra.moe>
> Date: Wed, 26 Sep 2018 15:49:15 -0700
> 
> Moving the cursor off the bottom of the window with follow-mode enabled
> doesn't move to the other window properly if frame-resize-pixelwise is
> set and a partial line is visible.

Yes, this is bug#8390 (which was fixed in Emacs 24.3, but later became
broken again).  I've reopen it now.

Thanks.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> From: Allen Li <darkfeline@felesatra.moe>
> Date: Wed, 26 Sep 2018 15:49:15 -0700
> 
> Moving the cursor off the bottom of the window with follow-mode enabled
> doesn't move to the other window properly if frame-resize-pixelwise is
> set and a partial line is visible.

It seems like setting make-cursor-line-fully-visible to nil solves the
problem.  Could you try that for a while, and see if this has any
adverse effects?

Alan and Anders: does setting this variable to nil in buffers under
follow-mode sounds like an okay solution?  It might mean that in some
rare cases the user will see the current line only partially (only in
the last window in the group).  If you think this is OK, we could
arrange for that variable to be set locally as part of turning on
follow-mode.

A more complex solution would be to allow
make-cursor-line-fully-visible have a value that is a function, which
follow-mode will define in a way that will only allow
partially-visible current line in a window if it is not the last one
in the order returned by follow-all-followers.

Comments?

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Thu, Sep 27, 2018 at 11:06:20 +0300, Eli Zaretskii wrote:
> > From: Allen Li <darkfeline@felesatra.moe>
> > Date: Wed, 26 Sep 2018 15:49:15 -0700

> > Moving the cursor off the bottom of the window with follow-mode enabled
> > doesn't move to the other window properly if frame-resize-pixelwise is
> > set and a partial line is visible.

> It seems like setting make-cursor-line-fully-visible to nil solves the
> problem.  Could you try that for a while, and see if this has any
> adverse effects?

> Alan and Anders: does setting this variable to nil in buffers under
> follow-mode sounds like an okay solution?  It might mean that in some
> rare cases the user will see the current line only partially (only in
> the last window in the group).  If you think this is OK, we could
> arrange for that variable to be set locally as part of turning on
> follow-mode.

> A more complex solution would be to allow
> make-cursor-line-fully-visible have a value that is a function, which
> follow-mode will define in a way that will only allow
> partially-visible current line in a window if it is not the last one
> in the order returned by follow-all-followers.

> Comments?

The cause of this is this:
(i) The C-n moves point from the last full line of LH window (L33) to
partial line in LH window (L34).
(ii) Follow Mode's post-command-hook determines that point should move
to the RH window, and sets up the windows correctly for this.
(iii) To try to avoid the LH window scrolling, follow mode does this (at
follow-adjust-window L+94:

          ;; If a new window was selected, make sure that the old is
          ;; not scrolled when point is outside the window.
          (unless (eq win (selected-window))
            (let ((p (window-point win)))
              (set-window-start win (window-start win) nil)
              (set-window-point win p))))

Here, `win' is the LH window.  It specifically calls set-window-start
with a nil NO-FORCE argument to try to ensure the redisplay will move
point into the window rather than scrolling the window to include point.

(iv) Redisplay sees w->force_start true and
make_cursor_line_fully_visible_p also true.  These conflict with
eachother here.  Priority is given to make_cursor_...._p.

Why does w->force_start not have priority here?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Fri, 28 Sep 2018 20:31:51 +0000
> Cc: Allen Li <darkfeline@felesatra.moe>, Anders Lindgren <andlind@gmail.com>,
>   32848@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> (iv) Redisplay sees w->force_start true and
> make_cursor_line_fully_visible_p also true.  These conflict with
> eachother here.  Priority is given to make_cursor_...._p.
> 
> Why does w->force_start not have priority here?

Because by default we don't want to show the cursor in a partial line,
ever: such a line might not be legible.  Over the years, more and more
rare use cases were reported where such a situation happens, and we
fixed them one by one.  Evidently, this is the popular demand.

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.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 29, 2018 at 00:27:11 +0300, Eli Zaretskii wrote:
> > Date: Fri, 28 Sep 2018 20:31:51 +0000
> > Cc: Allen Li <darkfeline@felesatra.moe>, Anders Lindgren <andlind@gmail.com>,
> >   32848@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > (iv) Redisplay sees w->force_start true and
> > make_cursor_line_fully_visible_p also true.  These conflict with
> > eachother here.  Priority is given to make_cursor_...._p.

> > Why does w->force_start not have priority here?

> Because by default we don't want to show the cursor in a partial line,
> ever: such a line might not be legible.  Over the years, more and more
> rare use cases were reported where such a situation happens, and we
> fixed them one by one.  Evidently, this is the popular demand.

OK.

> 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: there is a last follow mode window
where the cursor, if it ends up in the last line, doesn't have a next
window to move to.  Also, the user can change
make-cursor-line-fully-visible at any time, unlikely though this is.

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.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> 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?

> 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".

> 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?  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.  Besides, your proposal has the annoying
effect of causing a micro-scroll near the end of the window.

> 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.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

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).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> 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

[Eli Zaretskii]

> Date: Sat, 29 Sep 2018 16:47:16 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> 
> 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.

Forgot to tell: I volunteer to write this part, if you agree with the
approach.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 29, 2018 at 16:47:16 +0300, Eli Zaretskii wrote:
> > 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>

> > 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.

My patch doesn't do anything like that.  It merely has a test, and if
that test signals t, moves point by one line, away from the danger area.
The messing around with window-start has been in follow mode for ever.
I think it's time to post that patch:


diff --git a/lisp/follow.el b/lisp/follow.el
index fd397c077b..7d6204b08e 100644
--- a/lisp/follow.el
+++ b/lisp/follow.el
@@ -1385,7 +1385,15 @@ follow-adjust-window
 	  (unless (eq win (selected-window))
 	    (let ((p (window-point win)))
 	      (set-window-start win (window-start win) nil)
-	      (set-window-point win p))))
+	      (set-window-point win p)
+              (if (and frame-resize-pixelwise
+                       make-cursor-line-fully-visible
+                       ;; Check for cursor being in partially displayed line.
+                       (nth 2 (pos-visible-in-window-p p win t)))
+                  ;; If so, move point away from this disaster line,
+                  ;; preventing scrolling.
+                  (with-selected-window win
+                    (forward-line -1))))))
 
 	(unless visible
 	  ;; If point may not be visible in the selected window,


Please reconsider it, now you can see how little it actually does.

> 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.

Turning off m-c-l-f-v I can live with, and if you definitely reject my
approach above, I'm willing to implement it.  It can't be difficult, just
creating a buffer local variable and setting it to nil.  ;-)

[ .... ]

> 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).

Fair enough!  We are rather arguing about things which will rarely, if
ever, happen.

> > > 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.

OK.  But it will be more complex than my 5-line patch above.  But I have
no objections to this change (making that variable optionally a
function).

> > > 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?

No, my patch doesn't change anything.  Follow mode already does this:

    (set-window-start win (window-start win) nil)

, which it does solely to prevent redisplay scrolling that buffer.  It
does not change window-start here.  This is what I meant by follow mode
and redisplay fighting.

> Or maybe by "it" you meant move point?  Then moving point is a side
> effect I think we should avoid in this case.

Point cannot stay in that partially displayed line.  Follow mode moving
it away prevents redisplay from scrolling the window.

> > 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.

The current docs imply NOFORCE being nil always works.  If the docs had
mentioned the exception, it's possible we wouldn't now be dealing with
this bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Sat, 29 Sep 2018 14:48:46 +0000
> Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.
> 
> My patch doesn't do anything like that.  It merely has a test, and if
> that test signals t, moves point by one line, away from the danger area.
> The messing around with window-start has been in follow mode for ever.
> I think it's time to post that patch:
> 
> 
> diff --git a/lisp/follow.el b/lisp/follow.el
> index fd397c077b..7d6204b08e 100644
> --- a/lisp/follow.el
> +++ b/lisp/follow.el
> @@ -1385,7 +1385,15 @@ follow-adjust-window
>  	  (unless (eq win (selected-window))
>  	    (let ((p (window-point win)))
>  	      (set-window-start win (window-start win) nil)
> -	      (set-window-point win p))))
> +	      (set-window-point win p)
> +              (if (and frame-resize-pixelwise
> +                       make-cursor-line-fully-visible
> +                       ;; Check for cursor being in partially displayed line.
> +                       (nth 2 (pos-visible-in-window-p p win t)))
> +                  ;; If so, move point away from this disaster line,
> +                  ;; preventing scrolling.
> +                  (with-selected-window win
> +                    (forward-line -1))))))

But this means the user will have its command to move point down
"ignored" in the window where she did that, right?  IOW, I press C-n,
and yet cursor stays in the line where I was before, right?

> > 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.
> 
> Turning off m-c-l-f-v I can live with, and if you definitely reject my
> approach above, I'm willing to implement it.

I think it will have a smaller effect than what you propose, yes.

> It can't be difficult, just
> creating a buffer local variable and setting it to nil.  ;-)

Right.

> > 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.
> 
> OK.  But it will be more complex than my 5-line patch above.

I volunteer to do the xdisp.c part if you will agree to write the
follow.el function to serve as the value for
make-cursor-line-fully-visible.

> The current docs imply NOFORCE being nil always works.  If the docs had
> mentioned the exception, it's possible we wouldn't now be dealing with
> this bug.

I'm just saying that telling users it will sometimes not work,
depending on factors that are really hard to describe, is not
necessarily better.  But I don't object.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 29, 2018 at 18:06:20 +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Sep 2018 14:48:46 +0000
> > Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > 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.

> > My patch doesn't do anything like that.  It merely has a test, and if
> > that test signals t, moves point by one line, away from the danger area.
> > The messing around with window-start has been in follow mode for ever.
> > I think it's time to post that patch:


> > diff --git a/lisp/follow.el b/lisp/follow.el
> > index fd397c077b..7d6204b08e 100644
> > --- a/lisp/follow.el
> > +++ b/lisp/follow.el
> > @@ -1385,7 +1385,15 @@ follow-adjust-window
> >  	  (unless (eq win (selected-window))
> >  	    (let ((p (window-point win)))
> >  	      (set-window-start win (window-start win) nil)
> > -	      (set-window-point win p))))
> > +	      (set-window-point win p)
> > +              (if (and frame-resize-pixelwise
> > +                       make-cursor-line-fully-visible
> > +                       ;; Check for cursor being in partially displayed line.
> > +                       (nth 2 (pos-visible-in-window-p p win t)))
> > +                  ;; If so, move point away from this disaster line,
> > +                  ;; preventing scrolling.
> > +                  (with-selected-window win
> > +                    (forward-line -1))))))

> But this means the user will have its command to move point down
> "ignored" in the window where she did that, right?  IOW, I press C-n,
> and yet cursor stays in the line where I was before, right?

Yes.  But point in the non-selected windows of a follow set is in any
case of no consequence.  Try setting up follow mode, do a few things in
it, then do C-x o.  Often, when I do this, point is at the mid point of
the window moved to.  Of no consequence.

What I, as a typical user (hah!), sees, is that point moves from the LH
window to the RH window.  If I were using the GUI version, I would soon
learn not to see the hollowed out representation of point left in the
"old" window.  Maybe we could enhance Emacs to be able not to display
this hollow point in the non selected windows of a follow set.  I've not
looked into it, but it shouldn't be too difficult.

If we had real support for a multiple window in the display engine (I
started trying to write this a couple of years ago, but didn't get very
far), there would be just one point shared by all the "sub"windows, and a
single full width mode line rather than a truncated mode line for each
"sub"window.  Maybe somebody will someday construct this.

> > > 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.

> > Turning off m-c-l-f-v I can live with, and if you definitely reject my
> > approach above, I'm willing to implement it.

> I think it will have a smaller effect than what you propose, yes.

Oh, OK, then!  I can accept this.

> > It can't be difficult, just
> > creating a buffer local variable and setting it to nil.  ;-)

> Right.

I will make this change to follow-mode for Emacs-26, and commit it with a
"don't merge to master" instruction to our infrastructure.  Probably
tomorrow.

> > > 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.

> > OK.  But it will be more complex than my 5-line patch above.

> I volunteer to do the xdisp.c part if you will agree to write the
> follow.el function to serve as the value for
> make-cursor-line-fully-visible.

OK, let's do it!  What arguments will such a function get?  I think a
single argument, a window, would be appropriate.  The function would then
return either nil (for most windows) or non-nil (for a "right most"
window).

> > The current docs imply NOFORCE being nil always works.  If the docs had
> > mentioned the exception, it's possible we wouldn't now be dealing with
> > this bug.

> I'm just saying that telling users it will sometimes not work,
> depending on factors that are really hard to describe, is not
> necessarily better.  But I don't object.

You may be right.  But I think I'll extend the docu anyway.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Sat, 29 Sep 2018 20:25:46 +0000
> Cc: darkfeline@felesatra.moe, andlind@gmail.com, 32848@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > > 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.
> 
> > > OK.  But it will be more complex than my 5-line patch above.
> 
> > I volunteer to do the xdisp.c part if you will agree to write the
> > follow.el function to serve as the value for
> > make-cursor-line-fully-visible.
> 
> OK, let's do it!  What arguments will such a function get?  I think a
> single argument, a window, would be appropriate.  The function would then
> return either nil (for most windows) or non-nil (for a "right most"
> window).

Agreed.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Allen and Eli.

I've just committed the following change to the emacs-26 branch.  It is
a workaround, but is safe, and should enable you (Allen) to carry on
using follow mode.

Eli and I have a more satisfactory fix planned for master.



diff --git a/lisp/follow.el b/lisp/follow.el
index fd397c077b..7942901bb4 100644
--- a/lisp/follow.el
+++ b/lisp/follow.el
@@ -438,7 +438,10 @@ follow-mode
         (setq pos-visible-in-window-group-p-function
               'follow-pos-visible-in-window-p)
         (setq selected-window-group-function 'follow-all-followers)
-        (setq move-to-window-group-line-function 'follow-move-to-window-line))
+        (setq move-to-window-group-line-function 'follow-move-to-window-line)
+
+        ;; Crude workaround for bug #32848 for the emacs-26 branch, 2018-09-30.
+        (setq-local make-cursor-line-fully-visible nil))
 
     ;; Remove globally-installed hook functions only if there is no
     ;; other Follow mode buffer.
@@ -451,6 +454,9 @@ follow-mode
 	(remove-hook 'post-command-hook 'follow-post-command-hook)
 	(remove-hook 'window-size-change-functions 'follow-window-size-change)))
 
+    ;; Second part of crude workaround for bug #32848.
+    (kill-local-variable 'make-cursor-line-fully-visible)
+
     (kill-local-variable 'move-to-window-group-line-function)
     (kill-local-variable 'selected-window-group-function)
     (kill-local-variable 'pos-visible-in-window-group-p-function)

-- 
Alan Mackenzie (Nuremberg, Germany).



On Thu, Sep 27, 2018 at 11:06:20 +0300, Eli Zaretskii wrote:
> > From: Allen Li <darkfeline@felesatra.moe>
> > Date: Wed, 26 Sep 2018 15:49:15 -0700

> > Moving the cursor off the bottom of the window with follow-mode enabled
> > doesn't move to the other window properly if frame-resize-pixelwise is
> > set and a partial line is visible.

> It seems like setting make-cursor-line-fully-visible to nil solves the
> problem.  Could you try that for a while, and see if this has any
> adverse effects?

> Alan and Anders: does setting this variable to nil in buffers under
> follow-mode sounds like an okay solution?  It might mean that in some
> rare cases the user will see the current line only partially (only in
> the last window in the group).  If you think this is OK, we could
> arrange for that variable to be set locally as part of turning on
> follow-mode.

> A more complex solution would be to allow
> make-cursor-line-fully-visible have a value that is a function, which
> follow-mode will define in a way that will only allow
> partially-visible current line in a window if it is not the last one
> in the order returned by follow-all-followers.

> Comments?

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Sun, 30 Sep 2018 08:30:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> 
> > OK, let's do it!  What arguments will such a function get?  I think a
> > single argument, a window, would be appropriate.  The function would then
> > return either nil (for most windows) or non-nil (for a "right most"
> > window).
> 
> Agreed.

Now done on the master branch.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Sun, 30 Sep 2018 11:02:15 +0000
> Cc: Anders Lindgren <andlind@gmail.com>, 32848@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I've just committed the following change to the emacs-26 branch.  It is
> a workaround, but is safe, and should enable you (Allen) to carry on
> using follow mode.

Thanks.  I think this warrants a NEWS entry.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Sun, Sep 30, 2018 at 14:16:52 +0300, Eli Zaretskii wrote:
> > Date: Sun, 30 Sep 2018 08:30:56 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe

> > > OK, let's do it!  What arguments will such a function get?  I think a
> > > single argument, a window, would be appropriate.  The function would then
> > > return either nil (for most windows) or non-nil (for a "right most"
> > > window).

> > Agreed.

> Now done on the master branch.

Great!

My bit is now ready, too, and I was just about to commit it.  But...

There's a problem.  If you move point with C-n from the LH window to the
RH window, LH point stays on the partially visible line.  If you now do
C-x o, point moves to that position, but follow-mode decides that the RH
window is appropriate for displaying that point, so C-x o appears not to
be working.

I'll see what I can come up with to sort this out.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Sun, 30 Sep 2018 12:16:18 +0000
> Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> From: Alan Mackenzie <acm@muc.de>
> 
> > Now done on the master branch.
> 
> Great!
> 
> My bit is now ready, too, and I was just about to commit it.  But...
> 
> There's a problem.  If you move point with C-n from the LH window to the
> RH window, LH point stays on the partially visible line.  If you now do
> C-x o, point moves to that position, but follow-mode decides that the RH
> window is appropriate for displaying that point, so C-x o appears not to
> be working.

I see this before the change, just by setting
make-cursor-line-fully-visible to nil.  So it's not because of these
changes.

> I'll see what I can come up with to sort this out.

Yes, probably follow-mode needs to apply some smarts here.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Sun, Sep 30, 2018 at 14:24:22 +0300, Eli Zaretskii wrote:
> > Date: Sun, 30 Sep 2018 11:02:15 +0000
> > Cc: Anders Lindgren <andlind@gmail.com>, 32848@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I've just committed the following change to the emacs-26 branch.  It is
> > a workaround, but is safe, and should enable you (Allen) to carry on
> > using follow mode.

> Thanks.  I think this warrants a NEWS entry.

Sorry, I should have thought of that.  I'll do one.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello again, Eli.

On Sun, Sep 30, 2018 at 15:56:58 +0300, Eli Zaretskii wrote:
> > Date: Sun, 30 Sep 2018 12:16:18 +0000
> > Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> > From: Alan Mackenzie <acm@muc.de>

> > > Now done on the master branch.

> > Great!

> > My bit is now ready, too, and I was just about to commit it.  But...

> > There's a problem.  If you move point with C-n from the LH window to the
> > RH window, LH point stays on the partially visible line.  If you now do
> > C-x o, point moves to that position, but follow-mode decides that the RH
> > window is appropriate for displaying that point, so C-x o appears not to
> > be working.

> I see this before the change, just by setting
> make-cursor-line-fully-visible to nil.  So it's not because of these
> changes.

> > I'll see what I can come up with to sort this out.

> Yes, probably follow-mode needs to apply some smarts here.

The problem was that LH point was "straddling" the window "edge".  The
solution appears to be to copy what happens when LH point is outside the
window, i.e. allow redisplay to move it back to the centre of the window.

For this, a simple (forward-line) suffices.

The trouble is, all the make-cursor-line-fully-visible stuff we've done
then becomes redundant, since point will never be left inside a partially
displayed line, except possibly at EOB.

Here's my current patch.  What do you think?



diff --git a/lisp/follow.el b/lisp/follow.el
index 7aa7b51473..6300be1909 100644
--- a/lisp/follow.el
+++ b/lisp/follow.el
@@ -1382,7 +1387,13 @@ follow-adjust-window
 	  (unless (eq win (selected-window))
 	    (let ((p (window-point win)))
 	      (set-window-start win (window-start win) nil)
-	      (set-window-point win p))))
+              (if (nth 2 (pos-visible-in-window-p p win t))
+                  ;; p is in a partially visible line.  We can't leave
+                  ;; window-point there, because C-x o back into WIN
+                  ;; would then fail.
+                  (with-selected-window win
+                    (forward-line)) ; redisplay will recenter it in WIN.
+	        (set-window-point win p)))))
 
 	(unless visible
 	  ;; If point may not be visible in the selected window,
  

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Sun, 30 Sep 2018 14:09:21 +0000
> Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> From: Alan Mackenzie <acm@muc.de>
> 
> The problem was that LH point was "straddling" the window "edge".  The
> solution appears to be to copy what happens when LH point is outside the
> window, i.e. allow redisplay to move it back to the centre of the window.
> 
> For this, a simple (forward-line) suffices.
> 
> The trouble is, all the make-cursor-line-fully-visible stuff we've done
> then becomes redundant, since point will never be left inside a partially
> displayed line, except possibly at EOB.
> 
> Here's my current patch.  What do you think?

I think we should revert the change to set
make-cursor-line-fully-visible locally on the emacs-26 branch, and
install this patch instead.  But on master, I think we need both this
patch and a special function that sets make-cursor-line-fully-visible
nil in non-last windows under follow-mode, because that's definitely
what follow-mode wants.

WDYT?

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Sun, Sep 30, 2018 at 20:00:14 +0300, Eli Zaretskii wrote:
> > Date: Sun, 30 Sep 2018 14:09:21 +0000
> > Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> > From: Alan Mackenzie <acm@muc.de>

> > The problem was that LH point was "straddling" the window "edge".  The
> > solution appears to be to copy what happens when LH point is outside the
> > window, i.e. allow redisplay to move it back to the centre of the window.

> > For this, a simple (forward-line) suffices.

> > The trouble is, all the make-cursor-line-fully-visible stuff we've done
> > then becomes redundant, since point will never be left inside a partially
> > displayed line, except possibly at EOB.

> > Here's my current patch.  What do you think?

> I think we should revert the change to set
> make-cursor-line-fully-visible locally on the emacs-26 branch, and
> install this patch instead.

I can agree with this.

> But on master, I think we need both this patch and a special function
> that sets make-cursor-line-fully-visible nil in non-last windows under
> follow-mode, because that's definitely what follow-mode wants.

I don't understand what this would be for.  With my patch from the last
post, I don't think any window's point would ever be left by follow-mode
in a partially displayed line.  Maybe the function I've written
(follow-make-cursor-line-fully-visible-p) might be useful sometime in
the future.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Mon, 1 Oct 2018 12:33:36 +0000
> Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> From: Alan Mackenzie <acm@muc.de>
> 
> > But on master, I think we need both this patch and a special function
> > that sets make-cursor-line-fully-visible nil in non-last windows under
> > follow-mode, because that's definitely what follow-mode wants.
> 
> I don't understand what this would be for.  With my patch from the last
> post, I don't think any window's point would ever be left by follow-mode
> in a partially displayed line.  Maybe the function I've written
> (follow-make-cursor-line-fully-visible-p) might be useful sometime in
> the future.

Did you try a buffer whose first line is very tall, taller than the
window?

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

It's been a couple of weeks since your last post, which I'm only just now
answering, so here's a quick summary:

1. Original bug: in follow mode, moving point into a partially displayed
line at end-of-window, then onto the next line, caused the LH window to
scroll up rather than point being moved into the RH window.

2. I wrote a patch to follow-mode (now installed on the emacs-26 branch)
which would move point away from that critical line, allowing follow-mode
to work.

3. You wrote a patch to the C code (now installed on master) whereby
make-cursor-line-fully-visible can be a function.  I wrote a function for
this (not yet installed) which returned nil for non-last follow windows.

4. The strategy in 3. was problematic, since C-x o into a follow window
where point was on the partially displayed last line wouldn't work -
follow-mode moved the cursor back into the original window.

5. I suggested that we use the solution in 2. for master, too, discarding
3.  You countered by asking what would happen if a window's first line is
taller than the window.  (See below.)

On Mon, Oct 01, 2018 at 16:47:29 +0300, Eli Zaretskii wrote:
> > Date: Mon, 1 Oct 2018 12:33:36 +0000
> > Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> > From: Alan Mackenzie <acm@muc.de>

> > > But on master, I think we need both this patch and a special function
> > > that sets make-cursor-line-fully-visible nil in non-last windows under
> > > follow-mode, because that's definitely what follow-mode wants.

> > I don't understand what this would be for.  With my patch from the last
> > post, I don't think any window's point would ever be left by follow-mode
> > in a partially displayed line.  Maybe the function I've written
> > (follow-make-cursor-line-fully-visible-p) might be useful sometime in
> > the future.

> Did you try a buffer whose first line is very tall, taller than the
> window?

I've tried a few ways of getting such a window, but without luck.  Emacs
is very good at making sure a window is no smaller than one line tall.
;-)

Is it possible to create such a line in a window, probably with lisp?  Or
was your question more a prompt to me to handle this unlikely situation
gracefully?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Mon, 15 Oct 2018 09:23:41 +0000
> Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> From: Alan Mackenzie <acm@muc.de>
> 
> > Did you try a buffer whose first line is very tall, taller than the
> > window?
> 
> I've tried a few ways of getting such a window, but without luck.  Emacs
> is very good at making sure a window is no smaller than one line tall.
> ;-)
> 
> Is it possible to create such a line in a window, probably with lisp?

It's possible and even very easy.  Here's one way:

  emacs -Q
  C-x 2
  C-u 12 M-x shrink-window RET
  C-x C-+ + + + + + ....

Continue pressing "+" until the cursor becomes taller than the window,
and you are done.

Another way is to insert a tall image and see what happens with that.

> Or was your question more a prompt to me to handle this unlikely
> situation gracefully?

It was a good-faith question, this stuff always needs to be tested in
such extreme situations.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Eli.

On Mon, Oct 15, 2018 at 18:07:55 +0300, Eli Zaretskii wrote:
> > Date: Mon, 15 Oct 2018 09:23:41 +0000
> > Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> > From: Alan Mackenzie <acm@muc.de>

> > > Did you try a buffer whose first line is very tall, taller than the
> > > window?

> > I've tried a few ways of getting such a window, but without luck.  Emacs
> > is very good at making sure a window is no smaller than one line tall.
> > ;-)

> > Is it possible to create such a line in a window, probably with lisp?

> It's possible and even very easy.  Here's one way:

>   emacs -Q
>   C-x 2
>   C-u 12 M-x shrink-window RET
>   C-x C-+ + + + + + ....

> Continue pressing "+" until the cursor becomes taller than the window,
> and you are done.

Thanks, I didn't know about C-x C-+.

> Another way is to insert a tall image and see what happens with that.

> > Or was your question more a prompt to me to handle this unlikely
> > situation gracefully?

> It was a good-faith question, this stuff always needs to be tested in
> such extreme situations.

OK.  For brevity, I'm going to call a window with a line too tall to be
fully displayed a "very small window".

With my follow mode patch that was installed in the emacs-26 branch, the
cursor will not remain in a very small non-last window[*], regardless of
whether it starts there as the font size is increased.  Instead it moves
to the next normal sized window (and this displays the correct text
line).  The cursor can remain in a very small last window.

[*] Actually, when the two last windows are both very small, the cursor
will stay in any window, if moved there with C-x o.

With my follow mode patch, and additionally,
make-cursor-line-fully-visible set to the function
follow-make-cursor-line-fully-visible-p, I observed exactly the same
behaviour.

I think this behaviour is acceptable for very small windows.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Eli Zaretskii]

> Date: Mon, 15 Oct 2018 17:26:37 +0000
> Cc: 32848@debbugs.gnu.org, andlind@gmail.com, darkfeline@felesatra.moe
> From: Alan Mackenzie <acm@muc.de>
> 
> With my follow mode patch, and additionally,
> make-cursor-line-fully-visible set to the function
> follow-make-cursor-line-fully-visible-p, I observed exactly the same
> behaviour.
> 
> I think this behaviour is acceptable for very small windows.

Fine with me, thanks.

bug#32848: 26.1; follow-mode cursor move breaks with frame-resize-pixelwise

[Alan Mackenzie]

Hello, Emacs.

The bug has been fixed, separately in the emacs-26 branch and master.

-- 
Alan Mackenzie (Nuremberg, Germany).