--===============6140940765880871782== Content-Type: multipart/alternative; boundary=001a11c3c970f7979004f32f3874 --001a11c3c970f7979004f32f3874 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 25, 2014 at 2:23 AM, Dominik Haumann wrote: > 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? > May be, it does (many things make sense is this situation), but it is not what we actually have. AFAIU, you propose to highlight all qt stuff as dsExtension. On the other hand, Matthew proposed (and Milian committed: v4.10.90-857-g07bc7ed) another scheme where Qt keywords are dsKeyword and Qt types and functions are dsDataType and dsFunction accordingly. We should at least arrive at a consensus where dsExtension is used, right? > > Greetings, > Dominik > _______________________________________________ > KWrite-Devel mailing list > KWrite-Devel@kde.org > https://mail.kde.org/mailman/listinfo/kwrite-devel > --001a11c3c970f7979004f32f3874 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 25, 2014 at 2:23 AM, Dominik Haumann <dhaumann@kde.org> wrote:
On Tuesday 25 F= ebruary 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 recogn= ized by
> >> list-based lookup. If so, I don't understand the dsExtens= ion rule. Many
> >> things can be an extension, not just a keyword, but also a co= ntrol flow
> >> (e.g. Qt "foreach"), a data type, variable or funct= ion 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" att= ribute. 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. (Bu= t
> > Q_FOREACH I believe uses "extensions".) So while your p= oint is valid, FWIW
> > a simple dsExtension matches existing usage.
> >
> > I see dsExtension as more of a "language extensions", n= ot just things
> > implemented by some library (e.g. not functions, and probably not= data
> > types either). IOW, things like signals, SIGNAL, slots, SLOT, con= nect
> > (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 cla= rifying
> how everything is, but what I really meant to ask was: how it should b= e? Is
> it really good that "int" and "uint" are highlight= ed in exactly the same
> way? If we are going to use C++/Qt scheme by default it is important t= o
> make it comfortable for all C++ programmers. A beginner in C++, who kn= ows
> nothing about Qt, can type "uint" and believe that everythin= g is ok since
> it is highlighted like a standard type. Yes, we've already said th= at Kate
> is neither semantic nor even a syntactic analyzer, and that among grea= t
> number of thing that look good only few can compile (and e= ven 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&= #39;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 highlighte= d 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 d= efault
language construct/type/variable/object/whatever, instead, it's somethi= ng that
is just added by some other toolkit/addon or similar'. From this perspe= ctive,
it makes even less sense to add multiple extension default styles, since th= en
a user first has to get this sorted out what all the different colors imply= .

Does that make sense?

May be, it does (= many things make sense is this situation), but it is not what we actually h= ave. AFAIU, you propose to highlight all qt stuff as dsExtension. On the o= ther hand, Matthew proposed (and Milian committed: v4.10.90-857-g07bc7ed) a= nother scheme where Qt keywords are dsKeyword and Qt types and functions ar= e dsDataType and dsFunction accordingly. We should at least arrive at a con= sensus where dsExtension is used, right?
=A0

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

--001a11c3c970f7979004f32f3874-- --===============6140940765880871782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KWrite-Devel mailing list KWrite-Devel@kde.org https://mail.kde.org/mailman/listinfo/kwrite-devel --===============6140940765880871782==--