Last entries

Tue 09 Feb 2016

The need for a new editor mixing texts and graphics

Every time you do some programming, you need a text editor (except when you program in graphical languages like SCADE). Some long-time well-known ones are Emacs (which I use) or VI. Such editors are focusing on their editing capabilities (you can edit huge files without any issue) and their ability to be programmed, for example they have dedicated modes to edit C language files or OCaml files. They are very versatile, you can find modes for obscure languages or even have dedicated mode for proof assistant (e.g. ProofGeneral for Emacs).

But those editors are focusing on the text. I think most if not all the time, they are using regex to match some specific keywords of a program and then color or indent them in a specific way, but they don't understand the program, e.g. what is a variable, an expression or a method call. Therefore people have proposed another kind of text editor dedicated to programming languages, like Eclipse or IntelliJ IDEA. Such editors are very powerful: they understand the program structure, propose useful contextual helps (like giving parameters of a method call) or help in code refactoring (e.g. encapsulating an object field so it can only be accessed to getter and setter methods).

Of course the distinction is not so binary: textual editor like Emacs or VI have advanced modes than can understand program structure and do refactoring.

But both kind of editors have a strong limitation: they focus on programming language and most of the time they are unable to mix text, graphics or other layouts like tables. This is not entirely true for Eclipse, but I'll come to that later. So, why would you like to mix text and graphics when editing a program? Because a program is more than just text! Wouldn't be useful to use a quick drawing to explain an algorithm? If you program manipulates state machines, wouldn't be useful to directly draw state machines and automatically convert them into code? That would certainly avoid some kind of programming errors. One could also imagine tables to specify the behavior of a function like Parnas tables (which could be even considered as a formal, albeit readily understandable, specification). Or one could imagine graphically draw the architecture of the system, then dive into usual text code to edit the software modules.

Such kind of editor exists, like mbeddr for C code or some Eclipse plug-ins like Rodin for Event-B formal language. But again I see a strong limitation to their use: they are storing the edited source code into a model generally saved in an XML file. It is very difficult to handle such XML files with usual programming tools. For example handling them in source control tool like Git is a nightmare, with merges very frequently corrupting the XML files.

So what would be the ideal programming editor mixing text, graphics and tables? I won't give precise specification :-) but only sketch here some characteristics:

  • Versatile, programmable, so as to handle various programming languages like Emacs or VI;
  • Able to directly draw graphics and edit tables, in a WYSIWYG way. For me this is a crucial point. Wiki-like approaches with special markers are not user friendly and practical enough. The ability to program the editor would allow transforming graphics or table into code text and vice-versa;
  • Store edited programs only in text files (and of course probably some binary files for graphics). One would probably need some tags stored as program comment to reference graphics within the code text and display it properly within the editor;
  • Hyperlink capabilities, to be able to navigate within the code, e.g. jump from a graphic element to the corresponding code text, maintain index and reference tables (for code documentation), ...
  • Fast, low on memory, disk and CPU resources. Everybody that has already used Eclipse understands what I mean. :-)

As far as I know, such a tool does not exist yet. If you have hints or even tool name that would be able to do what I would like, I'm very interested. ;-) Tell it to me through this blog comments or directly.

Mon 18 May 2009

  • David Mentré
  • 1

Micro-guide de survie sur vi

Ce billet est sous licence Art Libre 1.3.

vi est un éditeur de texte disponible sur quasiment tous les systèmes Unix. Fonctionnant en ligne de commande et occupant peu de ressources, il est souvent le seul éditeur disponible sur un serveur ou quand tout est en rade. Savoir ce débrouiller avec est donc indispensable. Wikipédia propose un résumé plutôt complet des commandes mais encore trop long. Je résume ci-dessous le strict minimum pour pouvoir se dépatouiller avec vi.

Les deux modes de vi

vi fonctionnent suivant deux modes qu'on utilise à tour de rôle :

  1. le mode biiiiip ou mode commande. C'est le mode par défaut lorsqu'on lance vi. Il permet de se déplacer dans le texte, de copier ou de supprimer des lignes ou des mots. Attention, la plupart des commandes que l'on tape ne s'affichent pas à l'écran quand on est en mode biiiip/commande.
    Pour revenir au mode biiiip, il faut appuyer sur ESC. Si vous êtes perdu, si vous ne savez plus dans quel mode vous êtes : ESC, ESC, ESC, ... jusqu'à ce que ça fasse biiiip.
    En mode biiiip, il y a un sous-mode où on peut taper des commandes longues qu'on voit en bas de l'écran avec « : ». Là aussi, appuyer sur ESC pour revenir au mode commande/biiiip normal ;
  2. le mode massacre ou mode insertion, c'est le mode dans lequel on modifie le texte. Comme parfois on passe en mode insertion par erreur, on ne modifie pas toujours là où l'on veut (déjà fait ! \o ;-) Généralement, on tape « i » pour passer en mode insertion (i comme Insertion), et ESC pour revenir au mode commande.

Les commandes à connaitre en mode biiiip/commande

Les commandes indispensables à utiliser en mode commande ou biiip sont :

  • « :q! » : pour quitter vi, sans enregistrer les modifications, là maintenant, tout de suite, sans attendre !
    Un peu d'explications : « : » pour passer en mode commande longue, « q » pour Quitter, « ! » pour ne pas enregistrer les modifications (! comme Maintenant !) ;
  • « :q » : pour quitter vi (q comme Qitter). S'il y a des modifications faite au fichier, vi refusera de quitter. Utiliser alors « :q! » pour quitter sans enregistrer ou « @@:w » pour enregistrer les modifications (cf. infra) ;
  • les flèches du curseur : pour se déplacer dans le texte[1] ;
  • « :w » : pour enregistrer le fichier (w comme Write, écrire en Anglais) ;
  • « i » : on passe en mode insertion pour taper du texte avant le curseur. Taper ESC pour revenir au mode commande ;
  • « x » : effacer un caractère sous le curseur (x comme « faire une croix sur un caractère pour l'effacer »).

Les quelques commandes utiles, toujours à utiliser en mode biiiip :

  • « dd » : pour effacer la ligne sous le curseur (d comme Delete, effacer en Anglais). Pour effacer 2 lignes : « 2dd ». 3 lignes : « 3dd ». Je continue ? ;-) En fait, la ligne n'est pas seulement effacée mais aussi coupée, c.-à-d. recopiée dans un presse-papier ;
  • « yy » : copier la ligne sous le curseur (y comme Yank, tirer d'un coup sec en Anglais). Pour copier 42 lignes : « 42yy » ;
  • « p » : pour coller (p comme Paste, coller en Anglais) les lignes copiées (par « yy ») ou coupées (par « dd » ) après la ligne où se trouve le curseur ;
  • « u » : annuler (u comme Undo, annuler en Anglais) la dernière modification.

Voilà, avec ça vous pouvez vous débrouiller avec vi, je l'ai fait pendant des années. Après, deux-trois autres commandes sont utiles pour jouer au kéké mais on peut survivre sans. :-)

Mise à jour : 2009-05-31, licence Art Libre pour ce billet.


[1] Historiquement, on utilisait les touches « h », « l » (gauche et droite) et « j » et « k » (haut et bas) pour se déplacer, mais ça fait belle lurette que les touches du curseur sont reconnues.