> > > cannot handle regular expressions or kinda glob-ing as
> > > patterns?
> would be really cool to have.
Unfortunately, this also means inventing a new syntax.
How should "\*", "\(", and "\[" be treated -- as groff
escapes or as regular-expression magic?
Hi Tadziu,
> Unfortunately, this also means inventing a new syntax. How should
> "\*", "\(", and "\[" be treated -- as groff escapes or as
> regular-expression magic?
Exactly. Taking an earlier suggestion for OR, it's valid now.
$ nroff | grep .
.if 'a'a'b'c'
b’c’
$
However, a
wrote:
|>> the statement:
|>>
|>> .if 'str1'str2' anything
|>>
|>> cannot handle regular expressions or kinda glob-ing as patterns?
would be really cool to have.
|A nested .if-statement will have two .el-parts, containing the same
|code. I wanted to avoid that. However, a De Morgan of the
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
Tadziu Hoffmann wrote:
|>>> cannot handle regular expressions or kinda glob-ing as
|>>> patterns?
|
|> would be really cool to have.
|
|Unfortunately, this also means inventing a new syntax.
|How should "\*", "\(", and "\[" be treated -- as groff
|escapes or as regular-expression magic?
G
Tadziu Hoffmann wrote:
> Unfortunately, this also means inventing a new syntax.
> How should "\*", "\(", and "\[" be treated -- as groff
> escapes or as regular-expression magic?
A regex pattern containing variables is questionable. The pattern should be
literal (i.e. it is clear by the syntax
Ralph Corderoy wrote:
|> Unfortunately, this also means inventing a new syntax. How should
|> "\*", "\(", and "\[" be treated -- as groff escapes or as
|> regular-expression magic?
|
|Exactly. Taking an earlier suggestion for OR, it's valid now.
|
|$ nroff | grep .
|.if 'a'a'b'c'
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 Carsten,
> 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).
No, I think it's correct, and match
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
Hi Steffen,
> But anyway, i wonder what you all think about instead introducing
>
> .if $'a'b'c'd'e'f'g'a'$ .tm matches
>
> i.e., by enclosing the expression in a pair of dollars the normal
> delimiters can be used all through the case..esac string comparison
> series.
Is there any point intr
Hello again, and however..
i wrote
|Ralph Corderoy wrote:
||Exactly. Taking an earlier suggestion for OR, it's valid now.
which makes the former a backward-compatibility no-go, even though
i don't want to imagine a case where it would cause a problem.
But anyway, i wonder what you all think a
Here is another idea. Use the existing (;) notation eg as follows
(Ex; expr )
Where x is the existing unit indicator, E indicates an extended
expression and expr differs from current expressions in having
(a) operator priority;
(b) new string, matching and regular expression operators (Posix
> imho that is really annoying since some systems which never
> updated from 1.19.2 because of licensing reasons and have not yet
> moved to mandoc(1) are not capable to display the manual
> correctly via man(1) out of the box.
> And it is completely unnecessary since it seems Werner has
> designe
> I've just fully rebased `automake3', and I think it is nearly ready
> to be merged into master.
Great!
> - An entry in `NEWS' should also be added.
Why? Is there any change for the user?
Werner
Carsten Kunze wrote:
|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.
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
Carsten Kunze wrote:
|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/gro\
|ff/2014-11/msg00131.html) that this is poss
Ralph Corderoy wrote:
|Hi Steffen,
Yes! Ralph likes it!
(Good not to hear any technical objection!)
Ciao,
--steffen
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
Hallo Colin,
thanks a lot for your very clear explanations.
It worked fine.
I went to
https://launchpad.net/ubuntu/+source/groff/1.22.3-1 , selected my
architecture under "Builds" and got the right .deb to download.
I installed it with sudo dpkg -i.
I had just to install groff-base 1.22.3-
On Thu, Nov 13, 2014 at 09:28:05PM +0100, Carsten Kunze wrote:
> Subject: Re: [Groff] condition: OR of two string comparisons
>
>
> But why not as a first step keep the old syntax and make & a
> real AND and : ar real OR so that
>
> .if (\\n(AB>5:"\\$1"foo")&(!\\n(.$=2) ...
>
> is possible?
Th
>> > 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).
>>
>> No, I think it's correct, and
On 11/13/14, Carsten Kunze wrote:
> I see no relation of \h and .ss. So this
> sentence (although correct) does not make sense here. But "\ " is used in
> the example, for *that* escape the sentence would make sense.
The point of that sentence is that the example preceding it shows a
situation
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
26 matches
Mail list logo
