[Widget] Find in note cltr+f

[antoniotejada]

I wrote a Find in note widget to replace the crappy ctrl+f search.

• Works on code and text notes.
• Hardcoded keys:
  • F3/ctrl+f, to start a search (you will need to disable ctrl+f shortcut in Trilium shortcut dialog box so the widget can receive it).
  • F3/enter shift+f3/shift+enter to go to the next/prev occurrence
  • esc or click on note to end the search and go back to the note
• Doesn't work on readonly notes, no firm plans to make it work there.
• If you want to disable it in a note, use the label noFindWidget

Todos:

• Refactoring, code cleanup
• Regexp, case, whole word search.
• Find & Replace

https://github.com/antoniotejada/Trilium-FindWidget

Video

sandbox.-.Trilium.Notes.2022-04-22.15-41-19_rescaled.mp4

[antoniotejada]

Awesome sauce.

[sigaloid]

For the time being it only works on notes tagged with #findWidget

You can go to the root note, add the #findWidget attribute, and mark it as inheritable. Then every note will have that tag 😄

[antoniotejada]

Good trick!

FWIW, the tag is just a safety measure while I'm developing it, if you are so confident in the widget :-)) another option is to remove that condition from the code (ctrl+f ;-) in the widget code for "hasLabel" and remove it).

isEnabled() {
        return super.isEnabled()
            && ((this.note.type === 'text') || (this.note.type === 'code'))
            && this.note.hasLabel('findWidget');
}

[antoniotejada]

Perf update for CodeMirror: Bracketed all codemirror markText calls inside an operation(), this batches the calls and increases the speed from a few seconds to unnoticeable when searching for single char strings in this ~500 line script

antoniotejada/Trilium-FindWidget@be70b3d

[antoniotejada]

Fixed bug when there are multiple code-editors (in inactive tabs). Need to get all the code-editor components and find the one for the active tab note.

antoniotejada/Trilium-FindWidget@ed59338

[zadam]

That's pretty impressive! I originally wanted to use CKEditor/CodeMirror native dialogs, but the CKEditor bug (which prevents CTRL+F from working) is not getting fixed so I might use your solution (if you agree). Having consistent UI for both text notes and code notes is a nice bonus!

[antoniotejada]

Hi, some comments:

glob.appContext.getComponentByEl returns only one component when several match

I don't really understand this point. There can't be several matches, one DOM element is owned by one component.

getComponentByEl doesn't take an element as parameter, as written it takes a selector:

return $(el).closest(".component").prop('component');

the result of a selector can be multiple elements. Taking a selector is actually what you want so you can get a result array and then filter by noteId, since AFAIK you cannot express a noteId filter as a selector. Even if you could express filter by noteId as a selector, it could still return an array if two splits are displaying the same note.

Eg

glob.appContext.getComponentByEl(".note-detail-code:visible")

is what you would have to do to get the visible code editors, which will be several if you have splits. The current code is returning the first element of the array and ignoring the rest.

