home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!not-for-mail
- From: ophof@SERVER.uwindsor.ca (Scott Ophof)
- Newsgroups: comp.mail.elm
- Subject: Re: "Reply to *typed* address"
- Date: 9 Jan 1993 18:06:33 -0600
- Organization: UTexas Mail-to-News Gateway
- Lines: 71
- Sender: daemon@cs.utexas.edu
- Message-ID: <9301100004.AA10110@SERVER.uwindsor.ca>
- References: <1993Jan8.031147.17559@das.harvard.edu>
- NNTP-Posting-Host: cs.utexas.edu
-
-
- On 8 Jan 1993 03:11:47 GMT adam@endor.uucp (Adam Shostack) said:
- >In article <9301080223.AA22606@SERVER.uwindsor.ca> ophof@SERVER.uwindsor.ca (Scott Ophof) writes:
- >>When one hits "r" from the index screen or while reading an item,
- >>one means "reply to whatever originator/sender/reply-to address is
- >>in the header of this item".
- >>But other than laboriously rewriting the address on the headers
- >>screen, there's no (simple) way to specify a different address.
- >>...
- >How does this differ from forward?
-
- "forward" automatically includes not only the original item, but
- also its headers. That action is not what I want.
-
- The "reply" command automatically assumes an addr as destination
- without giving one the chance to add/change/remove addresses at the
- time the "reply" command is invoked. This action doesn't give me a
- chance to do what I want at the most obvious time in the chain of
- events. Sometimes I reply to an item which has an unreplyable
- return-addr. So I need to change this addr...
-
-
- >>In the doc I have access to, the "r" command is explained, but there
- >>seems to be no "R" command. And "R" isn't recognized by this version
- >>of elm.
-
- >There is no R command. I suggested that it be used to reply to a mail
- >and include the headers and such, which is an occaisonally useful
- >thing to do. It could also be used for R)espond and automatically
- >include the message. Or we could leave it for some future feature.
-
- Yes, I saw the relevant posting, and now understand what you meant
- in your item... ;-)
-
- Let's say that your suggestion and mine were seriously being
- considered for implementation. Assuming insistence on use of
- INTUITIVE ONE-character commands, and if the upper-case "R" is used
- here, then only one of the two suggestions can be implemented.
- Seems like we're already running out of command-space that can be
- used intuitively. (sigh)
-
- But how about a (set of) prefix character(s) to appropriately modify
- the command? Like:
-
- i Include specified address(es)
- t Include the original item
- h Include the original headers
- - Reverse the meaning of the above
-
- Thus "-itr addr" would mean "remove 'addr' from the list of addrs to
- reply to, but include the original text".
- This might be easier than manually editing the relevant field?
- (I know that "i" and "t" are existing commands; I just used those
- characters as examples.)
-
- Which reminds me; maybe add a way to access the "envelop" screen
- before going into edit mode? A version of that screen that still
- leaves most of the previous screen (index or item being read) nicely
- visible? And/or an option for ".elmrc" to *always* show the envelop
- screen after leaving edit mode?
-
- I'd like to add that insistence on 1-char commands does not make it
- easy to keep the command structure simple for the user, nor does it
- in any way help to increase intuitiveness.
-
- Comments?
-
- Regards.
- $$/
-
-
-