[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: texinfo to docbook - enhancement request
From: |
Patrice Dumas |
Subject: |
Re: texinfo to docbook - enhancement request |
Date: |
Thu, 6 Feb 2014 23:52:01 +0100 |
User-agent: |
Mutt/1.5.20 (2009-12-10) |
On Thu, Feb 06, 2014 at 07:11:08PM +0000, Karl Berry wrote:
> Hi Arnold,
>
> @cindex main topic, secondary point, tertiary point
> ...
> <indexterm><primary>main topic</primary><secondary>secondary
> point</secondary><tertiary>tertiary
> point</tertiary></secondary></primary></indexterm>
>
> Anyway, as a workaround for your immediate needs, maybe Patrice can
> point you to a hook into the Docbook output where you can tinker with
> the index output easily enough. Patrice?
That's not easy for 2 reasons. The first one is that there are no hooks
to customize DocBook output in general. This means in practice that you
have to change the code directly (_index_entry function in
Texinfo/ConvertDocBook). The second one is that since it is not a
Texinfo language feature, the tree that represents the output treats the
commas as text. So, maybe the best would be to manipulate the tree to
split the $index_entry->{'content'} at commas, and then convert each
split contents. There are two functions in Texinfo/Common.pm that may
be used to modify the tree, copy_tree(), to copy the tree to avoid
modifying the original tree, and modify_tree() that can be used to
modify 'args' and 'contents' in tree. For example, it is used to
modify a tree representation of
A: b
to
address@hidden:} b
through the function protect_colon_in_tree.
This would be maybe more robust, as it would handle better nested
@commands for instance, but this is not that easy to code.
Of course you can also use a simple regexp to add elements at commas
in _index_entry.
> (BTW, if it were me, I would not use commas, because commas are often
> used in index entries without any desire for subterms. Even when the
> index does support subterms. Some magic character like | seems like it
> would be better. But of course for real support one would want
> @commands anyway.)
I think that this issue really needs to be solved at the Texinfo
language level.
--
Pat