Mmm, this is interesting, but having to double click to open a file doesn't feel right to me (but I'd probably get used to it quickly). This may cause trouble with plugins like ephemeral_tabs (that uses the double click to remove the ephemeral status from a tab), but I'd need to test.

The alternative would be to use single click to open the doc, but avoid giving it the focus, and keeping it on the TreeView. This would also cause problems if what one wanted to do was just selecting an item without opening it.

In the end using double click is probably the best way to allow keyboard navigation.

We should have different styles for hovered and selected, and also apply all the commands to the selected item(s), not the hovered one.

An issue I noticed is that clicking on an item, then immediately clicking another is interpreted as a double click on the second item.

I also like the single-click, but the other IDE I use (Code::Blocks) does use the double-click. If that is the standard, we should support that.

Have this be a configurable option? I know we want to reduce the amount of configurable options, but this is a plugin technically, and so not part of the core config.

Mmm, this is interesting, but having to double click to open a file doesn't feel right to me (but I'd probably get used to it quickly). This may cause trouble with plugins like ephemeral_tabs (that uses the double click to remove the ephemeral status from a tab), but I'd need to test.

Could have it only make things non-emphemeral only if it's already the active document. That strikes me as reasonable, and would work with both styles.

Mmm, this is interesting, but having to double click to open a file doesn't feel right to me (but I'd probably get used to it quickly).

Same, I'm used to how it is, but I think this is the more common way to implement keyboard access, so if anyone has a better idea to implement we can go with that.

Have this be a configurable option? I know we want to reduce the amount of configurable options, but this is a plugin technically, and so not part of the core config.

I'm not sure what to configure here?

Another option: we could detect where the user clicked; on the text, or only on the row. If on the text, we treat as a double click, otherwise as a single click?

I'm not sure what to configure here?

I meant the single click vs. double click.

Another option: we could detect where the user clicked; on the text, or only on the row. If on the text, we treat as a double click, otherwise as a single click?

Not having a clear interactability indication would be bad UX, tho.

Another option: we could detect where the user clicked; on the text, or only on the row. If on the text, we treat as a double click, otherwise as a single click?

I think this could cause confusion, since there's 2 different outcomes while doing something quite similiar.

Yeah, that's fair. And I suppose if we don't want to add the single click as a config, I can always add a plugin to modify the plugin.

Yeah, that's fair. And I suppose if we don't want to add the single click as a config, I can always add a plugin to modify the plugin.

I can try doing that, actually before this I got singleclick working, but it wasn't the behavior I intended so I fixed it.

Actually, I just tested the thing and it works perfectly with single click. Should I just go with single click instead?

Actually, I just tested the thing and it works perfectly with single click. Should I just go with single click instead?

How does it behave? Do you need to open a file/show subdirs to be able to control via keyboard?

How does it behave? Do you need to open a file/show subdirs to be able to control via keyboard?

If you don't have any selection, pressing up or down will select the 1st (usually your project folder). After that you can navigate around, and then enter to expand/open files.

Yeah, but my problem with that is having to find an empty space in the TreeView to click, to give it focus. Missing that, you are forced to click a directory (and not a file because it would move the focus to its View).

In the end it's not too bad, as this is adding more controls without removing anything.

If a config option to switch between single and double click is simple to add, it would satisfy both old users that are used to single click, and users that want to use more keyboard navigation.

Also considering that we have commands to move focus from a Node to a neighboring one, the keyboard users wouldn't even need to use the mouse to move to the TreeView.
The problem with those commands is that they ignore locked Nodes, so it wouldn't work right now.
We could either allow moving focus to locked Nodes with our current commands, or add a new one to move focus to the TreeView.

We could either allow moving focus to locked Nodes with our current commands, or add a new one to move focus to the TreeView.

Is there any problems with the former approach? I think having treeview:focus is way too specific.

If a config option to switch between single and double click is simple to add, it would satisfy both old users that are used to single click, and users that want to use more keyboard navigation.

no problem. I can add clicks_to_open = 2

