bat
bat copied to clipboard
Extra file information in the header
Sometimes, you want to quickly glance at more information, in the header, than just the file name, e.g.: mime type, or file size, or relevant timestamps/dates, or full path, or permissions, etc.
I've managed to somewhat accomplish this with just the --file-name
option, but (A) I don't feel it's really appropriate, and (B) syntax detection fails, so you don't get any highlighting which sucks, and (C) the grid lines aren't printed:
❯ f=LICENSE.txt && bat \
--file-name "$f
Canonical: $(greadlink -f $f)
Filetype:$(file $f | cut -d':' -f2)
$(stat -x $f | tail -n3 | sed -E 's/^(.+)/ \1/')" \
$f
So yeah I thought this might be an interesting feature, that perhaps others might find useful as well. Also this would make the fzf
& bat
integration really quite nice and even more useful.
To be a bit more precise on the actual feature, without getting into implementation: a feature that allows inserting a variety of other useful information on the file, in the header. Either you could provide us with a list of possible additional informations, kinda like --style
's possible values, and we list them out in an option, e.g.:
bat --header-info=fullpath,filetype,access,modify,change[,...]
AND-additionally/OR provide the ability to specify arbitrary scripts that produce some text output, or some formatted (e.g. JSON, XML, HTML, or your custom designed format) output, something that you can easily read and print in the header; also you could limit the output to 1 line, or maybe not, I don't know. This could be kind of like fzf
's --bind '...:execute(<script>)'
option, where the user provides a script, i.e some chain of commands and not a script file, of what they want. E.g.:
bat\
--header-info=fullpath \
--header-info=execute(file {} | cut -d':' -f2)
{}
being a placeholder for the file.
The output would be printed in the header, 1 line under the other, in the order specified.
Also, Thank you for your wonderful work with bat
and all the other command line tools you've created, they're really useful !
Thank you for this feature request. I would also like to see this being integrated into bat
! (see related comment by me a while ago: https://github.com/sharkdp/bat/issues/1311#issuecomment-708572267)
As for the details on how this could work, it would be great to discuss this here in detail before anyone attempts to implement this. I think I like the --header-info
idea best, but it would be great to explore a few options.
Hello 👋
I'm interested in working on this. I think we can start by having a basic list of information that can be toggled on/off using --header-info
, similar to --style
, as suggested by @akharrou.
I can propose we start with implementing these basics, and later on we can extend it to include more if necessary:
- human readable size
- owner:group and file mode (e.g.
root:root (rw-r--r--)
) - last modified timestamp
More information to add later:
- encoding of file (e.g.
utf-8[unix]
) - mimetype
- full path
I don't think it needs to be multi-line necessarily. I'm drawing inspiration mostly from ls -lh
, vim
and less -M
, and they all just have the basic filename at one corner, and other information follows it with a tab/space. But I'm open to suggestions regarding this, would you rather:
File: tmux.conf
Last modified: 16 Aug 2020
Permissions: mahdi:mahdi rwxr-xr-x
Size: 3.3K
Or a one-liner:
tmux.conf mahdi:mahdi rwxr-x-r-x 3.3K 16 Aug 2020
Personally I find the multiple lines much clearer. EDIT to add: plus, then, if it is an all or nothing option, line length / terminal width becomes less of a concern, and we are free to add more info later.
@mdibaiee I took a high level look at your PR and it was a good start :+1:
My main high level concern is if we really want to introduce a new option type (--header-info
). In a sense, the existing --style
option already allows control of the header. But it only allows hide/show of the file name. Looking at --help
for --style
we currently have:
Possible values:
* full: enables all available components (default).
* auto: same as 'full', unless the output is piped.
* plain: disables all available components.
* changes: show Git modification markers.
* header: show filenames before the content.
* grid: vertical/horizontal lines to separate side bar
and the header from the content.
* rule: horizontal lines to delimit files.
* numbers: show line numbers in the side bar.
* snip: draw separation lines between distinct line ranges.
I would like to propose that we change this (in a compatible way) to something like this:
Possible values:
* full: enables all available components (default).
* auto: same as 'full', unless the output is piped.
* plain: disables all available components.
* changes: show Git modification markers.
* filename: show filenames before the content.
* filesize: show filesizes before the content.
* lastmodified: show modification times before the content.
* grid: vertical/horizontal lines to separate side bar
and the header from the content.
* rule: horizontal lines to delimit files.
* numbers: show line numbers in the side bar.
* snip: draw separation lines between distinct line ranges.
I think that has the potential of simplifying both the code and the CLI quite a bit. If you think it sounds like a good idea, it would be great with a quick and dirty prototype to get a sense for what the code would look like with such an approach.
@Enselic I like the idea, I don't think much will change in the code, but it will be simplified to some extend 👍
@Enselic Just a note: I had to slightly deviate from code of Style when implementing header information, because in the current --style
option, ordering doesn't matter as the ordering is enforced / hardcoded, however in header information I used a Vec
which allowed ordering to be customised by the user. To use --style
we would have to hardcode an ordering for the header fields, this might introduce slightly more complexity, but let's see how it turns out.
Thanks to great work by @mdibaiee in #1988 we now support adding info about file size to the header!
Before we can fully close this issue I think we need to add support for at least a few more fields.
We need to fix #2061 before we can do that though, IMHO.