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

[Dmitry Alexandrov <321942@gmail.com>]

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.