pipeto should build on alot.commands.globals.ExternalCommand

[zenhack]

@pazz mentioned this in the comments for issue #684; the PipeCommand class is duplicating a lot of work handled by ExternalCommand, and apparently this is to blame for some input handling issues.

[bbenne10]

Has there been progress made on this (or #703)? I'm running headlong into this problem, as I use a script to parse Outlook invitations into remind format and then open $EDITOR on my remind file. If there's progress, I won't investigate. If there is - I'll be happy to look into solving the issue (though I make no guarantees on quality or timeline :P)

[pazz]

if there was progress it'd be documented here.. so knock yourself out :)
Personally, I use python hooks for these things, so that's why this issue has a low priority for me.
But if anyone knows how to clean up the current mess, I'd be happy to push a fix.

[bbenne10]

I certainly don't yet know how to fix the mess, but I'll see what I can find. I'm interested in your workflow for stuff like this, as I'm quite new to both notmuch and alot. Is your workflow documented somewhere? If not, would it be possible for you to document how you are (or would recommend) doing some more "advanced" stuff like this?

[pazz]

If by "workflow" you mean how I would implement something like your remind-feature in my personal config, I can point you to the wiki entry on contributed hooks.
See in particular the hook i use to mark github notifications as read.
But this is just me. I know that many users will want to just pipe to some shell command, and this option really should work as expected.

[bbenne10]

I'll read that over to see if it provides the sort of functionality I need to patch this in the short term. I've just pulled up alot/commands/{globals,thread}.py while I finish my coffee, so hopefully I'll be a bit more use in the near future. Thanks for the help :)

[bbenne10]

So I think there's a relatively trivial way to apply this fix. Rather than inheriting from ExternalCommand, as there are some signficant differences in interface, we could simply instantiate ExternalCommand and call apply() on it once for each member in pipestrings (see line ~668 or so). The instantiation would either need to hardcode values (or accept defaults) for ExternalCommands spawn and refocus kwargs, or we could modify the interface of PipeCommand to take those arguments explicitly. This approach allows us to keep most of :pipetos behavior in place at the expense of flexibility.

We could also refactor PipeCommand to do essentially what ExternalCommand does, but use the thread messages contents rather than the passed in stdin. This would predicate changing the interface of :pipeto to look a bit more like :shellescape. I'm not sure which should be favored: maintaining consistent interfaces, or flexibility. I wanted to ensure I was going about it the "right" way before I started down either road.