* Re: branch master updated (0aa0e1f -> 9b7f9e6) [not found] <20200224101817.20439.52918@vcs0.savannah.gnu.org> @ 2020-02-24 15:31 ` Ludovic Courtès 2020-02-24 15:40 ` Pierre Neidhardt 2020-02-24 16:36 ` zimoun [not found] ` <20200224101818.9A1FC206ED@vcs0.savannah.gnu.org> 1 sibling, 2 replies; 14+ messages in thread From: Ludovic Courtès @ 2020-02-24 15:31 UTC (permalink / raw) To: guix-devel, Pierre Neidhardt 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’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch master updated (0aa0e1f -> 9b7f9e6) 2020-02-24 15:31 ` branch master updated (0aa0e1f -> 9b7f9e6) Ludovic Courtès @ 2020-02-24 15:40 ` Pierre Neidhardt 2020-02-24 16:36 ` zimoun 1 sibling, 0 replies; 14+ messages in thread From: Pierre Neidhardt @ 2020-02-24 15:40 UTC (permalink / raw) To: Ludovic Courtès, guix-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch master updated (0aa0e1f -> 9b7f9e6) 2020-02-24 15:31 ` branch master updated (0aa0e1f -> 9b7f9e6) Ludovic Courtès 2020-02-24 15:40 ` Pierre Neidhardt @ 2020-02-24 16:36 ` zimoun 2020-02-24 20:34 ` Ludovic Courtès 1 sibling, 1 reply; 14+ messages in thread From: zimoun @ 2020-02-24 16:36 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix Devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch master updated (0aa0e1f -> 9b7f9e6) 2020-02-24 16:36 ` zimoun @ 2020-02-24 20:34 ` Ludovic Courtès 2020-02-24 21:22 ` Pierre Neidhardt ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Ludovic Courtès @ 2020-02-24 20:34 UTC (permalink / raw) To: zimoun; +Cc: Guix Devel 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’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch master updated (0aa0e1f -> 9b7f9e6) 2020-02-24 20:34 ` Ludovic Courtès @ 2020-02-24 21:22 ` Pierre Neidhardt 2020-02-24 23:00 ` zimoun 2020-02-24 23:45 ` Jelle Licht 2 siblings, 0 replies; 14+ messages in thread From: Pierre Neidhardt @ 2020-02-24 21:22 UTC (permalink / raw) To: Ludovic Courtès, zimoun; +Cc: Guix Devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch master updated (0aa0e1f -> 9b7f9e6) 2020-02-24 20:34 ` Ludovic Courtès 2020-02-24 21:22 ` Pierre Neidhardt @ 2020-02-24 23:00 ` zimoun 2020-02-24 23:45 ` Jelle Licht 2 siblings, 0 replies; 14+ messages in thread From: zimoun @ 2020-02-24 23:00 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix Devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch master updated (0aa0e1f -> 9b7f9e6) 2020-02-24 20:34 ` Ludovic Courtès 2020-02-24 21:22 ` Pierre Neidhardt 2020-02-24 23:00 ` zimoun @ 2020-02-24 23:45 ` Jelle Licht 2 siblings, 0 replies; 14+ messages in thread From: Jelle Licht @ 2020-02-24 23:45 UTC (permalink / raw) To: Ludovic Courtès, zimoun; +Cc: Guix Devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20200224101818.9A1FC206ED@vcs0.savannah.gnu.org>]
* Re: 01/03: ui: Only display link in capable terminals. [not found] ` <20200224101818.9A1FC206ED@vcs0.savannah.gnu.org> @ 2020-02-24 15:35 ` Ludovic Courtès 2020-02-24 16:15 ` Pierre Neidhardt 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Courtès @ 2020-02-24 15:35 UTC (permalink / raw) To: guix-devel, zimoun 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’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 01/03: ui: Only display link in capable terminals. 2020-02-24 15:35 ` 01/03: ui: Only display link in capable terminals Ludovic Courtès @ 2020-02-24 16:15 ` Pierre Neidhardt 2020-02-24 20:38 ` Ludovic Courtès 0 siblings, 1 reply; 14+ messages in thread From: Pierre Neidhardt @ 2020-02-24 16:15 UTC (permalink / raw) To: Ludovic Courtès, guix-devel, zimoun [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 01/03: ui: Only display link in capable terminals. 2020-02-24 16:15 ` Pierre Neidhardt @ 2020-02-24 20:38 ` Ludovic Courtès 2020-02-24 21:23 ` Pierre Neidhardt 0 siblings, 1 reply; 14+ messages in thread From: Ludovic Courtès @ 2020-02-24 20:38 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 01/03: ui: Only display link in capable terminals. 2020-02-24 20:38 ` Ludovic Courtès @ 2020-02-24 21:23 ` Pierre Neidhardt 2020-02-27 23:16 ` Ludovic Courtès 0 siblings, 1 reply; 14+ messages in thread From: Pierre Neidhardt @ 2020-02-24 21:23 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 01/03: ui: Only display link in capable terminals. 2020-02-24 21:23 ` Pierre Neidhardt @ 2020-02-27 23:16 ` Ludovic Courtès 2020-02-28 7:10 ` Pierre Neidhardt 2020-02-28 14:29 ` zimoun 0 siblings, 2 replies; 14+ messages in thread From: Ludovic Courtès @ 2020-02-27 23:16 UTC (permalink / raw) To: Pierre Neidhardt; +Cc: guix-devel 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. :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 01/03: ui: Only display link in capable terminals. 2020-02-27 23:16 ` Ludovic Courtès @ 2020-02-28 7:10 ` Pierre Neidhardt 2020-02-28 14:29 ` zimoun 1 sibling, 0 replies; 14+ messages in thread From: Pierre Neidhardt @ 2020-02-28 7:10 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 01/03: ui: Only display link in capable terminals. 2020-02-27 23:16 ` Ludovic Courtès 2020-02-28 7:10 ` Pierre Neidhardt @ 2020-02-28 14:29 ` zimoun 1 sibling, 0 replies; 14+ messages in thread From: zimoun @ 2020-02-28 14:29 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix Devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-02-28 14:29 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20200224101817.20439.52918@vcs0.savannah.gnu.org> 2020-02-24 15:31 ` branch master updated (0aa0e1f -> 9b7f9e6) Ludovic Courtès 2020-02-24 15:40 ` Pierre Neidhardt 2020-02-24 16:36 ` zimoun 2020-02-24 20:34 ` Ludovic Courtès 2020-02-24 21:22 ` Pierre Neidhardt 2020-02-24 23:00 ` zimoun 2020-02-24 23:45 ` Jelle Licht [not found] ` <20200224101818.9A1FC206ED@vcs0.savannah.gnu.org> 2020-02-24 15:35 ` 01/03: ui: Only display link in capable terminals Ludovic Courtès 2020-02-24 16:15 ` Pierre Neidhardt 2020-02-24 20:38 ` Ludovic Courtès 2020-02-24 21:23 ` Pierre Neidhardt 2020-02-27 23:16 ` Ludovic Courtès 2020-02-28 7:10 ` Pierre Neidhardt 2020-02-28 14:29 ` zimoun
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.