duanev@kauai.ACA.MCC.COM (Duane Voth) (10/29/89)
I imagine everyone is feaverishly working on 7.0 but in case there are still programmer cycles left for trivia, here are two bits that bother me. I leave mush running constantly and press return when I want to view new mail. Mush then lists new mail with a message like New mail (#n thru #m) personx date len subject persony date len subject etc... When I have 20 pieces of new mail its a bit of a hassle to count down the new mail list figuring out the number of the letter I want to read first. Could the new-mail list be formatted with hdr_format just like the 'h' command does? Second, sometimes I like to save a letter in some folder and then leave it in my system mailbox along with other unread mail. I have "hold" set but unless I specifically 'preserve' the letter I just 'save'd to the folder, when I quit, the letter gets put in mbox and deleted from my system folder. I guess I'm asking that "hold" be expanded to automatically preserve saved letters. duane -- --- duane voth duanev@mcc.com ---- ALL systems are arbitrary! --- effectiveness is the measure of Truth --
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (10/29/89)
In article <370@kauai.ACA.MCC.COM> duanev@kauai.ACA.MCC.COM (Duane Voth) writes: } } When I have 20 pieces of new mail its a bit of a hassle to } count down the new mail list figuring out the number of the } letter I want to read first. Could the new-mail list be formatted } with hdr_format just like the 'h' command does? On line 330 of signals.c, in function check_new_mail(): 330 char *p2 = compose_hdr(last_msg_cnt++) + 9; Remove this ^^^^ You may also want to fiddle with the sprintf() format on line 336. If you don't want to mess with the source, you can try set newline="await | from" but that "hangs" mush in "await" if you hit newline when there isn't any new mail. (Not necessarily undesirable, I suppose.) } Second, sometimes I like to save a letter in some folder and then } leave it in my system mailbox along with other unread mail. I have } "hold" set but unless I specifically 'preserve' the letter I just } 'save'd to the folder, when I quit, the letter gets put in mbox } and deleted from my system folder. The letter gets saved in mbox? Really? I can't figure out any way that could possibly happen. What should happen is that it gets deleted, and that's it; saved messages are marked for deletion by default. You can set the variable $keepsave to prevent deletion, but they should never get saved to mbox. If you have $autodelete set as well as $hold, odd things happen, but saving in mbox isn't one of them. It isn't documented anywhere that I know of, but setting both $autodelete and $hold doesn't make sense -- neither $keepsave nor $hold nor sleet nor hail will stay $autodelete from its appointed rounds :-) so all read mail will be deleted unless you "preserve" it. By the way, if there is anyone out there who just couldn't go on living without $autodelete, speak now -- we are strongly considering removing it from the next release of mush. } I guess I'm asking that "hold" } be expanded to automatically preserve saved letters. That's what $keepsave is for. If you don't have $autodelete set, try setting $keepsave and see if that's what you want. Otherwise, you can do cmd save 'save \!* | preserve' If you DO have $autodelete set, get rid of it. You'll still need $keepsave, but at least your .mushrc will make more sense. ;-) -- Bart Schaefer "A Yellowbeard is never so dangerous as when he's dead." -- Graham Chapman, 1941-1989 UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer Internet schaefer@cse.ogc.edu (soon to be cse.ogi.edu)
duanev@kauai.ACA.MCC.COM (Duane Voth) (10/31/89)
In article <5334@ogccse.ogc.edu>, schaefer@ogccse.ogc.edu (Barton E. Schaefer) writes: > In article <370@kauai.ACA.MCC.COM> duanev@kauai.ACA.MCC.COM (Duane Voth) writes: > } sometimes I like to save a letter in some folder and then > } leave it in my system mailbox along with other unread mail. I have > } "hold" set but unless I specifically 'preserve' the letter I just > } 'save'd to the folder, when I quit, the letter gets put in mbox > } and deleted from my system folder. > > The letter gets saved in mbox? Really? I can't figure out any way that > could possibly happen. What should happen is that it gets deleted, and > that's it; saved messages are marked for deletion by default. You can > set the variable $keepsave to prevent deletion, but they should never > get saved to mbox. I must have been dreaming - I can't reproduce this. Bart, you are still quite sane. So $keepsave does what I want eh? Damn. This has happened to me too many times! Rtfm is on everybodys mind (mine too) yet a small voice in my head demands to say something in my defence: can anybody think of a way to organize the Mush docs so that related features/variables/ commands are somehow tied together? I'm tired of wasting peoples time! duane
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (10/31/89)
In article <372@kauai.ACA.MCC.COM> duanev@kauai.ACA.MCC.COM (Duane Voth) writes: } In article <5334@ogccse.ogc.edu>, schaefer@ogccse.ogc.edu (Barton E. Schaefer) writes: } > In article <370@kauai.ACA.MCC.COM> duanev@kauai.ACA.MCC.COM (Duane Voth) writes: } } Bart, you are still quite sane. Don't make assertions you may not be able to substantiate. :-) } This has happened to me too many times [....] can anybody think } of a way to organize the Mush docs so that related features/variables/ } commands are somehow tied together? This sort of thing is definitely a problem, and if anybody has any good solutions we [%] would be glad to hear of them. A reorganization of the Mush man page is on the to-do list, but probably won't make it into the next release. However, some changes have already been made that should help remedy this problem: 1) "Multivalued" variables. This means variables whose "string" value is a space-or-comma-separated list of keywords. Related concepts are thereby grouped under a single name. For example, the variable $quiet has been expanded from a simple boolean to a multivalued variable whose keywords designate suppression of messages (startup, autosign, fortune) and/or error bells (await, completion, tool). [%%] 2) Cross-referencing in the on-line help. Whenever help entries have been changed or added, a list of variables related to the command in question has been appended to the help paragraph. This has not yet propagated to all the help entries where it would be useful, but it's a step in the right direction. ____________ % I take the liberty of answering for Dan on this one. %% Comment for 7.0 alpha testers: the multivalued variable $bell is going away; it's functions have been inverted and moved to $quiet. ____________ There are obviously some limitations to both of the above schemes. Multivalued variables have so far been limited mostly to new features, because of "backwards compatibility" issues; in the case of $keepsave, this goes all the way back to UCBmail variables. Cross-referencing variables through commands has the drawback of missing the variables that aren't directly related to any command (though the only one I can think of at the moment is $newline). -- Bart Schaefer "A Yellowbeard is never so dangerous as when he's dead." -- Graham Chapman, 1941-1989 UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer Internet schaefer@cse.ogc.edu (soon to be cse.ogi.edu)