Yeah, but my problem with that is having to find an empty space in the TreeView to click, to give it focus. Missing that, you are forced to click a directory (and not a file because it would move the focus to its View).

That was an intended feature, but it seems it's not very good. I can try removing it.

We could either allow moving focus to locked Nodes with our current commands, or add a new one to move focus to the TreeView.

Is there any problems with the former approach? I think having treeview:focus is way too specific.

I don't know, I'd need to test.

Yeah, but my problem with that is having to find an empty space in the TreeView to click, to give it focus. Missing that, you are forced to click a directory (and not a file because it would move the focus to its View).

That was an intended feature, but it seems it's not very good. I can try removing it.

I mean, clicking in an empty space is mostly fine (and is an action done in file managers), no need to remove that.

Also, the scroll should follow the selected item.

Also, the scroll should follow the selected item.

What do you mean by this?

When selecting a file with the arrow keys, if the selected file is outside the visible area, the View should scroll to make it visible.

When selecting a file with the arrow keys, if the selected file is outside the visible area, the View should scroll to make it visible.

Sorry for the late follow up but I've implemented this. Now selection / moving (with mouse or keyboard) will center the file.

It looks like manually scrolling isn't working anymore.

It looks like manually scrolling isn't working anymore.

Fixed.

Would it be better to not scroll if the item is already in view? Or at least not scrolling when using the mouse to select the item.
This made me notice that we are updating the hovered item only on mouse move, not on mouse pressed.

Also, do you think we could introduce a visual difference between hovered and selected?

Would it be better to not scroll if the item is already in view? Or at least not scrolling when using the mouse to select the item.
This made me notice that we are updating the hovered item only on mouse move, not on mouse pressed.

Fixed.

Also, do you think we could introduce a visual difference between hovered and selected?

I can do this. I can turn selection alpha to 160, so there's distinction between selection and hovering.

Mmmm, scrolling the selected item to the middle is a bit weird.
I think that it would look better if we either

• always scroll to the middle if using the keyboard to change the selected item, or
• scroll just enough to show the selected item

This made me notice that we are updating the hovered item only on mouse move, not on mouse pressed.

What can be done to solve this?

What can be done to solve this?

It's possible to just iterate each_item on mouse click again, but then you'd need to iterate even if cursor in hovered_item already.

Perhaps you can cache hovered_item dimensions and check against that?

EDIT:
I actually ended up checking |scroll.to.y - scroll.y| and call on_mouse_moved appropriately.

I would like you to add these changes.
behavior VScode and Sublime Text

-- Register the TreeView commands and keymap
command.add(nil, {
  ["treeview:active"] = function()
    if not core.active_view:is(TreeView) then
      core.set_active_view(view)
      if not view.selected_item then
        for it, _, y in view:each_item() do
          view:set_selection(it, y)
          break
        end
      end

    else
      core.set_active_view(core.last_active_view)
    end
  end,
})

command.add(TreeView, {
  ["treeview:narrow"] = function()
    local item = view.selected_item
    if not item then return end
    if item.type == "dir" then
      item.expanded = false
    else
      local last_item
      local last_item_y
      local last_dir = {}
      for it, _, y in view:each_item() do
        if it.type == "dir" and it.expanded then
          last_dir = {it, y}
        end
        if it == view.selected_item then
          if not last_item then
            last_item = it
            last_item_y = y
          end
          break
        end
        last_item = it
        last_item_y = y
      end
      view:set_selection(last_dir[1], last_dir[2])
    end
  end,

  ["treeview:expand"] = function()
    local item = view.selected_item
    if not item then return end
    if item.type == "dir" then
      item.expanded = not item.expanded
    end
  end,
})


keymap.add {
  ["ctrl+0"]      = "treeview:active",
  ["up"]          = "treeview:previous",
  ["down"]        = "treeview:next",
  ["left"]        = "treeview:narrow",
  ["right"]       = "treeview:expand",
}

Adapted to new tree view changes and merged also included @AlexSol suggestions so closing this PR.