emacs-devel
[Top][All Lists]
Advanced

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

Re: Allowing point to be outside the window?


From: John Ankarström
Subject: Re: Allowing point to be outside the window?
Date: Wed, 08 Dec 2021 14:33:01 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (berkeley-unix)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: John Ankarström <john@ankarstrom.se>
>> Date: Wed, 08 Dec 2021 02:45:02 +0100
>> 
>> For what it's worth, I think that it would be a good idea to limit this
>> feature to mouse-based scrolling.
>
> The display engine doesn't know what kind of user gestures (or even
> Lisp program) caused the scroll, so doing that cleanly won't be easy,
> if at all feasible.  And Emacs users are likely to dislike a solution
> that makes such a distinction, since many of them don't use the mouse.
>
>> I agree with Alan that, if you primarily use the keyboard for scrolling,
>> it is very jarring if editing/movement commands bring the window view
>> back to the original position.
>
> You'd prefer to have the editing command change the buffer in the
> portion that stays invisible?  IMNSHO, that'd be not just more
> jarring, it would be appalling.

No. What I meant is this:

"Point-detached" scrolling is only useful if there is a way to move the
point to the current view.

Let's say the point is at the beginning of the buffer. I scroll down to
look for a specific definition. I find it in the middle of the buffer.
Now, I want to edit that definition. But how do I get the point to the
currently viewed position?

In (all?) "modern" editors, the only way to do this is by left-clicking.

That's why I suggested limiting the whole feature to mouse-based
scrolling. If you are scrolling with the mouse, it is natural to click
to set a new position for the point. But if you are scrolling with, say,
Page Up and Page Down, you would need to move your hand to the mouse to
set a new position for the point.

This makes the whole feature quite useless for any scrolling that isn't
mouse-based. When scrolling with the keyboard, it is annoying if the
only way to move the point to the scrolled-to position is by clicking
the mouse.

The alternative is to provide a keyboard-based way to move the point to
the currently viewed portion of the buffer -- like a reverse C-l.

Come to think of it, that is probably a better solution than limiting
the feature to mouse-based scrolling. I adjust my opinion!




reply via email to

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