lovstrand.EuroPARC@XEROX.COM (Lennart Lovstrand) (07/18/90)
Dear Saint Andrew:
While there are many things I like about Andrew as a user, there are
also (maybe as many, I dare say) things I find annoying and frustrating
when compared to other word processing or mail applications. This is
sad, because it acts as a obstacle in promoting Andrew as the general
office multimedia document system, one that otherwise would have a great
potential in serving technical staff and administrators alike and
bringing them together under the same roof.
The features of Andrew that I like the most are probably the modular
architecture of the toolkit applications, allowing almost anything to be
embedded within something else, and the fact that multimedia documents
are encoded in such a way they can be transparently shared between
Andrew users via email. It is an incredibly powerful combination that
not only looks & feels nice to use, but also opens exciting new doors to
creating applications by object manipulation and the ability to
distribute these with very little overhead.
[For comparisons, the only other system that I know of that provides
anything like this is Xerox Lisp with TEdit and Lafite, but that is
reserved for the "privileged few" who have a Lisp machine on their desk
-- and god how slow it is!]
Now over to the not-so-good part. Over the last six months or so, I've
been trying to collect notes on the things I'm not so happy with Andrew
about. I've included most of these below as suggestions for
improvements. Please see them as constructive criticism; any comments
are welcome (especially, "but you can already do that!").
--Lennart <Lovstrand.EuroPARC@Xerox.COM>
[An Andrew ToolKit view (a raster image) was included here, but could
not be displayed.]
EZ and TextView (&c)
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.
I wish I had M-X...
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.
I really, really wish there was an UNDO in ez &c.
I wish backup and checkpointing could be compatible with gnu emacs, ie.
#foo# for checkpoint and foo~ or foo~n~ for old versions.
I wish M-Del would put the deleted text in the kill-ring, as emacs does.
I wish there was a M-T (transpose-words).
I wish operations on text attributes (fonts, etc) would be available "on
the same level" as opposed to explicitly embedded within each other.
For example, one should be able to "unitalicize" foo in \italic{foo
\bold{bar}}, giving foo\italic{\bold{ bar}}.
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]
I wish the lookz menu would allow me to change the default style as well
as the others (does it?)
I wish I would be able to explicitly state that a certain piece of text
should be 12 point Optima (or whatever) without having to create a
random name for it and declare it using lookz.
I wish there were indications in the margin about what kind of style
[etc] the current para was.
I wish there was support for setting tab stops! [What no tabs??! You
must be joking!]
I wish there was [wysiwyg] support for 16 or 8 bit fonts and accented
characters in particular.
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?
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.
Graphics
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.
I wish there would be better graphical [paint, draw type] editors.
I wish there was full color support, not just fg/bg colors.
Messages & AMS
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).
I wish "Insert Header" would work even when the caret is in the body window
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 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.
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.)
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.
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?]
I wish Messages would support an easy way of following a branch of followups.
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 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 wish AMS wouldn't barf on a subject-less message (ugh!)
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.
General
I wish tm wouldn't scroll 2/3 of the window each time the caret goes
below the bottom of the screen. [Argh!]
I wish there would be a (one) consistent extension language, not ELI
here and NESS there etc.
I wish there wasn't so many flags littering the system and making it
virtually incomprehensible without investing
I wish the code wouldn't contain quite so many magic constants and
obscure defensive coding.nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/18/90)
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
Craig_Everhart@TRANSARC.COM (07/18/90)
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 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.... > 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. > 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! The left/right-justified stuff sounds like a bug. Nathaniel and Adam already told you how to control this some, so maybe it will be more to your liking. > 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. 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 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.) As we built AMS (for use on Vice/AFS), we didn't want people to have to retrieve a message (that whole file) in order to see a one-line caption describing it. Our choice of what information to put in the caption line, which is simply one field in the ``snapshot'' in the .MS_MsgDir index file, was therefore global to all readers of a folder. Not ideal, it's true. > 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. > 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. > 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. > I wish AMS wouldn't barf on a subject-less message (ugh!) Matter of taste. Like Nathaniel, I don't enjoy reading messages without subject lines; to me it marks a thoughtless message author. > 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. It relies not on a global file system but on a local-area file system; the global file system extensions came later, and are not as integral. Yeah, wouldn't it be nice if it worked with POP and all the rest. > I wish the code wouldn't contain quite so many magic constants and > obscure defensive coding. I read this as a complaint more about the obscurity of the defensive coding than the defensive coding itself. Too bad that when we were cornered into making a defensive fix that we didn't comment the situation against which we were defending. Thanks for the list! It's good to go through it. Craig
ghoti+@ANDREW.CMU.EDU (Adam Stoller) (07/18/90)
Excerpts from internet.info-andrew: 17-Jul-90 Re: Dear Saint Andrew... Nathaniel Borenstein@thu (11539+0) >> 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. Actually, I think there might already be one -- try adding the preference: StylesIncludeEnd: no > 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... :-) (Presumably that should be "middle button == menus" ) --fish
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/18/90)
Excerpts from internet.info-andrew: 17-Jul-90 Re: Dear Saint Andrew... Adam Stoller@andrew.cmu. (2310+0) > I believe FLAMES will allow you to do this for your own personal mail > folders - Trying to do it for public bboards would require [drastic?] > changes in the way the entire messages database works (which may or may > not be worth it in the long run, but who intends to put in the short > term time of (a) trying to make it work, and (b) trying to make it > robustly backward compatible???) Adam is right on a per-person basis. However, it is easy to modify the bboard daemon at any particular site to construct the captions however you like -- the key is that the captions look the same for everybody, that's all.
jjc@UNIX.CIS.PITT.EDU ("Jeffrey J. Carpenter") (07/18/90)
Excerpts from comp.info-andrew: 17-Jul-90 Re: Dear Saint Andrew... Nathaniel Borenstein@thu (11539+0) > Do you know about ESC-s? If not, go into a region of text with styles > and try typing it. > 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.. :-> ) Where are these things like ESC-s and ^X2 documented? I can't seem to find them anywhere... jeff Jeff Carpenter University of Pittsburgh, Computing and Information Services jjc+@unix.cis.pitt.edu, +1 412 624 6424, FAX +1 412 624 6436 [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.]
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/19/90)
^X2 is documented in the "messages-keys" help. ESC-s is documented in the "ez-keys" help. Useful help files, both of them.
datri@convex.com (Anthony A. Datri) (07/19/90)
>> #foo# for checkpoint and foo~ or foo~n~ for old versions. >If ATK and Emacs could agree on semantic points.... "emacs" does not imply "gnu" --
janssen@parc.xerox.com (Bill Janssen) (07/19/90)
Excerpts from ext.andrew: 17-Jul-90 Re: Dear Saint Andrew... Nathaniel Borenstein@thu (11539+0) > I really love these wish lists. Me too. > Excerpts from internet.info-andrew: 17-Jul-90 Dear Saint Andrew... > Lennart Lovstrand@xerox. (7062+1) >> 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. I've written a meta-x package. I'll put it on expo. >> 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've heard this called "the best is the enemy of the good". If we could have a separate undo list for each inset, not a unified list, that would go a very long way toward allowing people to use EZ on a day-to-day basis (as a code editor, for example, where you don't really care about insets (yet)). >> 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 read this a bit differently. Have you ever used InterLeaf WPS? They have a strip to the side of the page that reflects the paragraph type. >> 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. Maybe that's the way UNIX does quality control. None of the `standard' applications have any error-checking code, they just expect the underlying mechanisms to work, so the OS people have to *make* them work. Doesn't work out too well for people running research versions of the OS, though... Bill
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/19/90)
Excerpts from info-andrew: 18-Jul-90 Re: Dear Saint Andrew... Bill Janssen@parc.xerox. (2504+0) > Maybe that's the way UNIX does quality control. None of the `standard' > applications have any error-checking code, they just expect the > underlying mechanisms to work, so the OS people have to *make* them > work. Doesn't work out too well for people running research versions of > the OS, though... I can't let this one slip by. Most of the critical system calls are DOCUMENTED to have conditions when they fail. A responsible system designer therefore has to consider the consequences when this happens. You can build, for example, the most reliable file system in the world, but it will still occasionally fail to store files -- what you expect, however, is that it will tell you whether or not it has succeeded, and let you respond accordingly. I don't think this sort of thing works much better for "industrial-strength" versions of UNIX than for "research" versions. The system calls typically have semantics that include reasonable failure cases, and you have to consider these, that's all.
wdr@rchland.ibm.com (Wayne Richardson) (07/20/90)
Excerpts from ext.cmu.info-andrew: 18-Jul-90 Re: Dear Saint Andrew... Bill Janssen@RCHGATE.rch (2504+0) >>> 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 read this a bit differently. Have you ever used InterLeaf WPS? They > have a strip to the side of the page that reflects the paragraph type. I agree the strip would be really nice, but I survive with the following line in my .ezinit, which gives me a popup menu item called Toggle Expose Styles: addmenu textview-toggle-expose-styles "File,Toggle Expose Styles~90" textview -wr
lovstrand.EuroPARC@XEROX.COM (Lennart Lovstrand) (07/20/90)
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.]
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/20/90)
Excerpts from info-andrew: 19-Jul-90 Re: Dear Saint Andrew... Lennart Lovstrand@Xerox. (15952+1) > 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? Yeah, the thing is that there are times when the choice isn't obvious. For example, sometimes people mark things as they're reading a folder, planning to deal with them en masse at the end. So they're reading the Nth message, with K marked so far, and they say "delete". Now, do they mean delete this Nth message that I'm reading at the moment, or the K messages that are already marked? > 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? In the Return-path, I believe. By the way, I'd strongly encourage you to send that patch back to the ITC. > 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. OK, so sue me -- I was talking from memory and had it backwards. The gist of what I was saying remains true, which is that it isn't as simple as just eliminating the code that nukes the From lines -- you also have to add code that does the right thing with a Sender line. I guess that wouldn't really hurt, and would be easily implemented. > 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. Actually, there is (or used to be, I don't know which) an AFS option that said "don't ever let any FS operations fail -- just wait forever if necessary until you can make them succeed." If that had been the way AFS always behaved, the AMS code would have been much simpler. Unfortunately, that turns out to be NOT the behavior users want when one file server out of twenty goes down... > >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. Yeah, it could have been more modular, I'll grant that readily enough. >> 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.) Use the CUI "reconstruct" command. > 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. It's easy for me to be open-minded, since I'm no longer the one fixing the code... [An Andrew ToolKit view (an animated drawing) was included here, but could not be displayed.] ---------------------------------------------------------------------- [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.] [An Andrew ToolKit view (a raster image) was included here, but could not be displayed.] Nathaniel S. Borenstein <nsb@thumper.bellcore.com> Member of Technical Staff, Bell Communications Research Office: Bellcore Room MRE 2A-274, 445 South Street, Morristown, NJ 07962-1910 Work phone: (201) 829-4270 Work FAX: (201) 829-7019 Home: 25 Washington Ave., Morristown, NJ 07960, (201) 993-8586
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/20/90)
Excerpts from internet.info-andrew: 19-Jul-90 Re: Dear Saint Andrew... Wayne Richardson@rchland (697) > I agree the strip would be really nice, but I survive with the following > line in my .ezinit, which gives me a popup menu item called Toggle > Expose Styles: > addmenu textview-toggle-expose-styles "File,Toggle Expose Styles~90" textview My (possibly flawed) recollection is that this is not documented or heavily promoted because it is sometimes buggy in disturbing ways. But it is very useful, and does seem to work most of the time...
Craig_Everhart@TRANSARC.COM (07/20/90)
> Excerpts from internet.info-andrew: 19-Jul-90 Re: Dear Saint Andrew... > Lennart Lovstrand@Xerox. (15952+1) > 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! ;-) Quoting the local-part shouldn't cause your sendmail to choke; it should know how to strip the quotes. You're right on, though, that AMS expects to live in an RFC822 world, and any attempt to veer from that causes trouble. In this case, you're right that it's not doing a very good job of allowing you to express these non-RFC822 addresses, and there's no current fall-back from that. Wow, another address-validation request: don't even bother parsing the addresses, but just leave 'em alone. Or parse them in some broader syntax, and try to handle the ones you recognize. > 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. It's still not nice to send From: lines that don't at least parse. You might want to add Reply-to: in case the From: is parseable but unreplyable, for example when your friend without a computer account wants to send a piece of mail. Old Tops-10 RdMail used to add such a Reply-to: field automatically, when From: was unreplyable. I enjoyed reading Nathaniel's blurb on ``social experiments'' and can echo most of his sentiments. Again, though, I now believe that one can write a socially-responsible MUA while allowing users to change the From: line (in some ill-specified ways). It's just a matter of work and taste. > 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. I think Butler Lampson disagrees with this, in the advice-for-system-designers paper of about 1983; he claims that failures should be made visible end-to-end, so that after all lower-level recovery attempts have failed, the application, and eventually the user, will still have to cope with an underlying failure. TCP was a reliability improvement over UDP partly because it implemented a different abstraction. The AFS story is that it is a distributed file system programmed to the Unix system call interface, and indeed each call can separately fail. You could imagine another interface behind which many failures could be handled, and recovered, for you, but it's difficult to make incremental changes to the syscall interface to achieve that. > 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. Here's a difference between folders to which you have update access (like your personal ones) and folders to which you have only read access (like public bboards). If you have update access, sure, you own the has-this-message-been-examined bit in the .MS_MsgDir file, and those bits are set independently. If you don't have such access, the state of those bits isn't written back to that file, and the only record (from session to session) of which messages you've seen is the high-water-mark. > 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. A ``From '' line is more than the separator for /usr/spool/mail/eeeee messages; it's the delivered copy's record of the message envelope. That function it shares with RFC822 Return-path:. Craig
ghoti+@ANDREW.CMU.EDU (Adam Stoller) (07/20/90)
[This Message vs Marked Messages] Excerpts from internet.info-andrew: 19-Jul-90 Re: Dear Saint Andrew... Nathaniel Borenstein@thu (4870+3) > Yeah, the thing is that there are times when the choice isn't obvious. > For example, sometimes people mark things as they're reading a folder, > planning to deal with them en masse at the end. So they're reading > the Nth message, with K marked so far, and they say "delete". Now, do > they mean delete this Nth message that I'm reading at the moment, or the > K messages that are already marked? I was about to write the same thing - even with the ability to (a) Undelte all those messages you just accidently deleted, and (b) the ability to Clear Marks and then Restore Old Marks -- Suppose instead of Delete you chose Print with 100 messages marked, when you only wanted to print the one you were looking at -- it's not always something that can be easily cleared up (especially for users who are not that involved with computers and the workings of programs) Excerpts from internet.info-andrew: 19-Jul-90 Re: Dear Saint Andrew... Lennart Lovstrand@Xerox. (15952+1) >>> 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. In my limited experience with Mac's (i.e. those with the built in monitor - not any with large external monitors) - tabs are relatively easy because they've already defined the constraints of the "page". The ATK was developed on top of a window manager on a 19" monitor - allowing not only variable width fonts, but variable width (and height) windows. This puts a somewhat obvious fork in the road -- do you constrain the contents of the window to fit some ideal, so that you can easily determine where tab stops and page breaks are -- or do you make use of all the space your given. True, this may be a somewhat simplistic comparison - but considering how different a piece of text can look if it's in a 3 inch wide window frm how it looks in a 12 inch wide window - how would you support tabs consistantly in both?? Mac's (at least those with built in monitors) had it much easier. Out of curiosity, on a Mac if you make the window narrower than the full screen (in something like MacWrite...) - does the text wrap earlier, or does it simply get chopped off at the right-hand edge? (or will it even let you reduce the width of the window???) Excerpts from internet.info-andrew: 19-Jul-90 Re: Dear Saint Andrew... Lennart Lovstrand@Xerox. (15952+1) >> 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. ....... > 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. "seen" is correct in terms of meaning "shown the caption of" In a personal mail folder you may have many messages which you were shown the captions for, but which you did not read - the "high-water-mark" points to the last (or just after the last) caption you were shown when you last looked at the captions for that folder [unless you specifically set the mark earlier]. In a public bboard folder - all messages prior to the last one shown you are considered as "read" (whether or not you actually did read them), but the "high-water-mark" still points to the last caption you were shown when you last looked at the captions for that folder. --fish
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/20/90)
Excerpts from internet.info-andrew: 20-Jul-90 Re: Dear Saint Andrew... Craig_Everhart@transarc. (4577+0) > Wow, another address-validation request: don't even bother parsing the > addresses, but just leave 'em alone. Or parse them in some broader > syntax, and try to handle the ones you recognize. Yeah, kind of a neat idea for an option. Whereas most modifications to mswp.c are a real nightmare, it should really be quite easy to add an option that causes the MS_Validate... call to simply return an "all is well code" all the time.
guy@auspex.auspex.com (Guy Harris) (07/21/90)
>I wish tm wouldn't scroll 2/3 of the window each time the caret goes >below the bottom of the screen. [Argh!] I'll drink to that, at least to the extent that it should scroll up one line for every new line of output that arrives at the bottom of the screen. I looked into this briefly; it appears the 2/3-screen scrolling is done by "textv". Is there any way "tmv" could override this? (The 2/3-screen should perhaps be tunable in any case, as it is in Unipress EMACS - maybe GNU EMACS as well, dunno.) It might also be nice if "tmv" could pause when an entire screenful of output had come out. The problem is figuring out when it should (i.e., when the tty is being treated as a sequential file) and shouldn't (i.e., when some full-screen program is running) - basing it on cooked vs. uncooked mode on the tty means it will never pause when you're e.g. rlogged into or telnetted into another machine; this is a problem with the similar "pause every screenful" option in the SunView "shelltool".
guy@auspex.auspex.com (Guy Harris) (07/22/90)
>True, this may be a somewhat simplistic comparison - but considering how >different a piece of text can look if it's in a 3 inch wide window frm >how it looks in a 12 inch wide window - how would you support tabs >consistantly in both?? I don't think this is an issue of the monitor size so much as it's an issue of the philosophy of the underlying editor; if editors such as Interleaf, Frame, etc. - which were all originally done for big-screen workstations - support tabs, I suspect they support them more like other word processing editors do. I think most word processing editors do *not* set the margins based on the size of the window; the "page width" is fixed, and if you widen the window, it probably just leaves more white space. Andrew is different, in that the margins move if you change the width of the window. I don't think one can ascribe the philosophy of the other editors to the size of the screen for which they were originally developed....
nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (07/23/90)
Guy's right about philosophy. In the very earliest days of Andrew, there was a strong "anti-paper" bias -- that's when they traded the acronym WYSIWYG for WYSLRN (What You See Looks Real Neat). The fact that the screen was always paramount and paper was an afterthought, and that objects were supposed to be very dynamic in their response to their window size, is probably the underlying cause of Andrew's historical problems with tabs & printing. Not that it excuses anything, but it does help to explain it.
tobeye@northstar.dartmouth.edu (Anthony Edwards) (07/23/90)
Excerpts from internet.info-andrew: 19-Jul-90 Re: Dear Saint Andrew... Nathaniel Borenstein@thu (540+0) > My (possibly flawed) recollection is that this is not documented or > heavily promoted because it is sometimes buggy in disturbing ways. But > it is very useful, and does seem to work most of the time... I, too, use this undocumented feature. I find it extremely useful when working on a document with a lot of formatting. Yeah, it's quirky sometimes, but it has never crashed on me. Its utility outweighs its quirks. I was surprised that the EZ precursor, EditText, had this feature but EZ did not. When EZ first came out, my first reaction was to go into the source code and look for it. I haven't complained since because it was there, albeit undocumented. I cast my vote for the ITC to document the feature, perhaps with a caveat. - Anthony
wjh+@ANDREW.CMU.EDU (Fred Hansen) (07/24/90)
Excerpts from internet.info-andrew: 17-Jul-90 Re: Dear Saint Andrew... Nathaniel Borenstein@thu (11539+0) >> 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. edittext, the predecessor to ez, implemented tabs; tab stops could be set with the equivalent of lookz
tcrowley@bbn.com (Terry Crowley) (07/25/90)
I've heard this argument for years that the reason Andrew doesn't do tabs is because of the problems variable-width windows introduce. I think the argument's kind of a crock. There's an easily defined behavior for what to do with tabs no matter what your linewidth is. Word processor's have to deal with this because of the ability to mix tabs and adjustments to the left and right margins and overall page width. Granted, tabs are kind of a pain (I speak from experience, having implemented them in Slate (nee Diamond)), but variable size windows don't introduce any insurmountable difficulties. By the way, Slate handles the standard set of left justified, right justified, centered, and decimal tabs, as well as doing the "right thing" with tabs whether you're dealing with left-to-right or right-to-left languages. Terry Crowley
guy@auspex.auspex.com (Guy Harris) (07/26/90)
>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!). Which EMACS? If it were moved closer in some ways to GNU EMACS - e.g., by breaking the way ^T works, and not having it transpose the two characters to the left of the cursor - I'd have to change it back before using it. >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. If ^T is one of the ways in which it maintains that consistency, I consider that a misfeature. :-) EZ is, I suspect, more a descendant of *Gosling* EMACS than of GNU EMACS (which shouldn't be too much of a surprise :-)). Gosling may have been the person who changed ^T's behavior (I suspect so, given that the Korn shell gives GNUish behavior in its EMACS mode by default, but Gosling/EZ-ish behavior if EDITOR is set to ".../gmacs"; I'm assuming the "g" is for "Gosling"). Gosling EMACS also uses the ".BAK" and ".CKP" conventions for backup and checkpointing files, and I suspect that's whence EZ got them.
nichols@parc.xerox.com (David Nichols) (07/28/90)
Excerpts from ext.andrew: 26-Jul-90 Re: Dear Saint Andrew... Guy Harris@uunet.uu.net (1292) > Gosling may have been the person who changed ^T's behavior (I suspect > so, given that the Korn shell gives GNUish behavior in its EMACS mode by > default, but Gosling/EZ-ish behavior if EDITOR is set to ".../gmacs"; > I'm assuming the "g" is for "Gosling"). Actually, a number of the differences in key bindings and behavior between Gosling Emacs and ITS Emacs are due to Mike Kazar. Mike wrote a screen-oriented editor for Tops-10 called FINE. When James wrote his Emacs for Unix, he just copied the FINE key bindings. The funny thing to me about all this is that while some of the changes (like ^T) were intentional, some (like ^X^F bound to exit instead of find file) were simply because Mike mis-remembered the ITS bindings. David