Monday, March 17, 2014

kdevelop-python for Python 3: first stable version (1.6.0) released!

Yesterday, Python 3.4 was finally released, so I'm now happy to announce the first stable release of kdevelop-python which supports Python 3! See below for the tarballs.
As in the Python 2 series, PyQt continues to be one of the best supported frameworks.
Obsolete,  please use 1.6.1-py3 (see below) -- 1.6.0 didn't build on some systems kdev-python version 1.6.0-py3

kdev-python version 1.6.1-py3
SHA256: 26b1fa25e8f24f1e0b801ece02b283a750e77543e6df1e571dd52b36778859a5

The kdev-python 1.6-py3 series is compatible with KDevelop 4.6 (kdevplatform 1.6) and is suitable for working with Python 3.x source code.
If you're only interested in using (as opposed to packaging or developing) kdev-python, you should consider installing kdev-python from your distribution's package manager instead of downloading the source code. 
The python 3 and python 2 versions cannot be installed at the same time currently!
There's not that much more to say than what was already said in the beta announcement, so I will just post some screenshots of what continues to work in the Python 3 version:
Code completion is powerful as ever and tries very hard to only make suggestions which are useful in the current context.
Code tooltips are still there, too.
As always, please report any bugs you might find to the bug tracker. Happy hacking!

Tuesday, March 4, 2014

kdevelop-python for python 3: beta release

Good news: Python 3.4 is about to be released, and with it kdevelop-python's first version to support Python 3. Until that happens in a few days, here's a beta:
kdev-python version 1.5.80-py3

The kdev-python 1.6-py3 series is compatible with KDevelop 4.6 (kdevplatform 1.6) and is suitable for working with Python 3.x source code.
If you're only interested in using (as opposed to packaging or developing) kdev-python, you should consider installing kdev-python from your distribution's package manager instead of downloading the source code.
There are a few things which need to be announced about this, so read on!

Embedded Python fork

First and foremost, this abomination is finally gone in the -py3 series. Python 3.4 merged a patch which is required by kdev-python, and now we can use the system's python installation. This will especially make kdev-python comply with all distribution's requirements for packaging software, which means it will hopefully soon be available in all major distribution's package repositories.
This also means that kdev-python now depends on Python =3.4.

Python 2 compatibility

The py3 series is not compatible with Python 2, and currently you can not install kdev-python and kdev-python3 side-by-side. I will try to address this restriction in the future and I will also publish a script to install the two versions into separate environments, but for now that's what is like. Especially, for packagers, this means that kdev-python must conflict with kdev-python3. The problem cannot be solved by renaming all the files, it also requires new UI and glue code to be written to select the correct language version, which I only have done partially as of today.

Branch names in kdev-python.git

I also used this opportunity to reorganize the branches in kdev-python.git a bit:
  • python3 is now python3-legacy (do not use)
  • python3-nofork is now python3; this branch is the most recent (unstable) version of the python3 version of the plugin, and compiles against kdevplatform master
  • there's a 1.6-py3 branch which is like 1.6 but for python 3.
If you had any of the renamed branches checked out, you might need to do git reset --hard origin/branchname. In the near future, master will also be renamed to python2 and python3 will be renamed to master (but not yet).

Feature comparison of kdev-python3 and kdev-python2

Generally, the Python 3 version has all the features from Python 2 plus a few more and some bug fixes. Not all new Python 3 features are understood yet (the syntax is supported, but the semantics isn't, e.g. nonlocal does nothing), though. What is there however is support for function annotations:
If the expressions in a function annotation represent a type (i.e. not an instance or something different) they are used to adjust the function's return and argument types.
I really hope this feature gets used for type hints, so this is a first step to encourage you to use it for that. ;)
Not all is awesome just yet, though: Although I'm not aware of any major issues, there will be regressions (things which were working in Python 2 but are now broken). There are always regressions, even with the ~90% test coverage kdev-python has. That's the purpose of this beta: go forth and test, and report all the bugs to the tracker so they can be slain!

Friday, February 7, 2014

kate: intelligent code completion for all languages!

... well, maybe that's a bit of an exaggeration, but it's certainly much more intelligent than before. Look:

Code completion in CSS
... bash
... Lua
... PHP
even Gnuplot!
Note how this one has a different set of possible items for the same query, respecting the context.
Even Mathematica ;) This image shows a problem which still needs to be fixed: in case-insensitive languages, all completion suggestions are lowercased (which is not technically wrong of course, but a  bit ugly). It's easy to fix but simply not done yet.
There's unexpected profit from this in quite some areas, even KDevelop: for example, through this we now get code completion for all keywords in doxygen comments:
Completion for doxygen keywords inside a doxygen comment
Of course, those only appear inside actual doxygen, and not C++. When the cursor is in C++ code, it shows the C++ keywords instead (but they will not be very visible in KDevelop, since they're sorted below KDevelop's suggestions, which are better).

How does this work?

Short answer: magic! Correct answer: it uses the highlighting files. For highlighting, kate has a list of possible keywords for languages listed in highlighting files (/usr/share/apps/katepart/snytax/$language,xml). Those keywords are even context-sensitive: you will notice that e.g. the PHP highlighter does not highlight PHP function names inside comments or strings. So, the highlighting engine needs to know which keywords are valid at which position. Those are precisely the keywords which are suggested in the list.

