chip@osh3.OSHA.GOV (Chip Yamasaki) (06/20/91)
Please! Don't anyone confuse this with a flame! I love Elm and use it daily, but one of the managers and a user or two here has complained about a couple of things and I'd like to make a suggestion or two. I looked at Cymail, that new commercial package being advertised, and discussed it with them. They seem to be responsive, but I ad some complaints and have some reservations about waiting for a commercial package to be ported to the platform I might move to someday. Therefore, I'll look at it some more and see how the Elm community and developers react to a suggestion or two. Now for my users comments: They complained that Elm doesn't have a "menu". I'd call it a menu, but I think what they are looking for is a point and shoot type of thing with the current selection in reverse video and the arrow keys in control. Cymail even uses the Lotus-like technique of displaying a 1 liner explaining the currently highlighted option. Nice, but I personally like having more of the commands listed on one screen like the expert level menu on Elm. Maybe this other style of menu could be and option? Oh well, not so important. Another complaint is no binary attachments. I know this is easy for those of us who are "experienced" mail users, but Cymail does have a good approach for this too. They make the attach action a command separate from the composition of the message and attach the files using uuencode when the message is sent. Then they strip the attachments before piping the message to the pager. Elm could be modified easily for this and the attachments ommand could be placed on the same menu as the send command. Well? Finally, a nice touch is their editor. I've seen lots of callsfor a simple editor, but no great responses. Cymail does have what seems to be a good basic editor. It does the basics and devotes the top four or so lines of the screen to a list of those simple commands. Maybe the Elm development group could come up with something like this, or make a suggestion of another simple editor like that in the docs to help admins with naive users. Another thing I have yet to see is a macro language or API for Elm. That would be fantastic! Any possibility of these types of things appearing soon? -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------
syd@DSI.COM (Syd Weinstein) (06/20/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >I'll look at it some more and see how the Elm community and developers >react to a suggestion or two. I have been told I react poorly to suggestions...... >They complained that Elm doesn't have a "menu". I'd call it a menu, but >I think what they are looking for is a point and shoot type of thing >with the current selection in reverse video and the arrow keys in >control. Elm does not have that type of menu currently, but a character based point and shoot menu is under consideration for the character based front-end for Elm 3.0. >Another complaint is no binary attachments. This one has been under discussion since 2.2 was being developed. We even, internally, floated a proposal about it. No one did anything with it, partly because the AT&T method, Content-Type:/Content-Length: for attachments didn't go anywhere and become a 'global' standard, and at that time, not too much need, compared to now. Plus, at that time, most mail transports were not 8 bit clean, so the best we could do would be a uuencoded attachment.... Now, the IAB is just starting the process of standardizing an attachment interface/headers. That work is going to take a while until the standard becomes published. I would like Elm 3.0 to honor that standard (and perhaps also the older AT&T one), but I think it will come out too late for use in 2.4. >Finally, a nice touch is their editor. I've seen lots of callsfor a >simple editor, but no great responses. I would love a 'simple' editor to distribute with Elm as a contributed product. I am even threatened myself to 'write one' but I don't really have the time if I am to get 2.4 out. I also view this as a major shortcoming. >Another thing I have yet to see is a macro language or API for Elm. I need some convincing here that an Elm macro language would really do something and buy you something.... As for API, I am unsure how that would be used.... I need some 'education' there. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) (06/21/91)
In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>Finally, a nice touch is [Cymail's] editor. I've seen lots of calls for a >>simple editor, but no great responses. >I would love a 'simple' editor to distribute with Elm as a contributed >product. I am even threatened myself to 'write one' but I don't really >have the time if I am to get 2.4 out. I also view this as a major >shortcoming. How about MicroEMACS? I picked it up off an FTP site (I don't remember which) and set it up on our systems. Many of our users here use it as an editor for Elm, and they seem happy with it. It's easy to learn the basics with it (they had given up on "vi" long ago), and it's got enough power for more experienced users. I'm happy with it because it's small (disk space is at a premium on our systems), and because it really cuts down on training time. I patched version 3.8b to handle ANSI cursor keys, but I've heard that 3.10 supports cursor keys defined in termcap. While I'm at it, Syd, I'll get my $.02 in for suggested changes to Elm. I would really like a simple way to abort any command, like hitting Esc. When users accidentally select something like (b)ounce or (r)eply, it would be nice if they could quickly cancel the command, rather than having to step through all the prompts until they finally get to tell Elm to (f)orget it. -- Gilles Detillieux <Gilles@scrc.UManitoba.CA> Spinal Cord Research Centre or <grdetil@ccu.UManitoba.CA> Dept. of Physiology, U. of Manitoba Phone: (204)788-6766 Winnipeg, MB R3E 0W3 (Canada) Fax: (204)786-0932
russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (06/21/91)
grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >>chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>>Finally, a nice touch is [Cymail's] editor. I've seen lots of calls for a >>>simple editor, but no great responses. >>I would love a 'simple' editor to distribute with Elm as a contributed >>product. I am even threatened myself to 'write one' but I don't really >>have the time if I am to get 2.4 out. I also view this as a major >>shortcoming. >How about MicroEMACS? I picked it up off an FTP site (I don't remember which) >and set it up on our systems. Many of our users here use it as an editor for > [...........] >I patched version 3.8b to handle ANSI cursor keys, but I've heard that 3.10 >supports cursor keys defined in termcap. We also use uemacs (3.10) with elm and are very happy with it. >While I'm at it, Syd, I'll get my $.02 in for suggested changes to Elm. >I would really like a simple way to abort any command, like hitting Esc. I would second that one too. Russell. -- Russell Fulton, Computer Center, University of Auckland, New Zealand. <rj_fulton@aukuni.ac.nz>
syd@DSI.COM (Syd Weinstein) (06/21/91)
russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >>I would really like a simple way to abort any command, like hitting Esc. >I would second that one too. Many will second it, including me, back from the 2.2 development days, and its an oldy on the requested enhancements list... But, as Elm is currently written, it keeps too little screen and state info to do this properly. As such it will have to wait for 3.0. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
les@chinet.chi.il.us (Leslie Mikesell) (06/21/91)
In article <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM writes: >>Another complaint is no binary attachments. >This one has been under discussion since 2.2 was being developed. We >even, internally, floated a proposal about it. No one did anything >with it, partly because the AT&T method, Content-Type:/Content-Length: >for attachments didn't go anywhere and become a 'global' standard, >and at that time, not too much need, compared to now. Plus, at that >time, most mail transports were not 8 bit clean, so the best >we could do would be a uuencoded attachment.... >Now, the IAB is just starting the process of standardizing an attachment >interface/headers. That work is going to take a while until the standard >becomes published. I would like Elm 3.0 to honor that standard (and >perhaps also the older AT&T one), but I think it will come out too late >for use in 2.4. SysVr4 mail has the Content-Type:/Content-Length: headers and doesn't escape lines starting with From in the body. It's likely that there will be a fairly large installed base of these around very soon. How about working in at least a tolerance for these messages in the next release? At the very least, don't look for the start of a new message within the bounds of a Content-Length: header, add a command to save the body only which respects the Content-Length: header (multi-part support would be nice, but just getting the entire multi-part chunk into its own file would be a start), and don't barf when you hit NULLs in the body of a message. Actually I think the performace gain of doing the initial read/copy of the mailbox with large read()s and parsing the lines yourself would be worth the trouble compared to the current fgets(), even aside from the fact that it would work in the presence of nulls. >>Another thing I have yet to see is a macro language or API for Elm. >I need some convincing here that an Elm macro language would really >do something and buy you something.... As for API, I am unsure >how that would be used.... I need some 'education' there. Maybe you should ask in the mush group whether macros and a script language are useful, since those people would have the most experience with them. I think simple macros would be nice but I prefer elm to mush because you can give most of the commands from within the built-in pager. I normally can't tell enough about a message to do anything predictable without seeing at least the first screen. One other thing that I would find very useful would be a way to add and edit headers when both sending and reading mail. For example, it would be nice to be able to add a Keywords: header on received messages or edit the Subject: line. Then a command like mush's "pick" would become useful, where it typically isn't on the mail I receive. Les Mikesell les@chinet.chi.il.us
tih@barsoom.nhh.no (Tom Ivar Helbekkmo) (06/21/91)
While we're talking new ideas... This is not actually a suggestion for a new feature in elm, rather, I'd like to hear some comments on the following: Most mail UAs, including elm, use the concept of folders. I find it hard to utilize this properly. I tend to save incoming (and outgoing) mail in folders based on varying criteria. Some items go into folders named for the person I'm corresponding with, others by subject. Right now, there are 111 different folders in my Mail directory -- and it's getting more and more difficult to remember exactly where a certain piece of mail is. What I'd really love to see, is a UA that uses a free text (inverted index) database for storing mail items, and has a reasonably powerful command set for selecting messages. I'd like to be able to use selection criteria like "all messages either to or from person a or b", "all messages where the subject contains the word 'foo'", "the last 30 messages sent", "all messages with the word 'gargleblaster' in the text", "all messages sent by me last monday", and so on... (Of course, the syntax would be different from these examples, and much less verbose.) So, comments, anyone? And, to the elm developers: How major would such a change to the basic mail storage system be; would it mean a more or less total rewrite, or is elm modularized in such a way that it's possible to replace the storage and folder selection system with a different mechanism? Ah, and while I'm posting anyway: There is a simple change I'd like to see in elm. When viewing a mail item on screen, I'd really like to be able to change to a different folder without having to go back to the message list first. (The 'c' key is not used in that situation, so what I do now is something like "'c' <beep> [grumble] 'i' 'c' '=foldername' 'ret'". :-) -tih -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 Postmaster for domain nhh.no. Internet mail: tih@barsoom.nhh.no
nigelm@ohm.york.ac.uk (Nigel Metheringham) (06/21/91)
In <1991Jun20.192712.26853@ccu.umanitoba.ca> grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >>chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>>Finally, a nice touch is [Cymail's] editor. I've seen lots of calls for a >>>simple editor, but no great responses. >>I would love a 'simple' editor to distribute with Elm as a contributed >>product. I am even threatened myself to 'write one' but I don't really >>have the time if I am to get 2.4 out. I also view this as a major >>shortcoming. >How about MicroEMACS? I picked it up off an FTP site (I don't remember which) >and set it up on our systems. Many of our users here use it as an editor for >Elm, and they seem happy with it. It's easy to learn the basics with it >(they had given up on "vi" long ago), and it's got enough power for more >experienced users. I'm happy with it because it's small (disk space is at >a premium on our systems), and because it really cuts down on training time. >I patched version 3.8b to handle ANSI cursor keys, but I've heard that 3.10 >supports cursor keys defined in termcap. I'm not sure that MicroEMACS would be suitable for distribution as a mail editor within elm - although we use it extensively here. The reasons for my lack of enthusiasm are:- + It can be a pain to originally build (I am now using a much hacked version of ME 3.10, with code ripped out of the VMS function key parser and pasted into the Unix termcap driver). + Its quite big - it would make the elm distribution _significantly_ bigger + Its not that customised to handling mail + The syntax is, to non emacs-junkies, rather arcance. My ideal, having had the job of supporting elm (and the general concept of email) to a set of non-techies, is an editor with about a dozen commands total, and those fairly clearly listed on screen. The things that are needed (in no particular order, and with almost certainly some ommisions) include:- + A screen editor with obvious cursor controls + A Find command + Cut & Paste commands + Commands that don't hang up some systems (ie no control-S). + Basic text fill/format (if you are going to be clever, then make it recognise and treat specially quoted text) this includes standard word wrap. + Curses or similar inteface so that the darn thing works on the vast majority of systems I think I'll probably end up writing a script for MicroEMACS which changes its key bindings to make it do what I want - I have already partically done this by adding word wrap and a reformat key to the Mail Editor startup. >While I'm at it, Syd, I'll get my $.02 in for suggested changes to Elm. >I would really like a simple way to abort any command, like hitting Esc. >When users accidentally select something like (b)ounce or (r)eply, it would >be nice if they could quickly cancel the command, rather than having to step >through all the prompts until they finally get to tell Elm to (f)orget it. Agreed - but please not escape - thats the other thing that emacs has really onfused the world with. Programs have real trouble parsing single escape characters if a function key may also be valid. Nigel. -- # Nigel Metheringham # (NeXT) EMail: nigelm@ohm.york.ac.uk # # System Administrator ####### Phone: +44 904 432374 # # Department of Electronics # Fax: +44 904 432335 # # University of York, Heslington, York, UK, YO1 5DD #
tjc@ecs.soton.ac.uk (Tim Chown) (06/21/91)
In <1991Jun20.235134.18095@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >>While I'm at it, Syd, I'll get my $.02 in for suggested changes to Elm. >>I would really like a simple way to abort any command, like hitting Esc. >I would second that one too. That is a standard feature in many packages, including nn. Spending more time reading news (!) I keep finding myself hitting ESC in Elm and getting beeped at ... :-) As for a simple editor Micro Emacs would be my choice too; it gives you easy editing with arrow keys with default insertion and backspace deleting for you. All you need to know are the help and write/quit key sequences. Though on the face of it simple, it is quite powerful and you can progress to full GNU Emacs after a while ... Tim --
cookc@computing-maths.cardiff.ac.uk (Chris Cook) (06/21/91)
In article <1991Jun20.192712.26853@ccu.umanitoba.ca> grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >While I'm at it, Syd, I'll get my $.02 in for suggested changes to Elm. >I would really like a simple way to abort any command, like hitting Esc. >When users accidentally select something like (b)ounce or (r)eply, it would >be nice if they could quickly cancel the command, rather than having to step >through all the prompts until they finally get to tell Elm to (f)orget it. Gets my vote. It's really frustrating if you hit the "q" key, then decide you don't want to quit. Chris
fkk@stasys.sta.sub.org (Frank Kaefer) (06/21/91)
grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: |How about MicroEMACS? I picked it up off an FTP site (I don't remember which) I completely agree. MicroEmacs (3.10) is a great editor. But I think it might be too powerful for Elm. As far as I am concerned, it should be a small and very simple editor (like simped) because if you use MicroEmacs, you can also use Vi or any other editor. Well, here is another idea for ELM: what about a selection menu for the different mailfolders that exist ? It often happens to me the I type "+Oldmails" instead of "+OldMails" - a simple selection menu for all the files would be very nice ! Cheers, Frank -- | Frank Kaefer | fkk@stasys.sta.sub.org | Starnberg, Germany | | Compuserve: 72427,2101 | Internet: fkk@Germany.Sun.COM | | unido!sunde!fkaefer | postmaster@Germany.Sun.COM |
fred@compu.com (Fred Rump) (06/21/91)
syd@DSI.COM (Syd Weinstein) writes: >>chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>Finally, a nice touch is their editor. I've seen lots of callsfor a >>simple editor, but no great responses. >I would love a 'simple' editor to distribute with Elm as a contributed >product. I am even threatened myself to 'write one' but I don't really >have the time if I am to get 2.4 out. I also view this as a major >shortcoming. I simply don't understand why this request keeps coming up for an editor. Doesn't the world out there have a word processor out there that can simply be used in text mode? My point is always NOT to use some other editor. Stay away from vi and use the one thing that you always use to write with. To do otherwise confuses the hell out of ordinary joe/jane user. News, mail and any other written note or letter needs to want the same or very similar functions to keep users using the system. Somehow, doing every task with a different tool escapes me as a goal. fred -- Fred Rump | 'A little learning is a dangerous thing/Drink deep CompuData, Inc. | or taste not the Pierian spring' Alexander Pope 10501 Drummond Rd. | SCO Advanced Product Center Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
syd@DSI.COM (Syd Weinstein) (06/21/91)
les@chinet.chi.il.us (Leslie Mikesell) writes: >SysVr4 mail has the Content-Type:/Content-Length: headers and doesn't >escape lines starting with From in the body. It's likely that there >will be a fairly large installed base of these around very soon. >How about working in at least a tolerance for these messages in the >next release? This was supposed to be in 2.3 (We had a pre-release of the SVR4 concept available to us) but for some reason or another it never made it in. It WILL be in 2.4, and it is one of the things holding up 2.4. Elm will support generation and use of those headers for overall message, but not for attachments (in 2.4). Attachments will have to wait for attachment support in Elm. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
schrod@iti.informatik.th-darmstadt.de (Joachim Schrod) (06/21/91)
In article <2371@stasys.sta.sub.org>, fkk@stasys.sta.sub.org (Frank Kaefer) writes: |> Well, here is another idea for ELM: what about a selection menu for the |> different mailfolders that exist ? It often happens to me the I type |> "+Oldmails" instead of "+OldMails" - a simple selection menu for all |> the files would be very nice ! And another one: List only plain files in ~/Mail, no directories. Or tag the files like ls -F does. -- Joachim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: xitijsch@ddathd21.bitnet Computer Science Department Technical University of Darmstadt, Germany
syd@DSI.COM (Syd Weinstein) (06/21/91)
fkk@stasys.sta.sub.org (Frank Kaefer) writes: >Well, here is another idea for ELM: what about a selection menu for the >different mailfolders that exist ? It often happens to me the I type >"+Oldmails" instead of "+OldMails" - a simple selection menu for all >the files would be very nice ! Elm 2.4 has a wild card listing option on the change folder prompt. If the folder to change to has a wild card in it, 2.4 will run ls -C "%s" (the file name) on it (=prefixes will change dirs to the folder directory first) This will scroll (not page) out the list of possible files. This was added by Steve Simmons -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
rsk@juniper.circ.upenn.edu (Rich Kulawiec) (06/21/91)
In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >I would love a 'simple' editor to distribute with Elm as a contributed >product. Well, I'm bucking the trend here, but I'd rather *not* see any editor as part of Elm. Elm is a mail-reader/sender -- not an editor, not a news reader, not a reminder service, etc. I'd like to see it stay that way rather than have it contract "Emacs disease". As things stand, Elm is capable of calling vi/ex/whatever to the editing work; that seems to be just fine, since it leaves the task of editing to programs designed explicitly for that job. -- ---Rsk rsk@gynko.circ.upenn.edu
adeboer@gjetor.geac.COM (Anthony DeBoer) (06/22/91)
In article <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM writes: >chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>Another complaint is no binary attachments. > >This one has been under discussion since 2.2 was being developed. We >even, internally, floated a proposal about it. No one did anything >with it, partly because the AT&T method, Content-Type:/Content-Length: >for attachments didn't go anywhere and become a 'global' standard, >and at that time, not too much need, compared to now. Plus, at that >time, most mail transports were not 8 bit clean, so the best >we could do would be a uuencoded attachment.... Isn't uuencode a defacto standard? Perhaps a way of improving its interface to Elm would be for the pager to recognise and skip uuencoded files on display, but to tag these as attachments and offer appropriate options (like being able to mkdir/cd to the desired place to park them, from within Elm). My only really major beef with the pager in the current release is the lack of a page-backup key. A line-backup would be nice too. I tried using less as my pager for awhile, but losing the "d" and "j" commands made this a temporary thing. -- Anthony DeBoer NAUI#Z8800 adeboer@gjetor.geac.com Geac Canada Ltd., Toronto uunet!geac!gjetor!adeboer
syd@DSI.COM (Syd Weinstein) (06/22/91)
rsk@juniper.circ.upenn.edu (Rich Kulawiec) writes: >Well, I'm bucking the trend here, but I'd rather *not* see any editor >as part of Elm. Let me clarify... I have no intention of making any editor the only editor Elm supports. I just get lots of requests for a small, simple editor that can be used with Elm and would like to be able to distribute one with Elm. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
john@csrnxt1.ae.utexas.edu (John R. Schutz) (06/22/91)
rsk@juniper.circ.upenn.edu (Rich Kulawiec) writes: >In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >>I would love a 'simple' editor to distribute with Elm as a contributed >>product. >as part of Elm. Elm is a mail-reader/sender -- not an editor, not a >news reader, not a reminder service, etc. If an editor was to be distributed with Elm, there is nothing that would force you to use that editor, just as now there is nothing to force you to use a specific external editor. >Elm is capable of calling vi/ex/whatever to the editing work; Right. Just as it would still be able to if an editor was sent with Elm. At least I would hope so. john -- | John R. Schutz | Email&NeXTmail: | | A learning NeXTie | john@csrnxt1.ae.utexas.edu | | (512)328-0587 | The 23rd periodic element is Vanadium | | 3009 Hatley Dr., Austin, TX 78746 | 'V'. V is roman numeral for 5. Hmmm |
sherman@unx.sas.com (Chris Sherman) (06/22/91)
In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>They complained that Elm doesn't have a "menu". I'd call it a menu, but >>I think what they are looking for is a point and shoot type of thing >>with the current selection in reverse video and the arrow keys in >>control. >Elm does not have that type of menu currently, but a character based >point and shoot menu is under consideration for the character based >front-end for Elm 3.0. Sometimes point and click is fun, but mostly it gets in the way. Elm is something I use many, many times a day, everyday; it didn't take me long to learn the keys. Besides, I like to whip through mail without any cumbersome commands to waste typing on nor complicated screen graphics which fill up the screen or slow the program down. If you add menus, please add a way to shut them off. Other issues: I would like to see one minor, little function added to the builtin pager, a way to page up instead of just down. You could use the Delete button, like nn does. (In fact, nn and elm look so similar, that I sometimes confuse the buttons). Also, for the esc button debate, how about making ^G the escape button (again, like nn). Thanx, -- Chris Sherman .................... sherman@unx.sas.com | ,-----------------------------------------' / Q: How many IBM CPU's does it take to execute a job? | A: Four; three to hold it down, and one to rip its head off.
dave@compnect.UUCP (Dave Ratcliffe) (06/22/91)
In article <1991Jun21.215104.3204@DSI.COM>, syd@DSI.COM (Syd Weinstein) writes: > rsk@juniper.circ.upenn.edu (Rich Kulawiec) writes: > >Well, I'm bucking the trend here, but I'd rather *not* see any editor > >as part of Elm. > Let me clarify... I have no intention of making any editor > the only editor Elm supports. I just get lots of requests for > a small, simple editor that can be used with Elm and would like > to be able to distribute one with Elm. Then allow this humble Admin to cast a vote for Simped as well. While the version I have here is Jay's first release (V 1.0) and it DOES have a few bugs, it still has the simplicity needed for people with no reason to learn Emacs. I exchanged mail with Jay when Simped was released and suggested a couple of enhancements, .sig inclusion for one and not dropping to the command line when an existing file was encountered for another. Both were suggested with an eye towards use with ELM. Unfortunately I've not heard from Jay since the release of 1.0 and mail to him goes unanswered or winds up in byte heaven. Just my $.02 in the editor discussion. Dave [------------------------------------------------------ Dave Ratcliffe -----] : uunet!wa3wbu!compnect!dave | The Data Factory BBS : : dave@compnect.uucp | (717)657-4997 : : compnect!dave@uunet.UU.NET | (717)657-4992 : [------------------------------------------------------ Harrisburg Pa. ----]
chip@osh3.OSHA.GOV (Chip Yamasaki) (06/23/91)
In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>I'll look at it some more and see how the Elm community and developers >>react to a suggestion or two. >I have been told I react poorly to suggestions...... Who says! This looks like a pretty good response to me. >Elm does not have that type of menu currently, but a character based >point and shoot menu is under consideration for the character based >front-end for Elm 3.0. Great. Like I said, I like the current interface. But the less experienced users are crying for the P&S. An option to switch between the two would be a pain to develop and maintain, but would be nice. >>Another complaint is no binary attachments. >This one has been under discussion since 2.2 was being developed. We >even, internally, floated a proposal about it. No one did anything >with it, partly because the AT&T method, Content-Type:/Content-Length: >for attachments didn't go anywhere and become a 'global' standard, >and at that time, not too much need, compared to now. Plus, at that >time, most mail transports were not 8 bit clean, so the best >we could do would be a uuencoded attachment.... But that's just what I was suggesting, a uuencoded attachment. It didn't adhere to any standards, but there were a few nice things about it. 1. It would survive most MTA's (except for size limitations). 2. It could be unpacked almost anywhere. 3. Attachments could be accessed even by non-Elm'ers. 4. It should be a simple addition. As I said. The attach command could be offered on the same menu with (s)end/(f)orget, and the files could be attached just before release to the MTA. Then the only other things to worry about would be a "(F)ile attachment" command on the main menu, and stripping out the attachment and replacing it with "Attached file:<filename>" at the end of the letter before passing it on to the pager/editor. >>Finally, a nice touch is their editor. I've seen lots of callsfor a >>simple editor, but no great responses. >I would love a 'simple' editor to distribute with Elm as a contributed >product. I am even threatened myself to 'write one' but I don't really >have the time if I am to get 2.4 out. I also view this as a major >shortcoming. Yeah, it seems that nobody's got the guts or time (including me) to write such an editor. I recently saw somebody in the PC binaries group flame another person because the Pascal based editor they posted didn't have enough features. Sometimes people forget that there are some entry level users out there to support. >>Another thing I have yet to see is a macro language or API for Elm. >I need some convincing here that an Elm macro language would really >do something and buy you something.... As for API, I am unsure >how that would be used.... I need some 'education' there. Well, with a full featured macro language you could probably do away with most of the wonderful little filters and daemons you include with Elm yet leave the functionality. People could write scripts to THOROUGHLY filter their mail based on combinations of message content, sender, user defined headers, and other combinations of conditions. Another use for a macro language would be to create a mail server based on Elm. I'm sure there are lots of other uses for a macro language and you'll probably hear several from the netters. On the other hand, and API would be nice too. In fact, you could skip the macro language if you had an API. I think in many macro langauges the developers include lots of features that do not deal with the application at hand, but rather things that have to do with macro programming or application building. For example, with a macro language you might have commands to prompt for input, compare logical expressions, display output, etc. With an API you could skip all of this. Let the user get these features from whatever language they are accessing the API from (ASM, C, Perl, etc.), and just concentrate on the mail handling features. Considering Elm is not a commercial product I think all of this is a bit much to ask. Don't think I'm being unreasonable without realizing it. A nice approach to just about all these suggestions would be an Elm engine. This would be a kind of E-Mail UA engine that would form the heart of Elm. Mid-level features like "parse an address" or "get message sender", and high-level features like "mail a message" and "save a message" could be functions of the API. Then the current Elm interface could be separated into a replaceable front-end that would access that API to function exactly like it does now. Then when pesky users like me ask for a feature in the interface you could just say "add it to the interface yourself" or "come up with your own plug-and-play Elm interface". This way the interface could be modified and compatibility would only suffer at the interface. The mail handling features and heart of the application would remain the same. As I said. I know this is all unreasonable, but I thought I'd bring it up. Judging by the number of responses (I haven't read them yet) I'd say that it stirred some discussion. Sorry :-). Thanks! -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------
chip@osh3.OSHA.GOV (Chip Yamasaki) (06/23/91)
In <tih.677489054@barsoom> tih@barsoom.nhh.no (Tom Ivar Helbekkmo) writes: >What I'd really love to see, is a UA that uses a free text (inverted >index) database for storing mail items, and has a reasonably powerful >command set for selecting messages. I'd like to be able to use >selection criteria like "all messages either to or from person a or b", >"all messages where the subject contains the word 'foo'", "the last >30 messages sent", "all messages with the word 'gargleblaster' in >the text", "all messages sent by me last monday", and so on... (Of >course, the syntax would be different from these examples, and much >less verbose.) >So, comments, anyone? And, to the elm developers: How major would >such a change to the basic mail storage system be; would it mean a >more or less total rewrite, or is elm modularized in such a way that >it's possible to replace the storage and folder selection system >with a different mechanism? Well, I think with the API I suggested a user could do all of those things with their own application. The API could offer functions to open_folder() (you could store all your mail in one folder if you wanted), top_of_folder() to go to the first message, next_message() to skip, and things like message_sender() and send_date() to return whatever info you wanted. Then it's just a matter of picking the types of info you wanted to index and coming up with your interface. I think when you start talking about "free text databases" and full featured search engines you are really getting out of the E-Mail business. With the API though you could hook just about anything into Elm and add E-Mail functionality to virtually any application. -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------
chip@osh3.OSHA.GOV (Chip Yamasaki) (06/23/91)
In <1991Jun21.184912.6954@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes: >In article <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM writes: >>chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>>Another complaint is no binary attachments. >> >>This one has been under discussion since 2.2 was being developed. We >>even, internally, floated a proposal about it. No one did anything >>with it, partly because the AT&T method, Content-Type:/Content-Length: >>for attachments didn't go anywhere and become a 'global' standard, >>and at that time, not too much need, compared to now. Plus, at that >>time, most mail transports were not 8 bit clean, so the best >>we could do would be a uuencoded attachment.... >Isn't uuencode a defacto standard? Perhaps a way of improving its interface >to Elm would be for the pager to recognise and skip uuencoded files on >display, but to tag these as attachments and offer appropriate options (like >being able to mkdir/cd to the desired place to park them, from within Elm). Exactly what I was saying, and this is what Cymail does. >My only really major beef with the pager in the current release is the lack >of a page-backup key. A line-backup would be nice too. I tried using less >as my pager for awhile, but losing the "d" and "j" commands made this a >temporary thing. Ditto. I tried it and missed these features. I'd love to see less adapted to work smoothly with Elm. -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------
chip@osh3.OSHA.GOV (Chip Yamasaki) (06/23/91)
In <1991Jun21.215104.3204@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >rsk@juniper.circ.upenn.edu (Rich Kulawiec) writes: >>Well, I'm bucking the trend here, but I'd rather *not* see any editor >>as part of Elm. >Let me clarify... I have no intention of making any editor >the only editor Elm supports. I just get lots of requests for >a small, simple editor that can be used with Elm and would like >to be able to distribute one with Elm. I believe my original suggestion was to EITHER include a simple editor, or suggest one in the docs/README. I do see the point that including an editor would make the distribution larger, and that many people don't want to use a different editor from the one they use now. I also would NEVER suggest (as some people have inferred) that Elm not allow the user to select his/her own editor. A better approach might be for the Elm development group to write a small editor (VERY simple) that has an interface consistant with Elm and post it separately. Then suggest is in the README as a possibility. -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------
tkevans@fallst.UUCP (Tim Evans) (06/23/91)
In <1991Jun21.124644.17668@compu.com> fred@compu.com (Fred Rump) writes: >syd@DSI.COM (Syd Weinstein) writes: > >>chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>>Finally, a nice touch is their editor. I've seen lots of callsfor a >>>simple editor, but no great responses. >>I would love a 'simple' editor to distribute with Elm as a contributed >>product. I am even threatened myself to 'write one' but I don't really >>have the time if I am to get 2.4 out. I also view this as a major >>shortcoming. > I simply don't understand why this request keeps coming up for an > editor. Doesn't the world out there have a word processor out > there that can simply be used in text mode? > I tell my users they can use their standard word processor--WordPerfect-- and show them how to do it. Trouble is, they get right tired of sitting waiting for WP, with all its features, to load, just to write a one- line mail message. MicroEmacs or Mg2a, or other similar programmable editor, seems to me to be the way to go. Just re-bind the basic editing functions so they *look* like your favorite word processor. -- UUCP: {rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans INTERNET: tkevans%fallst@wb3ffv.ampr.org Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047
syd@DSI.COM (Syd Weinstein) (06/23/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >But that's just what I was suggesting, a uuencoded attachment. ... >4. It should be a simple addition. If I remember correctly, from our discussions on this over two years ago (it was a long time ago), it was not a simple addition.... Then, again, until 3.0 when we rewrite Elm, nothing necessarly is a simple addition. Due to its evolving and its non common function based design Elm is currently very convoluted and desperately needs the re-write. >Well, with a full featured macro language you could probably do away >with most of the wonderful little filters and daemons you include with >Elm yet leave the functionality. We have those daemons mostly to cut down on the overhead of running them. Elm is big, and relatively slow to start. For all the filters and daemons you don't necessarly want all the overhead of Elm. >Considering Elm is not a commercial product I think all of this is a bit >much to ask. Don't think I'm being unreasonable without realizing it. >A nice approach to just about all these suggestions would be an Elm >engine. This would be a kind of E-Mail UA engine that would form the >heart of Elm. Mid-level features like "parse an address" or "get >message sender", and high-level features like "mail a message" and "save >a message" could be functions of the API. Gee, has he seen the 3.0 ideas? Thats the only way we can have the different front ends. But having an API that is 'public' also leads to other problems such as support... I am still hesitant and wish to be educated into the proper use for it. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
john@csrnxt1.ae.utexas.edu (John R. Schutz) (06/24/91)
chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >Yeah, it seems that nobody's got the guts or time (including me) to >write such an editor. I am currently working on one. I have no idea whether it will be included with Elm upon completion, but it will be out there. I also really don't know when it will be completed (hopefully soon), due to time limitations. john -- | John R. Schutz | Email&NeXTmail: | | A learning NeXTie | john@csrnxt1.ae.utexas.edu | | (512)328-0587 | The 23rd periodic element is Vanadium | | 3009 Hatley Dr., Austin, TX 78746 | 'V'. V is roman numeral for 5. Hmmm |
les@chinet.chi.il.us (Leslie Mikesell) (06/24/91)
In article <1991Jun20.192712.26853@ccu.umanitoba.ca> grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >While I'm at it, Syd, I'll get my $.02 in for suggested changes to Elm. >I would really like a simple way to abort any command, like hitting Esc. >When users accidentally select something like (b)ounce or (r)eply, it would >be nice if they could quickly cancel the command, rather than having to step >through all the prompts until they finally get to tell Elm to (f)orget it. Most of the comands that prompt for something will automatically abort if you simply leave the field blank. For example, if you hit "b", Elm will prompt with "Send the message to:". If you just hit return, the command will be cancelled. Likewise, "r" will prompt with "Subject: Re: original subject". If you backspace over the proposed subject and hit return, you get a "No subject, continue with message? (y/n)" where you can easily cancel the command. The main exception is hitting "q", where you don't have any way back. I'd agree, though, that it would nice to have Escape cancel any command. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (06/24/91)
In article <1991Jun21.130158.19374@DSI.COM> syd@DSI.COM writes: >It WILL be in 2.4, and it is one of the things holding >up 2.4. Elm will support generation and use of those headers for >overall message, but not for attachments (in 2.4). Attachments >will have to wait for attachment support in Elm. How about an rn-like pipe-to-process for saving/detaching? If Elm itself just observes the "outer" Content-Length: header, it could pipe the entire message off to another program that would know how to extract the pieces and interactively prompt for filenames. The low-level support is already there for pipe-to-process anyway, but it would be nice to have a dedicated command for it. Les Mikesell les@chinet.chi.il.us
fred@compu.com (Fred Rump) (06/24/91)
tkevans@fallst.UUCP (Tim Evans) writes: >I tell my users they can use their standard word processor--WordPerfect-- >and show them how to do it. Trouble is, they get right tired of sitting >waiting for WP, with all its features, to load, just to write a one- >line mail message. I guess our customers write more than a one line message 99% of the time. We do customer support via e-mail and usually the questions need explaining to some extent. Not sure if anyone is using WordPerfect, I doubt it. It may be a hog. 95% use the text mode of Lyrix, the rest MS Word. Lyrix is easy and fast. Even those who upgraded to WORD still use the lyrix text mode for mail and news. Takes about a second or so to bring it up. fred -- Fred Rump | 'A little learning is a dangerous thing/Drink deep CompuData, Inc. | or taste not the Pierian spring' Alexander Pope 10501 Drummond Rd. | SCO Advanced Product Center Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
syd@DSI.COM (Syd Weinstein) (06/25/91)
In article <1991Jun24.145828.3137@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >How about an rn-like pipe-to-process for saving/detaching? If Elm >itself just observes the "outer" Content-Length: header, it could >pipe the entire message off to another program that would know how >to extract the pieces and interactively prompt for filenames. >The low-level support is already there for pipe-to-process anyway, >but it would be nice to have a dedicated command for it. There is already a dedicated command for it. Its called | and it pipes the message, headers and all to any process you'd like. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or dsinc!syd FAX: (215) 938-0235
les@chinet.chi.il.us (Leslie Mikesell) (06/25/91)
In article <1991Jun24.175945.392@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >>How about an rn-like pipe-to-process for saving/detaching? >>The low-level support is already there for pipe-to-process anyway, >>but it would be nice to have a dedicated command for it. >There is already a dedicated command for it. Its called | and it >pipes the message, headers and all to any process you'd like. First, it won't work as-is because ELM needs modifications to allow imbedded nulls, and to ignore lines starting with From within the bounds of a Content-Length: header. That aside, it's not very ELM-like to require the user to know anything about other processes, at least after the initial options are set up. You wouldn't suggest that everyone start using |lp -Dwhatever to print instead of the dedicated "p" command, would you? This would be a good argument for putting macros in ELM, since "bind-key-to" would provide equal or greater functionality compared to coding in a dedicated command and action. A variation of the "|" command that processed tagged messages with a separate invocation of the specified program per message would be nice too. Les Mikesell les@chinet.chi.il.us
tanner@cdis-1.compu.com (Dr. T. Andrews) (06/25/91)
sw-) I would love a 'simple' editor to distribute with Elm ...
fr-) I simply don't understand why this request keeps coming up ...
Easy. The user's word-processing editor tends to leave huge ugly
chunks around, or indent things which it shouldn't, or generate
``long'' lines. Some people don't normally use an editor.
For these folks, we need an alternative. The most common
editor, ``vi'', is lousy. EMACS is too {large, slow, difficult,
good for users:-pick one}. You don't want to know about ``ed''.
--
uflorida!ki4pv!cdis-1!tanner {uunet dsinc}!cdin-1!cdis-1!tanner