<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 22 Nov 2017, at 2:46, Matt Neuburg wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">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.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I can’t tell from the screenshot, but roughly how many characters are visible?</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">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 time.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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 below 200.</p>
<p dir="auto">The reason it doesn’t show the full line and make it horizontally scrollable is twofold:</p>
<ol>
<li value="1"><p dir="auto">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.</p></li>
<li value="2"><p dir="auto">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.</p></li>
</ol>
<p dir="auto">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.</p>
</div>
</div>
</body>
</html>