[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `message' not outputting the newline "atomically"
From: |
Daniele Nicolodi |
Subject: |
Re: `message' not outputting the newline "atomically" |
Date: |
Sun, 30 Jun 2019 22:11:48 +0200 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 |
On 26/06/2019 20:34, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden
>> From: Daniele Nicolodi <address@hidden>
>> Date: Wed, 26 Jun 2019 13:36:54 -0600
>>
>> Not that I care much about this, I feel that defending the use case of
>> debugging Emacs through printf() statements is rooted in believes akin
>> to religious ones, and religious arguments cannot be won with logic.
>
> It isn't religious at all. We have built-in debugging capabilities
> that use stderr, see the trace-redisplay feature as one example. This
> particular feature is very valuable for me, as it happens.
What I meant is that you have a strong believe that there may be cases
in which there is non zero probability that Emacs segfaults after
writing a string a sequence of characters to stderr that does not end in
a newline but at the same time contains crucial (or at least valuable)
information that will help diagnose the problem. I call this a
religious believe because (as far as I can tell) no example of such
occurrence has been provided and (in an unbounded system) logically
proving the non-existence of something is impossible (as the existence
of God in the universe, thus me calling this a religious believe). Of
course the Emacs' codebase is bounded, however an exhaustive list of the
supported platforms does not exist, making the possibilities practically
unbounded. I thus think it is on you to provide a plausible eou xample.
>> Why is re-implementing line buffering in Emacs any better than using
>> libc line buffering?
>
> Because we can apply that on a per-case basis, whereas setvbuf is
> global and irreversible.
Just add an fflush() after the write()s you care about...
>> Are you proposing that we selectively apply buffering in some occasions
>> but not others?
>
> YES!
>
>> However, if that is the route you are suggesting, it is much easier to
>> enable line buffering unconditionally ad place fflush() calls where it
>> matters, than the other way around.
>
> You are suggesting fflush after every character written? That's
> impractical, and we usually use something other than fputc to output
> the messages.
I suggest an fflush() after every message that does not terminate in a
newline and that must absolutely end in the terminal if Emacs crashes,
if any exists (see above).
Cheers,
Dan
- Re: `message' not outputting the newline "atomically", (continued)
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/26
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/26
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/26
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/26
- Re: `message' not outputting the newline "atomically", Daniele Nicolodi, 2019/06/26
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/26
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/27
- Re: `message' not outputting the newline "atomically",
Daniele Nicolodi <=
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/06/26
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/25
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/26
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/26
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/27
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/27
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/06/28
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/06/25