Re: prevent scroll-lock-mode from scrolling?

[lee]

Dmitry Alexandrov <321942@gmail.com> writes:

> lee <lee@yagibdah.de> writes:
>
>> Dmitry Alexandrov <321942@gmail.com> writes:
>>
>>> lee <lee@yagibdah.de> writes:
>>>> 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.
>>>
>>> Given that there is no free space before the first line of a buffer,
>>> this does make perfect sense with regard to scrolling backward (to the
>>> top of a buffer).  The other way we would just get stuck with the point
>>> in the middle of a screen not being able to reach first lines.  The
>>> scrolling forward behaves the same way for sake of coherence, I guess.
>>
>> There is no free space beyond the last line of a buffer, either.
>
> Well, by default in GNU Emacs there *is* free space beyond the last
> line, which is taken in account while scrolling.  I have no idea how
> could you disabled it.

Err, yes, I shouldn't have said it this way.  I mean there's no free
space, only whatever emacs uses to fill parts of the display there are
no buffer contents such parts could otherwise be filled with.

Inconsistently, emacs fills only what it considers as "below" of buffer
contents with non-buffer-contents.

> Actually I would like to see some day an opposite option in GNU Emacs
> — to enable empty lines above the top of a buffer.

I'd like that, too.  It would make things consistent.

>> It doesn't make sense, though, because scroll-lock means that the cursor
>> does not move when scrolling.  Why else would I use scroll-lock-mode?
>
> As far as I understand, minor modes for Emacs are generally designed to
> be used on permanent basis, not to be toggled every several keystrokes.
> Since the algorithm you described prevents user from accessing to first
> N lines of buffer, this algorithm would be perceived as broken.

Scroll-lock-mode shouldn't have been implemented as a minor mode then,
or be given a different name.  Not that I'd press the ScrollLock key
every few keystrokes, though.

> [...]
>
>>> Also, if you are regularily toggling the ‘scroll-lock-mode’ on and off,
>>> you might consider to use approach that, one might say, is more
>>> ‘Emacsish’ — another keychord instead of mode:
>>>
>>> (setq scroll-preserve-screen-position 'always)
>>> (global-set-key (kbd "M-n") #'scroll-up-line)
>>> (global-set-key (kbd "M-<down>") #'scroll-up-line)
>>> (global-set-key (kbd "M-p") #'scroll-down-line)
>>> (global-set-key (kbd "M-<up>") #'scroll-down-line)
>>
>> The idea was to make use of the ScrollLock key.  So I did that and found
>> that when scroll-lock-mode is enabled, the point does move when it
>> shouldn't.
>>
>> Since what scroll-lock-mode does is achieved by setting
>> scroll-preserve-screen-position to t, what is the point or purpose of
>> scroll-lock-mode?  That the cursor moves when it shouldn't?
>
> First of all, I would not say that there is something wrong even with
> existence of a minor mode that only toggles single variable.  However
> you might notice that besides toggling ‘scroll-preserve-screen-position’
> ‘scroll-lock-mode’ at least re-defines several moving keys: ‘C-n’, ‘C-p’, etc.

I'm wondering why a whole mode should be needed when what the mode does
can be done by just changing a single variable instead.  And why would
it do more than doing just that?

>> BTW, it seems that changing scroll-preserve-screen-position requires
>> restarting emacs to take effect.
>
> No.

You mean it does take effect without restarting when you try it?

>> Maybe that's what scroll-lock-mode is
>> for, being able to change the behaviour without restarting?
>
> As you already noticed, ‘scroll-lock-mode’ depends on state of
> ‘scroll-preserve-screen-position’.  How then could it evade such a
> limitation if it existed?

Why would it do more than changing the variable if changing it would
take effect without any further ado?


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