Highlighting for log & graphlog - mercurial_devel

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Highlighting for log & graphlog
Received-SPF: neutral (google.com: 173.11.57.241 is neither permitted nor denied by best guess record for domain of mercurial-devel-boun...@selenic.com) client-ip=173.11.57.241;
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type:content-transfer-encoding;
	b=cDIx+AOgehVFaEyzLl5O8TDzf4dAp146nv1OonUhae/2ew91eabN5PeeDCsY/pivH0
	9S74RWgVHulXY0hp5sSPoxB49rHw5xMxLc/kTd8CwLhEL+r8zS6BCSY44tslD/n+dg/U
	e7fQ5vshm9adU25v5B/oefZQEkuk2RPM7Rk1c=
MIME-Version: 1.0
In-Reply-To: <1304543437.13032.176.camel@calx>
References: <patchbomb.1304262...@dookie.local>
	<1304451254.13032.59.camel@calx>
	<BANLkTim_pw611LEkAmk2pgrOiUehbqv...@mail.gmail.com>
	<1304452373.13032.66.camel@calx>
	<BANLkTimFYYHEsdY7E5KuutqRkmagxvy...@mail.gmail.com>
	<1304454378.13032.69.camel@calx>
	<BANLkTimXr97MQs+RsH4q3NFU9EaJnV1...@mail.gmail.com>
	<1304543437.13032.176.camel@calx>
From: Peter Arrenbrecht <peter.arrenbre...@gmail.com>
Date: Thu, 5 May 2011 07:15:12 +0200
Message-ID: <BANLkTimpU8qZ6C_3MNu4dvrbrZqDeEO...@mail.gmail.com>
Subject: Re: [PATCH 0 of 3] Highlighting for log & graphlog
To: Matt Mackall <m...@selenic.com>
Cc: Dan Villiom Podlaski Christiansen <dan...@gmail.com>,
	Alexander Solovyov <pira...@piranha.org.ua>,
	Mercurial Devel <mercurial-de...@selenic.com>
Precedence: list
Reply-To: peter.arrenbre...@gmail.com
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: mercurial-devel-boun...@selenic.com
Errors-To: mercurial-devel-boun...@selenic.com

On Wed, May 4, 2011 at 11:10 PM, Matt Mackall <m...@selenic.com> wrote:
> On Wed, 2011-05-04 at 16:34 +0200, Peter Arrenbrecht wrote:
>> On Tue, May 3, 2011 at 10:26 PM, Matt Mackall <m...@selenic.com> wrote:
>> > On Tue, 2011-05-03 at 22:00 +0200, Benoit Boissinot wrote:
>> >> On Tue, May 3, 2011 at 9:52 PM, Matt Mackall <m...@selenic.com> wrote:
>> >> > On Tue, 2011-05-03 at 21:45 +0200, Benoit Boissinot wrote:
>> >> >>
>> >> >> It is nice for example with "outgoing()", I can easily see how the
>> >> >> outgoing csets fit into the whole graph.
>>
>> I'm the one who suggested the feature. It was triggered by Benoit's
>> suggestion that we have a "sample(undecidedset)" revset to visualize
>> how set discovery takes samples. But there's other uses. Basically, it
>> boils down to being able to see things in context:
>>
>> =A0* Where was this file touched, on what lines development?
>> =A0* Same for authors.
>> =A0* Highlight all ancestors/descendants of this node.
>> =A0* Highlight this named branch.
>>
>> In fact, I think we should maybe revisit the decision to try and align
>> log and glog. log is very much about speed and thus always walks the
>> changelog in revnum order. For glog, however, I think we should value
>> versatility over raw speed. It's a DAG visualizer. Once we see it as
>> such, we can do things like:
>>
>> =A0* Walk from all heads in breadth-first manner to get an overview of
>> what the heads are (maybe not exactly breadth-first, but a couple of
>> nodes at a time).
>> =A0* Use the linearizing toposort of shrink-revlog and combine it with
>> the elision of linear runs (an old patch of mine) to get a concise
>> overview of branching/merging in a tree.
>>
>> glog is very much about DAGs. I already took a first step in the
>> direction of making DAGs first class with dagutil.py (introduced by
>> set discovery). Benoit is working on moving the shrink-revlog toposort
>> there. Maybe we could also move Patrick's "redagging" (rebuilding a
>> DAG from a disconnected revset) there. So the more general DAG algos
>> would be clearly separate from visualizing them.
>
> Teaching revlog's sort() about toposort might be useful.
>
>> Then we could base glog on the DAGs exposed by dagutil. And we could
>> also easily add support for other visualizers like dot (which should
>> be configurable so it immediately launches a renderer and viewer) and
>> hgweb.
>>
>> This way, glog and other visualizers could make the power of revsets
>> even more awesome.
>
> I'm all for making glog cool. But I disagree about aligning it with log.
> People are going to continue to expect feature parity with log where it
> makes sense. And the current implementation of log is horrendous to the
> point where it's no longer maintainable. By being reimplemented in terms
> of revsets, I think graphlog has already passed it up.
>
> Check this out:
>
> $ time hg log -b stable -q | wc
> =A0 1238 =A0 =A01238 =A0 23481
>
> real =A0 =A00m2.564s
> user =A0 =A00m2.413s
> sys =A0 =A0 0m0.100s
>
> $ time hg log -r 'branch(stable)' -q | wc
> =A0 1238 =A0 =A01238 =A0 23481
>
> real =A0 =A00m2.145s
> user =A0 =A00m2.040s
> sys =A0 =A0 0m0.073s
>
> Revsets are faster (and much more powerful) than log's engine, and
> that's even before the optimizer has gotten the chance to do anything
> clever. The current log code wants to die, though we'll need to teach
> revsets a bit about the file fast path first.

Ah, wow! I have obviously not always been paying attention at the sprint.

>> >> > It's kind of problematic to me that on a stock install (ie color not
>> >> > enabled), -H is a no-op. If we do something like this, it should a)=
 have
>> >> > a meaningful non-color effect and b) have an appropriate non-color =
name.
>> >> > See <em> vs <i> in HTML for comparison.
>> >>
>> >> If you don't have color enabled, you won't see -H.
>> >
>> > Then I'd say it's too invasive of the core. Either it's general-purpose
>> > or it shouldn't be making the log core even hairier.
>>
>> It could, for instance, use a different node character like * for
>> highlighted nodes (like we use @ today for the dirstate parents). Or
>> we could allow folks to specify a prefix to use for the next text,
>> with a default taken from graphlog.highlightprefix.
>
> Ok, let's figure that out. Here's a plan of attack:
>
> - come up with a display-neutral name for the feature (compare <em> and
> <i> in HTML)
> - come up with a sensible way to display emphasized changesets (or
> whatever we call them) in plain text
> - implement the color part of it
>
> Note that whatever we do for plain text (ie prefix with a * or indent or
> whatever), we'll probably need to preserve when we turn color on to
> minimize surprise.
>
> Just so we have a concrete proposal to discuss, here's my take on '*'
> prefixing:
>
> o =A0 =A0changeset: =A0 14183:333def42e785
> |\ =A0 tag: =A0 =A0 =A0 =A0 qparent
> | | =A0parent: =A0 =A0 =A014181:bf951d58b917
> | | =A0parent: =A0 =A0 =A014182:ec5886db9dc6
> | | =A0user: =A0 =A0 =A0 =A0Matt Mackall <m...@selenic.com>
> | | =A0date: =A0 =A0 =A0 =A0Wed May 04 08:21:50 2011 -0500
> | | =A0summary: =A0 =A0 merge with crew
> | |
> | o =A0* changeset: =A0 14182:ec5886db9dc6
> | | =A0* parent: =A0 =A0 =A014160:fa2b596db182
> | | =A0* user: =A0 =A0 =A0 =A0Sune Foldager <c...@cyanite.org>
> | | =A0* date: =A0 =A0 =A0 =A0Wed May 04 13:37:41 2011 +0200
> | | =A0* summary: =A0 =A0 tests: fix deprecated use of hg debugdata/debug=
index
> | |
> o | =A0 =A0changeset: =A0 14181:bf951d58b917
> |\ \ =A0 parent: =A0 =A0 =A014180:1123bbba278d
> | | | =A0parent: =A0 =A0 =A014159:31ec4d7eb63f
> | | | =A0user: =A0 =A0 =A0 =A0Matt Mackall <m...@selenic.com>
> | | | =A0date: =A0 =A0 =A0 =A0Tue May 03 22:04:23 2011 -0500
> | | | =A0summary: =A0 =A0 merge with stable
>
> There are other possibilities like adding a new column 0:
>
> =A0o =A0 =A0changeset: =A0 14183:333def42e785
> =A0|\ =A0 tag: =A0 =A0 =A0 =A0 qparent
> =A0| | =A0parent: =A0 =A0 =A014181:bf951d58b917
> =A0| | =A0parent: =A0 =A0 =A014182:ec5886db9dc6
> =A0| | =A0user: =A0 =A0 =A0 =A0Matt Mackall <m...@selenic.com>
> =A0| | =A0date: =A0 =A0 =A0 =A0Wed May 04 08:21:50 2011 -0500
> =A0| | =A0summary: =A0 =A0 merge with crew
> =A0| |
> * | o =A0changeset: =A0 14182:ec5886db9dc6
> * | | =A0parent: =A0 =A0 =A014160:fa2b596db182
> * | | =A0user: =A0 =A0 =A0 =A0Sune Foldager <c...@cyanite.org>
> * | | =A0date: =A0 =A0 =A0 =A0Wed May 04 13:37:41 2011 +0200
> * | | =A0summary: =A0 =A0 tests: fix deprecated use of hg debugdata/debug=
index
> =A0| |
> =A0o | =A0 =A0changeset: =A0 14181:bf951d58b917
> =A0|\ \ =A0 parent: =A0 =A0 =A014180:1123bbba278d
> =A0| | | =A0parent: =A0 =A0 =A014159:31ec4d7eb63f
> =A0| | | =A0user: =A0 =A0 =A0 =A0Matt Mackall <m...@selenic.com>
> =A0| | | =A0date: =A0 =A0 =A0 =A0Tue May 03 22:04:23 2011 -0500
> =A0| | | =A0summary: =A0 =A0 merge with stable

I like the new column 0 idea very much. As for display-neutral names,
I'm not a native speaker. Highlighting seems OK to me. Or, as you say
in the <em> comparison, an emphasis on some nodes. Your column 0 also
would allow one to support multiple emphasized revsets with different
labels (which could then be called a glog annotation):

  hg glog --em 'branch(A)' --label A --em 'branch(B)' --label B

Then the actual highlighting machinery might define multiple color
specs like em1, em2, etc. in hgrc for this.
-parren
_______________________________________________
Mercurial-devel mailing list
Mercurial-de...@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
