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 :)
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.
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.
car c'est un langage qui intègre la possibilité de déclarer des grammaire BNF en natif.
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 :)
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.
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.
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 :)
Non, ceci n'est pas un troll pour prouver une théorique supériorité de LaTeX.
Cependant, il m'a semblé croiser au fil de mes écumages de la toile, des outils permettant de compiler des fichiers .tex en documents web ( ainsi qu'en documents doc, d'ailleurs ) .
Ceci étant dit, vu que tu sembles apprécier les outils avec une GUI, je ne suis pas sûr que tu apprécies LaTeX, puisque c'est du code. Mais peut-être que cette piste pourra te plaire ( personnellement, j'aime bien pour le peu que j'en connait, mais je trouve que c'est quand même un peu la jungle.
En fait, j'ai la même sensation avec LaTeX que quand j'ai découvert Debian pour de bon… noyé par les alternatives et les informations. Vu que je ne suis pas un grand fan de beauté conceptuelle de mes documents ( choisir la police, la couleur, et la taille de mes lettres une par une… non merci, vraiment. ) , je n'ai pas cherché à apprendre à nager dans cet océan, contrairement à Debian ou je m'exerce doucement à la brasse coulée :p —nage lente, mais pas trop fatigante qui donne de jolis aperçus du monde sous-marin sans trop se mouiller—)
Intéressant.
Il s'agit d'un bug que je n'ai jamais rencontré, peut-être parce que j'utilise opera ( en revanche j'en ai d'autres, dont un exclusif à linuxfr. Faudra que je report, un de ces 4… allez, je vais me motiver et le faire de suite. ).
Au final, si je comprend bien, le souci vient du fait que certains browser aient un nombre de connexion limité par serveur, je suppose dans le but d'économiser de la BP tout en téléchargeant plus d'un élément par page ( et donc onglet ), mais la bride entre en conflit direct avec le fait d'utiliser des onglets multiples.
Je me demande si ces situations ( sont-elles résolues? le message que tu cites date de 2011, il y a 3 ans donc. ) se seraient également produites dans le cas de plusieurs instances de la même application lancée sur la même machine?
Pour ma part, je flaire l'application (le browser) qui cherche à deviner ce que l'utilisateur veut, et foire lamentablement. Comme souvent quand une application se mêle d'interpréter les intentions d'un humain.
Et des onglets ! Un navigateur sans onglets c'est devenu has been ;)
Hum… le seul problème des onglets que j'arrive à voir, c'est de les isoler pour pas qu'un bug de l'objet contenu par l'un d'eux fasse planter l'application entière, ou pire, ne puisse corrompre les autres.
Maintenant… si les applications ont besoin de gérer les onglets elles-mêmes, c'est pour une et une seule raison: les gestionnaires de fenêtre flottantes ne font pas leur boulot de façon assez évoluée. Cette fonctionnalité de séparation des processus/thread/affichages (en gros, que dans un même programme on ait de multiples instances de ce programme même qui ne puissent pas communiquer ni avoir d'effets de bord avec/sur les autres) ne devrait pas être dans le navigateur. Bien entendu, je pense la même chose au sujet des éditeurs de texte, notamment.
Gérer les priorité des processus, c'est le job du kernel. Gérer les fenêtres, celui du gestionnaire de fenêtre ( ou comment enfoncer une porte ouverte… ) et donc absolument pas celui du navigateur.
Je crois que le jour où les développeurs de nombreux outils ( wm inclues ) auront compris ça, ils en chieront nettement moins à développer les applis end-user.
Bon, je parle, mais je code pas non plus dans le bon sens, j'admets. Le problème de la séparation des rôles n'est pas simple non plus, par exemple, rien que définir qu'est-ce qui dans une application est de la gestion de fenêtre, et qu'est-ce qui est de l'ordre des contrôles ( et donc, lié au toolkit ) n'est pas simple. Dans les 2 cas, le terme fenêtre est utilisé de façon à peu près semblable, mais pas complètement.
Toujours est-il que je trouve ça assez débile de faire des onglets multiples sur un navigateur, qui est du coup à instance unique ( généralement ) histoire que quand ça plante, ben que ça fasse pas semblant ( le pire, c'est que j'ai été heureux à l'époque ou je suis passé à FF d'avoir des onglets… ).
Pour le reste, je suis globalement d'accord avec toi.
Désolé, mais utiliser un mélange d'espaces et de tabulations (parfois sur la même ligne !)
Je plussoie. D'ailleurs, c'est assez pénible d'aller lire l'implémentation de GNU de la STL, justement parce que c'est le foutoir de ce point de vue ( et comme j'utilise des tab à 2, et non 4 comme la majeure partie des gens… ).
Quand on se dit qu'un simple hook sur l'action de commit du VCS suffirait à coller un coup d'astyle et donc avoir un code propret, c'est tout de même dommage.
La seule question que je poserai, c'est:
Opt-in ou opt-out?
Dans le cas de Debian, popcon, c'est uniquement si l'on choisit volontairement de l'installer. Quand on installe certains logiciels sous windows, chrome ( par exemple, mais il y a pleins d'autres malwares installés comme ça aussi :p—ça c'est pour rester dans le troll—) est installé automatiquement, par défaut. Mais vu que c'est désactivable, ça reste du "volontaire".
Si tu aimes ce genre de choses, je te suggère l'utilisation conjointe de astyle et de diff dans un script, avec un return -1 si le diff détecte une différence. Script collé dans ton outils favori de compilation. En plus ça ne gérera pas que l'indentation ( en fonction des paramètres d'astyle ).
Personnellement, j'aime avoir une indentation à mon goût et unifiée, mais comme toutes les règles ont des exceptions, il m'arrive de violer mes propres règles. Un warning à chaque fois m'emmerderait plus qu'autre chose. La seule option valable dans cette situation, c'est un -Wunreachable-code, code déjà dit. D'ailleurs, je le pensais inclus dans -Wall… m'en vais l'ajouter à tous mes CMakeLists.txt du coup. Merci à celui qui à souligné cette absence.
Juste une question, à quoi diable sert cette boucle ou l'on ne passe de toute façon qu'une seule fois?
Si c'est pour le scope, autant juste mettre les accolades, sans boucle, ça revient au même, sauf qu'au moins, le WTF est plus simple à détecter lors d'une lecture rapide (what? des accolades sans instruction conditionnelle?) et l'intérêt de ces accolades plus évident pour quelqu'un avec une connaissance moyenne du C et/ou C++ ( ah, ça doit être pour générer un scope artificiel, et donc nettoyer les variables! ).
Personnellement, ça m'arrive pour isoler des blocs de code que je sais que je ne réutiliserais pas ailleurs (donc les mettre dans un fonction séparée est inutile voire un remède pire que le mal), et qui utilisent des variables/objets coûteux qui ne sont utilisés réellement que lors de la moitié de la fonction, ainsi que pour réutiliser des variables bateau mal nommées ( genre it pour les itérateurs ).
Comme plusieurs dans les commentaires, je me moque totalement des lug et autre socialeries autour de linux.
Entres autres parce que ce n'est jamais dans mon coin, ou que si je veux ce genre de choses, je regarde autour de moi voir s'il y a des associations, et je vais ensuite me renseigner auprès d'elles.
Pourtant, je pense que ces brèves ont leur place ici, juste, pas en 1ère page, excepté pour les évènements majeurs ( genre nationaux au minimum ). C'est un peu comme si dans le journal on avait en 1ère page l'AG d'une obscure association de rando pédestre de trifouilly les oies en somme. Tout le monde s'en moque. Par contre, si l'on parle d'un évènement genre tour de France, alors pourquoi pas ( encore que… ).
Du coup j'aime bien l'idée de les "reléguer" à une carte ou ces manifestations seraient représentées par un point ou une couleur différente dans un département ou il y aurait une brève la concernant, par encore obsolète.
Ça ne prend pas de place, et c'est visuellement parlant, plutôt que devoir lire la dépêche pour savoir dans quel bled ça se trouve afin de faire une recherche pour savoir à peu près a quelle distance on en est ( trifouilly les oies, c'est dans l'Eure ou dans le Cantal?).
Par contre il faut trouver les petites mains pour le faire :)
En effet, ils ne sont pas la totalité de systemd, et n'impliquent pas l'installation du cœur de systemd..
Sauf que, ce sont des utilitaires qui ne servent à rien si tu n'as pas systemd installé. C'est du moins ce que me disent les description de ces paquets dans aptitude.
Après tout, systemd, ce n'est pas que le système d'init, mais aussi les outils qui gravitent autour, ainsi que des trucs qui n'ont rien à voir avec l'init. C'est même un des points forts de systemd. Ou de ses points faibles, en fonction du point de vue de l'utilisateur.
Je me souviens d'une phrase qui dit un truc de ce genre:
Un logiciel n'est pas parfait quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à enlever.
Malheureusement, je ne connais pas l'auteur, et je ne suis pas sûr d'avoir retranscrit fidèlement, mais le lien avec systemd, et les dépendances aux interfaces de systemd, me semble évident. On ajoute des choses qui n'ont pas forcément lieu d'être. Le souci est aussi que le nombre de fonctionnalités minimum d'un logiciel est différent d'une personne à l'autre :)
J'ai connu une personne sur travian, qui était incapable d'aligner plus de 3 mots sans faire de faute.
2 ans plus tard, je lui ai parlé à nouveau ( via msn de mémoire ) et son français était presque impeccable. Je me suis pas privé de lui faire la remarque ( vu que je l'avais bassiné auparavant pour qu'il se corrige ) et il m'a répondu qu'a force de se faire modérer sur le forum officiel, et corriger par les autres utilisateurs, c'était venu.
Conclusion: internet peut aider à corriger l'illettrisme ( non, pas d'autre mots pour qualifier son niveau au moment ou je l'ai connu ).
PS: skyblog et le forum dont tu parles, ne sont pas internet. Ils ne sont qu'une petite partie du web, lui-même petite partie d'internet.
Si l'action du "double clic sur le deb" est bindée sur dpkg, c'est normal. Mais il existe un outil qui lui gère les dépendances ainsi. Voire même, il ne me semble pas hyper complexe de faire un script ( oui, je t'accorde qu'il devrait être fournit par le DE, mais bon… ) qui fasse:
dpkg -i $1 && aptitude install -y
Si je ne m'abuse, dbus est surtout utilisé pour 2 choses:
_ récupérer une partie des droits root avec un utilisateur normal ( genre, pour contrôler le réseau: wicd par exemple dépend avec raison de dbus. Cet usage me semble normal et incontournable, malgré le fait que je n'apprécie pas du tout le fait que dbus utilise XML pour de la configuration, notamment. )
_ notifier une application que sa configuration à été modifiée par une autre ( il paraît. Sauf que personnellement, n'étant pas un utilisateur de DE pré-construit, je m'en tamponne un peu. En plus, je pense que seule une application devrait être experte de sa propre configuration, exactement comme une classe est la seule à manipuler ses données internes selon GRASP. Ce type de dépendance, je m'en passerai volontiers. )
Alors que PA, lui, peut être désactivé à peu près quand on veut sans handicaper le moins du monde les applications qui en "dépendent", en tout cas pour toutes celles que j'ai utilisées jusqu'à aujourd'hui ( ce qui ne veux pas dire que mon expérience est généralisable, je sais. Mais juste que je me permets de supposer que c'est le cas de bon nombre d' "utilisateurs audio classiques" qui ne font qu'écouter de la musique et regarder des films, avec un peu de mumble/skype au passage.).
Recompiler un paquet est simple oui, c'est certain. Mais ça signifie aussi qu'il faut le refaire à chaque nouvelle MaJ, et apt ne gère pas, à ma connaissance, le multi-tasking/threading, ce qui rend les MaJ un peu importantes déjà assez longues comme ça, sans vouloir y rajouter de la compilation.
En fait, si je voulais m'amuser a recompiler les paquets, nul doute que je ne m'orienterait pas vers Debian, qui n'est pas faite pour cet usage ( ce qui ne veut pas dire qu'on ne peut pas, juste que ça ne me semble pas être l'esprit ), mais plutôt vers sourcemage, gentoo, ou une distro dans ce style ( à noter que je me suis déjà essayé à gentoo, mais la compilation du kernel m'a stoppé net. Le mieux que j'aie réussi est un kernel lent - comparé à Debian - auquel il fallait passer des infos à la main au boot. Je réessaierai sûrement plus tard, ceci dit. ) qui ont de la doc naturellement plus poussée ainsi qu'un système de build conçu pour ça. Peut-être le jour ou linux compilera avec clang, qui sait ( histoire de passer moins de temps à la compilation ) …
Le français…
A notre échelle simplement nationale, on discerne déjà pas mal de dialectes… que l'on peut classer entre 2 familles linguistiques ( je suis même pas sûr que le terme de famille sois bon en plus ): langue d'oil et langue d'oc.
Chacune de ces famille état elle-même subdivisée en de multiples variantes dont certaines ( potentiellement classées à l'unesco seloin une source dont je n'arrive pas à retrouver la provenance. Au moins vous êtes prévenus. La recherche que j'avais faite à l'époque portait sur le cauchois, subdivision de la langue normande. )
Bref, tout ça pour dire, tu ne devrais pas être surpris par le fait que notre langue commune soit si riche. En même temps, je trouve ça intéressant qu'on ne soit pas capable de nous comprendre les uns les autres sans efforts.
Ca nous permets, voire nous force, de réfléchir à ce que l'on dit, et parfois, on y gagne en sagesse sans même le vouloir en nous faisant reformuler des idées qui semblaient évidentes mais étaient en fait stupides.
Oui, j'avoue, je ne comprend pas à la 1ère écoute un belge qui me parle, ni un marseillais.
Par contre, ça m'aide a comprendre les choses sous un autre angle: ils utilisent des mots différents, qui me forcent à m'interroger sur le sens des mots que, moi, j'utilise ( il ne faut pas oublier le contexte ) . Et au travers de ces interrogations, j'apprends à penser par moi-même. Grâce aux autres, tout en restant maître de mes opinions.
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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 freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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: Un nouveau Gnome ?
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 2.
La configuration de vim est clairement l'un des plus gros points noirs de cet outil.
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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 :)
[^] # Re: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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: La réponse de Bram Moolenaar
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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 freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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: Evolution
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. É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: LaTeX
Posté par freem . En réponse au message Faire une présentation en html/css/js ; quel outil utiliser ?. Évalué à 1.
Je n'ai pas eu l'impression que la demande de base se limitait à fontawesome, mais je me suis peut-être trompé :)
# LaTeX
Posté par freem . En réponse au message Faire une présentation en html/css/js ; quel outil utiliser ?. Évalué à 1.
Non, ceci n'est pas un troll pour prouver une théorique supériorité de LaTeX.
Cependant, il m'a semblé croiser au fil de mes écumages de la toile, des outils permettant de compiler des fichiers .tex en documents web ( ainsi qu'en documents doc, d'ailleurs ) .
Ceci étant dit, vu que tu sembles apprécier les outils avec une GUI, je ne suis pas sûr que tu apprécies LaTeX, puisque c'est du code. Mais peut-être que cette piste pourra te plaire ( personnellement, j'aime bien pour le peu que j'en connait, mais je trouve que c'est quand même un peu la jungle.
En fait, j'ai la même sensation avec LaTeX que quand j'ai découvert Debian pour de bon… noyé par les alternatives et les informations. Vu que je ne suis pas un grand fan de beauté conceptuelle de mes documents ( choisir la police, la couleur, et la taille de mes lettres une par une… non merci, vraiment. ) , je n'ai pas cherché à apprendre à nager dans cet océan, contrairement à Debian ou je m'exerce doucement à la brasse coulée :p —nage lente, mais pas trop fatigante qui donne de jolis aperçus du monde sous-marin sans trop se mouiller—)
[^] # Re: Euh... tu déconnes ?
Posté par freem . En réponse au message Pourquoi c'est dur de coder un navigateur Internet ?. Évalué à 1.
Intéressant.
Il s'agit d'un bug que je n'ai jamais rencontré, peut-être parce que j'utilise opera ( en revanche j'en ai d'autres, dont un exclusif à linuxfr. Faudra que je report, un de ces 4… allez, je vais me motiver et le faire de suite. ).
Au final, si je comprend bien, le souci vient du fait que certains browser aient un nombre de connexion limité par serveur, je suppose dans le but d'économiser de la BP tout en téléchargeant plus d'un élément par page ( et donc onglet ), mais la bride entre en conflit direct avec le fait d'utiliser des onglets multiples.
Je me demande si ces situations ( sont-elles résolues? le message que tu cites date de 2011, il y a 3 ans donc. ) se seraient également produites dans le cas de plusieurs instances de la même application lancée sur la même machine?
Pour ma part, je flaire l'application (le browser) qui cherche à deviner ce que l'utilisateur veut, et foire lamentablement. Comme souvent quand une application se mêle d'interpréter les intentions d'un humain.
[^] # Re: Euh... tu déconnes ?
Posté par freem . En réponse au message Pourquoi c'est dur de coder un navigateur Internet ?. Évalué à 1.
Hum… le seul problème des onglets que j'arrive à voir, c'est de les isoler pour pas qu'un bug de l'objet contenu par l'un d'eux fasse planter l'application entière, ou pire, ne puisse corrompre les autres.
Maintenant… si les applications ont besoin de gérer les onglets elles-mêmes, c'est pour une et une seule raison: les gestionnaires de fenêtre flottantes ne font pas leur boulot de façon assez évoluée. Cette fonctionnalité de séparation des processus/thread/affichages (en gros, que dans un même programme on ait de multiples instances de ce programme même qui ne puissent pas communiquer ni avoir d'effets de bord avec/sur les autres) ne devrait pas être dans le navigateur. Bien entendu, je pense la même chose au sujet des éditeurs de texte, notamment.
Gérer les priorité des processus, c'est le job du kernel. Gérer les fenêtres, celui du gestionnaire de fenêtre ( ou comment enfoncer une porte ouverte… ) et donc absolument pas celui du navigateur.
Je crois que le jour où les développeurs de nombreux outils ( wm inclues ) auront compris ça, ils en chieront nettement moins à développer les applis end-user.
Bon, je parle, mais je code pas non plus dans le bon sens, j'admets. Le problème de la séparation des rôles n'est pas simple non plus, par exemple, rien que définir qu'est-ce qui dans une application est de la gestion de fenêtre, et qu'est-ce qui est de l'ordre des contrôles ( et donc, lié au toolkit ) n'est pas simple. Dans les 2 cas, le terme fenêtre est utilisé de façon à peu près semblable, mais pas complètement.
Toujours est-il que je trouve ça assez débile de faire des onglets multiples sur un navigateur, qui est du coup à instance unique ( généralement ) histoire que quand ça plante, ben que ça fasse pas semblant ( le pire, c'est que j'ai été heureux à l'époque ou je suis passé à FF d'avoir des onglets… ).
Pour le reste, je suis globalement d'accord avec toi.
[^] # Re: Code défensif
Posté par freem . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 2.
Je plussoie. D'ailleurs, c'est assez pénible d'aller lire l'implémentation de GNU de la STL, justement parce que c'est le foutoir de ce point de vue ( et comme j'utilise des tab à 2, et non 4 comme la majeure partie des gens… ).
Quand on se dit qu'un simple hook sur l'action de commit du VCS suffirait à coller un coup d'astyle et donc avoir un code propret, c'est tout de même dommage.
[^] # Re: fin de l'histoire ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
Merci bien. Ca m'ennuyait de citer sans mettre le nom, et pire, sans mettre la citation exacte :S
[^] # Re: Le cas goto
Posté par freem . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 2.
Oh… pas faux. Merci, je penserai peut-être à utiliser ce genre d'astuce un jour du coup, si j'ai à nouveau recours au C.
[^] # Re: Debian aussi!
Posté par freem . En réponse au journal La Quadrature du Net veut-elle nous placer sous surveillance ?. Évalué à 1.
La seule question que je poserai, c'est:
Opt-in ou opt-out?
Dans le cas de Debian, popcon, c'est uniquement si l'on choisit volontairement de l'installer. Quand on installe certains logiciels sous windows, chrome ( par exemple, mais il y a pleins d'autres malwares installés comme ça aussi :p—ça c'est pour rester dans le troll—) est installé automatiquement, par défaut. Mais vu que c'est désactivable, ça reste du "volontaire".
[^] # Re: Manque un warning "indentation"
Posté par freem . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 1.
Si tu aimes ce genre de choses, je te suggère l'utilisation conjointe de astyle et de diff dans un script, avec un return -1 si le diff détecte une différence. Script collé dans ton outils favori de compilation. En plus ça ne gérera pas que l'indentation ( en fonction des paramètres d'astyle ).
Personnellement, j'aime avoir une indentation à mon goût et unifiée, mais comme toutes les règles ont des exceptions, il m'arrive de violer mes propres règles. Un warning à chaque fois m'emmerderait plus qu'autre chose. La seule option valable dans cette situation, c'est un -Wunreachable-code, code déjà dit. D'ailleurs, je le pensais inclus dans -Wall… m'en vais l'ajouter à tous mes CMakeLists.txt du coup. Merci à celui qui à souligné cette absence.
[^] # Re: Le cas goto
Posté par freem . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 1.
Juste une question, à quoi diable sert cette boucle ou l'on ne passe de toute façon qu'une seule fois?
Si c'est pour le scope, autant juste mettre les accolades, sans boucle, ça revient au même, sauf qu'au moins, le WTF est plus simple à détecter lors d'une lecture rapide (what? des accolades sans instruction conditionnelle?) et l'intérêt de ces accolades plus évident pour quelqu'un avec une connaissance moyenne du C et/ou C++ ( ah, ça doit être pour générer un scope artificiel, et donc nettoyer les variables! ).
Personnellement, ça m'arrive pour isoler des blocs de code que je sais que je ne réutiliserais pas ailleurs (donc les mettre dans un fonction séparée est inutile voire un remède pire que le mal), et qui utilisent des variables/objets coûteux qui ne sont utilisés réellement que lors de la moitié de la fonction, ainsi que pour réutiliser des variables bateau mal nommées ( genre it pour les itérateurs ).
# J'aime bien l'idée de la carte
Posté par freem . En réponse au journal Avoir du marbre (et des discussions techniques). Évalué à 10.
Comme plusieurs dans les commentaires, je me moque totalement des lug et autre socialeries autour de linux.
Entres autres parce que ce n'est jamais dans mon coin, ou que si je veux ce genre de choses, je regarde autour de moi voir s'il y a des associations, et je vais ensuite me renseigner auprès d'elles.
Pourtant, je pense que ces brèves ont leur place ici, juste, pas en 1ère page, excepté pour les évènements majeurs ( genre nationaux au minimum ). C'est un peu comme si dans le journal on avait en 1ère page l'AG d'une obscure association de rando pédestre de trifouilly les oies en somme. Tout le monde s'en moque. Par contre, si l'on parle d'un évènement genre tour de France, alors pourquoi pas ( encore que… ).
Du coup j'aime bien l'idée de les "reléguer" à une carte ou ces manifestations seraient représentées par un point ou une couleur différente dans un département ou il y aurait une brève la concernant, par encore obsolète.
Ça ne prend pas de place, et c'est visuellement parlant, plutôt que devoir lire la dépêche pour savoir dans quel bled ça se trouve afin de faire une recherche pour savoir à peu près a quelle distance on en est ( trifouilly les oies, c'est dans l'Eure ou dans le Cantal?).
Par contre il faut trouver les petites mains pour le faire :)
[^] # Re: fin de l'histoire ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
En effet, ils ne sont pas la totalité de systemd, et n'impliquent pas l'installation du cœur de systemd..
Sauf que, ce sont des utilitaires qui ne servent à rien si tu n'as pas systemd installé. C'est du moins ce que me disent les description de ces paquets dans aptitude.
Après tout, systemd, ce n'est pas que le système d'init, mais aussi les outils qui gravitent autour, ainsi que des trucs qui n'ont rien à voir avec l'init. C'est même un des points forts de systemd. Ou de ses points faibles, en fonction du point de vue de l'utilisateur.
Je me souviens d'une phrase qui dit un truc de ce genre:
Un logiciel n'est pas parfait quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à enlever.
Malheureusement, je ne connais pas l'auteur, et je ne suis pas sûr d'avoir retranscrit fidèlement, mais le lien avec systemd, et les dépendances aux interfaces de systemd, me semble évident. On ajoute des choses qui n'ont pas forcément lieu d'être. Le souci est aussi que le nombre de fonctionnalités minimum d'un logiciel est différent d'une personne à l'autre :)
[^] # Re: C'est la vie...
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
J'ai connu une personne sur travian, qui était incapable d'aligner plus de 3 mots sans faire de faute.
2 ans plus tard, je lui ai parlé à nouveau ( via msn de mémoire ) et son français était presque impeccable. Je me suis pas privé de lui faire la remarque ( vu que je l'avais bassiné auparavant pour qu'il se corrige ) et il m'a répondu qu'a force de se faire modérer sur le forum officiel, et corriger par les autres utilisateurs, c'était venu.
Conclusion: internet peut aider à corriger l'illettrisme ( non, pas d'autre mots pour qualifier son niveau au moment ou je l'ai connu ).
PS: skyblog et le forum dont tu parles, ne sont pas internet. Ils ne sont qu'une petite partie du web, lui-même petite partie d'internet.
[^] # Re: C'est la vie...
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
Si l'action du "double clic sur le deb" est bindée sur dpkg, c'est normal. Mais il existe un outil qui lui gère les dépendances ainsi. Voire même, il ne me semble pas hyper complexe de faire un script ( oui, je t'accorde qu'il devrait être fournit par le DE, mais bon… ) qui fasse:
dpkg -i $1 && aptitude install -y
[^] # Re: fin de l'histoire ?
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
Si je ne m'abuse, dbus est surtout utilisé pour 2 choses:
_ récupérer une partie des droits root avec un utilisateur normal ( genre, pour contrôler le réseau: wicd par exemple dépend avec raison de dbus. Cet usage me semble normal et incontournable, malgré le fait que je n'apprécie pas du tout le fait que dbus utilise XML pour de la configuration, notamment. )
_ notifier une application que sa configuration à été modifiée par une autre ( il paraît. Sauf que personnellement, n'étant pas un utilisateur de DE pré-construit, je m'en tamponne un peu. En plus, je pense que seule une application devrait être experte de sa propre configuration, exactement comme une classe est la seule à manipuler ses données internes selon GRASP. Ce type de dépendance, je m'en passerai volontiers. )
Alors que PA, lui, peut être désactivé à peu près quand on veut sans handicaper le moins du monde les applications qui en "dépendent", en tout cas pour toutes celles que j'ai utilisées jusqu'à aujourd'hui ( ce qui ne veux pas dire que mon expérience est généralisable, je sais. Mais juste que je me permets de supposer que c'est le cas de bon nombre d' "utilisateurs audio classiques" qui ne font qu'écouter de la musique et regarder des films, avec un peu de mumble/skype au passage.).
Recompiler un paquet est simple oui, c'est certain. Mais ça signifie aussi qu'il faut le refaire à chaque nouvelle MaJ, et apt ne gère pas, à ma connaissance, le multi-tasking/threading, ce qui rend les MaJ un peu importantes déjà assez longues comme ça, sans vouloir y rajouter de la compilation.
En fait, si je voulais m'amuser a recompiler les paquets, nul doute que je ne m'orienterait pas vers Debian, qui n'est pas faite pour cet usage ( ce qui ne veut pas dire qu'on ne peut pas, juste que ça ne me semble pas être l'esprit ), mais plutôt vers sourcemage, gentoo, ou une distro dans ce style ( à noter que je me suis déjà essayé à gentoo, mais la compilation du kernel m'a stoppé net. Le mieux que j'aie réussi est un kernel lent - comparé à Debian - auquel il fallait passer des infos à la main au boot. Je réessaierai sûrement plus tard, ceci dit. ) qui ont de la doc naturellement plus poussée ainsi qu'un système de build conçu pour ça. Peut-être le jour ou linux compilera avec clang, qui sait ( histoire de passer moins de temps à la compilation ) …
[^] # Re: C'est la vie...
Posté par freem . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 1.
Le français…
A notre échelle simplement nationale, on discerne déjà pas mal de dialectes… que l'on peut classer entre 2 familles linguistiques ( je suis même pas sûr que le terme de famille sois bon en plus ): langue d'oil et langue d'oc.
Chacune de ces famille état elle-même subdivisée en de multiples variantes dont certaines ( potentiellement classées à l'unesco seloin une source dont je n'arrive pas à retrouver la provenance. Au moins vous êtes prévenus. La recherche que j'avais faite à l'époque portait sur le cauchois, subdivision de la langue normande. )
Bref, tout ça pour dire, tu ne devrais pas être surpris par le fait que notre langue commune soit si riche. En même temps, je trouve ça intéressant qu'on ne soit pas capable de nous comprendre les uns les autres sans efforts.
Ca nous permets, voire nous force, de réfléchir à ce que l'on dit, et parfois, on y gagne en sagesse sans même le vouloir en nous faisant reformuler des idées qui semblaient évidentes mais étaient en fait stupides.
Oui, j'avoue, je ne comprend pas à la 1ère écoute un belge qui me parle, ni un marseillais.
Par contre, ça m'aide a comprendre les choses sous un autre angle: ils utilisent des mots différents, qui me forcent à m'interroger sur le sens des mots que, moi, j'utilise ( il ne faut pas oublier le contexte ) . Et au travers de ces interrogations, j'apprends à penser par moi-même. Grâce aux autres, tout en restant maître de mes opinions.