[PATCH 1 of 5] paths: drop ui.status label from output of "hg paths name"

Yuya Nishihara yuya at tcha.org
Thu Jan 14 08:35:09 CST 2016


On Wed, 13 Jan 2016 11:27:01 -0600, Matt Mackall wrote:
> On Wed, 2016-01-13 at 21:28 +0900, Yuya Nishihara wrote:
> > On Tue, 12 Jan 2016 14:46:10 -0600, Matt Mackall wrote:
> > > On Sat, 2016-01-09 at 18:45 +0900, Yuya Nishihara wrote:
> > > > # HG changeset patch
> > > > # User Yuya Nishihara <yuya at tcha.org>
> > > > # Date 1450011240 -32400
> > > > #      Sun Dec 13 21:54:00 2015 +0900
> > > > # Node ID 16099841acaa4fa42dffa994b9ac9e16c89a43be
> > > > # Parent  0db7943a4e1f843814865dc1b2cb22b994acc74f
> > > > paths: drop ui.status label from output of "hg paths name"
> > > > 
> > > > We just need to not print path if --quiet. ui.status label is unwanted.
> > > 
> > > Why?
> > > 
> > > My guess is: we don't have a problem with the label but the formatter
> > > doesn't
> > > support "status" and "note" output levels. That's probably a weakness of the
> > > formatter API. Yep:
> > 
> > Because it isn't a status message, it shouldn't be colorized as 'ui.status',
> > for example.
> 
> A "status message" in Mercurial has always simply been a message that is
> displayed when not quiet, so yes, it is a status message by our convention.
> Here's the code from 0.5 in 2005:
> 
> https://www.selenic.com/hg/file/f40273b0ad7b/mercurial/hg.py#l882
> 
> >  $ hg paths --config color.ui.status=red
> >   default = https://selenic.com/repo/hg/
> >   $ hg paths default --config color.ui.status=red
> >   <red>https://selenic.com/repo/hg/</red>  # why is this red?
> 
> Um, because you told it to be red and Mercurial obeyed your expressed desires?
> 
> (Or maybe it's warning us that the command nonsensically generates no output
> with -q.)
> 
> There are several different questions here that we need to keep carefully
> distinct:
> 
> - what is a status message? (see above)

Hmm, it appears I have different definition about a "message" since the
labeling API was introduced.

  ui.write: data requested by command (e.g. "log" content, list of "files")
  ui.status, .note, .warn, .debug: subsidiary information (e.g. progress of
    communication with peer repository)

Because Mercurial doesn't send .status and .note to stderr, it isn't possible
to extract log content from "hg incoming" output reliably, for example. I use
(or abuse in your sense) "ui.*" label to filter log payload as well as getting
command progress.

> - should this particular output be a status message as defined above?

>From my understanding, it is not a status message. But according to your
definition, it is.

> - should status messages in general be colorizable if a user so chooses?

Not sure. I just showed how ui.status label is working to express my definition
of a "status message."

> - is code that does "if not ui.quiet: ui.write()" bogus because it creates
> non-labeled status messages?

Perhaps no. I don't think "ui.status" label is useful in your definition.
So I would rather remove "ui.*" labels if "ui.status()" is just a conditional
"ui.write()".

> > I agree it will be handy to add a status/note-level fm.condwrite(), but it
> > shouldn't call ui.status() or ui.note().
> 
> Why not? I might like to de-emphasize the more verbose parts of the output so I
> can focus on the important bits.

Because I consider the output of formatter shouldn't be labeled as "ui.status",
from my definition of a "status message".

Regards,


More information about the Mercurial-devel mailing list