GNU Emacs 24 est là !

50
12
juin
2012
GNU

La nouvelle version de GNU Emacs vient de sortir en version 24 ce 10 juin. Cette version apporte son lot de nouveautés, dont certaines étaient plus attendues que d’autres comme la gestion des paquets simplifiée ou l’intégration à GTK+ 3.

Pour ceux qui l’auraient oublié ou à ceux qui ne le savent pas, Emacs est le père de la famille des Emacsen. Il a vu le jour dans les années soixante-dix au MIT des mains de Richard Stallman. Son nom signifie « Editing MACroS ». Le GNU de son nom, ne lui fut préfixé qu’en 1984.
Emacs est un Éditeur de MACroS un peu particulier puisqu’il est écrit en Lisp tout en étant son propre interpréteur. C’est de là que vient tout la force de ce logiciel phare qui fait bien plus que de l’édition de texte.

Dans la suite de cette dépêche sera présenté une liste, non exhaustive, des nouveautés apportées par la vingt-quatrième version de ce logiciel par rapport à la précédente. Les nouveautés sont regroupées par lots plus ou moins détaillés.

Sommaire

Nouveautés

Amélioration de l'édition

Emacs étant d'abord un éditeur de texte, il est normal de s'intéresser aux changements intervenus dans la gestion de l'édition de texte.

On notera l'arrivée d'une fonction count-word-region (M - =) qui permet de compter le nombre d'entités séparées par des espaces au sein de la sélection. Le nombre total de mots est calculé avec count-word.

Uniformisation des commandes C-y et M-y

C-y, commande utilisée pour coller la dernière chose copiée sur « l'anneau de collage » (ou « l'anneau unique tueur » ou tout simplement le « kill ring » en V.O.), voit maintenant son comportement être le même lors d'une recherche isearch (C-s).
De même pour M-y, qui fait tourner l'anneau, le fait aussi dans isearch.

Le comportement précédent de C-y dans isearch était de coller le reste de la ligne comprise entre le point et la fin de la ligne. Comportement quelque peu étrange. Pour les inconditionnels de ce mode de fonctionnement, cette fonction est maintenant activable avec M-s C-e.

Gestion de la sélection

Sous X, il est possible de sélectionner du texte de deux manières différentes. L'une d'elle, la plus connue, garde les informations dans le presse-papier. Typiquement, on fait appel à elle avec le copier/coller habituel.
La seconde manière est de simplement mettre le texte à sélectionner en surbrillance. On peut le coller simplement en appuyant sur la roulette de la souris. Ce type de sélection est dit primaire.

Ainsi, Emacs suit maintenant le comportement par défaut des application nées sous X : sélectionner une région avec la souris (ou en maintenant SHIFT appuyée) devient une sélection primaire, alors que sélectionner du texte avec C-SPC, par exemple, utilise le presse-papier par défaut.

Cela signifie donc que C-w et M-w utiliseront donc le presse-papier par défaut.

Meilleure intégration à GTK3

Emacs peut être compilé de manière à améliorer l'intégration avec GTK3 grâce à l'option --with-x-toolkit=gtk3 lors de la phase de configuration. Ceci apporte quelques changements qui améliorent la cohérence de l'interface d'Emacs dans les environnements GTK comme GNOME :

  • La barre de défilement est désormais placée à droite par défaut. (comportement changeable grâce à la fonction set-scroll-bar-mode)
  • La couleur de la région (la zone de texte sélectionnée) est désormais tirée du thème GTK utilisée.
  • Les infobulles (tooltips) GTK sont utilisées par défaut.
  • Les barres d'outils GTK peuvent êtres placées sur n'importe quel bord d'un cadre (haut, bas, gauche et droite).

Autres changements graphiques

D'autres modifications graphiques ont eu lieu comme la suppression des tirets dans la ligne de mode. (Exemple avant/après pour un fichier *.org)
Mode-line

Le thème peut maintenant être simplement choisi avec customize-themes. En outre, Emacs propose maintenant un module de thème propre nommé deftheme. Vérifiez que votre thème a bien été adapté à deftheme pour continuer à l'utiliser.

Des changements sur la gestion du défilement

Avant la version 24, il n'existait pas de commande pour faire défiler l'écran ligne par ligne. À présent, les commandes scroll-up-line et scroll-bottom-line le permettent.

Internationalisation

Emacs supporte désormais l'édition de texte de droite à gauche pour des langages comme l'arabe, le farsi ou l’hébreu. Le tutoriel a ainsi été également traduit en hébreu.

De plus, la détection du sens d'écriture est automatique et conforme à l'algorithme prescrit par Unicode (Unicode Bidirectional Algorithm).

Hebrew

Ce comportement automatique peut être désactivé grâce à la variable bidi-display-reordering.

Pour améliorer encore l'internationalisation, de nouvelles méthodes d'entrée sont disponibles : farsi, farsi-translit et bulgarian-alt-phonetic.

Gestionnaire de paquets

Tout utilisateur d'Emacs sait qu'installer un paquet n'est pas une sinécure, bien que certains soient installables grâce au gestionnaire de paquet de votre distribution linux.

Mais tout cela est maintenant du passé grâce au gestionnaire de paquets intégré ! (Emacs Lisp Package Archive - ELPA)
Pour l'utiliser, rien de plus simple : M-x list-packages

Il suffit d'en sélectionner un pour qu'Emacs le télécharge et l'installe automatiquement. En outre, il se charge aussi de l'activer au démarrage ; plus besoin de l'ajouter dans votre .emacs !
Vous pouvez obtenir une description du paquet sur lequel le point se trouve en tapant RET ou en cliquant sur le nom du paquet ou encore avec C-h P.

Il suffit de marquer un paquet avec i pour le sélectionner en vue de l'installer ; x lance le processus d'installation. Les paquets seront installés dans ~/.emacs.d/elpa/.

Bien sûr, il est possible de continuer à charger les paquets via le fichier .emacs en changeant la valeur de package-enable-at-startup et en spécifiant la liste des paquets à charger nommée package-load-list.

Par défaut, Emacs affichera la liste des paquets présents au sein du dépôt officiel et qui respectent, au niveau de la licence, la GPLv3. Il est toujours possible d'ajouter un autre dépôt dans la liste comme Marmalade ou MELPA :

(require 'package)
(add-to-list 'package-archives
             '("marmalade" . "http://marmalade-repo.org/packages/"))

Changements divers

Porte lexicale d'Emacs-lisp

Emacs-lisp offrait, jusqu'à maintenant, une portée dynamique en terme d'espace de noms. Il est maintenant possible de travailler en portée lexicale si lexical-binding est actif. Néanmoins, les variables globales (celles qui sont nées d'un setq) restent dynamiques.

Rappelons qu'une portée lexicale signifie que le nom d'une variable est limité à un lexique, c'est-à-dire une variable créée explicitement et dont le nom est local, astreint à une fonction par exemple.

Amélioration de l’auto-complétion

L'auto-complétion tend à se standardiser grâce à la fonction complete-at-point qui est maintenant utilisée par la majorité des modes d'éditions d'Emacs. Celle-ci devient ainsi plus simple à mettre en place, mais, et surtout, son comportement est empreint d'une cohérence unificatrice.

EmacsWiki se meurt, vive WikEmacs !

EmacsWiki est une source importante d'informations pour les utilisateurs d'Emacs. Il n'est pas parfait et peut même être assez brouillon. C'est ainsi que le 20 mars 2012, Bozhidar écrit un article intitulé « Die EmacsWiki, Die! ». L'auteur y parle de l'histoire d'EmacsWiki mais surtout des problèmes qu'il y voit :

  • pas de modération de contenu ;
  • plus qu'un wiki, c'est un dépotoir de fichier *.el et certains logiciels ne sont pas distribués autrement ;
  • la documentation est redondante avec celle présente sur les sites des projets ;
  • les discussions se font au sein même de la page.

Cet article attira les foudres de nombres de personnes entre-mêlées de commentaires approbateurs. Kensanata, l'auteur d'EmacsWiki depuis 2001, était de la partie.
Cependant, le plus gros reproche fait à cet article est son ton pompeux et l'absence de solutions concrètes proposées.

Le lendemain, après le flot très important de commentaires à propos de son article, l'auteur récidive avec un article intitulé « All Hands on Deck! (or the Action Plan for a New Emacs Community Wiki) » dans lequel il propose de changer le moteur de wikis, de payer pour l'hébergement du site dans un premier temps et de prendre du temps pour garder les pages d'EmacsWiki qui en valent la peine.

C'est ainsi que, cinq jours plus tard, WikEmacs naquit. Le faire-part de naissance était intitulé « WikEmacs - the Other Emacs Wiki ». L'article commence par une modération des précédents propos, car certains aiment le format actuel d'EmacsWiki.

L'auteur défini quelques lignes de conduite quant au nouveau WikEmacs :

  • les articles ne concerneront que les versions récentes d'Emacs (23 et 24) ;
  • les informations fournies ne devront pas être une copie de celles présentes sur le site d'Emacs ou du module concerné ;
  • les articles proposeront, principalement, des liens vers les sites officiels et leur documentation ainsi que quelques astuces introuvables ailleurs ;
  • enfin, les commentaires et les discussions auront lieu sur la page idoine.

Avec le temps, WikEmacs s'étoffera tout en offrant un espace plus clair et plus concis sur Emacs et ses modules.

Forks d'Emacs

Emacs, comme de nombreux logiciels libres d'envergure, a été forké de multiples fois. Voici quelques nouvelles de certains d'entre eux.

XEmacs

XEmacs semble toujours actif, bien que la dernière version stable date du 30 janvier 2009. L'ajout principal, sa gestion des paquets, n'est maintenant plus un attribut de différenciation.

µEmacs

µEmacs est une version allégée, plus ou moins libre d'Emacs. Connue car utilisée par Linus Torvald.

GNU Zile

GNU Zile est une autre version allégée, toujours maintenue, d'Emacs. En février 2012, une version expérimentale a été lancée ; elle fonctionne sous Guile, l'interpréteur Scheme bien connu. Elle est nommée Zile-on-Guile. Ceci est peut-être un pas de plus dans le projet, réellement lancé en 2010, de changer l'interpréteur Emacs Lisp d'Emacs par Guile.

Remerciements

J'aimerais remercier, par ordre alphabétique, bastien, Enjolras, farvardin, pixels et teoB pour leurs contributions à cette dépêche.

J'en profite aussi pour dire merci aux chasseurs de fautes pre et post publication de cette dépêche.

  • # ...bien que ...

    Posté par . Évalué à 3.

    J'imagine que tu voulais dire qu'installer des paquets n'est pas une sinécure ?

  • # Gestionnaire de paquets

    Posté par (page perso) . Évalué à 10.

    A la lecture de cette bien belle dépêche, une réflexion à heurté mon esprit (avec les dégâts sur la stabilité mentale que cela peut engendrer) :
    On se retrouve avec de plus en plus de gestionnaire de paquets. Il y a ceux pour la distribution, ceux pour les langages de programmation, et maintenant ceux pour les éditeurs de texte comme vim et emacs.

    Est-ce que cela signifie que les politiques mise en place par les distributions sont trop lourdes et que les projets préfères avoir leur propres gestionnaires et règles ?
    Comment voyez-vous le futur d'une administration d'un système centralisé (style mainframe linux ou tout les développeur sont censé utilisé les mêmes outils/version pour garder u système homogène) avec tout ces paquets à valider/mettre à jour etc … ? Verra-t-on apparaitre un meta gestionnaire de paquet pour tout maintenir ? Comment se déroulera la futur certif LPI 103 : gestionnaires de paquets ?

    • [^] # Re: Gestionnaire de paquets

      Posté par . Évalué à 10.

      Juste pour préciser. Vim n'a pas de gestionnaires de paquets. Il a un format de paquet, mais tu le télécharge manuellement.

      Pour répondre à ta question. Les langages, les éditeurs de texte et les navigateurs utilisent leur propres paquets pour ne pas obliger leurs utilisateurs à être administrateurs du système d'une part et pour ne pas que les paquet s'installent pour l'ensemble du système. C'est important pour les logiciels dont les extensions servent à chaque utilisateurs pour de la customisation. C'est très important pour les langages qui veulent pouvoir faire cohabiter sur un même ordinateur plusieurs versions d'une même bibliothèque pour des applications différentes.

      Bien sûr la diversité des gestionnaires de paquet est un frein à leur utilisation pour chaque extension/paquets de chacun de ses logiciels mais les deux premiers points que j'ai cité invalident de base les gestionnaires de paquets.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Gestionnaire de paquets

      Posté par (page perso) . Évalué à 3.

      je ne vois pas d'opposition, mais au contraire complémentarité.

      Le gestionnaire de paquets d'Emacs n'entre pas en conflit avec les modules installés via, par exemple, les dépôts Debian.

      Lorsque l'on gère un parc de machines un gestionnaire de paquet "global" est indispensable. Mais sur sa machine privée, dans certains cas, c'est absurde de s'y cantonner. Vais-je devoir attendre qu'une personne s'occupe de faire un paquet pour le mode "helm" pour avoir à l'utiliser ? Non, je vais faire un "list-packages" et l'installer en "local".

      • [^] # Re: Gestionnaire de paquets

        Posté par (page perso) . Évalué à 2.

        @Barret Michel : pour vim je pensais à vim-addon-manager qui est dans le même esprit.

        En faite, ma réflexion est surtout pour le cas des grosses machines utilisées par de nombreuses personnes à qui l'on donne un environnement complet.
        L'utilisation de différents systèmes de paquets limite les environnement identique, et le contrôle des licences et produit autorisé par une entité spécifique d'une entreprise (comme on en trouve dans toute les grosses boites françaises), ou les tests de non régression exhaustif lors de migrations de machine, voir simplement l'inventaire de ce qui est nécessaire pour une équipe.
        Je ne parle pas de notre pc perso.

        • [^] # Re: Gestionnaire de paquets

          Posté par (page perso) . Évalué à 4.

          Oui, j'ai bien compris. Seulement Emacs est "extensible" en local, avec ou sans gestionnaire de paquets intégré. En fait ce gestionnaire de paquets n'est qu'un petit programme lisp qui fait ce que l'on faisait avant manuellement. Si on veut un environnement Emacs "à l'identique" sur tous les postes, il faut faire en sorte d'interdire à Emacs de lire des programmes elisp qui seraient enregistrés dans le dossier personnel de l'utilisateur. Il n'y a pas d'autres solutions. Le gestionnaire de paquets intégré à Emacs ne change rien.

      • [^] # Re: Gestionnaire de paquets

        Posté par (page perso) . Évalué à 3.

        je ne vois pas d'opposition, mais au contraire complémentarité.

        C'est d'autant plus complémentaire que les systèmes d'empaquetage peuvent être adaptés pour empaqueter très rapidement des logiciels ou modules disponibles par un tel système de paquet interne. Pour Debian, c'est le cas au moins pour les extensions Mozilla et les logiciels ou bibliothèques en Python, en Perl et en Ruby par exemple.

    • [^] # Re: Gestionnaire de paquets

      Posté par . Évalué à 3.

      C'est fait pour plusieurs raisons je pense:
      1) le multi-plateforme : Que je sois sous Linux, Windows ou MacOS, je peux accéder sans trop de soucis aux bibliothèque. Sans être dépendant du gestionnaire de paquet (éventuel) du système.
      2) Ça permet à un non-administrateur d'avoir accès à des paquets ne touchant pas au système à proprement parler. C'est donc plus souple du point de vue utilisateur, même si ça peut poser des problème du point de vue administrateur parfois.
      3) Simplifier les procédures de création de paquets, souvent très lourdes dans les distributions, notamment quand on souhaite acquérir une certaine visibilité (accès à la branche "stable").

      Certes, la multiplication de ces gestionnaires peut poser problème. Néanmoins, si on veut quelque chose de rapide, simple et réactif, et à la fois stable et éprouvé, on n'a pour l'instant pas de réelle possibilité de n'utiliser qu'un outil.
      Une idée que je lance, ça serait d'avoir une norme/langage commun pour pouvoir automatiser ces installation de paquets à l'intérieur des applis. J'ai pesté pas mal de fois contre Eclipse à ce propos. Passer par le clicuodrome à chaque réinstallation pour ajouter 5 plugins est pénible. Un script aurait été très appréciable…

    • [^] # Re: Gestionnaire de paquets

      Posté par (page perso) . Évalué à 2.

      Il existe un gestionnaire de dépendances qui ne fait que ça et qui le fait bien: http://ant.apache.org/ivy/

      http://devnewton.bci.im

      • [^] # Re: Gestionnaire de paquets

        Posté par (page perso) . Évalué à 6.

        Sauf qu'il est en Java.

        • [^] # Re: Gestionnaire de paquets

          Posté par (page perso) . Évalué à 5.

          Comme beaucoup de très bons logiciels libres!

          http://devnewton.bci.im

          • [^] # Re: Gestionnaire de paquets

            Posté par (page perso) . Évalué à 1.

            Qui du coup n'ont aucune chance d'être utilisés dans pas mal de cas où ils pourraient être utiles. Java est une maladie du logiciel libre.

            • [^] # Re: Gestionnaire de paquets

              Posté par (page perso) . Évalué à 2.

              Pourquoi?

              http://devnewton.bci.im

              • [^] # tentative d'explication

                Posté par (page perso) . Évalué à 9.

                Parce que.

                • Parce qu'on l'a dit donc on le répète.
                • Parce qu'il fut proprio un jour, donc il l'est fondamentalement toujours.
                • Parce qu'on aime pas ce langage, et que tout ce que l'on aime pas est ou proprio, oui un mauvais logiciel libre qui aurait du rester proprio (ou le devenir).
                • Parce que c'est du Oracle.
                1. Pour l'une de ses raisons.
                2. Pour toutes ses raisons.
                3. Pour un mélange indistinct d'entre elles.
                4. Pour des raisons encore plus obscures.
                • [^] # Re: tentative d'explication

                  Posté par . Évalué à 4.

                  Tu as oublié : Obi-Wan Kenobi

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: tentative d'explication

                  Posté par . Évalué à 10.

                  COOL !!!

                  Aller Qt ça pue c'est pas libre !!!

                  On l'a déjà dit, il fut proprio, c'est du C++ et Linus vous diras comment le C++ c'est mal, c'est du Nokia.

                  Enfin je peux la ressortir ! Merci !

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: Gestionnaire de paquets

                Posté par (page perso) . Évalué à 2.

                Pour plein de raisons.

                • C'est propriétaire donc ça n'a pas sa place dans un système libre. Ça a été partiellement libéré par Sun, mais Java fait évidemment machine arrière.
                • Plus grave encore, il est tout simplement interdit de redistribuer le Java d'Oracle. C'était autorisé par une licence spéciale, qui a été retirée l'an dernier.
                • C'est lourd et contraignant en terme d'installation, probablement parce que ça a été conçu sans penser à l'intégration, en tout cas comparé à des systèmes concurrents comme Python.
                • C'est fait par Oracle qui sont des connards prêts à coller un procès à n'importe qui dès qu'ils trouvent une piste pour le faire : « Là, eux là-bas, Google, ils utilisent le mot “Java”, pas bien ! »

                Bref, pour toutes ces raisons, mais à mon avis surtout pour les trois premières, ce n'est pas demain la veille du jour où le solveur de dépendances de Debian sera codé en Java par exemple. D'une façon générale, beaucoup de gens, lorsqu'ils tombent sur un logiciel en Java, ont le réflexe de chercher une alternative en autre chose que Java.

                • [^] # Re: Gestionnaire de paquets

                  Posté par . Évalué à 7.

                  Openjdk 7 étant fourni par la plupart des distributions linux, je ne comprends pas pourquoi java reste un citoyen de seconde zone. Il est même affolant de voir qu'il y a plus de programmes dépendant de C#/mono que de programmes java/openjdk disponibles sur un desktop libre! Oracle a fait un procès pour de sombres raisons, mais qui sont plus relatives à la réimplémentation d'une plate-forme qu'à l'utilisation du langage, procès qui a d'ailleurs été perdu par Oracle.

                  • [^] # Re: Gestionnaire de paquets

                    Posté par (page perso) . Évalué à 2.

                    Parce qu'Openjdk a des problèmes de performances par rapport au Java distribué par Oracle.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Gestionnaire de paquets

                      Posté par (page perso) . Évalué à 6.

                      Et alors? Il y a bien des compilateurs C++ proprios qui génèrent du code plus performant que gcc.

                      http://devnewton.bci.im

                      • [^] # Re: Gestionnaire de paquets

                        Posté par (page perso) . Évalué à 5.

                        Ce ne serait pas gênant si ça ne rendait pas openjdk inutilisable. Pour éviter d'avoir des logiciels qui disent "ne pas l'utiliser avec openjdk".

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                        • [^] # Re: Gestionnaire de paquets

                          Posté par . Évalué à 3. Dernière modification le 12/06/12 à 17:29.

                          Quels logiciels demandent ça? j'utilise OpenJDK je n'ai jamais constaté cela. Niveau perf, ça tourne vraiment bien.

                          Pour faire du C, du Python ou du PHP, on utilise souvant un IDE fait en java quand on est sous Linux, ceux (les libres) en Python / C++ / C / PHP ne tiennent pas la route 2 secondes. Heureusement que le monde libre à Java.

                          • [^] # Re: Gestionnaire de paquets

                            Posté par (page perso) . Évalué à -1.

                            Quels logiciels demandent ça?

                            Tous les systèmes de prise de contrôle genre KVM IP.

                            • [^] # Re: Gestionnaire de paquets

                              Posté par (page perso) . Évalué à 8.

                              Tout comme certains logiciels demandent une Redhat mais sont indiqués non compatible centos. C'est beaucoup pour des histoires de support et/ou de test. Mais pas forcément une histoire de réelle compatibilité.

                          • [^] # Re: Gestionnaire de paquets

                            Posté par (page perso) . Évalué à 10.

                            Pour faire du C, du Python ou du PHP, on utilise souvant un IDE fait en java quand on est sous Linux, ceux (les libres) en Python / C++ / C / PHP ne tiennent pas la route 2 secondes. Heureusement que le monde libre à Java.

                            Cette phrase sur la dépêche d'Emacs mérite la potence !

                            • [^] # Re: Gestionnaire de paquets

                              Posté par . Évalué à 0.

                              totalement d'accord, "mea maxima culpa" comme disent les hauts cadres de Renault, j'aurais dû ajouter "si on exclut Emacs".

                              En même temps j'aurais pu parler de VI (le m c'est pour mauviette) ou ed (jamais 2 sans 3).

                          • [^] # Re: Gestionnaire de paquets

                            Posté par . Évalué à 1.

                            Il y a vraiment des gens qui utilisent éclipse pour autre chose que du java ?

                            Eclipse est l'éxemple d'outil qui font que j'utilise le moins possible d'outils en java. C'est certainement l'ide le plus complet qui soit, mais ça prend 3h à se lancer, c'est lent, peu stable, pas réactif…
                            Quand je compare à pharo, je rêve de trouver un ide semblable pour tout les autres langages.
                            Perso la plupart du temps j'utilise un simple éditeur, pour de gros projets , j'ai préféré déboursé des sous pour ruby, et pour c++ kdev et creator sont largement utilisables, et pour java… ben là en effet j'utilise eclipse, mais j'ai tendance à refuser les projets java ;)

                            Ensuite sur le langage, je n'ai que les critiques habituelles: noms à rallonge, api lourde et chiante, mais si elle est très propre d'un point de vue pattern,pas de système de dépendances, etc…

                • [^] # Re: Gestionnaire de paquets

                  Posté par (page perso) . Évalué à 9.

                  C'est propriétaire

                  openjdk, harmony, dalvik?

                  il est tout simplement interdit de redistribuer le Java d'Oracle

                  Et alors? Il faut utiliser une implémentation libre.

                  C'est lourd et contraignant en terme d'installation, probablement parce que ça a été conçu sans penser à l'intégration, en tout cas comparé à des systèmes concurrents comme Python.

                  aptitude install openjdk-6-jre
                  aptitude install python
                  
                  

                  Mmmh…

                  C'est fait par Oracle qui sont des connards prêts à coller un procès à n'importe

                  Vu le niveau des arguments utilisés, ils pourraient attaquer n'importe quel langage interprété. Heureusement ils sont en train de perdre lamentablement.

                  D'une façon générale, beaucoup de gens, lorsqu'ils tombent sur un logiciel en Java, ont le réflexe de chercher une alternative en autre chose que Java.

                  Je faisais ça aussi, mais c'était avant qu'il existe des implémentations libres de qualité.

                  http://devnewton.bci.im

                • [^] # Re: Gestionnaire de paquets

                  Posté par . Évalué à 7.

                  C'est fait par Oracle qui sont des connards prêts à coller un procès à n'importe qui dès qu'ils trouvent une piste pour le faire : « Là, eux là-bas, Google, ils utilisent le mot “Java”, pas bien ! »

                  Tu gueulera autant contre btrfs ?

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                  • [^] # Re: Gestionnaire de paquets

                    Posté par (page perso) . Évalué à -3.

                    Non, parce que btrfs c'est sous GPLv2, ce qui est déjà plus sûr. Mais effectivement, le fait que ce soit fait par Oracle n'est pas du tout rassurant.

                    • [^] # Re: Gestionnaire de paquets

                      Posté par . Évalué à 9.

                      Et OpenJDK/GCJ/GNU Classpath c'est quoi ?

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                      • [^] # Re: Gestionnaire de paquets

                        Posté par (page perso) . Évalué à -1.

                        Ben ça ne doit pas être la même chose qu'Oracle Java, parce que je ne connais pas un seul système de contrôle à distance (KVM IP…) qui fonctionne là-dessus, pour mentionner un exemple bien typique.

                        • [^] # Re: Gestionnaire de paquets

                          Posté par . Évalué à 9.

                          J'ai pas compris ton argument. Le langage pue car il n'a jamais était utilisé dans un cas particulier ?

                          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                          • [^] # Re: Gestionnaire de paquets

                            Posté par (page perso) . Évalué à -3.

                            Je ne comprends pas davantage ta question. Ce que je dis, c'est que Java, c'est celui d'Oracle. Qu'il y a des alternatives partiellement compatibles, ce qui ne résout pas complètement les problèmes de Java.

                            • [^] # Re: Gestionnaire de paquets

                              Posté par (page perso) . Évalué à 7.

                              Il y a des versions propriétaires de C++ beaucoup moins compatible avec GCC et pourtant personne ne s'en offusque.

                              http://devnewton.bci.im

                              • [^] # Re: Gestionnaire de paquets

                                Posté par . Évalué à 4.

                                Au moins en C++ il y a plus d'une implémentation conforme avec le standard…

                                • [^] # Re: Gestionnaire de paquets

                                  Posté par (page perso) . Évalué à 2.

                                  Faut voir la gueule du standard aussi…

                                  Il n'y a pas deux compilateurs identiques, les codes sources multiplateformes sont bourrés de ifdef…

                                  http://devnewton.bci.im

                                  • [^] # Re: Gestionnaire de paquets

                                    Posté par . Évalué à 5.

                                    les codes sources multiplateformes sont bourrés de ifdef…

                                    Si tu avais pris le temps d'aller lire un peu de code multiplateforme de qualite (il y a plein de logiciels libres avec du code tres propre) au lieu de d'etaler ton ignorance, tu aurais remarque que les ifdefs dans le code sont:

                                    • pour les parties systeme (genre ouverture de fichier differente entre Unix-like, Windows et plateformes plus exotiques)
                                    • parfois pour la lib standard (generalement une seule version pour tous les Unix, quelques petites differences pour Windows et souvent du code specifique pour le support de trucs comme gamecube, wii et n64 - exemple pris au hasard…)
                                    • et tres tres rarement pour des problemes lies a chaque compilateur (ca se resume a des contournement de bugs dans certains compilateurs, surtout les vieilles versions de GCC parfois encore necessaires pour compiler sur certaines archis)

                                    Si tu as du code spaghetti plein de ifdefs juste pour le support de 4-5 compilateurs, c'est pas les compilateurs le probleme, c'est que tu ecris du code de merde.

                                    • [^] # Re: Gestionnaire de paquets

                                      Posté par . Évalué à 1.

                                      Tu parle d'ignorance ?

                                      Les incompatibilités à cause du compilateur sont très rare. Le bytecode est bien défini et je n'ai jamais vu un .class refusant de s'executer. Les incompatibilités viennent de la bibliothèque standard qui, en java, regroupe tes deux premiers points.

                                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                      • [^] # Re: Gestionnaire de paquets

                                        Posté par . Évalué à 6.

                                        Le bytecode est bien défini et je n'ai jamais vu un .class refusant de s'executer

                                        On parle des compilateurs C++ dans ce bout de thread. Merci d'avoir participe…

                                    • [^] # Re: Gestionnaire de paquets

                                      Posté par (page perso) . Évalué à 2.

                                      Ou peut être qu'on n'a pas la même définition de portable.

                                      http://devnewton.bci.im

                                      • [^] # Re: Gestionnaire de paquets

                                        Posté par . Évalué à 4.

                                        Tu fais tourner du Java sur N64?

                                        • [^] # Re: Gestionnaire de paquets

                                          Posté par (page perso) . Évalué à 2.

                                          Tu peux déployer un même binaire sur Linux, Mac, Windows avec C++?

                                          http://devnewton.bci.im

                                          • [^] # Re: Gestionnaire de paquets

                                            Posté par . Évalué à 2.

                                            En même temps avec Java non plus… Par contre on peut effectivement déployer le même Bytecode qui sera traduit en fonction de l'architecture.

                                          • [^] # Re: Gestionnaire de paquets

                                            Posté par . Évalué à 1.

                                            Je peux te faire du code Java qui n'est pas portable entre ces 3 OS si tu veux, je vois pas ce que ça prouve (à part qu'à un moment il faut bien s'adapter à l'environnement qu'on cible).

                                            • [^] # Re: Gestionnaire de paquets

                                              Posté par . Évalué à 3.

                                              Tu peux générer un binaire qui seras compatible à ces 3 OS, tu ne peux pas en faire de même en C++. Dans l'un c'est peut être compliqué, d'ans l'autre ce n'est pas possible.

                                              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                              • [^] # Re: Gestionnaire de paquets

                                                Posté par . Évalué à 3.

                                                Si tu veux vraiment faire ça, tu peux toujours passer par LLVM en C++, qui fera exactement la même chose que Java, c'est-à-dire transformer le code intermédiaire en code natif au moment de l'exécution.

                                                Effectivement on peut se demander si on veut que le code source soit portable, ou que le binaire soit portable. Dans les deux cas, on peut faire des logiciels multiplateformes avec des contraintes finales un peu différentes.

                                                Recompiler à chaque architecture pose des problèmes, mais ce n'est pas forcément le problème principal pour la portabilité.

                                                • [^] # Re: Gestionnaire de paquets

                                                  Posté par . Évalué à 5.

                                                  Si tu veux vraiment faire ça, tu peux toujours passer par LLVM en C++, qui fera exactement la même chose que Java, c'est-à-dire transformer le code intermédiaire en code natif au moment de l'exécution.

                                                  Ça deviens possible avec ça mais le niveau de complexité est encore bien grand plus grand :

                                                  • il faut déployer llvm
                                                  • gérer la portabilité dans les sources (soit avec un bibliothèque qu'il faudra linker en statique ou déployer)

                                                  Avec python, java ou autre, tu as la vm qui est déjà très répandue (c'est pas négligeable) et tu as presque tout les mécanismes pour faire abstration de l'OS dans le langage ou la bibliothèque standard.

                                                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                                  • [^] # Re: Gestionnaire de paquets

                                                    Posté par . Évalué à 4.

                                                    gérer la portabilité dans les sources (soit avec un bibliothèque qu'il faudra linker en statique ou déployer)

                                                    Vu qu'on peut faire du code non portable en java, ça ne change rien; je suis justement en train de bosser sur une appli java qui se sert d'une bibliothèque codée c++ ;)

                                                    Avec python, java ou autre, tu as la vm qui est déjà très répandue (c'est pas négligeable)

                                                    Gné??? Python n'est pas installé par défaut sur mon Windows, pas plus que la machine virtuelle java. Ce sont des softs tiers qu'on installe manuellement. De plus, j'ai bien un interpréteur java sur mon windows, ça me fait plusieurs mois qu'il me dit qu'il y a une mise à jour, et plusieurs mois que je clique dessus et que ça échoue en me disant qu'il n'y a pas de maj dispo… Lorsqu'un soft aura besoin de la version à jour ça risque d'être galère.
                                                    Python n'est pas installé sur mon windows (par contre perl l'est, (en plus d'être à jours) doit on en conclure que perl est meilleur que java?

                                                    De même flash est très répandu, et c#/.net/mono le deviennent aussi.

                                                    À partir du moment où il faut installer un interpréteur tiers, la complexité est la même.

                                                    Pour devoir faire du code portable, ça fait des années que je n'ai pas eu à faire de morceau de code spécifique à un OS, sauf si le soft devait modifier la conf du système.

                                                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                    • [^] # Re: Gestionnaire de paquets

                                                      Posté par . Évalué à 1.

                                                      Vu qu'on peut faire du code non portable en java, ça ne change rien; je suis justement en train de bosser sur une appli java qui se sert d'une bibliothèque codée c++ ;)

                                                      Et on peut consommer toutes la mémoire de l'ordinateur en C++ (tout en faisant des factory de singleton template) donc je ne vois pas pourquoi il faudrait dire que Java consomme plus de mémoire que le C++ (ou même le C c'est la même chose).

                                                      Gné??? Python n'est pas installé par défaut sur mon Windows, pas plus que la machine virtuelle java.

                                                      Je n'ai pas dis, que c'était disponible en standard, mais plus répandu. Tu le dis toit même pour flash et .NET.

                                                      À partir du moment où il faut installer un interpréteur tiers, la complexité est la même.

                                                      Tu regarde ta cible, ce qu'ils ont comme machine et ce qu'il y a d'installé dessus. S'il n'y a rien, peut être que LLVM seras pertinent (bien que je ne suis pas sûr qu'il gère sa mise à jour de lui même par exemple). Mais de ce que j'en vois les Java, .Net et python sont plus souvent présent que LLVM.

                                                      Pour devoir faire du code portable, ça fait des années que je n'ai pas eu à faire de morceau de code spécifique à un OS, sauf si le soft devait modifier la conf du système.

                                                      Oui tu n'utilise jamais un appel système directement, tu as soit une bibliothèque standard qui suffit (ce qui en C et C++ est rarement le cas sur des vrai projet) soit tu utilise quelque chose comme Qt que tu link en statique ou que tu déploie sur les machines cibles.

                                                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                                                      • [^] # Re: Gestionnaire de paquets

                                                        Posté par . Évalué à 3.

                                                        Tu regarde ta cible, ce qu'ils ont comme machine et ce qu'il y a d'installé dessus

                                                        Généralement chez mes clients, si c'est du windows il y aura .net, si c'est du linux, il y aura un python, et de temps en temps il y aura java. Flash je suis sur à 99% de chance qu'il y soit.

                                                        (ce qui en C et C++ est rarement le cas sur des vrai projet)
                                                        pour les io en c++ pur std::cout et std::cerr ainsi que std::cin, voir des stdio.h avec snprintf et autre.

                                                        Sinon, effectivement j'ai tendance à utiliser du Qt, ce qui point de vu programation est quand même super agréable  ;)

                                                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                        • [^] # Re: Gestionnaire de paquets

                                                          Posté par (page perso) . Évalué à 4.

                                                          Généralement chez mes clients

                                                          J'ai déjà eu des clients avec des parcs composés de windows, de macs, de linux et de solaris, le tout dans des versions différentes, avec du 32 et du 64 bits.

                                                          Quand on te demande de faire tourner un appli C++/Qt pour tout ce petit monde, tu pleures en rêvant de pouvoir la réécrire en Java, en Python ou autre…

                                                          http://devnewton.bci.im

                                                          • [^] # Re: Gestionnaire de paquets

                                                            Posté par . Évalué à 2.

                                                            Quand on te demande de faire tourner un appli C++/Qt pour tout ce petit monde, tu pleures en rêvant de pouvoir la réécrire en Java,

                                                            En fait je pleurerai si il fallait l'écrire en java ou python :). Au pire je me tournerai vers perl.

                                                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                          • [^] # Re: Gestionnaire de paquets

                                                            Posté par . Évalué à 4.

                                                            ah oui et j'oubliais, si j'ai du AIX, HPUX, du arm ou du mips, je ne sais pas trop où chercher la jre:
                                                            http://www.oracle.com/technetwork/java/javase/config-417990.html

                                                            alors que si je cherche une libQt
                                                            http://doc.qt.nokia.com/4.6/supported-platforms.html

                                                            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                            • [^] # Re: Gestionnaire de paquets

                                                              Posté par (page perso) . Évalué à 2.

                                                              Tu n'as pas cherché bien loin, les premiers liens dans les bons moteurs de recherche donnent de quoi trouver des jre pour AIX, HP-UX. Pour arm et mips, debian semble fournir openjdk.

                                                              http://devnewton.bci.im

                                                              • [^] # Re: Gestionnaire de paquets

                                                                Posté par . Évalué à 2.

                                                                Vu le comportement d'Oracle et sa position d'interdire la redistribution de son produit, son attaque sur Dalvik, tu m'excuseras de me contenter de prendre une bibliothèque lgpl que je peux redistribuer moi même, modifier moi même et la redistribuer sans risquer de coûteux procès ?

                                                                http://www.pcinpact.com/news/67728-ubuntu-suppression-java-jdk-licence-oracle.htm

                                                                Donc si je ne trouve pas ce que je cherche sur le site d'Oracle, je préfère considérer que c'est risqué.

                                                                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                                • [^] # Re: Gestionnaire de paquets

                                                                  Posté par (page perso) . Évalué à 2.

                                                                  1) Le java d'Oracle est un logiciel propriétaire.
                                                                  2) Oracle perds son procès contre Dalvik si lamentablement qu'ils ne sont pas près de recommencer.
                                                                  3) Oracle a de bonnes relations avec openjdk.

                                                                  Si tu veux faire du libre avec java, tu peux prendre openjdk l'esprit serein.

                                                                  http://devnewton.bci.im

                                                                  • [^] # Re: Gestionnaire de paquets

                                                                    Posté par . Évalué à 7.

                                                                    Là, en 1024 x 768 ça commence à être dur…

                                                                    • [^] # Re: Gestionnaire de paquets

                                                                      Posté par (page perso) . Évalué à 3.

                                                                      gnii ?

                                                                      • [^] # Re: Gestionnaire de paquets

                                                                        Posté par (page perso) . Évalué à 5.

                                                                        il parle de l'écrasement des commentaires sur la droite àmha ;-)

                                                                        • [^] # Re: Gestionnaire de paquets

                                                                          Posté par . Évalué à 6.

                                                                          voyons ça se saurait si la largeur des commentaires se réduisait à chaque réponse; et on aurait fait quelque chose pour gérer une imbrication trop importantes; à moins qu'on ai laissé cette limitation justement pour indiquer aux trolleurs qu'a partir d'un certain point la discussion était stérile et qu'il était inutile de continuer.

                                                                          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                                          • [^] # Re: Gestionnaire de paquets

                                                                            Posté par (page perso) . Évalué à 10.

                                                                            à moins qu'on ai laissé cette limitation justement pour indiquer aux trolleurs qu'a partir d'un certain point la discussion était stérile et qu'il était inutile de continuer.

                                                                            Malheureusement, ça a mené à la popularisation des écrans larges pour pouvoir troller efficacement.

                                                                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                                                    • [^] # Re: Gestionnaire de paquets

                                                      Posté par (page perso) . Évalué à 4.

                                                      Gné??? Python n'est pas installé par défaut sur mon Windows, pas plus que la machine virtuelle java. Ce sont des softs tiers qu'on installe manuellement. De plus, j'ai bien un interpréteur java sur mon windows, ça me fait plusieurs mois qu'il me dit qu'il y a une mise à jour, et plusieurs mois que je clique dessus et que ça échoue en me disant qu'il n'y a pas de maj dispo… Lorsqu'un soft aura besoin de la version à jour ça risque d'être galère.

                                                      Si tu utilises un OS de geek où il faut tout faire à la main aussi…

                                                      http://devnewton.bci.im

                              • [^] # Re: Gestionnaire de paquets

                                Posté par (page perso) . Évalué à 2.

                                Parce qu'il n'y a pas de compilateur standard de fait en C++, du coup un code standard compile avec GCC (si le standard n'est pas trop récent évidemment). Tandis qu'en Java, si tu utilise la plateforme standard, tu peux être incompatible avec openjdk.

                                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Gestionnaire de paquets

                      Posté par . Évalué à 5.

                      C'est même plus fait par Oracle, le principal dev (Chris Mason) a changé de boîte récemment.

              • [^] # Re: Gestionnaire de paquets

                Posté par (page perso) . Évalué à 4.

                Pourquoi?

                Je pense que c'est surtout une grosse blague de tenter de justifier de mettre du java dans un projet comme Emacs codé en C/Elisp !

                Et cet argument est reprenable sur tout les projets n'utilisant pas de base java…

        • [^] # Re: Gestionnaire de paquets

          Posté par (page perso) . Évalué à -6.

          (normal c'est Apache, un bon repaire de fanas de Java, ça)

          • [^] # Re: Gestionnaire de paquets

            Posté par . Évalué à 1. Dernière modification le 12/06/12 à 18:22.

            tu proposes quoi (déjà je suis pas sûr que tu saches de quoi tu parles (je suis un fanatique des projets de la fondation apache aussi))?

            Pourquoi cette réaction épidermique?
            Y a un développeur Java qui t'a fait du mal ?
            C'est le côté business loto du vocabulaire des Évangélistes JEE qui te revient pas (à moi non plus, mais faut passer outre) ?

            • [^] # Re: Gestionnaire de paquets

              Posté par (page perso) . Évalué à -2.

              Y a un développeur Java qui t'a fait du mal ?

              Non, c'est Java lui-même qui m'a fait mal. J'ai été traumatisé par un DocumentBuilderFactory.getInstance().newDocumentBuilder().createDocument() : c'est un exemple typique d'abus de patrons de conception, avec ici un singleton de fabrique de fabrique de documents au sein même de la bibliothèque standard.

              • [^] # Re: Gestionnaire de paquets

                Posté par . Évalué à 2. Dernière modification le 12/06/12 à 20:06.

                si je peux te donner un conseil, c'est de ne pas trop s'entêter quand ça bloque, et revenir sur un problème après avoir pris du recule, je te dis ça car moi aussi je suis entêté.

                Aujourd'hui ce type de pattern est moins rencontré, on utilise plus les "Factory ceci", on utilise de l'injection de dépendance (comme avec Guice ou Spring, eclipse E4 (Foutaise)), personne de sensé ne devrait aimer J2EE, mais voilà maintenant il y a JEE, Grails et autres, donc il ne faut pas rester sur de mauvaises impressions.

                Si tu veux recommencer à perdre du temps avec Java, je te recommanderais Groovy (un python Like) pour commencer. Il faut surtout un bon IDE et les trucs comme ce que tu décris posent moins de problèmes car la complétion aide.

              • [^] # Re: Gestionnaire de paquets

                Posté par (page perso) . Évalué à 6.

                et tu as d'autres exemples ? Car là on a l'impression que tu as juste bloqué sur un seul cas et c'est tout… mais bon, tu sais, ça se soigne hein ;-)

              • [^] # Re: Gestionnaire de paquets

                Posté par (page perso) . Évalué à 5.

                Redonne une chance à Java, l'écosystème a beaucoup évolué.

                Les annotations, les types génériques, maven, un openjdk libre, des JIT beaucoup plus performants, des frameworks webs aussi différentes que wicket, play ou vaadin, la génération de parsers avec jaxb ou protobuf, la fin de l'abus de factory remplacé par l'injection de dépendances, des utilitaires comme guava ou apache commons pour combler les manques de l'api de base…

                Le monde Java d'aujourd'hui n'a rien avoir avec celui du début des années 2000.

                http://devnewton.bci.im

                • [^] # Re: Gestionnaire de paquets

                  Posté par . Évalué à 4.

                  Je ne suis pas un grand développeur et Java m'a toujours impressionné par sa complexité. Même si je connais play! qui est un très bon framework, ton commentaire ne m'a toujours pas rassuré sur la complexité du truc. Ça fait encore très usine à gaz par rapport à Ruby On Rails par exemple, ou Django.

                  • [^] # Re: Gestionnaire de paquets

                    Posté par . Évalué à 3.

                    En même temps, sur cette histoire de xmlfactory machin, il faut vraiment remettre les choses dans leur contexte si on ne veux pas les comparer avec n'importe quoi.
                    Déja l'API a pas loin de dix ans, et n'a pas bougé. C'est une performance qu'il faut relever, parce qu'à l'époque, les fournisseurs de services xml s'en donnaient à cœur joie pour faire de leurs implémentations des standards de fait, tout en s'en tenant aux standards du w3c (saxon, xerces, et compagnie).
                    Il y avait donc la contrainte supplémentaire de fabriquer une API générique, extensible et néanmoins puissante, pour fournir toute la clique xml: xpath, xslt, xtruc, etc. . Je dis pas que ya pas eu des ratés, cependant l'API est largement utilisable; il faut bien penser à ces points sous peine de juger trop vite.

                    • [^] # Re: Gestionnaire de paquets

                      Posté par . Évalué à 4.

                      Je pense que c'est très pertienent. On compare à ce que l'on trouve en python ou en ruby, qui n'ont pas (ou pas eu) d'API stable aussi longtemps de même pour les bibliothèque. Aujourd'hui il existe des bibliothèques plus récentes et aevc une API plus agréable à utiliser en Java. C'est le poids des années la dette technique, mais si on veut être utilisable sur le longterme en entreprise on est obligé de passer par là et de maintenir des vielleries.

                      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Emacs 24

    Posté par . Évalué à -5.

    Super, projet toujours aussi actif :D

  • # écrit en Lisp... et en C

    Posté par (page perso) . Évalué à 6.

    Merci pour la dépèche! Un petit détail cependant:

    Emacs est un Éditeur de MACroS un peu particulier puisqu’il est écrit en Lisp tout en étant son propre interpréteur.

    D'après wikipedia:

    GNU Emacs est écrit en C et fournit Emacs Lisp (lui-même écrit en C) comme langage d'extension.

    D'après les sources, y'a un paquet de fichier en C, donc je tends à donner raison à Wikipedia sur ce coup là.

    • [^] # Re: écrit en Lisp... et en C

      Posté par (page perso) . Évalué à 6.

      En fait, oui, l'interpréteur est principalement écrit en C, mais Emacs est majoritairement écrit en Lisp (interprété par du code C compilé…).

  • # Emacs est un bon système...

    Posté par (page perso) . Évalué à 10.

    Vous connaissez sans doute la blague :

    Emacs est un bon système d'exploitation, mais ce serait bien qu'on lui ajoute un éditeur de texte.

    J'ai eu le plaisir de la faire connaître à Richard Stallman il y a une dizaine d'année un soir où nous dînions avec Odile Benassy près des Halles à Paris. Richard a tout de suite réagi en prenant la critique très au sérieux et c'est Odile qui lui a expliqué que c'était une plaisanterie car il ne pensait pas que emacs pouvait être compliqué. Il faut dire qu'il s'en sert pour lire son courrier.

    • [^] # Re: Emacs est un bon système...

      Posté par . Évalué à 3.

      Il faut dire qu'il s'en sert pour lire son courrier.

      Comme beaucoup de monde. Le org mode est très utilisé aussi.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Emacs est un bon système...

        Posté par (page perso) . Évalué à 1.

        Moi, perso, mes courriels avec Emacs, je trouve pas ça super non plus (je pense à gnus ou VM…).

        Et puis, la philosophie Unix me convient : faire une chose et le faire bien. Emacs est parfait pour faire de l'édition de texte, et pour ça, j'en suis ravi (programmation, org & co).

        Aller, je mens un peu puisque j'utilise org-calendar (en fait, calfw par dessus).

        • [^] # Re: Emacs est un bon système...

          Posté par . Évalué à 3.

          Et puis, la philosophie Unix me convient : faire une chose et le faire bien. Emacs est parfait pour faire de l'édition de texte, et pour ça, j'en suis ravi (programmation, org & co).

          je suis un fan d'emacs et je m'en sers quotidiennement, mais dans le style faire tout bien, j'ai quand même bien galéré avec le mode mule pour gérer l'utf8 … heureusement ça s'est amélioré.

    • [^] # Re: Emacs est un bon système...

      Posté par . Évalué à 6.

      Ou alors il faut dire qu'il baigne dedans depuis tellement longtemps qu'il est totalement incapable de se rendre compte de la complexité du bouzin.

      Sérieusement, Emacs nécessite un temps d'apprentissage autrement supérieur à des logiciels que je pensais déjà élitistes. Difficile de justifier cet apprentissage auprès de codeurs non hautement productifs.

      • [^] # Re: Emacs est un bon système...

        Posté par . Évalué à 7.

        Emacs a des modes qui le rendent quasi irremplaçable comme éditeur. J'ai deux exemples pour ça :
        Perso, pour coder du vhdl, je ne sais pas ce que peuvent utiliser les autres développeur, mais je ne peux pas me passer du vhdl-mode. D'ailleurs, plusieurs éditeurs pour fpga proposent leur outil, mais sur les wikis qu'il gèrent n'hésitent pas à le documenter. Bon, je ne me considère pas comme un débutant sur emacs, c'est mon éditeur de prédilection depuis 1995.

        Pour l'autre exemple, une collègue qui code en java a du xml à gérer. Pour cela, elle a finalement laissé tomber eclipse pour utiliser le mode nxml (avec les rng qui vont bien).

        Avec les nouvelles UI, on peut commencer avec le mode clicodrome et apprendre peu à peu les raccourcis qui vont te transformer en power-user.

        • [^] # Re: Emacs est un bon système...

          Posté par . Évalué à 1.

          Il manque quand même pas mal de truc à emacs, et cela devient lourd. La navigation entre plein de fichier d'un projet est pénible. L'autocompletion était une fonctionnalité majeur, maintenant eclipse fait de l'autocompletion sur toute la lib, il est aussi capable de retrouver la définition et les usages d'une fonction. Comment tu fais cela en emacs ?

          "La première sécurité est la liberté"

          • [^] # Re: Emacs est un bon système...

            Posté par (page perso) . Évalué à 3.

            CEDET le fait, donc emacs le fait.

          • [^] # Re: Emacs est un bon système...

            Posté par . Évalué à 3.

            définition & déclaration des fonctions

            au niveau basique tu as ebrowse qui te le fait très bien.

            Tu peux même avoir une vision arborescente des classe, voir du premier coup d'oeuil les fonction, les membres, ceux qui sont statique, virtuel pur, retour constant, constant pour l'objet, bref une très bonne lisibilité de l'objet.

            Si tu veux la complétion contextuelle effectivement CEDET marche assez bien.

            Pour la navigation entre pleins de fichier d'un projet, le ctrl-x b + premières lettres du nom de fichier est pas mal, sinon j'ai une console à proximité où je tape fedit (avec completion sur le nom de fichier) et ça me l'ouvre dans le buffer courant.
            Sinon tu as la speedbar, ou encore CEDET.
            Mais généralement j'ai pas besoin de savoir quel fichier ouvrir, je cherche juste une définition ou une déclaration et pour ça EBROWSE t'envoie directement où il faut.

            j'aime beaucoup le eshell, avec toute les commande qui vont bien (un bon grep des famille par exemple)

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Emacs est un bon système...

              Posté par . Évalué à 3.

              CEDET a l'air peu supporté sous windows et en version emacs 24.

              ebrowse a l'air sympa, mais c'est que pour du c++.

              la speedbar j'ai utilisé mais j'avais vraiment du mal avec l'ergonomie.

              Faut que je creuse le eshell.

              "La première sécurité est la liberté"

              • [^] # Re: Emacs est un bon système...

                Posté par . Évalué à 6.

                je dois dire que je suis généralement sous C/C++, et donc ebrowse me donne une très bonne visibilité sur les projets; pour le reste j'ai tendance à beaucoup mixer emacs et le reste de mon environnement de travail, j'ai donc une plâtrée de mini utilitaire en bash ou parfois en elisp.

                Le truc c'est que j'ai tellement l'habitude des 'détail' d'emacs que dès que j'utilise autre chose je me met à pester sur le fonctionnement de la sélection (ctrl-espace y a que ça de vrai), le kill-ring (ctrl-y puis cyclage alt-y), le isearch/search automatique selon les majuscule ou non, le replace qui conserve les majuscules, et surtout les macros, le switch de buffer au clavier, les split-screen, la capacité d'ouvrir un fichier à partir de la ligne de commande d'à coté… Je pourrais continuer ainsi longtemps.

                Commencer à enregistrer une macro, utiliser la recherche, ainsi que les différents truc, stopper l'enregistrement, répéter la macro. Et si ça ne marche pas éditer la macro, et puis l'enregistrer.

                J'ai déjà du jongler avec 3/4 macro enregistrée et nommées, et mises en raccourcis.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Emacs est un bon système...

            Posté par . Évalué à 1.

          • [^] # Re: Emacs est un bon système...

            Posté par (page perso) . Évalué à -4.

            Avant de dire qu'il manque des trucs à emacs, c'est bien de vérifier que le problème ne se situe pas plutôt entre la chaise et le clavier :

            capable de retrouver la définition et les usages d'une fonction. Comment tu fais cela en emacs ?

            Quand tu demandes à emacs la valeur d'une variable, n'importe quelle variable, pas juste celle d'un de tes programmes mais par exemple celle d'une routine emacs spécifique, il te donne :

            La valeur de cette variable
            Un lien cliquable vers l'endroit dans le source ou elle est définie
            Et une documentation en humain, qui contient généralement des liens aussi, grace une syntaxe spéciale

            Exemple, si tu demandes de la doc sur "mailcap-download-directory" (Mx describe-function RET "mailcap-download-directory" ou C-h f "mailcap-download-directory" - si le point est sur le nom de la variable, ce dernier est entré par défaut) donne ceci :

            mailcap-download-directory is a variable defined in `mailcap.el'.
            Its value is nil

            Documentation:
            Directory to which `mailcap-save-binary-file*' downloads files by default.
            nil means your home directory.

            You can customize this variable.

            [back]

            Tu vois le terme "mailcap.el" là-haut ? C'est un lien vers l'endroit exact de la lib où est définie la variable.

            Et là, mailcap.el est une lib en elisp, mais si tu demandes de l'info sur une fonction bien primitive, genre "point", là le lien point directement sur les sources d'emacs :) Laisse-moi répéter ça : Emacs te fournit un lien vers l'endroit dans son propre source où est définie la fonction "point". Ça fait ça, eclipse ?

            Pour ce qui est de la complétion, tu fais ce que tu veux, mais moi quand je demande une complétion, emacs va la chercher dans

            -Le texte précédant le terme à compléter
            -Le texte suivant le terme à compléter
            -Les éléments de doc et de source sus-cités
            -Mon système de fichier (super pour compléter le chemin vers un fichier, et ça marche à distance avec tramp)
            -N'importe où ailleurs.

            La navigation entre plein de fichier d'un projet est pénible

            Une déclaration de ce genre, en plus d'être fausse n'est pas très constructive ; j'allais répondre en expliquant comment je m'y prends pour "naviguer entre plein de fichier d'un projet" et puis finalement je vais plutôt sortir jouer avec le chien dans le jardin, tiens.

      • [^] # Re: Emacs est un bon système...

        Posté par . Évalué à 5.

        oui, emacs est difficile à apprendre, personnellement, il m'a fallut plusieurs tentatives (et refaire le tutorial 4 fois au moins) mais c'est tellement plaisant quand on l'utilise après.

        On a l'impression d'être un vrai hacker :)

        • [^] # Re: Emacs est un bon système...

          Posté par (page perso) . Évalué à 7.

          On a l'impression d'être un vrai hacker :)

          Ha, un peu comme le |337 5p34k alors ! T'as l'impression mais en fait non.

          (bon, j'dis ça, mais j'ai codé pendant pas mal de temps sous emacs, y compris professionnellement, y compris sous windows…)

  • # C'est sûr pour le nom ?

    Posté par (page perso) . Évalué à 10.

    Son nom signifie « Editing MACroS »

    On m'a toujours dis que cela signifiait "Escape-Meta-Alt-Control-Shift"…

    • [^] # Re: C'est sûr pour le nom ?

      Posté par (page perso) . Évalué à 9.

      Non, non, c'est récursif, comme GNU :

      Emacs Makes All Computers Slow

      • [^] # Re: C'est sûr pour le nom ?

        Posté par (page perso) . Évalué à 9.

        La loi de Moore couplée à la stagnation des ressources nécessaires à faire tourner Emacs ont rendu cette blague caduque depuis les années 90…

        Cadeau la version mise à jours :

        Eclipse : a Computing Legend In Performance Sucking Environment

      • [^] # Re: C'est sûr pour le nom ?

        Posté par . Évalué à 7.

        moi on m'avait dit Eight Megabytes and Constantly Swapping ;)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: C'est sûr pour le nom ?

      Posté par . Évalué à 4.

      The foot pedals, shoulder buttons, elbow switches, and tongue actuators I installed help with emacs, too!

      Traduction libre :
      Les pédales, interrupteurs d'épaule, actionneurs par coude et boutons linguaux aident pas mal avec Emacs !

  • # µEmacs

    Posté par (page perso) . Évalué à 4.

    Quelqu'un sait pourquoi Linus l'utilise?
    Qu'a t'il de plus ou moins par rapport a emacs?

    • [^] # Re: µEmacs

      Posté par . Évalué à 10.

      Parait que Linus utilise des slips lapons en peau retournée de canard, quelqu'un sait pourquoi ce type de slip est supérieur et ou je peux m'en procurer?

      • [^] # Re: µEmacs

        Posté par (page perso) . Évalué à 10.

        Il peut être, je pense, légitime de connaitre les arisons d'utilisation de Emacs de la part d'une personne qui l'utilise activement.

        Oui Linus Torvalds n'est pas un gourou surpuissant, mais son avis pour tout ce qui touche la programmation est je pense assez intéressant, comme pour tout codeur de longue date sur de gros projets.

        • [^] # Re: µEmacs

          Posté par (page perso) . Évalué à 2.

          C'est l'idée derrière ma question, Linus a souvent un avis très tranché (voir même trollesque) sur les choses, mais son avis est souvent justifié. Donc je pense que si il utilise µemacs c'est qu'il a une bonne raison, cependant j'ai l'impression qu'il est peu avare de détails la dessus.

    • [^] # Re: µEmacs

      Posté par (page perso) . Évalué à 2.

      À vrai dire, c'était principalement car c'était un ami à lui qui lui en avait parlé et il était léger. Le code était semi-propriétaire je crois et le développement de μEmacs n'est plus poursuivit. Le lien que je donne est l'image que l'on peut trouver de ce que maintient Linus pour lui-même. Vu les dates, c'est pas non plus très à jour. Bref, il fait ce qu'il veut.

  • # Emacs 24 sur Ubuntu et Debian

    Posté par . Évalué à 5.

    Si vous cherchez des paquetages Emacs récents pour votre Debian ou votre Ubuntu : http://emacs.naquadah.org/

  • # font

    Posté par . Évalué à 1.

    Bizarre la font courrier new en taille 10 semble plus haute sur emacs 24 que sur emacs 22. C'est pas très beau.

    "La première sécurité est la liberté"

    • [^] # Re: font

      Posté par . Évalué à 0.

      J'ai ça dans mon .emacs.d/init.el pour ceux qui veulent changer leur police :

      (custom-set-variables
       '(default-frame-alist (quote ((font . "Inconsolata-12"))))
      
      

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.