Default way of opening a file in the `Files` browser should be configureable

[tmerten]

I am just starting to use vimrs awesome filebrowser. Personally I (nearly) do not use tabs in vim. As others, I would even discourage using a tab per file in vim, but that is up to the individual.

So much for the intro, now here is the actual feature idea:

1. It would be nice if the action that happens on left click in the file browser was configurable in the preferences (e.g. always Open in current tab instead of new tab). Otherwise the (personal) default/preference is always a right-click-aim-again-left-click-combo away (you know what I mean).
2. A nice addition to this would be to make the default way Enter opens a file configureable, too (since many vimmers might navigate in the tree with the keyboard...). And/or enable key combos like shift-enter to change the open-behaviour.
3. (Opening in splits could also be a configurable option, although I doubt many people would need it as their default. Its implementation might however be "free", if you want to implement the whole thing)

[ELLIOTTCABLE]

A hearty :+1:! In particular, I'd love to use the GUI as a replacement for my Denite-setup-as-Ctrl-P; but I, too, would want different actions.

My suggestion is not to overcomplicate the GUI with this — vim is built around filepaths. Actions in the GUI should call (.vimrc-configurable, not GUI-configurable) commands. In particular, it should extend upon the conventions established in :help cmdline-special, and support :help filename-modifiers; something like:

if has('gui_vimr')
   vimr#file_browser#set_command(':edit <guifile>:p')
endif

This is something worth getting right the very first time, imho! Let's establish a convention of keeping vim configuration inside the vim configuration; and leave it up to the users to integrate the behaviour with their keybinds / plugins / etceteras.

[ELLIOTTCABLE]

(Another side-effect of the current implementation is causing issues like #552. Making GUI-actions more robust, configurable, and idiomatic, would obviate an entire class of such issues in the future.)

[tmerten]

Interesting though to put all GUI settings in the .vimrc/init.vim @ELLIOTTCABLE .

In that case, however, the gui settings should be consistently done so in the whole vimr.app (which would imply a breaking change).

Anyway, since I don't know even a fraction of swift and such I can just give my five cents speculating on requirements.

Maybe

1. the CMD+, preference pane could then simply give instructions on what is possible to configure (something like printing the an equivalence of a help vimr-gui-preferences - that name could be choosen wiser, though ;) ) or
2. one could offer both things side by side and display corresponding vimrc settings for every gui option.

(maybe these thoughts are advancing to another/different issue)

[runningskull]

It looks like this used to be configurable at one point (and still referenced in the wiki), but isn't anymore. Now the behavior seems to boil down eventually to this line, though perhaps these lines (one jump up the call stack) would be the place to check for a user preference. A hearty 👍 from me on this as well.