Je sais que le groupe n'est pas dédié, mais je n'ai pas envie de me
noyer dans les groupes dédiés aux shell. De plus, je sais trouver ici
quelques experts.
Donc, je suis passé à bash lors de mon installation de 10.4
(installation toute propre après des années de màj). Auparavant,
j'utilisais encore tcsh, vu que mon compte a été créé sur un 10.0 (je
sais, j'aurais pu changer, mais la flemme, tout ça...).
J'avais personnalisé mon prompt tcsh pour avoir de zoulies couleurs
ainsi que quelques infos.
Comme bash est super fort, je m'attendais à pouvoir faire de même :)
Déjà, première déconvenue, je ne peux pas limiter le nombre d'éléments
affichés lorsque je demande le dossier en cours, dans tcsh, c'était
simple, je mettais "%c3" et hop, il ne m'affichait que les 3 derniers
éléments. Bon, bref, j'apprends à vivre sans dans bash (je suppose qu'il
y a moyen de bidouiller, mais un truc d'origine aurait été sympa).
Deuxième truc (qui découle en partie du premier), je demande l'affichage
complet du chemin et pas simplement la dernière partie et du coup, le
prompt grandit démesurément.
Or là, j'ai un truc bizarre. Si je demande à mettre certaines parties du
prompt en couleur, là, tout reste sur la même ligne, même si elle est
trop courte, très génant. Si j'enlève les couleurs, ça va bien à la
ligne. Voici les deux PS1 que j'ai testé :
- avec couleur (et donc sans passage à la ligne) :
PS1='\033[91m[\h:\w] \033[0m\u\\$\033 '
- sans couleurs (et donc sans soucis de passage à la ligne) :
PS1='[\h:\w] \u\\$ '
Si quelqu'un à une idée, je suis preneur.
D'avance merci et bonnes fêtes de fin d'année,
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Mais ça ne me dit pas ce que je peux faire de ce texte avec plein de caractères asiatiques...
apprendre le japonais pardi ! avec Ruby c'est un MUST )) -- une bévue
Vincent Lefevre
Dans l'article <1h88fas.1vvxzie1iumkx4N%, JPaul écrit:
J'avais personnalisé mon prompt tcsh pour avoir de zoulies couleurs ainsi que quelques infos.
Comme bash est super fort, je m'attendais à pouvoir faire de même :)
Je crois que zsh est encore + fort ;-)
Oui, avec zsh, on peut même avoir une partie du prompt sur la droite (en ce qui me concerne, j'y affiche l'heure).
Perso (dans zsh) je passe le chemin dans la partie droite du prompt (fin de ligne) ce qui fait que la partie gauche reste de longueur raisonnable et quand le chemin devient trop long, il n'est simplement plus affiché.
Chez moi il est à gauche, mais limité à un certain nombre de caractères, le chemin complet étant en titre du terminal, via la fonction precmd. D'ailleurs, voici la mienne:
precmd() { # Suggestion from # From: Atom 'Smasher' # Date: Fri, 23 Jul 2004 12:55:03 -0400 (EDT) # Subject: Re: zsh tips plea (tip of the day) # To: # Message-ID: # and the following thread. # Enabled for zsh 4.1.0 at least (zsh 4.0.6 crashes). [[ -n $zsh410 && -n $TTY && -n $terminfo ]] && print -n "$terminfo[rmacs]$terminfo[sgr0]" > $TTY
if [[ $domain == local.ay && "$(pmu_battery)" == "Battery" ]] then psvar[1]="[$(pmu_percent)%]" else psvar[1]="" fi
Concernant le test sur screen*, c'est que j'affiche d'autres info quand je suis dans screen. Mon .screenrc contient:
hardstatus off hardstatus string "%h%n (%t)" termcapinfo xterm*|rxvt|mlterm|xfce4-terminal hs:ts=E]2;:fs=^G:ds=E]2;TITLEDISABLED^G
En outre j'utilise %~ qui permet de remplacer la partie correspondant à mon répertoire principal par le symbole ~.
Moi aussi.
Les couleurs je n'ai pas testé pour le prompt. Je préfère les conserver pour des commandes telles que ls. Perso je mets juste le prompt en gras.
À noter que lorsqu'on utilise des séquences d'échappement, il faut bien penser à %{ et %} pour éviter des problèmes d'affichage (zsh doit connaître la longueur du prompt).
Quant à la fin de ligne je ne sais pas. A voir dans le manuel de zsh : man zsh et plus précisément : man zshmisc
Voici ma définition de prompt (PS1 = partie gauche et RPS1 = partie droite) : PS1="%B%n (%h)%#%b " # command prompt. RPS1="%B%~ [%*]%b"
La mienne:
putprompt() { local preprompt postprompt prefail postfail
Dans l'article <1h88fas.1vvxzie1iumkx4N%blanc@empty.org>,
JPaul <blanc@empty.org> écrit:
J'avais personnalisé mon prompt tcsh pour avoir de zoulies couleurs
ainsi que quelques infos.
Comme bash est super fort, je m'attendais à pouvoir faire de même :)
Je crois que zsh est encore + fort ;-)
Oui, avec zsh, on peut même avoir une partie du prompt sur la droite
(en ce qui me concerne, j'y affiche l'heure).
Perso (dans zsh) je passe le chemin dans la partie droite du prompt (fin
de ligne) ce qui fait que la partie gauche reste de longueur raisonnable
et quand le chemin devient trop long, il n'est simplement plus affiché.
Chez moi il est à gauche, mais limité à un certain nombre de caractères,
le chemin complet étant en titre du terminal, via la fonction precmd.
D'ailleurs, voici la mienne:
precmd()
{
# Suggestion from
# From: Atom 'Smasher'
# Date: Fri, 23 Jul 2004 12:55:03 -0400 (EDT)
# Subject: Re: zsh tips plea (tip of the day)
# To: zsh-users@sunsite.dk
# Message-ID: <20040723125246.Y326@willy_wonka>
# and the following thread.
# Enabled for zsh 4.1.0 at least (zsh 4.0.6 crashes).
[[ -n $zsh410 && -n $TTY && -n $terminfo ]] &&
print -n "$terminfo[rmacs]$terminfo[sgr0]" > $TTY
if [[ $domain == local.ay && "$(pmu_battery)" == "Battery" ]] then
psvar[1]="[$(pmu_percent)%]"
else
psvar[1]=""
fi
Concernant le test sur screen*, c'est que j'affiche d'autres info quand
je suis dans screen. Mon .screenrc contient:
hardstatus off
hardstatus string "%h%n (%t)"
termcapinfo xterm*|rxvt|mlterm|xfce4-terminal hs:ts=E]2;:fs=^G:ds=E]2;TITLEDISABLED^G
En outre j'utilise %~ qui permet de remplacer la partie correspondant à
mon répertoire principal par le symbole ~.
Moi aussi.
Les couleurs je n'ai pas testé pour le prompt. Je préfère les conserver
pour des commandes telles que ls.
Perso je mets juste le prompt en gras.
À noter que lorsqu'on utilise des séquences d'échappement, il faut
bien penser à %{ et %} pour éviter des problèmes d'affichage (zsh
doit connaître la longueur du prompt).
Quant à la fin de ligne je ne sais pas. A voir dans le manuel de zsh :
man zsh
et plus précisément :
man zshmisc
Voici ma définition de prompt (PS1 = partie gauche et RPS1 = partie
droite) :
PS1="%B%n (%h)%#%b " # command prompt.
RPS1="%B%~ [%*]%b"
La mienne:
putprompt()
{
local preprompt postprompt prefail postfail
Dans l'article <1h88fas.1vvxzie1iumkx4N%, JPaul écrit:
J'avais personnalisé mon prompt tcsh pour avoir de zoulies couleurs ainsi que quelques infos.
Comme bash est super fort, je m'attendais à pouvoir faire de même :)
Je crois que zsh est encore + fort ;-)
Oui, avec zsh, on peut même avoir une partie du prompt sur la droite (en ce qui me concerne, j'y affiche l'heure).
Perso (dans zsh) je passe le chemin dans la partie droite du prompt (fin de ligne) ce qui fait que la partie gauche reste de longueur raisonnable et quand le chemin devient trop long, il n'est simplement plus affiché.
Chez moi il est à gauche, mais limité à un certain nombre de caractères, le chemin complet étant en titre du terminal, via la fonction precmd. D'ailleurs, voici la mienne:
precmd() { # Suggestion from # From: Atom 'Smasher' # Date: Fri, 23 Jul 2004 12:55:03 -0400 (EDT) # Subject: Re: zsh tips plea (tip of the day) # To: # Message-ID: # and the following thread. # Enabled for zsh 4.1.0 at least (zsh 4.0.6 crashes). [[ -n $zsh410 && -n $TTY && -n $terminfo ]] && print -n "$terminfo[rmacs]$terminfo[sgr0]" > $TTY
if [[ $domain == local.ay && "$(pmu_battery)" == "Battery" ]] then psvar[1]="[$(pmu_percent)%]" else psvar[1]="" fi
Concernant le test sur screen*, c'est que j'affiche d'autres info quand je suis dans screen. Mon .screenrc contient:
hardstatus off hardstatus string "%h%n (%t)" termcapinfo xterm*|rxvt|mlterm|xfce4-terminal hs:ts=E]2;:fs=^G:ds=E]2;TITLEDISABLED^G
En outre j'utilise %~ qui permet de remplacer la partie correspondant à mon répertoire principal par le symbole ~.
Moi aussi.
Les couleurs je n'ai pas testé pour le prompt. Je préfère les conserver pour des commandes telles que ls. Perso je mets juste le prompt en gras.
À noter que lorsqu'on utilise des séquences d'échappement, il faut bien penser à %{ et %} pour éviter des problèmes d'affichage (zsh doit connaître la longueur du prompt).
Quant à la fin de ligne je ne sais pas. A voir dans le manuel de zsh : man zsh et plus précisément : man zshmisc
Voici ma définition de prompt (PS1 = partie gauche et RPS1 = partie droite) : PS1="%B%n (%h)%#%b " # command prompt. RPS1="%B%~ [%*]%b"
La mienne:
putprompt() { local preprompt postprompt prefail postfail
Dans l'article <1h89a2g.uzauks1i0go1oN%, Une bévue écrit:
par hasard, j'ai testé ))) <http://cjoint.com/data/mCbm1iYcgS.htm>
un autre exemple : <http://cjoint.com/data/mCbBhrCQHH.htm> j'ai installé une version récente de zsh ))
Ces exemples ne montrent rien concernant zsh, juste la possibilité du terminal à afficher de l'Unicode (et à la rigueur, le bon comportement des locales, si celles-ci sont utilisées).
Dans l'article <1h89a2g.uzauks1i0go1oN%pere.noel@laponie.com>,
Une bévue <pere.noel@laponie.com> écrit:
par hasard, j'ai testé )))
<http://cjoint.com/data/mCbm1iYcgS.htm>
un autre exemple :
<http://cjoint.com/data/mCbBhrCQHH.htm>
j'ai installé une version récente de zsh ))
Ces exemples ne montrent rien concernant zsh, juste la possibilité
du terminal à afficher de l'Unicode (et à la rigueur, le bon
comportement des locales, si celles-ci sont utilisées).
Dans l'article <1h89a2g.uzauks1i0go1oN%, Une bévue écrit:
par hasard, j'ai testé ))) <http://cjoint.com/data/mCbm1iYcgS.htm>
un autre exemple : <http://cjoint.com/data/mCbBhrCQHH.htm> j'ai installé une version récente de zsh ))
Ces exemples ne montrent rien concernant zsh, juste la possibilité du terminal à afficher de l'Unicode (et à la rigueur, le bon comportement des locales, si celles-ci sont utilisées).
Non, ça merdouille sur les caractères accentués. Et en plus ça semble envoyer des choses que iterm n'apprécie pas (terminal semble un peu plus robuste sur le coup).
Il faudrait indiquer la version quand tu dis ce genre de choses. zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0 n'est pas encore sortie, je crois, mais il y a des préversions, qui sont d'ailleurs dans Debian/unstable depuis hier).
Dans l'article <m24q4timyl.fsf@ratagaz.local>,
Erwan David <erwan@rail.eu.org> écrit:
pere.noel@laponie.com (Une bévue) écrivait :
question et UTF-8 avec zsh c'est OK ?
Non, ça merdouille sur les caractères accentués. Et en plus ça semble
envoyer des choses que iterm n'apprécie pas (terminal semble un peu
plus robuste sur le coup).
Il faudrait indiquer la version quand tu dis ce genre de choses.
zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0
n'est pas encore sortie, je crois, mais il y a des préversions, qui
sont d'ailleurs dans Debian/unstable depuis hier).
Non, ça merdouille sur les caractères accentués. Et en plus ça semble envoyer des choses que iterm n'apprécie pas (terminal semble un peu plus robuste sur le coup).
Il faudrait indiquer la version quand tu dis ce genre de choses. zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0 n'est pas encore sortie, je crois, mais il y a des préversions, qui sont d'ailleurs dans Debian/unstable depuis hier).
Dans l'article <1h8a2yn.q5f9nvh9ubpcN%, Une bévue écrit:
Erwan David wrote:
Non, ça merdouille sur les caractères accentués.
effectivement, ça marchotte, mais nettement mieux qu'il y a qq mois... je ne sais si cela est du à mon zsh 4.2.5 ou à MacOS X Tiger d'ailleurs depuis la dernière (ou avant dernière màj)
La 4.2.6 est la dernière.
j'ai des pbs avec TextEdit qui refuse d'ouvrir des documents encodés en UTF-8, document que je pouvais ouvrir AVANT...
Mais ce n'est pas dû à zsh, évidemment.
En ce qui me concerne, j'utilise Emacs (la version de développement), qui supporte bien Unicode. Mais il faut avoir une machine puissante, sinon ça rame au lancement.
Dans l'article <1h8a2yn.q5f9nvh9ubpcN%pere.noel@laponie.com>,
Une bévue <pere.noel@laponie.com> écrit:
Erwan David <erwan@rail.eu.org> wrote:
Non, ça merdouille sur les caractères accentués.
effectivement, ça marchotte, mais nettement mieux qu'il y a qq mois...
je ne sais si cela est du à mon zsh 4.2.5 ou à MacOS X Tiger
d'ailleurs depuis la dernière (ou avant dernière màj)
La 4.2.6 est la dernière.
j'ai des pbs avec TextEdit qui refuse d'ouvrir des documents encodés
en UTF-8, document que je pouvais ouvrir AVANT...
Mais ce n'est pas dû à zsh, évidemment.
En ce qui me concerne, j'utilise Emacs (la version de développement),
qui supporte bien Unicode. Mais il faut avoir une machine puissante,
sinon ça rame au lancement.
Dans l'article <1h8a2yn.q5f9nvh9ubpcN%, Une bévue écrit:
Erwan David wrote:
Non, ça merdouille sur les caractères accentués.
effectivement, ça marchotte, mais nettement mieux qu'il y a qq mois... je ne sais si cela est du à mon zsh 4.2.5 ou à MacOS X Tiger d'ailleurs depuis la dernière (ou avant dernière màj)
La 4.2.6 est la dernière.
j'ai des pbs avec TextEdit qui refuse d'ouvrir des documents encodés en UTF-8, document que je pouvais ouvrir AVANT...
Mais ce n'est pas dû à zsh, évidemment.
En ce qui me concerne, j'utilise Emacs (la version de développement), qui supporte bien Unicode. Mais il faut avoir une machine puissante, sinon ça rame au lancement.
Il faudrait indiquer la version quand tu dis ce genre de choses. zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0 n'est pas encore sortie, je crois, mais il y a des préversions, qui sont d'ailleurs dans Debian/unstable depuis hier).
bonne nouvelle, je viens tout juste d'installer la 4.2.6...
perso avec la 4.2.5 tous c'est la suppression du dernier caractère entré qui ne marchait pas correctement. ça donne l'impression que cette version, avec l'UTF-8, ne supprimer non pas un caractère mais un byte, d'où un comportement étrange... -- une bévue
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Il faudrait indiquer la version quand tu dis ce genre de choses.
zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0
n'est pas encore sortie, je crois, mais il y a des préversions, qui
sont d'ailleurs dans Debian/unstable depuis hier).
bonne nouvelle, je viens tout juste d'installer la 4.2.6...
perso avec la 4.2.5 tous c'est la suppression du dernier caractère entré
qui ne marchait pas correctement.
ça donne l'impression que cette version, avec l'UTF-8, ne supprimer non
pas un caractère mais un byte, d'où un comportement étrange...
--
une bévue
Il faudrait indiquer la version quand tu dis ce genre de choses. zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0 n'est pas encore sortie, je crois, mais il y a des préversions, qui sont d'ailleurs dans Debian/unstable depuis hier).
bonne nouvelle, je viens tout juste d'installer la 4.2.6...
perso avec la 4.2.5 tous c'est la suppression du dernier caractère entré qui ne marchait pas correctement. ça donne l'impression que cette version, avec l'UTF-8, ne supprimer non pas un caractère mais un byte, d'où un comportement étrange... -- une bévue
pere.noel
Vincent Lefevre <vincent+ wrote:
Mais ce n'est pas dû à zsh, évidemment.
non non, amha, c'est lié à MacOS X, mais où...
En ce qui me concerne, j'utilise Emacs (la version de développement), qui supporte bien Unicode. Mais il faut avoir une machine puissante, sinon ça rame au lancement.
perso j'ai un iMac 1.8 Ghz G5 avec 752 Mo de ram serait-ce un bon candidat, ça se trouve où cette verion d'Emacs ? install par ./configure+make+make install avec les bons args ? -- une bévue
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Mais ce n'est pas dû à zsh, évidemment.
non non, amha, c'est lié à MacOS X, mais où...
En ce qui me concerne, j'utilise Emacs (la version de développement),
qui supporte bien Unicode. Mais il faut avoir une machine puissante,
sinon ça rame au lancement.
perso j'ai un iMac 1.8 Ghz G5 avec 752 Mo de ram serait-ce un bon
candidat, ça se trouve où cette verion d'Emacs ?
install par ./configure+make+make install avec les bons args ?
--
une bévue
En ce qui me concerne, j'utilise Emacs (la version de développement), qui supporte bien Unicode. Mais il faut avoir une machine puissante, sinon ça rame au lancement.
perso j'ai un iMac 1.8 Ghz G5 avec 752 Mo de ram serait-ce un bon candidat, ça se trouve où cette verion d'Emacs ? install par ./configure+make+make install avec les bons args ? -- une bévue
Vincent Lefevre
Dans l'article <1h8c5s4.khgddv1iy380fN%, Une bévue écrit:
Vincent Lefevre <vincent+ wrote:
Il faudrait indiquer la version quand tu dis ce genre de choses. zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0 n'est pas encore sortie, je crois, mais il y a des préversions, qui sont d'ailleurs dans Debian/unstable depuis hier).
bonne nouvelle, je viens tout juste d'installer la 4.2.6...
perso avec la 4.2.5 tous c'est la suppression du dernier caractère entré qui ne marchait pas correctement.
ni avec la 4.2.6, mais avec la 4.3.0-dev-1 sous Debian, ça fonctionne.
Cependant, cela ne règle pas le problème du "cooked mode" (indépendant du shell), par exemple quand tu fais "cat[Enter]éèê[BS][BS][Enter]". Sous Linux avec uxterm, ça fonctionne bien (j'obtiens "é"), mais sous Mac OS X, avec n'importe quel terminal, j'obtiens "éè" (en UTF-8, je le rappelle).
Dans l'article <1h8c5s4.khgddv1iy380fN%pere.noel@laponie.com>,
Une bévue <pere.noel@laponie.com> écrit:
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Il faudrait indiquer la version quand tu dis ce genre de choses.
zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0
n'est pas encore sortie, je crois, mais il y a des préversions, qui
sont d'ailleurs dans Debian/unstable depuis hier).
bonne nouvelle, je viens tout juste d'installer la 4.2.6...
perso avec la 4.2.5 tous c'est la suppression du dernier caractère entré
qui ne marchait pas correctement.
ni avec la 4.2.6, mais avec la 4.3.0-dev-1 sous Debian, ça fonctionne.
Cependant, cela ne règle pas le problème du "cooked mode" (indépendant
du shell), par exemple quand tu fais "cat[Enter]éèê[BS][BS][Enter]".
Sous Linux avec uxterm, ça fonctionne bien (j'obtiens "é"), mais sous
Mac OS X, avec n'importe quel terminal, j'obtiens "éè" (en UTF-8, je
le rappelle).
Dans l'article <1h8c5s4.khgddv1iy380fN%, Une bévue écrit:
Vincent Lefevre <vincent+ wrote:
Il faudrait indiquer la version quand tu dis ce genre de choses. zsh commence à supporter UTF-8 à partir de la branche 4.3 (la 4.3.0 n'est pas encore sortie, je crois, mais il y a des préversions, qui sont d'ailleurs dans Debian/unstable depuis hier).
bonne nouvelle, je viens tout juste d'installer la 4.2.6...
perso avec la 4.2.5 tous c'est la suppression du dernier caractère entré qui ne marchait pas correctement.
ni avec la 4.2.6, mais avec la 4.3.0-dev-1 sous Debian, ça fonctionne.
Cependant, cela ne règle pas le problème du "cooked mode" (indépendant du shell), par exemple quand tu fais "cat[Enter]éèê[BS][BS][Enter]". Sous Linux avec uxterm, ça fonctionne bien (j'obtiens "é"), mais sous Mac OS X, avec n'importe quel terminal, j'obtiens "éè" (en UTF-8, je le rappelle).
Dans l'article <1h8c5yv.ejg5r1o1cuwN%, Une bévue écrit:
Vincent Lefevre <vincent+ wrote:
Mais ce n'est pas dû à zsh, évidemment.
non non, amha, c'est lié à MacOS X, mais où...
C'est lié à l'éditeur.
En ce qui me concerne, j'utilise Emacs (la version de développement), qui supporte bien Unicode. Mais il faut avoir une machine puissante, sinon ça rame au lancement.
perso j'ai un iMac 1.8 Ghz G5 avec 752 Mo de ram serait-ce un bon candidat, ça se trouve où cette verion d'Emacs ? install par ./configure+make+make install avec les bons args ?
J'utilise DarwinPorts. Après avoir installé DarwinPorts, il suffit d'un "sudo port -v install emacs-devel +carbon".
Pour pouvoir lancer emacs depuis un shell (comme sur un Unix traditionnel), j'ai le script suivant dans mon $HOME/bin:
Dans l'article <1h8c5yv.ejg5r1o1cuwN%pere.noel@laponie.com>,
Une bévue <pere.noel@laponie.com> écrit:
Vincent Lefevre <vincent+news@vinc17.org> wrote:
Mais ce n'est pas dû à zsh, évidemment.
non non, amha, c'est lié à MacOS X, mais où...
C'est lié à l'éditeur.
En ce qui me concerne, j'utilise Emacs (la version de développement),
qui supporte bien Unicode. Mais il faut avoir une machine puissante,
sinon ça rame au lancement.
perso j'ai un iMac 1.8 Ghz G5 avec 752 Mo de ram serait-ce un bon
candidat, ça se trouve où cette verion d'Emacs ?
install par ./configure+make+make install avec les bons args ?
J'utilise DarwinPorts. Après avoir installé DarwinPorts, il suffit
d'un "sudo port -v install emacs-devel +carbon".
Pour pouvoir lancer emacs depuis un shell (comme sur un Unix
traditionnel), j'ai le script suivant dans mon $HOME/bin:
Dans l'article <1h8c5yv.ejg5r1o1cuwN%, Une bévue écrit:
Vincent Lefevre <vincent+ wrote:
Mais ce n'est pas dû à zsh, évidemment.
non non, amha, c'est lié à MacOS X, mais où...
C'est lié à l'éditeur.
En ce qui me concerne, j'utilise Emacs (la version de développement), qui supporte bien Unicode. Mais il faut avoir une machine puissante, sinon ça rame au lancement.
perso j'ai un iMac 1.8 Ghz G5 avec 752 Mo de ram serait-ce un bon candidat, ça se trouve où cette verion d'Emacs ? install par ./configure+make+make install avec les bons args ?
J'utilise DarwinPorts. Après avoir installé DarwinPorts, il suffit d'un "sudo port -v install emacs-devel +carbon".
Pour pouvoir lancer emacs depuis un shell (comme sur un Unix traditionnel), j'ai le script suivant dans mon $HOME/bin:
