> True. Denis has a point though, it would be nice to use new syntax
> for things like `.nr'.
Example, please.
> I'd favour mandatory braces and no parenthesis around the condition.
OK.
> Must we keep the cluttered `\{\' with the new syntax? What if the
> open brace indicated multi-line form
Ping!
> Date: Mon, 10 Nov 2014 17:08:21 +0200
> From: Eli Zaretskii
> Cc: groff@gnu.org
>
> > Date: Sun, 09 Nov 2014 08:46:21 +0100 (CET)
> > Cc: groff@gnu.org
> > From: Werner LEMBERG
> >
> >
> > >> I was imagining something primitive, e.g. a working equivalent to
> > >>
> > >> #if define
Hi Werner,
> > Would it? That form could reject backwards compatibility; only new
> > format allowed, just as after .iff. I don't see why old syntax has
> > to be handled if it currently makes no sense to use `E' after the
> > `('.
>
> Well, using (E;...) everywhere is tedious.
True. Denis h
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
> Maybe I'm missing something, but from here it looks possible.
> True, you need a stack, but not very much, and no look-ahead.
> [...]
Indeed, if you terminate the block with an explicit "endif",
this will be no problem. But it might create new ones.
For example: will groff need to parse the wh
For the sake of othogonality and convenience it would be good to have
extended expressions usable anywhere an expression is required.
What about a new read/write number register ext to indicate how
expressions are to be interpreted?
DEnis
On Mon, 17 Nov 2014 09:22:54 +0100 (CET)
Werner LEMBERG w
>> But (E; expr) would cover only a minor subset of possible improvements
>> – it would be still necessary to provide backwards compatibility.
>
> Would it? That form could reject backwards compatibility; only new
> format allowed, just as after .iff. I don't see why old syntax has to
> be han
>>> 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.
>
> Is it worth adding as a feature request in the tracker? It would
> seem better to have this func
