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

List:       kwrite-devel
Subject:    Re: Re: Default Styles
From:       Dominik Haumann <dhaumann () kde ! org>
Date:       2014-02-18 8:39:32
Message-ID: 2707609.7SxfLpCm2u () obiwan
[Download RAW message or body]

On Monday, February 17, 2014 18:11:34 Matthew Woehlke wrote:
> On 2014-02-17 17:09, Milian Wolff wrote:
> > On Monday 17 February 2014 22:43:08 Dominik Haumann wrote:
> >> Numbers
> >> ? dsConstant    (new, if needed? maybe M_PI or similar things? not
> >> sure...)
> > 
> > dsConstant could be used for enums in languages which have them. So +1
> > from my side.
> 
> ...and probably in e.g. Python this could be used for True, None, etc.
> And probably more like true, nullptr, etc. in C++, since I don't know
> how you would tell the difference between macros that really are
> constants vs. annotations vs. something else.
> 
> And maybe CMake should use it for e.g. built-in variable names.

Still not sure about dsConstant. In C++ it doesn't make much sense.

Instead, I added dsBoolean, see next mail.

> >> ? dsDeprecated  (new: maybe for deprecated stuff?)
> > 
> > Similar to extension, this is more of an "on-top" attribute. I.e. I'd
> > expect a deprecated data type to look still look like a data type, but
> > the same would apply to a function etc. pp. So maybe we need a new
> > concept for such attributes? Deprecated could add a strike-through
> > effect. Extensions could change the color. Suggestions anyone?
> 
> If you're going that route, you don't need a default attribute; just
> specify strikeout in the attribute of the HL.
> 
> >> Notifications
> >> - dsError
> >> - dsAlert
> >> ? dsPositive    (new, e.g. NOTE)
> >> ? dsInformation (new, e.g. TODO)
> >> ? dsWarning     (new, HACK, ###, FIXME)
> > 
> > Imo, dsAlert + dsError are enough, no? HACK, FIXME, ### are imo dsError's.
> > Note and TODO are dsAlerts.
> 
> No they aren't. dsError is a syntax error (red with underline). dsAlert
> is red background (like the pen-and-paper sense of "highlight").
> 
> Since some time alert.xml started differentiating three categories of
> alert; the above (but see my reply re: dsPositive) would simply give
> those existing categories default attributes.
> 
> Currently, dsError is mostly reserved for when the HL either knows that
> you've written something that isn't valid, or goes bork, and IMO that's
> the way it should be.

I also disagree. Think for instance of:

/**
 * @note      (I think of dsInformation)
 * @warning   (I think of dsWarning)
 * @todo      (I'd be fine with dsAlert in this case, see screenshot:
 */

See: http://wstaw.org/m/2014/02/18/plasma-desktopNi3141.png

I wouldn't want all of these to have the dsAlert highlighting, which is pretty 
bold in the face. I'll move these to the Comments & Documentation section.

Greetings,
Dominik
_______________________________________________
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]