| Summary: | KTextEditor should allow overriding builtin scripts on a system-wide level | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-ktexteditor | Reporter: | RJVB <rjvbertin> |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | simonandric5 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | All | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=385413 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
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 |
KateScriptManager::collect() says this: ``` // then resources, e.g. the stuff we ship with us dirs.append(QLatin1String(":/ktexteditor/script/") + type); // then all other locations, this includes global stuff installed by other applications // this will not allow global stuff to overwrite the stuff we ship in our resources to allow to install a more up-to-date ktexteditor lib locally! ``` While I can understand the reasoning I think the current implementation goes a bit too far in that it makes it impossible for distributions to ship adapted versions of the builtin scripts (cf. #385413). In fact, I even wonder how effectively the intended result is achieved, if at all. With this prioritisation, no on will be installing modified versions of builtin scripts anywhere but in the writable GenericDataLocation (most likely in individual home directories). AFAICT all this order achieves is to make the non-writable GenericDataLocations off-limits for scripts that would override the builtin scripts. IMHO (and unless I'm missing something) the algorithm should be: - look in all appropriate directories under all GenericDataLocations - look in the builtin resources - pick the scripts with the latest revision number only.