[Suggestion] Use more "standard" keymaps for opening buffers (e/s/v/t) and reserve <Cr> for actual "triggering"

[idanarye]

Mind's current behavior is to open the node as a data node on <Cr>, and if it's not a data node make it a data node - unless it's already a URL node. I suggest a different behavior:

• To open the node's data, use e/s/v/t, which are kind of a standard for filesystem tree viewers in Vim.
• <Cr> will trigger the node type's action (should be customizable, as per my other suggestion - [Suggestion] explicit and customizable node types #31)
• For data nodes, that action can indeed be to open the file. But for typeless nodes, I think it should be to just toggle the node.
• Since data nodes are going to be the norm, using e/s/v/t on a typeless node will convert the node to a data node and open the file.
• For other types of nodes, e/s/v/t can have custom meanings. For example, For URL nodes it can open a scratch buffer for editing their URL.

[hadronized]

For data nodes, that action can indeed be to open the file. But for typeless nodes, I think it should be to just toggle the node.

It’s a bit more complex than that, since parent node can also have data.

For the rest, I think we could indeed add a couple of keybindings to open in different kind of split, indeed.

[idanarye]

<Tab> will still toggle nodes, of course. But if a node has no data, <Cr> will toggle it instead of adding data to it.

Another option is to have <Cr> open a vim.ui.select and let the user choose the node type.

[hadronized]

Yeah, the prompt idea is a good one, tracked from another issue as well. For the rest of your issue, that could open too, I need to investigate the keybindings a bit and refactor the code so that it’s easier to implement all of those – it’s basically just a different command to pass when the file is created; it shouldn’t be a big deal.