Je sais que la question parait trollesque à souhait. Elle n'en est pas moins complètement honnête. Je suis un peu perdu ces temps-ci.
Je souhaite retrouver le plaisir d'échanger, de correspondre dans mes emails (j'en parle ici : https://ploum.net/pour-un-logiciel-de-correspondance-plutot-quun-client-mail/ ). Et force est de constater qu'aucun logiciel de mail traditionnel n'y arrive réellement.
En fait, sous Linux, les options sont plus que limitées : Thunderbird, principalement, sinon Geary, qui est très buggué et Kmail, qui dépend de toute la stack KDE (que je n'utilise pas).
Bref, est-il possible de revenir aux bases, à savoir Vim/Mutt ou Emacs ?
Ça l'est certainement pour beaucoup d'entre vous mais je parle pour moi, dont le Vim est rouillé et dont la connaissance Emacs est inexistante.
Quels sont vos setups mails relativement simples (j'ai tenté une installation Mutt/Notmuch et c'était hallucinant de complexité à mettre en place) qui vous permettent d'être efficaces pour lire dans une inbox unifiée, écrire, archiver et rechercher dans plusieurs comptes simplement des mails sans devoir se farcir les myriades de dossiers, de boutons et autres fonctionnalités propres aux clients mails modernes ?
(la version blog un poil plus fouillée de ce journal : https://ploum.net/le-courriel-avec-vim-ou-avec-emacs/ )
# emacs + mu4e
Posté par openbar . Évalué à 8.
Pour les mails perso et le boulot, j'utilise emacs + mu4e (les boites sont gérées par ovh et gandi), ça marche assez bien, passé la phase de configuration initiale, qui m'a pris un peu de temps, ça fait 2/3 ans que je ne passe plus de temps à la configurer, ou quoi que ça soit.
L'avantage d'emacs, si tu utilises orgmode par exemple, c'est que tu peux "capturer" tes emails, c'est à lire definir un lien dans vers un email que tu manipule dans un fichier texte. Et donc tu peux mettre le lien vers un email dans le texte d'un todo.
La recherche, la lecture, l'archivage est rapide (je fais du zero inbox). Par contre je ne suis pas averti immediatement à la reception d'un email (ni ensuite d'ailleurs), il faut attendre que offlineimap passe (ce qu'il fait toutes les 5 minutes)
[^] # Re: emacs + mu4e
Posté par ploum (site web personnel, Mastodon) . Évalué à 5.
Le lien vers un mail dans un fichier texte, j'en rêve ! Ce serait vraiment top !
Et j'ai de toutes façons désactivé toutes les notifications.
Bref, tu me motives à apprendre un peu la bête, faut que je trouve un bon tuto.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: emacs + mu4e
Posté par dzecniv . Évalué à 10.
On peut avoir de belles interface avec Emacs et mu4e. Cf cet exemple récent: https://www.reddit.com/r/emacs/comments/jvnzxl/mu4e_dashboard_using_orgmode_with_mu4e_links/
Et des extensions ont été développées pour ce client (vue en conversation, "complétion" de contacts, notifications…) : https://wikemacs.org/wiki/Mu4e Et je suis sûr qu'il y en a plus.
[^] # Re: emacs + mu4e
Posté par QuietApe . Évalué à 1.
Un des avantages d’emacs dans ce cas est aussi la possibilité d'utiliser grammalecte (via flycheck-grammalecte) et de le configurer pour à peu près tout les modes qu'on veut. C'est particulièrement agréable avec org-mode, écrire des mails et pour LaTeX !
[^] # Re: emacs + mu4e
Posté par saltimbanque (site web personnel) . Évalué à 4.
mu4e est sans conteste l'un des modes emacs les plus réussis, avec par exemple magit. Emacs se prête très bien au mail car le fait d'être configurable - programmable - permet de résoudre tout vœu, et le mail s'y prête bien.
Je ne suis pas sûr que sur vim on arrive aussi bien, par exemple à afficher les images. Ou encore programmer toute sorte de chose pour rédiger ses mails. A mon sens vim est surtout extrêmement efficace pour écrire/coder, mais pas si on veut sortir un peu du cadre.
De plus comme mentionné dans d'autres commentaires, il est possible de rester sur les raccourcis vim, ou pourquoi pas des raccourcis plus modernes tels que control+c control+v.
La seule frustration que j'ai, ce n'est pas cette partie, c'est de devoir se synchro sa boite mail en local. Mais bon après les perf sont au rendez vous c'est sûr.
[^] # Re: emacs + mu4e
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Ça donne vraiment envie. Vous avez des conseils pour se mettre à Emacs à partir de rien ? (et en Bépo)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: emacs + mu4e
Posté par saltimbanque (site web personnel) . Évalué à 4.
On pourrait recommander nombre d'intro youtube foireuses. Mais je dirai surtout, apprendre elisp, le lisp de emacs. On ne recommanderait pas cela à tous, mais si tu aimes programmer, pourquoi pas? même ceux qui n'aiment pas particulièrement la syntaxe le trouveront simple. Dans emacs tout est fonction. Un raccurcis clavier invoque une fonction. Avec "control-h f" tu peux voir une description de cette fonction, voir son code, voire redéfinir cette fonction (et tout casser). Evidemment on édite sa configuration emacs en elisp, dans le même language que le programme.
Sinon un mode excellent pour débuter : which-key, qui est un affichage des raccourcis disponibles.
Pour aller au delà, le problème est qu'on a tous nos lubies à nos goûts : il y a plusieurs systèmes de complétions (come les complétions dans un terminal, dont comme helm ou ivy), des systèmes de raccourcis, des modes pour coder, pour tout. Il y a des distrib emacs qui ont tout revu à leur propre goût. Mais elisp dans tous les cas on en a besoin. Et which-key car j'ai déjà lu des utilisateurs regretter de l'avoir découvert trop tard.
Le wiki emacs est une bonne source d'info, même si on peut regretter certaines vieilleries. Pour beaucoup de choses ils répond. Il y a bien sûr tout plein de emacs sur linuxfr
[^] # Re: emacs + mu4e
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Merci. Si on peut passer les tutos youtube, ça me va. Je ne supporte pas ça. J'ai besoin de lire les choses (encore plus pour un éditeur de texte).
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: emacs + mu4e
Posté par saltimbanque (site web personnel) . Évalué à 5.
Au lancement de Emacs il y a un lien vers un tuto assez court, qu'il faut faire. Ensuite il y a plein d'aide dans Emacs. "Control+h i" pour info, va afficher toutes sortes d'aides, dont le manuel elisp. De manière générale les premières choses à apprendre, sont comment accéder aux illimités aides et fonctionnalités dans Emacs : lire les fonctions, les variables (ou les modifier), les manuels, installer des packages…
En ligne il y a les célèbres bloggeurs Emacs. Sans doute pas mal de commencer par Sacha Chua https://sachachua.com/blog/emacs/ .
La cheatsheet officielle peut aider à démarrer https://www.gnu.org/software/emacs/refcards/pdf/refcard.pdf
[^] # Re: emacs + mu4e
Posté par Elfir3 . Évalué à 3.
J'aurais tendance à dire qu'il y a deux écoles pour débuter avec emacs:
- commencer avec une configuration emacs vide, et un système épuré pour faire entrer la base, puis étendre emacs avec les outils dont tu as besoin
- commencer avec une configuration déjà en place que tu n'a plus qu'à personnaliser sur des détails
J'aurais tendance à dire que jeter un œil à des configurations prémachées comme Spacemacs ou Doom est pas mal pour se faire une idée de ce que à quoi tu peux arriver et te permettre de rentrer dans le vif du sujet. C'est ce que je recommanderais de base. Tu as de la doc, pas besoin de comparer les différents modes des fonctionnalités dont tu veux disposer et dans mes souvenirs tout est fait pour permettre de découvrir facilement les commandes disponibles.
Maintenant, si ton but est de te limiter aux mails, et de prendre le temps de découvrir petit à petit sur base de la documentation du mode, partir de la configuration de base peut avoir du sens.
Tout dépend de ta patience et de ton objectif :-)
[^] # Re: emacs + mu4e
Posté par openbar . Évalué à 3.
Avant j'utilisais Vim, du coup je me suis d'abord orienté vers quelque chose de type spacemacs, mais ensuite je me suis rendu compte que les raccourcis claviers de type ne s'intégraient pas trés bien dans les différents packages emacs, notamment dans mu4e, du coup j'ai fait un retour aux bases, j'ai décidé d'apprendre les raccourcis claviers natifs emacs pour se deplacer dans un texte (je suis en bépo aussi), sans remapper le clavier, ce qui a plusieurs avantages, car ces raccourcis sont utilisables tels quels dans la plupart des terminaux bash/zsh (c'est la librairie readline il me semble) du coup j'ai grandement gagné en efficacité dans mon utilisation de la ligne de commande.
On peut même mettre ces raccourcis dans gnome (ou gtk je sais plus), et donc les utiliser dans n'importe quel champs de saisie de texte graphique sur ton ordinateur.
J'ai donc commencé une nouvelle configuration d'emacs from scratch (maintenant j'ai 1800 lignes dans mon .emacs il faudrait que je nettoie un peu ça).
Qu'est ce qu'il m'aurait le plus aidé au début? je pense quelqu'un pour répondre aux dizaines de petites questions que je me posais sur le fonctionnement d'emacs. Si tu arrives à ce moment ou tu apprends via la doc et les tutoriaux, mais que tu as pas mal de questions sur certains trucs, on peut, si tu veux, faire un appel avec partage d'écran et je t'expliquerais ce que je pourrais! Tu peux me contacter à kkkpl chez pessemes.se
[^] # Re: emacs + mu4e
Posté par saltimbanque (site web personnel) . Évalué à 3.
La communauté qui maintient evil maintient une "collection" de raccourcis clavier pour de nombreux packages, qui permettent de garder une cohérence vim dans toutes les fonctionnalités.
https://github.com/emacs-evil/evil-collection
Cela pose question. On ne peut pas dire que ce soit absurde puisque cela fonctionne et la communauté étant suffisante, cela peut parfaitement être maintenu. Et l'avantage et que cela permet de gérer les raccourcis pour tout, sans pour autant adopter une distrib comme spacemacs qui a sa philosophie propre pour tout.
Mais a priori ça me parait un mauvais raisonnement car cela signifie que lire la doc d'un mode n'est plus une source d'info sûre. Or quels sont les raccourcis, certes non cohérents avec vim, dont on a besoin pour des modes spéciaux? assez peu pour que le cerveau puisse parfaitement s'adapter en passant d'un mode à l'autre. Je peux très bien savoir que, sur du texte "j" va sauter une ligne, et que sur autre autre chose il faudra utiliser "n". Au début on se dit c'est pas cohérent mais en fait notre cerveau fera le travail pour nous très vite , et ça permet de continuer à utiliser les modes tels qu'ils ont été écrits.
[^] # Re: emacs + mu4e
Posté par Narmer . Évalué à 1.
Viendez sur #emacsfr on freenode
et puis https://emacsconf.org/
la dernière a eu lieu il y a quelques jours
# Pour les Gnomeux comme moi
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 3.
Je me suis permis de relayer ton approche dans la boîte à idées de Tobias Bernard. Ça pourrait être chic, non ?
[^] # Re: Pour les Gnomeux comme moi
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Excellente idée, merci :-)
Mes livres CC By-SA : https://ploum.net/livres.html
# Sylpheed
Posté par Yth (Mastodon) . Évalué à 10.
J'interviens juste pour faire remarquer qu'il existe toujours Sylpheed, en bien plus léger qu'un Thunderbird, et sans grosse stack graphique. Et aussi Claws-mail, mais je ne l'utilise pas alors je n'en parlerai pas, mais pour ceux qui ne connaissent pas Claws-mail est un fork d'assez longue date de Sylpheed, et je ne connais pas les réelles différences.
J'apprécie Sylpheed depuis longtemps parce que c'est facile de gérer des tas de comptes, y compris temporaires, de garder un compte inactif dans un coin, de ranger et archiver ses mails, aussi bien localement que via IMAP.
Par exemple ma boîte d'archives est auto-hébergée, et j'y archive automatiquement avec des règles de filtrages des mails qui proviennent de toutes les autres boîtes.
On choisit très facilement quelles boîtes sont récupérées quand on clique sur « tout relever », et pour récupérer une autre boîte spécifique non-automatique il suffit de cliquer dessus (et faire relever manuellement si c'est du POP, mais l'IMAP est mis à jour à la volée).
Et tout ça en mails textuels : Sylpheed n'affiche pas les mails en HTML, mais présente la pièce-jointe HTML sur laquelle on peut cliquer pour l'ouvrir dans le navigateur, qui ouvre alors la copie locale hors-ligne de la partie HTML du mail.
J'ai un truc comme 100k mails dans mon Sylpheed, entre de l'IMAP et du local, ça n'a absolument aucun sens, et à part repartir de zéro je ne vois pas comment gérer ça aujourd'hui. Mais Sylpheed n'est pas perturbé par la quantité, ça va vite, ça ne plante pas. J'utilise le même Sylpheed depuis l'an 2000, en mettant à jour, sans jamais avoir rien eu de cassé, sans jamais avoir eu à faire de migration.
Avec tout ce bazar, il pompe 80Mo de RAM alors qu'il tourne depuis 15 jours (changé la batterie de portable fait tomber l'uptime, mais ça pourrait être 300 jours - et ça l'a déjà été - ça serait pareil).
Bref, je ne sais pas si Sylpheed peut répondre à ton besoin, parce qu'il ne s'utilise pas en mode texte, et ne s'interface pas avec org-mode, mais il n'a pas les inconvénients des trois que tu as cités.
Les mails étant stockés localement dans des fichiers individuels - y compris pour le cache local des boîtes en IMAP -, on peut même faire des recherches avec du grep, du find et des trucs comme ça.
Et si la boîte IMAP est définitivement inaccessible, ben tout ce qui est en cache localement est disponible, on peut même en déplaçant simplement le répertoire du cache dans un nouveau répertoire de la boîte locale les intégrer et y accéder comme s'ils avaient toujours été là.
On peut - noter le verbe utilisé qui n'oblige à rien - l'interfacer avec des outils de filtre antispam de façon très simple, il y a un préréglage pour bogofilter, sylfilter et bsfilter, mais comme tout ça se fait par l'invocation de lignes de commandes configurées dans Sylpheed, on peut interfacer un peu ce qu'on veut en bricolant.
On peut re-traiter tous les mails d'une boîte à travers le filtre anti-spam, ou les règles de filtrage, pour organiser après-coup des mails déjà reçus en fonction de nouvelles règles qu'on vient de créer.
Bref, avec un outil comme ça je n'ai jamais ressenti le besoin de subir Thunderbird ou Kmail…
Et sinon je serais probablement resté sous Alpine…
[^] # Re: Sylpheed
Posté par Psychofox (Mastodon) . Évalué à 6.
Ça fait des années que je n'ai pas utilisé sylpheed mais claws-mail a des plugins. Par exemple pour visualiser les mails html directement ou pas, des pdf attachés, gérer des filtres, les chiffrements/signatures, gérer un calendrier…
[^] # Re: Sylpheed
Posté par freem . Évalué à 5.
J'allais me log pour, justement, citer claws-mail quand j'ai lu les 3 alternatives…
Bref, je plussoie pour claws-mails, ceci étant dit, il m'est arrivé d'avoir des crash ou des freeze du MUA, et il «ne gère pas correctement le protocole non-standard utilisé par gmail».
Les guillemets devraient indiquer clairement ce que je pense à ce sujet…
À ma connaissance, il n'y a pas non plus de plugin fonctionnel pour la gestion des rendez-vous (caldav je crois?), et je n'ai jamais encore essayé d'y intégrer ldap, mais pour ces points la, il n'y a probablement que thunderbird qui peut avoir ce genre de trucs… et encore, c'est pas sûr.
Bref, je plébiscite également claws-mail. Seul inconvénient (à mes yeux): son interface nécessite l'usage de la souris.
Ah. Et, tant que j'y suis: claws-mail ne supporte pas dbus, ce qui implique qu'il faut un module pour avoir des popups quand on reçoit un mail. Ou alors, bien plus clean, utiliser "Éxécution d'une commande si du courriel arrive" pour être notifié.
J'y tiens, parce que du coup ça s'intègre a merveille dans les environnements de bureau légers et autres assemblages de WM + file browser + terminal +…
[^] # Re: Sylpheed
Posté par sebas . Évalué à 4.
J'utilise Claws-mail depuis de nombreuses années, et j'en suis pleinement satisfait (oui, c'est vrai, il freeze si un gos mail arrive, le temps de le charger).
Là où je rejoins le titre du journal de Ploum, c'est que claws permet de configurer le nom de l'éditeur de courriels qu'on désire utiliser, et bien évidemment j'ai choisi gvim, et j'ai donc toute la puissance de vim pour rédiger mes messages. Pour sortir de vim, il n'y a pas de bouton, on utilise donc ZZ ou :x, qui nous renvoie dans l'éditeur de texte défaut, et de là on peut envoyer le message.
Je ne suis pas d'accord qu'on a forcément besoin de la souris pour piloter claws, il y a des raccourcis claviers qui marchent très bien, de plus on peut facilement configurer les siens propres.
Claws évolue doucement, pas de grands changements au cours des upgrades, mais il est maintenu.
[^] # Re: Sylpheed
Posté par Yth (Mastodon) . Évalué à 2.
Ça fait partie des fonctionnalités communes entre Sylpheed et Claws-Mail : on peut utiliser un éditeur de texte externe pour composer les mails.
D'ailleurs on peut choisir en cours de rédaction de basculer sur l'éditeur de texte externe, puis de revenir sur l'éditeur de mail interne !
Et oui, il y a ce défaut de freeze de l'UI lors de l'incorporation des mails reçus.
Plus précisément :
- Sylpheed récupère une boîte en IMAP, tout va bien ;
- Il a terminé et incorpore les mails reçus : l'UI est gelée ;
- Sylpheed récupère une boîte en POP, et on voit apparaître les mails au fur et à mesure et on peut commencer à les lire pendant qu'ils arrivent.
Ce fut pire par le passé, il y a eu des améliorations ces dernières années à ce sujet.
On peut aussi ne pas faire de récupération automatique, et le faire exclusivement manuellement, un clic et il travaille.
Ou tout désactiver temporairement : il y a un mode hors-ligne, un simple clic et il ne communique plus, on ne risque donc pas d'être dérangé, et on bosse uniquement avec les données locales.
On a aussi l'impossibilité d'envoyer un mail directement pendant qu'une opération de réception est en cours, mais on peut mettre dans la boîte d'envoi et le laisser envoyer plus tard.
Il y a aussi un système de plugin dans Sylpheed, mais je ne sais pas du tout ce qui existe.
Mon plugin pour ouvrir tout type de pièce jointe c'est simplement de l'envoyer vers le système qui utilisera l'application configurée (xpdf, LOo, firefox, etc.)
Mais il affiche quand même les images en interne.
Oh, et bien sûr, lorsqu'on rédige un mail, on peut choisir en cours de route quel compte va envoyer le mail, et en changer autant qu'on veut, ce n'est pas bloqué au moment où on a cliqué sur « répondre » !
[^] # Re: Sylpheed
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Vous me donnez envie de retester ces deux monstres vénérables ;-)
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Sylpheed
Posté par sebas . Évalué à 3.
Alors, entre-temps j'ai lu ton billet de blog (dans lequel je me retrouve parfaitement, mes courriels sont rédigés comme des lettres, pensés, relus et envoyés pas forcément le même jour, je t'avoue que j'ai même quelques rares correspondants avec lesquel on échange les trucs importants (et donc non urgents ;-p) par snail-mail, et je peux dire qu'on n'écrit pas du tout pareil quand c'est sur papier (et qu'on ne peut pas corriger ni insérer des paragraphes ou des phrases, ni les déplacer par copier-coller) que par courriel — même bien construit —, on doit beaucoup plus réfléchir et concevoir la lettre avant d'irrémédiablement tacher le papier avec son stylo. Le style qui en dérive est du coup complètement différent.
Donc, claws va dans ton sens :
— on peut configurer le temps de relève automatique, ça peut très bien être une fois par jour (=> le facteur vient de passer) ou pas du tout, il faut alors demander de charger ses courriels (=> on va à la poste chercher son courrier). On peut faire les deux, la recherche manuelle ne perturbe pas le facteur qui continue à passer une fois par jour, même si entretemps tu es passé à la poste.
— on peut écrire ses mails et les mettre soit dans les brouillons si on veut les relire, soit dans la file d'attente s'ils sont prêts à partir (mais ils sont bien sûr toujours éditables). Ça n'est pas obligatoire d'envoyer le courriel sitôt fini, on peut faire un "send queue" une fois par jour, si on veut. Par contre, on ne peut pas configurer d'envoi automatique à intervalle régulier, comme pour la réception.
— pour le bepo, ben ça c'est à la charge du système, donc aucun problème de ce côté. D'ailleurs, comme les raccourcis pour les menus sont configurable à la gnome (on ouvre le menu, on fait le shortcut désiré sur l'item, et il est enregistré), c'est hyper rapide de reconfigurer les raccourcis défauts pour qu'ils correspondent mieux à ton clavier, si tu le souhaites.
— La boîte mail est groupée sur un seul dossier, facile à sauvegarder.
— On peut avoir plusieurs boîtes dans le même claws, on peut aussi avoir plusieurs instances de claws se lançant chacune avec sa config et sa boîte email (peut être utilisé pour relever sa boîte à spams, ou ses mails du type messages instantanés, etc., les possibilités sont nombreuses).
— On peut configurer le nombre de jours qu'un courriel relevé doit rester sur le serveur, après quoi il sera automatiquement supprimé lors du relevé suivant. Ça laisse un backup le temps qu'on sauvegarde sa boîte email, et ça permet de le prendre sur d'autres appareils, le cas zéche et han.
— Par défaut, les messages sont composés en texte pur, et les pièces jointes ne sont pas incluses dans le corps du message, mais… en pièces jointes. On peut considérer ceci comme une qualité ou un défaut, mais du coup les messages ressemblent beaucoup plus à des lettres et ne sont pas bourrées de fioritures inutiles, juste l'essentiel, les photos ou autres annexes sont dans l'enveloppe, mais à part.
— On peut chiffrer le contenu et signer avec GnuPG, et on peut configurer un proxy local pour passer par TOR (mais les metadata nous trahissent)
— Grammalecte est disponible pour vim, donc pour écrire des beaux courriels sans fautes (ou presque…)
Par contre :
— On ne peut pas configurer le temps de remise en fonction de la distance parcourue par le courriel ;-)
— La lecture des courriels html (que la plupart des gens envoient) perd souvent à la visualisation son formatage et quelquefois une partie de son contenu. Il y a des plugins pour lire les messages html, mais celui dispo sur debian est assez basique et le rendu un peu primitif. Je ne sais pas si fancy-html est toujours maintenu et quel est son rendu, mais sur debian, macache…
— Il n'y a pas de beaux timbres sur les messages entrant. ;-)
[^] # Re: Sylpheed
Posté par Astaoth . Évalué à 3.
Pour Clawsmail ou Sylpheed, les UI freeze pendant la relève des courriels. Inutiliable avec trop de boites mails et une relève selon un rythme assez soutenu.
Emacs le fait depuis 30 ans.
[^] # Re: Sylpheed
Posté par jihele . Évalué à 2.
Oui, j'utilise claws-mail depuis très longtemps (10 ou 15 ans) et c'est pénible. C'est le gros défaut. Il est mono-thread et il faut être patient.
[^] # Re: Sylpheed
Posté par freem . Évalué à 2.
J'ai la version 3.17.3 de claws, empaquetée par Debian Buster ici. Ok, je n'ai qu'un seul compte mail et "quelques" flux rss, mais je ne constate pas de freeze systématiques de l'UI quand je fait la relève.
Les freeze que j'ai expérimentés, c'est surtout avec une connexion de merde, sur un réseau dégueulasse, et je ne serais pas surpris que ça ait été causé par le routeur qui embarquait un cache DNS qui cassait toutes les 5 minutes, sans parler de la connection à la fiabilité douteuse (routeur ethernet <=> gprs) qui rendait impossible de conserver une connection ssh plus de 5 minutes, 10 pour les chanceux.
Vu l'âge du bestiau (claws/sylpheed), je ne serai pas surpris que l'usage sur des réseaux stables mais lent ne soit pas trop problématique (héritage) mais qu'un réseau non stable (avec fortes pertes de paquets je suppose?) puisse poser des problèmes?
[^] # Re: Sylpheed
Posté par Astaoth . Évalué à 5.
J'ai une dizaine de boites mails dont certaines qui ont plus de 20 dossiers et j'ai tenté à plusieurs reprise d'utiliser Claws-mail pour sa légèreté et sa simplicité. Plus de 60% du temps quand je l'ouvre pour lire mes mails, il était en train de faire une relève. Je suis à chaque fois repassé sur Thunderbird juste pour ca.
Emacs le fait depuis 30 ans.
[^] # Re: Sylpheed
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 16 décembre 2020 à 12:33.
Dans ce cas pourquoi tu ne désactivais pas la synchronisation auto de sylpheed pour utiliser fetchmail dans un cronjob à la place ?
[^] # Re: Sylpheed
Posté par Astaoth . Évalué à 3.
Parce que Thunderbird me permet de pas avoir besoin de faire tout ca pour pouvoir lire confortablement mes courriels en fait.
Emacs le fait depuis 30 ans.
# billet
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 14 décembre 2020 à 13:44.
J'ai lu ton billet et pour moi la réponse n'est pas dans le choix du client mais dans ton approche. C'est pas vim, emacs, mutt qui vont plus t'aider que evolution,thunderbird ou geary.
Si tu ne veux pas de mails de notification, ne t'abonnes pas à des listes. Si tu veux noter l'addresse de ton destinataire seulement après rédaction, fais le. Rien ne t'en empêche. Si tu veux recevoir tes mails et les envoyer à la demande, désactive la synchro automatique de ton client et sauve tes emails dans la outbox pour ne les envoyer que quand tu synchronise.
# Une question de volume?
Posté par Michaël (site web personnel) . Évalué à 9.
De 2000 à 2010 environ j'ai essentiellement utilisé Gnus/Emacs (oui Gnus: “gniouzes”) pour lire et écrire mes mails. Les raisons principales qui font que je ne l'utilise plus sont que:
Cela encaisse mal le volume des communications. En étant abonné à quelques mailing lists à fort trafic (FreeBSD), recevant plein de spams (plus de 50 par j) et ayant une messagerie d'entreprise avec un trafic complètement délirant, le logiciel ne suit pas.
La plupart des mes correspondants préfèrent les messageries instantanées. (Pas tous, la plupart.)
En travaillant avec plusieurs ordinateurs cela demande un effort de synchroniser les configurations de ces logiciels.
Comme tu le constates, les clients de messagerie ne sont pas très satisfaisants… soit la gestion des fils de discussion, tags, … est mauvaise ou inexistante, soit le flot de travail est contre-intuitif, soit trop gourmand en ressources, … bref aucun que j'ai utilisé en me disant “C'est vraiment ce qu'il me faut.”
Du coup j'utilise essentiellement les interfaces web de mes diverses messageries.
Si tu as un volume de messages relativement faible et que tu aimes bien configurer tout ce qui est configurable, j'avais trouvé Gnus/Emacs vraiment bien!
https://www.gnu.org/software/emacs/manual/html_node/gnus/Starting-Up.html#Starting-Up
Il y a même un chapitre “Emacs pour les païens” :D
# Vim et Emacs
Posté par paulez (site web personnel) . Évalué à 4.
Je ne répondrai pas à la question du courriel, mais dans ton billet tu sembles hésiter entre apprendre Emacs et rester sur Vim.
J'avais un peu le même problème, et j'ai trouvé le meilleur des deux mondes avec Spacemacs, qui est une configuration pour Emacs qui permet de l'utiliser comme Vim.
C'est super agréable à utiliser avec toute la mnémonique des opérations Vim, et la puissance d'Emacs.
[^] # Re: Vim et Emacs
Posté par ElVirolo (site web personnel) . Évalué à 4.
Il y a également Doom Emacs, plus rapide que Spacemacs.
Si l'on est prêt à y passer un peu de temps, je conseille de construire petit à petit sa propre configuration. Cet article est une bonne introduction à cette approche, pour celles et ceux qui souhaitent une configuration inspirée de Spacemacs.
[^] # Re: Vim et Emacs
Posté par saltimbanque (site web personnel) . Évalué à 4.
si vous voulez introduire les raccourcis vim dans emacs, il vaut mieux commencer par mentionner evil. Les distributions que sont spacemacs ou doom emacs sont des assemblages de nombreux éléments. Sans quoi on pourrait croire qu'il faille forcément spacemacs pour avoir vim dans emacs
[^] # Re: Vim et Emacs
Posté par paulez (site web personnel) . Évalué à 2.
Je déteste passer des heures à bidouiller la configuration de mon éditeur pour avoir quelque chose d'utilisable. J'ai arrêté Vim car c'était vraiment trop de perte de temps pour arriver à le configurer pour avoir quelques fonctions d'IDE.
J'ai ensuite utilisé Visual Studio Code qui est super agréable à utiliser, mais j'ai trouvé un peu dommage d'utiliser un produit Microsoft pour programmer.
J'ai commencé à configurer moi-même Emacs avec un résultat à peu près utilisable après quelque temps. Spacemacs m'a permis de faire un bond significatif en confort et efficacité d'utilisation.
Chacun ses préférences bien sûr ! Je trouve dommage qu'il n'y ait pas de bonne alternative d'éditeur "clé en main" à Visual Studio Code.
# Client en pure terminal ?
Posté par MookSkook . Évalué à 7.
Une autre solution serait un client KISS en pure terminal, je sais qu'il existe AERC https://aerc-mail.org/ qui commence à devenir bien (Il supporte le Vim-style keybindings).
Et bien entendu les vénérables mut et neomutt.
# notmuch
Posté par Thomas (site web personnel) . Évalué à 4.
Ca marche.
L'installation n'est pas triviale, mais ca tourne sans trop de maintenance depuis 3-4 ans. Quelques moments d'égarement, parfois, de la base de données mais ca se passe bien.
Revenons à l'installation : on centralise sur une machine qui fait office de serveur, avec muchsync qui synchronise le tout. Les mails sont récupérés avec offlineimap et … c'est tout. Notmuch, avec son client emacs, n'est qu'une interface de recherche dans la base d'emails.
Franchement, ca se fait.
Sois fort.
# Comme le papier
Posté par wilk . Évalué à 2.
Les mails (ou autres messageries directes) remplacent de plus en plus souvent des conversations et des réunions en chair et en os. Hors on n'enregistre pas ces conversations pour les ressortir "t'avais dit ça…". Ce qui ressort de ces conversations éventuellement on en fait un résumé que l'on classe dans le projet ad hoc.
Je fais pareil avec les mails, je les empile sur le bureau tant qu'ils ne sont pas traités, certains je les range dans un carton, la plupart finissent à la poubelle à plus ou moins brève échéance. Bref, j'en conserve très peu et pas longtemps.
Du coup peu importe le client mail. J'utilise vim comme un crayon, pour tout. Et mutt comme un vulgaire bureau avec quelques tiroirs.
# Alpine
Posté par binoyte . Évalué à 4.
historiquement il s’appelait pine, des mêmes auteurs de l'éditeur que pico.
Cela a donné alpine et nano.
C'est très simple d'utilisation, à l'image de l'éditeur nano. Les raccourcis sont rappelés en bas de l'écran. Peut-être, certain le trouve trop simple. Moi je l'utilise de temps en temps, et il me satisfait.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.