From: npostavs@users.sourceforge.net
To: Pierre Neidhardt <ambrevar@gmail.com>
Cc: 27407@debbugs.gnu.org
Subject: bug#27407: 25.2; SGR reset is ignored if it terminates Eshell's output
Date: Sun, 18 Jun 2017 15:34:11 -0400 [thread overview]
Message-ID: <87mv95qedo.fsf@users.sourceforge.net> (raw)
In-Reply-To: <20170618180742.GC2617@gmail.com> (Pierre Neidhardt's message of "Sun, 18 Jun 2017 19:07:42 +0100")
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
Pierre Neidhardt <ambrevar@gmail.com> writes:
>> My patch does not solve this scenario, but on the other hand, when I try
>> this experiment in a terminal with bash, not putting a reset does give a
>> coloured prompt, i.e., in the following the 2nd "~/src$" is in yellow:
>>
>> ~/src$ echo $'\e[33mhello'
>> hello
>> ~/src$
>>
>> So should eshell really be any different?
>
> Yes. Definitely. Eshell _already_ is very different and that's why we use
> it. Bash is hardly a role model in the world of shells.
>
> In the case of bash, the issue probably stems back from historical limitations
> of VT* terminals. Something that does not make sense to emulate in modern
> computers.
>
> I don't see any use case for letting the SGR color the shell. If you want to
> change you shell from a command, Elisp is your friend...
Hmm, seems easy enough to fix:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 933 bytes --]
From 34f41c8573936285076b4e24c2e7ff4d34a48b8d Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Sun, 18 Jun 2017 15:29:55 -0400
Subject: [PATCH v1] Reset ansi escape context before printing eshell prompt
(Bug#27407)
* lisp/eshell/em-prompt.el (eshell-emit-prompt): Reset
`ansi-color-context-region'.
---
lisp/eshell/em-prompt.el | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lisp/eshell/em-prompt.el b/lisp/eshell/em-prompt.el
index 53a83e6a67..8c81b43b1f 100644
--- a/lisp/eshell/em-prompt.el
+++ b/lisp/eshell/em-prompt.el
@@ -117,6 +117,8 @@ (defun eshell-prompt-initialize ()
(defun eshell-emit-prompt ()
"Emit a prompt if eshell is being used interactively."
+ (when (boundp 'ansi-color-context-region)
+ (setq ansi-color-context-region nil))
(run-hooks 'eshell-before-prompt-hook)
(if (not eshell-prompt-function)
(set-marker eshell-last-output-end (point))
--
2.11.1
next prev parent reply other threads:[~2017-06-18 19:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-17 11:31 bug#27407: 25.2; SGR reset is ignored if it terminates Eshell's output Pierre Neidhardt
2017-06-17 18:19 ` npostavs
2017-06-18 6:49 ` Pierre Neidhardt
2017-06-18 17:50 ` npostavs
2017-06-18 18:07 ` Pierre Neidhardt
2017-06-18 19:34 ` npostavs [this message]
2017-07-03 14:12 ` npostavs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mv95qedo.fsf@users.sourceforge.net \
--to=npostavs@users.sourceforge.net \
--cc=27407@debbugs.gnu.org \
--cc=ambrevar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).