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

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

[Peter Dyballa]

Hello!

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.

I let this foreground colour – and by chance it happened that it was switched back during another installation:

	--->  Installing libomp @10.0.0_0
	--->  Activating libomp @10.0.0_0
	--->  Cleaning libomp
	--->  Fetching archive for clang-9.0
	--->  Attempting to fetch clang-9.0-9.0.1_1+analyzer+libstdcxx.darwin_19.x86_64.tbz2 from https://packages.macports.org/clang-9.0
	--->  Attempting to fetch clang-9.0-9.0.1_1+analyzer+libstdcxx.darwin_19.x86_64.tbz2.rmd160 from https://packages.macports.org/clang-9.0

The last line was in the usual colour again.


Right now I have to run GNU Emacs in Apple's Terminal application (Version 2.10 (433)) because X11 wants to create cache files of font files and is not allowed to do so for some font directories in read-only areas of the file system (clearing fontpath would be an option). The colour switches do not happen in *compilation* buffer. And I've seen similar behaviour four years ago – could be a version of 25.0.x.

	https://trac.macports.org/ticket/53404
	https://trac.macports.org/ticket/61357 (with a picture of colour changes happening in the Attachments section)

One idea of the cause for this is that the word "No" is triggering the colour change – similarly to configure output in *compilation* buffer, not being restricted for the single word.


In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0)
 of 2020-09-15 built on catalina.internal.macports.net
Repository revision: 2a47ef86e95fad1dcc14a02e7471ba5d9cad4b9b
Repository branch: HEAD
System Description:  Mac OS X 10.15.7


Configured using:
 'configure --prefix=/opt/local --without-ns --without-x --without-dbus
 --without-gconf --without-libotf --without-m17n-flt --with-gmp
 --with-gnutls --with-json --with-xml2 --with-modules --infodir
 /opt/local/share/info/emacs 'CFLAGS=-pipe -Os
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch
 x86_64' 'CPPFLAGS=-I/opt/local/include
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk'
 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-no_pie
 -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
 -arch x86_64''

Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB MODULES THREADS JSON PDUMPER

Important settings:
  value of $LC_CTYPE: de_DE.UTF-8
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  show-paren-mode: t
  midnight-mode: t
  display-time-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/Library/Application Support/Emacs/preview-latex hides /opt/local/share/emacs/site-lisp/preview-latex
/Library/Application Support/Emacs/tex-site hides /opt/local/share/emacs/site-lisp/tex-site
/Library/Application Support/Emacs/auctex hides /opt/local/share/emacs/site-lisp/auctex
/Library/Application Support/Emacs/punycode hides /opt/local/share/emacs/site-lisp/punycode
/Library/Application Support/Emacs/idna hides /opt/local/share/emacs/site-lisp/idna
/Library/Application Support/Emacs/git hides /opt/local/share/emacs/site-lisp/git
/Library/Application Support/Emacs/cmake-mode hides /opt/local/share/emacs/site-lisp/cmake-mode
/Library/Application Support/Emacs/calendar28/cal-move hides /opt/local/share/emacs/28.0.50/lisp/calendar/cal-move
/Library/Application Support/Emacs/calendar28/lunar hides /opt/local/share/emacs/28.0.50/lisp/calendar/lunar
/Library/Application Support/Emacs/calendar28/solar hides /opt/local/share/emacs/28.0.50/lisp/calendar/solar
/Library/Application Support/Emacs/calendar28/icalendar hides /opt/local/share/emacs/28.0.50/lisp/calendar/icalendar
/Library/Application Support/Emacs/calendar28/calendar hides /opt/local/share/emacs/28.0.50/lisp/calendar/calendar
/Library/Application Support/Emacs/calendar28/cal-html hides /opt/local/share/emacs/28.0.50/lisp/calendar/cal-html
/Library/Application Support/Emacs/calendar28/cal-iso hides /opt/local/share/emacs/28.0.50/lisp/calendar/cal-iso
/Library/Application Support/Emacs/calendar28/cal-tex hides /opt/local/share/emacs/28.0.50/lisp/calendar/cal-tex
/Library/Application Support/Emacs/calendar28/parse-time hides /opt/local/share/emacs/28.0.50/lisp/calendar/parse-time
/Library/Application Support/Emacs/calendar28/holidays hides /opt/local/share/emacs/28.0.50/lisp/calendar/holidays
/Library/Application Support/Emacs/calendar28/cal-menu hides /opt/local/share/emacs/28.0.50/lisp/calendar/cal-menu
/Library/Application Support/Emacs/calendar28/cal-x hides /opt/local/share/emacs/28.0.50/lisp/calendar/cal-x
/Library/Application Support/Emacs/calendar28/diary-lib hides /opt/local/share/emacs/28.0.50/lisp/calendar/diary-lib

Features:
(shadow sort mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa
epg epg-config gnus-util rmail rmail-loaddefs text-property-search
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils smerge-mode diff diff-mode easy-mmode rect python tramp-sh
tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat
parse-time iso8601 ls-lisp format-spec ffap thingatpt url-parse
auth-source eieio eieio-core eieio-loaddefs password-cache json map
url-vars cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs view time-stamp pcmpl-unix pcmpl-gnu compile
tool-bar cal-julian holidays hol-loaddefs mule-util cal-move derived
cal-menu calendar cal-loaddefs cl-seq cl-extra seq help-fns radix-tree
cl-print debug backtrace help-mode find-func misearch multi-isearch
dired-aux term/xterm xterm byte-opt bytecomp byte-compile cconv
autorevert filenotify dired dired-loaddefs time-date subr-x easymenu
shell pcomplete comint regexp-opt ansi-color ring fringe jka-compr paren
midnight time image cus-start cus-load iso-transl edmacro kmacro cl-macs
cl gv session desktop frameset cl-loaddefs cl-lib advice tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type tabulated-list
replace newcomment text-mode elisp-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch timer select mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame minibuffer
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese composite
charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev
obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue
multi-tty make-network-process emacs)

Memory information:
((conses 16 302871 10754)
 (symbols 48 15543 1)
 (strings 32 47165 1784)
 (string-bytes 1 1964514)
 (vectors 16 20200)
 (vector-slots 8 225743 11443)
 (floats 8 89 792)
 (intervals 56 16600 1270)
 (buffers 992 26))

--
Greetings

  Pete

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
			– Rinzai, ninth century Zen master

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

[Lars Ingebrigtsen]

Peter Dyballa <Peter_Dyballa@Web.DE> 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

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 <larsi@gnus.org>:
> 
> 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.

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

[Peter Dyballa]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]


> Am 9.12.2020 um 14:24 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> 
> 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


[-- Attachment #2.1: Type: text/html, Size: 1284 bytes --]

[-- Attachment #2.2: Did it again.png --]
[-- Type: image/png, Size: 755152 bytes --]

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 <larsi@gnus.org>:
> 
> Can you reproduce this problem with an emacs started with "emacs -Q"?

I failed reproducing the effect with *shell* buffer on the left (and *Messages* on the right) and also with *shell* buffer as single buffer.

--
Greetings

  Pete

Perl—the only language that looks the same before and after RSA encryption.
				- Keith Bostic

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

[Lars Ingebrigtsen]

Peter Dyballa <Peter_Dyballa@Web.DE> 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

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

[Peter Dyballa]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]



> Am 11.12.2020 um 15:47 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> 
> 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.


[-- Attachment #2.1: Type: text/html, Size: 5623 bytes --]

[-- Attachment #2.2: root's tcsh prompt.png --]
[-- Type: image/png, Size: 5811 bytes --]

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

[Lars Ingebrigtsen]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

>  Am 11.12.2020 um 15:47 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
>  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

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

[Peter Dyballa]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]


> Am 11.12.2020 um 16:27 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> 
> 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


[-- Attachment #2.1: Type: text/html, Size: 1528 bytes --]

[-- Attachment #2.2: Once more.png --]
[-- Type: image/png, Size: 122913 bytes --]

[-- Attachment #2.3: And again.png --]
[-- Type: image/png, Size: 131633 bytes --]

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

[Lars Ingebrigtsen]

Peter Dyballa <Peter_Dyballa@Web.DE> 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

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 <larsi@gnus.org>:
> 
> 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.

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

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

Peter Dyballa <Peter_Dyballa@Web.DE> 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:


[-- Attachment #2: Type: image/png, Size: 198022 bytes --]

[-- Attachment #3: Type: text/plain, Size: 715 bytes --]


(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

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

[Peter Dyballa]

> Am 19.12.2020 um 00:18 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> 
> 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:
> 
> <Mail-Anhang.png>
> (It's switching the colours to inverse video here, I guess...)

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

> 
> 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)

--
Greetings

  Pete

These are my principles and if you don't like them... well, I have others.
				- Groucho Marx

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

[Lars Ingebrigtsen]

Peter Dyballa <Peter_Dyballa@Web.DE> 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

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

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 <larsi@gnus.org>:
> 
> 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

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 <larsi@gnus.org>:
> 
> 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

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

[Lars Ingebrigtsen]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> 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.

Thanks for checking; sounds promising.

> 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…

Great.

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> 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.
>
> Thanks for checking; sounds promising.
>
>> 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…
>
> Great.

This was a year ago, so I'm assuming this worked, and I'm therefore
closing this bug report.  If there's more to be done here, please
respond to the debbugs address and we'll reopen.

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