bajan@opus.cs.mcgill.ca (Alan Emtage) (07/20/89)
Hi Y'all, I have two (I hope) constructive comments to make about mush. Now, it seems to me that when one starts making suggestions in such small details as below, we must be working with a pretty good product, therefore: (1) I had a situtation recently, which I have had before, where some brain-damaged mailer had mangled the headers of the mail I was getting. Unfortuneately, in curses mode, mush seemed to advertise this fact at times when I couldn't catch what it was complaining about. For example, when reading a letter which was some distance (in the message list sense) from the actual offending piece of mail, mush would inform me of the bad header just after reading the mail (from the pager) and coming back to the curses "menu" (sorry can't think of a better term here), flashing on and off in about a second. With new mail in my box registering on the order of hundreds a day, it takes a while to find out where the "bad" mail is, especially when the mush flashes the warning (of some five or six lines) and it disappears before you can see it. (2) I often suspend mush and come back to it several times a day to see what's new in my mailbox (I try not to use biff whereever possible: too much new mail). However one has to issue at least 2 commands before you can get to the new mail from where you were. One to get it to tell you that there's new mail and a second to get to it. What would The Powers That Be say to the suggestion to replace the "Continue" message that you get when you bring mush back into the foreground with the message about where the new mail is, right then and there ? I realize that these are really small details in what is quite a complicated bit of software but I think (IMHO) that it's these small things which become so important when using the program as often as some of us do. BTW, thanks to the mushers out there who offered suggestions (and help ) the last time I posted a wish list. It's great to know that your'e not just IP'ing out to nothingness. ----------------------------------------------------------------------------- Alan Emtage, "Buying a house is no worse than ants McGill University,CANADA biting your eyes." - D. Barry INTERNET: bajan@cs.mcgill.ca UUCP: mit-eddie!musocs!bajan listmaster@cs.mcgill.ca BITNET: bajan@musocs.BITNET -----------------------------------------------------------------------------
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (07/20/89)
In article <1443@opus.cs.mcgill.ca> bajan@cs.mcgill.ca (Alan Emtage) writes: } } (1) I had a situtation recently, which I have had before, where } some brain-damaged mailer had mangled the headers of the mail I was } getting. Unfortuneately, in curses mode, mush seemed to advertise this } fact at times when I couldn't catch what it was complaining about. There are definitely some problems with curses mode error messages. Ideally, mush would go into "...continue..." mode whenever such a message is printed, so you'd be able to see it. Unfortunately the print routines for the various modes aren't as modular as they ought to be and triggering continue mode is therefore problematic. } For } example, when reading a letter which was some distance (in the message } list sense) from the actual offending piece of mail, mush would inform me } of the bad header just after reading the mail (from the pager) and coming } back to the curses "menu" (sorry can't think of a better term here), } flashing on and off in about a second. This happens because mush frequently re-parses the headers of the "visible" messages when redrawing the curses screen. So the message(s) you have read have only a limited relationship to the messages that are parsed, and the error messages come from the parsing code. Most of the errors reported will be with the "Date:" header, so if you display any part of the date in your hdr_format, you can look for missing or zero fields to find the "bad" messages. } (2) I often suspend mush and come back to it several times a day } to see what's new in my mailbox (I try not to use biff whereever } possible: too much new mail). However one has to issue at least 2 } commands before you can get to the new mail from where you were. That's by design, sort of. Mush executes the just-issued command and THEN looks for new mail. This prevents things like "pick" from wrongly including a newly arrived message. } What } would The Powers That Be say to the suggestion to replace the } "Continue" message that you get when you bring mush back into the } foreground with the message about where the new mail is, right then and } there ? There are lots of problems with suspend/restart. Mush can't tell whether it was suspended in the middle of doing a command, in the middle of running some unix process (such as the editor for composing a message), or when awaiting input; therefore it has a hard time deciding what to do when it is restarted. It doesn't check for new mail when restarted for the same reason it waits until after the "current command" to check. There is a workaround, if you can get used to typing something other than your regular suspend character to stop mush. For example, if your normal suspend character is ^Z, you could suspend mush curses mode with ^X by: bind-macro \CX '[line-mode]stop;await\n' When you restart mush after a ^X, the "await" will automatically pick up any new mail that may have come in. If none has arrived, you will see the line-mode prompt but will not be able to type anything (because await is really still awaiting), so you can at that point suspend again with your normal ^Z. With a little more care you could even figure out how to turn ^Z on and off with stty, and then bind-macro to ^Z instead of ^X, but the way I've suggested here is cleaner and safer. You could also modify the macro to change the prompt before the stop and restore it after the await, so you could more easily tell what was going on. } I realize that these are really small details in what is quite a } complicated bit of software but I think (IMHO) that it's these small } things which become so important when using the program as often as some } of us do. We are working on details like this. The suggestions I made above are about the best we can do WRT suspend/restart. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
jss%greeble@Sun.COM (Josh Sirota) (08/22/89)
In article <4679@freja.diku.dk> bajan@opus.cs.mcgill.ca (Alan Emtage) writes:
: (2) I often suspend mush and come back to it several times a day
:to see what's new in my mailbox (I try not to use biff whereever
:possible: too much new mail). However one has to issue at least 2
:commands before you can get to the new mail from where you were. One to
:get it to tell you that there's new mail and a second to get to it. What
:would The Powers That Be say to the suggestion to replace the
:"Continue" message that you get when you bring mush back into the
:foreground with the message about where the new mail is, right then and
:there ?
Likewise for tool mode. It'd be really nice if when you open the tool it
checked for new mail immediately, as the Sun Mailtool does.
Is that difficult? I haven't looked at the code for it.
Josh
--
Josh Sirota
Sun Microsystems, NSE group
INTERNET: jss@sun.com UUCP: ...!sun!jss