Provide a mechanism to perform the equivalent of ":read"'s ++edit flag

[jamessan]

Currently in the vim-gnupg plugin, I use a BufReadCmd to read output from gpg and populate the buffer. This BufReadCmd uses :r ++edit !gpg ... so the fileformat and encoding detection takes place.

I'm looking to change this to instead use a job so I can independently read stdout/stderr, which is required to deal with certain bugs in the plugin. However, manually populating the buffer with the job's output means I can't leverage the ++edit functionality.

In the specific case of BufReadCmd, it may make sense to automatically perform this detection after BufReadCmd executes (assuming other ++ options weren't included in the :e command). If that's not feasible, it would be useful if there were a way to manually execute this detection.

[brammool]

Currently in the vim-gnupg plugin, I use a `BufReadCmd` to read output from gpg and populate the buffer. This `BufReadCmd` uses `:r ++edit !gpg ...` so the fileformat and encoding detection takes place. I'm looking to change this to instead use a job so I can independently read stdout/stderr, which is required to deal with certain bugs in the plugin. However, manually populating the buffer with the job's output means I can't leverage the `++edit` functionality. In the specific case of `BufReadCmd`, it may make sense to automatically perform this detection after `BufReadCmd` executes (assuming other `++` options weren't included in the `:e` command). If that's not feasible, it would be useful if there were a way to manually execute this detection.

There is the read_buffer() function, which might be used for this. This is also done when reading stdin. The comment there says: // First read the text in binary mode into the buffer. // Then read from that same buffer and append at the end. This makes // it possible to retry when 'fileformat' or 'fileencoding' was // guessed wrong. It appears to have the same goal, thus should already be very close to what you want. After your job has filled the buffer, I suppose a function could be called to do the detection. Not sure what to call it, bufdetect() ? We would need to define exactly what happens. Perhaps we also only want to detect a specific option, such as 'fileformat', and not change others.

…

-- hundred-and-one symptoms of being an internet addict: 94. Now admit it... How many of you have made "modem noises" into the phone just to see if it was possible? :-) /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[jamessan]

It appears to have the same goal, thus should already be very close to what you want.

Thanks, I'll try to find some time to prototype this.

After your job has filled the buffer, I suppose a function could be called to do the detection. Not sure what to call it, bufdetect() ?

That's as good as anything came to mind for me. As long as it's cross-referenced from BufReadCmd's documentation, I think it'll be found when needed.

We would need to define exactly what happens. Perhaps we also only want to detect a specific option, such as 'fileformat', and not change others.

Agreed. My use case is only for setting up 'fileformat' and 'fileencoding' properly, but I think that aligns with what's typically required for BufReadCmd based plugins.