bc@cyb-eng.UUCP (09/18/86)
> [...] > This clearly makes it illegal for SMTP mailers to expand tabs. On the > [...] > This clearly suggests that mail-agents expand tabs before submitting > them to mailers. > > Meanwhile, if you use tabs in formatting such that the width of a tab > stop affects the content of your message (e.g., in drawing pictures), > other people will get what you deserve. > > joe I admit right off that I have little experience with mailers. One point I feel a layman can legitimately make, however, is that: If I have software on my end that knows what a tab means within a given context, and if I want to mail this file to someone else whose software is also aware of the context and of the meaning of tabs within that context, I think I should be able to do this without the mailer screwing up the situation. Perhaps this is obvious and is no problem, in which case, please do not followup to this article of concern.
jc@cdx39.UUCP (09/19/86)
> My system (a Xerox Star) displays mail in a proportionally spaced font, > making all diagrams hard to read without changing the font. > I'm not sure if this is a bug or a feature, however. > > In general, I think that having the mailer expand the tabs would be a bad > idea. There might be reasons for wanting the tabs in the message and it shouldn't > be impossible to do this. For those of us using many Unix systems, there is a very good reason. I keep finding myself helping people who can't get make(1) to work, and can't see anything wrong with their makefiles. Invariably, what turns out to be wrong is that something has expanded the tabs into spaces. Most (but not all) versions of make *require* that rule lines start with a TAB, and spaces aren't acceptable. Anything that expands tabs will destroy a makefile. Recently, someone installed a great new editor on a lot of systems around here, and it expands tabs to spaces....
mark@cbosgd.ATT.COM (Mark Horton) (09/20/86)
In article <8609181416.AA15967@SALLY.UTEXAS.EDU> bc@cyb-eng.UUCP writes: > If I have software on my end that knows what a tab means within > a given context, and if I want to mail this file to someone else > whose software is also aware of the context and of the meaning > of tabs within that context, I think I should be able to do this > without the mailer screwing up the situation. I think this is the heart of the matter: whether the implementors do or do not intend it, people use electronic mail to transfer files. Nobody expects mailers to leave binary files alone, so they use uuencode or a similar method to make them mailer-safe. But my experience is that if a file is plain text (and most people seem to include tabs in this definition) they don't bother, they just mail it. No amount of user education is likely to change this. From this I conclude that (1) mailers, including user agents and transfer agents, should leave messages alone as much as possible when transporting them. (2) people mailing formatted documents should expand tabs first, or else be willing to put up with ragged displays if the person they are sending them to has different tab settings. (3) Everything is fine currently, except for Multics, which (a) has unusual tab settings, and (b) expands tabs in the mailer. Mark