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

Reply via email to