GNU bug report logs -
#23546
25.1.50; scroll-restore-mode breaks comint-mode
Previous Next
To reply to this bug, email your comments to 23546 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Sun, 15 May 2016 23:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dmitry Alexandrov <321942 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 15 May 2016 23:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> local:~$ cd¦
cd¦user <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Mon, 16 May 2016 18:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 23546 <at> debbugs.gnu.org (full text, mbox):
> 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 <at> local:~$ cd¦
> cd¦user <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Tue, 17 May 2016 17:46:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 23546 <at> debbugs.gnu.org (full text, mbox):
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 <at> local:~$ cd¦
>> cd¦user <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Wed, 18 May 2016 07:02:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 23546 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> 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
[scroll-restore.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Wed, 18 May 2016 18:49:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 23546 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Thu, 19 May 2016 12:57:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 23546 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Sun, 22 May 2016 01:35:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 23546 <at> debbugs.gnu.org (full text, mbox):
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).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Thu, 03 Nov 2016 02:27:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 23546 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Sun, 06 Nov 2016 23:48:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 23546 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23546
; Package
emacs
.
(Mon, 07 Nov 2016 06:35:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 23546 <at> debbugs.gnu.org (full text, mbox):
> 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
This bug report was last modified 7 years and 310 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.