Re: branch master updated (0aa0e1f -> 9b7f9e6)

Re: branch master updated (0aa0e1f -> 9b7f9e6)

[Ludovic Courtès]

Hi Pierre,

guix-commits@gnu.org skribis:

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

>      new 9b7f9e6  ui: Don't truncate search output when inside Emacs.

Hmm, OK.

Ludo’.

Re: branch master updated (0aa0e1f -> 9b7f9e6)

[Pierre Neidhardt]

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

Ludovic Courtès <ludo@gnu.org> writes:

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

This

https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00155.html

and subsequent answers by Zimoun.

I believe the patch works since now colours are back in Eshell! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: branch master updated (0aa0e1f -> 9b7f9e6)

[zimoun]

Hi Ludo,

On Mon, 24 Feb 2020 at 16:33, Ludovic Courtès <ludo@gnu.org> wrote:

> guix-commits@gnu.org skribis:
>
> >      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?

I do not know if we had reached a consensus. :-)

Here [1] is explained the 2 issues. One issue comes from *eshell* and
should be solved upstream, as explained here [2] and has been already
explained by Ricardo there [3]. Upstream bug report is opened, AFAICT,
and merged soon [4].

The other issue is "that the OSC is not always supported and some
terminal emulators are not doing the correct thing. For example EShell
or (incorrectly build) Mate of Trisquel. Therefore, instead of
displaying this special character, just print the full path of the
generation file and the commit url." [5]. And this is not related to
Emacs and/or INSIDE_EMACS but related to the support of the OSC by the
terminal emulator. And the highlighting is another topic.

Well, from my understanding, the question was about the name of this
variable "INSIDE_EMACS" to replace the OSC by the full path and
how/where to document it, see Pierre's message [6] but then Ricardo
answered [7]: "we should not document it in Guix, nor should we rename
it to GUIX_INSIDE_EMACS".

Maybe the misunderstanding comes from there.


[1] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00188.html
[2] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00199.html
[3] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00040.html
[4] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39596
[5] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00164.html
[6] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00029.html
[7] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00031.html


Cheers,
simon

Re: branch master updated (0aa0e1f -> 9b7f9e6)

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Mon, 24 Feb 2020 at 16:33, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> guix-commits@gnu.org skribis:
>>
>> >      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?
>
> I do not know if we had reached a consensus. :-)

More accurately, I think there was no consensus around the proposed
changes.  Ricardo and I argued in favor of honoring ‘INSIDE_EMACS’ and
disabling colors when it is set.

In terms of process, I think it’s a case where we should make sure the
people involved in the discussion can come to an agreement before going
further (info "(guix) Commit Access").

WDYT?

> Here [1] is explained the 2 issues. One issue comes from *eshell* and
> should be solved upstream, as explained here [2] and has been already
> explained by Ricardo there [3]. Upstream bug report is opened, AFAICT,
> and merged soon [4].

Great, thanks for filing upstream bugs!

> The other issue is "that the OSC is not always supported and some
> terminal emulators are not doing the correct thing. For example EShell
> or (incorrectly build) Mate of Trisquel. Therefore, instead of
> displaying this special character, just print the full path of the
> generation file and the commit url." [5]. And this is not related to
> Emacs and/or INSIDE_EMACS but related to the support of the OSC by the
> terminal emulator. And the highlighting is another topic.

As I wrote elsewhere, we avoid working around terminal bugs in Guix
itself.  In this case, the bugs are in an old VTE version and about to
be fixed in Eshell, both of which are good reasons not to try to paper
over it in Guix.

> Well, from my understanding, the question was about the name of this
> variable "INSIDE_EMACS" to replace the OSC by the full path and
> how/where to document it, see Pierre's message [6] but then Ricardo
> answered [7]: "we should not document it in Guix, nor should we rename
> it to GUIX_INSIDE_EMACS".
>
> Maybe the misunderstanding comes from there.

I see reluctance to the proposed changes in
<https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00031.html> (I
agree with Ricardo’s concerns).

To me, that suggests at least that further discussion would have been
needed before pushing these three commits.

What should we do now?

Thanks,
Ludo’.

Re: branch master updated (0aa0e1f -> 9b7f9e6)

[Pierre Neidhardt]

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

Ludovic Courtès <ludo@gnu.org> writes:

