3 ms·
Neat! I used to be a kernel maintainer, and had a similar setup going inside emacs with gnus, and dvc-git commands bound to keys to apply patches. Here's an ol
by cjbprime 7y ago
Neat! I used to be a kernel maintainer, and had a similar setup going inside emacs with gnus, and dvc-git commands bound to keys to apply patches. Here's an old blog post about some of it:
https://blog.printf.net/articles/2010/10/04/git-patches-in-gnus/ https://blog.printf.net/articles/2010/10/04/git-patches-in-g...
Gnus was too slow, but worse, emacs is single-threaded, so e.g. polling for new mail in the background blocked the rest of the editor while it happened. I never understood why it was impossible to have any kind of multithreading in emacs.
- ddevault 7y agoHey, would you mind writing up some details about your email setup for kernel work to sir@cmpwn.com? I'd like to understand more email-driven workflows, especially from kernel maintainers, to guide aerc's design.
- cjbprime 7y agoHm! I can't think of much to add, except.. the next thing I would've worked on might've been to integrate a client for https://patchwork.kernel.org/ https://patchwork.kernel.org/ to keep it in sync and mark patches there as handled.
- ddevault 7y agoThanks! I wonder if you've seen my work with mailing lists on sourcehut, by the way? https://sourcehut.org https://sourcehut.org I'm working on a replacement for patchwork. Here's an example of a thread which was rendered with my tool, which is just generated from organic mail threads without extra human intervention: https://lists.sr.ht/~philmd/qemu/patches/5556 https://lists.sr.ht/~philmd/qemu/patches/5556 If you have more feedback or thoughts around this, I'd love to hear it too :)
- ajdlinux 7y agoA Patchwork client (well, a tool that does some of the more useful patchwork status updating, it's not a full client as such) for notmuch, which has a number of kernel dev users: https://github.com/stewart-ibm/pwnm-sync https://github.com/stewart-ibm/pwnm-sync
- c256 7y ago> I never understood why it was impossible to have any kind of multithreading in emacs. There are various ways to do multithreading in emacs now, but the answer to your question is usually “there’s a lot of existing elisp that isn’t thread-safe”, and that’s still kind of a problem.
- infiniteseeker 7y agoI’m still a novice functional programmer so this may be a dumb comment but I thought a lisp would be more thread safe due to immutable data structures.
- PyroLagus 7y agoNot all fp languages are purely functional, and certainly not all lisps. In fact, the only lisp that I'm aware of that focuses on immutability is clojure. Granted, many lisp programmers may decide to keep their functions pure, but it's rarely enforced.
- ncmncm 7y agoLisp is not a functional language. Or, not an obligate-functional language. I.e. you can do functional if you like, but where it becomes a PITA, you can just assign. Because of that, many optimizations possible in obligate-functional languages are not safe. Because of that, you sometimes need to do your own such optimizations, non-functional-wise. But it is still easier to get fast code than in an obligate-functional language, because in the latter it is indefinitely hard to predict where such optimizations, where permitted, would actually happen; and in some cases they are not allowed anyway. The tradeoff is that in Lisp (as in other imperative languages) you have to do them yourself where you want them. But you can choose to do them only in hot paths, a tiny fraction of your code.
- bhaak 7y agoI "solved" this by having a separate emacs instance where I'd do mail and usenet. So far, Gnus is still the best mail client in a terminal (that you can have the same instance in a tty and a X11 environment is just a bonus). Aerc looks interesting but then there's the ugly truth that I do much less mail than I used to do 10 years ago. So I probably won't switch even if it's looking really sexy.