Commit 141fef9e authored by Christoph Cullmann's avatar Christoph Cullmann

sync

parent 93215c4f
---
title: Kate Planning
author: Christoph Cullmann
date: 2019-09-095T14:06:00+02:00
date: 2019-09-09T14:06:00+02:00
url: /post/2019/2019-09-09-kate-planning/
---
### The Idea
During Akademy Dominik and me sat together and discussed a bit what we shall do to evolve Kate :)
Whereas Kate really already works well as a general purpose editor, the competition in the editor space got more intense in the last years.
Beside the well established stuff like Emacs & Vim, new editors were created that did set the bar higher on what users expect.
For example Sublime, Atom and Visual Studio Code are things to keep an eye on feature & polishing wise.
For example Sublime, Atom, Qt Creator and Visual Studio Code are things to keep an eye on feature & polishing wise.
Therefore we decided it would make sense to think a bit about which stuff should be improved or altered in the near future.
Some key points would be:
### The Plan
#### Kate Plugin Interfaces
Again provide Kate specific plugin interfaces inside kate.git (no installed headers).
This will allow us to extend the functionality provided to all plugins without needing to take care of binary compatibility.
After X years the "we have 3rdparty plugins" idea didnt take off, no need to limit oneself.
* again provide Kate specific plugin interfaces inside kate.git (no installed headers)
We shall install the plugins coupled to Kate, too, to be able to have no longer any need to setup a special environment to run self-compiled Kate variants.
reason: be able to extend the functionality provided to all plugins without needing to take care of binary compatibility
after X years the "we have 3rdparty plugins" idea didnt take off, no need to limit oneself
#### Integrate Projects into Kate Core
* move project functionality from plugin to Kate application core
Move project functionality from plugin to Kate application core
reason: be able to provide project features to addons, e.g. sane way to search in project, list project stuff in quick open, ...
other state of the art editors provide that per default, too
still stuff like "shall we create projects on the fly" can be deactivated like today
We want to be able to provide project features to addons, e.g. sane way to search in project, list project stuff in quick open, ...
Other state of the art editors provide that per default, too
Still stuff like "shall we create projects on the fly" can be deactivated like today
#### LSP Support per default
* get LSP support in a shape that it can be shipped per default
Get LSP support in a shape that it can be shipped per default
Users expect that modern editors provide advanced language integration off the shelf, like Atom, Visual Studio Code, ...
#### Great code navigation
Provide the user with better code navigation.
e.g. provide the plugins with some interface they can register location jumps, to be able to seamless jump back and forth for any kind of location change e.g. due declaration lookup or search in files match lookup, ...
#### Consolidate the plugins
e.g. the new LSP plugin shall subsume stuff like the Rust or D specific code completion plugins.
#### External Tools Plugin
revive the external tools in a improved way, e.g. like Qt Creator.
#### Improve Port to KSyntaxHighlighting
reason: people expect that modern editors provide advanced language integration off the shelf, like Atom, Visual Studio Code, ...
Porting the highlighting over to KSyntaxHighlighting was a big success.
Kate and Qt Creator now finally share the same highlighting engine and we got a lot of new contributions to our highlightings.
(we support now over 300 different languages, something to be proud of)
Still, e.g. the theme support is still not moved over to what the new framework provides.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment