[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: Default Styles in KF5
From: Andrey Matveyakin <a.matveyakin () gmail ! com>
Date: 2014-02-24 23:20:51
Message-ID: CAACAhstE6crLdGCco=dyVZR0xbHcNtsr=w78ZMF8zSBNS_5bAQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Feb 25, 2014 at 2:23 AM, Dominik Haumann <dhaumann@kde.org> 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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 25, 2014 \
at 2:23 AM, Dominik Haumann <span dir="ltr"><<a href="mailto:dhaumann@kde.org" \
target="_blank">dhaumann@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div>On Tuesday 25 February 2014 01:41:30 \
Andrey Matveyakin wrote:<br> > On Mon, Feb 24, 2014 at 7:56 PM, Matthew Woehlke \
<<br> ><br>
> <a href="mailto:mw_triad@users.sourceforge.net" \
target="_blank">mw_triad@users.sourceforge.net</a>> wrote:<br> > > On \
2014-02-23 16:41, Andrey Matveyakin wrote:<br> > >> Ok, I see that \
dsDataType and dsFunction are sometimes recognized by<br> > >> list-based \
lookup. If so, I don't understand the dsExtension rule. Many<br> > >> \
things can be an extension, not just a keyword, but also a control flow<br> > \
>> (e.g. Qt "foreach"), a data type, variable or function defined in \
a<br> > >> library. Which will be marked as dsExtension? All of them or \
only<br> > >> non-control-flow-like-keyword ones?<br>
> ><br>
> > If you look at C++ there is already an "extensions" attribute. \
This is<br> > > used for e.g. signals, connect, but not Qt control flow \
(foreach) or types<br> > > (uint), which use the same attribute as built-in of \
the same. (But<br> > > Q_FOREACH I believe uses "extensions".) So \
while your point is valid, FWIW<br> > > a simple dsExtension matches existing \
usage.<br> > ><br>
> > I see dsExtension as more of a "language extensions", not just \
things<br> > > implemented by some library (e.g. not functions, and probably \
not data<br> > > types either). IOW, things like signals, SIGNAL, slots, SLOT, \
connect<br> > > (although this one is dubious), Q_OBJECT, Q_CONSTEXPR, \
Q_OVERRIDE, etc..<br> ><br>
> Now it clear that I've posed the wrong question. Thank you for \
clarifying<br> > how everything is, but what I really meant to ask was: how it \
should be? Is<br> > it really good that "int" and "uint" are \
highlighted in exactly the same<br> > way? If we are going to use C++/Qt scheme by \
default it is important to<br> > make it comfortable for all C++ programmers. A \
beginner in C++, who knows<br> > nothing about Qt, can type "uint" and \
believe that everything is ok since<br> > it is highlighted like a standard type. \
Yes, we've already said that Kate<br> > is neither semantic nor even a \
syntactic analyzer, and that among great<br> </div></div>> number of thing that \
look good only few can compile (and even fewer --<br> <div>> work). But still: is \
this behavior more helpful than confusing? I'm not<br> > sure.<br>
><br>
> Sorry for nonconstructive criticism. The only alternative seems to<br>
> introduce separate dsExtensionKeyword, dsExtensionControlFlow,<br>
> dsExtensionFunction, dsExtensionDataType, and so on, which is probably too<br>
> complicated both for us and for users. Or may be, it's not. I don't \
know.<br> ><br>
> Am I the only one who feels it is odd that only keyword extensions are<br>
> highlighted separately? If yes, let's just close the topic.<br>
<br>
</div>From what I can tell, having Q_*, connect, disconnect, etc highlighted by<br>
one single colors was never a problem the last 10 years. I wouldn't go so<br>
far to add extension variants for all default styles.<br>
<br>
Maybe it helps to look at it from a user's perspective: Looking at some code,<br>
you see the extension color. What you then know is 'Ah, this is not a default<br>
language construct/type/variable/object/whatever, instead, it's something \
that<br> is just added by some other toolkit/addon or similar'. From this \
perspective,<br> it makes even less sense to add multiple extension default styles, \
since then<br> a user first has to get this sorted out what all the different colors \
imply.<br> <br>
Does that make sense?<br></blockquote><div><br></div><div>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?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Greetings,<br>
Dominik<br>
<div><div>_______________________________________________<br>
KWrite-Devel mailing list<br>
<a href="mailto:KWrite-Devel@kde.org" target="_blank">KWrite-Devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
</div></div></blockquote></div><br></div></div>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic