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.
The occurrences listings are not horizontally scrollable so there seems no way to learn the context.
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.
m.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 11! http://shop.oreilly.com/product/0636920107408.do iOS 11 Fundamentals! http://shop.oreilly.com/product/0636920107415.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
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:
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.
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@lists.macromates.com To:"TextMate users" textmate@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.
On Jun 11, 2018, at 7:34 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 25 Feb 2018, at 4:09, Matt Neuburg wrote:
[…] So maybe this is an edge case of some sort?
Latest (nightly) build has horizontal scroll for search results, so while the lines can still be cut short, the matching part should now always be visible :)
I think I see how this works. We can still truncate _before_ the matching part, but the entire remainder of the line is now available by scrolling horizontally. That's a clever compromise! m.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 11! http://shop.oreilly.com/product/0636920107408.do iOS 11 Fundamentals! http://shop.oreilly.com/product/0636920107415.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
-
Allan Odgaard -
Matt Neuburg -
Matt Neuburg