Re: [PATCH 2 of 2 V2] show: new extension for displaying various repository data

[Ryan McElroy]

On 3/25/17 5:22 AM, Yuya Nishihara wrote:

On Thu, 23 Mar 2017 11:38:45 -0400, Augie Fackler wrote:

On Thu, Mar 23, 2017 at 12:16:16AM +0900, Yuya Nishihara wrote:

On Tue, 21 Mar 2017 23:52:42 -0700, Gregory Szorc wrote:

On Tue, Mar 21, 2017 at 11:49 PM, Gregory Szorc 
wrote:


# HG changeset patch
# User Gregory Szorc 
# Date 1490165337 25200
#  Tue Mar 21 23:48:57 2017 -0700
# Node ID 80ca2bee4a06887f918e3328b3f005e4c1cb1ab1
# Parent  ae796e23fd42b036352b298f570af8949c2db2d9
show: new extension for displaying various repository data


Yuya, et al:

Since the default output isn't covered by BC guarantees, we probably want
HGPLAIN to be. I'm not sure what the preferred way to do that should be.
Should I create a separate topic within the template for the plain view?

No idea about BC guarantees vs HGPLAIN. HGPLAIN is to disable user
configuration. If "hg show" is covered by e.g. compat version, we'll only
need to set it to the lowest version if HGPLAIN set.

My vision for `hg show` was that we document it as having explicitly
unstable output and unsuitable for scripting. Perhaps in light of
that, HGPLAIN=1 should cause `hg show` to say `abort: show is only for
humans, you appear to be a robot` or similar.

Makes some sense, but `hg show` would support -Tjson, which is for scripting.


I basically agree, see my comment in my review:

> We should consider aborting if HGPLAIN=1 and no template is 
specified, in fact!


I think that gives us behavior everyone would be fairly happy with: 
abort if HGPLAIN is specified without a template, would would lead to 
unstable output.

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2 V2] show: new extension for displaying various repository data

[Yuya Nishihara]

On Thu, 23 Mar 2017 11:38:45 -0400, Augie Fackler wrote:
> On Thu, Mar 23, 2017 at 12:16:16AM +0900, Yuya Nishihara wrote:
> > On Tue, 21 Mar 2017 23:52:42 -0700, Gregory Szorc wrote:
> > > On Tue, Mar 21, 2017 at 11:49 PM, Gregory Szorc 
> > > wrote:
> > >
> > > > # HG changeset patch
> > > > # User Gregory Szorc 
> > > > # Date 1490165337 25200
> > > > #  Tue Mar 21 23:48:57 2017 -0700
> > > > # Node ID 80ca2bee4a06887f918e3328b3f005e4c1cb1ab1
> > > > # Parent  ae796e23fd42b036352b298f570af8949c2db2d9
> > > > show: new extension for displaying various repository data
> > > >
> > >
> > > Yuya, et al:
> > >
> > > Since the default output isn't covered by BC guarantees, we probably want
> > > HGPLAIN to be. I'm not sure what the preferred way to do that should be.
> > > Should I create a separate topic within the template for the plain view?
> >
> > No idea about BC guarantees vs HGPLAIN. HGPLAIN is to disable user
> > configuration. If "hg show" is covered by e.g. compat version, we'll only
> > need to set it to the lowest version if HGPLAIN set.
> 
> My vision for `hg show` was that we document it as having explicitly
> unstable output and unsuitable for scripting. Perhaps in light of
> that, HGPLAIN=1 should cause `hg show` to say `abort: show is only for
> humans, you appear to be a robot` or similar.

Makes some sense, but `hg show` would support -Tjson, which is for scripting.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2 V2] show: new extension for displaying various repository data

[Yuya Nishihara]

On Tue, 21 Mar 2017 23:52:42 -0700, Gregory Szorc wrote:
> On Tue, Mar 21, 2017 at 11:49 PM, Gregory Szorc 
> wrote:
> 
> > # HG changeset patch
> > # User Gregory Szorc 
> > # Date 1490165337 25200
> > #  Tue Mar 21 23:48:57 2017 -0700
> > # Node ID 80ca2bee4a06887f918e3328b3f005e4c1cb1ab1
> > # Parent  ae796e23fd42b036352b298f570af8949c2db2d9
> > show: new extension for displaying various repository data
> >
> 
> Yuya, et al:
> 
> Since the default output isn't covered by BC guarantees, we probably want
> HGPLAIN to be. I'm not sure what the preferred way to do that should be.
> Should I create a separate topic within the template for the plain view?

No idea about BC guarantees vs HGPLAIN. HGPLAIN is to disable user
configuration. If "hg show" is covered by e.g. compat version, we'll only
need to set it to the lowest version if HGPLAIN set.

> I'm still a bit confused as to how formatters work :/

[...]