What now?

Now that we have this feature, I think we can make more out of it in quite some cases. Especially, I want to invite you to have a look at your favourite language, and make sure all keywords / builtin functions / etc. are actually listed. Because of this feature, it might make sense to list keywords for languages where they are not terribly helpful for highlighting; a prominent example would be HTML, where currently the highlighter is totally generic and does not actually look at e.g. the tag names (thus, there's no completion). If you'd fix that by actually listing all valid HTML tag names, you'd (1) get better highlighting, e.g. you can mark undefined elements (think typos) as errors and (2) completion for free with that.

Another thing which can be improved is the context sensitivity. Some languages already do this rather well, but many languages will higlight keywords also in places where it'd be easy to detect that the keyword does not make sense there. That doesn't matter that much for highlighting only, because generally users write code which makes sense, but still -- if you can detect it, both consumers of the highlighting data (the actual highlighting, and the completion engine) gain something from it. So, extra motivation for making things more exact! ;)

I'm sure we can do more cool stuff with this. If you can come up with a good idea -- tell me, I'm happy to talk about it.

Sunday, January 26, 2014

KDevelop / Kate sprint in Barcelona in January 2014

Last week I have been in Barcelona at the KDevelop / Kate sprint with all the other nice people working on those projects. As always, it was very cool to meet everyone again and spend a week together improving software. A big thanks to the organizers and sponsors, too!

Since most of the time I work on a fairly encapuslated subsystem (Python support for KDevelop) and only a smaller part of my contributions goes towards the KDevelop / Kate core repositories, I don't  have any world-changing news to announce -- unlike for kate and KDevelop, no Qt5 / KF5 porting is happening yet in Python support. It doesn't make much sense to start porting until all the interfaces have stabilized.

Still, quite some interesting things have piled up in the last few months, and especially during the sprint.
In the following, I want to give a quick summary of those.

Tuesday, October 29, 2013

kdev-python update: version 1.5.2 released

I'm happy to announce the availability of a second stabilization update for the 1.5 series of kdev-python, the Python language support plugin for the KDevelop development environment. See the 1.5 announcement for more information.
kdev-python version 1.5.2

The kdev-python 1.5 series is compatible with KDevelop 4.5 (kdevplatform 1.5) and is suitable for working with Python 2.x source code.
If you're only interested in using (as opposed to packaging or developing) kdev-python, you should consider installing kdev-python from your distribution's package manager instead of downloading the source code.
kdev-python running in KDevelop master
Changes in this release (relative to 1.5.1):
  • Fix a bug which led to the PEP8 checker running on non-python files in some cases
  • Properly support unicode docstrings (thanks to Alexandr Zamaraev)
  • Fix a crash in code completion which happened in some rare cases
  • Fix a crash which could happen when a list comprehension was used as the default value for a function parameter
This is a small update containing only the above 4 bug fixes; all users are urged to switch to the new version as soon as it becomes available in their distribution.

There will be a larger update containing various cool new features in a few weeks, so stay tuned!

Monday, October 28, 2013

kte-collaborative 0.2: First stable release of the collaborative text editing project

I'm pleased to announce the first stable release of kte-collaborative, which provides collaborative text editing in kate through kde-telepathy, and an update to the libqinfinity library.
libqinfinity version 0.5.2:
SHA256: 739f99afb7fd464e4b541e2980e07911c8f30924f9871f14294dc3148137825a

kte-collaborative version 0.2.0 (aka 0.2): 
SHA256: 06c8cfb16b93a8fe3c5e2267ba3f71110526966267f73fed20a902c3f7982a55

kte-collaborative 0.2 depends on kde-telepathy 0.7 beta or later, and works with libinfinity 0.5.x.
kte-collaborative 0.2, with dolphin listing some files from and editing a file in kate.
There have not been many noteworthy user-visible changes since the last beta release, so please to refer to the 0.2 beta announcement for more information. As always, please report any bugs you find to!

Wednesday, October 23, 2013

Advanced code completion filtering in kate / KDevelop

I have implemented two new ways to filter the code completion popup in kate: filtering the list using an abbreviation, and filtering the list using text not occuring at the word's beginning. This can probably best be demonstrated by lots of pictures:

You can match completion items by their abbreviation. This works for both camel case and underscore notation.

You can also match entries by words they merely contain but do not start with. This matching is only allowed at word borders (capitals or underscores). This feature makes it far easier to find that damn class which has an unexpected name prefix, or the m_foo variable you thought was called foo.

The abbreviation expansion engine also allows you to type parts of the words from the abbreviation, making your search more specific in a convenient way.
This feature is not specific to kdev-python, it works in all kate-based apps. It is available in kate's master branch, and will be available in KDE SC >= 4.12.

If you have more suggestions or cases which are not handled well, I'm happy to discuss this further. Have fun hacking!

P.S. If anyone can come up with an efficient algorithm for doing what is depicted in the last image, I'd be interested. The current one is quite slow for some corner cases.