> These changes may, must, shall, should be undone.
I'd like to think the message was postmarked April 1, but it wasn't.
> "and more recently, McIlroy referred to it as a ``living fossil''."
...
> "A living fossil" is a sign of a successful species (function).
> And now this species shall be "ca
On Wed, May 20, 2020 at 09:48:27PM +, Bjarni Ingi Gislason wrote:
[...]
Would you please consider the great merits of brevity, specifically of
not appending over a hundred lines of condescending quotations to your
emails? And I think the level of aggression on display here is well out
of orde
On Mon, Apr 06, 2020 at 06:17:12PM +1000, G. Branden Robinson wrote:
> It is done.
>
> https://lists.gnu.org/archive/html/groff-commit/2020-04/msg3.html
>
> Regards,
> Branden
These changes may, must, shall, should be undone.
They
a) cause a regression
b) misuse the compatibility mode
On Sat, 4 Apr 2020 18:49:11 -0700
Larry McVoy wrote:
> On Sat, Apr 04, 2020 at 06:42:37PM -0700, Larry McVoy wrote:
> > Could we please just converge on this spec? I'm old and tired but
> > if we can get agreement on this and noone wants to do the code I'll
> > take a swing at it.
>
> I co
On Sun, 5 Apr 2020, Robert Thorsby wrote:
While the cognoscenti continue to debate how many angels can stand on the
head of a pin I am prepared to regard Larry & Doug as definitive.
I have been using *roff pre-ditroff so slightly longer than old Larry, but
not as long as young Doug, and I con
On Sat, Apr 04, 2020 at 06:42:37PM -0700, Larry McVoy wrote:
> Subject: [d...@cs.dartmouth.edu: Re: weird \s]
>
> ...
> Anyone arguing for \sDD is just misguided. If you want two things
> it is \s(12, if you want N things, groff gave you \s[1234].
>
> Could we please
On 05/04/20 11:42:37, Larry McVoy wrote:
Doug and I talked about this off line. Doug predates all versions of
roff, he watched it being developed and used it. I think his opinion
matters.
In the message below the "Am I wrong wanting" and the specs are me,
his response is below that.
An
On Sat, Apr 04, 2020 at 06:42:37PM -0700, Larry McVoy wrote:
> Could we please just converge on this spec? I'm old and tired but
> if we can get agreement on this and noone wants to do the code I'll
> take a swing at it.
I could probably be talked into trying to convert the texinfo docs
into roff
-
Date: Fri, 03 Apr 2020 18:36:39 -0400
From: Doug McIlroy
To: l...@mcvoy.com
Subject: Re: weird \s
Am I wrong in wanting
\sDwhatever - set size to D and print whatever
\s(DDwhatever - set size to DD and print whatever
\s[DD]whatever - set size to DD and prin
I agree with Tadziu. Along with .cc and .c2, the .ec request opens up a
world of creative (ab)uses that reward clever thinking.
On Sat, 4 Apr 2020 at 03:25, Tadziu Hoffmann
wrote:
>
> > In that light, inventing .ec was a terrible language design
> > mistake that should never have been permitted.
> In that light, inventing .ec was a terrible language design
> mistake that should never have been permitted. It was also
> absolutely useless, which i have proven by implementing logic
> in the mandoc pre-parser that eliminates .ec before even
> starting the main parse sequence. So all that c
Hi Branden,
G. Branden Robinson wrote on Sat, Apr 04, 2020 at 01:08:12AM +1100:
> I'm sorry to break with the consensus that's building around your
> post, but I don't find it part of it reasonably implementable.
Even though having a few postings expressing agreement certainly
looks like emergin
At 2020-04-02T23:58:01+, Bjarni Ingi Gislason wrote:
> This has been too much (long) chatter without simple solutions.
I'm sorry to break with the consensus that's building around your post,
but I don't find it part of it reasonably implementable.
> "Research is seeing the obvious." [1]
>
Amen.
I had a comment drafted and almost ready to go
when Bjarni made it unnecessary.
Doug
Date: Thu, 2 Apr 2020 19:11:35 -0700
From: Larry McVoy
Agreed.
On Thu, Apr 02, 2020 at 09:11:50PM -0400, Mike Bianchi wrote:
> Bjarni,
> Nice, tight analysis and proposed solutions. Thank you.
>
Agreed.
On Thu, Apr 02, 2020 at 09:11:50PM -0400, Mike Bianchi wrote:
> Bjarni,
> Nice, tight analysis and proposed solutions. Thank you.
> Mike Bianchi
>
> On Thu, Apr 02, 2020 at 11:58:01PM +, Bjarni Ingi Gislason wrote:
>
> sni
Bjarni,
Nice, tight analysis and proposed solutions. Thank you.
Mike Bianchi
On Thu, Apr 02, 2020 at 11:58:01PM +, Bjarni Ingi Gislason wrote:
snip
> 1) The missing part is information.
> Solution:
> a) Provide a mes
This has been too much (long) chatter without simple solutions.
"Research is seeing the obvious." [1]
1) The missing part is information.
Solution:
a) Provide a message (warning, error), if "\snn" is in the input.
b) Augment the documentation to tell the readers,
that "\snn" is depr
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
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
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
> [...] 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
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.
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,
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
> 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
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!
>
>
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
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 Branden,
> To the broader group, I would furthermore suggest that, being GNU roff,
> it might behoove us to preserve the above "accident of history" only in
> compatibility mode, and have the \sn form accept only a single-digit
> argument for consistency with other escape forms. Doug still wou
On Mon, Mar 30, 2020 at 10:53:23PM -0400, Doug McIlroy wrote:
> Subject: Re: weird \s
>
> Did the author of groff steal the code from Bell Labs? Or did
> he merely read the code and preserve the feature in a misguided
> nod to backward compatibility? Did he find it by
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!
Clearly this dates from the first CAT phototypesetter's limited
range of point sizes: 6
sydney.edu...@gnu.org] on behalf of
G. Branden Robinson [g.branden.robin...@gmail.com]
Sent: Tuesday, 31 March 2020 12:32 PM
To: Doug McIlroy
Cc: groff@gnu.org
Subject: Re: weird \s
At 2020-03-30T19:16:56-0400, Doug McIlroy wrote:
> Does anyone else see the following behavior?
> Version 1.
At 2020-03-30T19:16:56-0400, Doug McIlroy wrote:
> Does anyone else see the following behavior?
> Version 1.22.4 handles \s correctly up to \s39, but
> truncates a size of 40 or greater to its first
> digit. Here are two screen shots, with ^D edited in
> to show where input ends and output begins.
On 31/03/20 10:16:56, Doug McIlroy wrote:
Does anyone else see the following behavior?
Version 1.22.4 handles \s correctly up to \s39, but truncates a size
of 40 or greater to its first digit.
Good morning Doug,
The info page for my version 1.21 has the following:
`\sN' Set the point size t
I've used troff since the 1980s, and I've NEVER used that form for
defining point size.
Instead, I used .ps to establish the point size, then \s+nn where I've
used values up to 15
or perhaps more -- don't recall for sure.
I then us \s0 to return to the original value before the change.
Same
35 matches
Mail list logo