> > +@showview('bookmarks', fmtopic='bookmarks')
> > +def showbookmarks(ui, repo, fm):
> > +"""bookmarks and their associated changeset"""
> > +marks = repo._bookmarks
> > +if not len(marks):
> > +ui.write(_('(no bookmarks set)\n'))
> > +return
> > +
> > +active = repo._activebookmark
> > +longest = max(len(b) for b in marks)
> > +
> > +for bm, node in sorted(marks.items()):
> > +fm.startitem()
> > +fm.context(ctx=repo[node])
> > +fm.write('bookmark', '%s', bm)
> > +fm.write('node', fm.hexfunc(node), fm.hexfunc(node))
> > +fm.data(active=bm == active,
> > +_longestlen=longest)

I think the formatter API was designed to make hand-written output formatting
templatable, so the default (plain) output doesn't use template file.

  bookmarkfmt = '%%-%ds' % longest
  fm.write('bookmark', bookmarkfmt, bm)
  fm.write('node', '%s\n', fm.hexfunc_that_uses_shortest(node))

But 'hg show' does use template by default. That's why fm.plain() doesn't work.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 2 of 2 V2] show: new extension for displaying various repository data

[Gregory Szorc]

On Tue, Mar 21, 2017 at 11:49 PM, Gregory Szorc 
wrote:

> # HG changeset patch
> # User Gregory Szorc 
> # Date 1490165337 25200
> #  Tue Mar 21 23:48:57 2017 -0700
> # Node ID 80ca2bee4a06887f918e3328b3f005e4c1cb1ab1
> # Parent  ae796e23fd42b036352b298f570af8949c2db2d9
> show: new extension for displaying various repository data
>

Yuya, et al:

Since the default output isn't covered by BC guarantees, we probably want
HGPLAIN to be. I'm not sure what the preferred way to do that should be.
Should I create a separate topic within the template for the plain view?
I'm still a bit confused as to how formatters work :/


>
> Currently, Mercurial has a number of commands to show information. And,
> there are features coming down the pipe that will introduce more
> commands for showing information.
>
> Currently, when introducing a new class of data or a view that we
> wish to expose to the user, the strategy is to introduce a new command
> or overload an existing command, sometimes both. For example, there is
> a desire to formalize the wip/smartlog/underway/mine functionality that
> many have devised. There is also a desire to introduce a "topics"
> concept. Others would like views of "the current stack." In the
> current model, we'd need a new command for wip/smartlog/etc (that
> behaves a lot like a pre-defined alias of `hg log`). For topics,
> we'd likely overload `hg topic[s]` to both display and manipulate
> topics.
>
> Adding new commands for every pre-defined query doesn't scale well
> and pollutes `hg help`. Overloading commands to perform read-only and
> write operations is arguably an UX anti-pattern: while having all
> functionality for a given concept in one command is nice, having a
> single command doing multiple discrete operations is not. Furthermore,
> a user may be surprised that a command they thought was read-only
> actually changes something.
>
> We discussed this at the Mercurial 4.0 Sprint in Paris and decided that
> having a single command where we could hang pre-defined views of
> various data would be a good idea. Having such a command would:
>
> * Help prevent an explosion of new query-related commands
> * Create a clear separation between read and write operations
>   (mitigates footguns)
> * Avoids overloading the meaning of commands that manipulate data
>   (bookmark, tag, branch, etc) (while we can't take away the
>   existing behavior for BC reasons, we now won't introduce this
>   behavior on new commands)
> * Allows users to discover informational views more easily by
>   aggregating them in a single location
> * Lowers the barrier to creating the new views (since the barrier
>   to creating a top-level command is relatively high)
>
> So, this commit introduces the `hg show` command via the "show"
> extension. This command accepts a positional argument of the
> "view" to show. New views can be registered with a decorator. To
> prove it works, we implement the "bookmarks" view, which shows a
> table of bookmarks and their associated nodes.
>
> We introduce a new style to hold everything used by `hg show`.
>
> For our initial bookmarks view, the output varies from `hg bookmarks`:
>
> * Padding is performed in the template itself as opposed to Python
> * Revision integers are not shown
> * shortest() is used to display a 5 character node by default (as
>   opposed to static 12 characters)
>
> I chose to implement the "bookmarks" view first because it is simple
> and shouldn't invite too much bikeshedding that detracts from the
> evaluation of `hg show` itself. But there is an important point
> to consider: we now have 2 ways to show a list of bookmarks. I'm not
> a fan of introducing multiple ways to do very similar things. So it
> might be worth discussing how we wish to tackle this issue for
> bookmarks, tags, branches, MQ series, etc.
>
> I also made the choice of explicitly declaring the default show
> template not part of the standard BC guarantees. History has shown
> that we make mistakes and poor choices with output formatting but
> can't fix these mistakes later because random tools are parsing
> output and we don't want to break these tools. Optimizing for human
> consumption is one of my goals for `hg show`. So, by not covering
> the formatting as part of BC, the barrier to future change is much
> lower and humans benefit.
>
> There are some improvements that can be made to formatting. For
> example, we don't yet use label() in the templates. We obviously
> want this for color. But I'm not sure if we should reuse the existing
> log.* labels or invent new ones. I figure we can punt that to a
> follow-up.
>
> At the aforementioned Sprint, we discussed and discarded various
> alternatives to `hg show`.
>
> We considered making `hg log ` perform this behavior. The main
> reason we can't do this is because a positional argument to `hg log`
> can be a file path and if there is a conflict between a path name and
> a view 

