Thanks, Kevin. Kevin J. McCarthy <ke...@8t8.us> wrote on Sat, 15 Sep 2018 at 15:51:47 -0700 in <20180915225147.gb5...@afu.lan>:
> > I wonder if there's any appetite for reducing the default ... > I feel your pain, but 5 minutes is way below the RFC specified minimum. > I think likely the admins of the server dropped the timeout value to > reduce load. After extended conversations they claim not (however they also claim the timeout is 30 minutes, so clearly there are some issues), and of course, it's worth noting that over-aggressive timeouts can have the effect of increasing load, since they force [some] users to poll faster and restart connections. But anyhow, your position is reasonable and it's not watch the patch is about. (It would be nice to hear from other Exchange 2013 -or-newer mutt users who can state with confidence that they don't have these problems with the default imap_keepalive of 300 seconds aka 5 minutes.) > Peeking in the function myself, in the "normal" case where the mailcap > contains a '%s', Mutt calls mutt_system(), which would send keepalives. > However, if the mailcap entry is missing a '%s' filename specifier, I > see Mutt instead pipes the message on stdin uses the filter code. It seems to be slightly more than that, like if "use_pager" is true; but this code's logic is sufficiently complex that I might be misreading it. It seems ripe for refactoring, but that's probably a bad idea too. > The patch looks fine, but I wonder if we need to apply this hammer to > every filter. Filters are (supposed to be) short lived and produce > output back into Mutt for display; I think this may be the only case in > the code where we a using it to launch an external program for > interaction. It seems to me that while filters are supposed to be short-lived, they may not always be, and in the cases where they are short-lived, this won't make much difference. (Counterargument: messing with signals is dicey and should be avoided any more than is strictly necessary). > Perhaps it would be better to just adjust the "is_pipe" case for > mutt_view_attachment(). Please give me a few days to look into that > first. Err, the "use_pipe" case. I'm not sure how you'd go about doing that without putting low-level signal code around relatively high-level stuff in mutt_view_attachment, or complicating the abstraction further, but I have no objection if you can come up with something better. Certainly I'm not in any rush -- having suffered for the better part of a year and with a fix for the big problem in my config file and the small problem in my build tree, I'm happy to wait :) --jh...@mit.edu John Hawkinson
