[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(Not) scrolling past the end of a buffer

From: Jorgen Schaefer
Subject: (Not) scrolling past the end of a buffer
Date: Sat, 20 Oct 2012 00:34:12 +0200

There was a discussion back in February about Emacs scrolling past the
end of buffers, but that discussion never finished (as far as I can


Emacs' scrolling behavior allows for a window to move past the end of a
buffer up to the point where the last line of a buffer is the only
thing displayed. This can be useful for editing, but it is unexpected
behavior for modes that interact with other programs.

Based on the behavior of terminals, the expectation and preference
there is that the input line would remain at the bottom edge of a
window as long as there is enough data to be displayed.

There have been a number of hacks to implement this behavior. For
example, `comint-mode' introduced the variable
`comint-scroll-show-maximum-output' to achieve just this effect, but
it's an incomplete solution as manual scrolling or splitting windows
still can cause the prompt to show up in the middle of a window. The IRC
clients ERC and Circe both implement a specific hook to do this. Both
actually used `window-scroll-functions' for this, which worked well but
is problematic because other functions on the hook rely on the view port
not to change during the running of the hook. Hence a warning to that
effect was added to the hook description and ERC was changed to use
`post-command-hook', causing quite a bit of unnecessary computation.
Eshell and rcirc both have copied the comint behavior after originally
following ERC's approach.

And from the thread linked to above, it seems that some users would like
this behavior in editing buffers as well.

Based on the apparent need for such a functionality, I actually looked
at window.c to see if I can figure out how to add it right in the
scrolling code, but my C seems to be too rusty to actually get this
done. Though a buffer-local variable that's checked from the scrolling
code seems to me to be the correct solution for this problem.

So, with `window-scroll-functions' off-limits to this kind of code,
what's the officially recommended approach for modes that want to keep
their input line at the end of a window, and not break because of
splitting a window (or manual recentering, or any manual scrolling,
or ...)?

        -- Jorgen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]