Re: [PATCH 1/4] ptsname_r: new module

Paul Eggert wrote: > From my point of view, we shouldn't design manuals that are hard to > read under Emacs. The default choice of the "face" 'nobreak-space' is apparently intentional. In my opinion it makes sense for editable buffers, but is not the right thing for presentation modes (like Info-m

Re: [PATCH 1/4] ptsname_r: new module

Jim Meyering wrote: > They tend to cause confusion (at least with me) > because they look like a space in many contexts, yet when you search > for the explicit space, you will not find those as matches. Good point, yes. Things like that can drive people crazy. Bruno -- In memoriam Cornstalk

Re: [PATCH 1/4] ptsname_r: new module

Bruno Haible wrote: > Hi Jim, all, > >> >> I suggest using @tie{} between os (or program or ...) names and >> >> versions. That way the line breaks come out ok in both the source and >> >> the output. >> > >> > Indeed, the result looks better (at least in HTML). I tested >> ... >> I find that the

Re: [PATCH 1/4] ptsname_r: new module

Hi Bruno, As I said, an *extremely* minor pedantic nit, so please take with a large grain of salt (or three). I'm raising two technical points here: 1. There is a space between Mac and OS (and another space between OS and X). 2. The X in "Mac OS X" already says 10, so it's redundant when you

Re: [PATCH 1/4] ptsname_r: new module

Just today, before I read this exchange, I was running 'info' in an ASCII environment (LC_ALL='C' on Fedora 15). And just before *that*, I was reading documentation under Emacs info mode (my normal way of reading documentation). As a developer, I rarely read Emacs manuals using HTML, or using PDF,

Re: [PATCH 1/4] ptsname_r: new module

- .info output when viewed by the 'info' program in a UTF-8 locale. Just for the record, Emacs Info is a much more important/widespread reader than standalone Info. Personally, I find using any non-7-bit ASCII character when not absolutely necessary is simply a pain agent. But I don't expe

Re: [PATCH 1/4] ptsname_r: new module

Hi Jim, all, > >> I suggest using @tie{} between os (or program or ...) names and > >> versions. That way the line breaks come out ok in both the source and > >> the output. > > > > Indeed, the result looks better (at least in HTML). I tested > ... > I find that the mark-up renders the texi less

Re: [PATCH 1/4] ptsname_r: new module

As for things like AIX@notie{}5.1 I don't understand the "no". just to prevent paragraph fill from breaking things It's not primarily about paragraph fill; that's a side benefit. The primary purpose is to get good line breaks in the output (and the source), without having to think

Re: [PATCH 1/4] ptsname_r: new module

On 11/08/2011 04:01 AM, Bruno Haible wrote: Hi Eric, This patch looks fine. +@item +This function is missing on some platforms: +MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX +5.1, HP-UX 11, IRIX 6.5, Solaris 11 2010-11, Cygwin 1.7.9, mingw, MSVC 9, BeOS. @end itemize

Re: [PATCH 1/4] ptsname_r: new module

Gary V. Vaughan wrote: > Although it is common to see, e.g. Mac OS X 10.5 in writing, it's > redundant and technically incorrect. Possibly. But when discussing gnulib, I want to never evoke the impression that gnulib could support MacOS 9 or earlier. > or use the cat name > >Mac OS X Leopard

Re: [PATCH 1/4] ptsname_r: new module

Bruno Haible wrote: > Hi Karl, all, > >> > +MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX >> >> Could you please break the line after a comma? >> >> I suggest using @tie{} between os (or program or ...) names and >> versions. That way the line breaks come out ok in

Re: [PATCH 1/4] ptsname_r: new module

A minor nit: On 9 Nov 2011, at 05:25, Karl Berry wrote: >> +MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX >> +5.1, HP-UX 11, IRIX 6.5, Solaris 11 2010-11, Cygwin 1.7.9, mingw, MSVC 9, >> BeOS. >> @end itemize > >Could you please break the line after a comma? > > [sni

Re: [PATCH 1/4] ptsname_r: new module

But it reduces the readability of the .texi file, True, but it's one of those things you have to do to get correct output. Basically I was explaining to Eric that he should not use M-x fill-paragraph I know. And I was explaining that trying to make a convention "don't use fill-paragrap

Re: [PATCH 1/4] ptsname_r: new module

Hi Karl, all, > > +MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX > > Could you please break the line after a comma? > > I suggest using @tie{} between os (or program or ...) names and > versions. That way the line breaks come out ok in both the source and > the o

Re: [PATCH 1/4] ptsname_r: new module

> +MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX > +5.1, HP-UX 11, IRIX 6.5, Solaris 11 2010-11, Cygwin 1.7.9, mingw, MSVC 9, BeOS. > @end itemize Could you please break the line after a comma? I suggest using @tie{} between os (or program or ...) names a

Re: [PATCH 1/4] ptsname_r: new module

Hi Eric, This patch looks fine. > +@item > +This function is missing on some platforms: > +MacOS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX > +5.1, HP-UX 11, IRIX 6.5, Solaris 11 2010-11, Cygwin 1.7.9, mingw, MSVC 9, > BeOS. > @end itemize Could you please break the line af

[PATCH 1/4] ptsname_r: new module

For now, this replacement focuses solely on compilation compatibility, and assumes that isatty() and ttyname_r() work on a master side pty; if this assumption fails, or if thread-safety is also required, then a later patch can follow the lead of strerror_r.c in wrapping the system ptsname() with a