[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: qt4.xml -> qt.xml
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2014-03-03 16:29:54
Message-ID: lf2alk$8nd$1 () ger ! gmane ! org
[Download RAW message or body]

On 2014-03-01 14:01, Alex Turbov wrote:
> unfortunately due a birth trauma of the syntax highlighting engine "keeping
> clean" is impossible in that way...
>
> try this snippet to see the difference:
>
> #if 0
> QString some;
> #else
> QString some;
> #endif
>
> #if 1
> QString some;
> #else
> QString some;
> #endif
>
>
> it is not as simple as "just includeRule" of the ISO C++ to extend the
> "pure C++ syntax" w/ some new highlightings...
> and that complexity turns into impossibility w/ growing count of
> includeRules and different contexts from different files...
> unfortunately current engine is not flexible enough to make a "pure"
> syntaxes and "reuse" them...
> for example it is impossible to reuse any other syntaxes inside a doxygen's
> block comment like this:
>
> /**
>   * \dot
>   * <try to highlight this as `dot`> -- > FAIL!
>   * \endcode
>   */

This is a problem with reST in CMake, also, e.g.:

#.rst
# Hi, I am reST...
#
# But this::
#   Has no hope of correct highlighting :-(

...and I seem to recall at least one other case where similar issues 
apply. We need a way to highlight a block of text such that a known 
prefix string (regexp?) is removed from the line *before* applying HL 
rules. (This prefix stripping would further need to adjust column counts 
and other beginning-of-line like matching rules.)

> includeRule brings complexity to color settings dialog, which is ugly and
> hard to use even w/ less colors count.

And this is also a problem. *Some* of it would be fixed by forcing 
'default' to fall back on the non-included colors so that one doesn't 
need to change an HL's colors for every HL that includes it. It would 
probably help to be able to apply 'default' to an entire included HL in 
one go, and to be able to collapse (and maybe have collapsed by default) 
the entries for the same.

Oh, and an 'apply these colors to parent HL' would be nice.

> - why should I set C++ colors when I want to set some colors for CMake?
> - why not to "reuse" true C++ colors I've already have?

**YES!** See above.

(But note, there are cases where the user may want different colors for 
a "nested" vs. "stand alone" HL. I don't think we should remove this 
ability, just make it much easier to not use it and not have to set 
colors for the same role in so many places.)

> - how to really reuse various syntaxes? for example doxygen can support
> dot, msc, latex... nothing from this list can be used! not talking about
> "dynamic" includeRule to highlight @code/@endcode w/ style of the current
> document...

As I've suggested before, I think it would be helpful to allow injecting 
rules into an included HL. This should be done in a way that "fixes" 
your PP example above...

> * to have an ability to choose what extensions to use for particular
> language.

...and should be implemented in conjunction with this.

> * to have ability to see an interactive code snippet of the target language
> when setting some colors instead (in addition to) of a list of named items

This is an *enormous* amount of work. Each HL would have to provide an 
example text snippet that would have to be carefully maintained for this 
to work.

I think we should start first with an *optional* example text that 
katepart could present and highlight when fiddling with the colors (so 
it would be unsightly if it gets out of date, but wouldn't make color 
configuration actively unusable), and second build tools to verify the 
completeness of such.

-- 
Matthew

_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]