[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: Re: `message' not outputting the newline "atomically"
Date: Thu, 27 Jun 2019 05:34:25 +0300

> 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.

> > Can't we also fix that by replacing the above with 'sprintf' followed
> > by 'write'?
> 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.

> For your main argument in the thread, we would be loosing crucial
> debug information if something goes irreparably wrong between the
> string preparation and the write().  And given how error-prone is
> string manipulation in C, there are much higher chances that this
> will happen if we start doing that for every function that want to
> print something on stderr.

My main argument is actually that the issue this thread is trying to
fix is minor, even insignificant.  But given that some people pressure
to find a solution, I propose various compromises.  As any compromise,
they are somewhat ugly.  My personal preference would be to leave
things as they are.

> Any solution requires buffering of the output till the first newline.
> And you are opposed to buffering.

I'm opposed to buffering stderr globally, yes.  But I can agree to
that in specific cases.  The problem is, setvbuf doesn't allow
selective buffering.

> Are you proposing that we selectively apply buffering in some occasions
> but not others?


> 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.

reply via email to

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