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

List:       kwrite-devel
Subject:    Re: Documenting command signatures
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2014-02-03 23:23:40
Message-ID: lcp8df$mph$1 () ger ! gmane ! org
[Download RAW message or body]

On 2014-02-03 18:04, Stephen Kelly wrote:
> Matthew Woehlke wrote:
>> I guess you mean that in a '..code-block:: cmake' block, kate should
>> apply the CMake HL rules? (What about other languages; I guess the same
>> argument would apply to e.g. C++, Python, etc?)
>
> Kate already does that, since my recent patches to the cmake rst
> highlighting rules.

Ah. So it does... (I think that's more recent than the last time I'd 
looked at rest.xml, so I hadn't noticed yet.)

> Mappings for other languages could be added.

I would probably consider adding Python; not having Python seems a 
little odd given reST's relation to Python documentation :-).

Others can be added as someone requests them. Although...

> A more-general way of doing the
> mapping would be nice, but Milian told me such a thing does not currently
> exist in kate.

...this would indeed be better. (Other HL's could use this also, e.g. 
wiki. So could Doxygen, except the problem of including HL rules with 
the need to first strip some prefix from each line would need to be 
solved. The latter however would also fix reST blocks in CMake 
non-bracket comments, which would make it a double win.)

>> (Or do you mean that the CMake HL also doesn't mark the previous example
>> as invalid? ...which it doesn't.)
>
> Kate does not mark the source_group signature linked above as invalid.

Right. That can probably be improved. (There is probably some general 
refactoring of cmake.xml that could stand to happen. For example, 
AFAICT, CMake itself doesn't process generator expressions until after 
detecting strings, but I don't think we're highlighting like this.)

It's not high on my priority list right now, but feel free to take a 
crack at it. (Please review https://git.reviewboard.kde.org/r/115403/ 
first though so I can merge it and we don't have version number 
conflicts ;-).)

(p.s. I recently wrote a Python parser for CMake script. In the process 
I did a modest bit of poking into how CMake parsing works, so some of 
this is fresh in my head. The parsing-of-escapes change is also a result 
of that.)


Vaguely related: you might want to check with Daniele ¹ what's up with 
the "alternate" HL for reST, as it appears to be newer, though IME 
(yours too?) less correct.

(see https://bugs.kde.org/show_bug.cgi?id=300559)

-- 
Matthew

_______________________________________________
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]