> More accurately, I think there was no consensus around the proposed
> changes.  Ricardo and I argued in favor of honoring ‘INSIDE_EMACS’ and
> disabling colors when it is set.
>
> In terms of process, I think it’s a case where we should make sure the
> people involved in the discussion can come to an agreement before going
> further (info "(guix) Commit Access").
>
> WDYT?

I believe that all points have been answered and I waited one week as
usual.

> As I wrote elsewhere, we avoid working around terminal bugs in Guix
> itself.  In this case, the bugs are in an old VTE version and about to
> be fixed in Eshell, both of which are good reasons not to try to paper
> over it in Guix.

None of the changes that I pushed deal with the terminal bugs or with
the Eshell bug.  This is a separate issue.

> I see reluctance to the proposed changes in
> <https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00031.html> (I
> agree with Ricardo’s concerns).

I've addressed Ricardo's points:

- M-x shell font-locking is not influenced by the colors of the programs
  being executed.  M-x shell supports ANSI colors and it's expected of
  programs to display colors.

- PAGER=cat does not do the job as we discussed later.

I believe the changes I pushed are going in the right direction.  Please
let me know if this introduced a regression.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: branch master updated (0aa0e1f -> 9b7f9e6)

[zimoun]

Hi Ludo,


On Mon, 24 Feb 2020 at 21:34, Ludovic Courtès <ludo@gnu.org> wrote:

> >> Forgive me if I missed the discussion, but I thought we had reached
> >> rough consensus in favor of the status quo.  What happened?
> >
> > I do not know if we had reached a consensus. :-)
>
> More accurately, I think there was no consensus around the proposed

Ah sorry, I have not read "rough consensus in favor of the status quo"
as meaning "no consensus" (what I was suggesting :-)).


> changes.  Ricardo and I argued in favor of honoring ‘INSIDE_EMACS’ and
> disabling colors when it is set.

I disagree, that's why the consensus is not reached. As I explained
elsewhere, there is different issues and Emacs is not the main part of
the story.


> In terms of process, I think it’s a case where we should make sure the
> people involved in the discussion can come to an agreement before going
> further (info "(guix) Commit Access").

I agree.
The small diff that I sent here [1] is not even a commit but a fix
that I shared because I was annoyed by the current behaviour.

Speaking about process, I commented one patch [2] but all the comments
are not included (e.g., '(when (not' is ugly and should be replaced by
'unless' as you suggested [3]).
But again, speaking about process, the patches have been announced on
guix-devel [4] in the relative thread.


[1] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00034.html
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39642#17
[3] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00353.html
[4] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00215.html


> > The other issue is "that the OSC is not always supported and some
> > terminal emulators are not doing the correct thing. For example EShell
> > or (incorrectly build) Mate of Trisquel. Therefore, instead of
> > displaying this special character, just print the full path of the
> > generation file and the commit url." [5]. And this is not related to
> > Emacs and/or INSIDE_EMACS but related to the support of the OSC by the
> > terminal emulator. And the highlighting is another topic.
>
> As I wrote elsewhere, we avoid working around terminal bugs in Guix
> itself.  In this case, the bugs are in an old VTE version and about to
> be fixed in Eshell, both of which are good reasons not to try to paper
> over it in Guix.

I disagree. Not about the terminal bugs and where they have to be
fixed, I obviously agree on that.

I disagree on displaying the hyperlink in plain text. I am using xterm
and it does the correct thing about OSC and coloring. But I was not
aware that 'Generation' and 'commit' were hyperlinks and I was
suggesting a rename to NO_SUPPORT_HYPERLINK here [5], "long" before
the patches. :-)

