After investigating the work being done on KBibTeX a few months ago, we turn our attention to Kile, KDE's LaTeX and TeX editor. LaTeX is a document markup language and document preparation system built on top of the typesetting system TeX. It is frequently used for scientific publications as an alternative to word processors.

There is no stable Platform 4 version of Kile yet, but beta releases are already available and a stable release is not far away. Alexander van Loon took the opportunity to ask Michel Ludwig how the next version of Kile is shaping up. At this moment, Michel is the sole developer working on Kile.

Michel Ludwig talks about Kile's development

Alexander: To start, can you tell us what makes Kile special compared to other LaTeX editors?

Michel: Over the years Kile has accumulated an impressive number of features that can help with most aspects of LaTeX (and TeX) editing. Kile also has a highly configurable LaTeX tool launching system, a quick preview feature and scripting capabilities. As a KDE application, it can benefit from all the features that the excellent Kate editor has to offer, e.g. on-the-fly spell checking in particular. Kile can also make use of other helpful KDE features such as network-transparent file editing or embedding the Okular viewer for DVI, PS and PDF files. Finally, thanks to the KDE on Windows team, Kile can now also run natively on the MS Windows platform.

Autocompletion (click image for larger version)

Alexander: How is the effort to port Kile to KDE Platform 4 going, is it difficult to port?

Michel: The porting to the new KDE Platform is essentially complete now. However, large parts of Kile had to be rewritten. The autocompletion functionality is an example; it is now based on a much more powerful API so the autocompletion feature will be even more helpful in the future. The biggest obstacle during the porting was that some parts of the Qt 4 and KDE Platform API are fundamentally different from previous versions, and Kile had to be adapted to the new API.

Alexander: You have been occupied with porting for some years now and except for some others who contribute patches you are the only developer. Do you need help?

Michel: Actually, until a couple of months ago, I was assisted by another developer, who then had to stop his involvement with Kile due to personal reasons. Since then I am indeed the only developer of Kile. I am not satisfied with the current development speed, but there is not much I can do to improve the situation as I also have other commitments. So, I think that having additional active developers around would be a tremendous help. There are a couple of tasks available that would be ideal for new developers to familiarize themselves with the code base. In addition, for those that are not familiar with coding, some help with improving the documentation of Kile is also
needed.

Symbol insertion

Alexander: What needs to be done before a stable version of Kile for Platform 4 can be released?

Michel: There is not much that still has to be done before Kile 2.1 can be released, except for fixing a few minor bugs and polishing the documentation a bit. The latest version, 2.1 beta 5, is already stable and bug-free enough for daily use. I recommend that anyone who is still using Kile 2.0 should upgrade to version 2.1 beta 5, and check whether you can still find any bugs that have not been reported yet.

Alexander: What are the plans for the future after the next release?

Michel: After Kile 2.1 has been released, I would like to work on a few features that have been requested for a long time. Foremost, I think that the LaTeX parser that Kile uses will have to be optimized and made faster. This would also help correct a few bugs in the autocompletion functionality that are not so easy to fix at the moment. In addition, the ability to split the editor views and to have an integrated viewer for DVI, PDF, etc. alongside the LaTeX markup would also be interesting features for Kile. Then, the quick preview feature could also be improved by turning it into a live preview, and the scripting functionality could be extended by providing downloadable scripts. People can also check the feature wish list for Kile, which has grown considerably over the last years. It has numerous interesting suggestions for new features.

Alexander: Kile recently migrated to KDE's Git infrastructure. Do you like the change? (Previously, Kile resided in KDE's Subversion repository)

Kile table editor

Michel: Git is a very powerful tool with numerous features that will undoubtedly help a lot in the development process of KDE software projects. But probably as a consequence of its wealth in features, Git can sometimes be complicated to use in my opinion. Also, at times it does not seem to protect the users enough from their mistakes (e.g., it is possible to perform actions that leave the repository in a broken state, from which recovery may be difficult for novice users). However, as Git evolves, I am sure that its user interface will improve as well.

Additionally, I particularly like KDE's new development infrastructure around Git. The interconnection of the different websites like KDE Projects, KDE Identity and Review Board should bring a productivity boost to KDE development.

Alexander: Kile uses KDE's bug tracker and its Git repository, why not use KDE's infrastructure for the website, wiki and mailing lists instead of using the services of SourceForge?

