mark@DRD.Com (Mark Lawrence) (08/23/89)
We just got 2.2 PL 10 up. We've noticed some things that I think the
Elm developers deserve a big thank you for:
When you tag a bunch of headers and then save them somewhere, the
save really fast. Nice!
Being able to specify '<' and '!' to get back to the system mailbox
and outgoing copy folder respectively from the change folder
command.
Aliases can now be listed and deleted. Yay!
I don't use all the bells and whistles, so my experience outside of the
'elm' program proper is limited, but I'm really happy with the progress.
No complaints with the current incarnation.
Wish list for future versions:
. ability to bounce tagged mail (as a system administrator, I do this a
lot).
. ability to edit aliases from within elm.
. ability to set a default folder (other than the name of the sender).
. ability to set a different folder directory (i.e., visit subdirectories
to the folder directory and return)
--
mark@DRD.Com
uunet!apctrc!drd!mark
(918) 743-3013asd@mace.cc.purdue.edu (Kareth) (08/24/89)
In article <1989Aug23.121938.2967@DRD.Com> mark@DRD.Com (Mark Lawrence) writes: >We just got 2.2 PL 10 up. We've noticed some things that I think the >Elm developers deserve a big thank you for: >Wish list for future versions: >. ability to bounce tagged mail (as a system administrator, I do this a > lot). >. ability to edit aliases from within elm. >. ability to set a default folder (other than the name of the sender). >. ability to set a different folder directory (i.e., visit subdirectories > to the folder directory and return) - Ability to tag messages and have them all included in a reply. Take all of subject A's mail and reply in ONE letter. - File name completion on folder changes or saves. I've seen this done in a newsreader using only spacebar. - Elm be more flexible in file locking. Our system for instance doesn't have group id permission set in /usr/spool/mail. Tis an easy fix, by changing the file lock to the XENIX version, but couldn't Elm try the first method and then the second itself. Would allow a bit more flexibility I would think. I do have a few problems tho. First off: This is a Vax8800 running Ultrix2.2. I have Elm2.2 pl10. I've gone into the alias section and tried to delete aliases. No go. It correctly identifies the alias, asks me if I want to delete it, I say yes, it says it's updating the list, then re-reading them in, but nothing ever changes. Currently, elm is not installed yet (I'm just making sure it works), but it should have access to the necessary files. It just doesn't do diddly. Also, I recall some discussion about newmail not quiting when a terminal logs out. I didn't pay attention to the discussion at the time (twas before I was working on this). The newmail I've compilied here does that also. I've had a couple of users newmail process have the same tty as mine and had fun watching them get mail every so often. I recall there being a option in Configure on wether or not to have newmail automatically run in the background. If I say no, and a person then backgrounds it (&) will it quit when the terminal logs out like it should? Or is this a bug I can't do anything about besides try and patch it manually? Other than these two things, and the fact that I have to change which type of lock elm/filter use, it works fine. I do get an occasional: "Can't invoke /usr/local/bin/jove for composition!" AFTER I edit a reply and quit jove, returning to the prompt to ask me if I want to send the file. It will give me that line, and then go back to the regular "Command:" line w/o asking me if I want to send the file. The file is intact, because I can 'r' again, and include the last message. Could anybody explain what could be happening here? -kareth. (first time elm supporter)
syd@DSI.COM (Syd Weinstein) (08/24/89)
asd@mace.cc.purdue.edu (Kareth) writes:
.- Elm be more flexible in file locking. Our system for instance doesn't have
. group id permission set in /usr/spool/mail. Tis an easy fix, by changing
. the file lock to the XENIX version, but couldn't Elm try the first method
. and then the second itself. Would allow a bit more flexibility I would
. think.
File locking needs to be configuration time based, because if it failed,
you wouldn't want Elm blindly going on, risking loosing the mail.
.First off: This is a Vax8800 running Ultrix2.2. I have Elm2.2 pl10.
.I've gone into the alias section and tried to delete aliases. No go. It
.correctly identifies the alias, asks me if I want to delete it, I say yes, it
.says it's updating the list, then re-reading them in, but nothing ever
.changes. Currently, elm is not installed yet (I'm just making sure it works),
.but it should have access to the necessary files. It just doesn't do diddly.
If the alias has multiple names (a,b = test = name), it is a know bug
that it doesn't delete it. Other than that, are you sure it has
access to newalias (on the path), as that is required to recompile the
aliases.
.Also, I recall some discussion about newmail not quiting when a terminal logs
.out. ...
This is due to some systems not passing the sighup signal to the
children. For newmail to go away, it must still be associated with
your terminal, and your terminal must have hupcl set. If your method
of placing it in the background disassociates it from the terminal,
as in using csh and an & on the end, it won't go away. It depends on
getting the hupcl signal. It is best in that case to have it automatically
go into the background (config option) and then start it without a &,
and do not do so from a script that is already disassociated from the
terminal.
. "Can't invoke /usr/local/bin/jove for composition!"
This is also a common problem. If jove returns a non zero status,
thats an error status, some editors, by mistake, return non zero status
when there is nothing wrong. In this case, either fix the editor,
or wrap it in a shell script that has an exit 0 to clear the return status.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235chip@vector.Dallas.TX.US (Chip Rosenthal) (08/24/89)
In article <2969@mace.cc.purdue.edu> asd@mace.cc.purdue.edu (Kareth) writes: >In article <1989Aug23.121938.2967@DRD.Com> mark@DRD.Com (Mark Lawrence) writes: >>Wish list for future versions: >>. ability to bounce tagged mail >- Ability to tag messages and have them all included in a reply. Take all of > subject A's mail and reply in ONE letter. ...to all the senders of the tagged messages. Right now I've got about 8 requests in my mailbox for a program I offered on the net. It would sure be nice to tag 'em all and issue one reply. (Hey Syd...we're working as hard as we can to come up with things to merit a new release :-) -- Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337 "I wish you'd put that starvation box down and go to bed" - Albert Collins' Mom
rusty@fe2o3.UUCP (Rusty Haddock) (08/25/89)
In article <1989Aug23.225206.538@DSI.COM> syd@DSI.COM writes: >... >. "Can't invoke /usr/local/bin/jove for composition!" >This is also a common problem. If jove returns a non zero status, >thats an error status, some editors, by mistake, return non zero status >when there is nothing wrong. In this case, either fix the editor, >or wrap it in a shell script that has an exit 0 to clear the return status. >-- I'm glad that someone else has this same problem. I have it happen with 'vi'; not always but usually after a long winded message. I haven't found a way to recover after elm chokes. I'm not sure I care for Elm's cavalier approach to losing a composition, any composition, especially a lengthy one. The way I see it, Elm just says "Editor did not return in the way I expected so YOU LOSE!" Such a catastrophy should be dealt with in a way that gives the user an option. Something as simple as Your editor returned a status indicating a possible error with the editted file. Do you wish to continue with what the editor saved? [Y/N] _ would be much more sympathetic to the user and certainly not as... `hostile'. How many statements in C would this really take to implement? Four? Five maybe? Even if Elm did manage to stash away my (usually lengthy) composition, errors like this should not be handled in their current manner. Actions like this, when taken by a program, can upset the program's users (knowledgable or not) and that's not one of the basic ideas behind the design of a user interface. Thanks for reading. -Rusty- -- Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"
syd@DSI.COM (Syd Weinstein) (08/25/89)
rusty@fe2o3.UUCP (Rusty Haddock) writes: >Actions like >this, when taken by a program, can upset the program's users (knowledgable or >not) and that's not one of the basic ideas behind the design of a user >interface. I think I should defend the original author of Elm in this case. The error message you have received, and under discussion here, is that Elm thinks that the editor did not even get started. Its not that the editor left with a non zero status, although that is what actually happens. In the many years of Elm's evolution, this problem has not cropped up until now, yet this code is unchanged for probably three years. My point is, that Elm's original author thought that this message was all the work that was necessary for a catastrophic error that probably meant that something was drasticly misconfigured. (IE Unable to start the editor at all). It was never envisioned that the editor would start and then appear to have an error. In three years this is the first discussion on this (I still don't know why vi has broken all of a sudden, why not three years ago). All I ask, as coordinator, is to take the tone down one level, and to submit as a patch, to me, the change to do what you wish, make it friendler. Just remember to check for no editor, no processes, cannot fork, out of disk space, editor returned spurious error, editor actually did die, (Gee, its not so simple after all, is it? :-)) The problem is under consideration for a patch, we are suggesting a work around for the interim. Its just, that in anything as large as Elm, nothing is just 4 or 5 lines of C code, there are many side effects of even the slightest change. (after all, the editor just uses the standard subprocess interface). I do welcome any patches, and I do read all the mail that comes in. However, any mail with a patch gets higher priority than mail with just a suggestion, after all, we are all volunteers here, no one gets paid. The list of bugs is very long, some esoteric, some major, and many I would prioritize higher than this one, since the work around on this one is so easy. One of the reasons I have posponed the release of 2.3 is that people have been too busy to work on 2.3 and have anything done worth releasing. Its not that there are not things to do worth releasing, its that they are not done due to peoples time constraints. Thats why I say, all volunteers welcome. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
les@chinet.chi.il.us (Leslie Mikesell) (08/25/89)
In article <1989Aug25.014846.16421@DSI.COM> syd@DSI.COM writes: >Its not that the editor left with a non zero status, although that >is what actually happens. >... In three years this >is the first discussion on this (I still don't know why vi has broken >all of a sudden, why not three years ago). Vi normally gives the number of errors made in editting commands as its exit status. Perhaps it has taken you 3 years to make a mistake and give vi a bad command, or perhaps you have something wrong in EXINIT or .exrc. Les Mikesell
cudcv@warwick.ac.uk (Rob McMahon) (08/26/89)
In article <1989Aug25.014846.16421@DSI.COM> syd@DSI.COM writes: >rusty@fe2o3.UUCP (Rusty Haddock) writes: >>Actions like this, when taken by a program, can upset the program's users >>(knowledgable or not) and that's not one of the basic ideas behind the >>design of a user interface. > >In the many years of Elm's evolution, this problem has not cropped >up until now, yet this code is unchanged for probably three years. I have to just say that I've been bitten by this a couple of times, and I've seen users bitten by it too. Our standard editor round here exit(1)s if you quit out, discarding any changes, so typically you type your message, leave the editor normally, reenter the editor to make some changes, realise that you didn't have to after all and quit out. Oops, start again. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
rusty@fe2o3.UUCP (Rusty Haddock) (08/27/89)
In article <1989Aug25.014846.16421@DSI.COM> you write: >rusty@fe2o3.UUCP (Rusty Haddock) writes: >>Actions like >>this, when taken by a program, can upset the program's users (knowledgable or >>not) and that's not one of the basic ideas behind the design of a user >>interface. > >I think I should defend the original author of Elm in this case. >The error message you have received, and under discussion here, >is that Elm thinks that the editor did not even get started. Sorry, I guess I kinda get excited about this sort of thing. Don't get me wrong -- I wasn't trying to cut anyone in particular down. If anything, I was ``trying'' to extoll the virtues of a non-hostile program. I've had at least one former department head and two former supervisors that would have grilled me silly for a program that would die (for any reason) after typing in a long message without an escape or some sort of recovery. I've also worked with a number of good human factors people and a smaller number of psychologists. Because of this I'm a little sensitive to the human factors side of the issue and I don't like IT to be ignored even if I am an engineer. (I, on the other hand, am used to being ignored but I s'pose you have figured that out by now :-) >My point is, that Elm's original author thought that this message >was all the work that was necessary for a catastrophic error that >probably meant that something was drasticly misconfigured. (IE Unable >to start the editor at all). It was never envisioned that the editor >would start and then appear to have an error. In three years this Well, now that we know there's a problem let's work to remedying the situation. And yes, I will and can help now (summer finals were just about to start when I wrote the message). Gimme a chance to go through the sources and I'll see what would be appropriate. Maybe it won't be 4 or 5 lines -- maybe it will be. >is the first discussion on this (I still don't know why vi has broken >all of a sudden, why not three years ago). I don't believe that `vi' has broken all of a sudden, well, at least mine hasn't. I'm running Version 3.7, 6/10/83 and the binary hasn't been modified in the past 2.5-years. I don't have source either. Still, just because we don't see it doesn't mean it's not there, right? >All I ask, as coordinator, is to take the tone down one level, and >to submit as a patch, to me, the change to do what you wish, make >it friendler. Just remember to check for no editor, no processes, >cannot fork, out of disk space, editor returned spurious error, editor >actually did die, (Gee, its not so simple after all, is it? :-)) I really didn't think that the tone was up but, like I said before, I can excited over thses issues. Heck, the flame thrower hasn't even been broken out of its shipping crate yet and the napalm is still on backorder. :-) If I've got to do all that you suggest then *everyone* working on Elm has to! OK? This isn't s'pose to be a punishment assignment for getting excited. And is all that information really there without taking the smaller machines a minute to figure it out? Still, at this stage, I don't believe that the user really has a need to know the reason things crapped out (although the programmers WILL!) just that it did die and the program is trying to save them from itself until Elm can be fixed even better in the next version. It may not be the bravest rescue but it is trying for now. OK, I've had most of my say and it's time to finish breakfast and git to reading Elm. Syd, I'll bounce you a patch as soon as I can get a reasonable solution, OK? BTW folks, if you've had this editor problem happen to you PLEASE let me know about it via Email. It would particularly help if you tell me which version of Unix you're using as well as which editor (and version) bombed and the shell you're using. Anything else that you can REMEMBER about the session that was `different' would be helpful too. Thanks! -Rusty- P.S. The version of `vi' can be found by typing :vers followed by a carriage return or linefeed character. -- Rusty Haddock o {uunet,att,rutgers}!mimsy.umd.edu!fe2o3!rusty Laurel, Maryland o "IBM sucks silicon!" -- PC Banana Jr, "Bloom County"
sfreed@tesla.unm.edu (Steve Freed) (08/29/89)
syd@DSI.COM (Syd Weinstein) writes: >asd@mace.cc.purdue.edu (Kareth) writes: >.- Elm be more flexible in file locking. Our system for instance doesn't have >. group id permission set in /usr/spool/mail. >File locking needs to be configuration time based, because if it failed, >you wouldn't want Elm blindly going on, risking loosing the mail. This is true, however, it does NOT have to use both file locking systems; ie, flock and creating a lock file. It would be great, if in the Configure if the system has flock, then be asked if they want to use lock files in addition to. (I'm not sure why one would want to...) -- Steve. sfreed@ariel.unm.edu
asd@mace.cc.purdue.edu (Kareth) (08/29/89)
In article <441@ariel.unm.edu> sfreed@tesla.unm.edu (Steve Freed) writes: >syd@DSI.COM (Syd Weinstein) writes: >>asd@mace.cc.purdue.edu (Kareth) writes: >>File locking needs to be configuration time based, because if it failed, >>you wouldn't want Elm blindly going on, risking loosing the mail. > This is true, however, it does NOT have to use both file locking >systems; ie, flock and creating a lock file. It would be great, if in >the Configure if the system has flock, then be asked if they want to >use lock files in addition to. (I'm not sure why one would want to...) Well, take for example our system. It's running Ultrix 2.2 but it doesn't use the standard group permissions on the mail spool directory. It HAS to use lock files. That means I have to manually go in and change both elm and filter to use lock files. I'm not sure if all the other systems on campus use the same method (just reasonably sure). I would also like to see Configure ask what method should be used also. -kareth.
jgd@csd4.csd.uwm.edu (John G Dobnick) (08/31/89)
From article <441@ariel.unm.edu>, by sfreed@tesla.unm.edu (Steve Freed): > > This is true, however, it does NOT have to use both file locking > systems; ie, flock and creating a lock file. It would be great, if in > the Configure if the system has flock, then be asked if they want to > use lock files in addition to. (I'm not sure why one would want to...) Actually, using *both* causes some problems, as some of our less experienced users have discovered. (And as I discovered, the hard way, myself. But I'm more experienced now. :-) ) Given a machine crash while exiting elm when elm is rewriting the system mailbox... or a possibly impatient user on a HEAVILY loaded system hitting ^C while elm is doing doing the rewrite ... a <login>.lock file seems to remain to cause subsequent "confusion" to numerous parties with Elm's somewhat cryptic warning message. On systems with flock, the lockfiles are probably not necessary. I think the configuration procedure should allow the site manager/Elm installer to decide this question himself. -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@csd4.csd.uwm.edu UUCP: <backbone>!uwvax!uwmcsd1!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire