Archive for the ‘Thoughts’ Category

Thoughts on live previews in LaTeXila

Saturday, January 10th, 2015

Several years ago I talked about some principles for the user experience of LaTeXila, a GTK+ LaTeX editor for GNU/Linux. The conclusion:

The idea of LaTeXila is to always deal directly with the LaTeX code, while simplifying as most as possible the writing of this LaTeX code. The users don’t need to be LaTeX gurus, but they should understand what happens.

In my opinion this better follows the LaTeX philosophy than programs like LyX. By writing directly the LaTeX markup, you have full control of your document. The idea of LaTeX is to concentrate on the content and the structure of the document, not its layout.

With a live preview, you see constantly the layout… so you’re less concentrated on the content. As soon as something is wrong in the layout, you’ll want to fix it. This can lead to bad practices, like proceeding by trials and errors until the layout is good. LaTeXila tries to avoid that. As in programming, you should understand what you’ve written before the compilation or execution. You must be certain that the code is correct; if you have any doubts, the best is to read the documentation, this will save you time when you’ll use the same commands in the future.

Moreover, layout polishing should be done when the content is finished. For instance, it can sometimes happen that a word exceeds the margin, because LaTeX doesn’t know where to place an hyphen to split that word. It is useless to fix this issue when the content isn’t finalized, because if you add or remove some words in the sentence, the problem will maybe be fixed by itself.

Instead of a live preview, the workflow in LaTeXila is to compile from time to time the document (e.g. when you’ve finished a section) to re-read your text and check that the result is what you expected. A handy feature in that context is the forward and backward search between LaTeXila and Evince, to switch between the *.tex file(s) and the PDF at the corresponding positions, with a simple Ctrl+click.

But there are some special cases where a live preview can be useful, i.e. when more source <-> result cycles are required:

  • A PGF/TikZ figure preview, because in that case the layout is more important.
  • When we do something difficult, like writing a long and tricky math equation. But when it becomes difficult to find our way in the code, an alternative is to improve its readability, by spacing it out, adding comments to separate the sections, etc.

If you have other specific use cases where a live preview is really useful, I would be interested to hear them. I don’t think “learning LaTeX” requires a live preview, as explained above this can result in bad practices.

So I think a live preview might be useful for editing one paragraph. A live preview of the whole document is probably less useful. In any case, a live preview should be enabled only temporarily. In LaTeXila we can imagine doing a right click on a paragraph or TikZ figure, select the live preview in the context menu and we enter in a mode where only that paragraph (or selection) is visible, with the live preview on top/right/directly injected in your brain/whatever. Then when the writing of the tricky paragraph is finished, we return to the normal mode with the whole source content.

{specialized, general-purpose} × {text editors, IDEs}

Tuesday, February 11th, 2014

Some thoughts about text editors, IDEs, specialized or general-purpose applications.

Several languages Other tasks Plugins
Specialized text editor No No ?
General-purpose text editor Yes No Yes
Specialized IDE No Yes ?
General-purpose IDE Yes Yes Yes

The above table summarizes how I view the text editors and IDEs field.

Several languages

A specialized application focus only on one programming language, or several languages used together. A general-purpose application can support completely different programming languages and platforms.

Other tasks

A text editor focus only on editing text or source code, while simplifying as most as possible the writing of this code. An IDE integrate other features like building the source code, running it, writing commits, integrate a debugger, and so forth.


For obvious reasons, a general-purpose application should have a plugin system. For a specialized application, the need for plugins is less obvious.

Two extremes

The general-purpose IDE with plugins is one extreme. The user interface must be generic enough to suit plugins and different programming languages. And it takes more time to learn and configure the application.

The specialized text editor without plugins is the other extreme. The developer has full control on the user interface, so the application has a potentially better usability. The application requires less time to learn and configure. Ideally, it should Just Work.

Not reinventing the wheel for specialized applications

Write libraries for the common features! Or at least ensure that your code is reusable. This is not limited to text editors and IDEs, I’m sure you can apply the same principles on your favorite field.

Developing graphical IDEs the UNIX way

Wednesday, July 3rd, 2013

Programming on a UNIX environment generally involves the use of command line tools: vim/emacs, git, grep, sed, screen/tmux, and so on. What is really nice about these tools is that they do only one thing, but do it well. Now, what about people not wanting to learn shell commands? And sometimes (sometimes), graphical interfaces are more convenient.

An IDE is an integrated development environment. What people think about this “environment” is generally a bloated program (*cough* eclipse *cough*). But what if the environment is not one big application, but several small programs? The small programs can interact a little together through D-Bus, if needed.

Let’s take a few examples.

Specialized text editors

To have a good user experience, the text editor should be smart enough to know the language used (C, C++, Python, Vala, LaTeX, etc.) and implement features specifically for the language. A few examples:

  • Code completion;
  • Switching between the call of a function to its definition;
  • Have an overview of the file (the list of functions, or the structure of a LaTeX document).

Having only one text editor for several types of tasks (C and LaTeX for instance) is not convenient. It works with vim or emacs, but at the cost of passing lots of time in the configuration files. If a graphical application have thousands of settings, we end up with something worse than eclipse. No, instead, there should be one text editor for each task. And one another general-purpose text editor that don’t include specialized features.

This is not just about settings. With a single text editor for all tasks, the UI must be generic enough for the plugins, but they will always be restrictions. On the other hand, with an independent application, the UI can be exactly what is needed: not too generic nor too restrictive.

The common features between all those specialized text editors can be shared in a library. A project is to make the gedit source code more reusable. It would have been a nice GSoC for me (see this draft proposal for more details), but instead I work on GtkSourceView, which is also nice.


Working on a git repository can be a bit difficult at the beginning. A graphical application that implements the basic features can be useful for some people. But it doesn’t need to be available in the same program as the text editor!

Creating a commit, navigating through the repository history, pull, push, changing branches, … have nothing to do in a text editor, in my opinion. There are some things that can be useful in the text editor though: if there is an integrated file browser, we can mark the modified/added/removed files. And in the margin of the text content, we can mark the modified sections.

Search and replace

The search and replace in a text editor can be limited at one file at a time. The search and replace entries can be shown in the top-right corner of the file, with a little button to show and hide the replace entry.

The search and replace in multiple files is another beast. Integrating it nicely in the text editor is a difficult task. Generally the developer choose a dialog window, because it is the best available option, but it partially hides the file contents…

Why not a small application that do only that? It would roughly select a directory, and search in all files in this directory. The text editor can have a menu item “Advanced search and replace” that would launch the small program with some parameters. The advantage of this small program is that the UI is really better, since it doesn’t have all the text editor features.

When we replace some text, sometimes we want to do small modifications afterwards. But normally, the specialized text editor features would not be needed in the small search and replace application.

The specialized text editors would already have features to edit several files at once. For example, when we change the name of a function, all the calls to the function can be renamed too, and adjusting automatically the indentation of the parameters (should be doable).


The general idea is to have small programs with a clean and simple UI, which don’t require lots of configuration, and that work well together. Ideally, they should Just Work™, like other GNOME applications.