GNU bug report logs -
#50186
Shell in emacs very annoying using zsh
Previous Next
To reply to this bug, email your comments to 50186 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Tue, 24 Aug 2021 13:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"ÖÜÈηÉ" <orbitingflea <at> qq.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 24 Aug 2021 13:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
When use zsh instead of bash, shell become very annoying.
Even if I do not edit the shell buffer, but changing its size, there will be extra lines generated in the buffer, which is not expected.
GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2020-09-20
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Wed, 25 Aug 2021 11:51:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 50186 <at> debbugs.gnu.org (full text, mbox):
<orbitingflea <at> qq.com> writes:
> When use zsh instead of bash, shell become very annoying.
>
> Even if I do not edit the shell buffer, but changing its size, there will be extra
> lines generated in the buffer, which is not expected.
Do you have a recipe to reproduce the problem, starting from "emacs -Q"?
It would also be helpful with some screenshots.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Thu, 26 Aug 2021 13:53:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
When use zsh instead of bash, shell become very annoying. Even if I do not edit the shell buffer, but changing its size, there will be extra lines generated in the buffer, which is not expected.
Here is a recipe to reproduce the bug. See attached for screenshots.
(1) Starting from emacs -Q.
[1.png in attached]
(2) M-x shell. Here my default shell is zsh, and I also have oh-my-zsh installed.
[2.png in attached]
You can see there are multi-line "leading info" (sorry for my poor English, I mean the characters on the left of the cursor before you enter a command in the shell, showing the username and the current directory; I don't know what it is called in English), but in bash there is only one line instead. I guess this is the key of the problem.
By the way, maybe there are different "schemes" or "styles" for zsh, for some of them there will be multi-line leading info.
(3) Repeat C-x 1, C-x 2, C-x 1, C-x 2, ...
[3.png & 4.png in attached]
There will be more and more lines in the shell, which is unexpected, because you did not edit the buffer.
[Message part 2 (text/html, inline)]
[bug-zsh-emacs-screenshots.zip (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Thu, 26 Aug 2021 14:55:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 50186 <at> debbugs.gnu.org (full text, mbox):
Hello,
> When use zsh instead of bash, shell become very annoying. Even if I do
> not edit the shell buffer, but changing its size, there will be extra
> lines generated in the buffer, which is not expected.
Could it be that zsh requires a terminal emulator?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Thu, 26 Aug 2021 14:56:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Fri, 27 Aug 2021 06:24:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 50186 <at> debbugs.gnu.org (full text, mbox):
> You can see there are multi-line "leading info" (sorry for my poor English,
> I mean the characters on the left of the cursor before you enter a command
> in the shell, showing the username and the current directory; I don't know
> what it is called in English), but in bash there is only one line instead.
> I guess this is the key of the problem.
This is called "prompt", and you can change such multi-line prompt in zsh
PROMPT=$'%~\n%# '
simply by removing \n. Then the prompt will stay on one line.
In bash there are different shell variable names for prompt,
for example, PS1='\w\n$ ' where you can remove \n too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Fri, 27 Aug 2021 10:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 50186 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> This is called "prompt", and you can change such multi-line prompt in zsh
>
> PROMPT=$'%~\n%# '
>
> simply by removing \n. Then the prompt will stay on one line.
And is it a known limitation of shell that multi-line prompts cause
problems?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Fri, 27 Aug 2021 14:55:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 50186 <at> debbugs.gnu.org (full text, mbox):
"周任飞" <orbitingflea <at> qq.com> writes:
> Hello,
>
> > And is it a known limitation of shell that multi-line prompts cause
> > problems?
>
> No. When I use the terminal outside emacs, it works very well.
> Here's the screenshot:
Sorry for the confusion: my question was whether someone knows if this
is a known limitation in the Emacs shell mode.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Fri, 27 Aug 2021 15:18:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 50186 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Zsh worked well if the prompt is in a single line. The bug comes from multi-line prompt, i.e., when emacs shell used with multi-line prompt, unexpected lines are generated.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Fri, 27 Aug 2021 17:16:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 50186 <at> debbugs.gnu.org (full text, mbox):
>> This is called "prompt", and you can change such multi-line prompt in zsh
>>
>> PROMPT=$'%~\n%# '
>>
>> simply by removing \n. Then the prompt will stay on one line.
>
> And is it a known limitation of shell that multi-line prompts cause
> problems?
Actually, I see no problems with multi-line prompts in Emacs.
I tried to use "\n" in PS1 in bash, and then run M-x shell.
No problems noticed :)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Sat, 28 Aug 2021 16:06:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 50186 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Juri,
> Actually, I see no problems with multi-line prompts in Emacs.
> I tried to use "\n" in PS1 in bash, and then run M-x shell.
> No problems noticed :)
Wow! That's surprising to me.
Maybe I should show my zsh config file that generating this bug:
export ZSH="/home/friend/.oh-my-zsh"
ZSH_THEME="ys"
plugins=(git)
source $ZSH/oh-my-zsh.sh
export DISPLAY=`cat /etc/resolv.conf | grep nameserver | awk '{print $2}'`:0.0
export PATH="/home/friend/.local/bin:$PATH"
Here I used "ys" theme of oh-my-zsh, and it has multi-line prompt.
By the way, I tested bash with multi-line prompt, as you said. No problem.
So the problem comes from zsh?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Sat, 28 Aug 2021 16:29:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 50186 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Zsh is one of the programs that I need to run with
`comint-process-echoes' set to t in the comint buffer...
?ηÉ/orbitingflea, can you define these two functions,
(defun det () (interactive) (setq comint-process-echoes t))
(defun den () (interactive) (setq comint-process-echoes nil))
and then use Zsh a bit with comint-process-echoes set to true and a
bit with comint-process-echoes set to nil - use `M-x det' and `M-x
den' to change the value - to see if something changes?
[[]],
Eduardo Ochs
http://angg.twu.net/#eev
On Sat, 28 Aug 2021 at 13:06, ���ηÉ via Bug reports for GNU Emacs, the
Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> Hello Juri,
>
> > Actually, I see no problems with multi-line prompts in Emacs.
> > I tried to use "\n" in PS1 in bash, and then run M-x shell.
> > No problems noticed :)
>
> Wow! That's surprising to me.
> Maybe I should show my zsh config file that generating this bug:
>
> export ZSH="/home/friend/.oh-my-zsh"
> ZSH_THEME="ys"
> plugins=(git)
> source $ZSH/oh-my-zsh.sh
> export DISPLAY=`cat /etc/resolv.conf | grep nameserver | awk '{print
> $2}'`:0.0
> export PATH="/home/friend/.local/bin:$PATH"
>
> Here I used "ys" theme of oh-my-zsh, and it has multi-line prompt.
> By the way, I tested bash with multi-line prompt, as you said. No problem.
> So the problem comes from zsh?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50186
; Package
emacs
.
(Sun, 29 Aug 2021 02:17:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 50186 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Eduardo Ochs,
> and then use Zsh a bit with comint-process-echoes set to true and a
> bit with comint-process-echoes set to nil - use `M-x det' and `M-x
> den' to change the value - to see if something changes?
First I noticed that comint-process-echoes is not defined in shell mode.
Then I switched the shell buffer to comint mode. Then, in both det and
den settings, the problem still happens.
--------
Zhou Renfei
[Message part 2 (text/html, inline)]
This bug report was last modified 3 years and 297 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.