I’m a bit lost here. The find result’s pop-over looks sparse because your test file has notes with no $Text. The second line of a match in the pop-up is the (first) $Text match shown highlighted, i.e. in context. It isn’t designed to be some sort of dynamic.
I think this needs exploration in a more real-world content of a large outline with notes with $Text and thousands of notes. I suspect things might get a bit laggy or pull overall resource (I’ve usual lots of other large apps/data open too. I mention this as the description seems to be part-way to a recommender system "People who type ‘3’ probably want to look for. But if we find ourselves asking the toll thinks like “where is that note I used sometime last week?” without knowing how that might be resolved as a query, I think that’s a wet-ware problem. I take such things as Nature’s prompt that I need to add some additional metadata to capture (thought) state.
There is also an element here of blind typing being parsed, character by character, on the fly for each new character into a query. I wonder how efficient that is. IOW, I may imagine the process but if made will it work as smoothly as in the mind’s eye? I can’t answer that as it’s an engineering issue, but think it useful to surface that possible constraint, if only to resolve it before going further.
I understand the idea re tinkering with outline expansion/collapse, but I’d not be happy if that appraoch wasn’t an option I couldn’t turn off. Tinderbox has a host of shortcuts for outline expansion control as well as the disclosure triangle. If knowing where one is depends on the precise arrangement of part of the outline, again, I’d treat that as a wet-ware issue to resolve in my use of the app. Else, I’m asking the poor app to guess my intent and I’m not sure that’s good use of engineering cost compared to other improvements.
Tinderbox is inherently multi-viewed so we need to consider how these behaviour affect views like map/chart/treemap and how the view context will change. The selected note does not have to be in current view scope—it is selected but the selection contect is merely off-screen.
It feels to me that the issue here, if completed, is more than a querying (‘finding’) issue but of context control linked to querying activity. That seems with all the edge case problems already described.
Maybe it’s time to bring back the history view (as in the pre-v6 app), though if people use a lot of aliases I suspect there are some context-guessing edge cases in that too.
BTW, though I’m tugging at loose threads here, it’s not out of plain antipathy to the idea, but just figuring out how the mind’s-eye concept maps to real use.
I’d point out that from the contextual menu in “Find” with a result selected, we have the options to open a text window for that selected note, or open that selected note in a new tab. I don’t see why that feature doesn’t satisfy the “look at a note then return to what I was doing” requirement.
Many times Tinderbox has the features we want, even if we haven’t discovered them. Ask.
Thanks for pointing out the right click option @PaulWalters which I did not know about. I’ve done some experimenting.
For use case 2 (examine contents of found note and decide whether to move to it or not): tear-away the find window + right click the note of interest, look at the text window, Cmd+w to close the text window and either left-click on note in Find tear-off window (to move to that note), or, Cmd+w (to close find window and return to original)
For use case 3 (to consult a note and return to original context): right-click note in find window (no need to tear away), select text note, check contents of text note, Cmd-w to close text window and esc to return to original context.
This is a few more clicks/keys that I would like but I can live with that. Kudos to @mwra for the page on Find results pop-over which accurately describes the right click option. The remaining step on my side was putting the elements together in the use context above.
I think we can close the discussion on Find and we’ve also circumscribed the options to augment Blind Typing.
If I recall (as a user/tester at the time) is was considered hardly used: for deeper metrics on that you’d have to ask Eastgate. At the same time, v5 → v6 mean a complete ground-up rebuild of the app due to the framework and UI paradigm shift (at the time multi-window apps were `old’—I still miss the flexibility they offered). Anyway, any think that had to be built was a contributory engineering cost (time, $) both for initial code and through-life support, so pruning apparently moribund parts of the app made sense.N.B. the app was first made in 2001 so a lot has changed over time: the tools, the OS, the app design frameworks, our use of Macs, the internet/Web, out expectations for tools, etc. At c.20 years old, Tinderbox is venerable and it also draws on ideas from Storyspace (which dates from 1987 but started design c.1984) and other early hypertext systems.
If yuo want to get a feel for the app’s UI along the way see Origin of aTbRef which has links to the six previous aTbRef ‘versions’ I keep online for:
