bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Lars Ingebrigtsen
Peter Dyballa <[hidden email]> writes:

> Recently *compilation* buffer was reserved by some other process so I
> decided to install some Python packages in *shell* buffer (with tcsh
> 6.21.00 (Astron) 2019-05-08 (x86_64-apple-darwin) options
> wide,nls,dl,bye,al,kan,sm,rh,color,filec) as root. The installation
> manager is https://www.macports.org/index.php. It produced this output
> in the end:
>
> --->  Installing py38-jsonschema @3.2.0_0
> --->  Activating py38-jsonschema @3.2.0_0
> --->  Cleaning py38-jsonschema
> --->  Updating database of binaries
> --->  Scanning binaries for linking errors
> --->  No broken files found.
> --->  No broken ports found.
> root 252 /\
>
> Starting with the first '---> No broken files found.' line the
> foreground colour was switched to red. The MacPorts folks claim that
> their 'port' binary does not emit any ANSI codes to change the colour.

It's this screenshot?

https://trac.macports.org/attachment/ticket/61357/Foreground%20colour%20changes%20while%20finishing%20the%20installation%20of%20a%20port.png

Can you reproduce this problem with an emacs started with "emacs -Q"?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Peter Dyballa


> Am 9.12.2020 um 14:24 schrieb Lars Ingebrigtsen <[hidden email]>:
>
> It's this screenshot?
>
> https://trac.macports.org/attachment/ticket/61357/Foreground%20colour%20changes%20while%20finishing%20the%20installation%20of%20a%20port.png

Yes. Above the two red lines a lot more existed.

>
> Can you reproduce this problem with an emacs started with "emacs -Q"?

Yes, I could try. (Meanwhile an updated version of GNU Emacs 28.0.50 is running, and I have also GNU Emacs 27.1 installed.)

--
Greetings

  Pete

To most people solutions mean finding the answers. But to chemists solutions are things that are still all mixed up.




Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Peter Dyballa
In reply to this post by Lars Ingebrigtsen

Am 9.12.2020 um 14:24 schrieb Lars Ingebrigtsen <[hidden email]>:

Can you reproduce this problem with an emacs started with "emacs -Q"?

Yes, it just happened:


Earlier it happened when the shell buffer was on the left side. Since I can easily get rid of the updates and repeat I can retry with shell on the left and also with shell the only buffer.

--
Greetings

  Pete

There is no worse tyranny than to force a man to pay for what he does not want merely because you think it would be good for him.
– Robert A. Heinlein

Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Lars Ingebrigtsen
Peter Dyballa <[hidden email]> writes:

>  Can you reproduce this problem with an emacs started with "emacs -Q"?
>
> Yes, it just happened:

Hm...  does your Emacs really look like that when you start it with
"emacs -Q"?  Hm...  Oh, I see -- it's an "emacs -nw" and those are the
colours in your terminal?

And the blue "root 235 /\" is your shell prompt?  Are there any ANSI
codes in your prompt?  I don't quite see why that would affect the
output here in this way, but it's one more thing that would be nice to
eliminate -- could you use the default OS shell prompt and see whether
that changes anything?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Peter Dyballa


Am 11.12.2020 um 15:47 schrieb Lars Ingebrigtsen <[hidden email]>:

And the blue "root 235 /\" is your shell prompt?

Not really. I think it comes from shell-mode. In Apple Terminal it looks like this:


In ~/.emacs I have:

.emacs:503: '(comint-prompt-regexp "^[a-z]+ [0-9]+ /\\\\ " t)
.emacs:620: '(shell-prompt-pattern "^[a-z0-9]+ [0-9]+ /\\\\ ")
.emacs:650: '(comint-highlight-prompt ((t (:background "khaki" :foreground "firebrick" :weight bold))))
.emacs:670: '(minibuffer-prompt ((t (:background "yellow" :foreground "dark red" :weight bold))))


Are there any ANSI codes in your prompt?

Yes. It's defined like this in ~/.tcshrc:

