Re: prevent scroll-lock-mode from scrolling?

[lee]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: lee <lee@yagibdah.de>
>> Date: Sat, 18 Jun 2016 01:10:55 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: lee <lee@yagibdah.de>
>> >> Date: Fri, 17 Jun 2016 03:12:15 +0200
>> >> 
>> >> is there a way to prevent the point from moving up or down when
>> >> scroll-lock-mode is enabled and the contents of the buffer have been
>> >> scrolled so far as for the first or the last line to reach the top or
>> >> the bottom of the frame, respectively?
>> >> 
>> >> It pretty much defeats the idea of this mode when the point moves
>> >> nonetheless after scrolling for a bit, since I would use this mode to
>> >> keep the point in its very place when scrolling.
>> >
>> > AFAIU, that's exactly the point of this minor mode.  If you don't like
>> > it, I suggest not to turn on the mode.
>> 
>> Well, what happens when you turn it on and your scrolling reaches the
>> end of the buffer?
>> 
>> The point moves towards the end of the buffer rather than that the
>> buffer contents are scrolled up.
>
> Yes, as I'd expect.  I'm still not sure I understand why is that a
> problem in your case.

I turn on scroll-lock-mode to keep the point where it is and don't want
it to move.  Why would I expect it to move nonetheless?

>> >> Thinking of this, is there a kinda complementary mode, or an option, to
>> >> scroll-lock-mode, which would move the point together with the contents
>> >> of the buffer when I scroll?
>> >
>> > That's what happens by default, so I don't think I understand what are
>> > you looking for.  Perhaps consider telling more about the feature you
>> > want to have.
>> 
>> You must somehow be scrolling very differently from how I scroll.
>
> No, the problem is that your terminology is very different from what
> we use in Emacs.  When you say "point moves", the usual meaning of
> this is that point changes its buffer position.  But what you actually
> mean is "cursor changes its screen position".

I was assuming that 'point' means the position where letters appear when
I type, i. e. where the cursor is.

>> Or perhaps I shouldn't say "scroll" but "move the point" instead.  When
>> scroll-lock-mode is enabled and you move the point up or down (C-p or
>> C-n), the buffer contents are scrolled down or up, respectively, while
>> the point remains in one place.
>
> No, point does change its buffer position, but the screen coordinates
> of the cursor are kept constant as much as possible.

That is probably the same :)

>> Yet when you come close to the top or the end of the buffer, the
>> point /does/ suddenly move up or down as if scroll-lock-mode was
>> disabled.  That's what defeats the scroll-lock-mode entirely.
>> 
>> I'd even say it's a bug, and that scrolling the buffer contents must
>> stop when the top/bottom is reached.  Moving the point up or down is
>> exactly what I /don't/ want when I enable scroll-lock-mode.  Whether the
>> point should move left or right when scroll-lock-mode is enabled, or if
>> the buffer contents should be scrolled right or left, should be
>> configurable.
>
> That might make sense in some use cases of view-mode (and even then
> might get in the way), but not in a general-purpose editable buffer,
> IMO.  It means some buffer positions are unreachable by
> vertical-motion commands.

They won't be unreachable because you can always turn off
scroll-lock-mode and move the cursor around.

> I still don't understand why the current behavior is a problem.  If
> that's because it affects cursor position for future scrolls, you can
> change that by cursor motion commands like C-f, C-b, M-f, M-b, etc.,
> before you commence scrolling.

I'm afraid I don't understand how you don't understand this.  The
problem is that the cursor moves when it shouldn't.  Maybe it helps to
distinguish between different types of cursor positions:

The position of the cursor /within the buffer/ is irrelevant for where
it is /on the screen/.  It is relevant to me where the cursor is /on the
screen/ and /which buffer contents/ are around this screen position
(because I want to see them).  It is pretty much irrelevant at which
position /within the buffer/ the contents I want to see are.  I need
them displayed on the screen in a desirable way, and when programming,
the order and content of the lines I'm looking at are most of the time
much more important than it is where within the buffer they are.  (It
doesn't matter whether a function 'foo' is at line 500 or at line 5000
as long as it is declared before being used (which isn't required, but
it is what I do.))

Now the cursor is already at a desired position /on the screen/ when I
enable scroll-lock-mode and start scrolling.  I need the cursor to
remain at this screen position while I'm scrolling.  I wouldn't enable
scroll-lock-mode to keep the cursor where I don't want it to be.

If I wanted to move the cursor to a desired position /within the
buffer/, I wouldn't enable scroll-lock-mode and move it there (and then
perhaps press C-l to get it to a desirable position /on the screen/ as
well).

Does that make some sense?


Can you explain to me why the cursor remains at its position /on the
screen/ while I'm scrolling with scroll-lock-mode enabled all the time
like it should --- and then suddenly moves when the top or bottom of the
buffer contents come into view?  That doesn't make any sense to me; the
cursor still shouldn't move.  I intentionally fixed it by enabling
scroll-lock-mode.

It's like you're driving a car, and every time you come close to your
destination, the car suddenly decides to go off road and forces you to
somehow steer it back onto the road, or to stop driving once you're
close enough so it doesn't go off road.

The position of the car within the universe is irrelevant for this.  It
only needs to stay on the road.  I do not want to move the car to a
particular position between my starting point and the destination (or
anywhere else) before I start driving.  I start to drive where the car
is.

For the fun of it, imagine that the car had a drive-lock-mode.  The car
would remain at a fixed position and the earth (or universe) would spool
away under it until it reaches its destination when you enable the
drive-lock-mode.  You're happy with where the car currently is, so you
enable the drive-lock-mode and start driving.  But alas, the
drive-lock-mode is buggy in that the car suddenly moves when it
approaches either it's destination or its starting point.  The car
moving just isn't what you wanted, and it is like the opposite of what
the drive-lock-mode should do.

Scroll-lock-mode does that to me.


-- 
GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, X toolkit)
 of 2016-03-18 on heimdali