Request; file info in right? (or maybe I can make an org function..)
skeezix opened this issue · comments
I'm thinking how ibuffer or bufler (or selectrum+marginalia more specifically) show some file attributes, buffer modes, and file sizes to the side; that could be pretty neat.
I didn't use the org notes feature (yet!), so maybe that same panel could be co-opted rather than faking a column in the main tree view. (It also occurrs to me, could make a function that auto-regenerates the org notes file on occasion such as file-save or something, so as to keep the notes up to date with selected file permissions etc.. but that feals like the wrong way to do it.)
Any ideas?
Thanks for a cool package; I've switched from bufler -> ibuffer (didn't handle tramp well) -> filetree with icons enabled. Nice!
Thanks for the comments and suggestions -- I'm glad you're finding the package useful!
Yes, I have been thinking about how best to add additional information associated with the files in the filetree window. I prefer not to use the side window for showing this info for a number of reasons (mostly associated with keeping the two windows row aligned, e.g., font mismatches between windows, scrolling, split windows). I'm trying to decide between a couple of other options. One simple option is to add additional information in the default header (i.e., where we currently show the number of files, stack size, etc.); the drawback there is that we would only see the information for the file the pointer is currently on, and the information would be displayed potentially far from where the file is shown in the tree. The second option is to put information columns right justified in the main filetree window; here the issue is just with window real estate, since (deep) trees can span far to the right. I'll need to play around with the text to see if I can get it to be relatively clean. I'll plan to start with option 1 (add information to the default header), and then look into option 2.
BTW, on using the filetree-show-cur_buffers as a replacement for ibuffer, note that only the files associated with buffers will be shown--and the only buffers that will be represented will be the ones associated with files. So you wouldn't see the Messages or scratch buffers, for example. I'm sure you're already aware of this, but I just wanted to highlight that.
Thanks again for the feedback!
I'm aware of buffers being dropped from the list .. I consider it a feature. (I sort of assumed their regexp or somesuch was in the supplied filter variable, but didn't go looking.)
I consider it a feature .. I found ibuffer and bufler distracting with all the 'noise', so I had to put in functions of my own to filter out that stuff. (Also, they were too slow regarding Tramp.. I didn't torture filetree yet, but it seemed faster at first blush. Sort of hoping that if icon mode is off its not going to determine file types or metadata too much, but we'll see ;)
So, when I hit C-x C-b to get a buffer list, I want it to be files I opened on purpose (actual files.)
When I hit C-x b to switch buffers (and I'm using selectrum+marginalia+orderless) I get a nice complete buffer listing that I can easily sift through with orderless; type in 'ess' to get Messages showing up say, or whatever.
So I like C-x b to be complete buffer list, and yet C-x C-b to be a visible list of files I opened. My use case is 'hey, I've got 3 projects open with 40 files, let me see at a glance as I forget which one has this thing in it.. oh, there it is, right!', where as C-x b I want to be able to find a buffer across the works, but I've got a pretty good idea which one I want already.
--
For where to place metadata .. you could have it toggle on and off (like you do with other features), and maybe just view it on the left of the tree; toggle it on and poof, thre tree moves over 20 chars (or whatever), and the size and mode are shown; maybe a key to cycle through view-sets, and a user definable variable that defines the view sets. Default view sets could be things like..
( "set1"
( mode, size )
"set2"
( creation, modification, size )
)
Something like that?
Yeah, I filter out the non-files from the buffer list (simply because there's really no way of representing them in the file tree). Your use case for filetree-show-cur-buffers is exactly what I was intending :).
I like your idea of having the metadata on the left of the tree--don't know why I didn't think of that :). And yes, I would make it toggle (or possibly cycle as you suggested). Will plan on adding this functionality.
Thanks for the suggestion!
Hi @skeezix, just FYI, I check in an initial version of this feature in the dev branch. The user can use the "]" and "[" keys to cycle through different view sets. Currently I have 4 view sets:
- no info
- modes+size+last mod date
- modes+size+last mod date+vc state
- vc state
This is configurable, so users should be able to put whatever view sets and info they want. A view set is basically a list corresponding to each of the columns of info, and for each column of info the user specifies the column heading, column width, a function that takes a file or dir name as input and returns a (possibly "propertized") string with the info to display, and a setting for the column justification that should be used.
For example:
;; cycle 1 - modes/size/last mod
(("Modes" 11 filetree-get-file-modes "right")
("Size" 7 filetree-get-file-size "right")
("Last Mod" 12 filetree-get-file-last-modified "left"))
Here's a short clip showing example output:
I plan to test it for a little while on the dev branch before merging it into master. Let me know if you have any suggestions for changes.
Changes have been merged into master in 29a4012. To use the feature use "]" and "[" to cycle through the different view sets.
BTW, I ended up removing the "vc state" info, because it wasn't giving the latest vc status the way I was doing it. Will look into how other package get the latest vc status of a file (without opening the file).
I updated from melpa, and when hitting [ or ] I just get 'the buffer is read only'; did you push upstream, or should I pull from the github here using straight.el for awhile?
Thanks!
Hmm, that's strange.
I believe I did push the changes upstream (to master), and when I look on melpa (https://melpa.org/#/filetree), I do see the right SHA being pulled in the melpa build. Don't know if maybe there was just a delay in the build update on melpa? Let me know if you still see the issue after some time.
okay, I'll pull again; I manually clobbered my local just to trial the features. Love it!
Set myself up a default override for the defcustom and good to go.
Maybe specify a face for the info (or per column, may be too far) so that we can specify the colors/fonts to use per info type?
Alright, all good my mistake I suspect - maybe my Emacs cache wasn't updating; restarted it (gasp) and wiped the elc, and it pulled good.
Just so I don't lose the request - "Maybe specify a face for the info (or per column, may be too far) so that we can specify the colors/fonts to use per info type?"
Danke!
Great! I'm glad that worked out.
On the faces for the columns, I can add a face configuration for the column headings (currently all the headings use a bold face).
For the contents of the columns, the current setup is that the face property is applied within the functions used to calculate the column strings (e.g., filetree-get-file-modes)--these functions return a (potentially propertized) string given a filename as input. The reason I wanted to do it this way is to give the user the ability to define functions that selectively propertize the entries in that column--for example, in the file size column the user could write the function to use red for entries larger than 1G to highlight big files (another example is that the file modes currently use a bold face for directories).
One option if you'd like to set the face for all the contents of a column, would be to use an advice call, e.g., to make the face for the file size column contents green:
(advice-add 'filetree-get-file-size
:filter-return (lambda (x) (propertize x 'font-lock-face '(:foreground "green"))))
What do you think?
Works out pretty well; I do like the idea of a per-cell function call that we can override .. thats clever; but I do like column level consistency .. and that advice trick works really well.
Now I'm applying way too much amber and green to things to make it look like old school terminals and BBSes, but I likes :)