It’s in a very early stage of development, but well enough for my day-to-day work.
The kak script part is the bare minimum.
Note that my devs may focus mainly on my own needs (Sway as WM and Git as VCS). I’d gladly accept any contribution, especially on the tmux part (which I don’t use).
The next step is to implement a nice help, as I realized that the only way to know about the keybindings is reading the code.
(Thanks to @andreyorst for letting me know about this place, and for all his plugins (including kaktree) )
Do you plan on extending file manager so it could be interacted without gui?, I mean, so someone could embed it directly to the buffer, like I do with kaktree? This way the file manager could provide directory and tree information to the editor, and on kakscript side we could parse it and construct the buffer the way we want. This also will make it possible to use your filemanager in other editors like Emacs and Vim by writing wrapper script. What do you think?
Short answer: Not possible at the moment, but feasible, desirable, and could be done in a near future
Long answer:
“PT” in “PTFM” is Prompt-Toolkit, a well-known terminal UI in python (they even wrote pyvim with PT as a proof-of-concept). That said, the name can change :), I’m not happy with it.
At the moment the main internal tree is quite tied to the UI. I did thought a clean architecture with clear separation of concern, mainly for maintainability, but I took some shortcuts that blur the lines.
I plan a rework/cleanup of the internal architecture to be able to manipulate other trees than the file system (Tree-sitter｜Introduction comes to mind), I might end up with something where the UI itself is plugable.
On the other hand, the very point of PTFM is to develop the UI outside of the editor, I did try a long ago to implement the tree view in Kakoune, with an external server, it was a mess (Kudos for kaktree ).
With this design an editor integration is two-fold:
adding a thin launcher in the editor config, ptfm.kak is minimal but enough (there’s a lot to add here, in terms of user preferences, but the core is just launching ptfm).
adding a ClientControler class like those that implement a handful of methods to communicate with the editor. (at the moment I took a lot of shortcuts here, but the implementing class will be chose in ptfm command line).
This solves another problem: the controler interacts with the editor and with the WM. In the future PTFM will use python dynamic class creation to cover the whole matrix.
Lunch thoughts: It’s definitely a good idea, let’s get in touch when I do the cleanup pass to define the exchange format and protocol (JSON over kak -p ? ).
I think it would be nice if Kakoune could request (via shell expansion) certain directory to be returned as a some kind of data structure that could be easilly parsed by some tool (JSON may be a good choice because of jq) and script would transform this data to the listing. After that point interaction with the tree could be made by requesting the tree leaf information that will be turned into buffer information. I think your FM display engine itself could internally work like that, thus expanding these data structures beyond the FM makes it possible to write GUI or another TUI.
At least that’s how I would do that, but I’m no expert by any means. This is kinda how kaktree works. It request directory listings from ls with some flags, parses it with Perl subroutine, constructs thee as text inside other Perl subroutine, and returns that text to Kakoune to display. In my case the problem was the persistence of data, e.g. if I unfold a directory, and then unfold something inside, and after that fold the first directory, the unfolded state of second one inside the first one would be lost. Refreshing the tree also closes all folds, because we actually refresh only current directory and not the tree. Because there’s no tree in kaktree, except the visual tree. I had plans on working this out, but decided that it doesn’t worth the effort in the long term (as of this moment).
(including kaktree) )