* Check for ANSI compliance
@ 2024-01-17 18:29 Christian Miller
2024-01-29 16:44 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Christian Miller @ 2024-01-17 18:29 UTC (permalink / raw)
To: guix-devel
Hello,
I use the Emacs compilation mode (M-x compile).
For example, the following "M-x compile RET guix build does-not-exist
RET" would result to the following:
--8<---------------cut here---------------start------------->8---
-*- mode: compilation; default-directory: "~/" -*-
Compilation started at Wed Jan 17 19:18:57
guix build does-not-exist
guix build: ^[[1;31merror: ^[[0m^[[1mdoes-not-exist^[[0m: unknown package
Compilation exited abnormally with code 1 at Wed Jan 17 19:18:57
--8<---------------cut here---------------end--------------->8---
It is not only visually, but it actually breaks a feature of the mode,
too. The unknown package error is not detected as an error by the
mode. I also had a case where it detected warnings as errors.
Could we check for ANSI compliance instead of assuming it's presence?
--
Christian Miller
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Check for ANSI compliance
2024-01-17 18:29 Check for ANSI compliance Christian Miller
@ 2024-01-29 16:44 ` Ludovic Courtès
2024-03-08 18:07 ` Simon Tournier
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2024-01-29 16:44 UTC (permalink / raw)
To: Christian Miller, Pierre Neidhardt; +Cc: guix-devel
Hi,
Christian Miller <christian.miller@dadoes.de> skribis:
> I use the Emacs compilation mode (M-x compile).
>
> For example, the following "M-x compile RET guix build does-not-exist
> RET" would result to the following:
>
> -*- mode: compilation; default-directory: "~/" -*-
> Compilation started at Wed Jan 17 19:18:57
>
> guix build does-not-exist
> guix build: error: does-not-exist: unknown package
>
> Compilation exited abnormally with code 1 at Wed Jan 17 19:18:57
>
> It is not only visually, but it actually breaks a feature of the mode,
> too. The unknown package error is not detected as an error by the
> mode. I also had a case where it detected warnings as errors.
>
> Could we check for ANSI compliance instead of assuming it's presence?
That used to be the case until commit
672d3d4a87839b0692c307df0edb66cd16bcbf1a, which enabled colors even when
‘INSIDE_EMACS’ is set.
Pierre, do you remember what the rationale was?
Ludo’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Check for ANSI compliance
2024-01-29 16:44 ` Ludovic Courtès
@ 2024-03-08 18:07 ` Simon Tournier
0 siblings, 0 replies; 3+ messages in thread
From: Simon Tournier @ 2024-03-08 18:07 UTC (permalink / raw)
To: Ludovic Courtès, Christian Miller, Pierre Neidhardt; +Cc: guix-devel
Hi,
On lun., 29 janv. 2024 at 17:44, Ludovic Courtès <ludo@gnu.org> wrote:
> That used to be the case until commit
> 672d3d4a87839b0692c307df0edb66cd16bcbf1a, which enabled colors even when
> ‘INSIDE_EMACS’ is set.
>
> Pierre, do you remember what the rationale was?
I am not Pierre. :-) The context seems:
Guix search, colors and INSIDE_EMACS
Pierre Neidhardt <mail@ambrevar.xyz>
Tue, 04 Feb 2020 16:23:43 +0100
id:87blqeml4w.fsf@ambrevar.xyz
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blqeml4w.fsf@ambrevar.xyz
Quoting [1]:
--8<---------------cut here---------------start------------->8---
> new d7545a6 ui: Only display link in capable terminals.
> new 672d3d4 ui: Don't disable colors when INSIDE_EMACS is set.
Forgive me if I missed the discussion, but I thought we had reached
rough consensus in favor of the status quo. What happened?
--8<---------------cut here---------------end--------------->8---
Then quoting [2]:
--8<---------------cut here---------------start------------->8---
I’ve reverted it in c2f9ea2b502a617bb69227d5f858eee9d4288a6a, also
because if was causing a test failure.
--8<---------------cut here---------------end--------------->8---
where c2f9ea2b502a617bb69227d5f858eee9d4288a6a reads,
--8<---------------cut here---------------start------------->8---
Revert "ui: Only display link in capable terminals."
This reverts commit d7545a6b538813e88195d084f75a3e87065c999e.
The commit led to a test failure in 'tests/guix-package-net.sh'. It
also led to disagreements discussed here:
https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00353.html
Reverting until these are addressed.
--8<---------------cut here---------------end--------------->8---
and thus 672d3d4 had not been reverted. Let revert it since it does not
make sense without d7545a6, IMHO.
Cheers,
simon
1: Re: branch master updated (0aa0e1f -> 9b7f9e6)
Ludovic Courtès <ludo@gnu.org>
Mon, 24 Feb 2020 16:31:06 +0100
id:87blpom285.fsf@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blpom285.fsf@gnu.org
2: Re: 01/03: ui: Only display link in capable terminals.
Ludovic Courtès <ludo@gnu.org>
Fri, 28 Feb 2020 00:16:25 +0100
id:87wo87aaeu.fsf@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87wo87aaeu.fsf@gnu.org
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-03-11 14:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-17 18:29 Check for ANSI compliance Christian Miller
2024-01-29 16:44 ` Ludovic Courtès
2024-03-08 18:07 ` Simon Tournier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.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).