On 22 Nov 2017, at 2:46, Matt Neuburg wrote:
I think I've mentioned this before, but I do wish
it were fixed so I'm
mentioning it again. Sometimes the global Find dialog shows
(correctly) that my search text occurs on a certain line of a certain
file but doesn't show the occurrence. In this screen shot, the first
two occurrences are listed but the found text is at the end of the
line whereas what we are being shown is the start of the line.
I can’t tell from the screenshot, but roughly how many characters are
As the third line shows, this does work sometimes.
It's a great
feature and I've come to rely on it, so I do wish it worked all the
The way it currently works is that it will not show more than 500
characters from the matched line, and if more than 200 characters
precede the match, it will truncate the start of the line to keep it
The reason it doesn’t show the full line and make it horizontally
scrollable is twofold:
1. Horizontally scrolling table views require us to measure the width of
each line (in pixels), to calculate the width of the scroller, this is
expensive so it does not work well when people do searches that returns
hundreds of thousands of results or even numbers in the millions.
2. Including the full line in the result (rather than 500 bytes) is also
a performance problem when people have extremely long lines (like
megabytes) and there are hundreds or thousands of matches in such line,
as the table view would show the same line (that takes up megabytes)
hundreds or thousands of times, leading to accumulated memory usage in
the gigabytes, so again a performance issue.
That said, it should ideally show the matched portion of the line, which
is why I would like to know the exact number of characters preceding the
match and how many of them are displayed, to see if the current
heuristic works and just needs tweaking.