3 ms·

Data point: I can't stand gnus. It was a paon to config, and I never got RSS working. (mh-e is nice, though.) Building a mail system into a single-threaded tex

Data point: I can't stand gnus. It was a paon to config, and I never got RSS working. (mh-e is nice, though.) Building a mail system into a single-threaded text editor seems a bit silly to me...

asjo 17y ago
Building a mail system into a single-threaded text editor seems a bit silly to me... I have never encountered a system that could replace Gnus, though. What do you use to read nntp, email and rss in a coherent interface?
- silentbicycle 17y ago
  Firefox, actually. (Which is the new program-with-a-million-extensions.) I just use gmail for mail these days, though I would probably go back to mh or mutt if I started using a client program again. I've never found an RSS reader I've been satisfied with, though. I was working on one at one point that had an interface like mh, but I haven't gotten back to it in a while.
sielskr 17y ago
Building a mail system into a single-threaded text editor seems a bit silly to me... Why's that? The (not gnus) mail system I use on Emacs will hang the Emacs process for a few seconds sometimes when I hit send while the Emacs process talks to my ISP's mail server, but that is the only way the mail system's single-threadedness ever really bites. When I check for new mail on my ancient Pentium III system, the Emacs process hangs for less than a second or 2 usually. Those delays are nothing compared to the time I waste waiting for Firefox to do something.
- silentbicycle 17y ago
  I prefer the Unix (and Erlang!) model of having lots of independent processes communicating, and individually serving a specific function. While I really like using Emacs's buffer-based environment as the common interface (such as working in a shell buffer and being able to edit results), I'm not convinced that adding more and more functionality to the same process is a good idea from an architectural standpoint. (And unlike Firefox, GNU Emacs doesn't even have good namespacing / isolation for its extensions, hence all of the variables with package-variable-name-with-several-parts names.) Plan9's ACME preserves most of what I like about Emacs, but it's mouse-chord-based UI is a dealbreaker for me.

Data point: I can't stand gnus. It was a paon to config, and I never got RSS working. (mh-e is nice, though.) Building a mail system into a single-threaded text editor seems a bit silly to me...

asjo 17y ago

Building a mail system into a single-threaded text editor seems a bit silly to me... I have never encountered a system that could replace Gnus, though. What do you use to read nntp, email and rss in a coherent interface?

silentbicycle 17y ago
Firefox, actually. (Which is the new program-with-a-million-extensions.) I just use gmail for mail these days, though I would probably go back to mh or mutt if I started using a client program again. I've never found an RSS reader I've been satisfied with, though. I was working on one at one point that had an interface like mh, but I haven't gotten back to it in a while.

sielskr 17y ago

Building a mail system into a single-threaded text editor seems a bit silly to me... Why's that? The (not gnus) mail system I use on Emacs will hang the Emacs process for a few seconds sometimes when I hit send while the Emacs process talks to my ISP's mail server, but that is the only way the mail system's single-threadedness ever really bites. When I check for new mail on my ancient Pentium III system, the Emacs process hangs for less than a second or 2 usually. Those delays are nothing compared to the time I waste waiting for Firefox to do something.

silentbicycle 17y ago
I prefer the Unix (and Erlang!) model of having lots of independent processes communicating, and individually serving a specific function. While I really like using Emacs's buffer-based environment as the common interface (such as working in a shell buffer and being able to edit results), I'm not convinced that adding more and more functionality to the same process is a good idea from an architectural standpoint. (And unlike Firefox, GNU Emacs doesn't even have good namespacing / isolation for its extensions, hence all of the variables with package-variable-name-with-several-parts names.) Plan9's ACME preserves most of what I like about Emacs, but it's mouse-chord-based UI is a dealbreaker for me.