wrote (Wed, 12 Nov 2014 20:33:07 +0100):
At least, this concept
> .if 'str'pattern1'pattern2'..'patternN' anything
fails in groff cannot determine the end of the conditional:
.if 'str'pattern1'pattern2' .tm ' cause of that
Spaces can also be part of the pattern. It seems, that braces are
nee
> I really didn't get the true meaning of that sentence from the
> example in the document. After Werners explanation it became clear.
Please provide a patch for groff.texinfo and submit it to the bug
tracker.
Werner
>> Here is another idea. Use the existing (;) notation eg as follows
>>
>> (Ex; expr )
This is a nice idea and indeed a possible solution to the problem.
However, I think it's probably too restricted to cover all aspects
people were discussing here.
> Werner, have you considered enhancing ex
> 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
"Denis M. Wilson" wrote:
|On Fri, 14 Nov 2014 15:16:47 +0100
|Steffen Nurpmeso wrote:
|>|Since the evaluation is done at runtime I can't see a problem \
|>|with variables,
|>|although it would enable some very obfuscated code...
|>
|> I don't understand this, actually.
|
|A string varia
Hallo,
Carsten Kunze wrote:
|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
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
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
"Denis M. Wilson" wrote:
|
|Steffen Nurpmeso wrote:
|> 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 t
Hallo Werner,
Werner LEMBERG wrote:
|> 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
Uff, Carsten, ,)
Carsten Kunze wrote:
|> 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 num
Steve Izma wrote:
|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(.
Hey, Ralph,
Ralph Corderoy wrote:
|> Yes! Ralph likes it!
|> (Good not to hear any technical objection!)
|
|That's the wrong conclusion to draw. :-) I just didn't see the point
|in picking over the syntax for a string-OR given what I think is the
|bigger issue.
The good news is that "("
On Fri, 14 Nov 2014 15:16:47 +0100
Steffen Nurpmeso wrote:
> |
> |Since the evaluation is done at runtime I can't see a problem \
> |with variables,
> |although it would enable some very obfuscated code...
>
> I don't understand this, actually.
A string variable could expand to a subexpre
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
> 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
Hi Carsten,
> > 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 `anything' might now look like the continuation of
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
Hi Denis,
> 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 e
Hi Carsten,
> > 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
> > matching possibilities.
>
> But why not as a first step keep the old syn
Hi Steffen,
> Yes! Ralph likes it!
> (Good not to hear any technical objection!)
That's the wrong conclusion to draw. :-) I just didn't see the point
in picking over the syntax for a string-OR given what I think is the
bigger issue.
Cheers, Ralph.
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.
27 matches
Mail list logo
