Je suis désolé d'avoir supposé que j'allais pouvoir me ballader dans votre
jardin sans me faire jeter par une bande de *** qui confondent solidarité
avec rigueur et autorité !
Désolé d'avoir "écrit" au dessus et non dessous la réponse et d'avoir
"posté" deux questions différentes mais sur le même sujet !
Débutant j'avais conservé l'espoir que ses forums étaient identiques aux
autres...
Merci quand même à ceux (ils se reconnaîtront) qui n'ont pas fait dans le
'recadrement non constructif et systématique' et avec qui j'ai un peu
progressé sur aix/linux/unix qui LUI un système ouvert !
On a déjà parlé de ça :-( mais en ce qui me concerne, et de façon purement
subjective, je trouve les présentations en colonnes étroites absolument immondes. En particulier les posts formattés sur 60 caractères, ou la largeur
standard de paragraphe de Latex. D'ailleurs je remarque que dans la nouvelle
version de boborama, ils ont considérablement augmenté la largeur de paragraphe et c'est beaucoup plus joli. En bref, je considère que les règles
de limitation de largeur de colonnes soit disant standard sont de grossières
conneries. [...]
Et tu ne crois pas qu'il puisse y avoir une bonne raison a ces largeurs standard, que quelqu'un ait pu reflechir avant de sortir un chiffre ?
Au moins sur usenet et par email essaie de te limiter a 72 sinon 64, ca evite le genre de problemes comme celui observé ci-dessus.
Personnelement, je m'en fous, en ce moment, mon terminal fait 145 caracteres de large et mon logiciel de news/vi ne reformate pas les citations, mais on en etait a pinailler sur les conformances et normes d'usenet (normes qu'il serait plus juste d'appeler conventions/recommandations/usage et qui peuvent varier d'un newsgroup a l'autre) et justement, la RFC 1855 en parle.
-- Stéphane
2006-11-11, 15:08(+00), Michel Talon:
[...]
On a déjà parlé de ça :-( mais en ce qui me concerne, et de façon
purement
subjective, je trouve les présentations en colonnes étroites absolument
immondes. En particulier les posts formattés sur 60 caractères, ou la
largeur
standard de paragraphe de Latex. D'ailleurs je remarque que dans la
nouvelle
version de boborama, ils ont considérablement augmenté la largeur de
paragraphe et c'est beaucoup plus joli. En bref, je considère que les
règles
de limitation de largeur de colonnes soit disant standard sont de
grossières
conneries.
[...]
Et tu ne crois pas qu'il puisse y avoir une bonne raison a ces largeurs
standard, que quelqu'un ait pu reflechir avant de sortir un chiffre ?
Au moins sur usenet et par email essaie de te limiter a 72 sinon 64, ca
evite le genre de problemes comme celui observé ci-dessus.
Personnelement, je m'en fous, en ce moment, mon terminal fait 145
caracteres de large et mon logiciel de news/vi ne reformate pas les
citations, mais on en etait a pinailler sur les conformances et normes
d'usenet (normes qu'il serait plus juste d'appeler
conventions/recommandations/usage et qui peuvent varier d'un newsgroup a
l'autre) et justement, la RFC 1855 en parle.
On a déjà parlé de ça :-( mais en ce qui me concerne, et de façon purement
subjective, je trouve les présentations en colonnes étroites absolument immondes. En particulier les posts formattés sur 60 caractères, ou la largeur
standard de paragraphe de Latex. D'ailleurs je remarque que dans la nouvelle
version de boborama, ils ont considérablement augmenté la largeur de paragraphe et c'est beaucoup plus joli. En bref, je considère que les règles
de limitation de largeur de colonnes soit disant standard sont de grossières
conneries. [...]
Et tu ne crois pas qu'il puisse y avoir une bonne raison a ces largeurs standard, que quelqu'un ait pu reflechir avant de sortir un chiffre ?
Au moins sur usenet et par email essaie de te limiter a 72 sinon 64, ca evite le genre de problemes comme celui observé ci-dessus.
Personnelement, je m'en fous, en ce moment, mon terminal fait 145 caracteres de large et mon logiciel de news/vi ne reformate pas les citations, mais on en etait a pinailler sur les conformances et normes d'usenet (normes qu'il serait plus juste d'appeler conventions/recommandations/usage et qui peuvent varier d'un newsgroup a l'autre) et justement, la RFC 1855 en parle.
-- Stéphane
talon
Stephane Chazelas wrote:
2006-11-11, 15:08(+00), Michel Talon: [...]
On a déjà parlé de ça :-( mais en ce qui me concerne, et de façon purement
subjective, je trouve les présentations en colonnes étroites absolument Et tu ne crois pas qu'il puisse y avoir une bonne raison a ces largeurs
....
standard, que quelqu'un ait pu reflechir avant de sortir un chiffre ?
Au moins sur usenet et par email essaie de te limiter a 72 sinon 64, ca evite le genre de problemes comme celui observé ci-dessus.
C'est sûr qu'avec 3 niveaux de > le problème va apparaître. Tu en aurais mis 10 s'il avait été nécessaire. La limite de largeur conventionnelle est de 80 caractères. Voici ce que raconte tin:
Format your article to fit in less then 80 chars, since that's the conventional size (72 is a good choice as it allows quoting without exceeding the limit).
Ce qui est en accord avec ce que tu dis. Sauf que, si on utilise vi comme éditeur avec textwidthr on va se retrouver à éditer *tout* avec une largeur de colonne de 72 qui est, à mon avis, ridiculement étroite. Aprés tout, le quoting multiniveaux devraît être exceptionnel et il n'y a pas de raison de se baser sur cette éventualité hypothétique pour handicaper la totalité de ce qu'on écrit. J'ai mis le textwidth à 78 ce qui laisse la place pour '> ' sur les lignes faisant la longueur maximale, ce qui est loin d'être le cas de toutes les lignes.
Personnelement, je m'en fous, en ce moment, mon terminal fait 145 caracteres de large et mon logiciel de news/vi ne reformate pas les citations, mais on en etait a pinailler sur les conformances et normes d'usenet (normes qu'il serait plus juste d'appeler conventions/recommandations/usage et qui peuvent varier d'un newsgroup a l'autre) et justement, la RFC 1855 en parle.
Le même RFC parle aussi d'éviter les posts de plus de 12 lignes, ce qui en caractérise l'intérêt. Toutes ces recommandations datent d'une époque préhistorique où les terminaux étaient différents. Peu de gens désormais utilisent autre chose que des lecteurs de news qui de toute façon n'ont plus ces problèmes.
On a déjà parlé de ça :-( mais en ce qui me concerne, et de façon
purement
subjective, je trouve les présentations en colonnes étroites absolument
Et tu ne crois pas qu'il puisse y avoir une bonne raison a ces largeurs
....
standard, que quelqu'un ait pu reflechir avant de sortir un chiffre ?
Au moins sur usenet et par email essaie de te limiter a 72 sinon 64, ca
evite le genre de problemes comme celui observé ci-dessus.
C'est sûr qu'avec 3 niveaux de > le problème va apparaître. Tu en aurais mis
10 s'il avait été nécessaire. La limite de largeur conventionnelle est de 80
caractères. Voici ce que raconte tin:
Format your article to fit in less then 80 chars, since that's the
conventional size (72 is a good choice as it allows quoting
without exceeding the limit).
Ce qui est en accord avec ce que tu dis. Sauf que, si on utilise vi comme
éditeur avec textwidthr on va se retrouver à éditer *tout* avec une largeur
de colonne de 72 qui est, à mon avis, ridiculement étroite. Aprés tout, le
quoting multiniveaux devraît être exceptionnel et il n'y a pas de raison de se
baser sur cette éventualité hypothétique pour handicaper la totalité de ce
qu'on écrit. J'ai mis le textwidth à 78 ce qui laisse la place pour '> ' sur
les lignes faisant la longueur maximale, ce qui est loin d'être le cas de
toutes les lignes.
Personnelement, je m'en fous, en ce moment, mon terminal fait 145
caracteres de large et mon logiciel de news/vi ne reformate pas les
citations, mais on en etait a pinailler sur les conformances et normes
d'usenet (normes qu'il serait plus juste d'appeler
conventions/recommandations/usage et qui peuvent varier d'un newsgroup a
l'autre) et justement, la RFC 1855 en parle.
Le même RFC parle aussi d'éviter les posts de plus de 12 lignes, ce qui en
caractérise l'intérêt. Toutes ces recommandations datent d'une époque
préhistorique où les terminaux étaient différents. Peu de gens désormais
utilisent autre chose que des lecteurs de news qui de toute façon n'ont plus
ces problèmes.
On a déjà parlé de ça :-( mais en ce qui me concerne, et de façon purement
subjective, je trouve les présentations en colonnes étroites absolument Et tu ne crois pas qu'il puisse y avoir une bonne raison a ces largeurs
....
standard, que quelqu'un ait pu reflechir avant de sortir un chiffre ?
Au moins sur usenet et par email essaie de te limiter a 72 sinon 64, ca evite le genre de problemes comme celui observé ci-dessus.
C'est sûr qu'avec 3 niveaux de > le problème va apparaître. Tu en aurais mis 10 s'il avait été nécessaire. La limite de largeur conventionnelle est de 80 caractères. Voici ce que raconte tin:
Format your article to fit in less then 80 chars, since that's the conventional size (72 is a good choice as it allows quoting without exceeding the limit).
Ce qui est en accord avec ce que tu dis. Sauf que, si on utilise vi comme éditeur avec textwidthr on va se retrouver à éditer *tout* avec une largeur de colonne de 72 qui est, à mon avis, ridiculement étroite. Aprés tout, le quoting multiniveaux devraît être exceptionnel et il n'y a pas de raison de se baser sur cette éventualité hypothétique pour handicaper la totalité de ce qu'on écrit. J'ai mis le textwidth à 78 ce qui laisse la place pour '> ' sur les lignes faisant la longueur maximale, ce qui est loin d'être le cas de toutes les lignes.
Personnelement, je m'en fous, en ce moment, mon terminal fait 145 caracteres de large et mon logiciel de news/vi ne reformate pas les citations, mais on en etait a pinailler sur les conformances et normes d'usenet (normes qu'il serait plus juste d'appeler conventions/recommandations/usage et qui peuvent varier d'un newsgroup a l'autre) et justement, la RFC 1855 en parle.
Le même RFC parle aussi d'éviter les posts de plus de 12 lignes, ce qui en caractérise l'intérêt. Toutes ces recommandations datent d'une époque préhistorique où les terminaux étaient différents. Peu de gens désormais utilisent autre chose que des lecteurs de news qui de toute façon n'ont plus ces problèmes.
--
Michel TALON
Rakotomandimby (R12y)
Michel Talon:
Toutes ces recommandations datent d'une époque préhistorique où les terminaux étaient différents.
Il serait d'ailleurs interessant de savoir combien de normes/définitions/appelations établies sont à revoir pour cause d'obsolescence. On commencerait certainement par IP ;-)
Michel Talon:
Toutes ces recommandations datent d'une époque
préhistorique où les terminaux étaient différents.
Il serait d'ailleurs interessant de savoir combien de
normes/définitions/appelations établies sont à revoir pour cause
d'obsolescence. On commencerait certainement par IP ;-)
Toutes ces recommandations datent d'une époque préhistorique où les terminaux étaient différents.
Il serait d'ailleurs interessant de savoir combien de normes/définitions/appelations établies sont à revoir pour cause d'obsolescence. On commencerait certainement par IP ;-)
Stephane Chazelas
2006-11-11, 18:44(+00), Michel Talon: [...]
Ce qui est en accord avec ce que tu dis. Sauf que, si on utilise vi comme éditeur avec textwidthr on va se retrouver à éditer *tout* avec une largeur de colonne de 72 qui est, à mon avis, ridiculement étroite.
Pourquoi tout? Si tu utilises vim (le vi standard n'a pas d'option textwidth anyway), il doit identifier les messages que tu edites dans tin comme etant de type "mail" (et d'ailleurs, vim par defaut definit twr pour ce genre de fichiers).
$ grep tw /usr/share/vim/vim70/ftplugin/mail.vim if &tw == 0 setlocal twr
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr'
Aprés tout, le quoting multiniveaux devraît être exceptionnel et il n'y a pas de raison de se baser sur cette éventualité hypothétique pour handicaper la totalité de ce qu'on écrit. J'ai mis le textwidth à 78 ce qui laisse la place pour '> ' sur les lignes faisant la longueur maximale, ce qui est loin d'être le cas de toutes les lignes. [...]
Petites statistiques sur mon spool de leafnode, sur le niveau d'inclusion maximum des messages (et je ne prends en compte que les inclusions a la "> ").
71% des articles ont des citations. 13% des inclusions multiples, ce n'est pas ce que j'appelle hypothetique.
-- Stéphane
2006-11-11, 18:44(+00), Michel Talon:
[...]
Ce qui est en accord avec ce que tu dis. Sauf que, si on utilise vi comme
éditeur avec textwidthr on va se retrouver à éditer *tout* avec une largeur
de colonne de 72 qui est, à mon avis, ridiculement étroite.
Pourquoi tout? Si tu utilises vim (le vi standard n'a pas
d'option textwidth anyway), il doit identifier les messages que
tu edites dans tin comme etant de type "mail" (et d'ailleurs,
vim par defaut definit twr pour ce genre de fichiers).
$ grep tw /usr/share/vim/vim70/ftplugin/mail.vim
if &tw == 0
setlocal twr
Et sinon, j'imagine que tin te permet de specifier ton editeur
et rien ne t'empeche alors de mettre vim -c 'set twr'
Aprés tout, le
quoting multiniveaux devraît être exceptionnel et il n'y a pas de raison de se
baser sur cette éventualité hypothétique pour handicaper la totalité de ce
qu'on écrit. J'ai mis le textwidth à 78 ce qui laisse la place pour '> ' sur
les lignes faisant la longueur maximale, ce qui est loin d'être le cas de
toutes les lignes.
[...]
Petites statistiques sur mon spool de leafnode, sur le niveau
d'inclusion maximum des messages (et je ne prends en compte que
les inclusions a la "> ").
Ce qui est en accord avec ce que tu dis. Sauf que, si on utilise vi comme éditeur avec textwidthr on va se retrouver à éditer *tout* avec une largeur de colonne de 72 qui est, à mon avis, ridiculement étroite.
Pourquoi tout? Si tu utilises vim (le vi standard n'a pas d'option textwidth anyway), il doit identifier les messages que tu edites dans tin comme etant de type "mail" (et d'ailleurs, vim par defaut definit twr pour ce genre de fichiers).
$ grep tw /usr/share/vim/vim70/ftplugin/mail.vim if &tw == 0 setlocal twr
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr'
Aprés tout, le quoting multiniveaux devraît être exceptionnel et il n'y a pas de raison de se baser sur cette éventualité hypothétique pour handicaper la totalité de ce qu'on écrit. J'ai mis le textwidth à 78 ce qui laisse la place pour '> ' sur les lignes faisant la longueur maximale, ce qui est loin d'être le cas de toutes les lignes. [...]
Petites statistiques sur mon spool de leafnode, sur le niveau d'inclusion maximum des messages (et je ne prends en compte que les inclusions a la "> ").
71% des articles ont des citations. 13% des inclusions multiples, ce n'est pas ce que j'appelle hypothetique.
-- Stéphane
Nicolas George
Stephane Chazelas wrote in message :
71% des articles ont des citations. 13% des inclusions multiples, ce n'est pas ce que j'appelle hypothetique.
D'un autre côté, une double citation est rarement utile, une triple encore plus, et quatre je n'ai jamais vu ça. Donc on peut dire que si ça dépasse avec 76+citations, c'est la faute du goret qui a laissé les citations.
Stephane Chazelas wrote in message
<slrnelca2r.dg2.stephane.chazelas@spam.is.invalid>:
71% des articles ont des citations. 13% des inclusions
multiples, ce n'est pas ce que j'appelle hypothetique.
D'un autre côté, une double citation est rarement utile, une triple encore
plus, et quatre je n'ai jamais vu ça. Donc on peut dire que si ça dépasse
avec 76+citations, c'est la faute du goret qui a laissé les citations.
71% des articles ont des citations. 13% des inclusions multiples, ce n'est pas ce que j'appelle hypothetique.
D'un autre côté, une double citation est rarement utile, une triple encore plus, et quatre je n'ai jamais vu ça. Donc on peut dire que si ça dépasse avec 76+citations, c'est la faute du goret qui a laissé les citations.
talon
Stephane Chazelas wrote:
$ grep tw /usr/share/vim/vim70/ftplugin/mail.vim if &tw == 0 setlocal twr
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr'
...
71% des articles ont des citations. 13% des inclusions multiples, ce n'est pas ce que j'appelle hypothetique.
Je te concède la victoire, tu es trop fort. Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que je regarde meiux. Au moins j'ai appris quelque chose, et peut être d'autres aussi. Merci.
$ grep tw /usr/share/vim/vim70/ftplugin/mail.vim
if &tw == 0
setlocal twr
Et sinon, j'imagine que tin te permet de specifier ton editeur
et rien ne t'empeche alors de mettre vim -c 'set twr'
...
71% des articles ont des citations. 13% des inclusions
multiples, ce n'est pas ce que j'appelle hypothetique.
Je te concède la victoire, tu es trop fort.
Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que
je regarde meiux.
Au moins j'ai appris quelque chose, et peut être d'autres aussi.
Merci.
$ grep tw /usr/share/vim/vim70/ftplugin/mail.vim if &tw == 0 setlocal twr
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr'
...
71% des articles ont des citations. 13% des inclusions multiples, ce n'est pas ce que j'appelle hypothetique.
Je te concède la victoire, tu es trop fort. Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que je regarde meiux. Au moins j'ai appris quelque chose, et peut être d'autres aussi. Merci.
--
Michel TALON
talon
In article <ej5kfa$1tjm$ you wrote:
Stephane Chazelas wrote:
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr' Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que
je regarde meiux.
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais EDITOR='vim -c "set twr"' fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi est plus universel, il n'y a pas vim partout, etc. et EDITOR est une variable que le shell regarde. Je crois que la solution la plus simple est de trafiquer le fichier que tu disais pour en enlever le test sur tw=0. Ca non plus n'est pas universel, mais est un moindre mal, je pense.
--
Michel TALON
In article <ej5kfa$1tjm$1@asmodee.lpthe.jussieu.fr> you wrote:
Et sinon, j'imagine que tin te permet de specifier ton editeur
et rien ne t'empeche alors de mettre vim -c 'set twr'
Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que
je regarde meiux.
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais
EDITOR='vim -c "set twr"'
fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi
est plus universel, il n'y a pas vim partout, etc. et EDITOR est une
variable que le shell regarde. Je crois que la solution la plus simple
est de trafiquer le fichier que tu disais pour en enlever le test sur
tw=0. Ca non plus n'est pas universel, mais est un moindre mal, je
pense.
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr' Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que
je regarde meiux.
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais EDITOR='vim -c "set twr"' fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi est plus universel, il n'y a pas vim partout, etc. et EDITOR est une variable que le shell regarde. Je crois que la solution la plus simple est de trafiquer le fichier que tu disais pour en enlever le test sur tw=0. Ca non plus n'est pas universel, mais est un moindre mal, je pense.
--
Michel TALON
talon
In article <ej5kfa$1tjm$ you wrote:
Stephane Chazelas wrote:
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr' Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que
je regarde meiux.
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais EDITOR='vim -c "set twr"' fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi est plus universel, il n'y a pas vim partout, etc. et EDITOR est une variable que le shell regarde. Je crois que la solution la plus simple est de trafiquer le fichier que tu disais pour en enlever le test sur tw=0. Ca non plus n'est pas universel, mais est un moindre mal, je pense. Sauf que aprés vérification, ça ne fait absolument rien, tw reste à 78, quoiqu'on mette dans mail.vim (setlocal twr ou set twr) bien que le type mail soit reconnu. Bon j'ai la solution qui va bien: mettre ceci dans .vimrc autocmd FileType mail se twr Voilà comme ça je ne vous embêterai plus avec des lignes trop longues.
--
Michel TALON
In article <ej5kfa$1tjm$1@asmodee.lpthe.jussieu.fr> you wrote:
Et sinon, j'imagine que tin te permet de specifier ton editeur
et rien ne t'empeche alors de mettre vim -c 'set twr'
Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que
je regarde meiux.
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais
EDITOR='vim -c "set twr"'
fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi
est plus universel, il n'y a pas vim partout, etc. et EDITOR est une
variable que le shell regarde. Je crois que la solution la plus simple
est de trafiquer le fichier que tu disais pour en enlever le test sur
tw=0. Ca non plus n'est pas universel, mais est un moindre mal, je
pense. Sauf que aprés vérification, ça ne fait absolument rien, tw
reste à 78, quoiqu'on mette dans mail.vim (setlocal twr ou set twr)
bien que le type mail soit reconnu. Bon j'ai la solution qui va bien:
mettre ceci dans .vimrc
autocmd FileType mail se twr
Voilà comme ça je ne vous embêterai plus avec des lignes trop longues.
Et sinon, j'imagine que tin te permet de specifier ton editeur et rien ne t'empeche alors de mettre vim -c 'set twr' Enfin j'ai peur que tin ne trouve son éditeur à partir de EDITOR, il faut que
je regarde meiux.
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais EDITOR='vim -c "set twr"' fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi est plus universel, il n'y a pas vim partout, etc. et EDITOR est une variable que le shell regarde. Je crois que la solution la plus simple est de trafiquer le fichier que tu disais pour en enlever le test sur tw=0. Ca non plus n'est pas universel, mais est un moindre mal, je pense. Sauf que aprés vérification, ça ne fait absolument rien, tw reste à 78, quoiqu'on mette dans mail.vim (setlocal twr ou set twr) bien que le type mail soit reconnu. Bon j'ai la solution qui va bien: mettre ceci dans .vimrc autocmd FileType mail se twr Voilà comme ça je ne vous embêterai plus avec des lignes trop longues.
--
Michel TALON
Stephane Chazelas
2006-11-11, 23:44(+00), Michel Talon: [...]
pense. Sauf que aprés vérification, ça ne fait absolument rien, tw reste à 78, quoiqu'on mette dans mail.vim (setlocal twr ou set twr) bien que le type mail soit reconnu. Bon j'ai la solution qui va bien: mettre ceci dans .vimrc autocmd FileType mail se twr [...]
C'est ce que j'ai aussi, enfin
au FileType mail set formatoptions=tcq twd
-- Stéphane
2006-11-11, 23:44(+00), Michel Talon:
[...]
pense. Sauf que aprés vérification, ça ne fait absolument rien, tw
reste à 78, quoiqu'on mette dans mail.vim (setlocal twr ou set twr)
bien que le type mail soit reconnu. Bon j'ai la solution qui va bien:
mettre ceci dans .vimrc
autocmd FileType mail se twr
[...]
pense. Sauf que aprés vérification, ça ne fait absolument rien, tw reste à 78, quoiqu'on mette dans mail.vim (setlocal twr ou set twr) bien que le type mail soit reconnu. Bon j'ai la solution qui va bien: mettre ceci dans .vimrc autocmd FileType mail se twr [...]
C'est ce que j'ai aussi, enfin
au FileType mail set formatoptions=tcq twd
-- Stéphane
Marwan Burelle
On Sat, 11 Nov 2006 23:44:40 +0000 (UTC) (Michel Talon) wrote:
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais EDITOR='vim -c "set twr"' fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi est plus universel, il n'y a pas vim partout, etc. et EDITOR est une variable que le shell regarde.
Tu pourrais faire ça avec env en aliassant tin sur env EDITOR='vim -c "set twr"' tin
-- BOFH excuse #11:
magnetic interference from money/credit cards
On Sat, 11 Nov 2006 23:44:40 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais
EDITOR='vim -c "set twr"'
fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi
est plus universel, il n'y a pas vim partout, etc. et EDITOR est une
variable que le shell regarde.
Tu pourrais faire ça avec env en aliassant tin sur
env EDITOR='vim -c "set twr"' tin
On Sat, 11 Nov 2006 23:44:40 +0000 (UTC) (Michel Talon) wrote:
En fait je n'ai pas trouvé d'option de tin pour faire ça, mais EDITOR='vim -c "set twr"' fonctionne. Ce n'est pas une solution formidable parceque EDITOR=vi est plus universel, il n'y a pas vim partout, etc. et EDITOR est une variable que le shell regarde.
Tu pourrais faire ça avec env en aliassant tin sur env EDITOR='vim -c "set twr"' tin
