[Texmacs-dev] [plutot long] Quelques remarques et suggestions a propos de TeXmacs (fwd)

[Joris van der Hoeven]

Bonjour,

Merci beaucoup pour cet email en effet assez long.
Nous allons répondre en détail dans les semaines à venir.
En attendant, je l'ai forwardé aux autres développeurs.
Encore merci pour le temps de rédiger un email si détaillé,

Joris


P.S. : désolé pour la répétition.

---------- Forwarded message ----------
Date: Sat, 25 May 2002 17:39:26 +0200
From: Marc Mezzarobba <address@hidden>
To: address@hidden
Subject: [plutot long] Quelques remarques et suggestions a propos de TeXmacs

Bonjour,

Avant tout, un avertissement : je suis en prépa. Cela signifie que je
n'ai pas franchement beaucoup de loisirs, et donc :
- que je n'ai pas consacré à l'exploration de TM le temps qu'elle aurait
  mérité : certaines de mes remarques se rapportent probablement à des
  choses que je n'ai pas vues ou mal comprises ;
- que ce que je dis n'est peut-être plus vrai ;
- que ce que je dis n'est probablement pas exploitable en l'état, mais
  que je n'ai pas le temps de l'étoffer ;
- que je ne pourrai pas essayer d'implémenter moi-même les
  fonctionnalités dont je rêve (du moins dans l'année qui vient et plus
  probablement les deux prochaines années !).
J'ai malgré tout quelques remarques à faire sur TeXmacs. Il s'agit d'un
mélange de questions, de suggestions, de rapport de bugs présumés, etc.
Si elles peuvent servir à quelque chose, tant mieux, sinon ignorez-les,
tout de suite ou après les avoir lues ! Bien entendu, ce n'est qu'un
avis très partial, discutablle, d'autant qu'il y a peut-être des choses
qui m'échappent complètement dans la « philosophie » du logiciel.


Chapitre 1 -- Les qualités de TM

Pour éclairer mon point de vue dans l'optique de la suite, voilà quels
sont àmha les principaux avantages de TM, auxquels il ne faut renoncer à
aucun prix (et qu'il faut continuer à améliorer !).

Avant tout, la facilité de saisie, en particulier pour les maths
(combinaisons de touches appropriées, entrée naturelle d'équivalents
(La)TeX, etc.) : de ce point de vue, TM est plus ergonomique que Lyx.
Viennent ensuite la rapidité relative qu'il a fini par acquérir (il
tourne à une vitesse acceptable sur mon K6-233), et le concept
(l'édition wysiwig sructurée), qui est sympa mais pas vital (i.e. je
préfère LyX pour certaines choses). Plus spécifiquement, j'apprécie les
arbres et les exposants / indices « hauts » et « bas ».

Un mot sur mon traitement de texte *wysiwyg* préféré jusqu'ici :
WordPerfect 6.0 pour Windows 3.1x, auquel je ferai référence dans la
suite. C'est à ma connaissance, parmi les traitement de textes
traditionnels, celui qui offre (ou offrait : je ne peux pas avoir de
version plus récente faute de Win32, et la version Linux gratuite n'est
pas pratique) le meilleur compromis avec l'édition « structurée », avec
une interface adaptée. Il possède en particulier une fenêtre d'affichage
des « codes », et un système de styles « intelligent ». Les styles en
question sont des collections d'attributs ayant un sens. Ils peuvent
être imbriqués ; on peut les regrouper sur plusieurs niveau pour créer
des plans ; et on peut leur associer un comportement de l'éditeur (p.ex.
« si j'apuie sur entrée après un titre de niveau 2, insérer
automatiquement un titre de niveau 3 »), tout en gardant la possibilité
d'annuler au coup par coup les actions automatiques. Pour finir sur WP,
j'ajoute que TM et OpenOffice.org pourraient, chacun dans leur domaine,
le surpasser sous peu à mes yeux.


Chapitre 2 -- L'interface, première partie : les composants grpahiques

J'ai cru comprendre que TM allait passer à Gtk ; cela me semble une très
bonne idée. Un passage à un toolkit standard serait aussi l'occasion de
remplacer / compléter certaines options perdues dans les menus et
certaines lectures sur la barre d'état par des boîtes de dialogue :
l'interface « à la emacs » n'a pas que des avantages !

