On Tuesday 25 February 2014 01:41:30 Andrey Matveyakin wrote:
> On Mon, Feb 24, 2014 at 7:56 PM, Matthew Woehlke <
> 
> mw_triad@users.sourceforge.net> wrote:
> > On 2014-02-23 16:41, Andrey Matveyakin wrote:
> >> Ok, I see that dsDataType and dsFunction are sometimes recognized by
> >> list-based lookup. If so, I don't understand the dsExtension rule. Many
> >> things can be an extension, not just a keyword, but also a control flow
> >> (e.g. Qt "foreach"), a data type, variable or function defined in a
> >> library. Which will be marked as dsExtension? All of them or only
> >> non-control-flow-like-keyword ones?
> > 
> > If you look at C++ there is already an "extensions" attribute. This is
> > used for e.g. signals, connect, but not Qt control flow (foreach) or types
> > (uint), which use the same attribute as built-in of the same. (But
> > Q_FOREACH I believe uses "extensions".) So while your point is valid, FWIW
> > a simple dsExtension matches existing usage.
> > 
> > I see dsExtension as more of a "language extensions", not just things
> > implemented by some library (e.g. not functions, and probably not data
> > types either). IOW, things like signals, SIGNAL, slots, SLOT, connect
> > (although this one is dubious), Q_OBJECT, Q_CONSTEXPR, Q_OVERRIDE, etc..
> 
> Now it clear that I've posed the wrong question. Thank you for clarifying
> how everything is, but what I really meant to ask was: how it should be? Is
> it really good that "int" and "uint" are highlighted in exactly the same
> way? If we are going to use C++/Qt scheme by default it is important to
> make it comfortable for all C++ programmers. A beginner in C++, who knows
> nothing about Qt, can type "uint" and believe that everything is ok since
> it is highlighted like a standard type. Yes, we've already said that Kate
> is neither semantic nor even a syntactic analyzer, and that among great
> number of thing that look good only few can compile (and even fewer --
> work). But still: is this behavior more helpful than confusing? I'm not
> sure.
> 
> Sorry for nonconstructive criticism. The only alternative seems to
> introduce separate dsExtensionKeyword, dsExtensionControlFlow,
> dsExtensionFunction, dsExtensionDataType, and so on, which is probably too
> complicated both for us and for users. Or may be, it's not. I don't know.
> 
> Am I the only one who feels it is odd that only keyword extensions are
> highlighted separately? If yes, let's just close the topic.

From what I can tell, having Q_*, connect, disconnect, etc highlighted by
one single colors was never a problem the last 10 years. I wouldn't go so
far to add extension variants for all default styles.

Maybe it helps to look at it from a user's perspective: Looking at some code, 
you see the extension color. What you then know is 'Ah, this is not a default 
language construct/type/variable/object/whatever, instead, it's something that 
is just added by some other toolkit/addon or similar'. From this perspective, 
it makes even less sense to add multiple extension default styles, since then 
a user first has to get this sorted out what all the different colors imply.

Does that make sense?

Greetings,
Dominik
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel