Show full output of command :hi
in scratch window:
:Redir hi
Show full output of command :!ls -al
in scratch window:
:Redir !ls -al
Evaluate current line with node
and show full output in scratch window:
" current line
console.log(Math.random());
" Ex command
:.Redir !node
" scratch window
0.03987581000754448
Evaluate visual selection + positional parameters with bash
and show full output in scratch window:
" content of buffer
echo ${1}
echo ${2}
" Ex command
:%Redir !bash -s foo bar
" scratch window
foo
bar
Well… of course
:read !foo
can be used to insert the output of external commandfoo
in the buffer, or:put=execute('hi')
to insert the output of Ex command:hi
. But that's, like… in the current buffer, and 10% of what this:Redir
does.:Redir !foo
is functionally similar to the following crude command:and
:Redir foo
is functionally "similar" to:which is already a bit more than
:read
.That is more or less what I did for years but it had a bunch of issues that I fixed gradually to obtain this command, which now fits my workflow perfectly. Those issues, in no particular order:
Whether you do
:read
or:0read
, you always end up with an extraneous empty line, which is something I don't like at all. My first attempt to fix that was to switch to:put
, which allowed me to usesystem()
or:redir
, which allowed me to add a third command that removed the extra line:Which worked, but it started to become quite a mouthful. That is the point where you start to consider turning it into a an Ex command. And of course, it couldn't be turned into a command as-is because, depending on whether the command was internal or external, I would have to decide whether to use
system()
or:redir
.Note that I wrote this command before
execute()
was introduced, but that wouldn't change much.:redir
is perfectly fine.Taking one path or another depending on the argument is not super hard, mind you, but solving that specific "extra line" issue, made the problem—and the solution—a little bit more complex than a "simple"
:read
or a "simple":put
.The resulting buffer lingered behind because it was a regular one. Since I intended it to be a "scratch buffer", I had to set a few options. Once again, that's not hard, but that's more complexity added to the mix. It makes the whole thing much cleaner, though, so the added complexity is very much worth it.
And that's one more step further away from a simple
:read
or:put
.In some cases,
:read
changes the alternate file, which is something I wanted to avoid in this scenario but not all the time. Another reason why suggesting a simple:read
as an alternative would be disingenuous at best.I didn't want the command to spawn more than one scratch window. Solving it was, again, relatively easy, but that's still more complexity than that mythical
:read
.I wanted my command to be usable as a filter, which, yet again, added more complexity because I needed to handle ranges.
Etc.
So no,
:read
and:put
don't make things easier at all.