[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31193: 26.1; error in `term-down' after window configuration change
From: |
Phil Sainty |
Subject: |
bug#31193: 26.1; error in `term-down' after window configuration change |
Date: |
Wed, 18 Apr 2018 16:23:37 +1200 |
User-agent: |
Orcon Webmail |
On 2018-04-18 14:04, Noam Postavsky wrote:
term-emulate-terminal(#<process terminal> "\015\033[K$
\015\n\032//home/phil/emacs/26/26.1rc1/usr/local/share/emacs/26.1/lisp\015\n")
Hmm, yeah, it looks like your bash adds a "\r\n" (\015 is \r) after the
prompt, while mine doesn't. Although, wouldn't that extra \n leave
your
cursor one row below the prompt?
In practice the carriage return shunts the cursor back to the start of
the
prompt that I was already at, and then gets 'stuck' there -- no new line
is
created.
Typing RET again triggers the same error (with no change to the buffer),
but as soon as I start typing other keys, functionality is restored.
I also don't get the \032/<path>\r\n unless I do a 'cd'.
I observe that whenever I execute a shell command (or just enter a blank
line) and then trigger the error, I get this the first time:
term-emulate-terminal(#<process terminal> "\015\033[K$\015\n")
but repeatedly re-triggering the error gives me this every time:
term-emulate-terminal(#<process terminal>
"\015\033[K$\015\n\032/<path>\015\n$")
(until I next enter a command or blank line.)
The <path> matches the directory tracking -- I can affect it with cd.
(but setting default-directory does not affect it).