[Apologies Eli, re-sending to list rather than just you.]
On Tue, 3 Nov 2020 at 16:45, Eli Zaretskii <email@example.com
I'm okay with the first 2,
Great, I'll install those!
but I'm less comfortable with the 3rd one.
It is wrong to assume that nothing but warnings come through stderr:
for example "hunspell -D" emits the important information to stderr,
at least on my system.
I found this while testing a more ambitious patch that never collected
stderr (and indeed versions of Enchant until last night's release of
2.2.13 printed their --version output on stderr).
Hence, all of those uses still collect stderr.
It could be that we don't currently use the 2
functions you suggest to change for such cases, but I think ignoring
stderr in some calls and not the others is a slippery slope of
confusion and subtle bugs.
two functions I changed implement a long-running communication with the
spellchecker using the ispell protocol, notionally over a pipe. There's
no reason to mix two streams, and in any case that would only work
fortuitously, since the spellchecker doesn't know how those streams will
be combined. In other words, a source of confusion and subtle bugs.
Fortunately, none of the current spellcheckers we support tries to do this.
Since the important case -- that of
enchanty-lsmod -- is already solved, why do we need to make changes
that are not really required, and currently don't give us any gains?
as I mentioned before, it's not completely solved, as the "enchant"
program outputs warnings on stderr, just like enchant-lsmod. This is
interpreted by Emacs as additions to the suggestions or corrections
list, which is clearly wrong.