Re: Check for ANSI compliance

2024-03-11 Thread Simon Tournier
Hi,

On lun., 29 janv. 2024 at 17:44, Ludovic Courtès  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 
Tue, 04 Feb 2020 16:23:43 +0100
id:87blqeml4w@ambrevar.xyz
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blqeml4w@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 
Mon, 24 Feb 2020 16:31:06 +0100
id:87blpom285@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87blpom285@gnu.org

2: Re: 01/03: ui: Only display link in capable terminals.
Ludovic Courtès 
Fri, 28 Feb 2020 00:16:25 +0100
id:87wo87aaeu@gnu.org
https://lists.gnu.org/archive/html/guix-devel/2020-02
https://yhetil.org/guix/87wo87aaeu@gnu.org



Re: Check for ANSI compliance

2024-01-29 Thread Ludovic Courtès
Hi,

Christian Miller  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’.



Check for ANSI compliance

2024-01-17 Thread Christian Miller
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: error: does-not-exist: 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