Feature Request? Pipe buffer into other program

[chubin]

I am not sure, if this feature is not supported already, but I didn't manage to find it.

In less, it is possible to pipe the current buffer into external program:

       | <m> shell-command
              <m> represents any mark letter.  Pipes a section of the input file to the given shell command.  The section of the file to be piped is between the position marked by the letter and the current screen.  The entire
              current screen is included, regardless of whether the marked position is before or after the current screen.  <m> may also be ^ or $ to indicate beginning or end of file respectively.  If <m> is . or newline, the
              current screen is piped.

What is missing in less though, is support of macros and key combination definition,
so it is not possible to define some key that would always pipe the current buffer
into a certain program.

ov is much more powerful though, and allows to define the key combinations easily.

Unfortunately, it can't pipe the buffer into external programs though
(at least I didn't find how to do it).

Would it be possible to add this feature?

Use cases:

• "Send" fragments of logs and files to external "processors" that would to something with them

[noborus]

Thank you for the issue.
As you say, there is no equivalent function in OV.
Therefore it is suitable for a feature request.

However, I don't think it will be implemented as is just because it is in "less".
I need to consider why I need it.

[chubin]

The main idea behind this feature is to pass control to other programs and
provide them with additional information about the context.

For example, let's consider the following use case:

There is a log file that contains numerous irrelevant messages. However, hidden
within the middle of the file, there is a relevant text. This situation is
quite typical for logs.

The user locates the correct place in the log where the problem occurs, and
then they want to take action with it, such as sending it as a message or piping
it to another program.

Currently, it is not very simple. One can use a mouse or save the fragment to a
file, but these methods are both inconvenient and suboptimal, particularly if
they need to be repeated multiple times for multiple fragments.

This feature is rather trivial, but it can be very helpful.

Do you accept pull requests?

If you find the feature interesting and potentially useful for the project,
I could attempt to implement it

[noborus]

Thank you for your explanation.
This seems like an interesting feature.
Pull requests are always welcome, but you may have different ideas about the interface.
I haven't decided yet how to select the range and run the command.

[chubin]

Range selection is maybe even not needed at the beginning. It will pass the current buffer to the pipe (as less does),
but how to show the pipe output is a good question. less does it pretty ugly. Ideally, it should also support programs with terminal interface (like fzf, for example). It would allow us to build fzf -> ov -> fzf chains, where the user could descend into some complex structure (that is more or less what I currently do with less, but as I wrote before, less has the substantial drawback, that it does not allow to bind commands to keys; and many other drawbacks too).

[noborus]

Range selection is maybe even not needed at the beginning.

Sounds good.
In that case, I think you can proceed with an implementation that simply executes it with a pipe using "| command".