jss%greeble@Sun.COM (Josh Sirota) (09/20/89)
I think this is a bug: If you delete the last message in your mailbox, it continues to be the current message although it doesn't really exist. So, typing 't' or 'p' or 'r' or any of those common things accesses this supposedly nonexistent message. Wouldn't it make more sense if upon deletion of the last message in the mailbox, the current message is switched to the second-to-last one? Josh -- Josh Sirota Sun Microsystems, NSE group INTERNET: jss@sun.com UUCP: ...!sun!jss
loverso@Xylogics.COM (John Robert LoVerso) (09/20/89)
On the same vein of possible problems with deleted messages and
the current message pointer: Using curses mode, say I've got a
list of deleted messages that I've also saved in various ways such
that the S flag is set. If I undelete the message, mush moves the
current message pointer to the next message following the deleted
messages which hasn't been S'd. This is annoying, because I
sometimes backtrack to a saved&deleted message to look at it again,
and mush goes off and assumes it knows better than me which message
I want. This is irregardless of the setting of `autoprint', btw.
Oh, I just discovered out my +rr and -rr map!ings (see earlier
ravings about ~ commands) are rendered effectiveless by edit_hdrs,
as mush apparently builds headers once and then never changes
them(*) when edit_hdrs is set. This seems to be an offshoot of
the same problem with ~h and friends when edit_hdrs is in effect.
The obvious solution is to add the R-R-T header in the editor (I
am now), but this requires the addition of a macro in the editor
to define this in an appropriate, mail-composition-only way.
As a question to Dan or Bart: how `alpha' is 7.0 for those non-sunview
users among us?
John <LoVerso@Xylogics.COM>
(*) There is an exception to this, the `From:' header, which I wish
mush would either not supply (sendmail would do it right) or let
me supply it as `From: "Full User Name" <mailbox>'. I detest the
`(Full User Name) mailbox' form, as in the latter the () surround
a comment that mail system gateways (into X.400, for instance) are
allowed to discard at will. When I had more time, I'd go in and
rip and tear the From: code in mush, but I've got bits to push!schaefer@ogccse.ogc.edu (Barton E. Schaefer) (09/20/89)
In article <124974@sun.Eng.Sun.COM> jss@sun.Eng (Josh Sirota) writes: } I think this is a bug: } } If you delete the last message in your mailbox, it continues to be the } current message although it doesn't really exist. So, typing 't' or 'p' or } 'r' or any of those common things accesses this supposedly nonexistent } message. } } Wouldn't it make more sense if upon deletion of the last message in the } mailbox, the current message is switched to the second-to-last one? Probably. The closest thing you can get at the moment is switching the message to the *first* (non-deleted) one, by using "set wrap". Mush's find-the-next-message code does not presently know how to search "backwards". It is pretty much assumed that you have sorted your messages in the order you want to deal with them, so moving backwards isn't needed. (I realize this may be an incorrect assumption). In article <8909200236.AA16186@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes: } } On the same vein of possible problems with deleted messages and } the current message pointer: Using curses mode, say I've got a } list of deleted messages that I've also saved in various ways such } that the S flag is set. If I undelete the message, mush moves the } current message pointer to the next message following the deleted } messages which hasn't been S'd. This is annoying, because I Hopefully this happens only at the ...continue... prompt, or something is really messed up. Something is STILL messed up -- undeletion should not change the current message -- so I will look into it. } sometimes backtrack to a saved&deleted message to look at it again, } and mush goes off and assumes it knows better than me which message } I want. This is irregardless of the setting of `autoprint', btw. It's also regardless of show_deleted, which I had originally thought would have an effect. Ah, well ... } Oh, I just discovered out my +rr and -rr map!ings (see earlier } ravings about ~ commands) are rendered effectiveless by edit_hdrs, } as mush apparently builds headers once and then never changes } them(*) when edit_hdrs is set. Correct. } This seems to be an offshoot of } the same problem with ~h and friends when edit_hdrs is in effect. There's a time-and-effort vs. functionality tradeoff here. In order to allow tilde-commands (even ~:commands) to change the headers when edit_hdrs is set, mush would have to: 1) Put the headers into a new temp file and append the rest of the message so far, then start the editor; 2) Read the headers from the temp file into the internal structures and copy the rest of the message back to a header-less file; 3) Repeat steps 1 and 2 *every time a ~v is issued*. This is deemed (a) too many temp files to mess with and (b) too slow on too many systems. Believe me, there was a GREAT deal of discussion about this among the authors and other mush users before the decisions were made to do it differently. So what mush does instead is: 1) Put all the headers into a temp file and either start the editor or append whatever is typed to that file; 2) Read the headers out of the file ONCE just before sending, to make sure they have some semblance of the right format. and you are then stuck with adding any headers you want either before you give the "mail" command, or from within the editor. } As a question to Dan or Bart: how `alpha' is 7.0 for those non-sunview } users among us? If you aren't running System V, it's probably "beta" or better. There are going to be a number of changes (I have touched 8 files since the 7.0 alpha announcement, some of them with changes that have been discussed in this forum). (Note the time of night at which I am posting this. ;-) } (*) There is an exception to this, the `From:' header, which I wish } mush would either not supply (sendmail would do it right) or let } me supply it as `From: "Full User Name" <mailbox>'. If you compile with -DPICKY_MAILER, mush will not supply From: (it will appear in the editor file as it does now but will be removed when the file is copied to the MTA). In the 6.5.6.9+ beta and 7.0 alpha versions, you can use "my_hdr From: whatever" to specify the From: line in any form you happen not to detest :-) and mush will only change it if the address is "wrong" (e.g. no address, an obvious [%] forgery, or garbage). ____________ % When I say obvious, I mean REALLY obvious. There's only so much mush can figure out; you can fool it if you try. It is left up to the MTA to insert Sender: or other "authentification" headers if the From: line is questionable. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
loverso@Xylogics.COM (John Robert LoVerso) (09/20/89)
> Hopefully this happens only at the ...continue... prompt Yes. > There's a time-and-effort vs. functionality tradeoff here. In order > to allow tilde-commands (even ~:commands) to change the headers when > edit_hdrs is set, mush would have to: Understood; then perhaps it would be best get them out of the ~? display when edit_hdrs is defined (since they are useless). John