Context
Vim, le fameux éditeur de texte, est un logiciel ayant plus de 20 ans, qui contient environ 300 000 lignes de code de vieux C effrayant, que peut de gens comprennent.
Le mainteneur (unique ?) de vim, Bram Moolenaar, refuse de factoriser certaines parties du code, et est très prudent avant d'accepter des patchs, car c'est lui qui devra en assurer la maintenance.
Conséquence de tout ça : vim est très dépendant d'une seule personne, et évolue très lentement.
Neovim
Neovim est un fork de vim très récent (fin janvier 2014), qui a pour objectif premier de simplifier la maintenance de vim :
- modernisation de système de compilation : utilisation de cmake ;
- suppression du code assurant la compatibilité avec de vieux systèmes ;
- utilisation d'une bibliothèque externe (libuv) pour s'abstraire des différentes entre les systèmes d'exploitations ;
- factorisation « agressive » du code ;
- meilleur séparation du code entre différents développeurs.
Par la suite, un nouveau système de plugins est prévu, ainsi que la possibilité de pouvoir créer plus facilement des interfaces graphiques (à la manière des plugins).
Pour les utilisateurs d'Arch Linux, neovim est disponible dans aur. La configuration et les plugins de vim sont compatibles (.neovimrc et .neovim/).
Une campagne de financement participatif est en cours : https://www.bountysource.com/fundraisers/539-neovim-first-iteration
Elle a déjà atteint le premier objectif de 10 000 $ en à peine 48h00 !
Pour l'utilisateur final, neovim n'a actuellement pas d'intérêt particulier, mais il peut devenir à terme très intéressant :
- développement plus pérenne (ne repose pas sur une seule personne) ;
- correction de bugs et nouvelles fonctionnalités plus vite intégrées.
Site du projet (casi vide) : http://neovim.org/
neovim sur github : https://github.com/neovim/neovim/
# La réponse de Bram Moolenaar
Posté par Gof (site web personnel) . Évalué à 10.
https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8
[^] # Re: La réponse de Bram Moolenaar
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 26 février 2014 à 08:10.
Mais si pour ça il faut refactoriser car le code est trop bordélique et que si on améliore sans refactoriser on y passe 10x plus de temps, et qu'en même temps l'idée même de refactoriser n'est pas acceptée, je comprend parfaitement le fork face à cette réponse qui ne veut pas voir le problème.
Pour éviter les bugs, c'est simple : on ne code pas. Si j'ai bien compris c'est d'ailleurs le reproche fait (que ça n'évolue pas très vite).
Plus de fonctionnalités implémentées car les développeurs seront alors libérés d'un code qui est devenu trop complexe au fil des ans et n'est plus adapté?
[^] # Re: La réponse de Bram Moolenaar
Posté par David Demelier (site web personnel) . Évalué à 1.
En parlant de ça, j'ai un bug qui date d'au moins plusieurs années (mais peut-être c'est ma configuration). Quand je découpe la fenêtre en deux, si j'entame un commentaire sur la fenêtre du haut, la fenêtre du bas devient 100% en couleur de commentaire (normal puisque j'ai pas terminé le commentaire). Mais quand je termine d'écrire mon commentaire, la fenêtre du bas garde la couleur de commentaire ce qui est assez énervant.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: La réponse de Bram Moolenaar
Posté par barmic . Évalué à 9.
Pour éviter d'introduire des bugs lors de refactorisation, il est possible de créer des tests aussi. C'est d'ailleurs intéressant parce qu'on peut se rendre compte que l'ancienne version est très difficile à tester alors que la nouvelle, en plus des gains, en lisibilité/performance/fonctionnalité/sécurité est plus facile à tester.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La réponse de Bram Moolenaar
Posté par Philippe F (site web personnel) . Évalué à 10.
Je me suis renseigné un peu sur le projet. Ayant eu la naïveté de vouloir coder un clone de Vim par le passé ( Yzis ) et ayant tenté plusieurs projets d'intégration de Vim (KVim et autres), j'étais curieux de voir ce que ça donne.
Rappelons quand même que:
Les points négatifs:
pour citer des gros points faibles :
Pour moi, Vim est un très bon éditeur, qui commence à montrer son age. Les pratiques de développements d'un autre age ne tiennent plus la route face à la popularité et aux nouveaux enjeux d'un éditeur moderne. C'est un peu la FSF contre Github.
Donc un rafraichissement tel que celui proposé me semble tout à fait louable, avec un bon potentiel d'amélioration. Après, il ne faut pas sous-estimer la tâche. Vim est très gros, maintenir un fork de cette taille est un boulot monstrueux, et ce n'est pas sur qu'une équipe même motivée arrive à faire le travail de fond que fait Bram depuis des lustres.
J'ai regardé un peu le CV de Thiago de Arruda qui est l'auteur de cette initiative. C'est pas un manchot, il a déjà codé des trucs intéressants avec Vim, mais globalement, il est loin d'avoir donné la preuve qu'il est à la hauteur de l'enjeu. Forker un gros projet, c'est très difficile à tenir dans le temps. Les forks réussis qui durent sont extrèmement rares, il faut l'adhésion d'une partie de l'équipe de développement du coeur pour que ça réussisse. Sinon, ça retombe au bout de quelques mois.
En tout cas, bonne initiative. Ca me permettra peut-être de lacher SublimeText pour revenir à Vim…
[^] # Re: La réponse de Bram Moolenaar
Posté par arnaudus . Évalué à 2.
Justement, Vim est très gros, mais est-ce que ce n'est pas le principal problème? Visiblement, il faut avoir le cœur bien accroché pour aller voir le code, on dirait les avertissements vers les liens des vidéos de terroristes qui égorgent leurs otages à la machette rouillée. Donc j'avoue ne pas être assez courageux pour aller zyeuter les entrailles de vim, mais vu de l'extérieur, il n'est probablement pas nécessaire d'avoir des centaines de milliers de lignes de code pour un éditeur de texte de cette nature. Si le fork se concentre sur un système de plug-ins, il sera peut-être possible d'avoir une base saine minimaliste autour de laquelle pourront se greffer des extensions qui n'auront pas à être maintenues par le projet cœur. Enfin c'est ce que j'ai cru comprendre, vu de loin.
[^] # Re: La réponse de Bram Moolenaar
Posté par Philippe F (site web personnel) . Évalué à 2.
Oui et non. De fait, le fork va réduire le nombre de lignes de code en s'appuyant sur des lib existantes, en supprimant des fonctionnalités inusitées (la comapbilité old-vi est elle encore une fonctionnalité ?).
Une restructuration de la base de code permettra de séparer mieux les GUI et limitera le mélange des genres.
Après, il ne faut pas se leurrer, Vim reste un gros logiciel. Il y a un langage de script, un moteur de coloration syntaxique, un gestionnaire de terminal, la gestion de macros, de registres, des 5 modes d'éditions différents, de lancer des compilations, des bindings pour différents langages (Python, …).
Tout ça ne va pas disparaitre et va rester coton à maintenir !
[^] # Re: La réponse de Bram Moolenaar
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 26 février 2014 à 11:08.
Les ifdef sont rarement pour les distribs.
Perso, j'ai une chiée de ifdef dont aucun pour les distribs, mais pour des clients qui veulent de la perf/du gain d'espace/ne pas dépendre d'une lib/autre sans pour autant perdre la fonctionnalité qui les interesse.
Supprimer les ifdef est enlever une fonctionnalité (pas qui t'interesse, mais qui itneresse une autre personne). Donc pas terrible.
Ca arrive, et ça arrive même que la FSF accepte l'idée qu'elle a grandement merdé dans son conservatisme (OK, c'est rare! :) )
[^] # Re: La réponse de Bram Moolenaar
Posté par Philippe F (site web personnel) . Évalué à 9.
Les ifdef peuvent avoir une utilité pour un logiciel qui doit en effet se décliner en N versions différentes.
Est-ce le cas de Vim ? Je suis loin d'en être persuadé. Il y a bien un besoin entre un Vim minimaliste pour des plate-formes minimalistes et un Vim bouffi pour ceux qui ne regardent pas à la taille. Mais choisir individuellement entre avoir le support des split verticaux, des jumplist, et autres joyeusetés, est-ce que ça a un sens.
Pour ceux qui veulent voir à quoi ça ressemble, c'est:
https://code.google.com/p/vim/source/browse/src/feature.h
En l'occurence, il supprime la possibilité de supprimer une fonctionnalité en l'incluant automatiquement de base.
J'ai fait le compte vite-fait, il y a 110 feature différentes qui peuvent être activées ou désactivées. Question subsidiaire, qui teste les 2110 = 1298074214633706907132624082305024 combinaisons qui en resultent ? On est clairement dans un truc incohérent.
Dans les faits, certaines de ces fonctionnalités correspondent à des fonctionnalités spécifiques à des plate-formes. Mais au lieu d'avoir une couche de portabilité claire et des fichiers sources isolés, tout est en bazar dans la même base de code, sans permettre de distinguer facilement ce qui appartient à quoi.
Une des clés me semble être l'adhésion d'une partie de l'équipe de développement principale.
[^] # Re: La réponse de Bram Moolenaar
Posté par barmic . Évalué à 3.
C'est vrai qu'utiliser quelque chose comme lua serait cool. Ça casse la compatibilité mais ça permet de ne plus se soucier de maintenir un langage en plus. Je parle de lua parce qu'il est fait pour ça, comme guile.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La réponse de Bram Moolenaar
Posté par Philippe F (site web personnel) . Évalué à 1.
Pour l'avoir tenté, lua ne serait pas mon premier choix, même si c'est celui qui a été fait par neovim.
Ce qui est cool, c'est d'avoir un langage de script prêt à l'emploi, documenté, avec même un jit qui existe. Les gros incovénients de lua, c'est:
[^] # Re: La réponse de Bram Moolenaar
Posté par nud . Évalué à 2.
Quelles sont les autres alternatives ?
Si on plonge un petit peu dans l'histoire, on peut retourner à l'époque où Gnome cherchait un langage de script à mettre en avant pour la version 3, afin d'éviter d'avoir 150 langages comme c'était le cas dans Gnome 2. C'est Javascript qui a été choisi, car l'un des critères principaux était le fait que le langage soit dynamique et ne vienne pas avec sa propre plateforme (comme python, perl, etc). D'autres langages qui correspondent à ces critères sont scheme/lisp et lua, mais en fait ça écarte de facto la plupart des langages "barbus" habituels comme python, ruby ou perl…
Bon, en pratique les applications écrites en python n'ont pas été réécrites pour autant…
[^] # Re: La réponse de Bram Moolenaar
Posté par barmic . Évalué à 2.
On peut regarder un peu plus loin qu'un seul projet aussi, hein ?
Et il doit y en avoir d'autres. Note qu'il semble admit actuellement, qu'il vaut mieux étendre plutôt que permettre des extensions (par exemple). Ça me semblerais intéressant pour un dérivé de vi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La réponse de Bram Moolenaar
Posté par Philippe F (site web personnel) . Évalué à 4.
Honnêtement, ça m'arrache le c** de dire ça mais je pense que javascript est le meilleur langage de script qui réponde à ces contraintes:
Je pense que c'est pour toutes ces raisons que Qt a finalement choisi Javascript bien que ce soit pas un choix évident.
[^] # Re: La réponse de Bram Moolenaar
Posté par barmic . Évalué à 2.
Là tu parle de la syntaxe, parce que le modèle objet de python est plus proches de C++/Java que js.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La réponse de Bram Moolenaar
Posté par Philippe F (site web personnel) . Évalué à 2.
C'est de moins en moins vrai avec les dernières constructions du langage, mais pendant longtemps, quand tu voyais un programme Python et que tu connaissais le C,C++,Java,VB ou C#, tu comprenais ce que faisais le programme.
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . Évalué à 1.
Les alternatives existent, même si ce n'est pas forcément mainstream.
Par exemple (je ne me suis pas amusé avec ce langage donc je ne sais pas ce qu'il vaut), Code::Blocks utilise squirrel.
[^] # Re: La réponse de Bram Moolenaar
Posté par barmic . Évalué à 2.
Je n'ai pas était très choqué par la programmation en lua (mais j'en ai peut être pas fait des masses). Par contre la rupture de compatibilité est à mon avis assez importante et c'est probablement ce qui me fera changer de gestionnaire de fenêtre quand je mettrais à jour mon awesome (disons que c'est la goute d'eau, j'ai envie de passer à xmonad depuis longtemps maintenant).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La réponse de Bram Moolenaar
Posté par David Marec . Évalué à 1.
Tiens, c'est ce qui m'a fait passer à i3. Après une heure d'essais infructueux en lua, j'ai laissé tombé; la documentation n'était pas très à jour et je ne comprenait plus rien.
i3 fonctionne sans rien configurer.
Mais je ré-essaierai, il y a quelques petites choses qui me manquent, comme le chti menu et le basculement dans les styles. Avec I3, ça devient vite un puzzle ou un taquin.
[^] # Re: La réponse de Bram Moolenaar
Posté par barmic . Évalué à 3.
Je ne pense pas que changer la conf' sera vraiment bloquant pour moi (c'est le langage qui a une rupture de compatibilité pas la manière de gérer la conf' en elle même (de ce que j'ai compris)). Mais xmonad me fait de l'œil depuis pas mal de temps, il faut juste que je trouve la motivation pour m'y mettre sérieusement (il est plus rustique qu'awesome).
i3 j'ai jamais vraiment adhéré, je ne retouche presque jamais mes clients, je laisse ça aux layouts et je me contente de changer de layout en fonction de mon besoin. C'est comme ça que j'apprécie d'utiliser ma machine et c'est pas un comportement prévu pour i3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La réponse de Bram Moolenaar
Posté par David Marec . Évalué à 1.
Ce n'était pas tant la configuration, mais le fait d'avoir à la refaire et de ne pas y être arrivé rapidement. Ça vexe puis ça fâche.
C'est ce que voulais dire, les dispositions pré-définies par awesome manquent avec i3.
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . Évalué à 1.
C'est sûr, c'est le genre de fonctionnalités qui me manquent personnellement, même sans les avoir essayées. J'ai pu voir des screen qui m'ont fait comprendre l'idée, rien de plus, mais… c'est séduisant tout de même.
Pour le coup, à part que ces layouts sont faits via lua, comment ça marche, en gros? Je me dis que quelque part, peut-être qu'avec des scripts exploitants les IPC d'i3… enfin, je ne sais pas, mais peut-être qu'il y aurait moyen de faire un truc qui sois moins pénible que refaire complètement le layout à chaque démarrage de la machine. Donc, comment qu'ils font, en face? ( parce que j'aime énormément l'idée du fichier de config simple, malgré tout… )
[^] # Re: La réponse de Bram Moolenaar
Posté par David Marec . Évalué à 1.
Les dispositions ne sont pas faites en Lua, Awesome fournit une collection de dispositions, accessibles en lua pour peaufiner, ou pour définir une disposition par défaut pour chaque espace.
Du coup, on en arrive à toujours charger les logiciels connus dans un espace particulier (cela se fait aussi en lua), qui va tout organiser tout seul.
C'est particulièrement intéressant lorsque l'on utilise majoritairement des outils qui tournent dans un xterm.
les dispositions sont là.
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . Évalué à 1.
En fait, j'ai fini par faire des scripts shell pour placer à peu près. Ca bug à cause du temps, mais ça marchotte. Pour le coup, j'ai posé la question sur la ml d'i3 au sujet de comment résoudre ces bugs, et on m'a répondu que la prochaine version inclue un mécanisme de layout, qui résout donc ce manque de fonctionnalité.
A condition d'utiliser le dépôt git, bien entendu.
A voir, donc.
[^] # Re: La réponse de Bram Moolenaar
Posté par Zylabon . Évalué à 4.
Ça serait cool un rubix cube en dimension N. Pour les vrais hommes.
Please do not feed the trolls
[^] # Re: La réponse de Bram Moolenaar
Posté par zul (site web personnel) . Évalué à 2.
Pas de classes, je suis d'accord. Mais l'émulation ne me semble pas tellement complexe, voir même plutôt relativement simple et claire (et pas de "magie" justement).
La numérotation Lua est étrange. Si on regarder l'historique:
- 5.0 : 2003
- 5.1 : 2006
- 5.2 : 2011
En référence à ces valeurs, je ne suis pas sûr que lua s'en tire plus mal que d'autres. (2003, c'est Python 2.2 par exemple).
[^] # Re: La réponse de Bram Moolenaar
Posté par zebra3 . Évalué à 3.
Je n'en suis pas si sûr. Un script qui fonctionne avec Python 2.2 fonctionnera avec Python 2.7, même si l'inverse n'est pas forcément vrai.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La réponse de Bram Moolenaar
Posté par zul (site web personnel) . Évalué à 6.
J'aimerai bien voir ça quand même :) J'ai jeté un coup d'oeil aux changelog entre 2.2 et 2.7, et il y'a peut être des programmes avec la même sémantique, mais je suis quasiment sûr qu'il y'en a un paquet d'autres qui ne vont pas du tout fonctionner. Par exemple, None et yield sont des noms de variable valide en Python 2.2.
Bien sûr, on ne parle évidemment pas de Python 3.x, on serait méchant :).
[^] # Re: La réponse de Bram Moolenaar
Posté par Philippe F (site web personnel) . Évalué à 3.
Je serai curieux de voir ça. Python 2 est globalement rétrocompatible.
Du côté de mon expérience personelle:
Là, bon évidemment! Mais tu assignes souvent une valeur à None, même en Python 2.2 ? J'aimerai bien voir un programmer marcher avec None = 1, juste pour rire.
Il reste donc les nouveaux mot-clés: yield , with et probablement un ou deux autres.
[^] # Re: La réponse de Bram Moolenaar
Posté par zul (site web personnel) . Évalué à 1.
Je n'ai jamais écrit de code en Python 2.2.
Ça ne me choque pas de définir une constante None à 0, et d'utiliser cette constante symbolique plutôt qu'un entier. C'est exactement ce qu'on fait avec NULL.
raise "foo" est valide jusqu'à 2.6 et renvoie un TypeError depuis 2.6. Je ne vais sérieusement pas énuméré tous les "Porting your code to Python 2.x" de la documentation pour prouver que l'assertion "Un script qui fonctionne avec Python 2.2 fonctionnera avec Python 2.7" est fausse. Un contre-exemple suffit.
Globalement, globalement:) Lua est globalement compatible à quelques exceptions près :).
Je ne dis pas que c'est impossible.
Juste le traitement des u"foo" est chiant, vu que c'est valide en 2.{5, 6, 7}, 3.{3, 4}, mais pas en 3.{0, 1, 2}. Mais on peut toujours se débrouiller.
Le nom des imports change, mais on peut se débrouiller aussi (avec des raise / except).
Il ne faut juste pas dire que c'est "out of the box", je ne fais pas attention, et ça marche parfaitement entre 2.5 et 3.4. Là, personnellement, je n'y crois pas.
[^] # Re: La réponse de Bram Moolenaar
Posté par zebra3 . Évalué à 2.
Ça a été prévu. À partir de la 2.1 tu peux faire ça :
import __future__
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La réponse de Bram Moolenaar
Posté par zul (site web personnel) . Évalué à 1.
Je ne vois pas en quoi ça change le fait que le programme
None = 0
est valide en python 2.2 et est invalide en python 2.7.
[^] # Re: La réponse de Bram Moolenaar
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Le langage ne se résume pas aux constructions syntaxiques, les différents modules de base de Python évoluent fortement d'une version à l'autre, ce qui casse tout programme qu'on veut faire évoluer.
[^] # Re: La réponse de Bram Moolenaar
Posté par Ontologia (site web personnel) . Évalué à 2.
Je pense qu'il faudrait un langage fait pour la gestion de texte, de grammaire.
Code Worker est par exemple un langage pensé pour gérer du texte. Ce pourrait être une piste intéressante pour un langage maison.
Le problème des langages cités est qu'ils ne sont pas orientés gestion du texte. On parle de scripts pour un éditeur texte, ici…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . Évalué à 1.
Considérant que prolog est fait pour les linguistes, j'imagine que ce serait le genre de langages que tu aimerais voir? xD
[^] # Re: La réponse de Bram Moolenaar
Posté par Ontologia (site web personnel) . Évalué à 3.
Aimerais, ce n'est pas la question.
La question est de fournir un éditeur qui ait en natif les outils pour faire un assistant de programmation, un peu comme Eclipse, mais en moins lourd et sans Java.
Le but des script est d'analyser du texte, faire de la coloration syntaxique, analyser grammaticalement le code, aller chercher de la doc, intégrer tous les fichiers d'un projets, gérer un gestionnaire de version, etc..
Il faut donc un langage spécifique au traitement du texte ET généraliste (pour ne pas empêcher un auteur d'inventer une idée farfelue mais utile). CodeWorker est intéressant car c'est un langage qui intègre la possibilité de déclarer des grammaire BNF en natif.
En plus c'est un langage qui n'est pas trop distant de ce que les gens connaissent.
Faire un langage, c'est énormément de travail, je sais de quoi je parle, ce langage étant une bonne base, il pourrait être intéressant d'en partir.
Mais on peut toujours l'intégrer à NeoVim ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . Évalué à 2.
Ha oui en effet! J'admets être parti à la déconnade ( j'ai essayé prolog… je n'ai pas vraiment réussi à faire grand chose avec malheureusement ), mais un langage qui intègre les bnf dans le langage à un potentiel évident.
Comme quoi, parfois c'est utile de déconner :)
# Charité
Posté par bghflt (site web personnel) . Évalué à 10.
Mouais..
Détourner des utilisateurs d'un CharityWare pour un fonds différent c'est très moyen..
Bram sait faire des merveilles en Uganda avec 10.000USD.
[^] # Re: Charité
Posté par G.bleu (site web personnel) . Évalué à 2.
Mais Bram sait-il faire des merveilles sur sa codebase avec 10.000USD ? ;-)
[^] # Re: Charité
Posté par kupka . Évalué à 10.
C'est ce que j'ai pensé aussi.
C'est honteux de forker un logiciel qui incite à donner pour les enfants de l'Ouganda.
À peine réussi-t-on à les protéger du péril des dangereux pervers homosexuels qu'on leur coupe les vivres.
Il est évident que ce coup bas est une émanation du looby sataniste LGBT.
Pour aller au paradis, refusez ce fork.
CAPTCHA: TINC.
[^] # Re: Charité
Posté par fravashyo . Évalué à 10.
Apparemment, il y a une société des ostéopathes qui a contribué pour 42 % de ces dons, ils en avaient marre de voir des gens s'abîmer les doigts avec emacs.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Charité
Posté par Michaël (site web personnel) . Évalué à 5.
Ça aurait été plus simple de leur faire remarquer qu'ils ont deux mains!
[^] # Re: Charité
Posté par liberforce (site web personnel) . Évalué à 10.
Bah c'est surtout demander 10000$ pour 2 mois de boulot en étant localisé au Brésil…
Le développeur de git-annex demandait 15000$ pour un an de boulot en étant basé aux états unis. Bon, l'exemple est extrême, mais 5000$ par mois même s'il faut décompter les charges, pour faire le ménage et mettre en place le système de plugins, ça me parait un peu élevé.
[^] # Re: Charité
Posté par ß ß . Évalué à 10.
Maintenant que le bitcoin est en train de s'effondrer, c'est peut être le prochain moyen de se faire de l'argent facilement.
1/Tu bosses à fond sur un projet que tu aimes bien (ou que tu n'aimes pas, ça n'a pas d'importance) pendant deux semaines non stop.
2/Tu écris un article de blog disant que c'est tous des salauds les bénévoles du projet, ils n'ont acceptés que la moité de tes patches. Bien sûr il ne faut pas de commentaires dans le blog. Les admins du projets risqueraient de venir dire que tes patches sont sales ou qu'ils n'avaient pas de temps, mais que ça sera bientôt intégré.
3/Tu lances une campagne kickstarter en promettant plus de réactivité dans le traitement de bugs, dans l'ajout de features. Que ta version sera deux fois plus réactive et plus sikioure et plus bugproof avec deux fois moins de lignes de codes parce que tu vas tout refactoriser et qu'en plus il y aura de belles icônes.
Tu factures détailles une liste de tâches qui devrait prendre 6 mois et tu le factures au prix d'un an de travail au salaire US + charges etc (alors que tu habites au portugal).
4/Tu fait du buzz à fond sur les sites de dicaïdeur pressés, les sites de hipsters (ceux qui aiment bien être à l'avant garde de tout), sur touiteur, sur faysbouc, dans les commentaires de bugs du projet en question, etc. Tu inondes. Dénigrez, dénigrez, il restera toujours quelque chose.
5/Au bout d'un mois tu refais un buzz alarmiste en disant « OMG on n'y arrivera jamais donnez OMAGAD! »
6/ Profit. Tu as travaillé 2 semaines et tu as 1 an d'argent de poche.
Même si tu ne gagnes que 3 semaines de salaires tu es déjà gagnant.
[^] # Re: Charité
Posté par ckyl . Évalué à 5.
Marche pas ton truc. Le marketing prend plus d'une semaine ;)
Pour le prix, je ne connais pas le marché du brésil ni leur taux de taxes. Mais 10 minutes sur Google semble dire que c'est pas totalement déconnant. Ca fait 11000 BRL/mois avec 34% + ~15% de taxe, on peut arrondir à 50%. Il reste donc 5500/mois ou 66K/an ce qui semble être dans les fourchettes qu'on trouve sur Glassdoor. Je peux avoir totalement tord et ne demande qu'à me faire corriger par quelqu'un qui connait bien le marché local. Mais à vu de pif c'est payé correctement, voir bien, sans être la folie. Et toi tu bosses pour le smic ?
[^] # Re: Charité
Posté par Didrik Pining . Évalué à 10.
tort. De rien.
[^] # Re: Charité
Posté par lasher . Évalué à 2.
66K BR ~ 28KS. Je ne connais pas le salaire moyen d'un (bon) développeur au Brésil, et c'est l'information qui manque pour savoir si c'est complètement disproportionné ou pas.
[^] # Re: Charité
Posté par ckyl . Évalué à 7.
En général une bonne technique pifométrique est de regarder les salaires d'IBM sur Glassdoor pour les raisons suivantes:
Bref là en band 7 ça annonce dans les 71K par an pour Rio ou Sao Paulo. Un poste équivalent aux US ça correspond grosso modo à 70-90K.
Si y'a bien ~34% de taxe avant IR, ce qu'il annonce semble donc pas déconnant pour quelqu'un qui ne connait rien au Brésil…
[^] # Re: Charité
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 26 février 2014 à 00:24.
ou tu demandes $10000 et tu reverses $8000 au développeur d'origine (en ne gardant que $1000 par développeur du fork sur les deux mois, ce serait grand prince).
Je ne sais pas, je n'ai pas suivi l'affaire…
Pour la partie graphique, ils re-développent^Wfactorisent vim en C++ pour prendre en compte Qt ?
[^] # Re: Charité
Posté par zul (site web personnel) . Évalué à 3. Dernière modification le 26 février 2014 à 11:01.
Non. Il propose de définir une interface entre "vim-core" et les plugins / gui, en json-rpc / msgpack-rpc. Evidemment, on peut toujours critiquer le fait qu'il n'est fait que dessiner à gros trait et n'a pas explicité cette interface, ni evalué le surcoût par rapport à un lien plus direct.
Ça coute vraiment si cher de lire les liens avant de commenter ? :D
[^] # Re: Charité
Posté par barmic . Évalué à 6.
Pff, il aurait du choisir dbus ! :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Charité
Posté par Mali (site web personnel) . Évalué à 3. Dernière modification le 26 février 2014 à 13:19.
$10,000 will allow me to dedicate two months of full time work to this project, which will be enough to implement the following:
[^] # Re: Charité
Posté par liberforce (site web personnel) . Évalué à 5.
La seule faille dans l'histoire est que le gars est freelance et a pas franchement besoin de se taper une réputation de voleur ou d'arnaqueur sur le web…
[^] # Re: Charité
Posté par vlamy (site web personnel) . Évalué à 5.
On ne sait pas encore s'il a dépensé l'argent en pute et en coke, laissons lui le bénéfice du doute et regardons ce qu'il fait avec :)
En même temps, je pense qu'il va être bien surveillé le gars :)
# Hmmm...
Posté par LaBienPensanceMaTuer . Évalué à 10.
Personnellement, en 15 ans d'utilisation de vim pour coder, rédiger des mails et autres documents je n'ai jamais rencontré de bug …
Cet argument est donc légèrement HS ;)
[^] # Re: Hmmm...
Posté par Framasky (site web personnel) . Évalué à 10.
J'ai déjà vu Vim ralentir à un point insupportable à cause de la coloration syntaxique sur un fichier yaml de même pas 100 lignes. Ok, y avait des clés publique ssh dedans donc des lignes un peu longues, m'enfin.
Sans coloration, ça passait comme un charme.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Hmmm...
Posté par anaseto . Évalué à 1.
Ce qui est terrible c'est la coloration syntaxique de perl6 (heureusement que je l'utilise que pour m'amuser), mais bon le fichier de coloration fait plus de deux mille lignes donc je me demande si c'est vim, le fichier en question, ou perl6 qui a un problème ;)
Mais peut-être que ça marche mieux depuis la 7.4 vu qu'il y a eu justement des changements par rapport au moteur de regexp et la coloration syntaxique qui sont supposés être plus rapides maintenant, mais j'ai pas encore testé.
Sinon, ce qui est vrai c'est qu'avec les lignes trop longues vim n'est pas rapide (genre ouvrir sans faire exprès un fichier binaire ou des choses comme ça), mais c'est rarement un problème je trouve pour les fichier qu'on a réellement besoin d'éditer.
[^] # Re: Hmmm...
Posté par kupka . Évalué à 4.
Idem pour moi, mais il y a beaucoup de logiciels que j'utilise sans soucis et qui ont un bugtracker long comme le bras.
Par contre pour ce qui est de la réactivité sur les nouvelles fonctionnalités à intégrer, je suis dubitatif.
Quelqu'un qui a une utilisation un peu poussée de vim utilise des plugins. Les plugins n'ont plus besoin d'une mise à jour du code du core pour être mis à jour. Un peu comme Firefox quoi.
Avec de véritables gestionnaires de paquets intégrés à vim (vim-addon-manager/vam) on voit bien la vitesse et la régularité de la mise à jour de certains modules.
[^] # Re: Hmmm...
Posté par fravashyo . Évalué à 10.
Moi non plus. Ça fait 3 ans que je l'utilise non-stop. Je n'ai pas trouvé la commande pour quitter.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Hmmm...
Posté par fravashyo . Évalué à 6.
À noter que cette blague fonctionne bien (voire mieux) avec emacs également.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Hmmm...
Posté par zebra3 . Évalué à 10.
Note que ça marche aussi avec GNOME 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Hmmm...
Posté par barmic . Évalué à 3.
Moi si, avec la coloration syntaxique. J'ai jamais regardé si c'était la faute du fichier de syntaxe ou de vim, mais ça m'arrive de temps en temps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hmmm...
Posté par zebra3 . Évalué à 1.
Pareil, de temps en temps elle part en vrille (avec des gros scripts Python). Mais un coup de ctrl+L et elle se remet d'aplomb.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Hmmm...
Posté par Louis Roché (site web personnel) . Évalué à 0.
Personnellement j'ai d'énorme problèmes avec les interfaces graphiques comme gvim ou macvim. Et même dans les terminaux, j'ai des problèmes de rafraichissement, d'affichage tout cassé, de lenteurs, de clignotements…
Rien de critique, mais on ne peut pas dire que ce soit parfait. Je n'aime pas beaucoup ST, mais c'est vrai qu'avoir une GUI fluide c'est appréciable.
# Un nouveau Gnome ?
Posté par Pylade . Évalué à 7.
Quel sont les objectifs de ce projet ? Passage à CMake, suppression de fonctionnalités et ne même pas régler le problème du chemin des fichiers de configuration (car il existe un standard pour ça).
Ce projet est mort avant même d’être né.
[^] # Re: Un nouveau Gnome ?
Posté par ord . Évalué à 6.
Peut etre que l'avantage de neovim c'est que tu pourra ecrire le patch pour respecter le standard des fichiers de configuration et que le patch soit accepte?
[^] # Re: Un nouveau Gnome ?
Posté par barmic . Évalué à 3.
Note que c'est un standard freedesktop, donc ça n'a pas beaucoup de sens ailleurs que sur linux (mais je suis d'accord avec toi).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un nouveau Gnome ?
Posté par navaati . Évalué à 3.
Hein ? Les standards freedesktop de manière générale ont pas vocation à être spécifiques à linux, que je sache. En particulier celui là.
[^] # Re: Un nouveau Gnome ?
Posté par barmic . Évalué à 2.
Leurs vocations c'est sympa mais les choses comme dbus et autre n'ont pas vocation à sortir de linux. Donc on peut facilement imaginer qu'il en ai de même pour XDG.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un nouveau Gnome ?
Posté par zebra3 . Évalué à 1.
C'est pas toi qui m'avait dit qu'« on peut facilement imaginer que… » c'est pas un argument ? :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Un nouveau Gnome ?
Posté par barmic . Évalué à 4.
Bon je vais le refaire. Une norme ça ne vaut rien. Moi demain je peut créer le Michel consortium et créer des normes pour pleins de truc (par exemple pour définir les tailles standards de gâteau). Ce qui fera la différence en entre une norme ISO et ma super MN001 (pour Michel Norme 001) c'est que tout le monde se fout de la mienne alors que tout le monde écoute ISO.
Donc la question c'est est-ce que freedesktop est écouté par les BSD et autres unix ?
Ou encore est-ce que freedesktop a la légitimité pour parler des BSD et autres unix ?
Au vu de son orientation linux et de l'orientation linux-only de ses contributeurs, je ne crois pas.
Et ce même si XDG est une spec très simple qui n'a besoin de rien pour être déployée sur n'importe quel OS qui supporte HFS donc ce serait dommage de s'en passer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un nouveau Gnome ?
Posté par flagos . Évalué à 4.
Mais de qui parle tu ? ;-)
[^] # Re: Un nouveau Gnome ?
Posté par navaati . Évalué à 3.
Prétendre que fd.o==Lennart, c'est bas pour un jeudi.
[^] # Re: Un nouveau Gnome ?
Posté par freem . Évalué à 5.
XDG-directory ( ou un truc du genre ) n'a pas à être écouté par les dev d'OS, mais les dev d'application.
Tout OS ( shell, en fait ) qui est capable de gérer un système de fichier, un profil utilisateur et des variables d'environnement supporte cette norme, au final.
[^] # Re: Un nouveau Gnome ?
Posté par tyoup . Évalué à 3.
Tiens je savais pas qu'il y avait une norme ISO pour la taille des gâteaux ;-).
[^] # Re: Un nouveau Gnome ?
Posté par Philippe F (site web personnel) . Évalué à 10.
C'est vrai que mesurer les chances de réussites du projet à l'aune de savoir si il va standardiser les fichiers de config façon freedesktop, c'est une bonne approche !
# Evolution
Posté par reynum (site web personnel) . Évalué à 4.
En même temps à part un système simple (pas un plugin) pour commenter et dé-commenter du code comme le ctrl+m sur gedit, je ne vois pas ce qu'on doit ajouter à vim.
Ce logiciel a tellement de fonctionnalités, que je l'utilise très régulièrement depuis au moins 3 ans et j'apprends encore des trucs de fous presque tous les mois :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Evolution
Posté par Zylabon . Évalué à 10.
C'est presque une maladie dans l'informatique ça. De considérer qu'un logiciel fini est un logiciel mort.
Please do not feed the trolls
[^] # Re: Evolution
Posté par reynum (site web personnel) . Évalué à 6.
En même temps j'ai jamais dis ça.
kentoc'h mervel eget bezan saotred
[^] # Re: Evolution
Posté par kursus_hc . Évalué à 9.
En même temps il n'a jamais dit que tu l'avais dit.
[^] # Re: Evolution
Posté par reynum (site web personnel) . Évalué à 0.
Bah plus ou moins, c'est tout de même une réponse à mon post. Donc il est naturel de penser que Zylabon a cru que je voulais dire que, étant donné que vim dispose déjà d'une quantité colossale de fonctionnalité il ne devait plus évoluer, hors je pense que vim doit continuer d'évoluer. De plus comme j'aime les forks (la plus part en tout cas) j'espère que néovim apportera un coup de boost et des idées au vim initial.
kentoc'h mervel eget bezan saotred
[^] # Re: Evolution
Posté par ord . Évalué à 2.
d'un autre cote un organisme qui n'evolue pas a de forte chances de disparaitre rapidement d'apres la theorie darwiniene.
[^] # Re: Evolution
Posté par anaseto . Évalué à 5.
Ton raisonnement sous-entend que vim est vivant, ce qui est plutôt bon signe pour un logiciel.
[^] # Re: Evolution
Posté par Zylabon . Évalué à 1. Dernière modification le 26 février 2014 à 20:01.
Pas forcement. L'évolution sert à s'adapter à son environnement. Si une espèce est adaptée et que son environnement ne change pas, elle n'évolue pas.
L'exemple canonique est celui des Limulidae qui n'ont pratiquement pas évoluée au cours de 500 000 000 dernières années.
Ça vaut aussi pour les logiciels…
Please do not feed the trolls
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 1.
Ben oui c'est un logiciel mort.
Quid des failles de sécurité ? Des bugs ? (montre moi un seul logiciel parfait !) Des nouveaux usages, nouveaux besoins ?
Un cas où tout cela ne change pas, ça n'existe pas. Quand le logiciel ne change pas, c'est qu'il est mort.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par Zylabon . Évalué à 1. Dernière modification le 26 février 2014 à 20:53.
Les bugs (failles de sécurités incluses) sont en nombre fini dans un logiciel quelconque, en les corrigeant un par un sans en introduire de nouveau, au bout d'un moment, il n'y en a plus.
Des exemples, les logiciels triviaux : cat, rm, echo, cp, true, false…
Dans les logiciels non triviaux : un bibliothèque pour manipuler des objets X. Si elle est correcte, portable, et si ses performances sont satisfaisantes, pourquoi y toucher ?
Sinon, des logiciels répondant à un usage précis qui ne change pas, par exemple éditer du texte, les usages n'ont pas changé depuis les les années 60, et les besoins, il a fallut ajouter le support de l'utf-8 et autres trucs du genre, et avoir un beau système de plugin pour la prises en charge de nouveaux langages et voilà.
Please do not feed the trolls
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 3. Dernière modification le 26 février 2014 à 22:19.
Ben non, les "bugs" ça inclut les nouvelles fonctionnalités, les changements quand le compilateur change et que ça impacte ton système de build, ou que tu veux en profiter (par exemple même le support pour C90 n'est pas universel…)
Et corriger un bug sans en introduire de nouveau, c'est pas si simple que ça…
Qui évoluent toujours.
Parce qu'on l'utilise et qu'on découvre des bugs ? Qu'on se rend compte que l'API est mauvaise ?
Qu'on veut cibler une nouvelle plateforme ?
Les autres logiciels changent, les besoins changent, les compilateurs changent, les langages changent (exemple : passage de Python2 à Python3)…. Tôt ou tard, ton logiciel sera condamné à évoluer.
Ça dépend, si tu édites du code, on a néovim qui sort aujourd'hui encore…
Tu oublies la coloration syntaxique, la documentation incorporée, le refactoring, les suggestions intelligentes, … (pour le code)
Voire le correcteur ortographique/grammaticale (pour les trucs du genre LibreOffice Writer), l'insertion d'images/tableaux au sein du texte, le support pour l'impression, etc…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par Zylabon . Évalué à 1. Dernière modification le 26 février 2014 à 23:08.
Pour répondre à la majeure partie de ton commentaire : la conclusion de ta démonstration c'est qu'un logiciel n'est jamais fini, tu ne peux pas l'utiliser comme hypothèse.
J'oublie rien. J'ajoute même que ce genre de truc ne DOIT PAS faire partie du cœur du logiciel, pour pas se retrouver dans 20 ans 150 000 lignes de code mort servant à gérer des langages obsolètes.
ajout : dans coreutils je doute que ce soient les logiciels triviaux qui subissent les mises à jour.
Please do not feed the trolls
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 1. Dernière modification le 27 février 2014 à 07:21.
Ben si : rm, cp, et ls, au moins.
Que cela fasse partie du coeur ou non ne change pas le fait que le logiciel évolue bel et bien constamment quand il est maintenu.
Tu n'y réponds pas du tout. Je t'ai donné des exemples de logiciels triviaux qui évoluent encore, et tu en es encore à dénier la réalité, sans le moindre exemple du contraire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par Moonz . Évalué à 1.
C’est vrai pour les bloatware.
Pour les logiciels qui se comptent en centaine de lignes de code, c’est beaucoup moins vrai.
[^] # Re: Evolution
Posté par claudex . Évalué à 7.
Vu qu'on parle de vim ici qui approche le million de ligne de code on est plus proche de ta définition de bloatware.
« 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: Evolution
Posté par xcomcmdr . Évalué à 3.
Ben non. Même les logiciels triviaux évoluent toujours.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par Sufflope (site web personnel) . Évalué à 1.
Et y a quoi comme vrai programme qui fait des choses utiles à part hello world, yes et rm qui font quelques centaines de ligne ?
[^] # Re: Evolution
Posté par Moonz . Évalué à 3.
Tu en as des tonnes sur github. La seule difficulté est de les trouver (les trucs de quelques centaines de lignes de code font rarement de la pub en première page sur /.) En auto-pub :
[^] # Re: Evolution
Posté par freem . Évalué à 2.
Utile étant très subjectif…
J'avais à une époque ou je jouais beaucoup aux cartes Magic the gathering, créé un programme qui me permettait de calculer le nombre de terrains de chaque couleur que je devais mettre dans mon jeu pour optimiser mes chances de ne pas être handicapé par le fait de jouer plusieurs couleurs*.
Ca n'atteignait sûrement pas les 1000 lignes, considérant que la plupart du taf était faite via l'IHM, donc via une lib.
Je doute aussi que calc.exe ( proprio, certes, mais très utile ) fasse plus de quelques centaines de lignes, et pourtant, j'utilise souvent une calculette, peu importe mon OS. Celle de windows est mieux foutue que galculator sur certains aspects en plus.
J'ai aussi un script shell pour extraire les fichiers d'une archive jamendo dans une arborescence "artiste/album/*.???".
Ainsi qu'un outil pour générer une classe C++ en ligne de commande en fonction d'un nom que je lui passe, qui hérite automatiquement d'une liste de classes que je lui passe en paramètres ( fonctionnalité prévue: l'ajout automatique des prototypes des fonctions virtuelles des classes mères, avec le mot-clé override fournit gratos, entres autres ).
Je dois en citer d'autres, de petits utilitaires en dessous des 1000 lignes de code, ou tu as compris l'idée?
En fait, le mot est placé: utilitaire.
*: Ce qui me rappelle que le code source n'est pas "libre" ( surtout, pas diffusé ) mais j'avoue ne pas trop avoir imaginé qu'il puisse servir à quelqu'un… je dois encore l'avoir qui traîne sur un disque, je verrai p'tet pour le publier ce WE ^
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 2. Dernière modification le 28 février 2014 à 21:03.
Et depuis Windows 7 elle est passée à WPF pour l'aspect présentation, et s'est enrichie de modes de fonctionnement additionnels. Comme quoi, même les outils "triviaux" changent.
En fait, même notepad a changé.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par Moonz . Évalué à 0. Dernière modification le 28 février 2014 à 21:06.
Passer à WPF c’est pas faire évoluer une application mais la réécrire.
Par contre GNU bc n’a pas eu de release depuis 2000, c’est qu’il doit être mort et inutilisable, n’ayant plus sa place que dans les musée de l’informatique, n’est-ce pas ?
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 3.
Mais LOL. Elle doit être bien mal fichue ton application si changer la couche de présentation t'oblige à la réécrire de zéro.
C'est dommage, bc aurait pu rajouter des modes de calcul, par exemple.
Ce n'est pas parce que un logiciel n'évolue plus qu'il est feature-complete, hein. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par Moonz . Évalué à -1. Dernière modification le 28 février 2014 à 23:47.
Le truc, c’est que « feature-complete » est un choix que tout le monde ne fait pas et qui n’implique pas automagiquement que le logiciel est mort dans le sens « troué de bug et de failles de sécurité, incompilable sur les systèmes modernes… »
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 2.
C'est bien, je n'ai jamais dit ça. Mais pour le comprendre, faut sortir du cliché "logiciel qui n'évolue pas = logiciel parfait." ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par Moonz . Évalué à 3. Dernière modification le 01 mars 2014 à 12:15.
https://linuxfr.org/users/carif/journaux/neovim-vim-s-rebirth-for-the-21st-century#comment-1522793
Tu as logiciel parfait => logiciel qui n’évolue pas
Personne n’a dit logiciel qui n’évolue pas => logiciel parfait.
Par contre ce qu’on dit c’est que c’est stupide de dire « meh, ce logiciel a pas évolué depuis 3 ans, c’est qu’il doit être mort et enterré ». Ça peut être aussi parce qu’il répond au besoin (et tout le monde n’a pas comme besoin « faire le café et promener le chien ») sans bug/faille connus, bref, qu’il est « parfait » (même si le terme est un peu prétentieux, je préfère le terme « fini » ;))
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 2.
Sauf que j'ai démontré que même les logiciels soi-disant "triviaux" (rm, ls, …) évoluaient toujours.
J'ose à peine encore demander un exemple d'un logiciel "fini superbement".
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Evolution
Posté par Moonz . Évalué à 0.
Tu en as un plus haut : GNU bc, dernière release 2000
[^] # Re: Evolution
Posté par xcomcmdr . Évalué à 5.
Ben non, vu qu'il y a des tests releases
Et la dernière date de 2006.
Et pourquoi il y a des tests releases ?
Parce que ça bug ! ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Evolution
Posté par _jordan_ . Évalué à 2.
La fonctionnalité ctrl+d de sublime texte serait aussi un plus agréable.
Autre chose : Pourquoi le mode mouse=a ne permet pas la copie sur sélection de gnome dans gnome-terminal ?
Si c'était possible, j'aimerai bien ça également.
Après, je pense qu'il y aurait un bon travail à faire pour rendre le truc plus accessible en créant une meilleur doc en ligne mais c'est pas lié au logiciel directement.
Enfin, s'il y avait un vrai logiciel graphique parfaitement adapté pour vim, je courrais l'acheter tout de suite (même gratuit).
[^] # Re: Evolution
Posté par JGO . Évalué à 8. Dernière modification le 25 février 2014 à 21:14.
As-tu essayé le mode vi disponible dans tous les logiciels KDE (via KatePart) ? Ce n'est pas un remplacement complet pour vim mais si tu es habitué aux commandes, ça te permet d'utiliser facilement ces logiciels (que ce soit pour développer avec kate/kdevelop, écrire un document latex avec kile ou tes mails avec kmail, etc.). Voir http://kate-editor.org/kate-vi-mode/
[^] # Re: Evolution
Posté par mornik . Évalué à 2. Dernière modification le 26 février 2014 à 11:24.
Oui mais sans tes plugins, ta conf et pleins de plein de choses. C'est juste un mode frustrant.
C'est dommage que vim n'est pas une interface graphique sous qt pour ceux qui veulent un environnement à la souris complet sous KDE/QT.
En même temps, moi ça me gène pas, il suffit de lancer vim dans konsole et c'est intégré ^
[^] # Re: Evolution
Posté par Philippe F (site web personnel) . Évalué à 5.
Je l'ai fait, ca s'appelait KVim et ça ne marche pas. Justement à cause de la structure monolithique de Vim. Neovim entend casser cette structure monolithique et permettra si il remplit ses objectifs de faire un KVim fonctionnel et facile à maintenir.
[^] # Re: Evolution
Posté par navaati . Évalué à 2. Dernière modification le 26 février 2014 à 14:24.
Et comment fait GVim alors ?
[^] # Re: Evolution
Posté par Philippe F (site web personnel) . Évalué à 3.
Il fait des bidouilles qui marchent pas trop mal. Sauf que ce type de bidouille a ses limites. Pour un portage vers KDE en mode composant KPart, on a dépassé ces limites.
[^] # Re: Evolution
Posté par JGO . Évalué à 4.
Si tu as besoin de plugins vim, des fonctions avancées et de la conf de vim… ben tu utilises vim, point final. Mais si tu as besoin des plugins kdevelop, des fonctions avancées kdevelop et de la conf de kdevelop, mais que par ailleurs tu apprécies le style d'interaction homme-machine à la vi, alors tu coches juste la case dans la conf de Kate et c'est réglé. Il y a des raisons légitimes pour préférer un style d'interaction ; ne serait-ce que GTK et Qt n'ont pas la même interaction dans les zones de texte (par exemple si on fait Ctrl-Suppr. sur un mot entre deux autres, dans GTK ça laisse le curseur entre deux espaces, alors que dans Qt ça laisse le curseur juste avant le mot suivant. Ou bien si on fait Ctrl-→ pour se déplacer d'un mot à la fin d'une phrase, Qt place le curseur avant le point, GTK après le point).
[^] # Re: Evolution
Posté par Letho . Évalué à 3.
Sous OSX (je sais…), MacVim est vraiment excellent.
https://code.google.com/p/macvim/
[^] # Re: Evolution
Posté par flan (site web personnel) . Évalué à 1.
C'est à mes yeux la meilleure interface pour VIM, et de (très) loin, surtout quand on la compare à VIM dans un terminal ou à GVIM/Linux ou GVIM/Windows.
[^] # Re: Evolution
Posté par Tonton Th (Mastodon) . Évalué à 2.
Parce que c'est trop compliqué pour madame Michu.
[^] # Re: Evolution
Posté par bobo38 . Évalué à 2. Dernière modification le 26 février 2014 à 08:54.
gvim est peut-être ce que tu cherches : vim avec une fenêtre, un menu, les raccourcis dans le menu, tout ça…
Pour Windows, il existe une version portable mise à disposition par le projet Framakey :
http://framakey.org/Portables/VimPortable
[^] # Re: Evolution
Posté par lasher . Évalué à 2.
J'ai renoncé à utiliser gViM sous Windows à cause d'une gestion extrêmement bizarre de la sélection à la souris (et du copier-coller), et du fait qu'involontairement je pouvais effacer du texte sélectionné là où sous Linux/UNIX ça ne m'arrivait jamais. Du coup lorsque je dois bosser sous Windows, j'utilise Notepad++.
[^] # Re: Evolution
Posté par paco81 . Évalué à 1.
Il faut appuyer sur shift lors de la sélection (ou pendant le clic du milieu pour coller), sinon la sélection est interprétée comme le "visual mode" de vim.
Voir http://stackoverflow.com/questions/4608161/copy-text-out-of-vim-with-set-mouse-a-enabled/4608387#4608387
D'ailleurs le même "problème" se pose avec notamment midnight commander (mc) qui utilise également la souris, et ce n'est pas non plus spécifique à gnome-termnial.
[^] # Re: Evolution
Posté par reynum (site web personnel) . Évalué à 1.
Gvim ne te conviens pas ? il est pourtant pas mal.
kentoc'h mervel eget bezan saotred
[^] # Re: Evolution
Posté par freem . Évalué à 1.
Je suppose qu'un système permettant d'éditer un fichier à plusieurs serait utilisable. Problème, je doute que ce fork finisse par en être capable, il faudrait faire plus que découpler des modules et refactorer du code pour ça.
Pour ma part, probablement à cause du fait que je n'utilise vim que de façon basique, je trouve que la config est trop complexe à gérer ( j'avais regardé pour changer des bindings… les lignes de config m'ont fait penser "omg, usine à gaz spotted!" ). Mais la encore, je doute que ce fork fasse évoluer ça ( puisqu'il reste, naturellement, compatible avec l'original ).
J'ajouterai enfin l'édition verticale, plutôt qu'horizontale. C'est peut-être possible, je n'ai jamais cherché. Après avoir tapé le "case :" dupliqué 20 fois d'un switch, que le curseur évolue à la verticale plutôt qu'à l'horizontale s/est/serait/ utile. Enfin, ici aussi, je m'en fiche, j'ai commencé à prendre l'habitude d'utiliser des tableaux associatifs dans mon code, au lieu de switch à rallonge. En plus ça me permets de faire du switch sur string en C++ ( avec des lambda ou pointeurs de fonction en valeur, c'est assez sympa et me blesse moins à maintenir que les 20k lignes d'un switch classique. Mais j'imagine que niveau perf c'est un peu moins terrible… ).
Autrement dit, le fait de considérer vim comme fini dépend des gens :)
[^] # Re: Evolution
Posté par barmic . Évalué à 3.
Tu as regardé du coté des sélections carrées ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Evolution
Posté par freem . Évalué à 1.
Pas vraiment, mais ce n'est pas la même chose de sélectionner ( qui me sert surtout à copier/couper, je ne vois pas vraiment d'autres usages… ) ou de faire de l'édition en colonne. Ou alors j'ai mal compris ce que tu veux dire ( ce qui ne me surprendrais pas de ma part ).
Maintenant que j'y pense, on pourrait également mentionner les curseurs multiples, qui sont aussi un outil très sympa quand ça ne bug pas ( c'est implémenté par scintilla, mais le fait de faire un retour à la ligne fait perdre le multi-curseur, et certaines autres actions ne fonctionnent pas ou sont bugguées. Enfin, c'était le cas quand j'utilisais encore autre chose que vim. ).
Je doute que vim supporte ça. Mais je suis aussi persuadé que ce fork ne le supportera pas de sitôt, en admettant que la sauce prenne.
[^] # Re: Evolution
Posté par Philippe F (site web personnel) . Évalué à 3.
Vraiment, tu devrais regarder de SublimeText. Il a un très gros inconvénient: il est closed source. En dehors de ça, il fait tout ce que tu décris et plus: curseur multiples, édition verticale (si j'ai bien compris), mapping Vim, extensibilité en Python, portable sur le trio Lin/Win/OsX
[^] # Re: Evolution
Posté par freem . Évalué à 1. Dernière modification le 26 février 2014 à 23:52.
J'ai un collègue qui utilise cet outil, ça à effectivement l'air intéressant ( ceci dit, je ne savais pas qu'il tourne sous nux, le collègue en question restant sous win ).
Maintenant, je dois t'avouer que ma tendance personnelle va de plus en plus à l'écriture de fichiers d'une très petite taille ( C++, donc 1 fichier par classe, et quand ça dépasse les 200 lignes, je divise pour envoyer le code dans le cpp. ), des classes ultra-spécialisées et sans me gêner pour utiliser des templates.
Du coup, je ne suis pas sûr d'avoir encore besoin d'un éditeur de code très évolué: une fois que j'ai la coloration syntaxique, une auto-complétion potable et un système modal ( sur ce point, vim à changé ma vie, c'est une évidence ) je suis heureux, et donc mon usage basic de vim me conviens plutôt pas mal.
Le tout combiné avec, en fait, un simple terminal pour naviguer dans les fichiers, est plus efficace que tout ce que j'ai pu voir avec des IDE classiques.
Dommage d'ailleurs qu'il n'y ait pas un éditeur de code simple ayant ces 3 fonctionnalités avec une toute petite base de code, nul doute que je l'adopterai :)
Le but de mon message était surtout d'argumenter sur le fait "oui, vim peut encore évoluer". Ces fonctionnalités, je m'en servirais de temps en temps, genre, 1 fois par mois. Rien d'important donc.
Et puis, sans être un maniaque de l'open source ( j'utilise opera après tout ) je suis plutôt réticent à l'idée d'utiliser du code fermé.
LA fonctionnalité qui pourrait me faire utiliser un nouveau logiciel fermé, ce serait d'être capable de générer des diagrammes à partir du code, et vice versa. Mais ce n'est pas le job d'un éditeur de code, ça.
[^] # Re: Evolution
Posté par barmic . Évalué à 2.
Oui je parle de faire une sélection carrée pour ensuite faire une édition par colonne. Je vois pas vraiment ce qu'il peut y avoir de plus pratique. En fait oui j'ai déjà vu des gens taper une fois un mot, puis le dupliquer n fois sur la même ligne et enfin les mettre tous à la ligne, mais je ne sais pas comment ils ont fait (sous vim). D'ailleurs pour ton cas il doit être possible de passer directement en je les mets tous à la ligne.
Je présume que ça utilise des macros avec une bonne macro, on doit pouvoir faire des trucs de brutes, mais faut passer du temps pour bien maitriser je pense.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Evolution
Posté par reynum (site web personnel) . Évalué à 2.
Sur vim tu vas sur la ligne qui t'intéresses et tu fait yyp, ça a pour effet de dupliquer la ligne. Donc si tu veux dupliquer une ligne 5 ou 10 fois tu tapes 5 ou 10 fois p, mais si tu veux dupliquer 200 fois cette ligne tu fais naturellement yy200p et tu te retrouve avec 201 fois la même ligne (oui la première est toujours là :-D).
Sinon pour les sélections carrées il faut entrer en mode visual bloc à l'aide de ctrl+v.
effectivement sous vim c'est les "map" ça s'utilise en faisant : map [touche_a_mapper] [combinaison_de_touches]
Un exemple qui ajoute un # en début de ligne à l'aide de la touche F2 : map ^i#<DOWN><ESC>
un exmple qui supprime le premier caractère d'une ligne à l'aide de la touche F3 : map ^x<DOWN>
On peut évidemment les combiner avec les buffers, ainsi si on a :
dans le buffer z le mappage : map "z200p vous dupliquera 200 fois ce squelette basique de fonction à chaque pression sur F3 \o/
(j'adore les "map" on peut effectivement faire des trucs de fous).
Il est aussi possible des les mettre dans le vimrc pour en bénéficier tout le temps, il est bon de noter qu'il vaut mieux éviter de "mapper" des touches ayant déjà une fonction comme a ou i par exemple, ça fonctionne mais au final on risque se retrouver perturbé (les utilisateurs de vim comprendrons pourquoi :-D).
Un dernier truc si quelqu'un peut m'expliquer comment mapper des touches en fonction du type de fichier que l'on édite, par exemple si j'édite un .tex la touche F2 m'insérera
Et si j'édite un fichier c cette même touche F2 m'insérera
je trouverais ça génial.
kentoc'h mervel eget bezan saotred
[^] # Re: Evolution
Posté par fusible . Évalué à 2.
Je dirais de placer les affectations dans le dossier ftplugin:
.vim/ftplugin/tex.vimet.vim/ftplugin/c.vimEnsuite en utilisant les les paramètres
<buffer>et<LocalLeader>de la commande map. (voir :h map-arguments)[^] # Re: Evolution
Posté par reynum (site web personnel) . Évalué à 0.
j'essayerais et ferais un retour
kentoc'h mervel eget bezan saotred
[^] # Re: Evolution
Posté par flan (site web personnel) . Évalué à 2.
Et c'est dans ces moments-là qu'on voit les limites de VIM.
Dans mon IDE favori, quand je change un raccourci clavier, il m'indique immédiatement la présence de conflits, dès que j'entre le nouveau raccourci clavier.
Au final, j'ai beau avoir passé de longues heures à configurer un VIM pour faire du Python, il n'arrive toujours pas à la cheville de mon IDE brut de fonderie. Oui, on peut peut-être tout faire avec VIM, mais à quel prix…
[^] # Re: Evolution
Posté par freem . Évalué à 2.
La configuration de vim est clairement l'un des plus gros points noirs de cet outil.
[^] # Re: Evolution
Posté par barmic . Évalué à 2.
Je pensais aux macro non mappées (comme décris là).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Evolution
Posté par freem . Évalué à 1.
Bof, si c'est juste créer des lignes avec le même contenu, c'est facile:
:5oblablabla[esc]
écrira:
blablabla
blablabla
blablabla
blablabla
blablabla
Sauf que ça crée des lignes, donc pas toujours idéal. Par exemple, imagines un code qui utilise "use namespace std;", et la convention de codage du projet dit que les "use namespace" sont interdits. Comment ajouter facilement le "std::" à chaque endroit du code ou il est nécessaire?
Bon, c'est assez limite comme cas, j'avoue, mais pour les autres auxquels je pense, on peut utiliser une combo entre la méthode que j'ai mise pour créer N lignes identiques et/ou le remplacement via des regex :)
[^] # Re: Evolution
Posté par Philippe F (site web personnel) . Évalué à 3.
C'est un besoin extrêmement courant.
Sous Vim, j'aurai tendance à faire une macro vite fait: je me mets au début du premier blabla, je tape qq, je fais ma modif et ma place sur le 2e blabla, et je tape q, puis @q pour répéter sur les lignes suivantes.
Sous SublimeText, je pose le curseur sur le premier bla, je duplique le curseur sur les 6 lignes avec Ctrl+Alt+Down. Ensuite, j'édite mes 6 lignes simultanément, en profitant d'un feedback visuel immédiat.
[^] # Re: Evolution
Posté par misaflo (site web personnel) . Évalué à 3.
Tu peux le faire je pense aussi facilement avec vim.
Tu te mets au début de premier blabla, tu passes en mode VISUEL BLOC (ctrl + v), tu descends jusqu'au niveau du 6ème blabla, tu passes en mode insertion (avec shift + i), tu édites directement ta ligne, puis échappe, et toutes tes lignes sont édités.
La différence, c'est que le rendu ne s'effectue qu'à la fin sur les autres lignes.
[^] # Re: Evolution
Posté par freem . Évalué à 1.
Ça, c'est génial! Merci beaucoup!!!
Oui, je sais, commentaire inutile, mais je tenais à te remercier.
[^] # Re: Evolution
Posté par anaseto . Évalué à 3.
https://github.com/FredKSchott/CoVim
(je n'ai pas testé)
# Profitons-en
Posté par Framasky (site web personnel) . Évalué à 9.
Profitons d'un nourjal sur Vim pour parler de ce superbe site qu'est http://vimcasts.org/ !
Si vous voulez profiter au mieux de Vim, apprendre des nouveaux trucs et découvrir des plugins, c'est le site rêvé !
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Profitons-en
Posté par Le Gab . Évalué à 4.
Et de yoursachet pour configurer vIM sans peine.
# Plugin par défaut
Posté par robin . Évalué à 5.
J'utilise personnellement vim avec grand plaisir, mais j'ai failli abandonner récemment son utilisation, car des fonctionnalités très pratique sont absentes de vim. Je pense par exemple à un gestionnaire de fichier, une gestion des ctags, des snippets, une insertion automatique des parenthèses () [] {} <>, l'affichage du prototype des fonctions, … Mais heureusement, j'ai découvert les plugins. Une fois bien configuré, vim est le meilleur logiciel que je connaisse, mais cela prend énormément de temps. Je ne comprends pas pourquoi il n'y a pas un ensemble de plugins (dont vundle ou pathogen) d'installé par défaut avec vim. Cela permettrait d'avoir un véritable éditeur de texte moderne, pouvant servir d'ide, et très hautement personnalisable. Les plugins installé par défauts devant évidement pouvoir être désinstallé de manière classique. Cela permettrait d'avoir un vim plus intelligent à l'installation, mais possédant toutes les qualités de vim, et compatible avec toutes les configurations exotiques des anciens utilisateurs (il leur suffirait de restaurer le .vim et le .vimrc).
De la même façon, je n'ai pas commencé par LFS (linux from scratch), mais par ubuntu, et je suis désormais sous archlinux.
bépo powered
[^] # Re: Plugin par défaut
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Tant que tu y es, propose d'installer Cream par défaut :-D
[^] # Re: Plugin par défaut
Posté par freem . Évalué à 2.
Je suppose qu'il est possible de créer un paquet dépendant de vim et des plug-in que tu souhaites, et les activant automatiquement.
C'est d'ailleurs exactement ce qu'eclipse fait, car sans plug-in cette usine à gaz ne fait juste rien.
Il faut juste trouvé un motivé qui ne craigne pas de récolter l'opprobe générale ( et ça part vite chez les barbus ;) ) en déterminant de façon totalement subjective et personnelle quels plug-ins liés à quelle configuration peuvent rendre vim aussi puissants qu'eclipse.
Sincèrement, si tu oses le faire je te soutien sans condition.
[^] # Re: Plugin par défaut
Posté par robin . Évalué à 2.
Il y a déjà des « distribution vim » comme sp13 et janus, mais elles ne sont pas officielle, et c'est la tout le problème. Si on fait le parallèle avec le c++, il existe des dizaines de librairies pour faire à peu près tout, mais un comité de normalisation se réunit régulièrement pour avoir une librairie commune pour les besoins de base. Libre ensuite à l'utilisateur de la garder (je pense aux Qstring dans Qt par exemple). Je trouve que c'est vraiment quelque-chose qui manque dans la communauté vim.
De plus, l'avantage d'un comité de normalisation est qu'il permettrait de tester des configurations un peu étrange. Pour mon cas, j'utilise un clavier en bépo, et la distribution sp13 (que je trouve très bien par ailleurs) nécessite quelques modifications dû à des effets de bords lors de certain remap. Une solution standard n'aurait pas ce type de problème.
En imaginant que j'ai les compétences pour le faire (je ne connais pas assez vim – j'ai par exemple récemment découvert les autocommandes, et je me doute qu'il y a encore des trucs dont je n'ai pas la moindre idée de leur existence), je n'aurais pas l'influence nécessaire pour que vim soit distribué avec par défaut une liste de plugin que j'aurais choisis dans toutes les distributions linux, windows et mac. Comme je le disais, le problème n'est pas le manque de fonctionnalités de vim, mais le fait que ces fonctionnalités ne sont pas présente à l'installation.
bépo powered
[^] # Re: Plugin par défaut
Posté par freem . Évalué à 0. Dernière modification le 02 mars 2014 à 21:53.
Pas moi qui l'ai dit, que vim manque de fonctionnalités :)
Enfin, si, mais je suis clairement persuadé qu'on peut le transformer en IDE complet… ce qui ne gommera pas ses défauts. Et pour les distrib de vim que tu cites, je ne les connaissais pas ( je n'y connais pas grand chose , il faut dire ), et je testerai. Sauf que… je doute qu'il y ait une intro simple à comprendre, ou qu'ils aient gommé les défauts de vim, dont la config complexe fait clairement partie. Selon moi, du moins.
Et quand on voit le temps que mets le comité C++ à se décider pour une nouvelle norme ( 8 ans pour C++11, si on considère la bugfix 03 comme une norme a part entière… que personne de mémoire n'a entièrement implémentée d'ailleurs ) je doute que ce soit une solution.
Qui plus est, comment trouver un système pour que ce que l'on utilise pas du standard ne coûte rien, comme en C++? ( ce qui n'est pas inclut ni demandé explicitement n'est pas utilisé en C++, donc pas payé. Exceptions, RTTI, ce genre de choses. On peut aussi les désactiver explicitement, mais en théorie ce n'est pas utile. J'ai bien dit théorie, hein? )
[^] # Re: Plugin par défaut
Posté par barmic . Évalué à 3.
Tu parle de ceux qui prévoient de sortir en C++14 et un C++17 ? ;)
http://en.wikipedia.org/wiki/C%2B%2B#Standardization
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plugin par défaut
Posté par freem . Évalué à 1.
Oui. En même temps, ils avaient prévu de sortir C++11 avant 2010, d'où le nom du draft: C++0x.
Ceux qui inventent des excuses diront qu'on parle d'hexadécimal, mais j'ose espérer que personne n'est dupe.
Entre prévoir et faire, il y a une grande différence.
Après, je suis d'accord: on parle de standard ISO, donc il faut faire les choses bien, ce qui peut prendre du temps. Mais bon, 13 ans ( standardisation en 98 selon wikipedia, bugfix en 03 ) pour une nouvelle version, en info, c'est long.
Mais bon, ça n'empêche pas ce langage d'être mon favori, vu qu'avec les fonctionnalités de base on peut faire déjà énormément, et au moins on a peu de choses qui deviennent obsolètes ( mais ça existe malgré tout, comme auto_ptr ).
[^] # Re: Plugin par défaut
Posté par barmic . Évalué à 2.
C'était un exemple, le JCP (ceux qui font Java) accélèrent et java 8 arriveras cette année (et oui il arrivera cette année vu qu'Oracle annonce clairement qu'ils le sortent même s'il y a des bugs), python aussi a le même processus et est assez court. Le W3C a passé HTML5 en rolling release, etc…
Les commités commencent à comprendre que s'ils veulent garder leur boulot, il faut qu'ils se bougent et accélèrent grandement leur processus quitte à avoir des normes avec moins de nouveautés (le problème de C++0x a était entre autre les concepts qui étaient de trop malheureusement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plugin par défaut
Posté par freem . Évalué à 1.
Moui, enfin, C++ est quand même le plus lent à évoluer. Pour faire court, selon wikipedia, en 18 ans, Java à fait l'objet de 8 versions ( qui ne soient pas des bugfix ), python en à une tous les 2 ans, quand C++ en est à sa 2nde version standard, 3 si on compte la bugfix de 03.
Avec le w3c, il ne s'agit pas de standard, mais de recommandations, si ma mémoire est bonne. Recommandations qui ne sont respectées complètement par presque aucun site de ma connaissance. En pourcentage, ça doit donner de l'ordre du 5%, peut-être même moins! ( je pense être très optimiste avec mon 5%… )
Et il ne s'agit pas d'un langage de programmation, mais de description. Quand vim se configure, lui, avec un langage de programmation.
D'un autre côté, je peux comprendre, et accepter, que C++ soit plus long à standardiser.
Je ne voudrais pas que la quantité passe avant la qualité, franchement, donc qu'il ne fasse pas comme Oracle et son Java ou python ou les révisions mineures semblent empêcher d'interpréter des codes faits avec la rev mineure précédente ( lu je ne sais plus où sur ce dlfp ). Ca me va très bien comme ça.
Mais des MaJ plus petites, tout aussi propres et plus fréquentes, ça me ferait bien plaisir tout de même. Il n'empêche, le fait qu'ils en annoncent 1 pour cette année, n'implique pas que les délais seront tenus. Les procédures pour un standard ISO sont certainement nettement plus complexes que d'attendre l'approbation d'Oracle ou attendre qu'une équipe de dev open source accepte une contribution, cas de python. On parle d'un organisme de standardisation international reconnu par de nombreux pays, après tout.
Maintenant, en C++11, on peut toujours compiler du code qui date de 98, je ne suis pas sûr que ce soit le cas de la majorité des autres langages.
A part le langage de config de vim, j'imagine :)
[^] # Re: Plugin par défaut
Posté par lasher . Évalué à 3.
La différence c'est que C++ c'est une norme, et pas seulement un standard. Donc il faut que tous les membres du comité de normalisation soient d'accord, et donc on se retrouve avec des gens de Microsoft par exemple qui ont certains usages courants et des extensions qu'ils voudraient voir normalisés; idem pour les autres participants. Python, Perl, Ruby, Java, etc., même s'ils demandent leur avis aux utilisateurs, restent principalement une implémentation « unique ». Oui je sais, il existe plusieurs implém de Ruby, Python, Java, etc. La différence (selon moi), c'est que globalement il y a une version qui continue d'évoluer en permanence, là où en C ou C++, on se retrouve avec 12000 compilateurs (Sun CC, Intel CC, Gnu CC, Clang+LLVM, etc.). Bien qu'il existe des trucs du genre « Iron{Python,Ruby} » ou même des implémentations alternatives de Java, c'est ultra minoritaire en pratique.
[^] # Re: Plugin par défaut
Posté par barmic . Évalué à 1.
Je pense que python a plus d'implémentation que C++ n'a de parseur… :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plugin par défaut
Posté par lasher . Évalué à 1.
Quels sont les ports de Python qui sont des implémentations qui continuent d'évoluer ? C'est une vraie question. J'ai en tête les distributions suivantes:
J'ai entendu parler d'autres implémentations, mais qui semblent évoluer peu ou pas du tout :
Je me plante complètement ?
De l'autre côté, niveau front-ends pour C++, je dénombre (sans trop me prendre la tête):
(Note qu'à part
g++,clang++, et peut-êtreicc, je ne crois pas que la plupart de ces compilos gèrent correctement C++11)[^] # Re: Plugin par défaut
Posté par barmic . Évalué à 2.
C'était pas vraiment la question. Je voulais juste montrer que ce n'est pas parce qu'il y a un ensemble de gens qui doivent se mettre d'accord que c'est super long.
vimn'est pas un standard (contrairement àedetvi) donc sa conf et ses plugins n'ont pas à l'être. L'intérêt c'est juste de mettre un peu d'ordre (sachant qu'il n'est pas envisageable de mettre d'accord l'ensemble des communautés et des gens qui utilisent vi/vim, il y en a trop et depuis trop longtemps).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plugin par défaut
Posté par freem . Évalué à 1.
Point sur lequel on est d'accord.
Le souci étant, que mettre d'accord des gens, ça prend du temps. Et la, on parle d'utilisateurs de vim, des "barbus" qui ont lutté contre "l'ennemi" emacs sur de nombre de forums, etc etc.
Bref, la moindre tentative d'uniformisation de vim risque d'aboutir à la naissance d'un nouveau standard, en plus d'être longue à mettre en place.
[^] # Re: Plugin par défaut
Posté par robin . Évalué à 1.
Vous pensez sincèrement que si Vundle, un .vimrc.bundle, et que la valeur par défaut de certain paramètres (mais avec une nouvelle option « set nonew », fournie par défaut, les barbus pourraient se sentir lésés ? L'idée étant que si on rajoute au début de son .vimrc historique le « set nonew », il n'y ait aucun changement.
bépo powered
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.