Request: marking, or simple buffer operations such as kill
Closed this issue · 7 comments
In the buffer listing view for filetree (using it as a replacement for ibuffer, bufler, etc), it could be cool to go a little further than just a view. A phase 1 approach might be allowing folks to say hit 'k' to kill a buffer. A phase 2 approach could be to hit 'm' to mark an entry (and show a mark column in the view set, I suppose) .. thjen hit 'x' to execute the marks, or something to that effect. My case would be the kill buffer - using the buffer list as an easy way to clean up whats open, but I could see a case for people to mark some for deletion (physical file delete) ... but that might be side tracking off into a whole other set of features.
(at that point, I coudl see a filetree-fileops package as an addon, to keep filetree itself clean and simple).
shrug
Love the package!
Coincidentally, I just added marking functionality. Individual files and files in subdirs are marked using "m" ("c" clears the marks). There's a little green triangle that gets placed to the left of the filetree showing which files are marked, and the header shows a count of how many files have been marked. Pressing "M" will filter to show only the marked files. Note that the marked file list persists through the other filtering operations, so there may be marked files that you don't see in the current view.
As far as commands like "kill buffers", "delete files", etc.. These are actually quite easy to add (it's just a command acting on all the files in a list), but I'm a little hesitant to make it too easy to run destructive commands with a couple key strokes :). What I think I can do is create the commands for these functions, but not tie them to a key-binding by default--users can add their own key bindings if they are comfortable with that.
Any commands you think would be useful besides filetree-kill-buffers (which would kill all buffers associate with files in the current filelist), and filetree-delete-files (which would delete all files in the current filelist)?
FYI, I just pushed a change to master with the commands filetree-kill-marked-buffers (tied to keybinding "K") and filetree-delete-marked-files (no keybinding). Both commands act on only the marked files. The process would be to use "m" to mark the file(s) you'd like to act on, and then press "K" to remove the associated buffers.
Let me know if you see any issues with the changes.
Thanks for the suggestions!
Maybe do a quick review of dired for ideas (and maybe your delete function should call that ones, if it does any crazy stuff.)
I'm thinking 'invert mark selection' maybe, for those cases you want to mark everything but a couple files.
Or mark by pattern (user enters a regexp, such as *json) to mark (or mark everything but..); maybe a 'r' key, or a m -> r or something.. so m -> r is regexp mark, and then a ! or something to invert
In my case, the 99.9% use case is 'kill marked buffers', so thanks for that :) I'll go suck it down..
edit: Did a quick try (I see you added K for kill the buffers) .. works a treat!
I imagine the hardest part about being a new (yet awesome!) package is getting the word of mouth out; hopefully the word spreads!
I could see a side-package (filetree-extras) or something, for doing dired type functionality; or even midnight commander (old Norton Commander) side by side type of stuff; like if you have two file trees open (or more), the ability to say .. compare two trees (see ztree if memory servers, though), to see which files are new or different modes, or fail to exist on one side or the other. And things like 'copy from this filetree to the other filetree' .. in midnight commander or other tools like that, its often 'left tree' and 'right tree' and then you have 'copy differences from left to right', that sort of thing.
But that may well be going Too Far, and I imagine is too far for filetree itself.
Another option for marked files - o to open them all. (Use case ... for the show recentf list; so rather than open one at a time, just mark mark mark, o ... blammo, half dozen buffers ready to go.)
Thanks!
Yeah, I think the open buffers use case for marked files sounds useful--I'll add that. Also, I think adding a filetree-mark-all function will be useful--it'll enable things like marking by regex via the filtering tools already part of filetree (e.g., f <RET> \.json$<RET>, then filetree-mark-all), or the "invert mark selection" case.
Yeah, getting the word of mouth out for filetree is a little challenging. Also filetree is a bit of an odd package, so I think it's not immediately obvious to people how they might use the package in their workflow.
Thanks for all the inputs on your use cases--I think fleshing out features to support concrete use cases like this, really helps improve the package!
FYI, added filetree-mark-all (tied to keybinding "A") and filetree-open-marked-files (tied to keybinding "o") in the latest checkin to master (239121c). Let me know if you see any issues.
Thanks!
Works well; open-marked-files opens in background which I didn't expect, but could be handy; open, then go mark some more for additional opening or other operations.
I think I'm done bugging you for awhile.. well done and thanks! 👍