all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: lee <lee@yagibdah.de>
To: help-gnu-emacs@gnu.org
Subject: Re: prevent scroll-lock-mode from scrolling?
Date: Mon, 20 Jun 2016 21:50:05 +0200	[thread overview]
Message-ID: <877fdjej2q.fsf@heimdali.yagibdah.de> (raw)
In-Reply-To: <87a8ifalf9.fsf@gmail.com> (Dmitry Alexandrov's message of "Mon,  20 Jun 2016 19:12:58 +0300")

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



  reply	other threads:[~2016-06-20 19:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17  1:12 prevent scroll-lock-mode from scrolling? lee
2016-06-17  1:25 ` Emanuel Berg
2016-06-17  4:14   ` Stefan Monnier
2016-06-17  6:00     ` Emanuel Berg
2016-06-17 22:40       ` Stefan Monnier
2016-06-18  1:19         ` what to require (was: Re: prevent scroll-lock-mode from scrolling?) Emanuel Berg
2016-06-17 22:47   ` prevent scroll-lock-mode from scrolling? lee
2016-06-17  6:47 ` Eli Zaretskii
2016-06-17 23:10   ` lee
2016-06-18  8:38     ` Eli Zaretskii
2016-06-19 23:54       ` lee
2016-06-20  8:33         ` tomas
2016-06-20 14:32           ` lee
2016-06-20 10:05         ` Dmitry Alexandrov
2016-06-20 15:24           ` lee
2016-06-20 16:12             ` Dmitry Alexandrov
2016-06-20 19:50               ` lee [this message]
2016-06-20 14:34         ` Eli Zaretskii
2016-06-20 21:21           ` lee

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=877fdjej2q.fsf@heimdali.yagibdah.de \
    --to=lee@yagibdah.de \
    --cc=help-gnu-emacs@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.