Commit 16847130 authored by Christoph Cullmann's avatar Christoph Cullmann

sync

parent 203a0e1d
......@@ -5,61 +5,76 @@ date: 2019-09-09T14:06:00+02:00
url: /post/2019/2019-09-09-kate-planning/
---
### The Idea
### The Opportunity
During Akademy Dominik and me sat together and discussed a bit what we shall do to evolve Kate :)
During Akademy 2019 here in Milan, Dominik and me had time to sit together and discuss 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.
Whereas Kate already works well as a general purpose editor, the competition in the text 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.
Beside the well established stuff like [GNU Emacs](https://emacs.org) & [Vim](https://www.vim.org), new editor projects got started that did set the bar higher on what users expect from a advanced GUI text editor.
For example Sublime, Atom, Qt Creator and Visual Studio Code are things to keep an eye on feature & polishing wise.
For example [Sublime](https://www.sublimetext.com/), [Atom](https://atom.io) and [Visual Studio Code](https://code.visualstudio.com/) 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.
### The Plan
### The Rough Ideas
#### Kate Plugin Interfaces
Again provide Kate specific plugin interfaces inside kate.git (no installed headers).
From the KDE 4.x Kate to the KF5 based Kate version, we removed the Kate specific plugin interfaces and went with more generic interfaces in KTextEditor.
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.
The idea was to be able to share more plugins e.g. between Kate and KDevelop.
This idea never really did take off, at the moment just two of our plugins are shared at all...
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.
On the other side, this makes it much harder to expose new functionality to our plugins, as we need to stay binary compatible.
#### Integrate Projects into Kate Core
Moving back to having some Kate only stuff that has not even installed headers but is just usable for the plugins we bundle in our kate.git will make it again more flexible what to expose.
Move project functionality from plugin to Kate application core
One can still think about moving "proven in practice" parts back to the KTextEditor interface part.
#### Make Projects a Core-Feature
At the moment the projects feature is located in a plugin.
For exposure of some things like the current project files some evil Qt property hacks are used.
By moving this feature into the Kate core we can use a sane way to search in project, list project stuff in quick open, ...
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
We shall get the LSP support in a shape that it can be shipped enabled 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, ...
We shall provide the user with better code navigation.
This will work by e.g. provide the plugins with some interface they can register location jumps.
This will enable us 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.
The new LSP plugin shall subsume stuff like the Rust or D specific code completion plugins.
Think about the future of unmaintained plugins!
#### External Tools Plugin
revive the external tools in a improved way, e.g. like Qt Creator.
Revive the external tools in a improved way, e.g. like in Qt Creator.
#### Improve Port to KSyntaxHighlighting
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.
#### Further Brainstorming
......@@ -70,23 +85,24 @@ We shall take a look what other editors provide.
##### Diff/Patch Viewer
Want we to integrate with stuff like KDiff3/Kompare/... to have a better handling of e.g. git diff, patches, ...
Want we to integrate with stuff like KDiff3/Kompare/... to have a better handling of e.g. git diff, patches, ...?
##### Improve View Management
e.g. improve the way we handle splitting the views and the tabbing
Try to improve the way we handle splitting the views and the tabbing.
Take a look how other editors do that!
#### KDevelop vs. Kate?
Given already today we enter the area of KDevelop by providing the LSP client, we need to think about what happens in the future with overlapping features.
It is no goal to evolve Kate into an IDE.
We think Kate shall be a competitor for editors like Atom, not full-fledged IDEs like KDevelop or Visual Studio.
We think Kate shall be a competitor for editors like Atom, not for full-fledged IDEs like KDevelop or Visual Studio.
Still, e.g. in the area of project management/code navigation/version control support there will be some overlap.
The question is: can we share stuff there? What shall be the focus of Kate and KDevelop in e.g. language support?
I think Kate will aim to support as many languages as possible via LSP but not try to have more tight integration like that.
On the other side, KDevelop has great support for C++ and some support for other languages.
I think here it will be interesting which future direction the KDevelop project will take.
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