Michel: Kile uses the hosting services for web pages and mailing lists of SourceForge purely for historical reasons. Kile started out using those services offered by SourceForge, but there has been no incentive to change this so far; SourceForge's hosting services currently fulfill the needs of the project. However, for bug tracking, for instance, it is more useful indeed to use KDE's facilities as this allows for a closer interaction with other KDE projects.

Kile needs to learn from auctex. The editing process is way too slow. In Kile the access to LaTeX features if done mostly via menus and only a few have keyboard shortcuts. Furthermore when it's possible to input options, this is done via a big wizard that blocks the view of your text. While this is useful for beginners, once you know how the commands work it's just quicker to type everything down yourself.

In auctex you can easily access features using the keyboard (emacs commands), and any options are introduced in a non-intrusive way in the command buffer at the bottom of the editor. This does save plenty of time. There's quite a few other things that I'd miss if I were to move, but undoubtedly this would be the most important one.

Besides auto-completion, Kile also offers automatic expansion of abbreviations. Furthermore, if you want the ultimate customisation of the editing process (with possible input options), you can also use scripts which you can either bind to some specific text input of to keyboard shortcuts.

Hi Michel thanks for your answer. I appreciate all that, but let me try to explain my thoughts on it.

Consider the task, using serif font in math mode, i.e. command \mathsf{...}. In emacs you do C-c C-f C-f, (3 strokes). In Kile, by the time you typed \mat (4 strokes) you have a list with 32 entries, with the one you want being 25th. If you get to \maths then you have 2 entries so you can go down and press enter (8 strokes total). But 8 strokes is enough to type \mathsf{ so in the end you might as well just write everything. Not to mention that in emacs you can, for instance, apply a font to a text selection using the same keystrokes, in kile this would have to be user implemented using scripts.

This is evident with lots of other tasks. In emacs, to insert an environment you'd do C-c C-e. Then you get a minibuffer on the bottom to type the environment you want, with the last selected by default. If you want to use the default one press enter (3 strokes). Otherwise you start writing the one you want and then you can auto-complete with tab. In kile you get a huge auto-complete list after \beg (4 strokes), if you want to get more specific you have to continue writing \begin{ (7 strokes) and only now you can trim the list down.

Regarding abbreviations and user scripts, these can be nice. But someone still has to implement them. That possibility should be an extra, not required for core functionalities.

So I do understand your arguments. I also believe that I'm biased because I'm so used to emacs. But in my experience it does seem to me that you'd have to type way more in kile to get the same job done.

Just for the sake of completeness, let me point out that there is a (configurable) keyboard shortcut in Kile for inserting environments: it inserts "\begin{" and then the environment completion list is automatically shown.

@Michel:
Have you considered using (or do you already use) KDevPlatform in your application?
Your program is very similar to KDevelop (but it handles LaTeX instead of code), so I think the two applications could share some code. That code should reside in the KDevPlatform library.
Quanta uses KDevPlatform, too, so it's not a KDevelop-only library.

I use kile now and then. Even though it's far from perfect, it has been a great help. Thank you for working on it.

How can you improve it?
Well, you could begin by simplifying its interface. There are lots of options that nobody uses. For example the entire menu "latex" and "wizard" are of no use, since people using Latex already have an idea of what they're doing and the latex and symbols panel on the left already offers all that an more.

Surely the most important thing missing is a good and intuitive spellchecker (like the one in openoffice and firefox). I don't know why this desperately needed feature has been procrastinated so much. Is it so difficult to implement?

Another thing missing is support for glossaries and acronyms, but this isn't really important.

Finally, when kile autocompletes tables and expressions, it puts an unicode X inside the empty fields. I think this choice was very poor because it causes the document to stop compiling until you remove the X.

Well, I wouldn't say that the "LaTeX" and "Wizard" menus are useless. I happen to use them myself from time to time :-)

Have you tried Kile recently on KDE SC 4.4, 4.5, or 4.6? KatePart (and thus Kile) now also has on-the-fly spell checking.

Regarding the "unicode X", this is called a bullet in Kile terminology. It can be used to quickly navigate to different parts of the document. But if you don't want to have bullets inserted, you can disable them in the code completion configuration page of the configuration dialog.

For starters, one could take a look at the bug and feature request lists in the KDE bug tracker. However, before starting with the coding, I'd send an e-mail to the development mailing list of Kile, just to make sure that no one else is working on that particular bug already.

I could write my latex with vim and convert to pdf in terminal, and I also could use kate with my own makefile. There are many other ways in which I could do my latex work, but every time I come back to kile. Kile is comfortable, easy & stable, which is a tall order indeed. I've had no problems with 2.1, which is quite something for betas.