[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38940#29


> > Well, from my understanding, the question was about the name of this
> > variable "INSIDE_EMACS" to replace the OSC by the full path and
> > how/where to document it, see Pierre's message [6] but then Ricardo
> > answered [7]: "we should not document it in Guix, nor should we rename
> > it to GUIX_INSIDE_EMACS".
> >
> > Maybe the misunderstanding comes from there.
>
> I see reluctance to the proposed changes in
> <https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00031.html> (I
> agree with Ricardo’s concerns).

I disagree because the answer is only about Emacs. My concern was
about enabling/disabling OSC/coloring for any terminal emulator.
That's why I suggested NO_SUPPORT_HYPERLINK or whatever else name.


> To me, that suggests at least that further discussion would have been
> needed before pushing these three commits.

I agree.


> What should we do now?

I am fine with reverting for more discussions and/or polishing.


Cheers,
simon

Re: branch master updated (0aa0e1f -> 9b7f9e6)

[Jelle Licht]

Heya,

Ludovic Courtès <ludo@gnu.org> writes:

> [...]
> I see reluctance to the proposed changes in
> <https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00031.html> (I
> agree with Ricardo’s concerns).
>
> To me, that suggests at least that further discussion would have been
> needed before pushing these three commits.
>
> What should we do now?

Please do not re-break guix search in eshell by reverting 9b7f9e6f9;
I've enjoyed the roughly 2 hours of using it for the first time in what
seems like forever.

There is no reasonable workaround for this issue that I know of that has
been proposed, so let us not make the good the enemy of the perfect.

Thanks,
- Jelle

Re: 01/03: ui: Only display link in capable terminals.

[Ludovic Courtès]

Hi!

guix-commits@gnu.org skribis:

> commit d7545a6b538813e88195d084f75a3e87065c999e
> Author: zimoun <zimon.toutoune@gmail.com>
> AuthorDate: Mon Feb 17 14:16:53 2020 +0100
>
>     ui: Only display link in capable terminals.
>     
>     * guix/ui.scm (display-generation): Display generation path on new line.
>     * guix/scripts/describe.scm (channel-commit-hyperlink): Add TRANSFORMER argument.
>     (display-profile-content): Use TRANSFORMER argument to display URL explicitly
>     when terminal does not support hyperlinks.

[...]

> +                   (when (not (supports-hyperlinks?))

“unless”.

> +                     (format #t (G_ "    URL: ~a~%")
> +                             (channel-commit-hyperlink channel commit
> +                                                       (lambda (url msg) url))))))

So people see less information on terminals that support hyperlinks,
right?

I think there should be as much information displayed whether or not the
terminal supports hyperlinks.  Otherwise it can be confusing.
(Especially since we can’t tell whether the terminal really supports
hyperlinks: we don’t know whether it displays clickable links.)

Thoughts?

