vis_pipe*: take a Text object, vis-lua: add pipe_buffer

[git-bruh]

This adds a pipe_buffer helper to the lua api to allow piping arbritary buffers to an external command, as the current way of constructing a printf command is quite hacky and is prone to shell injection

As a workaround, I'd written a wrapper like this but it messes up the scroll position, so made this PR instead:

vis.pipe_buffer = function(vis, buffer, cmd, fullscreen)
	vis:command("open")
	vis.win.file:insert(0, buffer)

	local status, stdout, stderr = vis:pipe(vis.win.file, {start = 0, finish = vis.win.file.size}, cmd, fullscreen)

	vis.win:close(true)

	return status, stdout, stderr
end

[rnpnr]

I'm not sure about this one. Can you provide some real example of where printf is creating a problem?

(Ignore the failing macOS CI, github broke something.)

[git-bruh]

I'm not sure about this one. Can you provide some real example of where printf is creating a problem?

(Ignore the failing macOS CI, github broke something.)

In my case I had to display a list in the format of file:line: contents with a fuzzy search program, and it broke in certain cases as file contents can have embedded quotes as well that might not be terminated, so the constructed command could look something like this, causing the command to fail

printf '
./file1:0:line zero
./file1:1:'unterminated quote
'

[rnpnr]

Is there reason why you don't pipe the output of the fuzzy finder to the next stage in one go? Why do you need to save the intermediate output?

[git-bruh]

The contents I shared are generated by my lua code, I'm using it for displaying all the lines for the goto references in LSP. I get the file and line numbers from the LSP server, and then construct a buffer in lua that is piped to a fuzzy finder

[fischerling]

I wanted something like this too, but for different reasons.

Sometimes you do not have a window or a file to use vis:pipe with.

For example during the creation of the vis-lockfile plugin it would have been beneficial to be able to prompt for a user selection during a FILE_OPEN event (we solved it by subscribing to both FILE_OPEN and WIN_OPEN).
During the first FILE_OPEN event there does not exist a window or a file yet.

[rnpnr]

I'm OK with the idea but I'm not a fan of needing to go through at least 4 different dynamic allocations (text, piece, change, at least 1 in text_insert(), etc.) just to pass a string to a shell program. Maybe there is a better way?

[git-bruh]

Yeah we can definitely come up with more efficient ways of doing this, but for the PR just wanted to re-use as much of the existing code as possible