You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I read your blog post and share the same goal of reaching the panacea for a terminal-based IDE. My workflow is to use a TUI file-manager (like projectable) as a sort of vim multiplexer. That's simple enough, but a game-changing feature is the ability to invoke the TUI from within vim. In practice, this allows me to fly around yet never get lost ( too lost ;) ). P.S., I apologize in advance for this loaded issue. I have some general ideas and relevant context that makes this difficult to splice into clearly defined issues.
The vim plugin vim-floaterm makes it possible to invoke TUI tools within vim (see examples).
For this to be possible with projectable, there are a few things that need to happen:
optional panes -- When launching a TUI in vim, it is usually working with less screen real-estate. As is, the view is cramped. Making the "preview" and "log" panes optional would create more room for the file manager in this use-case.
The ability to modify the behavior of custom commands. Specifically, the ability to instruct projectable to close after issuing a command (this would enable integration with vim-floaterm).
Expanding on (2) a bit... A comparable TUI file-system, broot, defines commands (or "verbs") like so:
{
invocation: echo-and-exit
keys: [
enter
right
l
]
external: "echo {line} {file}" # this is picked up by vim-floaterm
set_working_dir: false
leave_broot: true # exit TUI after command executes?
apply_to: file # any one of: "any", "file", or "directory"
}
This is the actual command I use to integrate Broot with vim-floaterm. It's nice that it has the option to define multiple keybindings for one action, and it is essential that the TUI exits after the command executes. I can also specify that the command only execute against files, not directories.
While these are good enhancements, this is not to say "be like Broot", at least not totally. The hypothetical "best" tool in this space is one that blends simplicity with capability in an elegant way. I am fond of 2 tools in this space today, llama and broot. On the spectrum of simple vs. capable, llama is far on the simple side, and broot is on the side of being very capable (yet complex). With a few enhancements, I think projectable has an opportunity to strike this balance just right.
And of course, great work on projectable!
The text was updated successfully, but these errors were encountered:
I read your blog post and share the same goal of reaching the panacea for a terminal-based IDE. My workflow is to use a TUI file-manager (like projectable) as a sort of vim multiplexer. That's simple enough, but a game-changing feature is the ability to invoke the TUI from within vim. In practice, this allows me to fly around yet never get lost ( too lost ;) ). P.S., I apologize in advance for this loaded issue. I have some general ideas and relevant context that makes this difficult to splice into clearly defined issues.
The vim plugin vim-floaterm makes it possible to invoke TUI tools within vim (see examples).
For this to be possible with projectable, there are a few things that need to happen:
Expanding on (2) a bit... A comparable TUI file-system, broot, defines commands (or "verbs") like so:
This is the actual command I use to integrate Broot with vim-floaterm. It's nice that it has the option to define multiple keybindings for one action, and it is essential that the TUI exits after the command executes. I can also specify that the command only execute against files, not directories.
While these are good enhancements, this is not to say "be like Broot", at least not totally. The hypothetical "best" tool in this space is one that blends simplicity with capability in an elegant way. I am fond of 2 tools in this space today, llama and broot. On the spectrum of simple vs. capable, llama is far on the simple side, and broot is on the side of being very capable (yet complex). With a few enhancements, I think projectable has an opportunity to strike this balance just right.
And of course, great work on projectable!
The text was updated successfully, but these errors were encountered: