Insert Link in visual mode behaves strangely

[seflue]

When I use the insert_node function while in visual mode, this doesn't work as expected. I actually don't know, what the intended behavior is, but currently it seems to be broken. My intuition was, that it would grep the visual selection, open the find selector, let me choose a note and inserts a link while preserving the selection as description of the link.

What currently happens: Nothing get's inserted, I get no selection buffer, but the visual selection changes to the current word under cursor and Neovim goes back into insert mode.

[seflue]

Actually a similar behavior can be observed with "find node" in visual mode.

Now, as I am playing more with different cases, I find out, that this strange behavior happens only, if the selection cannot be found in the titles of my existing Roam files.

[seflue]

I actually try to pin down the strange behavior. When I use insert_node or find_node on a selection, which is not part of a title of an existing roam node, then the cursor jumps to the most left buffer and the mode changes to insert.

The reason, why the selection aborts, I found by this line:

org-roam.nvim/lua/org-roam/ui/select-node.lua

Line 57 in 5943188

cancel_on_no_init_matches = true,

I actually would prefer, when the select buffer does not just close but gives me the opportunity to refine my selection.

But what happens after cancelation is still a mystery to me. Closing the selection emits a EVENTS.CLOSE which somewhere should be translated in a EVENTS.CANCELATION but I just found this out by grepping through the code and it's hard for me to get a hang of how the business logic is actually orchestrated.

@chipsenkbeil Any hints on that? And what do you think about how the feature should actually behave?
My intuition and preference would be, that the visual selection could be inserted as initial input into the select buffer, but if no selection is found, instead of canceling, a is shown and the selection is removed, so the user has to reenter something else to filter down.
For the insert_node I still would like to have the visual selection kept as link description. This behavior would be similar to most of the textual tools, which allow to insert links, including Github.
If I just want to expand an existing word to a link, I can use <leader>n.. Otherwise both features are nearly identical, but creating links with a different description is not covered and must be done manually.

[chipsenkbeil]

@seflue another case of me not remembering fully where this is used. There was a situation where the experience was sub-optimal, and I think it was the complete under cursor opening a dialog window when there was no match; so, I wanted it to do nothing instead.

Looks like because this was put at the level of the select node ui function, it's affecting inserting and finding nodes as well. So this either needs to be updated to be false by default and user-configurable so roam_complete_node_under_cursor can still cancel the selection dialog automatically or have a way to turn it off, which would be used everywhere else.

I'm in favor of the first approach, where we change it to not be enabled within the core select ui and instead provide a way for roam_complete_node_under_cursor to specify it instead.

[chipsenkbeil]

My intuition and preference would be, that the visual selection could be inserted as initial input into the select buffer, but if no selection is found, instead of canceling, a is shown and the selection is removed, so the user has to reenter something else to filter down.

To make sure I understand, you're recommending that if a match is not found, display some message and clear the input so that someone can type something else, versus needing to manually tap the backspace key to clear out the selection? That makes sense, although I'm of the mind that this is configurable as well. This would also mean that we need to change behavior or add support within the core selection dialog tool, which is possibly the most complex part of the codebase given how many edge cases I was handling to make the behavior tolerable.

For the insert_node I still would like to have the visual selection kept as link description. This behavior would be similar to most of the textual tools, which allow to insert links, including Github.

I'm fine changing the behavior here. I was trying to figure out how Org Roam implemented the solution and copy it. We can either change the behavior for everyone, or make it be a setting that can be configured to switch between behaviors.

If I just want to expand an existing word to a link, I can use n.. Otherwise both features are nearly identical, but creating links with a different description is not covered and must be done manually.

Agreed.

[seflue]

My intuition and preference would be, that the visual selection could be inserted as initial input into the select buffer, but if no selection is found, instead of canceling, a is shown and the selection is removed, so the user has to reenter something else to filter down.

To make sure I understand, you're recommending that if a match is not found, display some message and clear the input so that someone can type something else, versus needing to manually tap the backspace key to clear out the selection?
Yes.

That makes sense, although I'm of the mind that this is configurable as well. This would also mean that we need to change behavior or add support within the core selection dialog tool, which is possibly the most complex part of the codebase given how many edge cases I was handling to make the behavior tolerable.

I agreed, that everything should be somehow configurable.

For the insert_node I still would like to have the visual selection kept as link description. This behavior would be similar to most of the textual tools, which allow to insert links, including Github.

I'm fine changing the behavior here. I was trying to figure out how Org Roam implemented the solution and copy it. We can either change the behavior for everyone, or make it be a setting that can be configured to switch between behaviors.

Actually it would be nice to have the expected link description visible and editable - but this might be step two, because UI code is, as you mentioned, a bit complex in Neovim. My experience with - let's call it "Neovim TUI Widgets" is still limited - I learned everything I know, when I added the timestamp extension to the Calendar widget in nvim-orgmode. But I would imagine a second line with the description and the user can toggle between the filter and the description with a mapable key, by default e.g. . If kept empty, it should be the node title (we could visualize that with italic greyed out title of the current link, but if the user entered the select window from visual mode, it should be set to the current visual selection.

Because I have currently configured Emacs available and running, I wasn't able to check first hand how Emacs Orgroams UI works. In the manual they are rather vague about the linking features.

I would be motivated to implement something useful. But first I wanted to agree with you on some sane UI workflow and then talk about entry points.

Speaking of entry points - how do you feel about some architectural documentation to enable more sustainable contribution to the project? What I can offer you is to condense my current belief state of the concepts and the architecture into a Draw.io diagram and add it as editable SVG to the project. This would probably also include some questions about things I currently don't understand. But what you then can do is to review this diagram and correct it/answer the questions as you feel confident.
Then we would have at least something more then just the code. As you said, it is easy to forget the stuff we implemented a couple of month ago and it is hard to rediscover the knowledge just from the code itself.

[chipsenkbeil]

Speaking of entry points - how do you feel about some architectural documentation to enable more sustainable contribution to the project? What I can offer you is to condense my current belief state of the concepts and the architecture into a Draw.io diagram and add it as editable SVG to the project. This would probably also include some questions about things I currently don't understand. But what you then can do is to review this diagram and correct it/answer the questions as you feel confident.

Sure, I don't see any harm in doing that. I can't promise I can get to the diagrams quickly at the moment due to family visiting, but feel free to share when you hav something drafted 😄