Path: utzoo!attcan!uunet!snorkelwacker!tut.cis.ohio-state.edu!ucbvax!XEROX.COM!lovstrand.EuroPARC From: lovstrand.EuroPARC@XEROX.COM (Lennart Lovstrand) Newsgroups: comp.soft-sys.andrew Subject: Re: Dear Saint Andrew... Message-ID: <0adTPN8B0TlkM4PEF=@zany.EuroPARC.Xerox.COM> Date: 19 Jul 90 18:07:21 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 356 Excerpts from andrew: 17-Jul-90 Re: Dear Saint Andrew... Nathaniel Borenstein@thu (11539+0) > I really love these wish lists. They're always very illuminating for > all concerned. Though I'm no longer part of the Andrew project, I can't > resist commenting about some of them -- especially since a lot of them > ARE things you can already do: > Excerpts from internet.info-andrew: 17-Jul-90 Dear Saint Andrew... > Lennart Lovstrand@xerox. (7062+1) >> I wish text selections would be "pending delete" [ie, automatically >> deleted when a new character is typed] in much the style of the >> Macintosh, Sun, and many Xerox environments. > Personally, I'd hate this, but it would be nice to have it as an option. Yes, please, make it an option. I guess one's preference is very much what one has gotten used to -- many of us who have the other paradigm well burnt into our spinal marrow from extensive use of the other systems. >> I wish I had M-X... > I believe that you do, sort of, using Ness, although the set of things > you can do with it is VERY different from what you get in Emacs. > More likely, though, this complaint is really a lot like many of your > other complaints, which are "I wish it was more like Gnu Emacs." When > you think about it though, the only reason you make these complaints is > that it's amazingly close to begin with. Complete compatibility between > two such different systems is fundamentally very unlikely. I agree, > however, that there are a few places where they could be more > consistent, but here's a little-known fact: EZ has been around longer > than Gnu Emacs! Yes, it is true that I many times wished EZ was even closer to Emacs than it already is (in fact, I even wish that the two were were one and the same program!). EZ may have been around longer than GNU Emacs, but remember that GNU Emacs itself is just a decendent of ITS/Twenex Emacs by the same author. It's changed a lot since then, but I think it's done a pretty good job still of keeping itself remarkably consistent with the original Emacs. >> I wish printing a document wouldn't be dependent on having troff -- most >> of the formatting is already done by Andrew, so why not just produce >> PostScript (or something DVI-like) right away? > I share your wish, but it's a lot harder than you imply. This would be > a major amount of work. Is this really true? It seems to me that getting at least what I see on my screen put on piece paper ought not to require a major effort. For things like footnotes and tables of contents, I can't really tell. >> I wish Messages wouldn't distinguish between operations on the selected >> message and operations on all marked messages. Clearly, one is just a >> special case of the other (and by jove it's confusing to find which >> operations are supported where). > Well, I believed that for a long time, and tried to figure out a way to > make it work. The problem is, one really isn't a special case of the > other, or at least so I finally concluded. What I would now like to > see, instead, would be a notion of "virtual folders" where you could > select some messages and treat them as if they were a whole folder. (I > believe Rob Hagens, at U of Wisconsin, is now building a mailer that > includes this concept.) But wait! If I just look at the operations that are available through the menu stack (deck?), most of the ones applicable to individual messages also have its twin in the "marked messages" section. Only the ones in italic below seems to be solely applicable to either one or the other (or neither). So it seems to me that one could at least write a set of substitute functions that would check wether or not any messages had been marked and then invoked the appropriate single/multi messages function function instead. Maybe you were thinking about something else, though? This Message Send/File Mrkd Marked Msgs Forward To File All Into Next Delete/Undelete Resend To Copy All Into Previous Restore Draft Append To Folder Reply to Sender Delete All Reply to All Append to File Append To File Undelete All Read Mail Descramble Reply to Senders Print All Fixed Width Reply to All Send/Post Message Clear Marks Print Resend All Delete Window Count Marks Mark as Unread Except All Quit >> I wish "Insert Header" would work even when the caret is in the body window > Doesn't it? Sounds like a trivial bug to fix... It probably is. And while on the subject of small fixes (but in a totally different context), how about giving feedback on when doing dialog box selections with the mouse? As it is now, when I press a mouse button over a "choice box", no feedback is given on which item I'm selecing. If I select it from the keyboard, though, it becomes inverted inpreparation to a confirmation with the RETURN key. It would be nice if "mouse button down" would give the same feedback. >> Printing hidden headers as footnotes is a nifty idea, but I wish it >> could be turned off -- and when on, that they wouldn't be >> (left-and-right) justified! > I don't know about the justification, but it can be turned off -- there > are preference options for this. I think they're even documented. > *.usefootnote:no -- will cause the headers to all show up at the top of > the page. > *.printminorheaders: no -- will cause the headers that would otherwise > be in footnotes to simply be omitted. That will do nicely, thanks. >> I wish Messages et al would allow more than just RFC822 addresses -- >> even though my mail backend (sendmail) allows me to send both XNS and >> UUCP formatted addresses, Messages insists on validating them as >> "user@domain". [Is there a way to turn this off?] > There is, in principle, at least for UUCP, but I just checked it and it > seems to be broken. I'll look into it. Meanwhile, you can use a trick > like this one. I assume your site has some full domain, which is > specified to Andrew as ThisDomain, and that there are shorthand versions > of it that Andrew doesn't know about. You can use this to trick the > system into thinking mail is external. If your site is "foo.bar.baz" > and "foo" is a valid nickname that Andrew hasn't been told about, then > even if "x!y" doesn't work, "x!y@foo" should work fine. Yes, but that work as well with XNS which has addresses looking like "User:Domain:Organization" (which can include spaces). Sending something to "Jane Doe:Research:ACME@localhost" will cause AMS to choke with a syntax error, and putting the local part in double quotes will make sendmail spit it back with unknown recipient. Ideally, I would just like be able to write "Jane Doe:Research:ACME" and have sendmail do the validation. Having said that, I'll have to agree that it's very nice to have the UA do the validation before posting the message, but what if we can't agree on what a proper address looks like? Really ideally, then, I would like to be able to "teach" AMS how to do address validation for a number of different protocols -- and local versions of the aliases database, etc. Maybe there already is a way of doing this using the White Pages, but I haven't had time to figure that out yet. (Buy, AMS is even more complex than sendmail! ;-) >> I wish AMS would properly retain the envelope sender as found in the >> From_ line when retrieved from the user's mbox in /usr/spool/mail. As >> it is now, at least the "X-Andrew-Authenticated-As" header is prepended >> to the message, pushing the "From " line down into the body of the >> headers (where it at least should be changed to a Return-Path: to >> belong). > I've suggested a similar idea in private mail to people at the ITC; I > don't know if it's coming out as a patch or not, but it's probably a > good idea. I first tried to track down all the places where a new header was added to the message and make sure it was added after the From_ line. After having patched two or three different places with no noticable result, I finally gave up and made cvtold.c turn the From_ line into a Return-Path: header instead. [Patch available on request] One thing puzzled me, though. Std UNIX stores the envelope information in the From_ line, but where does AMDS put it? Or maybe it doesn't keep any? >> I wish AMS wouldn't bluntly remove any user-supplied From: headers -- >> they're perfectly legal and perform the useful task of indicating a that >> the indicated sender is different from the (claimed) person sitting in >> front of the keyboard. > I believe this is NOT perfectly legal -- what you want here is a > "Sender" header, which I *think* it will let you add. "Reply-to" is > also perfectly legitimate. Nope, it's the other way around. The "From" address may be specified by the UA, and if not authentic, must be supplemented with a "Sender" by the mail system, indicating the authenticated sender of the message. See RFC822 section 4.4.1 and 4.4.2. >> I wish AMS wouldn't barf on a subject-less message (ugh!) > Yeah, this was a value judgement. Personally, I hate getting mail > without a subject. Think of this as my personal plea for better > network etiquette... Hrrm, well, some messages don't actually go to people but to network archive servers, etc, where a subject usually is very optional. Besides, IMHO, legislation is not the right way to promote ethics... >> I wish there would be a (one) consistent extension language, not ELI >> here and NESS there etc. > Not to mention preferences, init files, and so on... Yup, and you aren't alone -- just look at X (or don't depending on how sensitive you are)! >> I wish the code wouldn't contain quite so many magic constants and >> obscure defensive coding. > Magic constants are bad. Defensive coding is good, however, so I find > part of this complaint quite cryptic. Personally, the more I look at > source code for standard UNIX utilities, the more astounded I am that > anything ever works at all. Well, I guess this is something up to discussion, but as I see it, the more I can trust on some underlying functionality to do the job, the less I need to think about all the possible ways it could go wrong. This surely is a good thing in 99% of all cases. To make a naive analogy with TCP and UDP: The very reason for TCP's existence is that it's (supposedly) reliable, making it possible for the programmer to largely forget about possible failures on the network. When it comes to Andrew, there seems to be an awful lot of code there which solely is concerned with the success or failure of an AFS call. This has the effect of obscuring the true function of the code and making hard to understand, especially for someone outside the original development community. Even if there are many ways something may go wrong in a distributed FS environment, it seems to me that trying to make the applications programs compensate to compensate for this would be to attack the problem on the wrong level. From a user's standpoint, I agree that defensive coding is good if it makes the system more reliable. I only wish that it could have been confined to just a very few key places. > Gee, that was fun. -- Nathaniel The pleasure was all mine, sir... Excerpts from andrew: 18-Jul-90 Re: Dear Saint Andrew... Craig_Everhart@transarc. (5162+0) > Adam and Nathaniel have filled in lots of good answers (including both > ``here's how to do that, I think'' and ``here's a partial answer to your > wish''). >> Excerpts from internet.info-andrew: 17-Jul-90 Dear Saint Andrew... >> Lennart Lovstrand@Xerox. (7062+1) >> I wish I wouldn't have to type M-@ to select a region [for further >> kill-region, etc.] -- it's really confusing when moving between ez and >> emacs. > Simple--don't use emacs. (:-)) I wish I could... >> I wish backup and checkpointing could be compatible with gnu emacs, ie. >> #foo# for checkpoint and foo~ or foo~n~ for old versions. > If ATK and Emacs could agree on semantic points.... You mean things like copy versus rename etc? Yeah, right. >> I wish there was support for setting tab stops! [What no tabs??! You >> must be joking!] > Right. But look at what named tabs did to Bravo, in the old days: made > it almost slow enough to be unusable. Huh? But that was on ye olde Alto, yes? So why should it be impossible (or even hard) to have efficient tabs on UNIX workstations today when all the Mac apps has it on smaller machines? If Andrew is beginning to show it's age, maybe it's time to perform a substantial rejuvenation. >> I wish Messages would show the messages in chronological order by the >> Date: field -- as opposed to in the order they arrive, since messages >> frequently get arbitrarily delayed during the transport and thus arrive >> in a jumbled order. (Or is this already supposed to happen? But I have >> messages that > Sigh. You can re-sort your own folders by evaluated-Date: header value. How? (Except for writing my own date parser and copying the messages from one folder to another and running cui's scavenge.) > AMS doesn't at present maintain more than a high-water-mark within a > folder saying what messages you've seen, so messages are, by default, > sorted by arrival time since that's the only way AMS can show you the > ones you haven't seen yet. (Yes, it could micro-optimize the case where > it's appending several messages at once, and sort those, but that's > small payoff since it couldn't sort new messages to a spot before the > last old message.) Substantial rewriting would have to take place to > get this to work right. (The date parser doesn't handle time zones > properly, either, so you'd get somewhat anomalous results.) I'm confused. Do you by "seen" mean the same as "read"? Because I thought each individual message was flagged when I read it, which would allow me to have "gaps" of unseen messages in a folder. At least, so it appears. >> I wish Messages et al would allow more than just RFC822 addresses -- >> even though my mail backend (sendmail) allows me to send both XNS and >> UUCP formatted addresses, Messages insists on validating them as >> "user@domain". [Is there a way to turn this off?] > UUCP addresses should work a little bit, if you have the appropriate > AndrewSetup option on. You might have asked for x.400/x.500 addresses > as well. Good idea. Yes, please. And an actual X.400 mail transport service, and a dito X.500 mail directory service, and... ;-) >> I wish AMS would properly retain the envelope sender as found in the >> From_ line when retrieved from the user's mbox in /usr/spool/mail. As >> it is now, at least the "X-Andrew-Authenticated-As" header is prepended >> to the message, pushing the "From " line down into the body of the >> headers (where it at least should be changed to a Return-Path: to >> belong). > Yes, this should be supported. If AMS thinks it's in an RFC822 world, > it should convert the UUCP-ish envelope-from information to what it can > understand. Right, although a "From " line doesn't imply anything about UUCP -- it's just the convention for separating messages in the user's /usr/spool/mail file. >> I wish AMS wouldn't bluntly remove any user-supplied From: headers -- >> they're perfectly legal and perform the useful task of indicating a that >> the indicated sender is different from the (claimed) person sitting in >> front of the keyboard. > They're legal only if they work for a remote user. (At a college > campus, it's been important for AMS to try to keep From: headers > reasonably honest.) AMS might well have to add a Sender: header if the > From: header wouldn't work, or maybe add a Reply-to: header as well. No, no, please don't add any "Reply-to" headers automatically! Well, or at least make it user-optional. Some Xerox-internal mail systems insist on adding "Reply-to" headers when they really have no business doing so, so it's a bit of a sore spot with me. > Thanks for the list! It's good to go through it. > Craig Thanks for taking the time to answer it! And the same goes to all you other people who answered. It's clear to that you take pride in your creation (and rightly so), but it's even more encouraging to see that you're open for suggestions and improvements. Thanks again, --Lennart [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.]