Re: Proposal to improve the nomenclature of scrolling directions

[Eli Barzilay]

An hour ago, Stefan Monnier wrote:
> >>> I'll be happy if it does happen, of course.  One thing that
> >>> would be much simpler is if the functionality is folded into the
> >>> scrolling functions (as a customizable thing, of course), then a
> >>> large part of
> >> Yes, that's the way I'd like to see it, indeed.
> > Without a post-display hook?  Then the display-engine may override
> > it.
> 
> I'm not sure we're talking about the same thing.  I'm just talking
> about the fact that the code he has right now does something similar
> to advising/redefining some functions (which is the only way to do
> it for an external package), and I'd rather just change those
> functions in the source code instead.

Yes -- to be clear, the only thing that I'm interested in is what Nix
described: having a sequence of scrolling up/down end up with exactly
the same window configuration in the end (provided the same number of
scrolling in both directions).  There's no need for any hooks for
that.

(BTW, I'm not sure if a use case was argued for, so this is ignorable
if it was.  The place where this is most obvious is if I'm working on
a piece of code that is all on the screen and I want to have a quick
peek up the file.  In this case it is very distracting if the screen
ends up at a different position so I don't see the same part of the
code, and/or if the point is not in the same place.  Either of these
require me to manually restore things, which is losing hacking focus.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!