[PATCH 8 of 8 V2] hgweb: add a "followlines" link to hover-box in annotate

Denis Laxalde denis at laxalde.org
Mon Mar 6 04:32:01 EST 2017


Yuya Nishihara a écrit :
> On Wed, 1 Mar 2017 17:36:48 +0100, Denis Laxalde wrote:
>> Yuya Nishihara a écrit :
>>> On Tue, 28 Feb 2017 16:00:44 -0800, Gregory Szorc wrote:
>>>> Also, the page it links to showing the revisions with links to a line range
>>>> filtered diff is good but not great. I imagine developers will complain
>>>> that it requires too many clicks to go to what they want (the actual line
>>>> content). IMO it would be *really* useful if there were a single page
>>>> showing multiple changesets and line range data for either/and a) raw line
>>>> content b) annotate view c) diff view. That way, developers could scroll
>>>> and see all versions of that line range. If you were looking at say the
>>>> history of a function, this would be *extremely* useful compared to loading
>>>> N pages. This improvement could be done as a follow-up and doesn't need to
>>>> block this series.
>>>
>>> When the page gets more dynamically rendered, will we still need the mdiff
>>> filtering function? I guess filtering will be handled by js, and we'll need
>>> to label all chunks instead of filtering them on server side.
>>>
>>> I think the mdiff and patch.diff() APIs are the most controversial part in
>>> this series. If we can go without them, that would be nice.
>>>
>>
>> Maybe filtering can occur in webutil.diffs only, but I seems to me that
>> this would imply parsing diff headers (@@ +start,count -start,count @@).
>> I think that filtering in mdiff/patch.diff is cleaner but I agree that
>> the API is not nice. Also, working on mdiff/patch.diff side will
>> probably be necessary when implementing the command-line version of this
>> feature.
>
> One idea is to attach a context to each chunk so we can filter them later or
> embed in <span data-xxx=""> attribute. For example,
>
>   patch.diff() yields text
>   patch.diffchunks() yields (text, some_line_information)
>

Following your idea, I'll send a series adding a diffhunks function in
patch module. I'll keep it outside this "hgweb" series as it is actually
self-consistent (and large). Once settle, I'll get back to the hgweb part.


More information about the Mercurial-devel mailing list