11 if ($?TERM) then
12     if (($TERM == xterm) | ($TERM == nxterm)) then
13         setenv TERM xterm-color
17     endif
43     if (($TERM == eterm-color) | ($TERM == xterm-256color) | ($TERM == xterm-color)) then
44         set     red="%{\033[1;47;31m%}"
45         set   green="%{\033[0;47;32m%}"
46         set  yellow="%{\033[1;33m%}"
47         set    blue="%{\033[1;34m%}"
48         set magenta="%{\033[1;35m%}"
49         set    cyan="%{\033[1;36m%}"
50         set   white="%{\033[0;37m%}"
51         set     end="%{\033[0m%}" # This is needed at the end... :(
52 #        set prompt      = "`echo \e[31\;47\;1m\j-$user` ! /\\ "
53         set prompt="${red}%n ! /\\ ${end} "
54 #       set prompt="${red}%n${blue}@%m ${white}%~ ${green}! /\\ ${end}"
55 #       set prompt="[${green}%n${blue}@%m ${white}%~ ]${end}"
56         unset red green yellow blue magenta cyan yellow white end
57     else
58         set prompt       = "`echo $user` ! /\\ "
59     endif
126 endif


 I don't quite see why that would affect the
output here in this way, but it's one more thing that would be nice to
eliminate -- could you use the default OS shell prompt and see whether
that changes anything?

Alright, that'll be my next try! (In a new Terminal tab.)

--
Greetings

  Pete

We have to expect it, otherwise we would be surprised.

Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Lars Ingebrigtsen
Peter Dyballa <[hidden email]> writes:

>  Am 11.12.2020 um 15:47 schrieb Lars Ingebrigtsen <[hidden email]>:
>
>  And the blue "root 235 /\" is your shell prompt?
>
> Not really. I think it comes from shell-mode. In Apple Terminal it looks like this:
>
> *
>
> In ~/.emacs I have:
>
> .emacs:503: '(comint-prompt-regexp "^[a-z]+ [0-9]+ /\\\\ " t)

But you said you were running with "emacs -Q"?  So you should have none
of those settings in effect...

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Peter Dyballa

Am 11.12.2020 um 16:27 schrieb Lars Ingebrigtsen <[hidden email]>:

But you said you were running with "emacs -Q"?  So you should have none
of those settings in effect...

Right! I just mentioned them for completeness – uselessly!

Without prompt settings in ~/.tcshrc I could reproduce the effect when the shell buffer was either on the left or on the right side. I did not succeed when it was the only buffer:




--
Greetings

  Pete

The human animal differs from the lesser primates in his passion for lists of "Ten Best."
– H. Allen Smith

Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Lars Ingebrigtsen
Peter Dyballa <[hidden email]> writes:

> Without prompt settings in ~/.tcshrc I could reproduce the effect when
> the shell buffer was either on the left or on the right side. I did
> not succeed when it was the only buffer:

Right, so it doesn't seem to be your local customisations that's
triggering this, but that was kinda a long shot, anyway.  I'm now trying
to reproduce this on Catalina, but so far, no dice.  What's the command
you're running in shell mode when this happens, exactly?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Peter Dyballa


> Am 12.12.2020 um 11:54 schrieb Lars Ingebrigtsen <[hidden email]>:
>
> What's the command you're running in shell mode when this happens, exactly?

        port upgrade asciidoc cmake djvulibre

This upgrades in my present situation
        asciidoc @9.0.3_0, cmake @3.19.1_0+docs+python38, djvulibre @3.5.27_0 to versions
        asciidoc @9.0.4_0, cmake @3.19.1_1+docs+python38, djvulibre @3.5.28_0
and also includes upgrading of
        libarchive @3.5.0_0, py38-pygments @2.7.2_0, py38-tz @2020.1_0 to versions
        libarchive @3.5.0_1, py38-pygments @2.7.3_0, py38-tz @2020.4_0 since some dependencies there exist. And since some other ports might depend on the newly installed binaries the MacPorts system is being scanned for these. During this you might be able to see progress bars appear. After this stage the colour is switched.

--
Greetings

  Pete