[PATCH 2 of 2 V2] show: new extension for displaying various repository data

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1490165337 25200
#  Tue Mar 21 23:48:57 2017 -0700
# Node ID 80ca2bee4a06887f918e3328b3f005e4c1cb1ab1
# Parent  ae796e23fd42b036352b298f570af8949c2db2d9
show: new extension for displaying various repository data

Currently, Mercurial has a number of commands to show information. And,
there are features coming down the pipe that will introduce more
commands for showing information.

Currently, when introducing a new class of data or a view that we
wish to expose to the user, the strategy is to introduce a new command
or overload an existing command, sometimes both. For example, there is
a desire to formalize the wip/smartlog/underway/mine functionality that
many have devised. There is also a desire to introduce a "topics"
concept. Others would like views of "the current stack." In the
current model, we'd need a new command for wip/smartlog/etc (that
behaves a lot like a pre-defined alias of `hg log`). For topics,
we'd likely overload `hg topic[s]` to both display and manipulate
topics.

Adding new commands for every pre-defined query doesn't scale well
and pollutes `hg help`. Overloading commands to perform read-only and
write operations is arguably an UX anti-pattern: while having all
functionality for a given concept in one command is nice, having a
single command doing multiple discrete operations is not. Furthermore,
a user may be surprised that a command they thought was read-only
actually changes something.

We discussed this at the Mercurial 4.0 Sprint in Paris and decided that
having a single command where we could hang pre-defined views of
various data would be a good idea. Having such a command would:

* Help prevent an explosion of new query-related commands
* Create a clear separation between read and write operations
  (mitigates footguns)
* Avoids overloading the meaning of commands that manipulate data
  (bookmark, tag, branch, etc) (while we can't take away the
  existing behavior for BC reasons, we now won't introduce this
  behavior on new commands)
* Allows users to discover informational views more easily by
  aggregating them in a single location
* Lowers the barrier to creating the new views (since the barrier
  to creating a top-level command is relatively high)

So, this commit introduces the `hg show` command via the "show"
extension. This command accepts a positional argument of the
"view" to show. New views can be registered with a decorator. To
prove it works, we implement the "bookmarks" view, which shows a
table of bookmarks and their associated nodes.

We introduce a new style to hold everything used by `hg show`.

For our initial bookmarks view, the output varies from `hg bookmarks`:

* Padding is performed in the template itself as opposed to Python
* Revision integers are not shown
* shortest() is used to display a 5 character node by default (as
  opposed to static 12 characters)

I chose to implement the "bookmarks" view first because it is simple
and shouldn't invite too much bikeshedding that detracts from the
evaluation of `hg show` itself. But there is an important point
to consider: we now have 2 ways to show a list of bookmarks. I'm not
a fan of introducing multiple ways to do very similar things. So it
might be worth discussing how we wish to tackle this issue for
bookmarks, tags, branches, MQ series, etc.

I also made the choice of explicitly declaring the default show
template not part of the standard BC guarantees. History has shown
that we make mistakes and poor choices with output formatting but
can't fix these mistakes later because random tools are parsing
output and we don't want to break these tools. Optimizing for human
consumption is one of my goals for `hg show`. So, by not covering
the formatting as part of BC, the barrier to future change is much
lower and humans benefit.

There are some improvements that can be made to formatting. For
example, we don't yet use label() in the templates. We obviously
want this for color. But I'm not sure if we should reuse the existing
log.* labels or invent new ones. I figure we can punt that to a
follow-up.

At the aforementioned Sprint, we discussed and discarded various
alternatives to `hg show`.

We considered making `hg log ` perform this behavior. The main
reason we can't do this is because a positional argument to `hg log`
can be a file path and if there is a conflict between a path name and
a view name, behavior is ambiguous. We could have introduced
`hg log --view` or similar, but we felt that required too much typing
(we don't want to require a command flag to show a view) and wasn't
very discoverable. Furthermore, `hg log` is optimized for showing
changelog data and there are things that `hg display` could display
that aren't changelog centric.

There were concerns about using "show" as the command name.

Some users already have a "show" alias that is similar to `hg export`.

There were also concerns that Git users adapted to