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: 32874@debbugs.gnu.org
Subject: bug#32874: Unwanted scrolling in edebug `f' command when follow-mode is active
Date: Mon, 1 Oct 2018 12:59:22 +0000	[thread overview]
Message-ID: <20181001125922.GC5947@ACM> (raw)
In-Reply-To: <83in2m52h1.fsf@gnu.org>

Hello, Eli.

On Sun, Sep 30, 2018 at 20:17:46 +0300, Eli Zaretskii wrote:
> > Date: Sun, 30 Sep 2018 15:36:46 +0000
> > Cc: 32874@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > I've had a look at window-scroll-functions, but I can't see what you
> > > > must be seeing.  Currently, the documentation warns against trying to
> > > > influence the scrolling, saying "it probably won't work anyway".

> > > But you don't want to scroll yourself, you just want to switch the
> > > selected window and move point so that Emacs won't need to scroll.

> > > AFAIU, follow-mode wants to kick in when point goes off the selected
> > > window.  And the call to window-scroll-functions is exactly the place
> > > where the display engine decides it needs to scroll the window, but
> > > didn't actually scroll it yet.  So that looks like a good place to have
> > > follow-mode do its thing.  We might need to add some simple facility
> > > for follow-mode to use, so that it could signal the display engine not
> > > to scroll the window.  Other than that, I think this possibility is
> > > worth exploring.

> > Follow-mode also needs to be active on explicit scrolling commands such
> > as C-v.  Also, after inserting a newline, subsequent windows need to be
> > scrolled down.  After either of these, follow-mode laboriously starts
> > determining where all its windows have to start and end.  There's nothing
> > in the display engine to help in this process.

> I'm not sure you are right, since all of the situations you describe
> go through the function try_scrolling, which calls
> window-scroll-functions.

I have the feeling we're at cross purposes somehow, here.  I think the
display engine, by itself, is only ever going to be scrolling the
selected window.  Some mechanism is needed for scrolling the other follow
windows to synchronise with the selected window.  Currently, follow-mode
does all this calculation, neither elegantly nor efficiently.  I don't
think there is anything in the display manager to help with this.

Are you suggesting that the scrolling of the other follow windows could
somehow be assisted, possibly even triggered, by a call of
window-scroll-functions from the selected window?

> > > > Maybe it would be relatively simple to introduce new functionality.
> > > > Something like "scroll window so that window-end gets the given value".

> > > I'm not sure I understand how this could help follow-mode.  Please
> > > elaborate.

> > Currently when a middle or right hand window gets scrolled for any
> > reason, follow-mode has to determine how to scroll windows to the left of
> > it.  It does this by making a first guess at a window-start, does
> > set-window-start, then moves forward through the window to see how close
> > window-end is to where it needs to be.  If it's a line off, a different
> > starting position is chosen, and so on, until window-start gets correctly
> > placed.

> > If there were a function set-window-end, the display engine itself could
> > move back over the text lines to find window-start far more efficiently
> > and directly than follow-mode can.

> It should be very easy to write such a function, provided that you can
> pass it as argument the buffer position of the beginning of the last
> line in the window (not the end of that line).

That sounds very strange.  Where would the difficulty lie in the display
engine doing (forward-line -1) rather than the Lisp code?

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2018-10-01 12:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-29 14:09 bug#32874: Unwanted scrolling in edebug `f' command when follow-mode is active Alan Mackenzie
2018-09-29 14:35 ` Eli Zaretskii
2018-09-29 15:37   ` Alan Mackenzie
2018-09-29 16:09     ` Eli Zaretskii
2018-09-29 20:41       ` Alan Mackenzie
2018-09-30  7:35         ` Eli Zaretskii
2018-09-30 15:36           ` Alan Mackenzie
2018-09-30 17:17             ` Eli Zaretskii
2018-10-01 12:59               ` Alan Mackenzie [this message]
2018-10-01 13:52                 ` Eli Zaretskii
2018-09-30 14:45   ` Alan Mackenzie
2018-10-03 10:54     ` 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=20181001125922.GC5947@ACM \
    --to=acm@muc.de \
    --cc=32874@debbugs.gnu.org \
    --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.