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.