Book logo xindy

A Flexible Indexing System

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: \indexindy and sorting rules


> 1. A mapping is based on string or regexp-transformations (such as the
>    current sort-rules) but extended with mapping rules.

>    Informally we could say that "\index" must be written as
>    "\cmd{index}" and there is a mapping rule that says

Well, I think the user shouldn't have to write such special things.
This may cause errors and confusion. Imagine, a user want's
to index the sequence \cmd{text}. 

> 	(define-mapping "\cmd{(.*)}" "\1"
> 		:with-property (:markup cmd))

So this will convert the obove example to <text markup-cmd> but he
wanted <\cmd{text> markup-cmd>.

> 2. We try to tackle the problem the other way around. This concerns
>    the discussion about \indexindy command. Something like

> 	\indexindy[markup=texttt,...]{foo}

>    instead of

> 	\indexindy[...]{\texttt{foo}}

>    could solve the problem.

This one sounds much handier to me. The user hasn't to worry about
nested \cmds AND the key is totally independant of the markup.

>    Markup is not embedded in the plain keyword. A scanner is not
>    necessary anymore. Markup can be done in the markup-backend with
>    something like

> 	(markup-keyword :markup "texttt" :open "\texttt{" :close "}")

>    This would effectively yield the same results. It suffers from the
>    fact that not more than one markup can be associated with a
>    keyword, which seems be the case rarely.

Wouldn't this (not more than one markup) also last for the first version? 
AND, is it really necessary to allow different markup for the SAME

Bye, Andi