J'apprécierais que le menu principal soit (ou puisse être) un menu
standard gtk : si les polices TeX sont utiles dans la barre d'outils,
elles sont superflues dans les menus, et la navigation dans le menu
actuel est horriblement lente. Au passage, il semble que certains menus
aient une facheuse tendance à lire sur le disque (et pas seulement dans
le swap) quand on les ouvre. C'est désagréable quand on a arrêté un
disque dur bruyant pour écrire tranquilement. Toujours à propos des
menus, pourquoi ne pas cocher l'option activée quand plusieurs entrées
sont mutuellement exclusives ?

Les macros, fonctions et autres assign ne sont pas très lisibles : il
faudrait leur permettre de s'étendre sur plusieurs lignes et d'être
indentés.

Enfin et surtout, une fonctionnalité dont je rêve pour tous les
traitement de textes que j'aime bien : une fenêtre d'édition des codes à
la WordPerfect. Cela me semble particulièrement facile à implémenter
dans TM, puisqu'il travaille directement sur un arbre représentant la
structure du texte. Il s'agirait de permettre de diviser en deux
horizontalement la fenêtre d'édition, la partie du bas affichant non pas
la version wysiwyg du document, mais quelque chose entre le mode
preambule et le format d'enregistrement. Le point d'insertion se
déplacerait en parallèle dans les deux fenêtres, et on pourrait apporter
des modifications indifféremment dans les deux. Cela permettrait
éventuellement de se débarrasser totalement du mode préambule (bonne
chose àmha) qui manque vraiment de clarté, et de rendre la fenêtre
wysiwyg vraiment conforme au résultat.

Dans le même ordre d'idée, une fenêtre permettant d'explorer l'arbre du
document affiché sous forme arborescente serait un gadget utile.


Chapitre 3 -- L'interface, deuxième partie : l'utilisation

La gestion de la souris actuelle est bonne mais insuffisante. Dans
certaines circonstances, des menus *contextuels* obtenus avec le bouton
droit seraient précieux (par exemple pour la mise en forme des
tableaux).

La remontée d'un niveau avec la flèche vers la droite n'est pas très
pratique, il se retrouve facilement à imbriquer des choses
involontairement. Le système de sortie des maths ($) mériterait d'être
(un peu) étendu. De même, certaines séquences (application d'un style à
un texte vide) pourraient être supprimées automatiquement du document.
Je suis conscient que plusieurs <em>, par exemple, doivent pouvoir être
imbriqués, mais je ne vois pas l'intérêt de « maths, fin maths, maths ».

Je n'ai pas non plus compris comment désactiver un style ; si je
sélectionne un texte pour y appliquer un style, celui-ci s'étend
correctement. Mais comment *retirer* un attribut sans déplacer le texte
qu'il contient ?

Pourquoi [->] en fin de ligne ne passe-t-il pas à la ligne ?

La signification de « expand » et de « avec » sur la ligne d'état n'est
pas très intuitive (du moins en français !).

J'aimerais pouvoir naviguer facilement entre les différents niveaux de
plan et de liste : au lieu de choisir à chaque fois l'environnement
correspondant dans le menu ou par un raccourci clavier, je voudrais
pouvoir insérer (avec un seul raccourci !) le niveau de plan ou de liste
en cours. Il serait ensuite possible (par exemple avec Tab et
Shift + Tab) de passer au niveau au-dessus ou au-dessous. On pourrait de
même revenir au texte standard en effaçant (backspace) le numéro ou la
puce.

