Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!THUMPER.BELLCORE.COM!nsb From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) Newsgroups: comp.soft-sys.andrew Subject: Re: Dear Saint Andrew... Message-ID: Date: 17 Jul 90 21:15:25 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 255 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. > 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! > I really, really wish there was an UNDO in ez &c. Ditto. About a year and a half ago, we came up with a scheme for a "next generation" toolkit that could do an arbitrary undo within the distributed control structure of ATK-like architectures. (Think about doing a sequence of operations, each with a different inset, and then expecting successive "undo" operations to work right.) This exercise convinced me of two things: it would be possible, and it would be a LOT of work -- undo in an environment with distributed control is a lot harder than it is for Emacs. Our scheme involved having each proctable entry provide a "how to undo me" procedure which would be pushed onto an "undo stack" (along with some invocation-specific data) when the proctable entry was called! > I wish the caret wouldn't always take the font style of the previous > character -- it makes it especially frustrating to try and insert a new > word first on a line and discover that it took the font props of the > previous line. [MS Word, MacWrite, etc. does this right] Earlier versions of Andrew toolkits did this right. This was changed when the current ATK was written, and I've argued that it was a mistake ever since. It would be trivial to change it, or at least make it a preference option. > I wish there were indications in the margin about what kind of style > [etc] the current para was. Do you know about ESC-s? If not, go into a region of text with styles and try typing it. > I wish there was support for setting tab stops! [What no tabs??! You > must be joking!] No version of any Andrew toolkit has ever supported tabs properly. It's a tradition -- that's what the letters really stand for: All Tabs Killed. > I wish there was [wysiwyg] support for 16 or 8 bit fonts and accented > characters in particular. I've heard rumors that this was coming. > 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. > In general, I wish that ez would be on level with "real" word > processors, such as MS Word, Frame, Xerox Viewpoint, etc. so that it > could be a serious competitor. Me too, but you should keep in mind that nobody ever funded it as such, and nobody does today. In particular, ez was never really funded or supported at a level that would allow this to happen -- it was funded more as a research project to demonstrate the utility of the toolkit's approach to documents. As such, I would contend that it succeeded wildly -- so wildly that it was opened up to criticisms like this one. A better question now would be, how could we get someone to pay for either extending ez to this level, or for building a new word processor that has the advanced features permitted by the ATK architecture and the polish of the "real" word processers. > I wish middle button would do thumbing in the scroll bar [instead of > bringing up the menu] -- grabbing the scroll bar with the left or right > button is tedious and somewhat difficult when the text is large and the > scroll bar very small. Neat idea, but I think the "middle button == mouse" equation is hard-wired, both in the code and in the minds of the people who wrote it... :-) > I wish there would be better graphical [paint, draw type] editors. Ditto, but see my answer about "word processing" above. Nobody ever wanted to pay for this, either. > I wish there was full color support, not just fg/bg colors. Isn't this coming in patch 6? > 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.) > 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... > 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. > 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 > I wish Messages would give the choice of sorting order -- by date sent, > date received, author, recipient(s), subject, etc. Yeah, these would be very nice. Unfortunately, the idea of having the database ordered by time-received is deeply wired into the system -- the way user profiling information is kept, and so on. If I were doing it over again, I would probably do it differently, but fixing it would be a massive job. > I wish Messages et al would allow me to directly control the appearance > of the captions -- what is shown as well as how it is presented. > (Seeing that a message is from "Mail D. Subsystem" instead of > "Mailer-Daemon" is kind of amusing, but there are worse cases.) The default algorithm is highly-tuned with a lot of heuristics, which I sometimes think were specifically designed (by me) to make people laugh. The best ever was when Craig Everhart got mail from something like "Postmaster@ELEPHANT-BUTTE.SCRC.ARPA" (yes, that was a long time ago) and -- you guessed it -- the caption said "Postmaster@ELEPHANT-BUTT". He thought that one of the other developers was playing a prank on him! Actually, I still think the heuristics produce good answers an amazing portion of the time, given the h*rs*sh*t that often shows up in From: headers. However, you can do exactly what you ask for from a FLAMES program -- using the FLAMES "setcaption" primitive you can redesign the captioning algorithm (in LISP). > I wish Messages would allow me to have more than one "Message Draft" > window open -- I often want to keep several of these around until I'm > ready to send them off. No problem. Don't you know about the ^X2 keystroke, which can be used in any of Messages' windows? Try typing ^X2 in the sending window. (Aren't these key bindings intuitively obvious? I don't see the problem.. :-> ) > 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. > I wish Messages would support an easy way of following a branch of followups. Try "Mark Related Messages" on the "Search/Spell" menu card. > 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 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. > 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... > I wish the mail applications would have been written to use a "real" > mail service protocol, talking to a "real" mail server, instead of > trying to rely on a global file system. Well, you should bear in mind that we sold CMU/IBM on a mail system project in the first place in large part as a demonstration service to be built on top of AFS. We never originally intended that it would be taken apart and run with sendmail! > 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... > I wish there wasn't so many flags littering the system and making it > virtually incomprehensible without investing What, you mean there are better things to do with your time than learn about obscure options to Andrew? > 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. Gee, that was fun. -- Nathaniel