>>> What I'd like to be able to do is to browse, but as I am browsing, to >>> ke$ >> It would help readability if you'd avoid paragraph-length lines. > I love plaintext email aside from just this one issue. But if u > insist.
Oh, I don't insist. If you don't care how easy it is for people to read your mail, don't bother. But then don't be surprised if people drop your mail instead of going to the trouble needed to read it. (Depending on the reader's mail setup, that could be anything from zero to substantial.) > For me, readability is about not breaking sentences at arbitrary > places. :-( I can understand that. But breaking sentences at arbitrary places is not what I'm talking about; doing that would also lead to (a different flavour of) unreadability. The traditional thing is to break somewhere shortly before 80 characters - not arbitrary, but chosen to fit traditional terminal sizes and, more recently, default window sizes. > Screen real-estate too. My line length is a whopping 256 characters! > :-D I can get 320 characters width if I want it. I don't. I've tried it and find that finding the correct line to continue reading at after a line break is troublesome enough to break the flow of reading; 80 columns is long enough to be reasonably space-efficient but short enough that I (and, I gather, most people) can visually jump from the end of each line to the beginning of the next with little-to-no trouble. It also is roughly the line length of normal typeset text, too. I just now picked up a handy book and counted characters; while it's not totally comparable, because it's set in a proportional font instead of a fixed-width font, the sample line I picked had about 70 characters. (I speculate that characters are not the whole story; angle subtended may be important too. At least with the font I use, the lines I generate subtend about the same angle for me as a typical book line.) > This arises from using a 5x8px bitmap font on a 1280x800px display. > ;-) 6x13 and 1920x1080 in my case. But I don't usually use windows spanning the full width of the display. (I've got a 5x8 font, but it's just hard enough for me to read that I find I prefer the 6x13 one.) >> (If you want the recipient to reflow the text, RFC3676 is your >> friend.) > Yes, reflow is what I'm after! I've heard there was that other way. Other? Other than what? > Sadly,my plaintext-loving email client does not seem to support > RFC3676. :-( Surely it can be configured to add arbitrary user-specified headers? That should be enough to use 3676 format=flowed. Or you could ignore the issue and write off anyone for whom reading long lines is difficult. > At least I don't see how to enable it. For now, I'll reflow manually > for you. Like this! Thank you! > Even though I know email can support line lengths of upto 1024B. Yes and no. What "email" can support depends on what layer you're talking about. For SMTP, RFC 5321 says 4.5.3.1.6. Text Line The maximum total length of a text line including the <CRLF> is 1000 octets (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions. But (a) as that says, the limit may be increased by certain extensions and (b) arbitrary-length lines may be transferred by encoding them suitably (but if you're using MIME, which you normally will be if you're encoding mail bodies, see the MIME specs; there may be line length limits on text portions even when encoded - I can't recall offhand what, if anything, the MIME specs say about that). > I limit my paragraph length to just short of this,allowing 4 some > quotation. There's widespread support for rewrapping this, so what's > the problem? :-/ The problem is that not everybody wants to have to tell their UA to override the sender's lack of "please reflow" marking. (Email is used for more than just running text, including various things for which reflowing constitutes horrible mangling; always reflowing is a Bad Idea for general-purpose use.) >> For the archiving, the simplest thing that comes to mind is to set >> yourself up with a local proxy [...] > It has crossed my mind but I don't know how to, or which proxy is > best. I don't either. I don't use the Web enough to have had occasion to set up a proxy, nor have I had occasion to want a proxy that does that. >> For breadth-first browsing (the queue-of-URLs thing), > Oh cool, you've identified this exactly the same way that I have! :-D :-) > That Breadth-First Search can cope with infinite trees, & is > queue-based. Well, _can be_ queue-based. I've done breadth-first search often enough in ways that do not constrain visit order within a depth, but do ensure that each depth is finished before starting on the next. > Don't get me wrong - I love stacks too! Sure. Use the data structure appropriate for the task. >> I wrote a lynx wrapper that could do it, but it makes the "look at >> this URL later" rather more complicated than would be ideal. > I'd be very interested to know how this can be done from a wrapper. > :-) My wrapper - tablynx, I call it - runs lynx. If I have a link I want to look at later, I use = to display the link-to, copy it, type ^P (^Z for most people, but for historical reasons I use ^P) to suspend lynx, tell tablynx to record the URL, paste, and resume the lynx. As I said, rather more work than would be ideal, but workable for low-volume workflows. Could be improved by hacking on lynx to add both integration with tablynx and a new keystroke command. > It is the hackery on Lynx where I'd be wholely out of my depth. :-/ > If you could do that part it would greatly enable my script-based > hackery. Well, I probably could. But I use a rather old lynx (2.8rel.2) and use the Web so seldom I see little-to-no reason to either switch or put effort into adding things to it. >> about the time I might have, the Web collectively decided to insist >> everyone speak HTTPS, which I refuse to put up with, so I don't use >> the Web much any longer. > I'm in 2 minds about HTTPS. :-/ On one hand I see the benefits. Oh, I see nothing wrong with supporting HTTPS if you want to sink the resources into it. What bothers me is refusing to serve content over HTTP. These days, most webservers seem to refuse to serve anything over HTTP except redirects to HTTPS. > I also know how to configure a website that passes 100% at > Internet.NL . Dunno what that is; http://www.internet.nl/ hands me a redirect to HTTPS, and these days I doubt there's anything anywhere _except_ the Web describing what it does. >> /~\ The ASCII Mouse >> \ / Ribbon Campaign >> X Against HTML [email protected] >> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > Oh wow, I've not seen a ribbon campaign as ASCII before -- nice! :-D > I'm aware of the Any Browser campaign & JS-free, but this one's new > to me! Anti-HTML-email has nothing to do with browsers; that's kind of the point of it: plain email shouldn't need an HTML renderer. (Sure, if you're specifically mailing around HTML. But that's no different from needing a C compiler if you're mailing C code, or JPEG support if you're sending JPEGs, etc.) Indeed, my SMTP server is supposed to reject HTML-only mail, and it mostly does ("mostly" because I think I have seen reason to think there's a bug or two). > Relatedly,I tried 2 start th counterpart 2 HTML email Wikipedia > article. But sadly my page on plaintext email got shot-down and > disposed-of. :-( I am not going to try to defend Wikipedia on that (or any other) point. I use Wikipedia only rarely and (since they have drunk the "force HTTPS on everyone" koolaid) only from work machines. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
