all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 20:25:46 +0000	[thread overview]
Message-ID: <20180929202545.GE5008@ACM> (raw)
In-Reply-To: <83k1n45onn.fsf@gnu.org>

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





  reply	other threads:[~2018-09-29 20: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
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 [this message]
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=20180929202545.GE5008@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.