Raul Unfortunately the line length can grow (beyond the limit of perhaps 64-70 allowed) by the addition(s) of "> ", sigh.
Most mail agents wrap like you said at some predetermined value. One can wrap the whole in html's pre tag which is relatively simple - but tricking or creating clients to use that convention is much harder. Another convention is in Markdown: where a long line is only ended with two spaces. A reader could be made using that convention: It would run together all lines not demarked by two LF's or two spaces. Unwrapping the others. It would have to rid unused "> "'s - which might be sad if they are needed, though escaping, in that rare case, is an option. Markup symbols are also treated badly by variable width fonts, which are the norm for most readers. A wrap in a pre tag could make it all constant width, much much better for the symbology of J like languages. i do like the idea of piggybacking on internet wide proto-conventions... It makes for the possibility of reinforcing feedback loops amongst communities. Markdown is good, though its href capabilities are a bit convoluted compred to my preferred ~ method: ~ denotes a path, usually a file at a (default) location. A default TLD may be set with a ~, and dates, times, ftps, emails etc... If the reader client were made facile enough it could be generally used, even if not the vendors own. If it spoke SMTP possibly it could speak to multiple vendor servers... if it had r/w access to their inbox at a raw level. greg ~krsnadas.org -- from Raul Miller <[email protected]> to Beta forum <[email protected]> cc Chat forum <[email protected]> date 11 January 2011 14:09 subject Re: [Jbeta] mailing browser On Tue, Jan 11, 2011 at 4:24 PM, greg heil <[email protected]> wrote: > "watch out for line wraps"... almost a mantra on these fora;-) Is there a way, perhaps using "mark down", to get around that? In the general case, no -- each mail client implements its own rules. That said, if you keep your lines short enough (64 characters wide should be short enough, 70 might be short enough), no mail client should wrap the lines. The problem, here, is that discovering line width often means using some editor other than the one provided by the mail client. Another possibility involves wrapping the logical line in something that would recover from extraneous line breaks. For example: ".0 :0-.LF LINE GOES HERE ) However, this is bulky and distracting. Another possibility involves creating a "J line-end indicator" which would allow a script approach that ignores the email introduced line ends. To my knowledge no one has ever bothered with such a thing. There may be other possibilities. -- Raul -- from greg heil <[email protected]> to Chat forum <[email protected]>, Beta forum <[email protected]> date 11 January 2011 13:24 subject mailing browser "watch out for line wraps"... almost a mantra on these fora;-) Is there a way, perhaps using "mark down", to get around that? Generally it seems most email client apps seem to mess up the writers intentions:-(( Perhaps there is a way if only in our fora (not necessarily the wider word of emailed communication) to move beyond that into at least a modicum of formatting, without the heaviness of proprietary "solutions". Just putting the pre tag around an outgoing post can help tremendously. Yahoos! online rich text mailer is very good. Is there a way to get something like that working for incoming and outgoing mailings? On the outgoing end i would like control over a raw html'd post. On the incoming i would at least like to avoid the "line wraps" so frequently mentioned, and avoid the "alternative parts"! The deficit may be at the posting client agent end:-| Perhaps a custom posting client agent could me modeled in j7? If it can sit in the JUM, anyone with an account, anywhere can post markups (or downs). A reader client agent likely needs to sit on gigabytes of secure data and thus likely off the JUM. The poster only part, only needs the inbox, or about 5 lines of header info for each post - for correctly linked replies. Or a way to include appropriate headers. Perhaps bridge apps between receiver and poster agents. Is there an existing a solution that suffices? i (and others?) have been frustrated for decades by this state of affairs. The whole may be a snarled mess, but at least, with conventions or more, it could be ameliorated within a semi isolated ecosystem. greg ~krsnadas.org ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
