GNU bug report logs - #36967
27.0.50; Duplicate lines in xref output

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36967 <at> debbugs.gnu.org
Subject: bug#36967: 27.0.50; Duplicate lines in xref output
Date: Fri, 4 Dec 2020 01:44:47 +0200

On 03.12.2020 23:30, Juri Linkov wrote:
>>> Here is the patch that makes the broken
>>
>> Pretty harsh there.
> 
> But true: I can't use it in the current form, and was waiting
> when someone will fix it.

It's great to see you get this ball rolling.

>> Here's an alternative proposal:
>>
>> Combine the lines inside the rendering code instead.
>>
>> So each xref will have a separate location, but then xref--insert-xrefs
>> will see that xref-location-line value repeats across some consecutive
>> locations, and will combine them into single line with some text property
>> magic (basically, copying the summary from one of them, and then applying
>> 'xref-item and 'face properties appropriately). This retains the xref item
>> semantics (as opposed to, say, associating an xref item with multiple
>> locations). And _hopefully_ the replace-related code won't need
>> any changes.
> 
> I tried to improve xref--insert-xrefs to group matches by lines
> by using the most convenient function seq-group-by.  But then
> noticed that xref.el doesn't rely on seq.el.  Even xref--alistify
> that groups matches by files could be replaced by seq-group-by.
> Is it a requirement to avoid using seq functions in xref.el?

Not really, no. project.el pulls in seq already, why not have xref do it 
too.

I'm _slightly_ worried about extra garbage if we do seq-group-by twice 
(with an extra list for every line, even those that don't need it), but 
that's what benchmarking is for (can do that later).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.