Get file path from tree view

[eddyc]

Hi,
Thanks for this very useful package! Would it be possible to get the file path from the selected file in the tree view. This would make it possible to run processes on files that don't open an editor window, or that don't have a focused editor window.
Cheers
Ed

[morassman]

Hi @eddyc

That would be possible. I think there's more than one way to approach this, so I'd like to get your input before I start working on it.

First a bit of background
All the {file*} variables resolve against the file of what Atom calls the "active editor". This is not only the editor currently being used, but also the last editor that was used even if that editor doesn't have focus anymore. When, for instance, the tree view has focus and one runs a command then the file of the active editor will still be used regardless of what is selected in the tree view.

As I mentioned, there is more than one way to do this. What kind of behaviour would you like? Here are some options:

• Use the tree view's selected file when the tree view has focus, but the editor's file when the editor has focus. Whichever file is chosen will then be applied to the {file*} variables. This option might get ambiguous when neither the tree view nor an editor has focus.
• Define new variables specifically for the tree view, such as, {treeFilePath}, {treeFileName}, etc. A command that uses these variables will then always be applied to the selected file in the tree view and not to the file of the active editor. This option is less flexible, but helps to sort out ambiguity.
• Another suggestion?

[eddyc]

I think it would be best to use the second suggestion, although it introduces new variables, it is the most explicit way of specifying that you want the selected file in the tree view, and avoiding any ambiguity is always nice.

[morassman]

I'd like to make another suggestions.

I can add a context menu to the tree view that allows one to run a command on the file that is selected. This way it is not ambiguous nor is it necessary to define new variables.

If you've worked with Eclipse before then you may know that it implements this behaviour. You right click on a file and then choose what you'd like to run that file with. It works very well and it's clear to the user what will happen.

Would this approach work for you?

[eddyc]

Yeah, that sounds even better, the way I envisioned working with it would be to select and right click files in the tree view then run tasks from the context menu, although I was thinking I’d have to specify the various menu items for process-palette tasks in my init script. I think this would be a great way of implementing it. Ed

…

On 15 Jul 2017, at 16:31, morassman ***@***.***> wrote: I'd like to make another suggestions. I can add a context menu to the tree view that allows one to run a command on the file that is selected. This way it is not ambiguous nor is it necessary to define new variables. If you've worked with Eclipse before then you may know that it implements this behaviour. You right click on a file and then choose what you'd like to run that file with. It works very well and it's clear to the user what will happen. Would this approach work for you? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEsThr746u8Tmvc4RzmMMNatosLoFjOks5sONtggaJpZM4OXmj4>.

[morassman]

Great! I will do it like that then.

The entries in the context menu will be generated automatically based on which commands use any of the {file*} variables as input.

There's one thing to keep in mind when using the context menu in the tree view. You might have noticed this yourself. When one right clicks on a file in the tree view, the selection changes to that file in the background, but the highlight only updates once the menu closes. This can be misleading, because there isn't a visual indicator that the file that the command will be applied to is the one under the cursor. This behaviour can be verified by selecting a file and then right clicking on another file and choosing, for instance, to rename it. The file that will be renamed is not the one that is highlighted, but the one that was clicked on. This behaviour is unfortunately out of my hands and will be the same for this new feature.

[morassman]

I've released v0.14.0. It has the feature as described before. You do not need to do anything on your part for it to work. Commands that use any of the {file*} variables are automatically detected. When you open the context menu on a file in the file tree you will see a 'Run With' menu from which you can choose the command to run the file with.

[eddyc]

Thanks it works really well. Would it be difficult to arrange the context menu according to the 'Menu:' setting for each specified process?

[morassman]

Do you mean so that the context menu mirrors the layout of the main menu as configured for the command?

If that is the case, then no, it shouldn't be too much effort.

[eddyc]

Yes, instead of having the context menu for 'Run With' just flat, it would be nice to mirror the layout configured for the command, especially if there are a lot of commands.

On a related note, and I realise this would probably require many more changes, possibly adding a category to the process json, would it be possible to detect the file extension and only show/run processes if they apply to that file in the treeview and/or editor?

[morassman]

The same thought occurred to me as well. I think it is a logical next step for a feature such as this.