D27929: CMake syntax fixes

[Alex Turbov]

turbov created this revision.
turbov added a reviewer: Framework: Syntax Highlighting.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
turbov requested review of this revision.

REVISION SUMMARY
  - add some more variables introduced in CMake 3.17
  - allow back-slash characters in bracket comments
  - detect _internal variables first, then built-ins

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D27929

AFFECTED FILES
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/syntax/cmake.xml

To: turbov, #framework_syntax_highlighting
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D27580: Updates for CMake 3.17

[Alex Turbov]

turbov created this revision.
turbov added a reviewer: Framework: Syntax Highlighting.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
turbov requested review of this revision.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D27580

AFFECTED FILES
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/syntax/cmake.xml

To: turbov, #framework_syntax_highlighting
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D25811: cmake: Fix `CMAKE_POLICY_*_CMP` regex and add special args to `get_cmake_property`

[Alex Turbov]

turbov added a comment.


  In D25811#587606 , @cullmann wrote:
  
  > Hi, can you add stuff to the tests or shall we merge this as is?
  
  
  Sorry, I don't have time for this nowadays %(

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D25811

To: turbov, #framework_syntax_highlighting
Cc: cullmann, kwrite-devel, kde-frameworks-devel, LeGast00n, GB_2, domson, 
michaelh, ngraham, bruns, demsking, sars, dhaumann

D25811: cmake: Fix `CMAKE_POLICY_*_CMP` regex and add special args to `get_cmake_property`

[Alex Turbov]

turbov created this revision.
turbov added a reviewer: Framework: Syntax Highlighting.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
turbov requested review of this revision.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D25811

AFFECTED FILES
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov, #framework_syntax_highlighting
Cc: kwrite-devel, kde-frameworks-devel, LeGast00n, GB_2, domson, michaelh, 
ngraham, bruns, demsking, cullmann, sars, dhaumann

D25686: Updates from CMake 3.16 final release

[Alex Turbov]

turbov added a reviewer: Framework: Syntax Highlighting.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D25686

To: turbov, #framework_syntax_highlighting
Cc: kwrite-devel, kde-frameworks-devel, LeGast00n, GB_2, domson, michaelh, 
ngraham, bruns, demsking, cullmann, sars, dhaumann

D25686: Updates from CMake 3.16 final release

[Alex Turbov]

turbov created this revision.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
turbov requested review of this revision.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D25686

AFFECTED FILES
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/syntax/cmake.xml

To: turbov
Cc: kwrite-devel, kde-frameworks-devel, LeGast00n, GB_2, domson, michaelh, 
ngraham, bruns, demsking, cullmann, sars, dhaumann

D22698: Support passing target to ki18n_wrap_ui macro

[Alex Turbov]

turbov added inline comments.

INLINE COMMENTS

> KF5I18nMacros.cmake.in:76
> +  endif()
> endforeach (_current_FILE)
>  endmacro (KI18N_WRAP_UI)

Its _Modern CMake_ :) no need to use that crap anymore %)
(I'm talking about matched `end*()` things %)

REVISION DETAIL
  https://phabricator.kde.org/D22698

To: daandemeyer, ilic
Cc: turbov, cgiboudeaux, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

D22698: Support passing target to ki18n_wrap_ui macro

[Alex Turbov]

turbov added a comment.


  @daandemeyer 
  Cool stuff! :))
  
  one more proposal is to turn it into a function to avoid pollution of the 
outer scope w/ inner used (**and still unset**) variables %)
  Using `set(${RESULT_VAR} "blah-blah" PARENT_SCOPE)` could help to do that %)

REVISION DETAIL
  https://phabricator.kde.org/D22698

To: daandemeyer, ilic
Cc: turbov, cgiboudeaux, kde-frameworks-devel, LeGast00n, sbergeron, michaelh, 
ngraham, bruns

D22340: cmake: bring some missed features

[Alex Turbov]

turbov retitled this revision from "Bring some missed features" to "cmake: 
bring some missed features".

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D22340

To: turbov, #kate, #framework_syntax_highlighting
Cc: ngraham, kwrite-devel, kde-frameworks-devel, LeGast00n, domson, michaelh, 
bruns, demsking, cullmann, sars, dhaumann

D22340: Bring some missed features

[Alex Turbov]

turbov created this revision.
turbov added reviewers: Kate, Framework: Syntax Highlighting.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
turbov requested review of this revision.

REVISION SUMMARY
  - handle `CMAKE_ARGVn` properly
  - add some missed var
  - highlight `$CACHE{...}`

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D22340

AFFECTED FILES
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml
  generators/cmake.xml.tpl
  generators/cmake.yaml

To: turbov, #kate, #framework_syntax_highlighting
Cc: kwrite-devel, kde-frameworks-devel, LeGast00n, domson, michaelh, ngraham, 
bruns, demsking, cullmann, sars, dhaumann

D22095: Fix CMake add_custom_command() paren highlighting

[Alex Turbov]

turbov added a comment.


  I would say all commands w/ `COMMAND` named parameter need that. Also, 
`add_custrom_target` and `execute_process`...

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D22095

To: smokris, #framework_syntax_highlighting, cullmann
Cc: turbov, cullmann, kwrite-devel, kde-frameworks-devel, LeGast00n, gennad, 
bmortimer, domson, michaelh, genethomas, ngraham, bruns, demsking, vkrause, 
sars, dhaumann

D15780: YAML: add literal & folded block styles

[Alex Turbov]

turbov accepted this revision.
turbov added a comment.
This revision is now accepted and ready to land.


  Good job!
  
  @dhaumann,
  
  my +1

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  fix-literal-style-yaml

REVISION DETAIL
  https://phabricator.kde.org/D15780

To: nibags, cullmann, dhaumann, #framework_syntax_highlighting, turbov
Cc: turbov, kwrite-devel, kde-frameworks-devel, michaelh, kevinapavew, ngraham, 
bruns, demsking, cullmann, sars, dhaumann

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov added a comment.


  @cullmann,
  
  Up to you... When I'll fix it for the cases I've found (trying to write the 
`hightlighting.rst` test file) I come back w/ a new PR :)

REVISION DETAIL
  https://phabricator.kde.org/D7245

To: turbov, #kate, #framework_syntax_highlighting, dhaumann, cullmann
Cc: cullmann, dhaumann, #frameworks, michaelh, ngraham, bruns

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov added a comment.


  You can just close this MR, I'll be back sometime later w/ highlighting 
example and tests...

REVISION DETAIL
  https://phabricator.kde.org/D7245

To: turbov, #kate, #framework_syntax_highlighting, dhaumann, cullmann
Cc: cullmann, dhaumann, #frameworks, michaelh, ngraham, bruns

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov marked an inline comment as done.
turbov added a comment.


  I'm using this syntax 'till nowadays from my repo... I know about some not 
