bat -p should also default --wrap never

[wakemaster39]

When using cat on files containing long string like in id_rsa.pub, you are able to easily highlight and select the text and paste it anywhere and its copied verbatim. Using bat, since the default is to wrap output internally and not have the terminal do it, this causes additional line breaks in the copied text. This is extremely misleading when you are doing things like transferring text and using terminals of the same width so you do not see the added line breaks.

Adding the --wrap never along with -p is cumbersome and leads to falling back on cat instead.

Is this option configurable if I was to alter the theme?

[eth-p]

AFAIK, you can't configure it by altering the theme.

However, I agree that -p should also disable wrapping. Wrapping was meant to be used when the terminal's wrapping was inadequate (e.g. when the sidebar is there) and caused visual inconsistencies. When there isn't a sidebar, the terminal wrapping does a better job and it doesn't really make sense to have bat the wrap lines itself.

[sharkdp]

@wakemaster39 Thank you for the feedback!

Absolutely agreed, wrapping should be disabled for the plain style.

[sharkdp]

Fixed via #291 by @eth-p

[sharkdp]

Released in v0.7.0.

[falzm]

Hi, I've just upgraded to v0.7.0 and it doesn't seem to disable wrapping when invoked with --plain (still have to specify --wrap never). Am I missing something?

[sharkdp]

@falzm Thank you for the feedback!

I can confirm this - our implementation in #291 is wrong. I already have a fix.

[falzm]

Thanks!

[sharkdp]

Fixed in v0.7.1

[ernstki]

Hi, all. I'm using ranger, specifying bat as the previewer for Markdown files in scope.sh.

Within the ranger preview pane, tput cols does not report the correct viewport width, but they provide an environment variable that does, $PV_WIDTH (preview width).

Because of the outcome of this issue (-p disables wrapping) and the fact that wrapping settings are ignored anyway when stdout is not a terminal (app.rs line 190), I've been unable to coerce bat into giving me plain, wrapped output.

What I've resorted to is bat -p --color=always "$FILE_PATH" | fmt -s -w $PV_WIDTH, and I guess it's OK, but it seems like something bat could do (or used to be able to do).

I've made a screenshot to hopefully better illustrate everything I'm talking about above (large, so I'm not embedding it here).

Is there some other trick I'm missing to get --style plain and have the --terminal-width and --wrap options work together, to give me plain, wrapped output from bat? Also, is it just me, or does bat not do word wrapping (wrapping on word breaks, rather than in the middle of words)?

If the answer is "that's beyond the scope" or "it's not bat's job to do that" I understand. Thought I'd ask.

[eth-p]

@ernstki Good catch on it not being possible to wrap when stdout is not a terminal. That was done before --terminal-width became an available option, and correcting it should be a simple fix to your issue.

A solution would be to keep wrapping enabled if --terminal-width is present, even though it's not printing to a terminal:

- output_wrap: if !self.interactive_output {
+ output_wrap: if !self.interactive_output && !self.matches.is_present("terminal-width") {

---

You are correct about bat not having word wrapping. I was the one who added the wrapping feature, and I wasn't able to come up with a decent solution for how to do word wrapping at the time. The styles parsed by syntect weren't suitable as word boundaries, and I didn't want to implement word breaking that failed to take the language into consideration.

[ernstki]

OK, I understand that being more of a challenge with the embedded formatting from syntax highlighting.

I'm apprehensive about just implementing your suggestion in a new pull request, because

0. is it really a bug?
1. is it something that bat really needs to care about? (feeping creaturism, and all that)
2. is --terminal-width really what you would want to call that option?
   • the desired width in that use case has nothing to do with the terminal, per se; it'd be more apt to call that just --width or --output-width
     • and again with the feature creep

I think if no one else is asking for this, maybe it's best if I just keep a patchfile around on my end.

[eth-p]

It's definitely not a bug, but it is an outdated behaviour that could be improved upon fairly easily.

I also wouldn't consider it to be feature creep. The --terminal-width option already exists, and has been "available" (i.e. not hidden) since dda27b2. All the patch would do is change the behaviour of --wrap to respect that the user wants wrapping even when stdout isn't a terminal (and when a width is provided with --terminal-width).

I do agree that the option would be better named as --width or --output-width, but that could be problematic for backwards compatibility with scripts that already use --terminal-width.