This fixes #430
Continuing the work of #346 (/CC @tskinn)
* Allow for multiple occurrences of `--highlight-line <N>`
* Highlight the full line
* Proper handling for overlong lines
Continued discussion from #440 regarding `bat` showing diff chunks.
Currently, inside of a git repo, `bat` will compare the file being viewed with the previous version and decorate the left-hand gutter with
- Green `+` to indicate that the line has been added
- Red `-` to indicate that one or more lines have been removed
- Yellow `~` to indicate that the line has changed
This feature request asks that `bat` go a step further by inserting the block of old lines into the output:
- Where lines have been added, no change is necessary; they are decorated with a green `+`
- Where lines have been removed, display the old lines in a monochrome color (gray?) decorated with a red `-`
- Where lines have been changed,
- display the old lines in a monochrome color (gray?) decorated with a red `-`
- decorate the replacement/current lines with a green `+`
A couple additional things that would be nice to have:
- The ability to specify a commit ID to _diff against_, rather than only "the previous commit for this file"
- The ability to specify a commit ID to _view_, rather than the current version of the file
- Where the old lines are displayed in monochrome, highlight the differences in some way, similar to how [diff-so-fancy](https://github.com/so-fancy/diff-so-fancy) does:
We should add a "Integration with other tools" section to the README to document some of the ways in which `bat` can be combined with other tools:
- Use `bat` as a `--preview` program with `fzf`.
- Execute `bat` on the search results of `fd`/`find` via `fd pattern -X bat`
- Combine it with `git show` to view older versions of files: `git show v0.6.0:src/main.rs | bat -l rs`
- Use it with `xclip` to copy a file to the console
Change the default path to `bat`s configuration directory to
see #151, #375 and #419
We recently introduced command-line argument parsing for `PAGER` and `BAT_PAGER` and it's been causing some problems, because some people have set `PAGER="less -X"` (or similar) without including the `-R` argument which is needed in order for `bat` to work with `less` (enables parsing of ANSI sequences).
I think we should *disable* parsing of command line arguments for `PAGER` again but leave it for `BAT_PAGER`. If someone has `PAGER="less -X"` set, we should fall back to the default behavior (use `less` with `-FRX`).
Recently I needed a way to pretty-print some Rust code to the command-line while building [cargo-inspect](https://github.com/mre/cargo-inspect/).
I used syntect, but in a very crude way. It occured to me, that by using `bat` as a pretty-printer, I could piggy-back on what already exists and get features like line-numbers for free.
Probably other projects would want to do the same.
So I wonder if you considered providing a `lib.rs`, which would allow for using this crate as a library.
The `main.rs`, would then simply use the `lib.rs` as a dependency. That seems to be quite a common pattern. As an additional advantage, it would decouple the argument parsing from the rest of the code. Would that be possible?
Extracting this from https://github.com/sharkdp/bat/issues/23#issuecomment-431514541
> @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.
> @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.
![screen shot 2018-10-03 at 09 35 11](https://user-images.githubusercontent.com/2681677/46396496-d94d3800-c6ef-11e8-94ba-9381faee2e4f.png)
![screen shot 2018-10-03 at 09 36 31](https://user-images.githubusercontent.com/2681677/46396495-d94d3800-c6ef-11e8-9d8a-49f68548e8ad.png)
Hello, thank you for your awesome works on `bat` ! But I think there is a feature that still missing.
Suppose that I just want to change the line number color, I have to make a copy of the theme file and change its `gutterForeground` value. And the theme file is verbose, normally 400+ lines.
So it will be great the `bat` can provide an argument to overwirte the theme color e.g. `bat --theme Tomorrow-Night --colors gutterForeground=f5f5f5 README.md`.
Providing a PPA would be an awesome way to gain more users. Personally I usually don't install a .deb alone, unless is sets up its own repository, such that I will get updates automatically.
I am not really sure if this is an issue or intended behaviour.
It took me forever to move to end of a 6Mb file.
Steps to reproduce:
- `$ seq 1 1000000 > test`
- `$ bat test`
Press `G` to move to end of the file.
This step took a long time. It seems `bat` was going through the file sequentially.
Apologies, if this is not the place to ask this question or this is a known bug/feature.
Now that bat supports displaying a range of lines I would like to have bat be able to highlight one line.
My use case has to do with utilizing bat as a preview command in a fuzzy finder like [fzf](https://github.com/junegunn/fzf) or [skim](https://github.com/lotabout/skim).
Here is what we can do currently with bat: ![fzf](https://thumbs.gfycat.com/ShabbyHealthyChrysomelid-size_restricted.gif)
(I'm just using a copy of preview.sh I've put up [here](https://gist.github.com/tskinn/0ed07b1c43968807b24e0e585ae58ce2))
So how can or should this be done? Invert the colors of the line? Does syntec api have something that makes this easy? Or should we just manipulate the grid portion of the display like the line number or insert an arrow in that gutter?
Again I'd be happy to work on it but would like some input before I do.
First: congrats on the release, and props for creatively putting together the pieces that make this work!
Anyway: It'd be really neat if this could be used as an alternative to the default `pager` in Git -- this is REALLY nice-looking, and I'd love to use this as a pager. Would you be open to a PR or implementing yourself a feature to filter out everything that's not a hunk in a diff? 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.