covered cases in it, but have no time these days to improve it even more %)
  Most of the time I quite satisfied w/ it... and sorry for the tests :(

REVISION DETAIL
  https://phabricator.kde.org/D7245

To: turbov, #kate, #framework_syntax_highlighting, dhaumann, cullmann
Cc: cullmann, dhaumann, #frameworks, michaelh, ngraham, bruns

D14824: Relicense modelines.xml to MIT license

[Alex Turbov]

turbov accepted this revision.
turbov added a comment.


  I agree w/ relicense

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  relicense-modelines-mit (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D14824

To: dhaumann, vkrause, cullmann, martinwalch, turbov
Cc: kwrite-devel, kde-frameworks-devel, michaelh, kevinapavew, ngraham, bruns, 
demsking, cullmann, sars, dhaumann

D7175: Redesign CMake syntax

[Alex Turbov]

turbov updated this revision to Diff 26933.
turbov added a comment.


  Updates for CMake 3.11

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7175?vs=23100&id=26933

REVISION DETAIL
  https://phabricator.kde.org/D7175

AFFECTED FILES
  data/generators/cmake-gen.sh
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks, michaelh

D7175: Redesign CMake syntax

[Alex Turbov]

turbov added a comment.


  In https://phabricator.kde.org/D7175#202300, @vkrause wrote:
  
  > I'm with Christoph on this. Having the generated code checked in is fine, 
I'd like to avoid running this on compile time due to the extra dependencies.
  
  
  It doesn' needed to run anything @ compile time.
  
  Just to clarify things once again:
  
  - The generator use only YAML as input
  - The YAML file is manually maintained! (cuz grabbing output of `cmake 
--help...` doesn't work well for a long time already)
  - I do updates of YAML w/ every CMake release after reading release notes 
line by line (cuz I do a lot of CMake code in may daily job and use the latest 
version all the time)
  
  If that is OK 4 u guys, I'll commit...

REVISION DETAIL
  https://phabricator.kde.org/D7175

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks, michaelh, ngraham

D7175: Redesign CMake syntax

[Alex Turbov]

turbov added a comment.


  @cullmann , @dhaumann
  
  if there is no intereset, I'll close this review and will distribute my CMake 
syntax in other ways...

REVISION DETAIL
  https://phabricator.kde.org/D7175

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks, michaelh, ngraham

D7175: Redesign CMake syntax

[Alex Turbov]

turbov added a comment.


  ping

REVISION DETAIL
  https://phabricator.kde.org/D7175

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov updated this revision to Diff 23100.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7175?vs=6&id=23100

REVISION DETAIL
  https://phabricator.kde.org/D7175

AFFECTED FILES
  data/generators/cmake-gen.sh
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks

D8780: Try `llvm-config` to find `libclang`

[Alex Turbov]

turbov added a comment.


  @cgiboudeaux,
  
  Yep, this review is the first in series about to clean up the code of 
`FindPythongModuleGeneration` and make it generic (not only for Ubuntu) and 
flexible.
  It is why I want to clean up it from "hard-coded" values like `3.8`/`3.9` and 
"brute force" of any versions...
  
  So, obviously, this module requires `libclang` and `clang` executable.  I 
propose not to brute force the version, but just ask `clang --version` and give 
hints to library finder (i.e. when `llvm-config` is not available). 
  In case of any failure, this module should have a variable(s) which can be 
overridden by a user via CLI and explicitly control what Clang it wants to use.

INLINE COMMENTS

> cgiboudeaux wrote in FindPythonModuleGeneration.cmake:213
> https://cmake.org/cmake/help/v2.8.12/cmake.html#command:find_library + 
> https://cmake.org/pipermail/cmake/2010-October/040460.html

Thanks for the last link... I'll fix it

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8780

To: turbov
Cc: cgiboudeaux, shaheed, #frameworks, #build_system

D8780: Try `llvm-config` to find `libclang`

[Alex Turbov]

turbov added inline comments.

INLINE COMMENTS

> cgiboudeaux wrote in FindPythonModuleGeneration.cmake:212
>   NAMES clang clang-3.8 clang-3.9
> 
> and remove the lines 234-239

What distribution is this? Why only 3.8 and 3.9?? Why not 4.0 or 5.0???

I've just checked Ubuntu 14.04 (Clang 3.3 to 3.9 available) and 17.10 (up to 
5.0 available)... installing `libclang-X.Y` (or `libclang-X.Y-devel` obviously) 
always bring `libclang.so` library (which is of cause a symlink to a versioned 
name), but it always here... Also, I've checked CentOS 7 w/ DTS7 
 (Clang 4.0) 
-- same here...

so the question is "why to search a versioned name?" -- I don't know any distro 
where `libclang.so` is not available... do you?

> cgiboudeaux wrote in FindPythonModuleGeneration.cmake:213
> Replace PATH with HINTS.

Why `HINTS` is "better"?? As for me this is not a "hint" -- at this point we 
know exactly the correct libdir location... it is why I use `PATH`...

> FindPythonModuleGeneration.cmake:217
> +else()
> +# Ok, try w/o `llvm-config` then...
> +set(_LIBCLANG_MAX_MAJOR_VERSION 7)

As for me, I would remove whole this part of "brute forcing" available clang 
version. I can't see how it could work w/o additional hints due a  location of 
`libclang` is not a standard directory (typically `/usr/lib/llvm-X.Y/`) and no 
`HINTS` given to `find_library`...

Also this code is really lack of flexibility: what if I have few versions of 
`clang`, but want to use only particular one... (which is not a newest one)?? 
-- Nowadays, this scenario not handled at all...

Instead, I propose to be not so aggressive:

- If a user has `clang` installed, let's ask the version of it (`clang 
--version`), then "guess" a library dir
- if nothing found, then OK... just skip the generation of SIP files...
- If a user has some private installation of Clang (possibly built somewhere in 
`/home/john/work/tools/clang/...`) and really want to build Python bindings, 
let's give him an option to provide a libdir via CMake CLI (like 
`-DGPB_LIBCLANG_PATH=...`)
- If a user wants a particular version, he always can set a hint variable to 
the desired path...

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8780

To: turbov
Cc: cgiboudeaux, shaheed, #frameworks, #build_system

D8780: Try `llvm-config` to find `libclang`

[Alex Turbov]

turbov created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REVISION SUMMARY
  The current way to search for `libclang` doesn't work for me (Gentoo with 
clang 4 and 5 installed). 
  Instead of "brute force", here is a "legal" way (at least for Linux distros) 
-- use `llvm-config` first, then "fallback" to the old way.
  
  BTW, the problem w/ the old-way in the used (expected) library name 
`libclang-X.Y`... actually, I never seen that name used (which distro it is?)
  
  PS. This is my first patch on the way to make python binding generation works 
for me (Gentoo). This is what I intended to make it work, cuz want to port 
Python host plugin to `kate5`.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8780

AFFECTED FILES
  find-modules/FindPythonModuleGeneration.cmake

To: turbov
Cc: #frameworks, #build_system

D7175: Redesign CMake syntax

[Alex Turbov]

turbov updated this revision to Diff 6.
turbov edited the summary of this revision.
turbov added a comment.


  Updated for CMake 3.10

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7175?vs=21208&id=6

REVISION DETAIL
  https://phabricator.kde.org/D7175

AFFECTED FILES
  data/generators/cmake-gen.sh
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov updated this revision to Diff 21208.
turbov added a comment.


  Include updates for CMake 3.10

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7175?vs=21207&id=21208

REVISION DETAIL
  https://phabricator.kde.org/D7175

AFFECTED FILES
  data/generators/cmake-gen.sh
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov updated this revision to Diff 21207.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7175?vs=18322&id=21207

REVISION DETAIL
  https://phabricator.kde.org/D7175

AFFECTED FILES
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov, dhaumann, #kate, #framework_syntax_highlighting, vkrause
Cc: cullmann, #frameworks

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov added a comment.


  In https://phabricator.kde.org/D7245#146719, @dhaumann wrote:
  
  > @turbov ping
  
  
  pong...
  I wanted to make some improvements...
  And it would be nice to have some hint about how to add the mentioned tests...

REVISION DETAIL
  https://phabricator.kde.org/D7245

To: turbov, #kate, #framework_syntax_highlighting, dhaumann
Cc: cullmann, dhaumann, #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov added a comment.


  In https://phabricator.kde.org/D7175#138554, @dhaumann wrote:
  
  > What is still unclear to me: As I understand we from time to time run the 
generator script (point 2 in my list). So this is not automatically run when 
executing "make", right?
  
  
  correct. it doesn't run on `make` and never was. Some time ago I've imroved 
that generator and know its limitations and pitfals -- yeah, it is too simple 
to "parse" informal (in fact) output of `cmake --help-xxx` commands correctly.
  That is the main goal I pursue doing that redesign -- to make sure that all 
commands and parameters are here (in keyword lists) is not a mistake (error in 
the current generator).
  And most important, at least to me, to highlight only really existed named 
keywords for particular command, giving a hint to a user that particular 
parameter is really exists in this particular command.
  
  > I would be fine with this change, but the other point still stand: remove 
hard-coded colors :-) And do we have a test case for this? If not, please add a 
test file.
  
  yeah, I'll do that as soon as realize that this MR have a chance to be 
accepted... %)
  
  > Also, since you redesign this file, I think it would be OK to relicense to 
MIT.
  
  sure

REVISION DETAIL
  https://phabricator.kde.org/D7175

To: turbov, dhaumann, #kate, #framework_syntax_hightlighting, vkrause
Cc: cullmann, #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov updated this revision to Diff 18322.
turbov added a comment.


  Remove spaces around ``

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7175?vs=17801&id=18322

REVISION DETAIL
  https://phabricator.kde.org/D7175

AFFECTED FILES
  data/generators/cmake-gen.sh
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov, dhaumann, #kate, #framework_syntax_hightlighting, vkrause
Cc: cullmann, #frameworks

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov updated this revision to Diff 18321.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7245?vs=17993&id=18321

REVISION DETAIL
  https://phabricator.kde.org/D7245

AFFECTED FILES
  data/syntax/rest.xml

To: turbov, #kate, #framework_syntax_hightlighting, dhaumann
Cc: dhaumann, #frameworks

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov updated this revision to Diff 17993.
turbov added a comment.


  Make code block `::` works as again as expected

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7245?vs=17992&id=17993

REVISION DETAIL
  https://phabricator.kde.org/D7245

AFFECTED FILES
  data/syntax/rest.xml

To: turbov, #kate, #framework_syntax_hightlighting
Cc: #frameworks

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov updated this revision to Diff 17992.
turbov added a comment.


  Fix attribute name

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7245?vs=17991&id=17992

REVISION DETAIL
  https://phabricator.kde.org/D7245

AFFECTED FILES
  data/syntax/rest.xml

To: turbov, #kate, #framework_syntax_hightlighting
Cc: #frameworks

D7245: Improve reStructuredText highlighting

[Alex Turbov]

turbov created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  1. make `code-block` directive looks like a "directive" and not like a "code"
  2. highlight directive options for `code-block` (and `code`) -- just like 
"other" directives can
  3. introduce a list of standard directives and their options
  4. introduce a list of Sphinx 
 directives and their options
  5. support for "complex" names of roles and directives (like 
`:cmake:command:` & etc)

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D7245

AFFECTED FILES
  data/syntax/rest.xml

To: turbov, #kate, #framework_syntax_hightlighting
Cc: #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov added a comment.


  In https://phabricator.kde.org/D7175#133152, @dhaumann wrote:
  
  > I see seveal issues that imo should be addressed:
  >
  > 1. Please add a test case in autotest/input/ or extend it if one already 
exists (did you run make test?)
  
  
  no, I don't run tests yet (it is too complicated to build the repo for me 
nowadays)
  
  > 
  > 
  > 2. How does it work, are we supposed to run this command from time to time 
manually? If so, then I'd be ok with that.
  
  it work pretty simple:
  
  1. reading YAML (as a Python's `dict`)
  2. prepare (rename keys, & etc) data for renderer
  3. render data (a `dict`) into the Jinja template
  
  as I said the previous generator became unstable -- parsing the output of 
`cmake --help` is not reliable, so this generator uses "static" YAML file, 
which should be updated manually
  
  > 
  > 
  > 3. How high is the maintenance burden over time: I understand that this 
should this, but given we have a yaml file that needs to be maintained 
manually, I wonder whether we simply move the maintenance from one place to 
another and additionally introduce complexity (in terms of additional tooling) 
one first needs to understand before being able to fix things.
  
  the point w/ the current generator: I'm far from sure it "parse" everything 
correct... moreover, I know exactly that it "parses" `cmake --help` output 
incorrectly (and one have to fix the generated syntax manually after the 
generator) and there is really hard to make the generator right cuz the 
informal/irregular nature of help screens.
  in contrast, the new approach offers a full control over the generated 
syntax, yeah, by the cost of "manual" maintenance of the YAML file (I tried to 
make it as simple as possible, and I'm sure it shouldn't be a problem to anyone 
to add anything to it %)
  Usually, I read CMake's ChangeLog carefully after any new release, spotting 
new commands/variables/properties/etc and this is the time to update syntax 
(YAML file)...
  
  > 
  > 
  > 4. The kateversion is back to 2.4 and hard-coded colors are used again. 
Previously, it was set to 5.0, and used already the newly introduced default 
styles. I strongly suggest to keep the new default styles - we purposefully 
changed this some time ago, and I dislike that fact that we go a step back here.
  
  previous cmake.xml do not use anything from modern kate, this syntax works 
fine w/ KDE4 version of kate. 
  anyway, it would be easy to fix it and remove hardcoded colors anyway...
  
  the hardest part is to realize would this approach be accepted or not

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D7175

To: turbov, dhaumann, #kate, #framework_syntax_hightlighting, vkrause
Cc: cullmann, #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov added reviewers: dhaumann, Kate, Framework: Syntax Hightlighting.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D7175

To: turbov, dhaumann, #kate, #framework_syntax_hightlighting
Cc: #frameworks

D7175: Redesign CMake syntax

[Alex Turbov]

turbov created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  CMake syntax has been redesigned to pursue the following goals:
  
  - the former generator has used an output of `cmake --help` (and friends) 
commands, which is quite informal (not a well formed) and error prune
  - the current syntax was really out of date
  
  The new approach is to use a trivial Python script, which uses a prepared 
YAML data file and Jinja template to render the resulting syntax file.
  Key features of the new implementation are:
  
  - every command highlight only related named parameters -- e.g. `add_library` 
do not have `TARGET` named option, so it doesn't highlighted in this context
  - new highlight classes has introduced to distinct property names, aliased 
(imported) targets, special non-named arguments...
  - reuse RST syntax for comments
  - input data now in VCS and trackable
  
  there is still some work to do, but I've just want to know is there any 
interest in this approach...

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D7175

AFFECTED FILES
  data/generators/cmake-gen.sh
  data/generators/cmake.xml.tpl
  data/generators/cmake.yaml
  data/generators/generate-cmake-syntax.py
  data/syntax/cmake.xml

To: turbov
Cc: #frameworks

D5338: Add syntax highlighting file for Doxyfile

[Alex Turbov]

turbov added a comment.


  my 2 cents:
  
  I've used the syntax made by Ernst quite a long time and pretty happy w/ it :)

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5338

To: kfunk, vkrause, kwrite-devel, dhaumann
Cc: turbov, emaurer, #frameworks

Re: Review Request 115083: Python3 support

[Alex Turbov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115083/
---

(Updated Jan. 17, 2014, 8:21 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Aurélien Gâteau.


Repository: kapidox


Description
---

make it Python 3 compatible


Diffs
-

  src/doxyfilewriter.py 1a45934d8acccee1c0f3ca5dcf076b959dd466ef 
  src/kgenapidox.py 5cc45bc50cb957db2708035594b11c8229ca5d91 

Diff: https://git.reviewboard.kde.org/r/115083/diff/


Testing
---

tested w/ python 3.3 and 2.7


Thanks,

Alex Turbov

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 115083: Python3 support

[Alex Turbov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115083/
---

Review request for KDE Frameworks and Aurélien Gâteau.


Repository: kapidox


Description
---

make it Python 3 compatible


Diffs
-

  src/doxyfilewriter.py 1a45934d8acccee1c0f3ca5dcf076b959dd466ef 
  src/kgenapidox.py 5cc45bc50cb957db2708035594b11c8229ca5d91 

Diff: https://git.reviewboard.kde.org/r/115083/diff/


Testing
---

tested w/ python 3.3 and 2.7


Thanks,

Alex Turbov

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel