Hello,
On Thu, Nov 20 2014 at 07:46:16 PM, Werner LEMBERG wrote:
> wl pushed a commit to branch master
> in repository groff.
>
> commit 6360d7c66deea677de7260e1efacfce3daa55d85
> Author: Eli Zaretskii
> Date: Thu Nov 20 19:45:17 2014 +0100
>
> Improve native Windows port.
>
> Thi
> My vote for the syntax of these "extended expressions" is to simply
> enclose them in brackets:
>
> .nr i [3+4*6]
> .if ['\\$1'abc':\\n[.$]=0] stuff
>
> I believe this feels much more natural than the other suggestions
> offered so far.
Good idea! Since groff introduces \n[...] and frien
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
> When building at revision 6360d7c66deea677de7260e1efacfce3daa55d85
>
> I have this error:
>
> In file included from [...] src/libs/libgroff/color.cpp:23:0:
Mea culpa. I committed the patch without doing a `make depend' before
`make' to regenerate dependencies. This is another thing that your
Hi,
I have a document (using Mom package) that I generated without problem
with the 1.22.2 tarball, but when I used up-to-date groff I encountered
an obscure error. I've wrote a minimal, simpler doc (attached,
test.mom) to reproduce the problem. It seems to me the error occurs
when I put a .FOOT
Hi Carsten,
> But can it be agreed, that it's not specified for historical troff?
Disagree. The venerable CSTR 54.
7.1. ... Request, macro, and string names share the same name
list.
7.4. Diversions. Processed output may be diverted into a macro for
purposes...
So it's not
Hi Steffen,
> |I think his point is[.]
>
> No, it works fine in practice:
My snipped point still stands though, you can't use .substring to get a
zero-length string from a non-empty one.
> > > The current behaviour is an unusable mystery to me personally:
> > > how can you gain a subst
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
Hi Werner,
On Sat, Nov 29 2014 at 03:19:19 PM, Werner LEMBERG wrote:
>> When building at revision 6360d7c66deea677de7260e1efacfce3daa55d85
>>
>> I have this error:
>>
>> In file included from [...] src/libs/libgroff/color.cpp:23:0:
>
> Mea culpa. I committed the patch without doing a `make depe
> 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 *should* be done
> > 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
12 matches
Mail list logo
