Version: (using KDE KDE 3.5.4) Installed from: Debian testing/unstable Packages It would be nice, if there was an API (probably in KTextEditor::HighlightingInterface) to change some aspects of the highlighting definition in use at runtime. The most important use case I have in mind would be highlighting of function names or keywords. Since many languages allow to include modules/libraries with additional functions / objects, or of course to define new functions / objects, it is impossible to define all valid names statically. At least for specialized IDEs embedding a katepart, it would be nice to have an easy option to add / remove keywords dynamically. Maybe something like void KTextEditor::HighlightingInterface::setListItems (const QString &list_name, const QStringList &new_items); Further low level functions to modify contexts and rules are thinkable, but would probably require a lot more work for relatively little gain. However - without knowing the relevant code - I guess modifying a list of keywords should not be too hard to implement, and would be highly useful IMO.
in kde4 you can add overlay highlighting with SmartRanges: http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/interfaces/ktexteditor/html/classKTextEditor_1_1SmartRange.html
The MovingRanges interfaces allows to do this, e.g. KDevelop uses this now since years.
Well, I won't complain if you close this wontfix, but no, MovingRanges (alone) is not what I'm talking about, or at least not as far as I am aware. What I had in mind was a way to work on the basis of a _static_ highlighting definition, and simply add in some dynamic details. And yes, of course, I can overlay the static highlighting with MovingRange-based highlighting, but that means duplicating a jolly lot of non-trivial parsing to find out which context I'm in, etc. - work that is already done (and done well) by the static highlighting. Actually, another way to make me happy is simply giving me an easy and reliable way to tell which highlighting _context_ is active at a given cursor position (even if it's limited to the context at the start of a line or whatever). So if that stands any more chances of happening, I'll be glad to open a new wish for that, instead.
Ok, I see. You want to e.g. add the right imported functions/types/... inside the right context dynamically. Hmm, not that easy, given beside the "dynamic" contexts used for constructs like "here docs" the highlighting contexts are completely static. We need to think about that bit more I guess. For the interface, the problem there is ATM that we have no real interface at all for the highlighting and we would first need to come up with some "stable" API for the 5.x series. Any patches are welcome.
Thomas, is this still an issue for you? We are currently working on a new git repository called syntax-highlighting. What are you use cases exactly? I'm not sure modifying keyword lists is really a good idea, since to be sure, you'd need to rehighlighting everything then (since there could be other context switches then). MovingRanges are imho indeed what you want. What you are missing is a proper parser then, but I'm not convinved Kate's syntax highlighting files should act as parser for you :-)
Hi! This is still a wanna-have to me, although there really are at least two routes, for what I am trying to accomplish. The situation is this: The "static" kate syntax highlighting works beautifully for my language. It is smart enough to differentiate the different contexts, reliably, even though that is not entirely trivial. Essentially I would like to re-use all that existing cleverness, and add some bits that cannot be defined statically. Importantly, of course, these bits to add are _not_ independent, but they do depend on the syntactical context, i.e. on exactly the rules that the "static" highlighter knows, already. The alternative route, then would leave the static highlighting static, _but_ I would need a way to 1) extract the (name of the) active context at a given cursor position 1b) preferably also extract information on the encapsulating context(s), and on where the context starts, and where it ends; this part is not terribly important, though 2) receive notification whenever the context has changed in an area (a visible area) of the document (and I should update my custom/dynamic highlighting). Does that make sense and sounds less out-of-scope?
Dear user, this wish list item is now closed, as it wasn't touched in the last year and no contributor stepped up to implement it. The Kate/KTextEditor team is small and we can just try to keep up with fixing bugs. Therefore wishes that show no activity for a years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users. If you want your feature to be implemented, please step up to provide some patch for it. If you think it is really needed, you can reopen your request, but keep in mind, if no new good arguments are made and no people get attracted to help out to implement it, it will expire in a year again. We have a nice website https://kate-editor.org that provides all the information needed to contribute, please make use of it. Patches can be handed in via https://phabricator.kde.org/differential/ Greetings Christoph Cullmann