Keyboard-friendly Find (ESC behaviour)

I’d like to see Find (cmd-f) be made more keyboard-friendly.

Current Behavior

  • With focus in a note, in editor mode, type cmd-f: this opens the Find mini-dialog at the base of the note’s pane
  • Enter text to be searched for
  • Hit enter
  • If found, the pane scrolls to the found text and the search text is selected
  • Optionally keep hitting enter to loop thru multiple matches if they exist until the desired instance is selected
  • At this point, focus is still inside the Find dialog. If I hit esc, the Find dialog disappears but focus is not in the edit area
  • I can hit alt-shift-tab to move focus to the edit area, but the cursor is wherever it was immediately preceding the Find invocation, not at the found matching text

Change Request

  • What I’d like to be able to do is hit esc to make the Find dialog disappear and have focus be on the edit area, with the cursor at the end of the selected text (as if I had selected it manually), so that I am positioned to do whatever it was that I came here for

(Bonus: this behavior change will also make certain keyboard macros easier (until API is available) - can’t currently use Find with them effectively)

Thanks!

27 Likes

Steps to reproduce

Type Cmd-F
Type your search term
Type Return
Type Esc

Expected result

Cursor should be on the search term that was found, so I can start typing there.

Actual result

Cursor completely vanishes, is not in the pane any more.
I have to click into the edit pane to get a visible cursor.

Basically, I expect that with ‘Cmd-F’ I can go to the place in the file where the search term is found, using the keyboard alone.
Instead, I have to click on the search term with the mouse to get there.

Environment

  • Operating system: macOS Big Sur 11.0.1

  • Obsidian version: 0.9.17


Additional information

5 Likes

Do not only highlight but select the matched text when searching in edit mode

Use case or problem

keyboard-only navigation to matched string

Proposed solution

Do not only highlight but select the matched text when searching in edit mode.
Then, all non-selected matches can remain just highlighted while we continue editing text. Works that way e.g. in EmEditor.

Current workaround

find visually highlighted match (can be hard on larger screen), grab mouse, click there.

Related feature requests

2 Likes

This would be an amazing feature - it’s one of the few issues I’ve had with obsidian since I’ve properly switched to it.

Anyone know if this is prioritized on a list anywhere that I can plus 1?

1 Like

Another big vote for this feature/fix. This is an important feature for increasing accessibility to those of us who must use computers primarily by voice.

Those of us who do not or cannot use a mouse must rely on voice-activated keyboard commands to get around the document. The “Find” command is a great way to achieve this by voice type force in most text editors --if the cursor actually moves to the text that you are looking for.

It’s currently very painful to get the cursor where you want to go with Obsidian because you cannot use “Find” commands to go to the tape or matched text. While it’s possible to achieve this behavior with Vim, this adds a lot of keystroke-and-knowledge-overhead to be switching between command mode and insert mode. It’s simpler to have a “Find” command that behaves like other applications.

1 Like

Update: this behavior can be achieved using the Relative Find plug-in.

I tried the plugin but it’s my understanding this doesn’t address the problem here. It enables searching relative to cursor position, when I do it highlights the text but I can’t start typing right away it might be a problem on my end but I had to click into the window before it even placed the cursor anywhere.

VSCode achieves the feature requested in this thread elegantly and I’d +1 if something like this was implemented. The cursor in VSCode move along with the search, highlighting and selecting the searched word with the cursor at the end enabling the user to start typing immediately.

It feels weird to tie the user to using mouse to click into the text just to place the cursor when Obsidian’s other features like are so hotkey-centric. I generally don’t touch my mouse when I interact with a text editor or try to limit it as it’s faster to move around with shortcuts.

Generally when I search for something it’s to jump to that portion of the text and add or edit something, I’d press ctrl+f, type the term, press enter until I find the target, press esc to close the search dialog, press the arrows to move one or two lines maybe and then start typing. This sounds like a long list but with both hands on the keyboard it’s way faster than moving from mice and back to the keys.

+1 would be really helpful!

Such a simple feature but still not supported?

I tried the plugin as well but agree that it does not address the mentioned issue.
+1 for this to be addressed as this is important when searching.

1 Like

Another +1 for this feature.

1 Like

+1 for this feature. It’s rather annoying to not be able to quickly find and jump cursor to text position I’m looking for.

1 Like

+1 Would definitely appreciate it

2 Likes

I had to give up on Obsidian for this very reason. My mental way of working depends on fast keyboard navigation, and wild jumps and unexpected behaviour can totally throw my train of thought.

Hope this can be changed soon.

1 Like

Perhaps vim mode’s / bind might do what you’re looking for? (Unfortunately, this requires knowing all the useful vim binds, and changes the workflow a bit more.)

(Or a plugin might exist? Not sure, either way hope this reply helps)

1 Like

My current workaround was to implement mouse movements and left-click using a keyboard button. I’m on macOS so I used Karabiner.

Current Behavior

I perform a search in Obsidian by doing a “Ctrl/Command+F” and then enter in my search word. Obsidian properly highlights the word, I press Enter multiple times and it cycles through all the matching words in the document. Once I see the particular word I’m interested in, I hit the Escape key to exit the search hoping that the caret navigates to right side of the last searched word so I can add on to it. The caret is still at the original location prior to performing the search.

Proposed solution

I propose to create an option to change the behavior on exit search where the caret appears to the right side of the last highlighted and searched word. This is how it behaves in most applications.

Current workaround (optional)

The current workaround is after you find the particular word you’re looking for, use the mouse to click to the right side of the highlighted and searched word.

Related feature requests (optional)

Would also like the same sort of behavior in the global search “Ctrl/Command+Shift+F”. After I typed in a word, would like the ability to tab through the search results and then upon hitting enter, the caret gets navigated to the right of the highlighted and searched word.

These behavior modifications on search would be a big win for keyboard-heavy users. Users that don’t rely on switching between keyboard and mouse too much in their workflow.

Thanks!

will be implemented in 0.14.11

3 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.