Re: [Kile-devel] Questions about latex.xml, v1.55

[Thomas B. <tho...@vi...>]

Hi Justin (CC to kile-devel),

I did some coding in latex.xml in the last couple of years and just saw
your post.


> 1. I think "\input" should be grouped with "\include" and 
> "\documentclass", not "\vspace", since it also has to do with file 
> inclusion.

>From a sematic point of view definitly, but as 89a36fa5 in the kate repo looks this was
done for the spell checker.

> 2. I noticed the context for arguments to "\newcommand" and friends was 
> switched to "LabelParameter" instead of "CommandParameter".  I recently 
> added a new itemData, "Reference", to be used by LabelParameter, since I 
> like to see clearly where my \label and \ref commands are used.  So I 
> think it makes more sense to keep the context for labels/refs separate 
> from the context for \newcommand instead of allowing them to share a 
> context.

I definitly agree here!

> 3. Following (2), could we introduce a new itemData, say "Definitions", 
> to handle the specific case of arguments to \def and \newcommand?  For 
> example, I've been using stable Kate from KDE 4.8.5 (latex.xml version 
> 1.48), in which arguments to \newcommand are highlighted as "Normal 
> Text".  Having a "Definitions" style would allow one to give these 
> arguments some distinctive feature, like a colored background, instead 
> of them appearing only as plain text.

Historically \newcommand etc. arguments were never syntax highlighted as it could go easily wrong.
My version 1.55 does highlight \newcommand code as normal latex.

[I took the liberty in pasting your other email here as well]


> 1. Would it be better to use non-capturing groups since no 
> backreferences are (currently) used?

Yes, although that makes reading them a bit harder.

> 2. Should alternations be re-written to avoid duplication?  For example, 
> "\\(newcommand|renewcommand|providecommand)" could instead be written as 
> "\\((re)?new|provide)command".  I realize this may make some of the 
> RegExpr entries unreadable (especially \cite and friends), so why not...

What is the idea behind the renaming? Some performance consideration?

> 3. Use entities for re-used or complex RegExpr searches (\label and 
> friends, \cite and friends)?  For example, for \label, use something like
> 
> [   <!-- RegExpr for \label, \ref, and friends
>           Finds: \subref(*), \cref(*), \Cref(*), \ref(*), \label,
>              \eqref, \pageref, \vpageref, \autoref, \vref, \pagecite
>           followed by non-letter character
>      -->
>      <!ENTITY labelRefCmds 
> "\\((sub|c|C)?ref\*?|label|(eq|v?page|auto|v)?ref|pagecite)(?=[^a-zA-Z])">
> ]

I would really LOVE to see entities used where possible.

> With regard to the engine in general:
> 
> 4. There are many instances of using #pop multiple times in a row.  Is 
> it more efficient to have "less depth" when the engine doesn't need to 
> remember previous contexts?
> For example, when the highlighter finds '\begin{' it moves through this 
> list of contexts:
> 
>     Normal Text                   | context: Normal Text
>     FindBeginEnvironment          | context: Normal 
> Text/FindBeginEnvironment
>     BeginEnvironment              | context: Normal 
> Text/FindBeginEnvironment/BeginEnvironment
>     (some class of environments)  | context: Normal 
> Text/FindBeginEnvironment/BeginEnvironment/(environment class)
> 
> Since FindBeginEnvironment and BeginEnvironment are not used again until 
> the current (environment class) is processed, why not "pop" one 
> environment at each step, like this:
> 
>     Normal Text                        | context: Normal Text
>     FindBeginEnvironment               | context: Normal 
> Text/FindBeginEnvironment
>     #pop!BeginEnvironment              | context: Normal 
> Text/BeginEnvironment
>     #pop!(some class of environments)  | context: Normal 
> Text/(environment class)

I think I can't follow you here.

In general a big overhaul of the latex syntax HL is in my opinion more than due.
As it is really complex, and I always need a lot of time for even the smallest change.

And the first step in an overhaul would be to collect complex, and maybe contrived, examples
how the current syntax highlighting colors things. As it is not really an option to make it simpler
but less powerful. Some automatic testing would be nice for that, although I don't know of a way to do that.

In the kile source directory is a folder internal-testing this holds some examples of contrived latex code.
For example, taken from the syntax examples and a bit modified:
\ensuremath{a+b = \text{asd $1$ asd} {asd} asd } test $test$ % test

Thomas