Treemacs: [Discuss] The behavior of mouse-click

[seagle0128]

While clicking on a file without any tags in treemacs, a message pops up like this:

[Treemacs] No imenu index found for /Users/vincent/.dotfiles/LICENSE

The behavior is same as TAB. I think the better behavior is opening the file instead, like RET. It's more convenient to visit the files quickly. I am struggling to Click or TAB without response but only a message, and have to press RET. Your opinion?

[Alexander-Miller]

Good timing. I have just finished a proof of concept for doing double clicks, so weve twice the playroom now.

Heres my propostion: We leave single clicks as it is, as a simple expand/close mechanism. Double clicks will work the same as RET, so theyll open files as youre requesting. Maybe I can add some minor changes, for example a double click on a directory could still just expand a directory, since this is the way its done in IDEs like eclipse & intellij.
Additionally doube clicks can be configured via a mapping like RET is with treemacs-default-actions.

What do you think?
Also asking you, @TimoFreiberg, @bitterblue.

[TimoFreiberg]

I'm voting for double click == RET

[seagle0128]

Good idea!
But I prefer click == RET and double click == TAB. It seems more conventional.
Maybe adding a customization is a better way :-)

[bitterblue]

Not much of a mouse user, so no strong opinions here. @TimoFreiberg's preference makes it easier to explore directory structures, @seagle0128's makes it easier to quickly browse through files. Both is fine with me.

[Alexander-Miller]

Configuration it is then. Ill see to it that I come up with some sane defaults, but youll get adjust things as you please.
Customization will be done the same way as RET and treemacs-default-actions, so best take a look at its docs.

[TimoFreiberg]

After thinking about it and testing what RET actually does with directories, I agree with @seagle0128 !

I vote for click == RET

[rswgnu]

I have added Treemacs mouse support to Hyperbole's next release. For users that enable unshifted-mouse key support, in a Treemacs buffer, mouse-2 will perform the RET function with a single click on the item label/name and the TAB function with a single click on the item's icon. This is simpler and clearer than moving to double clicks, I believe, because you have a separate visual item to target for each different function. Any interest in doing it that way?

[wyuenho]

click == RET and double click == TAB. It seems more conventional

Open file or directory on double click is the default behavior on Windows, Mac and Gnome, although, you can configure to use a single click to open an item on Windows and Gnome. The Emacs ecosystem is already full of terrible UI "conventions", please don't invent or imagine another here. Let's use double click first, and then make it configurable in the future if desired.

[wyuenho]

During the course of figuring out how to open a file on double click, I came across treemacs-click-mouse1, treemacs-push-button, and treemacs-visit-node-default-action. I find it quite weird that tab, return and mouse-1 are not mapped to the same action for the same item type. The more I dug into the code and researching how other file managers work, the more I'm convinced that Treemacs is really being unconventional here. I'd very much like return to either open the dir or file or prompt me to change the dir or file name. Single click should move the point and select the item, and double clicking should open the item. Tab should either do nothing or select the next item, and expansion and collapse should be done with left and right arrow keys. This is approximately how most file managers work, plus or minus a few modifier keys.

However, I realize most people aren't like me, so I propose making the following changes:

Unify treemacs-click-mouse1, treemacs-push-button, and treemacs-visit-node-default-action

Let's just remove treemacs-click-mouse1, treemacs-push-button, and treemacs-visit-node-default-action, and treemacs-default-actions and substitute with the following:

[tab]

Introduce a treemacs-tab-action customizable option, choices could be:

1. Expand/collapse (like now)
2. Next item on the same level (like macOS Finder)
3. Noop
4. Select last window (sort of like Windows File Explorer, but not quite. The whole point of this is to move focus out of the Treemacs window, to be implemented)
5. Any ELISP command (advanced config)

[return]

Introduce a treemacs-return-action customizable option, choices could be:

1. Expand/collapse/visit file (like now)
2. Rename dir or file, noop for tag (like macOS Finder, to be implemented)
3. Noop
4. File "stat" (sort of like Windows File Explorer, to be implemented)
5. Any ELISP command (advanced config)

<mouse-1> and <double-mouse-1>

Introduce treemacs-mouse-click-action and treemacs-use-double-click customizable options.

treemacs-mouse-click-action