You could do the jquery .note-detail-code:visible yourself and then pass the resulting element just for getComponentByEl to add a .closest(".component") selector, but then the function is not very useful and complicates the code more than anything, you may as well add the .component selector to your original query (which is what I'm doing at the moment).

api.getActiveTabTextEditor calls the callback once for each of the split panes, not just for the "active".

That's a bug. Splits is a relatively new feature and this wasn't caught yet. Fixed now in master.

return this.$widget.is(":visible") && this.noteContext?.ntxId === appContext.tabManager.activeNtxId;

Isn't that the same noteId comparison I've already mentioned and that it doesn't work when two splits are displaying the same note?

While we are there, another wrong thing with api.getActiveTabTextEditor is that it should state that it runs deferred and return a promise, since the callback is deferred. That deferral keeps biting me when I put code after the callback that because of the deferral ends up running before the callback.

api.getActiveTabNote returns only one note, which is what it should do, but I don't see a way to go from that note to the HTML where it's being rendered when two splits show the same note.

Am I correct in assuming that you need it for read only notes? Since for e.g. editable notes you seem to be fine using just the CKEditor instance. I guess some new API would be needed for that.

Once getActiveTabTextEditor has been fixed to work with splits, then I need it for any note that is not CKEditor:

• CodeMirror notes
• Read only notes
• ...

The tabManager tab doesn't show the active note title when there's a split, only the first one.

That's kind of intended. The first one is "main", the other splits are sort of helping splits. IMHO changing tabs based on active split would make it more difficult to use.

FWIW to deal that, other tools (eg vscode) organize the split at the tab parent level, not at the tab child level: each split gets its own set of tabs.

There's no visual cue to which note is the active one in a split (other than the cursor, if the note is writeable, and if the cursor is in view). You can look at the tree, but again won't work with same-note splits.

I agree, I did not find a subtle but useful way to indicate that. Maybe graying out (a little bit) the inactive splits?

I think Trilium requires a more general "focus" rectangle, you also have same problem trying to tell if you are focused on the tree or on the note. The only one that has a focus rect is the note title, maybe you should add a similar rect to the note and the tree. Things only get worse as you add more widgets that can be focused (the FindWidget does have a focus rect).

There's no visual cue to what tabs are split in tabManager unless you activate the tab and see that it has splits.

I'm not decided if this is really needed, or it's more visual noise.

I'm not sure I have a good use case for splits yet either, I'm just trying to support them for completeness.

What I'm dying for is a diff in the revision dialog box, if you want to look into that I recommend google's diff-match-patch. I've used it to do incremental saving in my automatic version saving plugin for vscode and reducing the storage by 99% (you store the most recent version full, then the previous version as a delta, the previous previous as a delta vs. previous, etc). With that method I don't need a limit on the number of versions, since each version takes almost no space (if the diff takes more space than the full version I store the full version instead, this also makes it compatible with a safe approach that stores all versions fully).

I tried other libraries and had horrible corner cases taking 10s of seconds to do a 10 line diff.

[antoniotejada]

api.getActiveTabTextEditor calls the callback once for each of the split panes, not just for the "active".

That's a bug. Splits is a relatively new feature and this wasn't caught yet. Fixed now in master.

return this.$widget.is(":visible") && this.noteContext?.ntxId === appContext.tabManager.activeNtxId;
Isn't that the same noteId comparison I've already mentioned and that it doesn't work when two splits are displaying the same note?

Ah, I thought ntxId was just a shorter version of noteId, but looks like it's not, every split has a different ntxId even if they hold the same noteId. Not only that but ntxId is part of the data attribute of note-split, so I can indeed easily build a selector to get to the component:

$(".note-split[data-ntx-id=zJLH] .note-detail-editable-text.component").prop('component').componentId
'comp-editable_text-ieVaarx2'

which is equivalent to

glob.appContext.getComponentByEl(".note-split[data-ntx-id=zJLH] .note-detail-editable-text").componentId
'comp-editable_text-ieVaarx2'

so that should indeed fix the split ambiguity.

[zadam]

getComponentByEl doesn't take an element as parameter, as written it takes a selector:

No, it takes a DOM element (indicated by "el" naming, which is kind of JS naming standard). Because of jQuery overloaded $ function, you can pass also selector, but then it does something a bit different.

Ah, I thought ntxId was just a shorter version of noteId, but looks like it's not, every split has a different ntxId even if they hold the same noteId. Not only that but ntxId is part of the data attribute of note-split, so I can indeed easily build a selector to get to the component:

No, it's a shortcut for "NoteContextId". You could see "Split" as a UI manifestation of NoteContext, for most purposes they are 1:1.

[antoniotejada]

No, it takes a DOM element (indicated by "el" naming, which is kind of JS naming standard). Because of jQuery overloaded $ function, you can pass also selector, but then it does something a bit different.

If it's supposed to take an element then I don't see the usefulness of the function, how are you supposed to use it? For example for the cases I've mentioned where you want to get the code editor given a ntxId. Because if I have to do a manual jquery myself to find the code editor DOM element and then call that function just to get the .component, it's pretty useless. That manual jquery is already tying me to the current CSS implementation enough that adding an extra .component selector instead of using getComponentByEl is not going to make it less implementation dependent.

The only usage I've found (which in itself it's telling), in #272, is with a selector, which is what makes sense.

[zadam]

I guess first thing is that this function isn't actually part of the documented "script API" published in the api object. It is used in the custom CKEditor plugins in the Trilium's CKEditor build.

The intended use is that you'll get an element in some way (e.g. in onclick handler) and you can get the component which owns the clickable element.

I think you're struggling because the Script API in Trilium is not complete, especially for the more advanced cases like yours (one component accessing "private" elements of another component). I'm looking at ways to fix that.

[XXXJetfireXXX]

Doesn't work on readonly notes, no firm plans to make it work there.

Maybe make it so that if the note has #readonly or is too long and doesn't have #autoReadOnlyDisabled it would automatically enter the edit mode when you press Ctrl+F?
Just like if you did this manually:

[antoniotejada]

That's an intriguing hack. I may or may not look into that...

[antoniotejada]

Updated

• bugfixes for splits
• added some asserts
• showDebug is now taken from the script's #debug label
• finalized user interaction (initializing search from selected text or previous search...)
• changed all key events to keydown
• fixed word highlight overriding search highlight in codemirror

The only missing part of the main functionality is starting the search from the current cursor position.

antoniotejada/Trilium-FindWidget@070ae33

[antoniotejada]

Updated

• finalized user interaction: search now starts at cursor position.
• removed findWidget guard, turned into noFindWidget
• fixed ctrlKey vs. controlKey bug
• removed old prevFocus stuff, switched initialization to check on findbox being shown.

antoniotejada/Trilium-FindWidget@42223ba

[antoniotejada]

Deleted gist and moved to my repo https://github.com/antoniotejada/Trilium-FindWidget