Re: Comprehension problem with macros
Hi Oliver,
> .nr number 0 1
> .while (\n[number] < 16) \{\
> .ie (\n[number] < 10) \[u4E0\n[number]]
> .el \[u4E0\*[\n[number]]]
> .nr number +1
> .\}
>
> So far, everything works perfectly.
>
> However, if I wrap this loop in a macro like
>
> .de myline
> .\" material as above
> ..
The text after .de is read twice. Once when the macro is defined and
again when it is executed. The reading occurs in two different modes.
See section 7 of CSTR 54. https://troff.org/54.pdf
For example, \nn puts the value of number-register n when the macro is
defined into the macro whereas \\nn delays getting the value of n to
when the macro is executed.
Here's a variation on your test.
$ cat oliver.tr
.pl 2
.
.ds 0 0
.ds 1 1
.ds 2 2
.ds 3 3
.ds 4 4
.ds 5 5
.ds 6 6
.ds 7 7
.ds 8 8
.ds 9 9
.ds 10 A
.ds 11 B
.ds 12 C
.ds 13 D
.ds 14 E
.ds 15 F
.
.nr n 0 1
.while (\n[n] < 16) \{\
\[u216\*[\nn]]
.nr n +1
.\}
.br
.
.de m
.nr n 0 1
.while (\\n[n] < 16) \\{\\
\\[u216\\*[\\nn]]
.nr n +1
.\\}
..
.m
$ troff -Tutf8 oliver.tr | grotty
Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ Ⅵ Ⅶ Ⅷ Ⅸ Ⅹ Ⅺ Ⅻ Ⅼ Ⅽ Ⅾ Ⅿ
Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ Ⅵ Ⅶ Ⅷ Ⅸ Ⅹ Ⅺ Ⅻ Ⅼ Ⅽ Ⅾ Ⅿ
$
--
Cheers, Ralph.
Re: Comprehension problem with macros
Hi Ralph,
yes, I remember having heard of the two different modes but had only a
passive understanding.
Thank you for pointing this out!
I also see that you avoid going through .ie n < 10 then n .el \*[n]
construction. I was not quite sure if I could abuse single-digit numbers
in such a way.
Best regards,
Oliver.
On 23/04/2023 14:24, Ralph Corderoy wrote:
Hi Oliver,
.nr number 0 1
.while (\n[number] < 16) \{\
.ie (\n[number] < 10) \[u4E0\n[number]]
.el \[u4E0\*[\n[number]]]
.nr number +1
.\}
So far, everything works perfectly.
However, if I wrap this loop in a macro like
.de myline
.\" material as above
..
The text after .de is read twice. Once when the macro is defined and
again when it is executed. The reading occurs in two different modes.
See section 7 of CSTR 54. https://troff.org/54.pdf
For example, \nn puts the value of number-register n when the macro is
defined into the macro whereas \\nn delays getting the value of n to
when the macro is executed.
Here's a variation on your test.
$ cat oliver.tr
.pl 2
.
.ds 0 0
.ds 1 1
.ds 2 2
.ds 3 3
.ds 4 4
.ds 5 5
.ds 6 6
.ds 7 7
.ds 8 8
.ds 9 9
.ds 10 A
.ds 11 B
.ds 12 C
.ds 13 D
.ds 14 E
.ds 15 F
.
.nr n 0 1
.while (\n[n] < 16) \{\
\[u216\*[\nn]]
.nr n +1
.\}
.br
.
.de m
.nr n 0 1
.while (\\n[n] < 16) \\{\\
\\[u216\\*[\\nn]]
.nr n +1
.\\}
..
.m
$ troff -Tutf8 oliver.tr | grotty
Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ Ⅵ Ⅶ Ⅷ Ⅸ Ⅹ Ⅺ Ⅻ Ⅼ Ⅽ Ⅾ Ⅿ
Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ Ⅵ Ⅶ Ⅷ Ⅸ Ⅹ Ⅺ Ⅻ Ⅼ Ⅽ Ⅾ Ⅿ
$
--
Dr. Oliver Corff
Wittelsbacherstr. 5A
10707 Berlin
G E R M A N Y
Tel.: +49-30-85727260
Mail: oliver.co...@email.de
Re: Comprehension problem with macros
Hi Oliver, > I was not quite sure if I could abuse single-digit numbers in such a > way. Single-digit strings. Sure, it's not abuse. It's the language. Just as dc(1) allows a byte as the name of a string. $ dc -e '6 7*s > cl > p' 42 $ If you think it might clash with other uses of strings 0, 1, ... then prefix their name. .ds lut0 0 ... \[u216\*[lut\nn]] -- Cheers, Ralph.
Re: Comprehension problem with macros
HI Ralph, not that I do not get the difference;-) However, I was not sure it would *work*. Best regards, Oliver. On 23/04/2023 14:40, Ralph Corderoy wrote: Hi Oliver, I was not quite sure if I could abuse single-digit numbers in such a way. Single-digit strings. Sure, it's not abuse. It's the language. Just as dc(1) allows a byte as the name of a string. $ dc -e '6 7*s > cl > p' 42 $ If you think it might clash with other uses of strings 0, 1, ... then prefix their name. .ds lut0 0 ... \[u216\*[lut\nn]] -- Dr. Oliver Corff Mail: oliver.co...@email.de
Re: Comprehension problem with macros
Hi Oliver, At 2023-04-23T14:32:55+0200, Oliver Corff wrote: > yes, I remember having heard of the two different modes "Copy mode" and (not copy mode), which didn't have a name in CSTR #54. (Terser is better. :-| ) > but had only a passive understanding. > > Thank you for pointing this out! > > I also see that you avoid going through .ie n < 10 then n .el \*[n] > construction. I was not quite sure if I could abuse single-digit > numbers in such a way. Yup. *roff is extremely generous in what it will accept as an identifier. I significantly revised groff's Texinfo manual and the groff(7) and roff(7) man pages for groff 1.23.0 to cover both this topic and copy mode in what I hope is clearer language. https://www.dropbox.com/sh/17ftu3z31couf07/AAC_9kq0ZA-Ra2ZhmZFWlLuva?dl=0 Regards, Branden signature.asc Description: PGP signature
Re: Comprehension problem with macros
Hi Branden, > > yes, I remember having heard of the two different modes > > "Copy mode" and (not copy mode), which didn't have a name in CSTR #54. > (Terser is better. :-| ) No name is needed. It would be clutter to add it. troff is either in copy mode or is not in copy mode. There is no need for a not-copy mode term. There are quite a few modes in troff, e.g. ligature. There isn't a special term for not being in ligature mode. Creating a mode ‘bar’ to indicate the mode isn't ‘foo’ increases what needs to be learnt and remembered from one term to two terms and the relationship between them. -- Cheers, Ralph.
Re: Comprehension problem with macros
At 2023-04-24T12:11:02+0100, Ralph Corderoy wrote: > > > yes, I remember having heard of the two different modes > > > > "Copy mode" and (not copy mode), which didn't have a name in CSTR > > #54. (Terser is better. :-| ) > > No name is needed. It would be clutter to add it. troff is either in > copy mode or is not in copy mode. There is no need for a not-copy > mode term. I disagree--there can be a need when the reader doesn't know which modes implicate others. Does nroff mode imply no-space mode? Does fill mode imply adjustment mode? Does no-fill mode? Is there only one adjustment mode, or several? Does nroff mode imply constant character width mode? What about underline mode? Does adjustment mode imply hyphenation mode? Are all of these questions meaningful? Can a novice tell which, if any, are nonsensical? Please don't _answer_ these. I pose them for the benefit of people other than you. > There are quite a few modes in troff, e.g. ligature. With this, I do agree. One of these days I mean to assemble a table of them since their variety is so bewildering. > There isn't a special term for not being in ligature mode. Creating a > mode ‘bar’ to indicate the mode isn't ‘foo’ increases what needs to be > learnt and remembered from one term to two terms and the relationship > between them. When your labels are "foo" and "bar", that's true. As with variable naming, when one chooses identifiers that communicate meaning, they can pay their freight. I concede that this is a point lost on those who still name the variables corresponding to their command-line option parser "cflag", "xflag", "zflag", and so on. I'm sure this is brilliant for a person who wrote the code and remembers what all of the flags mean for that particular application. It's not for anyone new to the code. Sustainable documentation, like sustainable code, is written for the benefit of people other than author at their moment of maximum familiarity with the work. Regards, Branden signature.asc Description: PGP signature
