* bug#4635: 23.1.50; term-previous-input and split windows
@ 2009-10-04 22:07 Stephen Berman
2009-11-19 21:55 ` Stephen Berman
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Berman @ 2009-10-04 22:07 UTC (permalink / raw)
To: emacs-pretest-bug
1. emacs -Q
2. Type M-x term RET to bring up the *terminal* buffer in term-mode
(/bin/bash here, if that's significant).
3. Type RET to put point on line 2 of the *terminal* buffer.
4. Type C-c 2 to make split windows (or any other command that makes
split windows, e.g. C-c 3, C-c C-b, etc.).
5. Type M-p to insert previous input.
=> The cursor in the selected *terminal* buffer jumps to the beginning
of the buffer instead of staying at the end of the inserted input.
This only happens if the *terminal* buffer has at least two displayed
lines (step 3). Any further term-* command restores the cursor to the
correct position. The cursor displacement also happens if the frame is
unsplit after step 5, i.e. C-c 1 followed by M-p (but not if the frame
is unsplit between steps 4 and 5).
This problem also happens with Emacs 22.
In GNU Emacs 23.1.50.2 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
of 2009-10-03 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#4635: 23.1.50; term-previous-input and split windows
2009-10-04 22:07 bug#4635: 23.1.50; term-previous-input and split windows Stephen Berman
@ 2009-11-19 21:55 ` Stephen Berman
2010-02-19 14:25 ` Stephen Berman
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Berman @ 2009-11-19 21:55 UTC (permalink / raw)
To: 4635
ping
The recipe in my OP was too specific, the problem occurs even without
term-previous-input:
1. emacs -Q
2. M-x term RET
3. C-c 2
4. RET
=> Cursor jumps from the term prompt to the beginning of the buffer
I instrumented term.el but could not induce the jump when stepping
through with edebug. I don't know how else to try debugging this.
Steve Berman
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#4635: 23.1.50; term-previous-input and split windows
2009-11-19 21:55 ` Stephen Berman
@ 2010-02-19 14:25 ` Stephen Berman
2010-09-25 16:07 ` Johan Bockgård
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Berman @ 2010-02-19 14:25 UTC (permalink / raw)
To: 4635
On Thu, 19 Nov 2009 22:55:57 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
> 1. emacs -Q
> 2. M-x term RET
> 3. C-c 2
> 4. RET
> => Cursor jumps from the term prompt to the beginning of the buffer
>
> I instrumented term.el but could not induce the jump when stepping
> through with edebug. I don't know how else to try debugging this.
Manifestations of this bug continue to annoy me (currently using GNU
Emacs 23.1.92.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6) of 2010-02-13
on escher). Does anyone have any idea how to fix (or at least debug)
it? Can anyone else reproduce it?
Steve Berman
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#4635: 23.1.50; term-previous-input and split windows
2010-02-19 14:25 ` Stephen Berman
@ 2010-09-25 16:07 ` Johan Bockgård
2010-09-26 13:03 ` Stephen Berman
0 siblings, 1 reply; 6+ messages in thread
From: Johan Bockgård @ 2010-09-25 16:07 UTC (permalink / raw)
To: Stephen Berman; +Cc: 4635
Stephen Berman <Stephen.Berman@gmx.net> writes:
> On Thu, 19 Nov 2009 22:55:57 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> 1. emacs -Q
>> 2. M-x term RET
>> 3. C-c 2
>> 4. RET
>> => Cursor jumps from the term prompt to the beginning of the buffer
>>
>> I instrumented term.el but could not induce the jump when stepping
>> through with edebug. I don't know how else to try debugging this.
>
> Manifestations of this bug continue to annoy me (currently using GNU
> Emacs 23.1.92.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6) of 2010-02-13
> on escher). Does anyone have any idea how to fix (or at least debug)
> it? Can anyone else reproduce it?
Point is being moved by
<process filter> -> term-emulate-terminal -> term-check-size ->
term-reset-size -> term-set-scroll-region
The same thing will also happen if you resize the window without
splitting it.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#4635: 23.1.50; term-previous-input and split windows
2010-09-25 16:07 ` Johan Bockgård
@ 2010-09-26 13:03 ` Stephen Berman
2012-06-17 8:26 ` Chong Yidong
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Berman @ 2010-09-26 13:03 UTC (permalink / raw)
To: 4635
On Sat, 25 Sep 2010 18:07:02 +0200 Johan Bockgård <bojohan@gnu.org> wrote:
> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> On Thu, 19 Nov 2009 22:55:57 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
>>
>>> 1. emacs -Q
>>> 2. M-x term RET
>>> 3. C-c 2
>>> 4. RET
>>> => Cursor jumps from the term prompt to the beginning of the buffer
>>>
>>> I instrumented term.el but could not induce the jump when stepping
>>> through with edebug. I don't know how else to try debugging this.
>>
>> Manifestations of this bug continue to annoy me (currently using GNU
>> Emacs 23.1.92.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6) of 2010-02-13
>> on escher). Does anyone have any idea how to fix (or at least debug)
>> it? Can anyone else reproduce it?
>
> Point is being moved by
>
> <process filter> -> term-emulate-terminal -> term-check-size ->
> term-reset-size -> term-set-scroll-region
>
> The same thing will also happen if you resize the window without
> splitting it.
Thanks for tracking that down. So, if I comment out the sexp (term-goto
0 0) in the last line term-set-scroll-region, the jump still happens,
but only to (line-beginning-position) and then the cursor immediately
returns to the first character after the prompt. This looks strange but
is at any rate much less disconcerting than jumping to the beginning of
the buffer. The only other place term-set-scroll-region is called is at
the end of term-handle-ansi-escape; I don't know how to test if this
change causes problems here. BTW, the jump only happens in character
mode (the default), not in line mode.
Steve Berman
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#4635: 23.1.50; term-previous-input and split windows
2010-09-26 13:03 ` Stephen Berman
@ 2012-06-17 8:26 ` Chong Yidong
0 siblings, 0 replies; 6+ messages in thread
From: Chong Yidong @ 2012-06-17 8:26 UTC (permalink / raw)
To: Stephen Berman; +Cc: 4635
Stephen Berman <stephen.berman@gmx.net> writes:
>>>> 1. emacs -Q
>>>> 2. M-x term RET
>>>> 3. C-c 2
>>>> 4. RET
>>>> => Cursor jumps from the term prompt to the beginning of the buffer
>
> Thanks for tracking that down. So, if I comment out the sexp (term-goto
> 0 0) in the last line term-set-scroll-region, the jump still happens,
> but only to (line-beginning-position) and then the cursor immediately
> returns to the first character after the prompt. This looks strange but
> is at any rate much less disconcerting than jumping to the beginning of
> the buffer. The only other place term-set-scroll-region is called is at
> the end of term-handle-ansi-escape; I don't know how to test if this
> change causes problems here. BTW, the jump only happens in character
> mode (the default), not in line mode.
I committed a similar fix, in term-emulate-terminal, to trunk. Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-06-17 8:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-04 22:07 bug#4635: 23.1.50; term-previous-input and split windows Stephen Berman
2009-11-19 21:55 ` Stephen Berman
2010-02-19 14:25 ` Stephen Berman
2010-09-25 16:07 ` Johan Bockgård
2010-09-26 13:03 ` Stephen Berman
2012-06-17 8:26 ` Chong Yidong
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).