1. Expand/collapse/visit file (fix bug with mouse-1 not visiting file if there's no tag)
2. Rename dir or file, noop for tag
3. Noop (like now)
4. Any ELISP command (advanced config)

treemacs-mouse-action-event

1. Either <double-mouse-1> or <mouse-1>. Whatever is chosen triggers treemacs-mouse-click-action.

Arrow keys

Introduce a treemacs-arrow-key-actions customizable option, its values should be a list of key-sequence and action pairs. The default could be:

1. <up> - treemacs-goto-parent-node-or-uproot, if the up key is pressed on the root level, uproot, otherwise just select the parent node. Or, just select the item on top like how it is now.
2. <down> - treemacs-change-root-maybe, depending on whether the current item can be made the root. Even files should be able to be rooted, this way Treemacs can double as an imenu index tree.
3. <left> and <right> - collapse and expand the current item accordingly.

[Alexander-Miller]

I came across treemacs-click-mouse1, treemacs-push-button, and treemacs-visit-node-default-action. I find it quite weird that tab, return and mouse-1 are not mapped to the same action for the same item type.

Things are not as ordered as they could be because this stuff has grown organically. Push-button came first, and for a while it was all that was needed. There were only dirs and files. Dirs are expanded and closed and files are opened. TAB and RET did the same thing.
Then I added tags. Now you sometimes want to open a file, sometimes you want to expand its tags. So I refactored: TAB/Push-button is all about expanding and closing nodes. RET has a focus on opening nodes instead, but it's precisely configurable for every type of node via treemacs-default-actions.
mouse-1 is stuck somewhere in the middle. I added it fairly early and had plans to come back later when this issue came up. The idea is that it'll have a config similar to the default-actions - some sane defaults, but also precise control.

I'd very much like return to either open the dir or file or prompt me to change the dir or file name.

Rename on RET? Really?

The more I dug into the code and researching how other file managers work, the more I'm convinced that Treemacs is really being unconventional here.

What other managers did you look at?
Also note that treemacs is not a file manager, but a file explorer. Basically this means that I am not competing with dired and thunar, but neotree and speedbar, and maybe ranger, if only for the keybinds.

like macOS Finder

I don't think this is a good comparison. File explorer vs manager distinction frome above aside, Emacs has a primarily text and keyboard driven and partially terminal based interface where the mouse is mostly an afterthought. I am sure that this is quite different from how Macs work, though I've never used a one before. That's also probably why the idea of doing a rename on RET seems ridiculous to me.

Single click should move the point and select the item, and double clicking should open the item

That makes sense, however there's the expand vs open problem. In e.g. eclipse's project explorer you can expand a file's tag's by clicking on a small ▸ icon before the filename. That's also an option, although it's probably the most difficult one to implement. Expanding tags by clicking on the icon is probably the best compromise.

As for the main body of your proposal I agree that a unification of the 3 interfaces is a desirable change. It is in the details that we differ.

I think an expansion and standardization of the default-action customization interface is more than sufficient. It'll give you precise control based on the type of button you're on and covers cases like going to the next line and running arbitrary code.

Select last window (sort of like Windows File Explorer, but not quite. The whole point of this is to move focus out of the Treemacs window)

I'd rather not get into reinventing the wheel of window selection. Internal Emacs functions aside there are already good packages like winum and ace-window dedicated to just that.

File "stat" (sort of like Windows File Explorer, to be implemented)

You mean showing file size, mod time and the like? By default that should be bound to something lie i for info.

Arrow keys

I'm one of those evil vim people, so I consider moving my hands to the arrow keys as highly undesirable. Whatever happens with them will be 1) an option, and 2) done last.

[rswgnu]

On Mon, Dec 18, 2017 at 1:05 PM, Alexander-Miller [e-mail]
wrote:

Single click should move the point and select the item, and double
clicking should open the item

That makes sense, however there's the expand vs open problem. In e.g.
eclipse's project explorer you can expand a file's tag's by clicking on a
small ▸ icon before the filename. That's also an option, although it's
probably the most difficult one to implement. Expanding tags by clicking on
the icon is probably the best compromise.

​FYI, here is how GNU Hyperbole interfaces with Treemacs as documented in
the Hyperbole Info Manual.
The ACTION and ASSIST keys can be mouse buttons or keyboard keys; for
Treemacs, one mouse button does
it all. Maybe Treemacs could be made do some subset of this out-of-the-box.
​​​
Treemac
​​
s
​​
items may be dragged with the Action Key to other windows for
display
​​
.
​

When in a Treemacs file browser buffer:
ACTION KEY or ASSIST KEY
(1) on an entry icon, the treemacs TAB command is run to expand and
collapse the entry;
(2) elsewhere within an entry line, the item is displayed for editing,
normally in another window;
(3) at the end of an entry line: invoke 'action-key-eol-function',
typically to scroll up proportionally, if an Action Key press;
invoke
'assist-key-eol-function', typically to scroll down proportionally,
if an As
​sis
t Key press;
(4) on the first line of the buffer (other than the end of line),
dired is run on the current directory of this Treemacs;
(5) at the end of the first or last line of the buffer,
this Treemacs invocation is quit.

B
​ob
​

[wyuenho]

Rename on RET? Really?

Yep. It should be configurable, and probably shouldn't be the default. You've implemented this, it's trivial to bind that to a key. I'm not too concerned about it to tho, the first iteration can probably leave this out, just to avoid people demanding <down-mouse-1> to rename item like on Windows File Explorer.

that treemacs is not a file manager, but a file explorer

I've never heard of such distinction. The cynical me believes that if you start with either one, eventually it'll do whatever the other does.

Emacs has a primarily text and keyboard driven and partially terminal based interface where the mouse is mostly an afterthought.

I was thinking maybe in addition to the primitives I outlined, perhaps we should introduce another customizable var treemacs-ui-mode or something. The options could be Terminal, Window System, Custom. Terminal uses the current keybindings. Window System uses whatever keyboard and mouse (event . action) combo we agree with. Custom falls backs to the primitive vars I outlined in https://github.com/Alexander-Miller/treemacs/issues/79#issuecomment-352282247.

eclipse's project explorer you can expand a file's tag's by clicking on a small ▸ icon before the filename. That's also an option, although it's probably the most difficult one to implement. Expanding tags by clicking on the icon is probably the best compromise.

I like this compromise. It shouldn't be too difficult I think, it just requires putting a keymap text property to the icons.

I'd rather not get into reinventing the wheel of window selection. Internal Emacs functions aside there are already good packages like winum and ace-window dedicated to just that.

Sounds good too.

I'm one of those evil vim people, so I consider moving my hands to the arrow keys as highly undesirable. Whatever happens with them will be 1) an option, and 2) done last.

Agree. It's trivial to change in treemacs-evil and treemacs-mode-map.

[wyuenho]

@rswgnu Hyperbole sounds really interesting but in terms of convention, that's probably way out there in the fringe. As long as whatever we are going to do doesn't break Hyperbole, what you suggested should stay in Hyperbole. How does that sound?

[rswgnu]

On Tue, Dec 19, 2017 at 5:18 AM, Jimmy Yuen Ho Wong <
[email protected]> wrote:

eclipse's project explorer you can expand a file's tag's by clicking on a
small ▸ icon before the filename. That's also an option, although it's
probably the most difficult one to implement. Expanding tags by clicking on
the icon is probably the best compromise.

I like this compromise. It shouldn't be too difficult I think, it just
requires putting a keymap text property to the icons.

​No, it doesn't and please don't do this as text property keymaps are very
hard to override. You can just recognize if a click is on an icon or not
dynamically and dispatch from there.
​
Bob

[Alexander-Miller]

Click events can already tell by themselves if the click happened on an image. I've used this in a previous version before expanding the clickable area to the entire line.

[rswgnu]

On Tue, Dec 19, 2017 at 5:20 AM, Jimmy Yuen Ho Wong <
[email protected]> wrote:

@rswgnu https://github.com/rswgnu Hyperbole sounds really interesting
but in terms of convention, that's probably way out there in the fringe.

​Hyperbole uses the context around point to maximize what the system does
for the user without the need to think much about it. It is very
consistent across many major modes.

Alexander and I have already made Hyperbole and Treemacs compatible. There
is no expectation that other packages will implement all of the contexts to
which Hyperbole responds but maybe that single function mouse bindings will
behave similarly, e.g. left mouse button sets point to a location and
middle button activates/displays the thing at point.

As
​ ​
long as whatever we are going to do doesn't break Hyperbole, what you
suggested should stay in Hyperbole. How does that sound?

​Yes. As long as the bindings Treemacs makes are normal mode-specific
keymap bindings and not textual property keymaps, they won't interfere with
Hyperbole's behavior or support for Treemacs.

Bob

[wyuenho]

middle button activates/displays the thing at point.

This is a major problem right there. Tons of PC and Mac mice don't have a middle button. Anyway, I would suggest you deal with Hyperbole compatibility within Hyperbole.

The problem with single click action for everything in Treemacs is, currently there's no way to tell whether the user wants to open the file or open a tag. If there is no tag for the file, should a single click fall back to open the file or not? It's not clear now. Having only the icon take mouse events sounds like a good idea, but there's no file icons if you are using text mode UI in a GUI. May be we should do something stupid, like Eclipse, just prepend an expand icon to every file when you open a directory. When the user clicks on the expand icon, Treemacs first checks if there are tags, if not, remove the expand icon, same thing for directories. Double clicking should always "open". In the case of a directory, it just expands; if a file, open the file; if a tag, open the file on the tag's location.

I know I'm backtracking a bit, but I think maybe we should separate the actions of single and double clicks, and don't make the mouse actions configurable now. Possibly something like this.

1. Leave <tab> and <enter> alone. They work well enough for keyboard based interactions, but maybe refactor the code a bit so event handlers don't just look at the button state, but also the event type, do we can reuse them for mouse actions.

2. For mouse actions, <double-mouse-1> event action should expand or collapse if the point is on a dir; if on file, visit file; if on tag, visit file at tag location. <mouse-1> should select the item if point is on text. If on expand collapse icon, just expand or collapse the item if it can, otherwise remove the expand/collapse icon.

[rswgnu]

On Tue, Dec 19, 2017 at 10:47 AM, Jimmy Yuen Ho Wong <
[email protected]> wrote:

middle button activates/displays the thing at point.

This is a major problem right there. Tons of PC and Mac mice don't have a
middle button.

​Hyperbole handles 2 button mice and it doesn't override your middle button
by default either (it uses shift-middle or shift-right for its default). I
was just making a general point about how things can work.​

Anyway, I would suggest you deal with Hyperbole compatibility within
Hyperbole.

The problem with single click action for everything in Treemacs is,
currently there's no way to tell whether the user wants to open the file or
open a tag. If there is no tag for the file, should a single click fall
back to open the file or not? It's not clear now. Having only the icon take
mouse events sounds like a good idea, but there's no file icons if you are
using text mode UI in a GUI. May be we should do something stupid, like
Eclipse, just prepend an expand icon to every file when you open a
directory. When the use clicks on the expand icon, Treemacs first checks if
there are tags, if not, remove the expand icon. Double clicking should
always "open". In the case of a directory, it just expands; if a file, open
the file; if a tag, open the file on the tag's location.

​

1.

For mouse actions, event action should expand or
collapse if the point is on a dir; if on file, visit file; if on tag, visit
file at tag location. should select the item if point is on
text. If on expand collapse icon, just expand or collapse the item if it
can, otherwise remove the expand/collapse icon.

​I don't use or bind many double clicks because I find users often remain
unaware of them. That said, whatever reasonable ideas come out for double
clicks would therefore be alright.

In textual mode, you can use the +/- signs in lieu of the icons for expand
and contract operations and maintain consistency.

You really should try ​the Hyperbole Treemacs mouse interface so you have a
feel for how simple and intuitive it is and maybe that will stimulate other
good ideas that you can contribute.

[Alexander-Miller]

I've done a good bit of refactoring now and pushed it to the mouse branch.

TAB, RET and mouse clicks now all share the same interface and config options, but are configured individually. The mouse also behaves like in modern GUI applications. A single mouse click just selects a node, a double click expands dirs and opens files and tags.

For expanding tags I think single clicking the icon is the best compromise. It's somewhat unintuitive when you don't know about it, but it doesn't require adding more strange icons into the view and avoids the issue of showing expand icons for files with no tags. In addition I also have a working proof of concept for using the pulse library for visual feedback, so you'll quickly see when e.g. a file has no tags to display.

About Macs: I am completely foreign to all things apple, so I think the best solution is for you to create a small treemacs-mac package that rebinds all the mac specifica, similar to treemacs-evil.

[rswgnu]

On Thu, Dec 21, 2017 at 3:22 PM, Alexander-Miller [e-mail]
wrote:

I've done a good bit of refactoring now and pushed it to the mouse branch.

TAB, RET and mouse clicks now all share the same interface and config
options, but are configured individually. The mouse also behaves like in
modern GUI applications. A single mouse click just selects a node, a double
click expands dirs and opens files and tags.

For expanding tags I think single clicking the icon is the best
compromise. It's somewhat unintuitive when you don't know about it, but it
doesn't require adding more strange icons into the view and avoids the
issue of showing expand icons for files with no tags. In addition I also
have a working proof of concept for using the pulse library for visual
feedback, so you'll quickly see when e.g. a file has no tags to display.

​Sounds good.
​

About Macs: I am completely foreign to all things apple, so I think the
best solution is for you to create a small treemacs-mac package that
rebinds all the mac specifica, similar to treemacs-evil.

​If you attach a 3-button mouse to your Mac, it works like any other UNIX
system these days. If you don't, you'll have more limited mouse keys but
you really shouldn't need anything Mac-specific in your package.
​

[Alexander-Miller]

If you don't, you'll have more limited mouse keys but you really shouldn't need anything Mac-specific in your package. ​

I was referring to keybinds like using RET to rename a file, which I've never of before. I assume there are enough such cases to justify a small package or at least minor mode.

[wyuenho]

Oh this branch is sweet, thanks!

For expanding tags I think single clicking the icon is the best compromise. It's somewhat unintuitive when you don't know about it, but it doesn't require adding more strange icons into the view and avoids the issue of showing expand icons for files with no tags.

If treemacs-no-png-images is t, there's no way to expand the tags with just a mouse now. I think putting an expand/collapse icon on everything is your best bet there, or at least put the icon when not showing png images.

As to Mac and Window keybindings, they should be trivial if you get this underlying machinery right. I'm not too concerned about it.

[Alexander-Miller]

If treemacs-no-png-images is t

then not even the double click works, so I first need to get into that.

Without png images there is still a unicode icon shown for files, but with issues like #119 it's doubtful it'll stay that way. A small expand icon probably really is the way to go. Of course I'll need to show it for all files, even those that don't or just plain can't have tags.

For right mouse I want to eventually offer a real right click menu, using something like popup.el, or maybe the new emacs26 child frames, so they're off the table for now.

The middle mouse button could serve a TAB like function, in that it always expand nodes, including tags, but that still leaves macs.

[wyuenho]

then not even the double click works

I'm not sure what this means. It works exactly like RET now. I think you just have to attach the double click event handler to the expand/collapse icon.

Without png images there is still a unicode icon shown for files, but with issues like #119 it's doubtful it'll stay that way.

I've set treemacs-icon-fallback-text to just " " (2 spaces) for a while now. This glyph is also very very rare in fonts, and basically non-existent on monospaced fonts.

[Alexander-Miller]

I'm not sure what this means.

It means that double clicks would literally do nothing when I just tried it without png icons and I need to look into that.

This glyph is also very very rare in fonts, and basically non-existent on monospaced fonts.

If you know a unicode icon that'd be a good fit then I'm all ears.

[wyuenho]

Mmm, double clicks works for me. As to what the icon should look like with no png, I believe the answer is none. There's no icon for directories, why do you need one for files? The only reason you needed an icon is because you aren't automatically indenting by levels, so you needed some spacer, and a unicode file and a space just happened to be the 2 characters you needed to occupy that space. I'd just use 2 spaces. I wouldn't even make it configurable.

[Alexander-Miller]

I've pushed the change to master. Mouse behaviour is now in line with gui apps. Single click to focus, double click to expand/collapse directory or visit a file. Tags are opened/closed by clicking on the icon. That means you cannot use the mouse for tags in the terminal, but I figure the intersection of people who run emacs in the terminal and who want to use the mouse to be rather small.
In addition TAB, RET and double clicks can now all be configured in their own treemacs-*-actions-config.

Feedback is welcome.

[seagle0128]

Wow, great! I will get the new release and test soon.

[sadhu89]

It works great! Thanks for the awesome work!

[seagle0128]

I tested with GNU Emacs 26.0.91 on macOS 10.13.3. It works well!

Can I request one more configuration for the left mouse click? maybe treemacs-leftclick-actions-config, will make treemacs more flexable.

Well, I'm agree to close it anyway. Thanks for the excellent work, again!

[Alexander-Miller]

Not on mouse1, no. I want to keep things simple, and, most importantly, I don't want any compatibility issues with double clicks. I you have something specific in mind I might go about adding middle mouse clicks.

As a long term prospect there are also right clicks, but I first need to figure out a good way to create a right click menu.

[seagle0128]

It does make sense. Thanks for the update, @Alexander-Miller!