[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
`message' not outputting the newline "atomically"
From: |
Paul Eggert |
Subject: |
`message' not outputting the newline "atomically" |
Date: |
Sat, 13 Jul 2019 17:42:45 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 |
Eli Zaretskii wrote:
Because we now have a simpler solution.
I don't think it's simpler: it causes 'message' write to a different
file descriptor, and thus introduces a backward incompatibility.
I meant simpler to implement and easier to maintain. My email discussed the
backward compatbility issue, which is negligible.
Emacs uses stdout reasonably extensively for this sort of thing already; see
'write_stdout' and I can cite several other examples.
write_stdout is used in exactly 10 places, which I wouldn't call "extensive".
As I mentioned, write_stdout isn't the only place stdout is used for this sort
of thing. Another example is w32con_write_glyphs. I'm not saying stdout is used
as often as stderr; however, stdout is used in a reasonably large set of places,
and nobody cares. In this sense, Emacs differs from typical Unix-like utilities.
It is used where AFAIU any other file descriptor would
be problematic.
In the places where write_stdout is used, stderr is no more problematic than
stdout is. Neither is guaranteed to be displayed to the user.
I don't understand how could you make these assertions. What are they
based on?
You're asking me to prove a negative? OK, I concede; I can't do that. However,
my statements were based on experience in using Emacs and in reading its source
code and bug reports and complaints about it.
So I think your previous proposal for message_to_stderr and vmessage
should be okay to go in. But not the rest, sorry.
OK, I put that proposal into master (with some minor improvements). Also, I
installed the attached patches to fix the most-annoying remaining stderr
interleaving problems without changing stderr buffering. This should be enough
to address the interleaving problems on GNU/Linux, in areas where the OS lets us
address them.
Unfortunately, GNU Emacs master still suffers from interleaving problems on
Solaris, AIX, and perhaps some other POSIXish platforms, because their fprintf
implementations write "%s"-formatted strings separately. Although it's easy to
fix that, no fix is likely to meet your standards.
0001-Avoid-interleaving-stderr-in-dump_fingerprint.patch
Description: Text Data
0001-Avoid-interleaving-stderr-lines-when-shutting-down.patch
Description: Text Data
- Re: `message' not outputting the newline "atomically", (continued)
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/07/08
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/07/09
- Re: `message' not outputting the newline "atomically", Paul Eggert, 2019/07/09
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/07/09
- Re: `message' not outputting the newline "atomically", Lars Ingebrigtsen, 2019/07/09
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/07/09
- `message' not outputting the newline "atomically",
Paul Eggert <=
- Re: `message' not outputting the newline "atomically", Eli Zaretskii, 2019/07/14