all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 54307@debbugs.gnu.org
Subject: [bug#54307] [PATCH 0/2] Highlight headings showing what to build/download
Date: Thu, 10 Mar 2022 11:46:12 +0100	[thread overview]
Message-ID: <c931f9d4010363f3084da9aff013d12d0f7199a6.camel@ist.tugraz.at> (raw)
In-Reply-To: <87mthyyush.fsf_-_@gnu.org>

Am Donnerstag, dem 10.03.2022 um 11:19 +0100 schrieb Ludovic Courtès:
> Hi,
> 
> Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis:
> 
> > Am Mittwoch, dem 09.03.2022 um 11:12 +0100 schrieb Ludovic Courtès:
> > > * guix/colors.scm (highlight/warn): New procedure.
> > > * guix/ui.scm (show-what-to-build): Use 'highlight/warn' when
> > > displaying
> > > what would/will be built.
> > highlight/warn sounds somewhat misleading for this use-case. 
> > Should
> > this be highlight/info instead?
> 
> I agree “warn” is misleading, but I don’t find “info” any clearer. 
> :-)
> 
> Maybe ‘highlight-more’ or something?
Highlight more than what?  Looking at (guix diagnostics) we currently
have merely bold for info, bold magenta for warning and bold red for
error.  On a related note, (guix diagnostics) appears a little over-
engineered; it's mostly there to highlight the diagnostic prefix, but
it would also highlight any other non-whitespace argument... is that
really useful?

Anyway, I would suggest using a less "offensive" colour to indicate how
much is being downloaded/built.  Using red or magenta in this case
would signal an error when that's actually the expected behaviour.  My
personal colouring bias would tend towards cyan or green here, although
green itself is already used to signal success and might not be a good
idea either.

While highlight/info on its own really doesn't make sense, it'd make
more sense if we also defined %warning-color, %info-color, %error-color
in colors and simply used them in diagnostics rather than the other way
round and also defined highlight/warning and highlight/error to
complete the pattern.  Once we figure out what we want to do with the
diagnostics, we could even drop them from the exports if the coloring
procedures can be used in their stead.

Cheers




  reply	other threads:[~2022-03-10 10:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09  9:57 [bug#54307] [PATCH 0/2] Highlight headings showing what to build/download Ludovic Courtès
2022-03-09 10:12 ` [bug#54307] [PATCH 1/2] ui: 'show-what-to-build' highlights "The following [...] will be built" Ludovic Courtès
2022-03-09 10:12   ` [bug#54307] [PATCH 2/2] ui: 'show-what-to-build' highlights "would be downloaded" headings Ludovic Courtès
2022-03-09 10:52   ` [bug#54307] [PATCH 1/2] ui: 'show-what-to-build' highlights "The following [...] will be built" Liliana Marie Prikler
2022-03-10 10:19     ` [bug#54307] [PATCH 0/2] Highlight headings showing what to build/download Ludovic Courtès
2022-03-10 10:46       ` Liliana Marie Prikler [this message]
2022-03-13 22:00         ` Ludovic Courtès
2022-03-18 15:10 ` bug#54307: " Ludovic Courtès

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c931f9d4010363f3084da9aff013d12d0f7199a6.camel@ist.tugraz.at \
    --to=liliana.prikler@ist.tugraz.at \
    --cc=54307@debbugs.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 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.