1. Si Desktop n’est pas utilisable, il y a des variables d’environnement ($VISUAL, $EDITOR $ALTERNATE_EDITOR) qui permettent de connaître l’éditeur préféré de l’utilisateur. Il existe aussi parfois (systèmes à base Debian au moins) le lien symbolique /usr/bin/editor. (Sinon on aurait pu glisser sur des réflexions comme « mets Emacs, ça marche ».)
Bon, il faut encore que les utilisateurs renseignent ces variables...
2. Un éditeur en console utilise les capacités de la console (le terminal), ne serait-ce que les déplacements du curseur. La classe Process ne fournit au processus appelé que des flux (des fichiers, System.in/out/err), donc cela empêche parfois le processus d’avoir accès à toutes les capacités du terminal. gvim est dans sa propre fenêtre, donc ça ne lui pose pas de problème. vim veut utiliser la console mais les flux qu’on lui donne ne lui suffisent pas.
En C, on fait un fork() et un exec() et le processus fils récupère directement les flux du père et peut donc utiliser la console sans soucis. Runtime.exec() ressemble plus à un popen() : le processus fils récupère des flux, mais ce ne sont pas les mêmes que celui du père (ce sont des tubes), donc ils ne sont pas directement liés à la console, donc exit l’interactivité (c’est comme si tu lançais "cat | editor" en console (quoique parfois ça fonctionne...)).
[^] # Re: $EDITOR
Posté par Sylvain Sauvage . En réponse au message Ouvrir l'éditeur par défaut dans une console. Évalué à 1.
1. Si Desktop n’est pas utilisable, il y a des variables d’environnement ($VISUAL, $EDITOR $ALTERNATE_EDITOR) qui permettent de connaître l’éditeur préféré de l’utilisateur. Il existe aussi parfois (systèmes à base Debian au moins) le lien symbolique /usr/bin/editor. (Sinon on aurait pu glisser sur des réflexions comme « mets Emacs, ça marche ».)
Bon, il faut encore que les utilisateurs renseignent ces variables...
2. Un éditeur en console utilise les capacités de la console (le terminal), ne serait-ce que les déplacements du curseur. La classe Process ne fournit au processus appelé que des flux (des fichiers, System.in/out/err), donc cela empêche parfois le processus d’avoir accès à toutes les capacités du terminal. gvim est dans sa propre fenêtre, donc ça ne lui pose pas de problème. vim veut utiliser la console mais les flux qu’on lui donne ne lui suffisent pas.
En C, on fait un fork() et un exec() et le processus fils récupère directement les flux du père et peut donc utiliser la console sans soucis. Runtime.exec() ressemble plus à un popen() : le processus fils récupère des flux, mais ce ne sont pas les mêmes que celui du père (ce sont des tubes), donc ils ne sont pas directement liés à la console, donc exit l’interactivité (c’est comme si tu lançais "cat | editor" en console (quoique parfois ça fonctionne...)).