[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `message' not outputting the newline "atomically"

From: Paul Eggert
Subject: Re: `message' not outputting the newline "atomically"
Date: Sun, 23 Jun 2019 10:32:48 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1

Eli Zaretskii wrote:

Bugs aren't hypotheses, they actually happen.

I've looked carefully for any of the bugs hypothesized so far, and haven't found any. That's not to say they don't exist, but these mythical creatures are so rare that in practice it's fair to assert that they are less important than the practical bugs that this patch fixed.

If we could use hypothetical bugs as part of the argument, I could easily hypothesize bugs where unbuffered stderr produces less-useful output than line-buffered stderr does. But that would be going down a rabbit hole. We should focus on bugs that actually occur rather than implausible bugs hypothesized for the sake of argument.

the primary purpose of stderr is to produce diagnostic
error messages

And if these diagnostics are confusing or unintelligible, as with unbuffered stderr, this purpose is not being fulfilled.

That use case could have a more specialized solution

Sure: we could take every bit of Emacs code that produces piecemeal stderr output, and rewrite it to generate the output into a temporary memory buffer and then output that buffer manually. For example, we could install something like the attached patch to address the dump_fingerprint issue. But this sort of change would be counterproductive: it would complicate the code and it would not make diagnostic output any more reliable (on the contrary - just look at all those tricky buffer-size calculations). In contrast, using _IOLBF is a one-line fix that fixes the problem without introducing all this complexity and unreliability.

Attachment: handbuffer.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]