|
From: | Dmitry Gutov |
Subject: | bug#43715: 28.0.50; Duplicate results in project-find-regexp |
Date: | Thu, 1 Oct 2020 23:38:01 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 01.10.2020 04:15, Lars Ingebrigtsen wrote:
Dmitry Gutov <dgutov@yandex.ru> writes:The behavior is less than ideal, but the fix will have to satisfy multiple constraints: the xref item creation (taking care of the format being backward-compatible), the rendering of them in the buffer, and the 'xref-query-replace-in-results' command, the implementation of which relies on the one-line-per-match property of an xref buffer.Right. I know next to nothing about xref internals... but... couldn't this function just squash the multiple-matches-on-a-single-line into one line? Preserving the text props from the multiple lines and whatnot? So a post-processing step?
Which function?xref-query-replace-in-results works on an existing xref buffer. And it uses the position of point (at the beginning of line) as both user indicator and to persist the state of the replacement process.
Going back to xref buffers, if two matches are rendered on one line, that leads to a question of how 'n' and 'p' should behave (whether they would also jump between the matches on the same line).
[Prev in Thread] | Current Thread | [Next in Thread] |