Hi Branden! On Sat, Jun 15, 2024 at 08:31:31PM GMT, Alejandro Colomar wrote: > Link: <https://lore.kernel.org/linux-man/20240611122453.qn6jyl4go4bvwkqm@illithid/> > Suggested-by: "G. Branden Robinson" <branden@xxxxxxxxxx> > Signed-off-by: Alejandro Colomar <alx@xxxxxxxxxx> > --- > Range-diff against v0: > -: --------- > 1: 1fc1669e9 man/: Use \[rs] instead of \e > [...] > man/man7/man-pages.7 | 18 +-- [...] > 284 files changed, 1173 insertions(+), 1173 deletions(-) > [...] > diff --git a/man/man7/man-pages.7 b/man/man7/man-pages.7 > index 007b9e7a2..dc117662f 100644 > --- a/man/man7/man-pages.7 > +++ b/man/man7/man-pages.7 The cases in man-pages(7) are a bit special, since they are mostly examples of man(7) source code. Would you recommend using \e or \[rs] there? Thanks, and have a lovely day! Alex > @@ -184,7 +184,7 @@ .SS Sections within a manual page > for important details of the line(s) that should follow the > \fB.SH NAME\fP command. > All words in this line (including the word immediately > -following the "\e\-") should be in lowercase, > +following the "\[rs]\-") should be in lowercase, > except where English or technical terminological convention > dictates otherwise. > .TP > @@ -464,7 +464,7 @@ .SS Sections within a manual page > (don't hyphenate) > directives. > Hyphenation of individual page names can be prevented > -by preceding words with the string "\e%". > +by preceding words with the string "\[rs]%". > .IP > Given the distributed, autonomous nature of FOSS projects > and their documentation, it is sometimes necessary\[em]and in many cases > @@ -611,7 +611,7 @@ .SS Formatting conventions for manual pages describing functions > .BR fcntl () > .EE > .P > -(Using this format, rather than the use of "\efB...\efP()" > +(Using this format, rather than the use of "\[rs]fB...\[rs]fP()" > makes it easier to write tools that parse man page source files.) > .\" > .SS Use semantic newlines > @@ -669,7 +669,7 @@ .SS Lists > .TP > Bullet lists > Elements are preceded by bullet symbols > -.RB ( \e[bu] ). > +.RB ( \[rs][bu] ). > Anything that doesn't fit elsewhere is > usually covered by this type of list. > .TP > @@ -958,7 +958,7 @@ .SS NULL, NUL, null pointer, and null byte > is the > .IR "null byte" , > a byte with the value 0, represented in C via the character constant > -.IR \[aq]\e0\[aq] . > +.IR \[aq]\[rs]0\[aq] . > .P > The preferred term for the pointer is "null pointer" or simply "NULL"; > avoid writing "NULL pointer". > @@ -998,7 +998,7 @@ .SS Use of e.g., i.e., etc., a.k.a., and similar > In addition, "e.g." and "i.e." should always be followed by a comma. > .SS Em-dashes > The way to write an em-dash\[em]the glyph that appears > -at either end of this subphrase\[em]in *roff is with the macro "\e[em]". > +at either end of this subphrase\[em]in *roff is with the macro "\[rs][em]". > (On an ASCII terminal, an em-dash typically renders as two hyphens, > but in other typographical contexts it renders as a long dash.) > Em-dashes should be written > @@ -1073,7 +1073,7 @@ .SS Generating optimal glyphs > .P > .in +4n > .EX > -\e\- > +\[rs]\- > .EE > .in > .P > @@ -1090,11 +1090,11 @@ .SS Generating optimal glyphs > produce real minus signs when pasted into a terminal. > .P > To produce unslanted single quotes that render well in ASCII, UTF-8, and PDF, > -use "\e[aq]" ("apostrophe quote"); for example > +use "\[rs][aq]" ("apostrophe quote"); for example > .P > .in +4n > .EX > -\e[aq]C\e[aq] > +\[rs][aq]C\[rs][aq] > .EE > .in > .P -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
