The Maildir is synchronized to multiple MDAs by OfflineIMAP, a command line program, which I set up to retrieve the IMAP passwords from an encrypted file using auth-source.el by execing emacsclient. To provide an example, I use mu4e as an email client and reader, which uses a separate process running mu to operate on a Maildir. "Write programs to handle text streams, because that is a universal interface" is the reason why Unix utilities do not integrate well. Emacs is much better at "Writ programs to work together" - Emacs extensions usually work with each other without any extra effort, and deep integration is easy to achieve. A lot of the time "Write programs that do one thing and do it well" really means "I don't understand the difference between a procedure and a program." It is much easier to write procedures than it is to write programs, and it is often easier to turn a procedure into a program than vice-versa ( emacsclient does the former especially well). Emacs falls down with images and navigating modern webpages though (haha modern anything written in my lifetime), so I use a browser like everyone else. Eg, at the moment I'm writing a comment for a website - if I only viewed sites like Hacker News (mostly text reading and editing) then I would 100% end up doing it from emacs. The secret is that many tasks involve 60% editing text and it then starts to make sense to implement the 40% in an environment where your heavily customised keyboard shortcuts all work. I must admit, the advantages aren't really there for me on this one, I prefer stand alone viewers. Has me stumped, although sometimes when I write documents that are going to be emailed as a pdf I'll use emacs and it makes a lot of sense to preview in place as I go. I can see a lot of utility in a stand-alone calendar program if the workflow you want isn't based on text, though. If this is your workflow, again it makes more sense to implement from a text editor (because the "calendar" is really a parsed text file and maintaining the text file is what the user works on). This one is pretty workflow sensitive, but Org Mode encourages a very holistic approach of writing everything related to a project in one file, then parsing the file for dates and creating a calendar. Especially for mostly-text emails or emails discussing, say, code. From this perspective, a text editor implementing email makes a lot more sense than an email client implementing text editing. That means sed, vi, emacs, and a few other tools that are old as dirt but rock solid.One view of email is really reading and composing lightly formatted text with a "send" option. And those tools are not Visual Studio, Eclipse, IntelliJ, or whatever other fancy tools you want. When you're in that scenario you need tools that work there in those old low memory, text-only, low bandwidth, low cpu environments. Sometimes you're on a remote terminal to a text only interface, maybe a slow serial interface, and those fancy tools aren't available. Let's have the best of today and the best tomorrow can offer. There is no battle, no need for attacks, there is room for all to improve and for any other entrants that can join. Let's absolutely keep growing and expanding the list of amazing tools out there. Sure, if you're on your main work computer feel free to fire up whatever editor you want. For example, for small things I use Vi(m), but use Emacs for larger/longer edits - or things I want to write/record a macro for, but not necessarily write a separate Perl / Ksh script, etc. As long as whatever editor you use does what you need it to do, especially in a way that's comfortable and helps you be productive, who cares which editor it is. More to the point, any "attacks" are unnecessary.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |