Hi,
> > 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 above example to <text markup-cmd> but he
> wanted <\cmd{text> markup-cmd>.
Not necessarily. Mappings are intended to map characters to letters.
The above mapping says that all characters matching `\1' should be
recursively mapped onto letters but these new letters should have the
additional property (:markup cmd).
Thus it would be possible to map with the following declarations
(define-mapping "\cmd{(.*)}" "\1"
:with-property (:markup cmd))
(define-mapping "\foo{(.*)}" "\1"
:with-property (:markup foo))
the string
"\cmd{bar\foo{baz}fasel"
into the letter sequence
<b (:markup cmd)><a (:markup cmd)><r (:markup cmd)>
<b (:markup foo)><a (:markup foo)><z (:markup foo)> (*)
<f (:markup cmd)><a (:markup cmd)><s (:markup cmd)>
<e (:markup cmd)><l (:markup cmd)>
(*) here it depends if the inner property overrides the outer one,
which seems to be most useful in most cases.
We would be able to assign markup not only to the whole keyword as in
the example below, but rather for arbitrary subsequences.
> > 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.
I generally agree. My intention was to ask if such a scheme would
suffice in most cases. We actually discuss *only* the TeX-specific
frontend and I think that your approach following a keyword-value pair
of specifications seems to be the most appropriate one.
Follwing this style we must be able to parse *all* keyword-value pairs
in the [...] notation of the \indexindy command.
\indexindy[markup=foo,...]
could then be written to the indexentry
(indexentry :markup "foo" ... )
and I would extend the markup scheme to be able to dispatch on this
argument as well.
But to make the system acceptable for most users it is really
necessary to allow the defintion of macros that can be used as
shortcuts, which you already mentioned some mails ago.
> > 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
> key?
See above. I'm currently not sure if its really necessary. For this
reason I wanted to ask all others out there if they were satisfied
with such a solution. We *must* offer one. But which one?
Bye.
--
======================================================================
Roger Kehr kehr@iti.informatik.th-darmstadt.de
Computer Science Department Technical University of Darmstadt