bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

[Dmitry Alexandrov]

Hello.

I encountered a problem that looks like a bug to me: scroll-restore-mode
(from elpa.gnu.org [0]) breaks comint-mode (built-in, GNU Emacs 25.1.50.1).

[0] https://elpa.gnu.org/packages/scroll-restore.html

Steps to reproduce in a clear environment:

$ mkdir /tmp/emacs.d
$ emacs --quick --eval '(setq user-emacs-directory "/tmp/emacs.d")'

(package-initialize)
(package-refresh-contents)
(package-install 'scroll-restore)
(setq scroll-restore-jump-back t)
(scroll-restore-mode 1)

M-x shell

Now I can type the first command (c d RET), start to type the second one
— and the point jumps before shell prompt:

user@local:~$ cd¦
cd¦user@local:~$

(here ‘¦’ denotes cursor position)

I could move point back to the end manually (with M-> for instance), but
that is pretty annoying.

I have to mention that it would not present a huge problem if there were
a way disable scroll-restore-mode on per-major-mode basis.  However
scroll-restore-mode has only global state, no buffer-local, as far as I
can see.

bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

[martin rudalics]

 > I encountered a problem that looks like a bug to me: scroll-restore-mode
 > (from elpa.gnu.org [0]) breaks comint-mode (built-in, GNU Emacs 25.1.50.1).
 >
 > [0] https://elpa.gnu.org/packages/scroll-restore.html
 >
 > Steps to reproduce in a clear environment:
 >
 > $ mkdir /tmp/emacs.d
 > $ emacs --quick --eval '(setq user-emacs-directory "/tmp/emacs.d")'
 >
 > (package-initialize)
 > (package-refresh-contents)
 > (package-install 'scroll-restore)
 > (setq scroll-restore-jump-back t)
 > (scroll-restore-mode 1)
 >
 > M-x shell
 >
 > Now I can type the first command (c d RET), start to type the second one
 > — and the point jumps before shell prompt:
 >
 > user@local:~$ cd¦
 > cd¦user@local:~$
 >
 > (here ‘¦’ denotes cursor position)
 >
 > I could move point back to the end manually (with M-> for instance), but
 > that is pretty annoying.

Could you try with ‘comint-scroll-to-bottom-on-input’ set to 'this?
That option apparently conflicts with ‘scroll-restore-jump-back’.  (IMO
‘scroll-restore-jump-back’ is much too aggressive, I never set it.)

 > I have to mention that it would not present a huge problem if there were
 > a way disable scroll-restore-mode on per-major-mode basis.  However
 > scroll-restore-mode has only global state, no buffer-local, as far as I
 > can see.

I'm afraid that ‘scroll-restore-mode’ is too simplistic in this regard.

Thanks, martin

bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

[Dmitry Alexandrov]

On 16/05/16 11:20, martin rudalics wrote:
>> I encountered a problem that looks like a bug to me: scroll-restore-mode
>> (from elpa.gnu.org [0]) breaks comint-mode (built-in, GNU Emacs 25.1.50.1).
>>
>> [0] https://elpa.gnu.org/packages/scroll-restore.html
>>
>> Steps to reproduce in a clear environment:
>>
>> $ mkdir /tmp/emacs.d
>> $ emacs --quick --eval '(setq user-emacs-directory "/tmp/emacs.d")'
>>
>> (package-initialize)
>> (package-refresh-contents)
>> (package-install 'scroll-restore)
>> (setq scroll-restore-jump-back t)
>> (scroll-restore-mode 1)
>>
>> M-x shell
>>
>> Now I can type the first command (c d RET), start to type the second one
>> — and the point jumps before shell prompt:
>>
>> user@local:~$ cd¦
>> cd¦user@local:~$
>>
>> (here ‘¦’ denotes cursor position)
>>
>> I could move point back to the end manually (with M-> for instance), but
>> that is pretty annoying.
>
> Could you try with ‘comint-scroll-to-bottom-on-input’ set to 'this?
> That option apparently conflicts with ‘scroll-restore-jump-back’.

Yes, this option does force any input to be typed at the end-of-buffer, 
of course.  However, the possibility to ‘C-r’ back, edit some command 
in-place and hit ‘RET’ — i. e. the possibility that this option disables 
— is exactly why I prefer shell-mode over a full-featured terminal emulator.

>> I have to mention that it would not present a huge problem if there were
>> a way disable scroll-restore-mode on per-major-mode basis.  However
>> scroll-restore-mode has only global state, no buffer-local, as far as I
>> can see.
>
> I'm afraid that ‘scroll-restore-mode’ is too simplistic in this regard.

Alas.

bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

 >> Could you try with ‘comint-scroll-to-bottom-on-input’ set to 'this?
 >> That option apparently conflicts with ‘scroll-restore-jump-back’.
 >
 > Yes, this option does force any input to be typed at the
 > end-of-buffer, of course.  However, the possibility to ‘C-r’ back,
 > edit some command in-place and hit ‘RET’ — i. e. the possibility that
 > this option disables — is exactly why I prefer shell-mode over a
 > full-featured terminal emulator.

I still don't understand what you need ‘scroll-restore-jump-back’ for.
But I have to admit that I don't even remember the purpose of that
option well :-(

 >> I'm afraid that ‘scroll-restore-mode’ is too simplistic in this regard.
 >
 > Alas.

I'll attach my latest version of ‘scroll-restore-mode’.  Please try it.
If you confirm that this version works and doesn't break anything else,
I can install the appropriate changes in the elpa version.

Thanks, martin

[-- Attachment #2: scroll-restore.el --]
[-- Type: application/emacs-lisp, Size: 20760 bytes --]

bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

[Dmitry Alexandrov]

On 18/05/16 10:01, martin rudalics wrote:
>>> Could you try with ‘comint-scroll-to-bottom-on-input’ set to 'this?
>>> That option apparently conflicts with ‘scroll-restore-jump-back’.
>>
>> Yes, this option does force any input to be typed at the
>> end-of-buffer, of course.  However, the possibility to ‘C-r’ back,
>> edit some command in-place and hit ‘RET’ — i. e. the possibility that
>> this option disables — is exactly why I prefer shell-mode over a
>> full-featured terminal emulator.
>
> I still don't understand what you need ‘scroll-restore-jump-back’ for.
> But I have to admit that I don't even remember the purpose of that
> option well :-(

Hmm...  Probably I completely missed the point, but is not 
‘scroll-restore-jump-back’ an option that enables the title 
functionality of scroll-restore-mode — restoring the point position 
after scrolling, thus simulating the behaviour of most editors, which 
does not have that limitation of Emacs — that cursor position can be 
on-screen only.

How would you recommend to use it?  To write an advice around 
‘keyboard-quit’ (like below), so scrolling would be ‘cancelled’ only 
with ‘C-g’?

(defadvice keyboard-quit (before scroll-restore-jump-back activate)
   (scroll-restore-jump-back))

>>> I'm afraid that ‘scroll-restore-mode’ is too simplistic in this regard.
>>
>> Alas.
>
> I'll attach my latest version of ‘scroll-restore-mode’.  Please try it.
> If you confirm that this version works

Yes.  My appreciations to you.

> and doesn't break anything else,

I could not try anything, of course, but at first sight it does not.

bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

[martin rudalics]

 > Hmm...  Probably I completely missed the point, but is not
 > ‘scroll-restore-jump-back’ an option that enables the title
 > functionality of scroll-restore-mode — restoring the point position
 > after scrolling, thus simulating the behaviour of most editors, which
 > does not have that limitation of Emacs — that cursor position can be
 > on-screen only.

The aim of ‘scroll-restore-mode’ was much more modest: To move the
cursor to the position of ‘window-point’ after a sequence of scroll
commands have made that position invisible and then visible again.

‘scroll-restore-jump-back’ is much more aggressive: It forces the
position of ‘window-point’ to become visible again and move the cursor
to it after the first command which is not part of a sequence of scroll
commands that have made that position invisible.  If you are used to the
behavior of "most editors" where such behavior is the default, you might
like this.

Note, however, that the behavior I just described is not precisely the
behavior of these editors because, in addition to moving window-point
when it is scrolled off-screen, Emacs may also move window-point when it
enters the scroll margin.  Such movement is left alone by my algorithm.

 > How would you recommend to use it?  To write an advice around ‘keyboard-quit’ (like below), so scrolling would be ‘cancelled’ only with ‘C-g’?
 >
 > (defadvice keyboard-quit (before scroll-restore-jump-back activate)
 >    (scroll-restore-jump-back))
 >

It depends on what precisely you want to accomplish (or what you are
used to).  But why on earth would you want to advise ‘keyboard-quit’?

 >> I'll attach my latest version of ‘scroll-restore-mode’.  Please try it.
 >> If you confirm that this version works
 >
 > Yes.  My appreciations to you.
 >
 >> and doesn't break anything else,
 >
 > I could not try anything, of course, but at first sight it does not.

All you have to do is use it for a sufficient amount of time.  I'm
confident that there are unresolved issues left.

martin

bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode

[Dmitry Alexandrov]

On 19/05/16 15:56, martin rudalics wrote:
>> Hmm...  Probably I completely missed the point, but is not
>> ‘scroll-restore-jump-back’ an option that enables the title
>> functionality of scroll-restore-mode — restoring the point position
>> after scrolling, thus simulating the behaviour of most editors, which
>> does not have that limitation of Emacs — that cursor position can be
>> on-screen only.
>
> The aim of ‘scroll-restore-mode’ was much more modest: To move the
> cursor to the position of ‘window-point’ after a sequence of scroll
> commands have made that position invisible and then visible again.
>
> ‘scroll-restore-jump-back’ is much more aggressive: It forces the
> position of ‘window-point’ to become visible again and move the cursor
> to it after the first command which is not part of a sequence of scroll
> commands that have made that position invisible.  If you are used to the
> behavior of "most editors" where such behavior is the default, you might
> like this.
>
> Note, however, that the behavior I just described is not precisely the
> behavior of these editors because, in addition to moving window-point
> when it is scrolled off-screen, Emacs may also move window-point when it
> enters the scroll margin.  Such movement is left alone by my algorithm.

Thank you for explanation.

>> How would you recommend to use it?  To write an advice around ‘keyboard-quit’ (like below), so scrolling would be ‘cancelled’ only with ‘C-g’?
>>
>> (defadvice keyboard-quit (before scroll-restore-jump-back activate)
>>    (scroll-restore-jump-back))
>>
>
> It depends on what precisely you want to accomplish (or what you are
> used to).  But why on earth would you want to advise ‘keyboard-quit’?

To make ‘C-g’ and other keys that I bound to ‘keyboard-quit’ to ‘quit’ 
scrolling (if I may say so) too, of course.  Should I redefine these 
keys instead?

>>> I'll attach my latest version of ‘scroll-restore-mode’.  Please try it.
>>> If you confirm that this version works
>>
>> Yes.  My appreciations to you.
>>
>>> and doesn't break anything else,
>>
>> I could not try anything, of course, but at first sight it does not.
>
> All you have to do is use it for a sufficient amount of time.  I'm
> confident that there are unresolved issues left.

And you are right.  There is one of them: now it breaks macros that 
involve isearch.  Suppose that macro:

C-x ( C-s sit RET SPC bar C-x )

By executing it on a line:

¦Lorem ipsum dolor sit amet.

instead of:

Lorem ipsum dolor sit bar¦ amet.

I get:

r¦ab Lorem ipsum dolor sit amet.

(‘¦’ denotes point).

bug#23546:

[a]

[-- Attachment #1: Type: text/html, Size: 412 bytes --]

bug#23546: nevermind, pretty broken

[a]

[-- Attachment #1: Type: text/html, Size: 185 bytes --]

bug#23546: nevermind, pretty broken

[martin rudalics]

 > the updated version here indeed fixes comint mode, but it appears to break
 > macros in the same way for me as well (in evil mode, for what it's worth):
 >
 > replaying a macro that changes a word to "input" (`cwinput`) gives "putni"
 > instead of input
 >
 > can't quite work out a complete pattern, but it moves point backwards while
 > inserting text in many situations, which movement may or may not be correlated
 > with cpu load

Sorry, I can't follow well.  I suppose the following ingredients are
necessary:

(1) ‘scroll-restore-jump-back’ must have been set.

(2) A macro must be executed that moves point.

I neither use (1) nor (2) so can you give a full example, please?

Thanks, martin