Ces deux-là (au moins vimium-ff que j'ai testé) ont des raccourcis très différents de Vimperator et n'ont pas de "miniprompt". Cependant vimiu-ff marche bien. Pour le coup vim-vixen ressemble beaucoup à Vimperator. Elles ont toutes quelques limitations, par exemple elles ne marche pas sur les pages spéciales de FF (page d'extensions, nouvel onglet, about:config etc).
Sinon je citerais bien which-key: https://github.com/justbur/emacs-which-key c'est LE package sous-jacent à Spacemacs, celui qui montre contextuellement après un léger délai quels sont les raccourcis et fonctions possibles après une première touche. Donc on peut avoir un petit goût de Spacemacs, et une grande aide, en installant et activant which-key-mode.
Non malheureusement pas d'autres lectures sur Weblocks à proposer, l'ancien site n'a pas grand chose.
Effectivement Weblocks produit un couplage comme tu l'as décrit, mais à l'inverse de ce qu'on pourrait conclure avec les exemples qui mélangent allégrement logique, template et style, on peut faire du MVC en mettant ce qu'il faut dans leurs propres fichiers et modules. Néanmoins, à ce que je comprends un bénéfice de l'approche de Weblocks serait d'écrire une app web de manière plus linéaire, grâce à son système basé sur les continuations (qui gère la session et pour lequel le développeur n'a besoin de connaître que 2 ou 3 macros).
Mais tu n'y es pas du tout ! Google n'est toujours pas bon en CL donc on doit le nourrir à la becquée. Il faut rediriger vers http://lisp-lang.org/ pour mettre l'eau à la bouche aux lecteurs et lectrices, puis citer https://github.com/CodyReichert/awesome-cl pour éventuellement évoquer Cliki (j'aime pas Cliki). Ensuite moi je cite toujours le Common Lisp Cookbook, la version sur github, vachement améliorée cette année.
Ensuite as-tu vu Panic, une preuve de concept qui fait marcher React ?
Pour ce qui est d'un framework web "dynamique", je parie et m'intéresse fort à Weblocks. Mais à la version d'un dév en train de le factoriser et moderniser, dont l'exemple pour faire un TodoMVC est très clair et très simple: http://40ants.com/weblocks/quickstart.html On construit donc une page interactive en pure lisp, sans écrire d'appels Ajax, où ils sont backportés en pur html si besoin, avec l'avantage d'un environnement Lisp (détection d'erreurs, debuggeur, création d'un exécutable,…). Mon idéal en passe de se réaliser c'est de coder une app web en un langage, avec la même expérience de dév et débug par conséquent, de construire des exécutables prêts à être déployés, d'explorer leur runtime en live, de déployer "à chaud" et de fournir une version de bureautique via Electron (Ceramic en CL). On y est quasiment !
Fais-nous part de tes avancées par ici !
ps: cf aussi mon tuto en cours de finition (web scraping, création d'exécutables, tests,…)
pps: vidéo de Marco illisible "fichier corrompu" :(
eh bien, j'espère que ta campagne va toucher assez de gens, bien que le travail soit assez spécialisé.
Et j'espère que tu continueras à travailler à temps partiel pour pouvoir te consacrer à tes projets :)
Quoiqu'on pense, étant donné la hausse extrèmement soudaine de la moyenne des températures sur terre depuis le début du siècle comparé à l'évolution depuis la dernière ère glaciaire, autant prendre la question de réduction des émissions au sérieux:
Évolution de la température moyenne sur terre depuis la dernière ère glaciaire il y a 22 000 ans
dsl pour la méga image, elle vaut le coup je pense :)
Vu le travail de recherche effectué par ces sociétés je trouve normal qu'elles protègent le fruit de leur travail.
tu t'en fiches des OGM et des graines non reproductibles et de Monsanto qui impose tout ça, comme pour le coton au Burkina Faso, avec des effets désastreux sur l'indépendance des paysans ET sur les cultures ?
Le jeu des Lobby a fait qu'on les a laissé aller beaucoup trop loin (comme d'hab).
la surface étudiée ne compte pas les allées, aires de compostages et bâtis: pour cultiver 1 000m2 comme le dit l'étude il faut bien le double
leur chiffre d'affaire équivaut à la valeur récoltée, qui est pour certains produits seulement estimée, et au meilleur prix possible
pour eux la productivite égale la valeur récoltée, ce qui est faux, et ce qui est calculé bizarrement
ils cultivent surtout des tomates et autres légumes de saison à fort valeur ajoutée, peu de choses pour l'hiver qui prend plus de temps à pousser
ils ont une forte charge de travail gratuite par des stagiaires
la ferme génère beaucoup de revenus par des formations payantes
la ferme n'a pas de prêts bancaires ou autres investissements à rembourser, elle a été créée avec le fonds personnel des créateurs qui viennent d'une autre activité
De nombreux langages et concepts modernes n'existaient pas à l'époque
de nombreux concepts de lisp ne sont pas présents dans les languages aujourd'hui, tels que Python: le modèle objet (méthodes génériques,…), les hooks ("advice"), la méta-programmation riche (les fameuses macros) (Python avec ses décorateurs et "with statements" fait pâle figure), le fait d'avoir une "lisp machine" est énorme, les reader macros (modification du reader, qui lit le code source, pour créer une nouvelle syntaxe), l'inférence de types, créer une image exécutable standalone, désassembler une fonction, plus d'orientation objet, les closures,… (Cf mon commentaire https://linuxfr.org/nodes/112513/comments/1711088)
mais pas sûr que elisp serait choisi sur un autre lisp, oui.
Emacs en Rust, mais oui mon ami ! https://github.com/Wilfred/remacs Où Rust remplace le C, mais où le elisp est inchangé. Ce n'est pas un fork, bonne chose à noter.
J'ai écrit quelques paquets elisp, j'ai mon avis sur elisp VS python. Clairement Python est plus populaire, mais il me paraît totalement inadapté au rôle que remplie le lisp. Lisp permet d'avoir une "lisp machine", où on peut évaluer du code dans le process en cours qui devient disponible de suite. En Python, on écrit et on relance l'appli. Elisp et d'autres lisps permettent de définir une fonction qui soit exécutée juste avant, juste après ou à la place d'une autre (les "advice"). C'est ce qui permet d'implémenter les hooks par exemple, et c'est beaucoup utilisé en général. Ça permet d'écrire facilement des extensions à un paquet, sans avoir à le modifier. En Python (ou autres), il n'y a pas ça par défaut. De manière similaire certains frameworks proposent des signaux (pre-save, post-save,…). De manière générale la méta-programmation en lisp est plus riche et complète, de par le module objet, ces hooks, et grâce aux parenthèses (le code est une liste, facile à manipuler), alors que vas-y pour manipuler l'ast de python. Des trucs comme ça.
Plus concrètement, je me demande comment on ferait pour taper du python, sensible à l'indentation, dans le mini-buffer ! Alors qu'en lisp tu regardes le matching des parenthèses.
Enfin notons qu'on peut écrire des extensions qui utilisent en sous-main des paquets python, en l'installation elles-mêmes à l'endroit qui va bien, etc (emacs-traad,…).
Et que Emacs25 supporte les Xwidgets, donc on peut imaginer voir ces trucs plus puissants (encore que, moi je préfère manipuler du texte qu'un widget graphique à la souris).
Question: en utilisant spacemacs, j'observe que des fois dans les aides emacs ça diffère un peu. Est-ce que tu penses que ça reste superficiel, ou alors y a des domaines où c'est fondamentalement différent ? (si tu connais un peu spacemacs bien sûr).
euh alors ce devrait être des différences superficielles, du genre raccourcis claviers (évidemment) ou moyens de configurer les différents modules en elisp, auquel cas si ça diffère de la doc officielle c'est pas grave (j'ai pas utilisé spacemacs (evil-mode bien sûr !) (mais j'ai un peu regardé sa config) donc des exemples seraient bienvenus).
En tout cas merci encore pour wikemacs, ça va peut-être me garder définitivement dans emacs (ou plutôt spacemacs) !
ça c'est cool ça :) Je rappelle qu'un wiki est ouvert aux contributions et que petit à petit le "noob" construit des pages utiles ;) (la preuve)
Il y a des milliers de fonctions possibles. Des raccourcis (et un menu) ne suffisent pas.
Il peut y avoir plein de solutions ; certains packages offrent d'ailleurs des idées.
A mes yeux si Emacs veut être utilisatble "out of the box direct t'as vu"; il faut absolument montrer à l'utilisateur à quelles fonctions il a accès.
c'est sûr, mais on peut s'en sortir je pense: avec which-key, avec un dashboard de bienvenue (https://github.com/rakanalh/emacs-dashboard), avec un smex ou counsel-M-x (https://github.com/abo-abo/swiper) à la place de M-x pour avoir comme une palette sous d'autres éditeurs, et avec des hydras (https://github.com/abo-abo/hydra/) et l'interface à la magit: un "menu" interactif montre les sous-commandes accessibles en une touche. C'est super efficace !
[^] # Re: extension pour un comportement à la Vim
Posté par dzecniv . En réponse au journal Le Firefox nouveau est arrivé !. Évalué à 2.
Ces deux-là (au moins vimium-ff que j'ai testé) ont des raccourcis très différents de Vimperator et n'ont pas de "miniprompt". Cependant vimiu-ff marche bien. Pour le coup vim-vixen ressemble beaucoup à Vimperator. Elles ont toutes quelques limitations, par exemple elles ne marche pas sur les pages spéciales de FF (page d'extensions, nouvel onglet, about:config etc).
# gitlab CI ?
Posté par dzecniv . En réponse au journal Projet DIY d'intégration continue auto-hébergée. Évalué à 10.
salut, et Gitlab CI ? Tu peux l'auto héberger au besoin.
# which-key
Posté par dzecniv . En réponse au journal Emacs NU-MODE et ses concurrents. Évalué à 5.
tant pis si ça n'a aucun sens sur bépo…
Sinon je citerais bien which-key: https://github.com/justbur/emacs-which-key c'est LE package sous-jacent à Spacemacs, celui qui montre contextuellement après un léger délai quels sont les raccourcis et fonctions possibles après une première touche. Donc on peut avoir un petit goût de Spacemacs, et une grande aide, en installant et activant which-key-mode.
[^] # Re: Oui mais non
Posté par dzecniv . En réponse au journal C'est décidé, j'apprends Common Lisp!. Évalué à 2.
Non malheureusement pas d'autres lectures sur Weblocks à proposer, l'ancien site n'a pas grand chose.
Effectivement Weblocks produit un couplage comme tu l'as décrit, mais à l'inverse de ce qu'on pourrait conclure avec les exemples qui mélangent allégrement logique, template et style, on peut faire du MVC en mettant ce qu'il faut dans leurs propres fichiers et modules. Néanmoins, à ce que je comprends un bénéfice de l'approche de Weblocks serait d'écrire une app web de manière plus linéaire, grâce à son système basé sur les continuations (qui gère la session et pour lequel le développeur n'a besoin de connaître que 2 ou 3 macros).
# Oui mais non
Posté par dzecniv . En réponse au journal C'est décidé, j'apprends Common Lisp!. Évalué à 4.
Salut,
ravi de lire cela, moi-même investissant du temps pour découvrir le langage et son écosystème (cf mon journal https://linuxfr.org/users/dzecniv/journaux/decouvrons-common-lisp-comparaison-avec-l-environnement-python)
Mais tu n'y es pas du tout ! Google n'est toujours pas bon en CL donc on doit le nourrir à la becquée. Il faut rediriger vers http://lisp-lang.org/ pour mettre l'eau à la bouche aux lecteurs et lectrices, puis citer https://github.com/CodyReichert/awesome-cl pour éventuellement évoquer Cliki (j'aime pas Cliki). Ensuite moi je cite toujours le Common Lisp Cookbook, la version sur github, vachement améliorée cette année.
Ensuite as-tu vu Panic, une preuve de concept qui fait marcher React ?
Pour ce qui est d'un framework web "dynamique", je parie et m'intéresse fort à Weblocks. Mais à la version d'un dév en train de le factoriser et moderniser, dont l'exemple pour faire un TodoMVC est très clair et très simple: http://40ants.com/weblocks/quickstart.html On construit donc une page interactive en pure lisp, sans écrire d'appels Ajax, où ils sont backportés en pur html si besoin, avec l'avantage d'un environnement Lisp (détection d'erreurs, debuggeur, création d'un exécutable,…). Mon idéal en passe de se réaliser c'est de coder une app web en un langage, avec la même expérience de dév et débug par conséquent, de construire des exécutables prêts à être déployés, d'explorer leur runtime en live, de déployer "à chaud" et de fournir une version de bureautique via Electron (Ceramic en CL). On y est quasiment !
Fais-nous part de tes avancées par ici !
ps: cf aussi mon tuto en cours de finition (web scraping, création d'exécutables, tests,…)
pps: vidéo de Marco illisible "fichier corrompu" :(
# Exemples ?
Posté par dzecniv . En réponse au journal Le Courrier du hacker, newsletter sur le Logiciel Libre et Open Source francophone. Évalué à 4.
Ola, y a-t-il des exemples de ces lettres ? Merci.
ps: ça marche pour toi linuxjobs ? (grâce auquel j'ai trouvé un chouette taf :) )
[^] # Re: captcha + Mailchimps
Posté par dzecniv . En réponse au journal Le Courrier du hacker, newsletter sur le Logiciel Libre et Open Source francophone. Évalué à 6.
J'ai vu passer cette alternative à Mailchimp: https://github.com/freeCodeCamp/mail-for-good/ À déployer sur AWS. Serait 100x moins cher que Mailchimp pour les grosses listes.
# eh bé
Posté par dzecniv . En réponse à la dépêche Campagne de financement pour GtkSourceView. Évalué à 4.
eh bien, j'espère que ta campagne va toucher assez de gens, bien que le travail soit assez spécialisé.
Et j'espère que tu continueras à travailler à temps partiel pour pouvoir te consacrer à tes projets :)
# L'original: la patate
Posté par dzecniv . En réponse au journal Keybase, un Discord/Slack like Open-Source mais centralisé. Évalué à 2.
Pour moi le plus original du lot c'est Potato, écrit en Common Lisp et ClojureScript ! Et il a son lot de fonctionnalités.
# Repos
Posté par dzecniv . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2. Dernière modification le 19 septembre 2017 à 11:24.
[^] # Re: Attention, n'allons pas trop vite…
Posté par dzecniv . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 10. Dernière modification le 07 septembre 2017 à 18:23.
Quoiqu'on pense, étant donné la hausse extrèmement soudaine de la moyenne des températures sur terre depuis le début du siècle comparé à l'évolution depuis la dernière ère glaciaire, autant prendre la question de réduction des émissions au sérieux:
Évolution de la température moyenne sur terre depuis la dernière ère glaciaire il y a 22 000 ans
dsl pour la méga image, elle vaut le coup je pense :)
# la Chine ?
Posté par dzecniv . En réponse au journal 3% d'ordinateurs personnels sous Linux. Évalué à 6.
Serait-ce Ubuntu dont les ventes explosent en Chine ?
Apparemment Dell y vend 42% de ses PCs avec Ubuntu Kylin (http://thevarguy.com/open-source-application-software-companies/091515/ubuntu-linux-based-open-source-os-runs-42-percent-dell-pc).
Ou alors une "petite" municipalité passe son parc sous linux et bim, on a notre chiffre.
[^] # Re: bec helloin
Posté par dzecniv . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 3.
oui bien sûr. Va lire l'article, tu comprendras. En fait ils ne font pas (ou très peu) pousser de patates ou de choux.
[^] # Re: my 2 cents
Posté par dzecniv . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 7.
tu t'en fiches des OGM et des graines non reproductibles et de Monsanto qui impose tout ça, comme pour le coton au Burkina Faso, avec des effets désastreux sur l'indépendance des paysans ET sur les cultures ?
c'est plus compliqué, et "les lobbies" sont concommitant de la construction des administrations: cf par exemple https://agone.org/lordredeschoses/lescourtiersducapitalisme/
[^] # Re: bec helloin
Posté par dzecniv . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 5.
Attention étonnamment malgré la présence rassurante de l'INRA l'étude du Bec Hellouin comportent plein de biais qui gonflent les chiffres. Au final, ils ne sont pas si mirobolants: http://www.barricade.be/publications/analyses-etudes/permaculture-maraichage-biologique-un-choix-economiquement-interessant
Par exemple, mais ce n'est pas exhaustif:
[^] # Re: les graines en France
Posté par dzecniv . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 2.
C'est exact, il y a même un livre: http://leseditionsduboutdelaville.com/index.php?id_product=6&controller=product (pas lu, mais j'ai aimé d'autres livres de cette maison d'édition, notamment "Le Ménage des Champs")
[^] # Re: en fait Emacs est très facile. Enfin le lisp.
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 2.
ah là non, je ne suis pas du tout d'accord !
[^] # Re: en fait Emacs est très facile. Enfin le lisp.
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 2.
de nombreux concepts de lisp ne sont pas présents dans les languages aujourd'hui, tels que Python: le modèle objet (méthodes génériques,…), les hooks ("advice"), la méta-programmation riche (les fameuses macros) (Python avec ses décorateurs et "with statements" fait pâle figure), le fait d'avoir une "lisp machine" est énorme, les reader macros (modification du reader, qui lit le code source, pour créer une nouvelle syntaxe), l'inférence de types, créer une image exécutable standalone, désassembler une fonction, plus d'orientation objet, les closures,… (Cf mon commentaire https://linuxfr.org/nodes/112513/comments/1711088)
mais pas sûr que elisp serait choisi sur un autre lisp, oui.
[^] # Re: en fait Emacs est très facile. Enfin le lisp.
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 5.
Emacs en Rust ? Remacs ! https://github.com/Wilfred/remacs où Rust remplace le C, lisp inchangé. (cf mon commentaire plus bas sur lisp VS python)
[^] # Re: en fait Emacs est très facile. Enfin le lisp.
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 4.
Emacs en Rust, mais oui mon ami ! https://github.com/Wilfred/remacs Où Rust remplace le C, mais où le elisp est inchangé. Ce n'est pas un fork, bonne chose à noter.
J'ai écrit quelques paquets elisp, j'ai mon avis sur elisp VS python. Clairement Python est plus populaire, mais il me paraît totalement inadapté au rôle que remplie le lisp. Lisp permet d'avoir une "lisp machine", où on peut évaluer du code dans le process en cours qui devient disponible de suite. En Python, on écrit et on relance l'appli. Elisp et d'autres lisps permettent de définir une fonction qui soit exécutée juste avant, juste après ou à la place d'une autre (les "advice"). C'est ce qui permet d'implémenter les hooks par exemple, et c'est beaucoup utilisé en général. Ça permet d'écrire facilement des extensions à un paquet, sans avoir à le modifier. En Python (ou autres), il n'y a pas ça par défaut. De manière similaire certains frameworks proposent des signaux (pre-save, post-save,…). De manière générale la méta-programmation en lisp est plus riche et complète, de par le module objet, ces hooks, et grâce aux parenthèses (le code est une liste, facile à manipuler), alors que vas-y pour manipuler l'ast de python. Des trucs comme ça.
Plus concrètement, je me demande comment on ferait pour taper du python, sensible à l'indentation, dans le mini-buffer ! Alors qu'en lisp tu regardes le matching des parenthèses.
Enfin notons qu'on peut écrire des extensions qui utilisent en sous-main des paquets python, en l'installation elles-mêmes à l'endroit qui va bien, etc (emacs-traad,…).
Et que Emacs25 supporte les Xwidgets, donc on peut imaginer voir ces trucs plus puissants (encore que, moi je préfère manipuler du texte qu'un widget graphique à la souris).
[^] # Re: Vieux débat (nouvelles réponses?)
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 2.
c'est justement which-key !
M-x which-key-mode
[^] # Re: Vieux débat (nouvelles réponses?)
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 3.
t'as des solutions ici: https://www.reddit.com/r/emacs/comments/3ucnnx/trying_out_spacemacs_without_messing_with_my/ et ceci marche pour moi:
[^] # Re: Vieux débat (nouvelles réponses?)
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 4.
ou tu utilises un mode fait pour le live preview: http://wikemacs.org/wiki/Markdown#Live_preview_as_you_type :)
[^] # Re: Vieux débat (nouvelles réponses?)
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 2.
euh alors ce devrait être des différences superficielles, du genre raccourcis claviers (évidemment) ou moyens de configurer les différents modules en elisp, auquel cas si ça diffère de la doc officielle c'est pas grave (j'ai pas utilisé spacemacs (evil-mode bien sûr !) (mais j'ai un peu regardé sa config) donc des exemples seraient bienvenus).
ça c'est cool ça :) Je rappelle qu'un wiki est ouvert aux contributions et que petit à petit le "noob" construit des pages utiles ;) (la preuve)
[^] # Re: les conventions sur les raccourcis!!!!
Posté par dzecniv . En réponse au journal Participer à l'amélioration de l'expérience utilisateur d'Emacs (c'est facile). Évalué à 3.
c'est sûr, mais on peut s'en sortir je pense: avec which-key, avec un dashboard de bienvenue (https://github.com/rakanalh/emacs-dashboard), avec un smex ou counsel-M-x (https://github.com/abo-abo/swiper) à la place de M-x pour avoir comme une palette sous d'autres éditeurs, et avec des hydras (https://github.com/abo-abo/hydra/) et l'interface à la magit: un "menu" interactif montre les sous-commandes accessibles en une touche. C'est super efficace !