Hi Branden,
> Doug wrote:
> > A diagnostic from gcc chimes in:
> > 'mktemp' is deprecated: the use of `mktemp' is dangerous; use `mkstemp'
...
> https://www.gnu.org/prep/standards/standards.html#Quote-Characters
My impression was Doug was passing on a warning about the continued used
of mktemp(3)
At 2019-02-10T15:35:24-0500, Doug McIlroy wrote:
> A diagnostic from gcc chimes in:
> 'mktemp' is deprecated: the use of `mktemp' is dangerous; use `mkstemp'
GNU is a big ship, but they're turning in the "right" direction (IMO)
and GCC simply hasn't gotten there yet (at least as of 8.2.0).
https:
A diagnostic from gcc chimes in:
'mktemp' is deprecated: the use of `mktemp' is dangerous; use `mkstemp'
Doug
On Friday, February 8, 2019 9:38 PM, Jeff Conrad wrote
> I discussed this with Doug Kerr, one of the authors (and the principal
> editor) of X3.4-1967. He assures me that accent grave was coded at
> 0x60; the intent was to provide the *option* to use 0x60 and 0x27 for
> opening and closing quotes
On Friday, February 8, 2019 6:18 AM, Ingo Schwarze wrote
> you seem to be reading too much into various sources,
Quite likely, but perhaps no more so than anyone else. My point was
simply that the distinction between “historical” and “modern” isn’t very
helpful. If indeed X3.4-1967 called for a
Hi Jeff,
you seem to be reading too much into various sources, but fortunately,
it only tangentially affects what matters to the proposed patch:
there can be little doubt that fonts more commonly show 0x60 as a
grave accent today, and likely also in the past, and that that
practice better matches
On Friday, February 8, 2019, Ingo Schwarze wrote
> > I think "historic" is pretty context dependent. As nearly as I can
> > tell, ASA/ANSI X3.4 has called for 0x60 to encode "accent grave".
>
> Absolutely not:
>
> http://worldpowersystems.com/ARCHIVE/codes/X3.4-1963/page5.JPG
>
> In that sta
Hi Jeff,
Jeff Conrad wrote on Fri, Feb 08, 2019 at 04:25:51AM +:
> On Wednesday, February 6, 2019 6:39 AM, Ingo Schwarze wrote
>> BENEFITS:
>> -
>> - stop relying on a historic meaning of ASCII 0c60
>>that was never portable and that conflicts with Unicode
> I think "historic" i
On Saturday, February 2, 2019 8:58 AM, Ingo Schwarze wrote
> > I think you're incorrect there. Using ` ' as input
> > has always been a correct way to get single left and right quotes;
> > see CSTR 54 2.1.
>
> You seem to be right about that. In modern roff implementations,
> that appears to be
Hi,
Doug McIlroy wrote on Mon, Feb 04, 2019 at 07:33:05PM -0500:
> Ingo has recorded me as being opposed to rendering \(oq and \(cq
> the same in -T ascii.
>
> I had raised the issue of ` in m4 and shell scripts. However, it
> is good practice to make examples by pasting in working code,
> which
Ingo has recorded me as being opposed to rendering \(oq and \(cq
the same in -T ascii.
I had raised the issue of ` in m4 and shell scripts. However, it
is good practice to make examples by pasting in working code,
which can in turn be cut, especially from nroff-ed documents.
The rendering of \(oq
Hi Mike,
Mike Bianchi wrote on Sat, Feb 02, 2019 at 09:53:43AM -0500:
> ... build a generalize tool where the choice of font or device implies
> a set of desirable (to me) character substitutions and renderings that
> can easily be changed via a personalized configuration file. Say
>.groffto
> "Stamp out US-specific, internationally non-portable usage of ASCII
> that is incompatible with Unicode, ..."
> Is that something we can agree on?
I don't agree because it cannot be done. Documentation, still valuable today,
was written with "US-specific, internationally non-portable usage o
> ... that doesn't look like a consensus yet, and unfortunately,
> i don't see how to argue further, ...
> :
> Any ideas how to resolve this clash of priorities?
Rephrasing what I said before:
... build a generalize tool where the choice of font or device implies
a set of des
14 matches
Mail list logo