Il serait aussi très pratique de pouvoir transformer instantanément une
equation en eqnarray (quand on commence à écrire une formule qui va
finalement s'étendre sur plusieurs lignes).

Enfin, j'aimerais avoir la possibilité de créer deux sortes de
raccourcis bien distincts. D'une part les macros / fonctions,
enregistrées comme telles, ayant un sens, modifiables après coup, et
d'autre part des simples raccourcis (sensibles à l'état des variables
d'environnement), remplacés à la saisie. Je ne veux pas créer une macro
pour taper plus rapidement le V cursif dans un texte qui l'utilise tout
le temps, s'il ne s'agit pas d'une notation ayant un sens particulier
(et uniforme) et susceptible de changer. La portée de ces raccourcis
devrait être variable : globale (dépendant éventuellement de la classe
de document) ou limitée au document en cours (raccourcis enregistrés
dans le préambule).


Chapitre 4 -- Le moteur de rendu et la structuration du texte

L'idéal serait de pouvoir insérer des élément (La)TeX de façon souple
pour ce que TM ne fait pas encore. Mais ne rêvons pas. À défaut, il
faudrait une fonction pour insérer des *symboles* (isolés) arbitraires.

Les equation sont toujours centrées. Comment les obtenir alignées à
gauche et indentées ? Je trouve ça beaucoup plus agréable pour taper de
longs calculs.

Alors que TM est devenu assez rapide, le passage du mode préambule au
mode normal est *très* long. Une raison de plus pour l'exterminer. ;-)

Le mode mathématique ne semble pas gérer les caractères (romains)
accentués.

La distinction entre ce qui est / sera du domaine de Guile et ce qui est
du domaine des fonctions de programmation de TM n'est pas claire, dans
mon exprit du moins. Pas plus que la manière de les interfacer.


Chapitre 5 -- Bugs ?

TeXmacs traduit parfois des chaînes non pertinentes, en particulier les
noms de fichier dans la boîte de dialogue d'ouverture.

La gestion du répertoire courant (celui du document en cours) est
non-standard et pas très pratique. La navigation de répertoire en
répertoire dans le dialogue d'ouverture de fichier est malaisée. Un
bouton pour aller directement dans le répertoire de TM (pour consulter
les modèles, etc.) serait le bienvenu.

Certains noms de « n?uds » (affichés à droite) sont vraiment trop longs,
du moins en version française.

Le seul moyen que j'ai trouvé pour obtenir une présentation du type :

Théorème. Soit u une application linéaire et khi son
    polynôme caractéristique. On a alors
        khi(u) = 0.
    Le polynôme minimal du u divise son polynôme
    caractéristique.

consiste à décaler la marge puis à insérer un espacement horizontal
négatif.  Ce n'est pas propre. Plus embêtant, tout ce passe comme il
faut en insérant un espace néatif au début d'un environnement comme
verse, qui décale les marges. En revanche, je n'arrive pas à obtenir le
même résultat en créant une macro qui insère elle-même l'espacement
négatif. J'obtiens alors des tas de choses bizarres. En particulier, dès
que la ligne logique est plus longue qu'une ligne physique, la marge
droite n'est plus prise en compte et le texte inséré par al macro se
trouve isolé sur une ligne. (Désolé, pas d'exemple de code sous la
main !)


Chapitre 6 -- Divers

En fait, la principale chose qui manque à TM, c'est de la doc ! Le Wiki
est un pas en avant, mais... En revanche, la doc actuelle (concise !)
est bien faite, au sens qu'elle apprend énormément en peu de pages.

Il faudrait un script ou des documents d'exemple chargés pour générer
des jeux de polices complet à l'avance.

D'après l'aide, les paramètre de fonction se comportent comme des
variables d'environnement. Pourtant on ne les récupère pas avec <value|>
mais avec <apply|>. D'ailleurs, c'est pareil pour les variables
d'environnement, non ?

La portée des variables et des paramètres n'est pas calirement définie,
ou pas documentée.

D'autres packages de théorèmes (non numérotés ; théorèmes, remarques en
compagnie tous formatés comme des remarques ; etc.) seraient facile à
ajouter mais feraient gagner du temps et éviteraient des ahcks maison
douteux.


...Voilà, « c'étaient mes deux centimes d'euro ».


Cordialement,

Marc Mezzarobba


PS -- Ce message a fini beaucoup plus long que je ne le prévoyais au
départ. Si jamais vous avez des questions (ou des réponses !) sur l'un
ou l'autre point, j'essaierai d'y répondre à mon tour, mais je ne peux
rien promettre quant aux délais.

-- 
Marc Mezzarobba