Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra file information in the header #1701

Open
akharrou opened this issue Jun 23, 2021 · 7 comments · Fixed by #1988
Open

Extra file information in the header #1701

akharrou opened this issue Jun 23, 2021 · 7 comments · Fixed by #1988
Labels
feature-request New feature or request

Comments

@akharrou
Copy link

akharrou commented Jun 23, 2021

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

image


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 !

@akharrou akharrou added the feature-request New feature or request label Jun 23, 2021
@akharrou akharrou changed the title Can we add header information without losing syntax detection ? Can we add extra header information lines, without losing syntax detection ? Jun 23, 2021
@akharrou akharrou changed the title Can we add extra header information lines, without losing syntax detection ? Extra file information in the header Jun 23, 2021
@sharkdp
Copy link
Owner

sharkdp commented Jul 25, 2021

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: #1311 (comment))

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.

@mdibaiee
Copy link
Contributor

mdibaiee commented Dec 24, 2021

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

@keith-hall
Copy link
Collaborator

keith-hall commented Dec 24, 2021

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.

@Enselic
Copy link
Collaborator

Enselic commented Jan 2, 2022

@mdibaiee I took a high level look at your PR and it was a good start 👍

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.

@mdibaiee
Copy link
Contributor

mdibaiee commented Jan 2, 2022

@Enselic I like the idea, I don't think much will change in the code, but it will be simplified to some extend 👍

@mdibaiee
Copy link
Contributor

mdibaiee commented Jan 2, 2022

@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.

@Enselic
Copy link
Collaborator

Enselic commented Feb 7, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants