On 3/31/20, Ralph Corderoy wrote:
> Doug's idea of \s314 being 314, not 31, is better, but the effect can
> already be achieved with groff's existing extension of (xx to [yyy...]
True, the functionality is already there. But the principle of least
astonishment argues that the bare numbers 39 and
Hi Dave,
> [Treating \s65 as point-size 65] would break historical documents that
> use such constructions -- but they're poor style anyway: anyone
> writing with an eye to clarity would already have said "\s[6]5 golden
> rings"
That one's not valid syntax in a historical document.
> or "\s6\&5
Hi Doug,
Doug McIlroy wrote on Mon, Mar 30, 2020 at 10:53:23PM -0400:
> Thanks for spotting the facts in info, a jungle I rarely
> enter. Especially for groff, for which groff(7) is quite a
> comprehensive reference.
>
> The difference between \s39 and \s40 is a documented living
> fossil!
>
>
> What do folks think?
I would add that where \s[nnn] is legal it would be the preferred syntax.
It is what I use all the time, even for \s[9] . Unambiguous.
Witness in groff:
.sp 8
.ps 8
\ .ps 8 \s10 10 \s40 40 \s(20 20 \s[40] 40 \s[120] 120
attachment
On Tue, Mar 31, 2020 at 09:57:08AM +0100, Ralph Corderoy wrote:
> :
> The point of being able to format historical documents is that they can
> be formatted without examination and editing to fix what today might be
> considered bad style.
In an ideal world, preserved historical documents wo
On 3/31/20, Ingo Schwarze wrote:
> There is value in compatibility with historical documents, in
> particular where the consequences of changing behaviour would be
> as ugly as for historical code similar to "\s99 nroff\s0".
> Then again, there is also value in avoiding surprising parser
> rules,
Hi Mike,
> In an ideal world, preserved historical documents would be generated
> from preserved historical source processed by preserved historical
> processing programs running on preserved historical systems.
But not many of us have a C/A/T so we prefer a modern system to process
old formats.
> [...] at the expense of obvious clarity to anyone writing
> content today [...]
If you want clarity, choose the modern syntax: \s[40].
(By the way, groff also allows \s'40'.)
The old syntax will always be inconsistent or ambiguous, unless
you are willing to give up on the \s0 shortcut for ret
I've been writing the ugly \s360 since ancient times. Groff still thinks
this means a 36-point 0. But man 7 groff says it means a 3-point 60:
\s±N Set/increase/decrease the point size to/by N scaled points; N is
a one-digit number in the range 1 to 9. Same as ps request.
B
On 3/31/20, Tadziu Hoffmann wrote:
> If you want clarity, choose the modern syntax: \s[40].
> (By the way, groff also allows \s'40'.)
Yes, that's my first point: anyone interested in writing clear source
should already be doing this.
My second point is about the language design. To users writin
> Also bump copyright year; significant* non-cosmetic changes to
> this file were made in 2019 and this year. (I know that a
> script can be directed to come around and bump the copyright
> year on this file even if, say, only whitespace changes were
> made, or no changes at
Hi Werner!
At 2020-03-31T17:41:47+0200, Werner LEMBERG wrote:
> This is not the point of view taken by the FSF. To cite from
>
> https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices
>
> (emphasis added by me).
>
> To update the list of year numbers, add each year in which yo
It was shockingly easy to implement my proposal of de-compatifying the
special logic that historical troff used to support two digits in the
single-digit form of the point-size escape.
But not so surprising in hindsight. When you're heaping conditionals
this high in your recursive-descent parser,
Hi Branden,
> Support 2-digit \sNN only in compatibility mode.
No, again.
This is not acceptable. My muscles know to write \s14foo\s0 bar and
don't like changing, my eyes know how to read it. I don't see why you
should force this side issue on us when the topic is whether \s42foo\s0
sets the p
On Tue, Mar 31, 2020 at 06:17:52PM +0100, Ralph Corderoy wrote:
> Hi Branden,
>
> > Support 2-digit \sNN only in compatibility mode.
>
> No, again.
>
> This is not acceptable. My muscles know to write \s14foo\s0 bar and
> don't like changing, my eyes know how to read it. I don't see why you
>
At 2020-03-31T18:17:52+0100, Ralph Corderoy wrote:
> This is not acceptable. My muscles know to write \s14foo\s0 bar and
> don't like changing, my eyes know how to read it.
What text editor do you use?
> I don't see why you should force this side issue on us when the topic
> is whether \s42foo\s
Doug McIlroy wrote:
>
> I've been writing the ugly \s360 since ancient times. Groff still thinks
> this means a 36-point 0. But man 7 groff says it means a 3-point 60:
>
> \s±N Set/increase/decrease the point size to/by N scaled points; N is
> a one-digit number in the range
Hi groffies!
I reading the manual again.
There is something I don't understand.
I read in the manual, at chap. 2.6:
"groff file
This command processes file without a macro package or a preprocessor.
The output device is the default, ‘ps’, and the output is sent to
stdout."
I tried this with a s
On Wed, 1 Apr 2020, Gr?goire Babey wrote:
I tried this with a simple file named aa, containing only two
characters. "aa". If I type:
groff aa
I should find at some place a file named aa.ps.
That is incorrect - 'groff' send its output to standard output.
You need to type
groff aa >
Salut Gregoire,
Gregoire Babey wrote on Wed, Apr 01, 2020 at 03:55:24AM +0200:
> I reading the manual again.
> There is something I don't understand.
> I read in the manual, at chap. 2.6:
>
> "groff file
>
> This command processes file without a macro package or a preprocessor.
> The output dev
20 matches
Mail list logo
