[TxMt] Re: global find dialog not showing occurrences

[Matt Neuburg]

Let's take the first line shown, which says "You can define your
custom view property" and so on. That is _start_ of a paragraph
consisting of 186 characters followed by (and ending with) the target
string.

Similarly the second line shown is the _start_ of a paragraph
consisting of 184 characters followed by (and ending with) the target
string.

So maybe this is an edge case of some sort?

m.

--matt neuburg, phd = http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 10! http://shop.oreilly.com/product/0636920055235.do
iOS 10 Fundamentals! http://shop.oreilly.com/product/0636920055211.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html

----- Original Message -----
From: "TextMate users" <textmate at lists.macromates.com>
To:"TextMate users" <textmate at lists.macromates.com>
Cc:
Sent:Sun, 25 Feb 2018 09:28:57 +0700
Subject:[TxMt] Re: global find dialog not showing occurrences

	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 visible?  

	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.  

	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. 

	The reason it doesn’t show the full line and make it horizontally
scrollable is twofold: 

	* 

	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. 
	* 

	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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20180224/e242ba01/attachment.html>