At 2020-11-21T15:04:06+0100, Tadziu Hoffmann wrote:
> You should replay diversions in no-fill mode (.nf), otherwise
> whitespace will be reformatted *again* (which you usually don't
> want, since diversions contain already-formatted material).
Yp. Ding ding ding. A couple of qualifiers in CS
You should replay diversions in no-fill mode (.nf), otherwise
whitespace will be reformatted *again* (which you usually don't
want, since diversions contain already-formatted material).
In a move that will shock no one, I'm working on the manual. I'm also
using Heirloom Doctools troff as a convenient stand-in for AT&T because
it is a pain to fire up SIMH and run V7 Unix troff, though I have done
it before.
Is the following behavior difference a bug? Can someone explain to me
wh
Hi Tadziu,
> I was actually surprised to see that this feature existed at all in
> Heirloom and Unix nroff, and I would consider it to be a bug (just not
> a bug that the Heirloom project introduced, but one that was already
> present in Unix n/troff).
>
> My guess is that it's not intentional, bu
> Based on this, if I understand correctly, without further knowledge
> whether some arbitrary text would be passed through a diversion or not,
> one must make sure he escapes (e.g using "\&") all words starting
> with "." or "'", such as below?
> AAA BBB BBB \&.CCC CCC
Yes.
(But beware of ma
Thank you, Branden and Tadziu. It would seem this particular issue
is most closely related to the investigation performed by Tadziu.
Based on this, if I understand correctly, without further knowledge
whether some arbitrary text would be passed through a diversion or not,
one must make sure he es
> Have Ultrix rise again?
> https://www.in-ulm.de/~mascheck/various/ancient/
Indeed! Didn't know this existed, but it's been an eye-opener.
I ran the PDP-11 emulator with v7 Unix, and the included nroff
(this appears to be pre-DIT n/troff, as troff just produced
gibberish probably intended for
Hi Tadziu,
> our old Ultrix machine has been decommissioned
Have Ultrix rise again?
https://www.in-ulm.de/~mascheck/various/ancient/
--
Cheers, Ralph.
> Before creating a bug report, I would like to verify that I am not
> misunderstanding something and that this is indeed a bug.
[snip]
Hard to tell. Maybe it's a feature of Heirloom roff.
The documentation doesn't say much about how these output-line
traps work internally except that they are
At 2019-04-22T06:20:05-0400, Mircea Hossu wrote:
> Before creating a bug report, I would like to verify that I am not
> misunderstanding something and that this is indeed a bug.
>
> It appears that a word starting with a period or apostrophe is
> interpreted as a request/macro call even if it doe
Hello,
Before creating a bug report, I would like to verify that I am not
misunderstanding something and that this is indeed a bug.
It appears that a word starting with a period or apostrophe is
interpreted as a request/macro call even if it does not start at the
beginning of the line, under the
I do not have experience with online collaborative programming, so I
just opened a github account and created an issue regarding this,
along with source code and a few more examples:
Suggestion: adding external scripting support to troff:
https://github.com/n-t-roff/heirloom-doctools/issues/82
Wo
Hi,
On Mon, Jan 07, 2019 at 10:01:40AM -0800, Mircea Hossu wrote:
> If anyone else is interested, I can share all my work, which is
> implemented in the Heirloom troff source tree. Any other suggestions
> are very much appreciated.
Maybe you could open a pull request or similar:
https://github
Thank you, Tadziu, it is an interesting trick and it does work in the
test case posted earlier. Unfortunately, in a more realistic document,
I did hit those "unexpected results", e.g. when the string was used
inside a macro argument (thank you for the warning).
The final solution I picked was to c
> But, after a quick experiment, it seems to not behave this
> way. The macro body gets expanded instead of executing:
In groff it works with the following change:
.de m
\c
.nr x +1
..
Be aware that this is only a trick. It works in the running
text, but can go wrong unexpectedly in o
I didn't know that was possible. Yes, it would indeed solve my
problem. But, after a quick experiment, it seems to not behave this
way. The macro body gets expanded instead of executing:
.do xflag 3
.papersize a4
.mediasize a4
.ps 14p
.vs 24p
.
.nr x 0 1
.de m
.nr x +1
..
.ds s \\n+x
.ds t \\*m\\n
You can invoke a macro with name xxx with
\*[xxx]
instead of
.xxx
You can even provide arguments for the macro in the form
\*[xxx arg1 ...]
as explained in
http://n-t-roff.github.io/heirloom/doctools/troff.pdf
§7.1. Does this answer your question or did you mean something else?
Is it possible in Heirloom troff to invoke a macro from a string?
There is an escape sequence:
\R'R ±N' => Set number register R to ±N
This is useful, but the expression is too limiting in some cases. For
example, is it possible to increase register R by 1 only if it hasn't
reached a maximum va
Dnia 21.08.2016 Werner LEMBERG napisał/a:
>
>> I don't know if spaces are forbidden in the spec, but I have
>> proposed the change (https://github.com/n-t-roff/heirloom-doctools/pull/34)
>> to properly encode the glyph name so it does not
>> interfere with PostScript.
>
> Glyph names in a `post' t
> I don't know if spaces are forbidden in the spec, but I have
> proposed the change (https://github.com/n-t-roff/heirloom-doctools/pull/34)
> to properly encode the glyph name so it does not
> interfere with PostScript.
Glyph names in a `post' table must not contain spaces, since they are
intend
Dnia 20.08.2016 Werner LEMBERG napisał/a:
>
>
>> actually I don't think it is really a heirloom-doctools issue, but
>> rather problem with the font or ghostscript.
>>
>> The problem is described at
>>
>> https://github.com/n-t-roff/heirloom-doctools/issues/33
>
> I've commented there; the font i
> actually I don't think it is really a heirloom-doctools issue, but
> rather problem with the font or ghostscript.
>
> The problem is described at
>
> https://github.com/n-t-roff/heirloom-doctools/issues/33
I've commented there; the font is invalid.
Werner
Hello,
actually I don't think it is really a heirloom-doctools issue, but rather
problem with the font or ghostscript.
The problem is described at
https://github.com/n-t-roff/heirloom-doctools/issues/33
With the test file supplied by the user and
troff -ms test.ps | dpost > test.ps
gs test.ps
Hi Dorai,
Dorai Sitaram wrote:
> This is somewhat related. What is the canonical way to determine using
> generic troff commands that the troff being used is Heirloom troff, without
> regard to whether compatibility is off or on? (I used to test the number
> register .g to rule out groff, but a
Hi Carsten:
[Sorry. didn't send to group on first try.]
This is somewhat related. What is the canonical way to determine using generic
troff commands that the troff being used is Heirloom troff, without regard to
whether compatibility is off or on? (I used to test the number register .g to
rul
Werner LEMBERG wrote:
> Ah, I wasn't aware that the project moved to github. Please commit a
> last change to the CVS repository that explains that the project has
> moved, and that the CVS repository is now defunct! Ditto for
> http://heirloom.sourceforge.net/doctools.html.
That would indeed m
> since the last Heirloom troff release one year ago there had been
> many bug fixes.
Ah, I wasn't aware that the project moved to github. Please commit a
last change to the CVS repository that explains that the project has
moved, and that the CVS repository is now defunct! Ditto for
http://hei
Hello,
since the last Heirloom troff release one year ago there had been many bug
fixes. Most of them are -mandoc related, some also address general typesetting
issues. It had become necessary to create a new release since the state of the
current release is quite obsolte.
Before the release
Hello Henry,
Henry McGilton wrote:
> I have been reading and re-reading the Heirloom instructions for
> adding fonts to the collection.
>
> Given that dpost is (apparently) a reflection of a LaserWriter II,
> should I add new fonts to dpost, or should I create some new
> device of my own?
Have
I have been reading and re-reading the Heirloom instructions for
adding fonts to the collection.
Given that dpost is (apparently) a reflection of a LaserWriter II,
should I add new fonts to dpost, or should I create some new
device of my own?
There is a snippet of information in the instruction
Hello,
in lack of a Heirloom roff mailing list from time to time I use the groff list
for Heirloom discussions hoping that some Heirloom users are on this list.
It had IMHO been an unfortunate decision to to give \A at Heirloom a different
meaning than that of groff's \A. Now I need this funct
Hello,
compared to TeX Heirloom's paragraph formatting is unacceptable and will
change. It is likely that parameters of the new behavior will be adjustable
(since it depends on the typographs taste and the actual document, what is
best), even the algorithm will be selectable (so e.g. current T
Hello,
reffort@github (https://github.com/reffort) did notice a major issue in one of
the key features of Heirloom roff which is paragraph-at-once formatting.
Gunnar very likely did implement this algorithm based on the 1981 Knuth-Plass
paper (KP-81 in the following text) and had maybe not bee
> A. MM has no clear way to set ll
You can use ll in MM, but the effect will remain local.
It is common practice among macro packages to reset the line length
to some "master value" on every paragraph / section header / etc.
In MM that master value is taken from register W while defining
the ma
On Mon, Jun 22, 2015 at 09:02:16AM -0500, Blake McBride wrote:
> I have been using troff on and off since 1983. I know all that.
>
> The macro packages act as a higher level API but almost never completely
> duplicates all of the lower level commands. Surely you don't want to
> conflict with a m
I have been using troff on and off since 1983. I know all that.
The macro packages act as a higher level API but almost never completely
duplicates all of the lower level commands. Surely you don't want to
conflict with a macro package that assumes it has control over a certain
parameter, but li
On Sun, Jun 21, 2015 at 08:35:34PM -0500, Blake McBride wrote:
> On Sat, Jun 20, 2015 at 3:52 PM, wrote:
> > The interface to .ll is \nW or .PGFORM. At first my plan was to implement
> > .PGFORM. But *maybe* using W like MS's LL could also make sense. But for
> > compatibility with groff .PGFOR
> .ll works with MM in Heirloom and groff. Tbl should too.
> It doesn't make sense to require all kinds of hoops just to
> get something as basic as .ll to work.
> Also, why would the problem be in MM? MM is working. I think
> the problem is in tbl.
I think you misunderstood me. Tbl *is* usi
> Adding .PGFORM is fine, but I would prefer just having .ll work like it
> does on groff. This way the original docs work and produce as expected.
.PGFORM is already implemented but not committed yet.
Do you know how .ll works in groff's MM? It is not documented. You know how
it works for y
On Sat, Jun 20, 2015 at 3:52 PM, wrote:
> ...
>
> The interface to .ll is \nW or .PGFORM. At first my plan was to implement
> .PGFORM. But *maybe* using W like MS's LL could also make sense. But for
> compatibility with groff .PGFORM should be prefered. (?)
>
Adding .PGFORM is fine, but I wou
> 1. I do use Heirloom troff and I often use MM.
This is a statement. So heirloom MM will be changed now.
> 2. The current behavior is wrong, period. The fact that changes are being
> made to Heirloom at all proves that it isn't a think of absolute perfection
> - not to be touched. If this i
Also, why would the problem be in MM? MM is working. I think the problem
is in tbl.
On Sat, Jun 20, 2015 at 9:07 AM, Blake McBride wrote:
> 1. I do use Heirloom troff and I often use MM.
>
> 2. The current behavior is wrong, period. The fact that changes are
> being made to Heirloom at all
1. I do use Heirloom troff and I often use MM.
2. The current behavior is wrong, period. The fact that changes are being
made to Heirloom at all proves that it isn't a think of absolute perfection
- not to be touched. If this issue were reported back when MM was being
developed, they would hav
Hi Ralph,
> groff_mm(7):
>
> PGFORM [linelength [pagelength [pageoffset [1
thank you!
If one *uses* heirlooms -mm macros and *really* needs that feature it could be
added. Otherwise I would agree with Tadziu that initially setting W should be
sufficient. The -ms macros had register
> [...] though I think that was accidental and thus a bug.
https://xkcd.com/1172/
:-)
Hi Tadziu,
> You might even want to keep a copy of the macros with the document, to
> avoid possible surprises in case the systemwide macros get updated and
> this results in different formatting.
As with the 1.17.2 to 1.18 change, though I think that was accidental
and thus a bug.
https://b
> PGFORM [linelength [pagelength [pageoffset [1
Yes, but that's for the GNU version of mm. I don't think
the original AT&T macros had a corresponding request.
One could theoretically delve into the mm code to see how
the various parts are initialized from the registers set on
the comman
Hi Carsten,
> IMHO it is not expected that .ll is compatible with the -mm macros.
> These macros often set .ll from register W or other internal
> registers. It looks to me that -mm doesn't support changing the line
> length inside the document. Are there -mm experts who know the
> suggested way
> I'd prefer it to be changed to work as expected rather than
> have to employ secret internal steps.
Then use the -rW command line option. This is the
way the designers of mm intended the text width to be set
(instead of using troff internals such as .ll), and it's
clearly documented (so it's n
Blake McBride wrote:
> I'd prefer it to be changed to work as expected rather than have to employ
> secret internal steps.
IMHO it is not expected that .ll is compatible with the -mm macros. These
macros often set .ll from register W or other internal registers. It looks to
me that -mm doesn
I'd prefer it to be changed to work as expected rather than have to employ
secret internal steps.
Thanks.
Blake
On Jun 19, 2015 5:42 AM, "Tadziu Hoffmann"
wrote:
>
> > The "expand" option works correctly (as expected) on groff,
> > but when using Heirloom _with_ MM, it doesn't fully expand.
> >
> The "expand" option works correctly (as expected) on groff,
> but when using Heirloom _with_ MM, it doesn't fully expand.
> I think it does without MM.
In the heirloom version of mm the display is processed in
environment 1, which still has the original line length.
To fix your problem, you cou
The "expand" option works correctly (as expected) on groff, but when using
Heirloom _with_ MM, it doesn't fully expand. I think it does without MM.
Here is a sample:
.ll 6.5i
Now is the time for all good men to come to the aid of their party.
Now is the time for all good men to come to the aid of
On Mon, 08 Dec 2014 18:08:28 +
Ralph Corderoy wrote:
> Hi Ingo,
>
> > You are confusing character escape sequences \[...]
> > and user-defined strings \*[...].
>
See groff_char(7)
--
Hi Ingo,
> You are confusing character escape sequences \[...]
> and user-defined strings \*[...].
Thanks!
Cheers, Ralph.
Hi Ralph,
Ralph Corderoy wrote on Mon, Dec 08, 2014 at 05:53:31PM +:
> Carsten wrote:
>> someone wrote:
>>> \(lqABC\(rq
>>> doesn't put double quotes around ABC like groff and Neatroff do.
>> This is a groffism :)
> `info groff' has this under node `Predefined man strings' suggesting
> it's
Hi,
Carsten wrote:
> > \(lqABC\(rq
> >
> > doesn't put double quotes around ABC like groff and Neatroff do.
>
> This is a groffism :)
`info groff' has this under node `Predefined man strings' suggesting
it's with -man only, but it works all the time?
Cheers, Ralph.
Hi Blake,
> I haven't updated my Heirloom stuff in a little while but I came across an
> interesting problem.
>
> \(lqABC\(rq
>
> doesn't put double quotes around ABC like groff and Neatroff do.
This is a groffism :)
Traditional troff did use ``ABC'' and nroff did use "ABC". But I'll add it.
Greetings,
I haven't updated my Heirloom stuff in a little while but I came across an
interesting problem.
\(lqABC\(rq
doesn't put double quotes around ABC like groff and Neatroff do.
Thanks.
Blake
> BTW--something I've never figured out is whether it's possible to
> set up kern pairs in groff font files that have "space" as the first
> element of the pair.
This is not possible.
Werner
On Fri, Nov 14, 2014, Dale Snell wrote:
> But I am wondering if the publishing houses are hiring
> professionals anymore.
Pretty much, no, at least here in Canada. To be expected now that
typesetter, as a recognized trade, is dead.
--
Peter Schaffter
http://www.schaffter.ca
On Fri, Nov 14, 2014 at 01:53:20PM -0500, Peter Schaffter wrote:
> > ... ease of reading or better comprehension ...
> >have nothing to do with "the rules." Sigh.
> :
> The matter gets more complicated when you have sentences that end
> with "r." or "y.".
>
On Fri, 14 Nov 2014 19:31:48 +0100
Tadziu Hoffmann wrote:
>
> > > So the default groff behavior of adding additional space
> > > between sentences also does not follow today's typical US
> > > typography. You would have to specify ".ss 12 0" to achieve
> > > US convention.
>
> > It seems ease
On Fri, Nov 14, 2014, Mike Bianchi wrote:
> It seems ease of reading or better comprehension (which are the reasons I
> prefer extra space after sentences, etc.) have nothing to do with "the rules."
> Sigh.
I wouldn't say "nothing," but the issue of spacing between sentences
is tricky and hard to
> > So the default groff behavior of adding additional space
> > between sentences also does not follow today's typical US
> > typography. You would have to specify ".ss 12 0" to achieve
> > US convention.
> It seems ease of reading or better comprehension (which are
> the reasons I prefer extra
On Thu, Nov 13, 2014 at 08:17:50PM -0600, Dave Kemper wrote:
> On 11/12/14, Carsten Kunze wrote:
> > by default Heirloom troff inserts a double word space if a line ends with
> > ":". Is this correct US English typography?
>
> Most modern US typography uses the same amount of space for everythin
On 11/12/14, Carsten Kunze wrote:
> by default Heirloom troff inserts a double word space if a line ends with
> ":". Is this correct US English typography?
Most modern US typography uses the same amount of space for everything
on the line: between sentences, between words, and after any
punctuat
Hi jkl,
> If the succeeding clause is independent, put it on a different line
> and let troff treat it as end-of-sentence. If it's not, leave it in
> the running text and let troff treat as end-of-word.
Yep, matches how I understand English English. For the end of word:\&
suffix with a zero-wi
Carsten Kunze wrote:
|"James K. Lowden" wrote:
|> It is not incorrect. Typographical convention has varied over time and
|> treatment of the colon along with it. So, "correct" is hard to pin
|> down.
|>
|> I was taught 500 moons ago that a colon may be followed by one or two
|> spaces
Clarke Echols wrote:
> Only input lines that end with an end-of-sentence character
> (including colon) is treated other than as a normal single-space-
> between-words situation -- or at least that's my understanding.
Ok, .cflags 1 sets it. I didn't get it on first reading of the
documenta
On 11/12/2014 03:13 PM, Carsten Kunze wrote:
Werner LEMBERG wrote:
How about 1.5 times the wordspace after a period that ends a
sentence, 1.2 times the wordspace after a colon? Or some other
fraction?
groff's `.ss' command allows this.
But groff does not distinguish between an input lin
Werner LEMBERG wrote:
> > How about 1.5 times the wordspace after a period that ends a
> > sentence, 1.2 times the wordspace after a colon? Or some other
> > fraction?
>
> groff's `.ss' command allows this.
But groff does not distinguish between an input line that ends with a word and
an inpu
On 11/12/2014 03:02 PM, Werner LEMBERG wrote:
That is new to me. I thought that only one space is
used after a colon.
Why do people always think that space should exist
only in integer multiples of a basic space quantum?
This is what people used with old typewriters.
How about 1.5 time
>> That is new to me. I thought that only one space is
>> used after a colon.
>
> Why do people always think that space should exist
> only in integer multiples of a basic space quantum?
This is what people used with old typewriters.
> How about 1.5 times the wordspace after a period that ends
> That is new to me. I thought that only one space is
> used after a colon.
Why do people always think that space should exist
only in integer multiples of a basic space quantum?
How about 1.5 times the wordspace after a period that
ends a sentence, 1.2 times the wordspace after a colon?
Or some
"James K. Lowden" wrote:
> It is not incorrect. Typographical convention has varied over time and
> treatment of the colon along with it. So, "correct" is hard to pin
> down.
>
> I was taught 500 moons ago that a colon may be followed by one or two
> spaces depending on purpose. Examples:
Peter Schaffter wrote:
> For typeset copy with proportionally-spaced fonts, no. For
> monospaced fonts (terminal), yes, but only if sentences are
> separated by two wordspaces as well.
That is new to me. I thought that only one space is used after a colon.
So now what about the behavior of gr
On Wed, 12 Nov 2014 18:08:12 +0100 (CET)
Carsten Kunze wrote:
> by default Heirloom troff inserts a double word space if a line ends
> with ":". Is this correct US English typography?
It is not incorrect. Typographical convention has varied over time and
treatment of the colon along with it.
On Wed, Nov 12, 2014, Carsten Kunze wrote:
> Hello,
>
> by default Heirloom troff inserts a double word space if a line
> ends with ":". Is this correct US English typography?
For typeset copy with proportionally-spaced fonts, no. For
monospaced fonts (terminal), yes, but only if sentences are
Hello,
by default Heirloom troff inserts a double word space if a line ends with ":".
Is this correct US English typography?
Carsten
Hi Carsten,
Carsten Kunze writes:
> "Anthony J. Bentley" wrote:
>
> > It's worth noting that groff's refer(1) already uses typographic quotes
> > around %T with my -ms documents.
>
> Can you please provide some lines of input for refer/-ms to reproduce this?
foo.ms:
.PP
.[
foo
.]
bibliograp
"Anthony J. Bentley" wrote:
> It's worth noting that groff's refer(1) already uses typographic quotes
> around %T with my -ms documents.
Can you please provide some lines of input for refer/-ms to reproduce this?
Carsten
Hello,
following the groff trend :) there will be a heirloom troff release soon.
AFAIK the last release had been on 2008-04-07. This had been a 32 bit version
(normally at that time), which causes problems on current 64 bit systems.
To have a stable code base besides the changes in the reposi
Blake McBride wrote:
> Wow. That did fix the problem. Can't find any documentation on it.
It is documented in the tbl man page.
The line drawing commands had been introduced for pic (AFAIK). That may be the
reason that \l \L is used instead of \D'l ...'.
Or that \l \L also work with nroff.
Wow. That did fix the problem. Can't find any documentation on it. What
about lines in troff?
Thanks!
Blake
On Sun, Sep 28, 2014 at 1:31 PM, Carsten Kunze
wrote:
> Blake McBride wrote:
>
> > Documents with tables look kind of ugly and out-of-date on the screen.
>
> Please try tbl with opt
Blake McBride wrote:
> Documents with tables look kind of ugly and out-of-date on the screen.
Please try tbl with option "-g". The lines should be continuous then.
Carsten
Ralph Corderoy wrote:
> > It looks broken into dashes on the PDF for me.
>
> Different PDF viewers show it differently IME. And zoom level matters
> too. Here with evince,
>
> A\(em\h'-\w'\(em'/2'\(emB
> A\(em\(emB
>
> shows as darker on the overlap with the first line, and also very
>
Hi Blake,
> Carsten wrote:
> > Have you tested that with PDF? If I magnify it I see a continous
> > line.
>
> It looks broken into dashes on the PDF for me.
Different PDF viewers show it differently IME. And zoom level matters
too. Here with evince,
A\(em\h'-\w'\(em'/2'\(emB
A\(em\(e
On Wed, Sep 24, 2014 at 1:38 PM, Carsten Kunze
wrote:
> Blake McBride wrote:
>
> > Also, how does groff get around the problem?
>
> groff may use a true line where ditroff may use the "_" and "|" characters.
>
> > Given that most documents are probably viewed via screen these days, and
> > the u
Blake McBride wrote:
> Also, how does groff get around the problem?
groff may use a true line where ditroff may use the "_" and "|" characters.
> Given that most documents are probably viewed via screen these days, and
> the ugliness of the dashes, I'd think this is important to fix.
Have you
Thanks for the input. I'm traveling right now and don't have access to a
printer. I'll check when I get back.
Also, how does groff get around the problem?
Given that most documents are probably viewed via screen these days, and
the ugliness of the dashes, I'd think this is important to fix.
Th
Hi Blake,
> The same is also true with vertical lines with heirloom tbl. A series
> of small lines is produces rather than a single line.
This seems familiar from long ago. Could it be that if they were ink on
paper then they would overlap and join up, but when viewing them on a
screen with ant
The same is also true with vertical lines with heirloom tbl. A series of
small lines is produces rather than a single line.
On Wed, Sep 24, 2014 at 10:41 AM, Blake McBride wrote:
> This is true of =, \_, and \= too.
>
>
> On Wed, Sep 24, 2014 at 10:34 AM, Blake McBride
> wrote:
>
>> Greetings
This is true of =, \_, and \= too.
On Wed, Sep 24, 2014 at 10:34 AM, Blake McBride wrote:
> Greetings,
>
> Using the following:
>
> .TS
> l .
> _
> abcdefghijklmnopqrstuvwxyz
> .TE
>
>
> In groff, the line is unbroken (as is desired). In heirloom, a bunch of
> dashes are produced. Each dash i
Greetings,
Using the following:
.TS
l .
_
abcdefghijklmnopqrstuvwxyz
.TE
In groff, the line is unbroken (as is desired). In heirloom, a bunch of
dashes are produced. Each dash is separated by a small space. In other
words, groff produced a _line_, and heirloom troff produces a _series of
das
Ralph Corderoy wrote:
> See ascii(7), as others have said, and 10.1 in http://troff.org/54.pdf
> around where it says
I should probably stop skim through this document to look
for command definition, and start reading it from the begin
to the end... :)
Thanks !
Pierre-Jean.
Hi Pierre-Jean,
> I've recently seen the usage of the ^G character as field separator.
> That is a good idea, since it should avoid most possible conflicts
> with user input. But does anyone know what does this character means,
> and why does it seems to be prefered to other control characters ?
> .do xflag 3
> .if "A"A" .tm A is like A
> .if ^GB^GB^GB .tm B is like B
> .char " "\|
> .if "A"A" .tm A is like A
> .if ^GB^GB^GB .tm B is like B
>
> Output "A is like A" and "B is like B" only once.
It is fixed on GitHub now. Thanx for the bug report.
> Output "A is like A" and "B is like B" only once.
You mean, only once on the terminal? Do you get any text in
the output file?
> .do xflag 3
> .if "A"A" .tm A is like A
> .if ^GB^GB^GB .tm B is like B
> .char " "\|
> .if "A"A" .tm A is like A
> .if ^GB^GB^GB .tm B is like B
Sorry, I didn't notice the |. You're right, there is a problem.
1 - 100 of 145 matches
Mail list logo
