New Home/End behavior for Suggest Modals BREAKS Navigation within Wiki-Links

Plugins ideas
, ,
1

Use case or problem

As of version 1.2.7 the behavior of home and end keys changed:

Suggest modals now support page down and page up as well as home and end keys for faster keyboard navigation.

In general I appreciate the possibility to quickly navigate the suggest modals. However, the new feature breaks my workflow with wiki-links. Here I think it is crucial to have the home and end keys available to directly navigate inside a wiki-link. With the new feature, this is not possible anymore. Moreover modal navigation is completely useless for long links, where the suggest modal is very short (or empty).

Proposed solution

At least for windows/linux keyboards, I suggest to move the modal-home/end-navigation from home and end to ctrl+page up and ctrl+page down

Alternatively an options switch in the menu would be fine, too, but I guess you want to reduce the number of such switches to an absolute minimum.

Current workaround (optional)

Currently the only way around is to press Esc before using home and end to exit the suggest modal first. But this is too slow and contra-intuitive.

Related feature requests (optional)

In addition to the old behavior it would be amazing, if home and end within wikilinks would first navigate inside the link and then outside (similar to the behavior inside bullet-lists, where home would first go to the beginning of the list-entry and only later to the beginning of the line.

1 Like
2

I’m also completely lost when entering wikilinks. Previously I would type the link in, press End and be on my way. Now I have to type the link in, press Esc, then End and then continue.

I’d like to see the option to disable the Home/End for modal navigation of wikilinks.

1 Like
3

Home and End are generally used to go beginning/end of line (or page).

I am confused as how you use it for navigating within a link.

@Gnopps You can use tab or enter to accept the autocomplete or ]] to just keep what you wrote.

There are also these
Ctrl-ArrowLeft (Alt-ArrowLeft on macOS): cursorGroupLeft (selectGroupLeft with Shift)
Ctrl-ArrowRight (Alt-ArrowRight on macOS): cursorGroupRight (selectGroupRight with Shift)
Cmd-ArrowLeft (on macOS): cursorLineStart (selectLineStart with Shift)
Cmd-ArrowRight (on macOS): cursorLineEnd (selectLineEnd with Shift)

4

Thanks for your answer.

So my workflow (pre v1.2.7) for entering a new wiki-link (where I don’t want the auto-suggest) was to type “[[acme” and then press End.
With the new version this no longer works, I have to do either press first Esc then End OR type “]]”. Both of these mean more steps to accomplish the same thing.

Also to note here is that the “[” and “]” symbols do not have native keys on many non-English keyboards. I’m using Nordic keyboard and there I have to press Alt + 9 to get the “]” character.

So again, would be good to have an option not to have Home/End assigned to the suggest modal.

1 Like
5

the way you were using end would not have worked if there was text after link (because end jumps to the end of line or page).

A better approach is to use Ctrl-ArrowLeft (Alt-ArrowLeft on macOS).

6

Thanks for taking up the discussion.

Ctrl-ArrowLeft is a good option for one-word wikilinks but it is very cumbersome for multi-word wikilinks.

I ran into workflow trouble dealing with long and structured inline wikilinks like e.g.

  • See [[E.1. Tabletennnis Part 1]] for more info on…
  • See [[E.1. Tabletennnis Part 2]] for more info on…

If you now want to navigate to the middle part of the wikilink to correct the typo you would simply go there, make the correction and then use home or end to continue writing. Often I create such dead-links before actually writing the notes, so I really don’t care about the modals. The only thing I want is going back and forth within the line. This is my core-understanding of home and end in a text editing context. So it is very counter intuitive for me that I now have to consider modal-navigation as well.

Please consider my related feature request from above, I think this would work amazing, as it takes up the logic as it is already found in lists:

Related feature requests (optional)

In addition to the old behavior it would be amazing, if home and end within wikilinks would first navigate inside the link and then outside (similar to the behavior inside bullet-lists, where home would first go to the beginning of the list-entry and only later to the beginning of the line.

7

It is not, just press it multiple times.

Perhaps there are some third party plugins that do this already. Also you may me a good candidate for learning vim.

8

Thank you for your answer.

Well, this basically is my definition of “cumbersome” ;.)

I agree that the example from above (with the tabletennnis-typo) may be somewhat constructed. But I have dozens if not hundreds of such cases in my workflow every day, where the new priority to model navigation really does slow me down.

Reason 1: More clicks It simply requires more keyboard action (including both hands leaving center-position: first with the left hand to Esc and then with the right hand to end).

For example, this happens in elements like:

  • Log ([[2022-10-20]]): Here is some text

While refactoring old notes, I always have to change the dates – and then I need a one-click hotkey to get to the end of the line. In my opinion this is what end is for.

Again, my argumentation is from the perspective of a writing-only-workflow that does not care about modals – the wiki-links in the logs are for future backtracking, but they all go to mostly non-existing files.

Reason 2: Inconsistency Also I think this introduces inconsistency, since there are similar use cases were the expected workflow with end would perfectly work, like e.g.

  • Multi-word header of list-item: Here is some very long text

To change something in the bold header above, you would never press Esc to go to the end of the line, but simply press end. But for my use cases it is the exact same situation. And it will remain contra-intuitive to think of modals in one case and in the other not.

Solution:
So again I suggest to move the modal-home/end-navigation from home and end to ctrl+page up and ctrl+page down…

… or at least to introduce an opt-out somewhere in the menu.

PS: I have seen your comment on VIM and I gave it a try… but it is not an option for me right now. But thank you for the hint!

9

Sorry, we are not gonna change this. If somebody wants to write a plugin for it, that’s fine for us.

10

Ok, thank you for your answer.
So I leave this unresolved, so that potential future plugin writers can add to the existing discussion. I can provide robust js-coding experience, however it would be my first Obsidian plugin. So if someone with this experience would like to join in, please hit me up!

11

If you get the itch to try it yourself, the developer documentation is at https://docs.obsidian.md/.

1 Like
12

With version 1.3.5 there is a new functionality: Pressing Shift + Enter will accept the input as is. While it is not as good as the deprecated functionality of using just End it is at least a slight improvement.

1 Like
13

yeah, I was about to post it here too.

1 Like