Giter Site home page Giter Site logo

Filter to only include hunks? about bat HOT 17 CLOSED

sharkdp avatar sharkdp commented on May 5, 2024 8
Filter to only include hunks?

from bat.

Comments (17)

sharkdp avatar sharkdp commented on May 5, 2024 10

It's been almost two years, but I finally found the time to implement this. See #940 for details and screenshot.

from bat.

bendem avatar bendem commented on May 5, 2024 3

@bendem Could you elaborate what that means?

I mean that git supports highlighting inside of lines, which I don't think bat does yet. That would be an awesome feature to have.

diff-highlight
screen shot 2018-10-03 at 09 35 11

no diff-highlight
screen shot 2018-10-03 at 09 36 31

from bat.

ErichDonGubler avatar ErichDonGubler commented on May 5, 2024 1

I think that at this point a single flag or subcommand would be appropriate -- the assumption with a libgit2-based diff is that you're operating inside of a Git repository.

Requirements I'm confident should be part of this

This flag/subcommand (hereafter referred to as diff, which is definitely subject to bikeshedding):

  • will fail the entire command if not inside of a Git repo
  • should take a reasonable subset of options that map to common git diff invocations; some example invocations might be:
    • bat diff would display all unstaged changes, minus untracked files (a la git diff)
    • bat diff cached would display all staged changes (a la git diff --cached)
      • Alternative invocations for this use case could look like bat --diff --cached

Unresolved questions

  • Should this be a subcommand or a flag?

    • Flags would be unambiguous, but a subcommand might look more ergonomic (git-esque, in this case).
    • If a subcommand is desired, then maybe the following design would work:
      • bat print or some similar subcommand would be the default when only file paths are provided. For instance, given the following file structure: foo:
        $ tree
        .
        ├── diff
        ├── foo.txt
        └── print
        
          ...then:
        
        • bat foo.txt would be equivalent to today's functionality, inferred to be bat [print] foo.txt.
        • bat print would be ambiguous and return an error reporting that a file and a subcommand exist with that name. This can be resolved by using bat print print. This case could also just print a warning to stderr, since in this case the intent to print a file is NOT ambiguous.
        • bat diff would likewise report an ambiguity, as with print. This would have to be a hard error, and resolved with either bat print diff or bat diff --, depending on the intended subcommand.
      • Alternatively, bat <file> shorthand could simply be removed and get rid of the ambiguous cases in the above design.
  • Should bat diff be a filter of the format we get from bat print, or more of a diff pager?

    • The difference is that a filter would only show diff number column marks, while a diff pager would actually show the deleted/added lines a la git diff.
    • IIUC, treating this flag as a filter more closely matches the spirit of the --context idea in the issue you linked.

from bat.

ErichDonGubler avatar ErichDonGubler commented on May 5, 2024 1

Your first bullet point sounds like a waaay-streamlined version of what I just proposed. I would definitely choose that over what I suggested. :)

I would also vote for only doing the first bullet point as a first iteration -- I'd be happy with that, and I don't know how straightforward it would be to highlight things without the full file.

from bat.

fdcds avatar fdcds commented on May 5, 2024 1

@ErichDonGubler: Are you aware of https://github.com/dandavison/delta, which implements a pager for git diffs?

from bat.

ErichDonGubler avatar ErichDonGubler commented on May 5, 2024 1

@sharkdp: Not enough emojis to express my excitement. :)

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

Thank you for the feedback!

Nice idea! I actually was on a similar track here: #12 (see --context option).

Would you be open to a PR

Definitely! However, maybe it would be worth to first discuss some details here in this ticket?

For example, how would the command line interface (subcommand, option/flag) for that feature look like?

I'm not sure if this should be a special way to process diff/patch files or just integrated with libgit2 directly -- the latter is probably easier, since you're already using libgit2 as a dependency.

Yes, libgit2 sounds like the better option to me.

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

@ErichDonGubler Thank you very much for writing this up! It might take me a few days before I get back to you on this.

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

What I don't really like about adding a diff subcommand (or option) is that we open up a completely new field with that functionality. While we are not truly following the UNIX "do one thing and do it well" philosophy with bat, it is mainly a program that is intended to display file contents.

So here is a slightly different proposal that I would like to discuss:

  • Add a --diff-context=<lines> option (didn't come up with a better name for now), which, when enabled, would only show <lines> lines of context around modified parts of the specified files (the default would be "--diff-context=infinite").
  • Write a tool to provide git diff-like functionality. This could be as simple as
    git diff --name-only | xargs bat --diff-context=3

Edit: changed --hunk-context to --diff-context

from bat.

bendem avatar bendem commented on May 5, 2024

Since we are speaking about this and it's being considered, is there any plan for also supporting diff-highlight type of highlighting?

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

@bendem Could you elaborate what that means?

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

I think my proposal above should be rather straightforward to implement.

I think we should first (possibly in a separate PR) update the --line-range option to be accepted multiple times.

In a second step, we would then use the Git modifications and the value given in the --diff-context option to generate a list of line-ranges that could be processed by the already existing line-range functionality

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

@bendem Thank you for your feedback. This is not really related to this ticket. I don't currently plan to implement inline-diffs and I think that would be quite a substantial feature. If you think this should be discussed, please open a new ticket.

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

I think we should first (possibly in a separate PR) update the --line-range option to be accepted multiple times.

That first part has been implemented in #368

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

We are aware of delta. That's why we added it to the README.

from bat.

Mouvedia avatar Mouvedia commented on May 5, 2024

@sharkdp can you publish a new release?

from bat.

sharkdp avatar sharkdp commented on May 5, 2024

Released in v0.15.0.

from bat.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.