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
- EmacsWiki se meurt, vive WikEmacs !
- Forks d'Emacs
- Remerciements
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)
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).
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.
Aller plus loin
- Site Officiel (941 clics)
- EmacsWiki (159 clics)
- WikEmacs (198 clics)
- Sortie officielle (130 clics)
# ...bien que ...
Posté par Michaël Ughetto . Évalué à 3.
J'imagine que tu voulais dire qu'installer des paquets n'est pas une sinécure ?
[^] # Re: ...bien que ...
Posté par patrick_g (site web personnel) . Évalué à 3.
C'est corrigé.
[^] # Re: ...bien que ...
Posté par Didrik Pining . Évalué à 7.
C'est pas faux
[^] # Re: ...bien que ...
Posté par teoB . Évalué à 1.
il a vu le jour
C-y, commande utilisée pour coller la dernière chose copiée
bien que certains soient installables grâce
sau gestionnaire de paquet[^] # Re: ...bien que ...
Posté par BAud (site web personnel) . Évalué à 2.
corrigé, merci.
# Gestionnaire de paquets
Posté par mornik . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par jbbourgoin (site web personnel) . É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 mornik . É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 jbbourgoin (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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 isildur37 . É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 devnewton 🍺 (site web personnel) . Évalué à 2.
Il existe un gestionnaire de dépendances qui ne fait que ça et qui le fait bien: http://ant.apache.org/ivy/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Sauf qu'il est en Java.
[^] # Re: Gestionnaire de paquets
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Comme beaucoup de très bons logiciels libres!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 2.
Pourquoi?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # tentative d'explication
Posté par jbbourgoin (site web personnel) . Évalué à 9.
Parce que.
[^] # Re: tentative d'explication
Posté par zebra3 . É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 barmic . É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 !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Pour plein de raisons.
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 fredoche . É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 claudex . É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 devnewton 🍺 (site web personnel) . Évalué à 6.
Et alors? Il y a bien des compilateurs C++ proprios qui génèrent du code plus performant que gcc.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par claudex . É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 YBoy360 (site web personnel) . Évalué à 3. Dernière modification le 12 juin 2012 à 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 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
Tous les systèmes de prise de contrôle genre KVM IP.
[^] # Re: Gestionnaire de paquets
Posté par CrEv (site web personnel) . É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 G.bleu (site web personnel) . Évalué à 10.
Cette phrase sur la dépêche d'Emacs mérite la potence !
[^] # Re: Gestionnaire de paquets
Posté par YBoy360 (site web personnel) . É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 Alex . É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 devnewton 🍺 (site web personnel) . Évalué à 3.
Le troll est parti de ma suggestion d'Ivy comme système de gestion de dépendance…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par Alex . Évalué à 2.
je parlais pour les jar, comme gem pour ruby
[^] # Re: Gestionnaire de paquets
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Alors ivy est un système de dépendances générique. On peut s'en servir pour récupérer des jar, des dll ou des .poney. Pour les jars, il est compatible avec un autre outil: Maven.
Dans le monde Java, Maven est l'équivalent de gem en ruby.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par Alex . Évalué à 0.
Arf, en effet j'avais oublié maven… c'est ça de faire top de dev android ;)
[^] # Re: Gestionnaire de paquets
Posté par barmic . Évalué à 2.
Tu peux utiliser maven pour du développement android (ou du gradle par exemple).
http://code.google.com/p/maven-android-plugin/wiki/GettingStarted
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
openjdk, harmony, dalvik?
Et alors? Il faut utiliser une implémentation libre.
Mmmh…
Vu le niveau des arguments utilisés, ils pourraient attaquer n'importe quel langage interprété. Heureusement ils sont en train de perdre lamentablement.
Je faisais ça aussi, mais c'était avant qu'il existe des implémentations libres de qualité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par barmic . Évalué à 7.
Tu gueulera autant contre btrfs ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 barmic . Évalué à 9.
Et OpenJDK/GCJ/GNU Classpath c'est quoi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 barmic . Évalué à 9.
J'ai pas compris ton argument. Le langage pue car il n'a jamais était utilisé dans un cas particulier ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 7.
Il y a des versions propriétaires de C++ beaucoup moins compatible avec GCC et pourtant personne ne s'en offusque.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par Shuba . Évalué à 4.
Au moins en C++ il y a plus d'une implémentation conforme avec le standard…
[^] # Re: Gestionnaire de paquets
Posté par devnewton 🍺 (site web personnel) . É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…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par Littleboy . Évalué à 5.
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:
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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par Littleboy . Évalué à 6.
On parle des compilateurs C++ dans ce bout de thread. Merci d'avoir participe…
[^] # Re: Gestionnaire de paquets
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ou peut être qu'on n'a pas la même définition de portable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par Littleboy . Évalué à 4.
Tu fais tourner du Java sur N64?
[^] # Re: Gestionnaire de paquets
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Tu peux déployer un même binaire sur Linux, Mac, Windows avec C++?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par Spack . É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 Shuba . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par TortuXm . É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 barmic . Évalué à 5.
Ça deviens possible avec ça mais le niveau de complexité est encore bien grand plus grand :
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par fearan . Évalué à 4.
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++ ;)
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 barmic . Évalué à 1.
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).
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.
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.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de paquets
Posté par fearan . Évalué à 3.
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.
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 devnewton 🍺 (site web personnel) . Évalué à 4.
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…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par fearan . Évalué à 2.
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 fearan . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par fearan . É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 ?
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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par Philip Marlowe . Évalué à 7.
Là, en 1024 x 768 ça commence à être dur…
[^] # Re: Gestionnaire de paquets
Posté par Juke (site web personnel) . Évalué à 3.
gnii ?
[^] # Re: Gestionnaire de paquets
Posté par BAud (site web personnel) . Évalué à 5.
il parle de l'écrasement des commentaires sur la droite àmha ;-)
[^] # Re: Gestionnaire de paquets
Posté par fearan . É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 claudex . Évalué à 10.
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 devnewton 🍺 (site web personnel) . Évalué à 4.
Si tu utilises un OS de geek où il faut tout faire à la main aussi…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par claudex . É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 devnewton 🍺 (site web personnel) . Évalué à 4.
Si tu fais du libre avec du libre, ta plateforme standard, c'est openjdk.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par claudex . Évalué à 2.
C'est bien le problème, ce n'est pas courant en Java. Par exemple, un logiciel Apache qui n'est pas compatible avec Openjdk http://esme.apache.org/faq.html
« 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 devnewton 🍺 (site web personnel) . Évalué à 1.
Ce n'est pas un problème spécifique à Java: des logiciels python/c++/ruby qui ont des problèmes de compatibilités entre les différentes versions des langages/compilos/OS, on en voit tout le temps.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par YBoy360 (site web personnel) . Évalué à 4.
je veux pas être désobligeant mais c'est un bug qui date de 2008, j'utilise quotidiennement OpenJDK avec une myriade de logiciels, et il n'y a vraiment pas de problème.
comme disent les autres, si on compare au C/C++, les incompatibilités entre les différentes implémentations de la plateforme Java c'est vraiment peanuts.
[^] # Re: Gestionnaire de paquets
Posté par Alex . Évalué à 3.
je ne vois surtout pas l'interêt de comparer avec un langage qui compile en natif. Autant comparer avec c#, ruby, st…
[^] # Re: Gestionnaire de paquets
Posté par djano . Évalué à 2.
Ha ha ha ha ha ha ha ha!
Le problème que tu cites est lié a la librairie Yahoo UI qui a un problème avec l'implémentation JavaScript d'OpenJDK (Rhino) qui a un bug:
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/287035
http://sourceforge.net/tracker/index.php?func=detail&aid=2184760&group_id=165715&atid=836476
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149
Tout ça pour ça! Merci pour la rigolade!
Bref, il n'y a donc aucun souci. Merci de le signaler!
[^] # Re: Gestionnaire de paquets
Posté par daemontux . É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 G.bleu (site web personnel) . Évalué à 4.
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 devnewton 🍺 (site web personnel) . Évalué à 0.
Il suffit de changer aussi l'éditeur pour le très Jedit :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -6.
(normal c'est Apache, un bon repaire de fanas de Java, ça)
[^] # Re: Gestionnaire de paquets
Posté par YBoy360 (site web personnel) . Évalué à 1. Dernière modification le 12 juin 2012 à 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 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
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 YBoy360 (site web personnel) . Évalué à 2. Dernière modification le 12 juin 2012 à 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 CrEv (site web personnel) . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Gestionnaire de paquets
Posté par lezardbreton . É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 fredoche . É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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Emacs 24
Posté par woprandi . Évalué à -5.
Super, projet toujours aussi actif :D
# écrit en Lisp... et en C
Posté par elboulangero (site web personnel) . Évalué à 6.
Merci pour la dépèche! Un petit détail cependant:
D'après wikipedia:
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 Jiehong (site web personnel) . É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 Pierre Jarillon (site web personnel) . É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 barmic . Évalué à 3.
Comme beaucoup de monde. Le org mode est très utilisé aussi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Emacs est un bon système...
Posté par Jiehong (site web personnel) . É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 Christophe Turbout . Évalué à 3.
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 Maclag . É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 JN . É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 Nicolas Boulay (site web personnel) . É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 Pierre marijon (site web personnel) . Évalué à 3.
CEDET le fait, donc emacs le fait.
[^] # Re: Emacs est un bon système...
Posté par fearan . É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 Nicolas Boulay (site web personnel) . É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 fearan . É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 lendemain . Évalué à 1.
je n'ai pas testé mais tu as:
http://eclim.org/
https://github.com/Golevka/emacs-clang-complete-async
https://github.com/aemoncannon/ensime
et sans doute d'autres
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Emacs est un bon système...
Posté par coïn . É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 CrEv (site web personnel) . Évalué à 7.
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 Christophe Merlet (site web personnel) . Évalué à 10.
On m'a toujours dis que cela signifiait "Escape-Meta-Alt-Control-Shift"…
[^] # Re: C'est sûr pour le nom ?
Posté par jjl (site web personnel) . Évalué à 9.
Non, non, c'est récursif, comme GNU :
[^] # Re: C'est sûr pour le nom ?
Posté par G.bleu (site web personnel) . É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 :
[^] # Re: C'est sûr pour le nom ?
Posté par fearan . É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 krouik . É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 weeber (site web personnel) . É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 krumtrash . É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 Renault (site web personnel) . É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 weeber (site web personnel) . É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 Jiehong (site web personnel) . É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 Damien Cassou . Évalué à 5.
Si vous cherchez des paquetages Emacs récents pour votre Debian ou votre Ubuntu : http://emacs.naquadah.org/
# font
Posté par Nicolas Boulay (site web personnel) . É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 Damien Cassou . Évalué à 0.
J'ai ça dans mon .emacs.d/init.el pour ceux qui veulent changer leur police :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.