emacs-devel
[Top][All Lists]
Advanced

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

Re: scroll-restore.el


From: martin rudalics
Subject: Re: scroll-restore.el
Date: Fri, 22 Feb 2008 20:32:07 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> Well, that is perhaps useful on its own.  But just to note, some of
> the additional features are probably needed to address the
> transient-mark-mode region selection concern in the context where
> Martin introduced scroll-restore - e.g. handle-region and jump-back.
> (handle region just gives the appearance that an active region can go
> offscreen,

Yes.  I found it useful when showing the same buffer in two windows.
Scrolling one window wouldn't relocate the region in the other.

> jump back is apparently then needed so that the region is
> really reset to the pre-scrolled region just before the kill,
> otherwise the real region at scrolled time is killed).

No.  The region is restored automatically when the original position is
restored.  Jump back is much more aggressive in the sense that when you
have scrolled the original `point' offscreen and, for example, type a
self-insert character, that character is inserted at the original
position of `point' and not where `point' actually is.  I wouldn't use
the feature in practice but it's consistent with `delete-selection-mode'
and its derivatives.

>>  We can add a new
>> specific hook, and run it from commands and features that scroll.
>
> I think that may wind up being necessary anyway - e.g. As pointed out
> in the source comments, the code can't handle e.g. vertical scroll bar
> or mouse drag scrolling sometimes because they don't cause a
> post-command-hook?

Precisely.

> (And if you are then concerned with the behaviour of the active region
> under scrolling (though of course you mightn't be),  that can then
> cause  serious flickering at best, "wrong" region at worst (e.g. if
> you segue directly into a vertical scroll bar scroll from a mouse drag
> mark region)).

There are two options IMHO: Either turn off active region highlighting
when `point' is scrolled off-screen or highlight the region between the
original position and the mark.  The current approach of expanding and
contracting the region whenever `point' is adjusted is simply confusing.





reply via email to

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