Sur une machine utilisant X11 avec gnome, je cherche =C3=A0 utiliser emacs=
=20
dans un gnome-terminal pour profiter du lissage des polices de caract=C3=A8=
res
dans ce terminal. Une nouvelle fen=C3=AAtre ne sait pas le faire dans la
version courrante.
Je lance donc emacs -nw (la version 21.4.1) et n'arrive pas =C3=A0 obtenir=
=20
les lettres accentu=C3=A9es, alors que je les obtiens si emacs ouvre lui=20
m=C3=AAme une fen=C3=A8tre.
J'ai beau jouer avec des commandes comme cela qui permettait d'avoir un
emacs en =C3=A9tat de marche sur les versions pr=C3=A9c=C3=A9dentes.
J'obtiens selon les cas lorsque je tape sur le e accent (le =C3=A9)
Un scan error
Un carr=C3=A9 vide
Ou un [e accent] suivi d'un blanc.
La premi=C3=A8re erreur est :
Scan error: "Unbalanced parentheses", [position du curseur,position du curs=
eur]
Et dans le *Message*
For information about the GNU Project and its goals, type C-h C-p.
up-list: Scan error: "Unbalanced parentheses", 1, 1
[ctrl-H] k me renvoie un surprenant :
M-c runs the command capitalize-word
(capitalize-word ARG)
which is an interactive built-in function.
lorsque je tape le m=C3=AAme [=C3=A9]
La variable $LANG du syst=C3=A8me est maintenant fr_FR.UTF-8.
En revanche j'ai le plaisir de voir que le [alt-X] dans le gnome-terminal
marche bien, au contraire du m=C3=AAme [alt-X] dans un xterm.
J'obtiens selon les cas lorsque je tape sur le e accent (le é) Un scan error
Mmh ?
Un carré vide
Un carré vide indique qu'Emacs n'a pas trouvé de caractère dans la font ou le fontset courant pour afficher le caractère.
Ou un [e accent] suivi d'un blanc.
La première erreur est : Scan error: "Unbalanced parentheses", [position du curseur,position du curseur]
Et dans le *Message* For information about the GNU Project and its goals, type C-h C-p. up-list: Scan error: "Unbalanced parentheses", 1, 1
Ça c'est bizarre. Peut-être est-ce dû à la différence de paramétrage du système qui semble en utf-8 et d'emacs à qui on de demande de traiter du latin-1 ?
[ctrl-H] k me renvoie un surprenant : M-c runs the command capitalize-word (capitalize-word ARG) which is an interactive built-in function. lorsque je tape le même [é]
La variable $LANG du système est maintenant fr_FR.UTF-8.
Ce qui ne concorde pas avec le set-language-environment déclaré plus haut. Il est important que le paramétrage d'Emacs sur l'environnement coïncide avec la réalité. Utiliser latin-1 pour set-language-environment définit entre autres : (input-method . "latin-1-prefix") (unibyte-display . iso-latin-1) (unibyte-syntax . "latin-1") (nonascii-translation . latin-iso8859-1) (coding-priority iso-latin-1) (coding-system iso-latin-1) (charset ascii latin-iso8859-1)
En revanche j'ai le plaisir de voir que le [alt-X] dans le gnome-terminal marche bien, au contraire du même [alt-X] dans un xterm.
Le 21 January 2006 à 20:58, Francois Maltey vraute :
Je me complète,
après avoir mis ces deux lignes dans .emacs le [e accent aigu] devient deux caractères : [A majuscule tide puis le c du copyright]
Ça c'est le symptôme d'un caractère utf-8 (qui utilise 2 bytes par caractère) traité comme un caractère latin (où les caractères n'utilisent qu'un byte).
J'obtiens selon les cas lorsque je tape sur le e accent (le é)
Un scan error
Mmh ?
Un carré vide
Un carré vide indique qu'Emacs n'a pas trouvé de caractère dans la
font ou le fontset courant pour afficher le caractère.
Ou un [e accent] suivi d'un blanc.
La première erreur est : Scan error: "Unbalanced parentheses",
[position du curseur,position du curseur]
Et dans le *Message*
For information about the GNU Project and its goals, type C-h C-p.
up-list: Scan error: "Unbalanced parentheses", 1, 1
Ça c'est bizarre. Peut-être est-ce dû à la différence de paramétrage du
système qui semble en utf-8 et d'emacs à qui on de demande de traiter du
latin-1 ?
[ctrl-H] k me renvoie un surprenant :
M-c runs the command capitalize-word
(capitalize-word ARG)
which is an interactive built-in function.
lorsque je tape le même [é]
La variable $LANG du système est maintenant fr_FR.UTF-8.
Ce qui ne concorde pas avec le set-language-environment déclaré plus
haut. Il est important que le paramétrage d'Emacs sur l'environnement
coïncide avec la réalité.
Utiliser latin-1 pour set-language-environment définit entre autres :
(input-method . "latin-1-prefix")
(unibyte-display . iso-latin-1)
(unibyte-syntax . "latin-1")
(nonascii-translation . latin-iso8859-1)
(coding-priority iso-latin-1)
(coding-system iso-latin-1)
(charset ascii latin-iso8859-1)
En revanche j'ai le plaisir de voir que le [alt-X] dans le
gnome-terminal marche bien, au contraire du même [alt-X] dans un
xterm.
Le 21 January 2006 à 20:58, Francois Maltey vraute :
Je me complète,
après avoir mis ces deux lignes dans .emacs le [e accent aigu]
devient deux caractères : [A majuscule tide puis le c du copyright]
Ça c'est le symptôme d'un caractère utf-8 (qui utilise 2 bytes par
caractère) traité comme un caractère latin (où les caractères
n'utilisent qu'un byte).
J'obtiens selon les cas lorsque je tape sur le e accent (le é) Un scan error
Mmh ?
Un carré vide
Un carré vide indique qu'Emacs n'a pas trouvé de caractère dans la font ou le fontset courant pour afficher le caractère.
Ou un [e accent] suivi d'un blanc.
La première erreur est : Scan error: "Unbalanced parentheses", [position du curseur,position du curseur]
Et dans le *Message* For information about the GNU Project and its goals, type C-h C-p. up-list: Scan error: "Unbalanced parentheses", 1, 1
Ça c'est bizarre. Peut-être est-ce dû à la différence de paramétrage du système qui semble en utf-8 et d'emacs à qui on de demande de traiter du latin-1 ?
[ctrl-H] k me renvoie un surprenant : M-c runs the command capitalize-word (capitalize-word ARG) which is an interactive built-in function. lorsque je tape le même [é]
La variable $LANG du système est maintenant fr_FR.UTF-8.
Ce qui ne concorde pas avec le set-language-environment déclaré plus haut. Il est important que le paramétrage d'Emacs sur l'environnement coïncide avec la réalité. Utiliser latin-1 pour set-language-environment définit entre autres : (input-method . "latin-1-prefix") (unibyte-display . iso-latin-1) (unibyte-syntax . "latin-1") (nonascii-translation . latin-iso8859-1) (coding-priority iso-latin-1) (coding-system iso-latin-1) (charset ascii latin-iso8859-1)
En revanche j'ai le plaisir de voir que le [alt-X] dans le gnome-terminal marche bien, au contraire du même [alt-X] dans un xterm.
Le 21 January 2006 à 20:58, Francois Maltey vraute :
Je me complète,
après avoir mis ces deux lignes dans .emacs le [e accent aigu] devient deux caractères : [A majuscule tide puis le c du copyright]
Ça c'est le symptôme d'un caractère utf-8 (qui utilise 2 bytes par caractère) traité comme un caractère latin (où les caractères n'utilisent qu'un byte).
Le 22 January 2006 à 22:16, Francois Maltey vraute :
Bonjour tout le monde, merci Sébastien !
Merci d'avoir fait ressortir ces trois notions principales d'emacs : [...]
Ravi d'avoir pu faire avancer le schmillblick. Je me suis déjà bien cassé la tête sur ces problèmes de coding system et je sais que c'est frustrant de ne pas trouver le réglage magique :oP
J'ai réglé le problème en mettant dans mon .emacs :
(when (not window-system)
Je crois que cette forme se simplifie en (unless window-system ...)
Oui, ça paraît bien coller avec le terminal en utf-8 et cette définition est bien protégé avec le test.
J'ai aussi eu besoin de comprendre qu'emacs << devinait automatiquement >> si un fichier était de type latin1 ou utf-8.
Un bon nombre des erreurs décrites dans le premier message provenait du fait que mon fichier de test qui contenait les commandes de configuration en lisp et les lettres accentuées devait mélanger de l'utf-8 et du latin1.
En appliquant ce .emacs à des fichiers latin1 je n'ai plus de problèmes.
Bien.
Il me reste à faire marcher les lettres accentuées majuscules : Le [ctrl X] 8 ' E affiche bien un e-majuscule-accentué mais il apparait dans la ligne de commande qu'il bloque (j'en sors par un [ctrl G]) et pas dans le fil du texte.
Heu, c'est à dire ? L'entrée d'un É dans le minibuffer par exemple avec la touche compose un caps-lock + é fait coincer emacs ?
Le couper/coller d'un less ou d'une autre fenêtre gnome-terminal ne marche pas.
Est-ce que l'autre fenêtre est aussi en utf-8 (Je ne me rappelle plus si tout le système est en utf) ?
Est-ce que ça fonctionne en ajoutant ceci avant la manipulation de codage : C-x RET c utf-8 RET <effectuer le collage>
Je crois que le coding system utilisé pour les opération de copier/scotcher peut se faire interactivement avec C-x RET x ou set-selection-coding-system en lisp.
Le résultat est <<pas mal>>
Le principal c'est qu'avec Emacs on arrive à ce qu'on veut :o)
-- Sébastien Kirche
Le 22 January 2006 à 22:16, Francois Maltey vraute :
Bonjour tout le monde, merci Sébastien !
Merci d'avoir fait ressortir ces trois notions principales d'emacs :
[...]
Ravi d'avoir pu faire avancer le schmillblick. Je me suis déjà bien
cassé la tête sur ces problèmes de coding system et je sais que c'est
frustrant de ne pas trouver le réglage magique :oP
J'ai réglé le problème en mettant dans mon .emacs :
(when (not window-system)
Je crois que cette forme se simplifie en (unless window-system ...)
Oui, ça paraît bien coller avec le terminal en utf-8 et cette définition
est bien protégé avec le test.
J'ai aussi eu besoin de comprendre qu'emacs << devinait
automatiquement >> si un fichier était de type latin1 ou utf-8.
Un bon nombre des erreurs décrites dans le premier message provenait
du fait que mon fichier de test qui contenait les commandes de
configuration en lisp et les lettres accentuées devait mélanger de
l'utf-8 et du latin1.
En appliquant ce .emacs à des fichiers latin1 je n'ai plus de
problèmes.
Bien.
Il me reste à faire marcher les lettres accentuées majuscules : Le
[ctrl X] 8 ' E affiche bien un e-majuscule-accentué mais il apparait
dans la ligne de commande qu'il bloque (j'en sors par un [ctrl G]) et
pas dans le fil du texte.
Heu, c'est à dire ? L'entrée d'un É dans le minibuffer par exemple avec
la touche compose un caps-lock + é fait coincer emacs ?
Le couper/coller d'un less ou d'une autre fenêtre gnome-terminal
ne marche pas.
Est-ce que l'autre fenêtre est aussi en utf-8 (Je ne me rappelle plus si
tout le système est en utf) ?
Est-ce que ça fonctionne en ajoutant ceci avant la manipulation de
codage : C-x RET c utf-8 RET <effectuer le collage>
Je crois que le coding system utilisé pour les opération de
copier/scotcher peut se faire interactivement avec C-x RET x
ou set-selection-coding-system en lisp.
Le résultat est <<pas mal>>
Le principal c'est qu'avec Emacs on arrive à ce qu'on veut :o)
Le 22 January 2006 à 22:16, Francois Maltey vraute :
Bonjour tout le monde, merci Sébastien !
Merci d'avoir fait ressortir ces trois notions principales d'emacs : [...]
Ravi d'avoir pu faire avancer le schmillblick. Je me suis déjà bien cassé la tête sur ces problèmes de coding system et je sais que c'est frustrant de ne pas trouver le réglage magique :oP
J'ai réglé le problème en mettant dans mon .emacs :
(when (not window-system)
Je crois que cette forme se simplifie en (unless window-system ...)
Oui, ça paraît bien coller avec le terminal en utf-8 et cette définition est bien protégé avec le test.
J'ai aussi eu besoin de comprendre qu'emacs << devinait automatiquement >> si un fichier était de type latin1 ou utf-8.
Un bon nombre des erreurs décrites dans le premier message provenait du fait que mon fichier de test qui contenait les commandes de configuration en lisp et les lettres accentuées devait mélanger de l'utf-8 et du latin1.
En appliquant ce .emacs à des fichiers latin1 je n'ai plus de problèmes.
Bien.
Il me reste à faire marcher les lettres accentuées majuscules : Le [ctrl X] 8 ' E affiche bien un e-majuscule-accentué mais il apparait dans la ligne de commande qu'il bloque (j'en sors par un [ctrl G]) et pas dans le fil du texte.
Heu, c'est à dire ? L'entrée d'un É dans le minibuffer par exemple avec la touche compose un caps-lock + é fait coincer emacs ?
Le couper/coller d'un less ou d'une autre fenêtre gnome-terminal ne marche pas.
Est-ce que l'autre fenêtre est aussi en utf-8 (Je ne me rappelle plus si tout le système est en utf) ?
Est-ce que ça fonctionne en ajoutant ceci avant la manipulation de codage : C-x RET c utf-8 RET <effectuer le collage>
Je crois que le coding system utilisé pour les opération de copier/scotcher peut se faire interactivement avec C-x RET x ou set-selection-coding-system en lisp.
Le résultat est <<pas mal>>
Le principal c'est qu'avec Emacs on arrive à ce qu'on veut :o)
