bug#13546: 24.2.92; Error(s) when sending emails

[Eli Zaretskii <eliz@gnu.org>]

> From: "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com>
> Cc: Thierry Volpiatto <thierry.volpiatto@gmail.com>,  13546@debbugs.gnu.org
> Date: Fri, 15 Feb 2013 11:37:04 +0100
> 
> > Btw, I'm surprised that helm starts an async subprocess, just to kill
> > it after its output was collected.  Isn't this exactly what
> > synchronous subprocesses are for?  What is the purpose of such a
> > strange design? (except if you wanted to help find bugs in Emacs when
> > async subprocesses are launched and killed at high frequency ;-)
> 
> IIUC, I guess the reason is not to block the user during typing: the fact that
> Helm's locate is still collecting results does not hinder to type an extra
> character to refined the search.

That consideration doesn't apply in this case, AFAIU, for 2 reeasons:

  . 'locate' must be (and is) reasonably fast for this feature to be
    liked by users.  Otherwise, the results you see will lag behind
    input, i.e. they will lie to you.  In your screencasts one can
    clearly see that you type a character and wait for the result to
    appear before you type the next one, which is what I'd expect, so
    a synchronous subprocess that does its job quickly will fit this
    very well.

  . Typing at a very fast rate will prevent Emacs from reading output
    from 'locate', if it is run asynchronously, so you will see no
    results at all in this case.  Not really useful, IMO.