From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: branch master updated (0aa0e1f -> 9b7f9e6)
Date: Tue, 25 Feb 2020 00:00:41 +0100 [thread overview]
Message-ID: <CAJ3okZ2Cke8X9TwDu7qNgD_g3g3p4aAVZxs5p7a_L_8E6=6WsA@mail.gmail.com> (raw)
In-Reply-To: <87v9nvg1wf.fsf@gnu.org>
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
next prev parent reply other threads:[~2020-02-24 23:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ3okZ2Cke8X9TwDu7qNgD_g3g3p4aAVZxs5p7a_L_8E6=6WsA@mail.gmail.com' \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).