I just requested of a friend that they reconfigure their email client to send email with a text width <=78 characters, so that when I quote relevant portions of their emails they can have every line indented and prepended with ">" without the formatting getting all screwed up. How 1990s is that? Why haven't we come up with a decent way of indicating quotes which is readable for people using plain-text, easily formatted to be pretty looking in serious mail clients, and doesn't depend on the terminal width being 80 columns? For that matter, why do we still send email with hard breaks somewhere in the 70th-78th column, rather than only using hard breaks for paragraph separation and allowing the reader's client to word-wrap nicely for readability based on the size of their actual view? Why did GMail, last I checked, fuck it up so that in their default configuration, if you do internal quoting rather than top-quoting or bottom-quoting, the quoted text is completely indistinguishable from the content of the new email?
Our tools suck. Here's what *should* happen:
* Our mailers should smoothly word-wrap the text of incoming emails when "lines" are longer than the width of whatever they're using to display the text. The cost in processing power is really negligible in today's world (and is being incurred at the sending end now anyway).
* We should all be able to assume this is going to happen, and thus send email which only uses whatever newline character is being used when it's necessary to denote something meaningful.
* Our mailers should do something to distinguish quoted text from the rest of the email body (every mail client I've used in the last 5 years has done this one way or the other).
* We should be able to assume this is going to happen, and thus be able to come up with a nice, simple, universal new standard for quoting text which degrades reasonably for crappy clients but doesn't make replying using internal quotation difficult/annoying. Actually, if we stop using hard breaks at the sending end in favor of word-wrap at the receiving end, the current standard of prepending "> " should suffice, since we no longer have to worry that adding characters to a line will screw up its formatting in the average case.
Have I just misconfigured mutt and vim and consequently missed out on the last 10 years of development? I'll have to look into that; it wouldn't be the first time it had happened. However, we *are* still including hard breaks in our email, and stripping out someone's hard breaks is dangerous (they might actually indicate formatting).
Along the same lines, in writing this post I need to type in crap like "<". What's with that shit? The HTML team made a really crappy choice when deciding which characters should have special meanings and what we should do when we want to use them the normal way. Why can't I escape special characters with a backslash, so it's "\<" like in every fucking other thing I use, is trivial to type (just hit backslash before what you want), and is easy to remember (just hit backslash before what you want). Fuckers. I may have to figure out how the JLJ preprocessor works so I can extend it to do exactly that, because this crap is stupid.
(The formatting on this is probably going to be FUBAR because I can't be assed to enclose every paragraph in <P> tags like I usually do, and I haven't yet learned how to use this tool if I'm not going to send true HTML. I should do that sometime; it's a nice tool in general.)
BTW, how do I get vim to show text as word-wrapped without inserting actual hard breaks in some form of text mode? I don't need a newline every 78 characters when I'm writing LJ posts, but it's much easier to read what I've written if the visual lines wrap at word boundaries instead of at the edge of the terminal, and if up/down go by the visual line rather than the real line. I'm sure someone's written something to do this and I just haven't found it yet.
Please don't tell me to switch away from the terminal. The terminal is exceedingly useful in a lot of ways, and by now we should have evolved our tools to take advantage of its advantages without putting us hostage to its apparent limitations (apparent because they're only limitations if we're lazy programmers).