[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: qt4.xml -> qt.xml
From: Alex Turbov <i.zaufi () gmail ! com>
Date: 2014-03-01 19:01:38
Message-ID: CANktQtswRe8wAprGZ4tjSnkfmVmnw4_62WzZRuf_YWkPM_WOBA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
*/
same problems w/ bash syntax: it actually can't be reused reliably!
includeRule brings complexity to color settings dialog, which is ugly and
hard to use even w/ less colors count. recent "troubles" w/ cmake is a
signal to rethink and redesign this engine... w/ more syntaxes, things
getting more and more complicated. the problem is not in a broken colors I
saw, but in a more reasonable questions:
- 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?
- 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...
personally I want:
* to have an ability to choose what extensions to use for particular
language. for example in a treeview of "Highlighting and Text Styles" it
would be nice to have check boxes w/ boost, gcc, clang specifics... or
radiobuttons for Qt4, Qt5, Qt5+Qt4. I' thinking about "conditional"
includeRules to implement this... and some new XML tags to describe a
choice options...
* 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
-- so clicking to some part of that snippet (for example to a keyword or
string) shows me a color chooser dialog to change corresponding color (and
bold/itallic/etc) -- to implement this syntax file should (may) contains a
tag w/ CDATA w/ a code snipped to be displayed at colors configure time
provided by syntax authors... if no such tag, colors can be choosed by
selecting an item in a tree view (like we have it nowadays)...
... I'm still think about particular details "in background"... it is why
I'm not interested to change anything in my environment now and in case of
your changes I'll move my further improvements to C++ syntax back to
kde-files.org... particularly I want to add some neat feature for
preprocessor and maybe introduce a separate qt5 syntax (probably w/ qt4
marked as deprecated)...
On Sat, Mar 1, 2014 at 10:40 PM, Christoph Cullmann <cullmann@absint.com>wr=
ote:
> Hi,
>
> looking in more detail on the isocpp.xml file, I think other stuff could
> be moved from isocpp.xml
> to cpp.xml:
>
> 1) The GCC extension stuff, that's no std c++, either
> 2) The BOOST stuff, which is just like Qt some "common" used C++ library
> (even if some future standard things are drafted there)
>
> Greetings
> Christoph
>
> ----- Urspr=FCngliche Mail -----
> > > > Thats already implemented like that with cpp.xml, no?
> > > Yeah, I would only make it more clear, that we shall have a "big
> > > full-featured"
> > > C++ as default, which might include more than Qt in the long run, e.g=
.
> > > boost
> > > stuff
> > > or so and call that C++ with a high prio and have some stripped down
> > > "isocpp.xml" which
> > > by definition SHALL NOT contain any custom extensions.
> > >
> > > Would that be ok for you Alex, to still share work on the isocpp.xml
> file
> > > (and
> > > have a own extended one)?
> > See my change:
> >
> > Git commit 8c835073cf447cce8f87c9c63f15cde753acf128 by Christoph
> Cullmann.
> > Committed on 01/03/2014 at 17:54.
> > Pushed by cullmann into branch 'master'.
> >
> > do it the other way around: keep an clean 'ISO C++' highlighting which
> SHALL
> > NOT CONTAIN ANY NON-C++ STANDARD (or ucoming standard) EXTENSIONS and
> have
> > per default a 'full-featured' C++ highlighting that MAY contain more
> > extensions like Qt, Boost, ....
> >
> > M +1 -1 src/script/data/indentation/cppstyle.js
> > M +1 -1 src/script/data/indentation/cstyle.js
> > M +1574 -464 src/syntax/data/cpp.xml
> > C +3 -3 src/syntax/data/isocpp.xml [from: src/syntax/data/cpp.xm=
l
> -
> > 099% similarity]
> > D +0 -1606 src/syntax/data/qt4.xml
> >
> >
> http://commits.kde.org/ktexteditor/8c835073cf447cce8f87c9c63f15cde753acf1=
28
> >
> >
> > --
> > ----------------------------- Dr.-Ing. Christoph Cullmann ---------
> > AbsInt Angewandte Informatik GmbH Email: cullmann@AbsInt.com
> > Science Park 1 Tel: +49-681-38360-22
> > 66123 Saarbr=FCcken Fax: +49-681-38360-20
> > GERMANY WWW: http://www.AbsInt.com
> > --------------------------------------------------------------------
> > Gesch=E4ftsf=FChrung: Dr.-Ing. Christian Ferdinand
> > Eingetragen im Handelsregister des Amtsgerichts Saarbr=FCcken, HRB 1123=
4
> > _______________________________________________
> > KWrite-Devel mailing list
> > KWrite-Devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kwrite-devel
> >
>
> --
> ----------------------------- Dr.-Ing. Christoph Cullmann ---------
> AbsInt Angewandte Informatik GmbH Email: cullmann@AbsInt.com
> Science Park 1 Tel: +49-681-38360-22
> 66123 Saarbr=FCcken Fax: +49-681-38360-20
> GERMANY WWW: http://www.AbsInt.com
> --------------------------------------------------------------------
> Gesch=E4ftsf=FChrung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbr=FCcken, HRB 11234
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel
>
[Attachment #5 (text/html)]
<div dir="ltr"><div><div><div><div><div><br><div class="gmail_extra">unfortunately \
due a birth trauma of the syntax highlighting engine "keeping clean" is \
impossible in that way...<br><br></div><div class="gmail_extra"> try this snippet to \
see the difference:<br><br>#if 0<br>QString some;<br>#else<br>QString \
some;<br>#endif<br><br>#if 1<br>QString some;<br>#else<br>QString \
some;<br>#endif<br><br><br></div><div class="gmail_extra">it is not as simple as \
"just includeRule" of the ISO C++ to extend the "pure C++ syntax" \
w/ some new highlightings...<br> </div><div class="gmail_extra">and that complexity \
turns into impossibility w/ growing count of includeRules and different contexts from \
different files...<br></div><div class="gmail_extra">unfortunately current engine is \
not flexible enough to make a "pure" syntaxes and "reuse" \
them...<br> </div><div class="gmail_extra">for example it is impossible to reuse any \
other syntaxes inside a doxygen's block comment like \
this:<br><br>/**<br></div><div class="gmail_extra"> * \dot<br></div><div \
class="gmail_extra">
* <try to highlight this as `dot`> -- > FAIL!<br></div><div \
class="gmail_extra"> * \endcode<br> */<br></div><br></div><div>same problems w/ bash \
syntax: it actually can't be reused reliably!<br></div><div><br> includeRule
brings complexity to color settings dialog, which is ugly and hard to
use even w/ less colors count. recent "troubles" w/ cmake is a signal to \
rethink and redesign this engine... w/ more syntaxes, things getting more and more \
complicated. the problem is not in a broken colors I saw, but in a more reasonable \
questions: <br>
- why should I set C++ colors when I want to set some colors for CMake? <br>- why not \
to "reuse" true C++ colors I've already have? <br></div>- 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...<br> <br></div>personally \
I want:<br><br></div>* to have an ability to choose what extensions to use for \
particular language. for example in a treeview of "Highlighting and Text \
Styles" it would be nice to have check boxes w/ boost, gcc, clang specifics... \
or radiobuttons for Qt4, Qt5, Qt5+Qt4. I' thinking about "conditional" \
includeRules to implement this... and some new XML tags to describe a choice \
options...<br> <br></div>* 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 -- so clicking to some part of that snippet (for example to a keyword or \
string) shows me a color chooser dialog to change corresponding color (and \
bold/itallic/etc) -- to implement this syntax file should (may) contains a tag w/ \
CDATA w/ a code snipped to be displayed at colors configure time provided by syntax \
authors... if no such tag, colors can be choosed by selecting an item in a tree view \
(like we have it nowadays)...<br> <br></div>... I'm still think about particular \
details "in background"... it is why I'm not interested to change \
anything in my environment now and in case of your changes I'll move my further \
improvements to C++ syntax back to kde-files.org... particularly I want to add some \
neat feature for preprocessor and maybe introduce a separate qt5 syntax (probably w/ \
qt4 marked as deprecated)...<br> \
<br><div><br><div><div><div><div><br><br><br></div></div></div></div></div></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 1, 2014 at 10:40 PM, \
Christoph Cullmann <span dir="ltr"><<a href="mailto:cullmann@absint.com" \
target="_blank">cullmann@absint.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi,<br> <br>
looking in more detail on the isocpp.xml file, I think other stuff could be moved \
from isocpp.xml<br> to cpp.xml:<br>
<br>
1) The GCC extension stuff, that's no std c++, either<br>
2) The BOOST stuff, which is just like Qt some "common" used C++ library \
(even if some future standard things are drafted there)<br> <br>
Greetings<br>
Christoph<br>
<br>
----- Ursprüngliche Mail -----<br>
<div class="HOEnZb"><div class="h5">> > > Thats already implemented like \
that with cpp.xml, no?<br> > > Yeah, I would only make it more clear, that we \
shall have a "big<br> > > full-featured"<br>
> > C++ as default, which might include more than Qt in the long run, e.g.<br>
> > boost<br>
> > stuff<br>
> > or so and call that C++ with a high prio and have some stripped down<br>
> > "isocpp.xml" which<br>
> > by definition SHALL NOT contain any custom extensions.<br>
> ><br>
> > Would that be ok for you Alex, to still share work on the isocpp.xml \
file<br> > > (and<br>
> > have a own extended one)?<br>
> See my change:<br>
><br>
> Git commit 8c835073cf447cce8f87c9c63f15cde753acf128 by Christoph Cullmann.<br>
> Committed on 01/03/2014 at 17:54.<br>
> Pushed by cullmann into branch 'master'.<br>
><br>
> do it the other way around: keep an clean 'ISO C++' highlighting which \
SHALL<br> > NOT CONTAIN ANY NON-C++ STANDARD (or ucoming standard) EXTENSIONS and \
have<br> > per default a 'full-featured' C++ highlighting that MAY contain \
more<br> > extensions like Qt, Boost, ....<br>
><br>
> M +1 -1 src/script/data/indentation/cppstyle.js<br>
> M +1 -1 src/script/data/indentation/cstyle.js<br>
> M +1574 -464 src/syntax/data/cpp.xml<br>
> C +3 -3 src/syntax/data/isocpp.xml [from: src/syntax/data/cpp.xml -<br>
> 099% similarity]<br>
> D +0 -1606 src/syntax/data/qt4.xml<br>
><br>
> <a href="http://commits.kde.org/ktexteditor/8c835073cf447cce8f87c9c63f15cde753acf128" \
target="_blank">http://commits.kde.org/ktexteditor/8c835073cf447cce8f87c9c63f15cde753acf128</a><br>
><br>
><br>
> --<br>
> ----------------------------- Dr.-Ing. Christoph Cullmann ---------<br>
> AbsInt Angewandte Informatik GmbH Email: cullmann@AbsInt.com<br>
> Science Park 1 Tel: +49-681-38360-22<br>
> 66123 Saarbrücken Fax: +49-681-38360-20<br>
> GERMANY WWW: <a href="http://www.AbsInt.com" \
target="_blank">http://www.AbsInt.com</a><br> > \
--------------------------------------------------------------------<br> > \
Geschäftsführung: Dr.-Ing. Christian Ferdinand<br> > Eingetragen im \
Handelsregister des Amtsgerichts Saarbrücken, HRB 11234<br> > \
_______________________________________________<br> > KWrite-Devel mailing \
list<br> > <a href="mailto:KWrite-Devel@kde.org">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> ><br>
<br>
--<br>
----------------------------- Dr.-Ing. Christoph Cullmann ---------<br>
AbsInt Angewandte Informatik GmbH Email: cullmann@AbsInt.com<br>
Science Park 1 Tel: +49-681-38360-22<br>
66123 Saarbrücken Fax: +49-681-38360-20<br>
GERMANY WWW: <a href="http://www.AbsInt.com" \
target="_blank">http://www.AbsInt.com</a><br>
--------------------------------------------------------------------<br>
Geschäftsführung: Dr.-Ing. Christian Ferdinand<br>
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234<br>
_______________________________________________<br>
KWrite-Devel mailing list<br>
<a href="mailto:KWrite-Devel@kde.org">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>
_______________________________________________
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