https://noblogo.org/sknob/faites-quelque-chose
| Articles | https://sroccaserra.fr |
| Code | https://git.sr.ht/~sroccaserra/ |
| Code | https://codeberg.org/sroccaserra/ |
| Articles | https://sroccaserra.fr |
| Code | https://git.sr.ht/~sroccaserra/ |
| Code | https://codeberg.org/sroccaserra/ |
@romeu Thank you, I'm trying it for a few weeks.
I used Emacs a lot around Emacs 20, I loved using ELisp.
Then I like Vim very much as well, the default bindings are awesome for me.
But I'd like to refresh the default Emacs keys, so EShell is a good excuse. And I'm curious to explore the mix of shell + ELisp (?)
I do prefer @jbrains’s usage of “complication” rather than “complexity”, BTW.
If you haven’t seen this talk, entitled “7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development”, click:
Hi @romeu, you said some time ago that you use eshell as your main shell. Do you have some tips to share, or specific reasons to recommend it? I would be interested.
Also, how do you start it? Do you have Emacs open anyway, so you start it from there, or do you have a specific startup script to start it as a separate app?
J'ai apprécié cet article de @jbrains. Quand on simplifie du code, paradoxalement il y a un risque de le rendre moins familier (ce n'est plus comme avant, ce n'est plus comme on a toujours fait). Ça peut être une raison d'accepter de ne pas simplifier. Mais si on ne prend jamais ce risque, on passe à côté d'opportunités de simplifications. Compromis... Je trouve intéressant d'avoir ça en tête collectivement.
=> https://blog.jbrains.ca/permalink/a-central-conflict-in-readable-code
Sometimes we struggle getting buy-in from others about improving our software designs. I think I know one of the ways that happens:
https://blog.jbrains.ca/permalink/a-central-conflict-in-readable-code