[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode
From: |
Dmitry Alexandrov |
Subject: |
bug#23546: 25.1.50; scroll-restore-mode breaks comint-mode |
Date: |
Wed, 18 May 2016 21:48:45 +0300 |
User-agent: |
Mozilla/5.0 (X11; GNU x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 |
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.