> --- a/guix/ui.scm
> +++ b/guix/ui.scm
> @@ -1637,7 +1637,7 @@ DURATION-RELATION with the current time."
>      (let* ((file   (generation-file-name profile number))
>             (link   (if (supports-hyperlinks?)
>                         (cut file-hyperlink file <>)
> -                       identity))
> +                       (cut format #f (G_ "~a~%file: ~a") <> file)))
>             (header (format #f (link (highlight (G_ "Generation ~a\t~a")))

I understand it’s a matter of taste, but I’m not a fan of the extra
line here.

Ludo’.

Re: 01/03: ui: Only display link in capable terminals.

[Pierre Neidhardt]

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

Ludovic Courtès <ludo@gnu.org> writes:

> So people see less information on terminals that support hyperlinks,
> right?
>
> I think there should be as much information displayed whether or not the
> terminal supports hyperlinks.  Otherwise it can be confusing.
> (Especially since we can’t tell whether the terminal really supports
> hyperlinks: we don’t know whether it displays clickable links.)
>
> Thoughts?

The file/URL was not displayed in terminals that support hyperlinks.
This was also true before this commit.

The user has to guess that they are clickable.

I agree that displaying the file / URL in all cases and making the
clickable if possible would be an improvement.

>> --- a/guix/ui.scm
>> +++ b/guix/ui.scm
>> @@ -1637,7 +1637,7 @@ DURATION-RELATION with the current time."
>>      (let* ((file   (generation-file-name profile number))
>>             (link   (if (supports-hyperlinks?)
>>                         (cut file-hyperlink file <>)
>> -                       identity))
>> +                       (cut format #f (G_ "~a~%file: ~a") <> file)))
>>             (header (format #f (link (highlight (G_ "Generation ~a\t~a")))
>
> I understand it’s a matter of taste, but I’m not a fan of the extra
> line here.

You mean the "~%" in "~a~%file: ~a"?
How would you like to display it?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/03: ui: Only display link in capable terminals.

[Ludovic Courtès]

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> So people see less information on terminals that support hyperlinks,
>> right?
>>
>> I think there should be as much information displayed whether or not the
>> terminal supports hyperlinks.  Otherwise it can be confusing.
>> (Especially since we can’t tell whether the terminal really supports
>> hyperlinks: we don’t know whether it displays clickable links.)
>>
>> Thoughts?
>
> The file/URL was not displayed in terminals that support hyperlinks.
> This was also true before this commit.
>
> The user has to guess that they are clickable.

The user can hover over it, but VTE, Eterm, etc. make hyperlinks visible
even when you don’t hover over them.

The hyperlink is an enhancement, not a piece of information that was
intended to be displayed upfront.

>>> --- a/guix/ui.scm
>>> +++ b/guix/ui.scm
>>> @@ -1637,7 +1637,7 @@ DURATION-RELATION with the current time."
>>>      (let* ((file   (generation-file-name profile number))
>>>             (link   (if (supports-hyperlinks?)
>>>                         (cut file-hyperlink file <>)
>>> -                       identity))
>>> +                       (cut format #f (G_ "~a~%file: ~a") <> file)))
>>>             (header (format #f (link (highlight (G_ "Generation ~a\t~a")))
>>
>> I understand it’s a matter of taste, but I’m not a fan of the extra
>> line here.
>
> You mean the "~%" in "~a~%file: ~a"?
> How would you like to display it?

I would not display it at all.  I think it’s a bit of clutter that’s
best avoided.

I guess I’m suggesting a revert of this patch.

WDYT?

Ludo’.

Re: 01/03: ui: Only display link in capable terminals.

[Pierre Neidhardt]

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

Ludovic Courtès <ludo@gnu.org> writes:

>> You mean the "~%" in "~a~%file: ~a"?
>> How would you like to display it?
>
> I would not display it at all.  I think it’s a bit of clutter that’s
> best avoided.
>
> I guess I’m suggesting a revert of this patch.

So users of terminals without hyperlink support cannot see this piece of
information?  That's to bad in my opinion.  Better display more than too little.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/03: ui: Only display link in capable terminals.

[Ludovic Courtès]

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> You mean the "~%" in "~a~%file: ~a"?
>>> How would you like to display it?
>>
>> I would not display it at all.  I think it’s a bit of clutter that’s
>> best avoided.
>>
>> I guess I’m suggesting a revert of this patch.
>
> So users of terminals without hyperlink support cannot see this piece of
> information?  That's to bad in my opinion.  Better display more than too little.

I’ve reverted it in c2f9ea2b502a617bb69227d5f858eee9d4288a6a, also
because if was causing a test failure.

The way I see it, it’s on purpose that this piece of information was not
displayed before.  For example, I think ‘guix describe’ should be
to-the-point.

More generally, hyperlinks were introduced as a way to enhance the user
experience for those using capable terminals.  Like for hyperlinks in
HTML, it’s a way to convey additional information; displaying all these
links in addition to the “invisible” hyperlink data can only lead to
clutter IMO, and defeats the point of hyperlinks.

Thoughts?

Ludo’, who’s supposed to be mostly away from keyboard this week.  :-)

Re: 01/03: ui: Only display link in capable terminals.

[Pierre Neidhardt]

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

Hi,

it's fine by me, I'm not too hyped up about this feature.

What do Guix users think?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/03: ui: Only display link in capable terminals.

[zimoun]

Hi Ludo,

On Fri, 28 Feb 2020 at 00:16, Ludovic Courtès <ludo@gnu.org> wrote:

> I’ve reverted it in c2f9ea2b502a617bb69227d5f858eee9d4288a6a, also
> because if was causing a test failure.

I understand and I am fine.
This needs more discussion and polishing.


> The way I see it, it’s on purpose that this piece of information was not
> displayed before.  For example, I think ‘guix describe’ should be
> to-the-point.
>
> More generally, hyperlinks were introduced as a way to enhance the user
> experience for those using capable terminals.  Like for hyperlinks in
> HTML, it’s a way to convey additional information; displaying all these
> links in addition to the “invisible” hyperlink data can only lead to
> clutter IMO, and defeats the point of hyperlinks.

I do not buy your argument. :-)
Hyperlinks means 2 things: how the link is displayed and how to follow
the link. And they are generally connected. If you can click to the
link to follow it then you can display it as you want.
The point is to control how to display the link; whatever the way to follow it.

However, I agree that INSIDE_EMACS is not the right environment
variable to deal with that.


> Ludo’, who’s supposed to be mostly away from keyboard this week.  :-)

Enjoy your holidays! :-)

Cheers,
simon