Steffen Nurpmeso wrote:
> Well. Why not restricting this by saying that a new conditional
> mode (don't nail me down onto it: .if @'LHS'RHS') is introduced
> where RHS (or LHS) is _not_ subject to token processing, but
> _only_ to regular expression matching, e.g.
>
> .ds idea La terre est fe
Steffen Nurpmeso wrote:
> Like Tadziu said, having an opportunity to be more specific, on
> a per-letter base, would be something to play with.
It's an idea.
Werner had answered
(http://lists.gnu.org/archive/html/groff/2014-11/msg00131.html) that this is
possible with the .ss request, but I th
Hi Ralph,
Ralph Corderoy wrote:
> > maybe there is a typo in "5.7 Manipulating Filling and Adjusting"
> > section "Register: \n[.sss]". In the sentence "Note that the \h
> > escape produces unbreakable space." the "h" maybe should actually be a
> > space (in the context of that section).
>
> N
Ralph Corderoy wrote:
> $ nroff | grep .
> .if 'a'a'b'c'
> b?c?
> $
>
> However, a new syntax is needed. I'd guess something at the start that
> is currently invalid would indicate a whole new style of expression is
> present, one with typical precedence, and more string matchin
Dave Kemper wrote:
> The point of that sentence is that the example preceding it shows a
> situation where one might think to use a \h to insert horizontal
> space. That sentence is pointing out a drawback of \h in that
> context, compared to the fiddling-with-.ss approach used in the
> example.
Hi Ralph,
> If study shows that old valid expressions can't be interpreted
> differently under the new parsing rules, then fine. But I'd assume they
> could be.
Why should they when they don't contain errors or use side effects? The
current rules for numerical expressions and the conditional st
> The `anything' might now look like the continuation of the expression.
>
> .if t&e
It makes sense that there is a space between `N' and `anything'. Traditional
troff may be fine without that space but for that case there is a compatibility
mode. So I still see no problem. Do you?
Carst
Steffen Nurpmeso wrote:
> For S-roff i can say that yes, i'm open and want such an
> extension, but i will not tear up the parsers that yet exist in
> order to do so.
> I'm not yet sure but i think introducing the $ extension trigger
> seems to be a way to get this going, introducing some "outer
Steffen Nurpmeso wrote:
> But i would prefer if the roff's could stay in sync somewhat.
> Noone wins if this diverges even more.
That had been my preference too. But I'm not convinced of that new syntax, I'd
like to stay with which is well known to all *roff users (that means ".if N"
and addi
Steffen Nurpmeso wrote:
> I personally don't like neither Carsten's N idea nor (X;).
> The former has the problem that a lot of letters are yet used,
> including lowercase n, meaning that there is no immediate visual
> indication that the expression is of an extended kind, so to say.
What precis
Tadziu Hoffmann wrote:
> I thought the whole idea of if/elseif/else/endif was about
> improving the clarity of deeply nested conditionals?
> Otherwise the existing syntax is sufficient...
Of course the existing syntax is sufficient. What is the gain of writing .elif
instead of .el .if? Two cha
hoh...@arcor.de wrote:
> > .ifx ... \{\
> > ...
> > .\}
> > .el .if ...
>
> A customer would know inherently that for
>
> .if x ... \{\
> ...
> .\}
> .el .if ...
The use should know if compatibility mode is on or not. I think few users
today know that once (lets name it) .iff and .if f was th
hoh...@arcor.de wrote:
> Is this a standard? (.ifg == .if g, .ifq == .if q, ..)
Only in compatibility mode. In default groff mode it is not the same.
> .iff doesn't exists, doesn't it?
It is discussed as one possibility to be implemented.
> .if o and .ifo isn't implemented neither.??
.if
> Having `.if x' instead of a new keyword `.ifx' is appealing to me.
Ok, sounds interesting. Could also be used for .nr:
.nr x
> Assuming that we have a global register to activate a novel
> interpretation of expressions (as suggested by Colin), we could indeed
> simply stay with the currentl
> No. Only the part where this register is set gets interpreted with
> the new syntax.
You're right. This is a good solution.
> Note that groff doesn't convert macros into an internal
> representation; they are only stored and interpreted on demand (this
> has both advantages and disadvantages)
Ingo Schwarze wrote:
> > While that is true... The current behaviour is an unusable
> > mystery to me personally: how can you gain a substring of length
> > null,
>
> .rm myname
> .ds myname ""
This defines " for myname.
> .ds myname \&
But
.ds myname
could be added to the list.
BTW
> BTW: Why doesn't .fl work with GNU nroff?
Sorry, I should have looked in the manual before asking...
Carsten
Hi Ralph,
> But new users to troff, and I think Peter's MOM can attract them, could
> well have been raised on C at best and Java at worst. If we're to have
> them step beyond the friendly macro package into doing a bit of troff,
> getting involved, helping keep interest going, perhaps specialis
> Oh, I think a basic .if is still useful to the novice who will probably
> want to conditionally do something, e.g. "DRAFT" heading, etc. Does mom
> aim to remove the need for any non-mom-macro command, e.g. `.ds company
> Google, Inc.'?
Ok, I agree. But there might not be much of that statemen
Hi Ralph,
> > (It was unfair to put the .ds after .if !\w and .if d ... :-)
>
> I didn't write it; it's real code from groff's distributed macros. :-)
I meant that there was the condition *and* the conditional statement on the
same line which has made this example looking more complicated tha
Hi Ralph,
> What about string expressions that give strings as results? And having
> `.ds' take a new-format expression?
This is a totally different thing. We had been talking about conditionals and
numerical expressions.
> I'm fed up pointing out in different emails this is about having some
Hello,
is it safe to divert into a string variable? That means instead of:
.br
.di A
...text...
.br
.di
.A
use something like:
.br
.di A
...text...
.br
.di
...\*A...
The 4.4BSD mdoc macros use this in the macro .x2. The string is even
interpolated in fill mode there... It works somehow but
Dave Kemper wrote:
> It's documented in the groff manual in section 5.19; see the sentence
> "Strings, macros, and diversions (and boxes) share the same name
> space" and the following few paragraphs.
That doesn't describe it. But indeed the following sentences (of the groff
manual) do.
But i
> It's documented in the groff manual in section 5.19; see the sentence
> "Strings, macros, and diversions (and boxes) share the same name
> space" and the following few paragraphs.
Didn't read it to the end--yes, the following sentences do. But can it be
agreed, that it's not specified for hist
Hi Ralph,
> Disagree. The venerable CSTR 54.
>
> 7.1. ... Request, macro, and string names share the same name
> list.
Yes, ok. But I had stated that it is not specified in CSTR54 that macro
contents can be accessed via \*(xx and that a string defined with ".ds xx ..."
can be acces
> > Yes. But does this say that the diverted data can be accessed via \*(xx?
>
> It shouldn't be done. Whether it *can* be done is an implementation
> detail. In many languages you can create interesting effects by
> writing to an array with an out-of-bounds index. That doesn't mean
> it *shou
> I want to make a document that can give good
> ascii and Postscript results. I found that I need
> to adjust the formating of tables. I'm trying to
> to this with .ie/.el like this:
>
>10 .TS H
>11 expand,center;
>12 .ie t lw(0.5i) lw(0.01i) lw(0.5i) lw(2.5i) lw(1.4i).
>13
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.
Hello,
are there special characters missing in groff? I get the following warnings in
an UTF8 locale:
$ tbl /usr/local/share/man/man7/groff_char.7|nroff -mandoc >/dev/null
/usr/local/share/man/man7/groff_char.7:811: warning: can't find special
character `\o'
/usr/local/share/man/man7/groff_cha
Hello,
when there is a unicode character for e.g. "not equal" (U+2260) why there is a
combination of characters in groff_char(7) instead of unicode? Is it intended
for ASCII output?
Carsten
Hi Ingo,
thanks for your in-depth answer!
> 3. In case you are talking about the third column "Unicode"
> in said table, which contains "u003D_0338" even though
> groff actually produces U+2260:
> That looks like a documentation bug to me. I'm not
> sending a patch because ther
Hello,
it should not be a problem for gtbl to restore the tab settings "itself".
If at begin it saves register \n[.tabs] in a string and then set
.ta \*[saved_tabs]
at the end the tabs from before .TS should be set after .TE?
Carsten
Robert Thorsby wrote:
> I need to set some text (eg., Lorem Ipsum) along the arc of a curve
> (eg, a circle). The curve itself need not be visible.
>
> Can anyone point me in the right direction? A mailing list thread?
> Something in pic? Some postscript code?
Heirloom troff has a .pshape r
Hello,
is there a way (except \N'45') to output an ASCII dash (0x2d) with nroff in an
UTF-8 locale (i.e. without -T or with -Tutf8)?
I want to copy command lines from nroff output into a xterm, but the shell
complains about the '-' which is not 0x2d.
E.g. mandoc(1) does output 0x2d for '\-' an
Hello Ingo and Anthony,
> That shouldn't happen in manual pages. Both tmac/an-old.tmac
> and tmac/doc.tmac contain:
>
> .\" For UTF-8, map some characters conservatively for the sake
> .\" of easy cut and paste.
> .
> .if '\*[.T]'utf8' \{\
> . rchar \- - ' `
> .
> . char \- \N'45'
> .
"Anthony J. Bentley" wrote:
> I only
> ever mark up command flags in -mdoc, so I just type Fl for those. I
> wish Fl became ASCII '-', but we're talking about changing decades of
> historical practice here.
It is ASCII (as Ingo had pointed out), isn't it? I had tested it right now
with -mdoc a
Deri James wrote:
> If you use groff's native pdf driver (-Tpdf) I believe
> minus is rendered, can be searched for and
> copy/pasted. The postscript driver also outputs a
> "minus" so I suspect it is the ghostscript conversion
> to pdf which is changing it.
It is ok for me if copy/paste fro
Dorai Sitaram wrote:
> I had the following
> .char ? \[u005C]
> in a file (the first ? is U+2216, or set-minus) and used set-minus within
> the same file, and it works fine.
> However, when I place the .char call in a different file, and source it via
> .so or .mso, occurrences of set-minus in t
Bjarni Ingi Gislason wrote:
An: groff@gnu.org
Datum: 06.03.2015 22:57
Betreff: [Groff] Lack of professionalism, thinking, education, understanding,
wisdom, consequences, [references] ...
> A trigger was an output from my "man"-script with argument "mg"
>
> :10: warning: unbalanced .el
Bjarni Ingi Gislason wrote:
> I did not see at first anything wrong, there are two left curly
> brackets and two right ones. Each "ie" and "el" has a one line
> argument or a block, but the code is FLAT, there is NO STRUCTURE
> visible.
There is indeed no indentation in the installed
/usr/loc
201 - 240 of 240 matches
Mail list logo
