[Discuss] The behavior of mouse-click #79
Comments
|
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. What do you think? |
|
I'm voting for double click == |
|
Good idea! |
|
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. |
|
Configuration it is then. Ill see to it that I come up with some sane defaults, but youll get adjust things as you please. |
|
After thinking about it and testing what I vote for click == |
|
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? |
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. |
|
During the course of figuring out how to open a file on double click, I came across However, I realize most people aren't like me, so I propose making the following changes: Unify
|
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.
Rename on RET? Really?
What other managers did you look at?
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.
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.
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.
You mean showing file size, mod time and the like? By default that should be bound to something lie
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. |
|
On Mon, Dec 18, 2017 at 1:05 PM, Alexander-Miller ***@***.***> 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
|
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
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.
I was thinking maybe in addition to the primitives I outlined, perhaps we should introduce another customizable var
I like this compromise. It shouldn't be too difficult I think, it just requires putting a keymap text property to the icons.
Sounds good too.
Agree. It's trivial to change in |
|
@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? |
|
On Tue, Dec 19, 2017 at 5:18 AM, Jimmy Yuen Ho Wong < ***@***.***> 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
|
|
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. |
|
On Tue, Dec 19, 2017 at 5:20 AM, Jimmy Yuen Ho Wong < ***@***.***> 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
|
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.
|
|
On Tue, Dec 19, 2017 at 10:47 AM, Jimmy Yuen Ho Wong < ***@***.***> 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, <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.
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.
|
|
I've done a good bit of refactoring now and pushed it to the 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. |
|
On Thu, Dec 21, 2017 at 3:22 PM, Alexander-Miller ***@***.***> 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.
|
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. |
|
Oh this branch is sweet, thanks!
If As to Mac and Window keybindings, they should be trivial if you get this underlying machinery right. I'm not too concerned about it. |
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. |
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.
I've set |
It means that double clicks would literally do nothing when I just tried it without png icons and I need to look into that.
If you know a unicode icon that'd be a good fit then I'm all ears. |
|
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. |
|
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. Feedback is welcome. |
|
Wow, great! I will get the new release and test soon. |
|
It works great! Thanks for the awesome work! |
|
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 Well, I'm agree to close it anyway. Thanks for the excellent work, again! |
|
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. |
|
It does make sense. Thanks for the update, @Alexander-Miller! |
While clicking on a file without any tags in treemacs, a message pops up like this:
The behavior is same as
TAB. I think the better behavior is opening the file instead, likeRET. It's more convenient to visit the files quickly. I am struggling toClickorTABwithout response but only a message, and have to pressRET. Your opinion?The text was updated successfully, but these errors were encountered: