Refactor terminal files and add file manager commands

[David Tejada]

Here are some of my observations regarding terminal commands:

• apps/generic_terminal/generic_unix_shell.py and apps/generic_terminal/generic_windows_shell.py are identical
• apps/generic_terminal/generic_windows_shell.py isn't used anywhere, the tag that matches this file is user.generic_windows_shell but it isn't applied in any talon or python file
• the tag generic_windows_shell is defined in code/tags.py and applied in apps/platforms/win/powershell/power_shell.talon but again there is no context that matches that tag without the user. in front
• file manager commands like for example go talon user that are defined in code/file_manager.py are left to individual apps to implement. I copied the commands from apps/platforms/win/mintty/mintty.py to my alacritty.py and they worked without changes. I think this commands could be added it to apps/generic_terminal/generic_unix_shell.py to have it working out of the box for all unix terminals

I propose to:

• Remove generic_windows_shell.py and apply the tag user.generic_unix_shell to power_shell.talon
• Add the file manager commands too apps/generic_terminal/generic_unix_shell.py
• Remove the file manager commands from apps/platforms/win/mintty/mintty.py and any other file that already applies the tag user.generic_unix_shell

I can submit PR but I wanted to check what you people think. I also don't use Windows so I don't know if I'm missing something here.

[splondike]

I think there are a couple of things that are different to the above:

• The terminal_list_all_directories action is different in generic_windows_shell.py .
• The usage of tag(): user.generic_windows_shell in app/platforms/win/power_shell.talon should enable the command implementations in generic_windows_shell.py unless I'm missing something.

The usage of the file manager commands in various terminals looks a bit weird to me. There are quite a few commands in apps/file_manager.talon that don't seem relevant/would not be easy to implement.

I imagine it's just the go <folder name> commands that you find useful? Perhaps that could be split out in to its own concept backed by a Talon list+capture? That could then in theory be used in GUI file managers, the terminal, Slack, Outlook etc.

[David Tejada]

Thanks for taking the time to look into this.

I can see that the action terminal_list_all_directories is different, sorry about that. But still we could have less duplicate code if we just re implemented that action for windows. I don't know if it's worthy though, maybe it's clearer the way it is now.

Yes, that file was changed in this commit after I filed this issue. @knausj85 must have seen it. I think issue #770 was related to that.

I agree with what you said about the file manager commands in terminals. Yes, go <folder name> is the only command that I was interested in. The concept of a capture + list it's interesting. Would that capture just return the path of the folder? We will have to take into account things like this, right?

[splondike]

Ah right, makes sense! The shifting sands of git repos :).

I agree that it is probably a bit clearer with the current duplication of code in the shell files; probably not worth abstracting it.

With the list+capture thing I'm reconsidering how generalised to make it. While it could be used for Outlook folders etc. that may be a bit too abstract for the benefits it gets us (the 'go ' command). So let's just say it's about file system paths.

So yeah, I think the list would be a map between the thing you say and the file system path. You'd wrap that list in a capture in the commands since that allows the end user to easily extend the list without having to completely replace it (let me know if this pattern isn't clear, I intend to document it in the wiki one of these days).

You'd use something like that block of code you linked to to populate the initial list. You'd move the file_manager_open_user_directory action out to something like file_system_paths_open_user_directory but could otherwise just remove that OneDrive block and keep the rest the same.

[David Tejada]

I understand how to wrap a list in a capture, and I already have it working. This is how I have done it:

@mod.capture(rule="{user.system_paths}")
def system_path(m) -> str:
    return m.system_paths

But could you please explain how is it better for extensibility than just having the list available for the user?

I don't think we need to keep file_manager_open_user_directory around since the capture is going to be returning the full path, taken into account the Onedrive stuff, and that is the sole purpose of that function. So in file_manager.talon we can just have:

go <user.system_path>: user.file_manager_open_directory("{system_path}")

And in generic_terminal.talon:

go <user.system_path>: insert("cd \"{system_path}\"\n")

Do you think it would be interesting to also import user paths from a .csv so the user can define their own paths easily?

[splondike]

For the list, wrapping it in a capture lets the user extend the list without having to completely replace it. For example in my personal config I have overridden the user.symbol_key capture to just add the 'semi' command without having to completely redo the list as I've done for user.special_key. Note how I've redefined the capture rule in the @ctx.capture line.

Those .talon lines look good to me. It probably would make sense to load extra directories from a CSV if you can be bothered (see the get_list_from_csv function in user_settings.py). If not, then the user still has the option of writing some code to override the matcher (which probably knocks out non-programmers, but better than nothing).

[David Tejada]

Overwriting captures was the missing piece for me, but I understand it now. I already submitted the PR: #802. I would appreciate if you could check it out