could you add edit mode?

[FoxDaxian]

bat is awesome plugin, even if like now, bug it's a pity that you can't edit.

[FoxDaxian]

just like sample vim...

[sharkdp]

This is definitely out of the scope for this project (see Project goals).

I quickly thought about the possibility to open an external editor from the pager (less). There is actually a key for this (v - Invokes an editor to edit the current file being viewed), but this doesn't work since we pass input to less via standard input. It therefore just shows "Cannot edit standard input". There is the LESSEDIT command-line option that allows users to change the way the editor is invoked, but apparently it's not possible to bypass the "Cannot edit standard input" error.

[FoxDaxian]

wow, do you have a plan to make a vim version? : D

[sharkdp]

I don't really know what you mean by "vim version", but I think this discussion is leading nowhere. I'm going to close this, but feel free to comment here if you think there is still valuable feedback.

[chaoyi]

This is definitely out of the scope for this project (see Project goals).

I quickly thought about the possibility to open an external editor from the pager (less). There is actually a key for this (v - Invokes an editor to edit the current file being viewed), but this doesn't work since we pass input to less via standard input. It therefore just shows "Cannot edit standard input". There is the LESSEDIT command-line option that allows users to change the way the editor is invoked, but apparently it's not possible to bypass the "Cannot edit standard input" error.

Bash process substitution could be used to bypass the "Cannot edit standard input" error. Something similar to function open-in-emacs { LESSEDIT="emacsclient -nw ?lm+%lm. \"$1\"" LESS= less -fR <(bat --color=always "$1"); }

[cben]

A quick way to reproduce less refusing to apply LESSEDIT on stdin: [I'm launching bat separately from less for easy experimentation, but is the actual idea is for bat to keep launching less just with customized env vars]

bat --force-colorization README.md | env LESSEDIT='nano README\.md' less

and pressing v while in less results in:

Cannot edit standard input (press RETURN)

• I suspect that refusal was motivated by primary use case of exporting LESSEDIT permanently, with values like nano %g that use the name of the file. In that scenario, there is no globally-applicable meaning to user "wanting to edit stdin", nor a safe way for less to interpolate "stdin" file name into the command just to try whether it understands that. It can't work anyway because stdin was already consumed by less.
• What we want to do is launch less each time with hard-crafted value telling what we mean by "edit".
  • [ ] Perhaps less could be persuaded to make its refusal conditional on presence of %g, %f, or %F file name in LESSEDIT? (Even if yes, users would need newer less to benefit.)

But inspired by @chaoyi's find above, looks like simply giving a name e.g. /dev/stdin seems enough to placate less! (with --force so it agrees to read it, not being a "regular file")

bat --force-colorization README.md | env LESSEDIT='nano README\.md' less --force /dev/stdin

Victory?! :tada:

Well, embedding the file name in LESSEDIT requires double care:

1. [ ] The characters %\?:. have special meaning in LESSEDIT and need to be escaped with \.
2. [ ] The result needs to be shell-quoted...

Maybe it's simpler to export another var with the file name, allowing fixed LESSEDIT:

bat --force-colorization README.md | env BAT_FILE="README.md" LESSEDIT='nano "$BAT_FILE"' less --force /dev/stdin

And also bat won't have to hard-code nano, can tell less to honor $EDITOR/$VISUAL, and also pass +NNN line number when known, similar to default value of LESSEDIT:

bat --force-colorization README.md | env BAT_FILE="README.md" LESSEDIT='%E ?lm+%lm. "$BAT_FILE"' less --force /dev/stdin

• [ ] Additionally, I'm not certain whether /dev/stdin is 100% portable across unixes. Or is /dev/fd/0 better?

---

Another round-about way that kinda works:

env LESSOPEN="|bat --force-colorization %s" less README.md

here less is aware that it's viewing a file, it's just being pre-processed. Alas, less asks to confirm every time:

WARNING: This file was viewed via LESSOPEN (press RETURN)

but if you do, it opens your editor. But it is awkward to have less launch bat; if we want current architecture outer bat already has the file(s) colorized, just want to pass the results unmodified. Could spill it to a temp file LESSOPEN="cat /tmp/..."? Anyway less fun with the need to confirm.

---

It's unclear how bat FILE1 FILE2 FILE3 should work with pressing v??

In the LESSOPEN mode, if you give less multiple file, less shows one at a time (you have to press :n / :p to go to next/previous one), and then it has clear picture of which is "current file". But I do much prefer bat's approach of concatenating all files with name headers.