Swimming in money is dry fun.




Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Lars Ingebrigtsen
Peter Dyballa <[hidden email]> writes:

> port upgrade asciidoc cmake djvulibre

[...]

> since some dependencies there exist. And since some other ports might
> depend on the newly installed binaries the MacPorts system is being
> scanned for these. During this you might be able to see progress bars
> appear. After this stage the colour is switched.

I've installed a fresh Catalina VM with Macports, and the claim that the
"port" command doesn't issue any ANSI codes while doing this stuff is
incorrect.  I instrumented the bit in ansi-color.el that does the
fontification, and there's a whole bunch of ANSI-related sequences:



(It's switching the colours to inverse video here, I guess...)

However, I'm not able to reproduce the problem you're seeing -- it
doesn't switch the colour to red for me.  Then again, that command
doesn't actually update anything for me, which isn't strange, since I've
just installed it:

larsi@open-catalina lisp % sudo port upgrade asciidoc cmake djvulibre
sudo port upgrade asciidoc cmake djvulibre
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
larsi@open-catalina lisp %

So I guess I'll just have to wait a while until something is
upgradeable...

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

attachment0 (264K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Lars Ingebrigtsen
Peter Dyballa <[hidden email]> writes:

> These are progress bars that try to display how much of an archive has
> been downloaded yet. This feature seems to work fine…

Yup; I was just wondering whether "port" did without any ANSI codes at
all.  There have been bugs in the Emacs ANSI handling code before --
when text is output in blocks, and half the ANSI code arrives in one
block, and the next arrives in the next block, then Emacs would
misinterpret that.  These are supposed to be fixed now, but what you're
seeing seems to imply otherwise.

>> So I guess I'll just have to wait a while until something is
>> upgradeable...
>
> Approximately once per month GNU Emacs, development edition, gets
> updated. But there is no binary depending on it… ('port echo
> dependentof:<port name>' shows which other ports depend on the given
> one)

Yup; I guess I'll just wait a few weeks, and then do an update (with
instrumentation) to see whether I can catch it.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Lars Ingebrigtsen
I've pushed a fix for a related ANSI-colouring problem to Emacs 28
earlier today.  Could you check whether this fixes the problem you're
seeing, by any chance?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Peter Dyballa

> Am 22.2.2021 um 17:12 schrieb Lars Ingebrigtsen <[hidden email]>:
>
> I've pushed a fix for a related ANSI-colouring problem to Emacs 28
> earlier today.  Could you check whether this fixes the problem you're
> seeing, by any chance?

Hello Lars!

I "patched" the Portfile for GNU Emacs 28.0.50 to use this new software revision. The port programme just fetched the sources via '/usr/bin/git checkout -q f1fa35f0914f5de6d0dbfde9cd00cc7ab1b20ebd'. I found the branch version on https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=f1fa35f0914f5de6d0dbfde9cd00cc7ab1b20ebd.

GNU Emacs built meanwhile. I hope I also manage to install this version vie the port system!

--
Greetings

  Pete

"What do you think of Western Civilisation?"
"I think it would be a good idea!"
                                – Mohandas Karamchand Gandhi




Reply | Threaded
Open this post in threaded view
|

bug#44118: 28.0.50; Unwanted switch of foreground colour in *shell* buffer

Peter Dyballa
In reply to this post by Lars Ingebrigtsen

> Am 22.2.2021 um 17:12 schrieb Lars Ingebrigtsen <[hidden email]>:
>
> Could you check whether this fixes the problem you're seeing, by any chance?

It looks good. Foreground colours changed a few times upgrading old packages. Since port fell back into its old decease of building Python 3.9 I stopped its build with C-c C-c. Colours were OK after this.

I am going to build GNU Emacs again, this time with the MacPorts "native build" variant with GCC 10 (which needs to be built first). Let's see whether this makes a difference from the Apple clang version 12.0.0 built GNU Emacs…

--
Greetings

  Pete

A lot of us are working harder than we want, at things we don't like to do. Why? ...In order to afford the sort of existence we don't care to live.
                                – Bradford Angier