mark@cbnewsu.att.com (Mark Horton) (10/03/90)
I notice the following problems in MUSH: The "alternates" feature does not seem to work. If I say ":alternates" in curses mode it lists them from my .mushrc correctly, but when I reply all it still sends a copy to me. When using mushtool, when I press "done" it closes the window down OK, but it moves the current message to the last preserved message, marking it read. I have to manually preserve it each time I open the window. When replying, if I forget to press "send" (or miss it) and then press "close", the reply window goes away and so does the reply button! I found that by getting a menu on any random message and selecting "reply" I can get it back (although it won't reply) but there's no visible icon or any other normal way to get it back. Are these bugs fixed (I have 7.1.1) anywhere, or are there workarounds better than manually deleting my name and manually preserving? General gripe: in curses mode, the interface looks and feels very much like rn, but many things that work in rn that could reasonably work in mush don't. In particular, when I'm paging through a long message and have a "more" at the bottom, I would like to be able to issue commands like "n" or "r" without having to "q" first. I can do this in mushtool but not in curses mode. Sure would be nice if, in curses mode at the main message menu, j and k would work at the bottom and top of the screen ala vi. Currently I have to z or Z- which is inconvenient (and inconsistent from vi.) Thanks, Mark
argv@turnpike.Eng.Sun.COM (Dan Heller) (10/03/90)
In article <1990Oct2.170734.17606@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: > The "alternates" feature does not seem to work. If I say ":alternates" > in curses mode it lists them from my .mushrc correctly, but when I reply > all it still sends a copy to me. You're not specific enough. It does work, you're just not setting the right alternates values :-). Let me give an example of what I do for myself (my .mushrc). alts * !cory.berkeley.edu!dheller !ora.ora.com!danh !comp-sources-x The * implies "argv everywhere". That is, if I reply to a message and it sees "argv" as a user name, it gets removed no matter where it's going. The next case: !cory.berkeley.edu!dheller indicates that I have an account on cory.berkeley.edu with the login of dheller. So, no matter what the path is, if it *ends up* at that host and machine, then remove it from the list. The leading ! implies that any path up to cory is irrelevant. The same thins is true for and ora.ora.com!danh. In the last case, !comp-sources-x means any mail addressed to that user no matter what the path... Since I am the moderator for comp.sources.x, people that mail to me will have that address, not "argv". I can reply to them and not send myself a copy of the message. In patch #3 that will soon be available, you will be able to specify the @-style format such as: dheller@cory.berkeley.edu This is a "convenience" for the user -- it'll just internally use the bang-formats discussed above. I think bart and I are also planning on supporting *user to imply the same thing as !user now... > When using mushtool, when I press "done" it closes the window down OK, > but it moves the current message to the last preserved message, marking > it read. I have to manually preserve it each time I open the window. There has always been a bunch of bantering about back and forth on what to do about "preserve". I'll let bart answer this one. I agree that its an inconvenience.... all things considered, this is not a trivial problem to solve. > When replying, if I forget to press "send" (or miss it) and then press > "close", the reply window goes away and so does the reply button! You can still hit the <compose> button, can't you? That's just there to bring up the compose window -- not necessarily to invoke a new composition. This should have the same effect that your workaround provides: > found that by getting a menu on any random message and selecting "reply" > I can get it back (although it won't reply) but there's no visible icon > or any other normal way to get it back. If the <compose> button is also disabled, then we have a problem. > General gripe: in curses mode, the interface looks and feels very much > like rn, Really?! Ugh, then there *IS* a bug! :-) (seriously, that was never intentional -- it could be just the way you've set things up). > In particular, when I'm paging through a long message and > have a "more" at the bottom, I would like to be able to issue commands > like "n" or "r" without having to "q" first. I can do this in mushtool > but not in curses mode. The disadvantage to "rn" is that you have to use *their* pager. I hate that and I think most will agree that it is better for you to specify your own pager (more, less, pg, etc..) than to not be given a choice. Thus, you are never going to have the capability you are asking for here. *However* there is something almost as good. When you are paging the message and the pager is done (you've hit 'q'), and you are given a "...continue..." prompt, you *can* issue a new curses mode command and you do not have to return to the toplevel menu. > Sure would be nice if, in curses mode at the main message menu, j and k > would work at the bottom and top of the screen ala vi. Currently I > have to z or Z- which is inconvenient (and inconsistent from vi.) This is true, but vi is tuned to take full advantage of the capabilties of the screen. Mush just uses those curses(3X) commands that are most portable across all versions of unix (that we've found). We cannot do reverse scrolling reliably (which would give you your desired effect) and be assured that it works everywhere. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
del@thrush.mlb.semi.harris.com (Don Lewis) (10/03/90)
In article <1990Oct2.170734.17606@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: >When using mushtool, when I press "done" it closes the window down OK, >but it moves the current message to the last preserved message, marking >it read. I have to manually preserve it each time I open the window. Yeah, this is annoying, but the flip side is that if you opened the window in response to incoming mail, it sure is nice that it automatically displays the first new message. I suspect that since I set the hold variable, I find the overall behavior less annoying than you. > >When replying, if I forget to press "send" (or miss it) and then press >"close", the reply window goes away and so does the reply button! I >found that by getting a menu on any random message and selecting "reply" >I can get it back (although it won't reply) but there's no visible icon >or any other normal way to get it back. I get bitten by this occasionally, too. I find it annoying to discover that I never sent out the message that I composed several hours ago. An easier way to get the compose frame back is to hit the Compose button. Mush will whine that you have to finish your first letter and will pop up the compose frame. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
schaefer@ogicse.ogi.edu (Barton E. Schaefer) (10/03/90)
In article <1990Oct2.170734.17606@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: } I notice the following problems in MUSH: } } The "alternates" feature does not seem to work. If I say ":alternates" } in curses mode it lists them from my .mushrc correctly, but when I reply } all it still sends a copy to me. You probably have $metoo set. Mush will continue to include you in replies if that variable is set. } General gripe: in curses mode, the interface looks and feels very much } like rn, but many things that work in rn that could reasonably work in } mush don't. In particular, when I'm paging through a long message and } have a "more" at the bottom, I would like to be able to issue commands } like "n" or "r" without having to "q" first. I can do this in mushtool } but not in curses mode. That's because mush doesn't have any sophisticated pager built in. You get either an extremely simple pager (the code is about 30 lines) or your usual pager process (more, less, pg, etc.). Obviously, you can't issue mush commands from the middle of a forked-off paging process, so it would be confusing to allow it from the built-in pager. } Sure would be nice if, in curses mode at the main message menu, j and k } would work at the bottom and top of the screen ala vi. Currently I } have to z or Z- which is inconvenient (and inconsistent from vi.) Problem: Many curses implementations do not perform scrolling properly, even if the terminal supports "scrolling regions", which many don't. Mush would have to redraw the whole screen when the j passed the bottom or the k passed the top. Since this can be rather slow (depending on baud rates) mush doesn't want to do it "accidentally" if you happen to hit j or k one or two times more often than is necessary to get you to the message you want. In article <1990Oct3.025026.3297@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: } In article <1990Oct2.170734.17606@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: } >When replying, if I forget to press "send" (or miss it) and then press } >"close", the reply window goes away and so does the reply button! I } >found that by getting a menu on any random message and selecting "reply" } >I can get it back (although it won't reply) but there's no visible icon } >or any other normal way to get it back. } } I get bitten by this occasionally, too. I find it annoying to discover } that I never sent out the message that I composed several hours ago. } An easier way to get the compose frame back is to hit the Compose button. } Mush will whine that you have to finish your first letter and will pop } up the compose frame. We've discussed having a variable or some such that would send when you close the frame, automatically. But there are times when you might *want* to close the frame without sending ... sorry if it isn't obvious enough that hitting <Compose> again will bring back the window ... I suppose supplying some kind of compose window icon would be better. -- Bart Schaefer schaefer@cse.ogi.edu
del@thrush.mlb.semi.harris.com (Don Lewis) (10/03/90)
In article <12573@ogicse.ogi.edu> schaefer@ogicse.ogi.edu (Barton E. Schaefer) writes: >In article <1990Oct3.025026.3297@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: >} In article <1990Oct2.170734.17606@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: >} >When replying, if I forget to press "send" (or miss it) and then press >} >"close", the reply window goes away and so does the reply button! I >} >found that by getting a menu on any random message and selecting "reply" >} >I can get it back (although it won't reply) but there's no visible icon >} >or any other normal way to get it back. >} >} I get bitten by this occasionally, too. I find it annoying to discover >} that I never sent out the message that I composed several hours ago. >} An easier way to get the compose frame back is to hit the Compose button. >} Mush will whine that you have to finish your first letter and will pop >} up the compose frame. > >We've discussed having a variable or some such that would send when >you close the frame, automatically. But there are times when you might >*want* to close the frame without sending ... sorry if it isn't obvious >enough that hitting <Compose> again will bring back the window ... I >suppose supplying some kind of compose window icon would be better. I don't believe that it is possible to close a subframe to an icon in Sunview. Another possibility would be to make both the Reply and Compose buttons invisible, and make a "Continue Editing" button visible when editing is in progress and the compose subframe has been closed. This new button would open the compose subframe and not print the warning message. While we are on this subject, I'd like to mention that a mushtool user here mentioned that it would be convenient to have a way to open the compose frame to compose message while leaving the main frame closed to an icon. It sounds like a great idea to me since it can take quit a while to open the tool in order to just hit the Compose button. I often find myself just using Mail from a shelltool window instead. Probably the cleanest way to do this is by creating a new toplevel frame menu. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
mark@cbnewsu.att.com (Mark Horton) (10/04/90)
Bart - thanks for the fast response! In article <12573@ogicse.ogi.edu>, schaefer@ogicse.ogi.edu (Barton E. Schaefer) writes: > } The "alternates" feature does not seem to work. > You probably have $metoo set. Mush will continue to include you in > replies if that variable is set. I popped up the "options" button and it says "metoo" is "false". Yet every reply still goes to any alias even though it's me. > } General gripe: in curses mode, the interface looks and feels very much > } like rn, > > That's because mush doesn't have any sophisticated pager built in. > You get either an extremely simple pager (the code is about 30 lines) > or your usual pager process (more, less, pg, etc.). Obviously, you > can't issue mush commands from the middle of a forked-off paging > process, so it would be confusing to allow it from the built-in pager. rn uses a built-in pager (public domain code - you could snarf it) which apparently pops you out to the top level for unrecognized commands. I have "set PAGER=/usr/ucb/more" in both my .mushrc and .mailrc, but yet I seem to get the built-in pager when I use mush -C. This built-in pager should be smart enough to pop out to top level when it gets something it doesn't recognize, especially r, n, or s. I certainly understand that you aren't going to teach an external pager ala more to understand them. > } Sure would be nice if, in curses mode at the main message menu, j and k > } would work at the bottom and top of the screen ala vi. Currently I > } have to z or Z- which is inconvenient (and inconsistent from vi.) > > Problem: Many curses implementations do not perform scrolling properly, > even if the terminal supports "scrolling regions", which many don't. > Mush would have to redraw the whole screen when the j passed the bottom > or the k passed the top. Since this can be rather slow (depending on > baud rates) mush doesn't want to do it "accidentally" if you happen > to hit j or k one or two times more often than is necessary to get you > to the message you want. You have -DSYSV to tell at compile time whether you have the System V curses, which can scroll efficiently, or the Berkeley curses, which can't. (Of course, mush won't compile with -DSYSV on a Sun, it's apparently never been tested under /usr/5bin/cc - this needs to be taken care of.) It would not be hard to #ifdef SYSV around conditional scrolling code, or better yet, have an option similar to vi's "slowopen" which defaults differently depending on #ifdef SYSV, to control what happens when you j/k off the edge of the screen. At 9600 BPS even on a Berkeley system it may be very reasonable to repaint the whole screen - you sure do it easily when the user hits space. (I wish space went on to the next message ala n, and <CR> or <ESC> or something put you back in the top level menu.) Once you do scroll on a slow system, of course, you should scroll half a page at a time so you don't do this quadratically. > In article <1990Oct3.025026.3297@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: > } In article <1990Oct2.170734.17606@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: > } >When replying, if I forget to press "send" (or miss it) and then press > } >"close", the reply window goes away and so does the reply button! I > } >found that by getting a menu on any random message and selecting "reply" > } >I can get it back (although it won't reply) but there's no visible icon > } >or any other normal way to get it back. > } > } I get bitten by this occasionally, too. I find it annoying to discover > } that I never sent out the message that I composed several hours ago. > } An easier way to get the compose frame back is to hit the Compose button. > } Mush will whine that you have to finish your first letter and will pop > } up the compose frame. > > We've discussed having a variable or some such that would send when > you close the frame, automatically. But there are times when you might > *want* to close the frame without sending ... sorry if it isn't obvious > enough that hitting <Compose> again will bring back the window ... I > suppose supplying some kind of compose window icon would be better. An icon for the compose window would be a big improvement. I note that mushtool makes you confirm lots of other things, such as sending out a message in the first place, or saving it to a file. Closing the compose window without pressing send first is unusual and ought to require a confirmation. Personally I would prefer to turn off these confirmations - have <send> automatically <close> the compose window, and not bother with confirmations when you save a file. (Is there an option I can set for this?) Lacking an icon, you could put a message in the message window saying to bring it back up press <compose>. Another general comment: I spend a lot of time with my mouse in mushtool carefully positioning it all over the place - lots of wasted motion, and lots of energy keeping it on that tiny little diamond when I'm paging through a message. A <page-forward> button near <next> would be very nice, even better if hitting space in the same window had the same effect. Mark
del@thrush.mlb.semi.harris.com (Don Lewis) (10/04/90)
In article <1990Oct3.172900.28233@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: >I note that mushtool makes you confirm lots of other things, such as sending >out a message in the first place, or saving it to a file. Closing the >compose window without pressing send first is unusual and ought to require >a confirmation. Personally I would prefer to turn off these confirmations - >have <send> automatically <close> the compose window, and not bother with Maybe the same with <abort> too. >confirmations when you save a file. (Is there an option I can set for this?) >Another general comment: I spend a lot of time with my mouse in mushtool >carefully positioning it all over the place - lots of wasted motion, and >lots of energy keeping it on that tiny little diamond when I'm paging through >a message. A <page-forward> button near <next> would be very nice, even >better if hitting space in the same window had the same effect. Try j, k, ^d, ^u, ^f, ^b, the up and down arrow keys, R7 and R13. Sorry, no space though. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
schaefer@ogicse.ogi.edu (Barton E. Schaefer) (10/05/90)
In article <1990Oct3.172900.28233@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: } Bart - thanks for the fast response! } } In article <12573@ogicse.ogi.edu>, schaefer@ogicse.ogi.edu (Barton E. Schaefer) writes: } > } The "alternates" feature does not seem to work. } > You probably have $metoo set. Mush will continue to include you in } > replies if that variable is set. } } I popped up the "options" button and it says "metoo" is "false". } Yet every reply still goes to any alias even though it's me. In article <143274@sun.Eng.Sun.COM> argv@turnpike.Eng.Sun.COM (Dan Heller) writes: } You're not specific enough. It does work, you're just not setting } the right alternates values :-). Let me give an example of what I do } for myself (my .mushrc). } } alts * !cory.berkeley.edu!dheller !ora.ora.com!danh !comp-sources-x If you're still having problems after trying Dan's examples, send me the alternates line from your .mushrc. Back to mark@cbnewsu.att.com (Mark Horton): } rn uses a built-in pager (public domain code - you could snarf it) which } apparently pops you out to the top level for unrecognized commands. Actually, thinking about it, it wouldn't be very difficult to add to mush. Try this. The following lines are from misc.c (7.1.2 version): 555 while ((c = getchar()) >= 0 && c != CTRL('D') && !isspace(c) && 556 c != '\n' && c != '\r' && lower(c) != 'q' && lower(c) != 'd') 557 bell(); Change line 557 to: if (iscurses) { m_ungetc(c); c = 'q'; } else bell(); and let me know how that works. } I have "set PAGER=/usr/ucb/more" in both my .mushrc and .mailrc, but yet } I seem to get the built-in pager when I use mush -C. That's odd. Oh, wait! Mush doesn't have a local variable named PAGER. It recognizes the *environment* variable PAGER and the local variable pager. So you need either set pager=/usr/ucb/more or setenv PAGER /usr/ucb/more in your .mushrc. } > } Sure would be nice if, in curses mode at the main message menu, j and k } > } would work at the bottom and top of the screen ala vi. } > } > Problem: Many curses implementations do not perform scrolling properly, } > even if the terminal supports "scrolling regions", which many don't. } } You have -DSYSV to tell at compile time whether you have the System V } curses, which can scroll efficiently, or the Berkeley curses, which can't. That's not quite good enough. There are other systems besides SVR2 that use the SYSV define, that have curses packages just as messed up as Berkeley's. } (Of course, mush won't compile with -DSYSV on a Sun, it's apparently never } been tested under /usr/5bin/cc - this needs to be taken care of.) We just got mail from someone who compiled it under SysV on the Sun. Hm. I don't think I saved the message. Anyway, /usr/5bin/cc at least on pre- 4.x suns has a badly broken preprocessor, which can't handle some of the #if constructs that are handled correctly by every other SysV mush has been compiled on (which is most of them). We aren't going to go through the major effort required to rewrite all our preprocessing directives for that one case when the alternative of /bin/cc is available. } (I wish space went on to the next message ala } n, and <CR> or <ESC> or something put you back in the top level menu.) bind ' ' display-next unbind '\n' unbind '\E' } An icon for the compose window would be a big improvement. As Don Lewis mentioned, it probably isn't possible, because the compose window is not its own process -- its just a child window in its own frame. In article <1990Oct4.062156.24647@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: } In article <1990Oct3.172900.28233@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: } >I note that mushtool makes you confirm lots of other things, such as sending } >out a message in the first place, or saving it to a file. Closing the } >compose window without pressing send first is unusual and ought to require } >a confirmation. Personally I would prefer to turn off these confirmations - } >have <send> automatically <close> the compose window, and not bother with } } Maybe the same with <abort> too. Does <Abort> ask for confirmation? Hmm. (Can you tell I don't use a Sun very often?) Anyway, in 7.1.2 (as opposed to 7.1.1, which I think Mark still has) the variable "verify" has become multi-valued, and has a field "save" that controls whether you are asked about saves to a file. The others could be added as well, we'll consider it. } >Another general comment: I spend a lot of time with my mouse in mushtool } >carefully positioning it all over the place - lots of wasted motion, and } >lots of energy keeping it on that tiny little diamond when I'm paging through } >a message. A <page-forward> button near <next> would be very nice, even } >better if hitting space in the same window had the same effect. That's sort of wryly amusing, because there used to be such a button, but we removed it when the scrollbars went in. As Don says, though: } Try j, k, ^d, ^u, ^f, ^b, the up and down arrow keys, R7 and R13. Sorry, } no space though. -- Bart Schaefer schaefer@cse.ogi.edu
mark@cbnewsu.att.com (Mark Horton) (10/05/90)
In article <143274@sun.Eng.Sun.COM>, argv@turnpike.Eng.Sun.COM (Dan Heller) writes: > alts * !cory.berkeley.edu!dheller !ora.ora.com!danh !comp-sources-x Aha! That's the secret. Silly me, I figured that since all the mail addresses on my Sun are user@domain format, that putting the exact-string-match user@domain in the alternates list would do it. I flipped them around and stuck a ! on the front and now it works! Thanks! > In patch #3 that will soon be available, you will be able to specify > the @-style format such as: > dheller@cory.berkeley.edu > This is a "convenience" for the user -- it'll just internally use the > bang-formats discussed above. I think bart and I are also planning > on supporting *user to imply the same thing as !user now... This seems like a reasonable thing to do since user@host is the standard format that most people use these days. > > When using mushtool, when I press "done" it closes the window down OK, > > but it moves the current message to the last preserved message, marking > > it read. I have to manually preserve it each time I open the window. > > There has always been a bunch of bantering about back and forth on > what to do about "preserve". I'll let bart answer this one. I agree > that its an inconvenience.... all things considered, this is not a > trivial problem to solve. Somehow mailtool manages to do it. > > When replying, if I forget to press "send" (or miss it) and then press > > "close", the reply window goes away and so does the reply button! > You can still hit the <compose> button, can't you? That's just there to > If the <compose> button is also disabled, then we have a problem. Yes, <compose> works, it just wasn't obvious that I should press it. You view <compose> as meaning "pop up the compose window", I view it as meaning "I want to send a new piece of mail". I suspect users are more likely to make the latter interpretation. > > In particular, when I'm paging through a long message and > > have a "more" at the bottom, I would like to be able to issue commands > > like "n" or "r" without having to "q" first. I can do this in mushtool > > but not in curses mode. > > The disadvantage to "rn" is that you have to use *their* pager. I seem to get mush's pager no matter what I ask for. But that's OK - I don't really want a separate pager, it takes too long to start up. I just want the built-in pager to do something reasonable (not just beep) when I type a mush command at it. I realize this is hard to do if you use your own pager, but for the built-in one that I get anyway it should be easy. > > Sure would be nice if, in curses mode at the main message menu, j and k > > would work at the bottom and top of the screen ala vi. Currently I > > have to z or Z- which is inconvenient (and inconsistent from vi.) > This is true, but vi is tuned to take full advantage of the capabilties > of the screen. Mush just uses those curses(3X) commands that are most > portable across all versions of unix (that we've found). We cannot do > reverse scrolling reliably (which would give you your desired effect) > and be assured that it works everywhere. Are there bugs in screen scrolling on the BSD curses? Or is it just slow to scroll backwards? I think even the BSD curses will scroll the whole screen forward a line if you set scrollok to true. Mark
del@thrush.mlb.semi.harris.com (Don Lewis) (10/05/90)
In article <12635@ogicse.ogi.edu> schaefer@ogicse.ogi.edu (Barton E. Schaefer) writes: >In article <1990Oct4.062156.24647@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: >} In article <1990Oct3.172900.28233@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: >} >I note that mushtool makes you confirm lots of other things, such as sending >} >out a message in the first place, or saving it to a file. Closing the >} >compose window without pressing send first is unusual and ought to require >} >a confirmation. Personally I would prefer to turn off these confirmations - >} >have <send> automatically <close> the compose window, and not bother with >} >} Maybe the same with <abort> too. > >Does <Abort> ask for confirmation? Hmm. (Can you tell I don't use a Sun >very often?) Anyway, in 7.1.2 (as opposed to 7.1.1, which I think Mark >still has) the variable "verify" has become multi-valued, and has a field >"save" that controls whether you are asked about saves to a file. The >others could be added as well, we'll consider it. <Abort> doesn't ask for confirmation, but I was thinking that maybe it should also close the compose window. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
argv@turnpike.Eng.Sun.COM (Dan Heller) (10/08/90)
In article <1990Oct4.212140.11006@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: > > In patch #3 that will soon be available, you will be able to specify > > the @-style format such as: > > dheller@cory.berkeley.edu > > This is a "convenience" for the user -- it'll just internally use the > > bang-formats discussed above. I think bart and I are also planning > > on supporting *user to imply the same thing as !user now... > > This seems like a reasonable thing to do since user@host is the standard > format that most people use these days. But the bang-form is a superset of the @-format (in this context). Anyway, as long as you can specify the @-format style, you needn't really worry about the internal storage. > > > When replying, if I forget to press "send" (or miss it) and then press > > > "close", the reply window goes away and so does the reply button! > > You can still hit the <compose> button, > Yes, <compose> works, it just wasn't obvious that I should press it. > You view <compose> as meaning "pop up the compose window", I view it > as meaning "I want to send a new piece of mail". I suspect users > are more likely to make the latter interpretation. If you can think of a better solution for this, I'm listening. Keep in mind that real estate is a big issue/problem. I don't want to just "add another button" -- we could change the label on the <compose> button, for example, but to what? > > > In particular, when I'm paging through a long message and > > > have a "more" at the bottom, I would like to be able to issue commands > > > like "n" or "r" without having to "q" first. I can do this in mushtool > > > but not in curses mode. > I seem to get mush's pager no matter what I ask for. That's because (If I remember correctly) you are doing set PAGER=... Just as in csh, you only use all-caps (customarily) for environment variables. You should have done setevn PAGER ... note: no equal sign. You can use this in your .mushrc or your .cshrc, .login, or at the csh command line--mush honors your environment variables (e.g., you can import mush configuration from your environment). If you just want to use a pager specifically/only when using Mush: set pager = ... > OK - I don't really want a separate pager, it takes too long to > start up. If you haven't been able to get it started, then how do you know? It shouldn't take very long; it certainly doesn't take as long as Mail takes to start up a new pager. > I just want the built-in pager to do something reasonable > (not just beep) when I type a mush command at it. I realize this is > hard to do if you use your own pager, but for the built-in one that > I get anyway it should be easy. We're looking at that now. > > This is true, but vi is tuned to take full advantage of the capabilties > > of the screen. Mush just uses those curses(3X) commands that are most > > portable across all versions of unix (that we've found). We cannot do > > reverse scrolling reliably (which would give you your desired effect) > > and be assured that it works everywhere. > > Are there bugs in screen scrolling on the BSD curses? Or is it just slow > to scroll backwards? I think even the BSD curses will scroll the whole > screen forward a line if you set scrollok to true. curses doesn't have any reverse scrolling mechanisms in it. It does not do screen management very well at all when it comes to any kind of screen scrolling. For example, open a line above (like 'O' in vi) is incredibly inefficient. This is one reason why I hate emacs so much :-) -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
mark@cbnewsu.att.com (Mark Horton) (10/17/90)
> If you're still having problems after trying Dan's examples, send me the > alternates line from your .mushrc. Using the bang notation made it work, thanks. > > 555 while ((c = getchar()) >= 0 && c != CTRL('D') && !isspace(c) && > 556 c != '\n' && c != '\r' && lower(c) != 'q' && lower(c) != 'd') > 557 bell(); > > Change line 557 to: > > if (iscurses) { > m_ungetc(c); > c = 'q'; > } else > bell(); > > and let me know how that works. It still beeps - no visible change. > } (I wish space went on to the next message ala > } n, and <CR> or <ESC> or something put you back in the top level menu.) > > bind ' ' display-next > unbind '\n' > unbind '\E' Thanks! Note that the latter two produce an error message. > } An icon for the compose window would be a big improvement. > > As Don Lewis mentioned, it probably isn't possible, because the compose > window is not its own process -- its just a child window in its own frame. It seems to be possible in the Open Look mailtool. I realize this may not apply to Sunview, however. Mark
mark@cbnewsu.att.com (Mark Horton) (10/17/90)
In article <143444@sun.Eng.Sun.COM>, argv@turnpike.Eng.Sun.COM (Dan Heller) writes: > In article <1990Oct4.212140.11006@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: > > > > When replying, if I forget to press "send" (or miss it) and then press > > > > "close", the reply window goes away and so does the reply button! > > > You can still hit the <compose> button, > > Yes, <compose> works, it just wasn't obvious that I should press it. > > You view <compose> as meaning "pop up the compose window", I view it > > as meaning "I want to send a new piece of mail". I suspect users > > are more likely to make the latter interpretation. > > If you can think of a better solution for this, I'm listening. > Keep in mind that real estate is a big issue/problem. I don't > want to just "add another button" -- we could change the label > on the <compose> button, for example, but to what? I suggest you just leave the <reply> button there, and pressing it would just pop the window back up, just like <compose> does. > > > This is true, but vi is tuned to take full advantage of the capabilties > > > of the screen. Mush just uses those curses(3X) commands that are most > > > portable across all versions of unix (that we've found). We cannot do > > > reverse scrolling reliably (which would give you your desired effect) > > > and be assured that it works everywhere. > > > > Are there bugs in screen scrolling on the BSD curses? Or is it just slow > > to scroll backwards? I think even the BSD curses will scroll the whole > > screen forward a line if you set scrollok to true. > > curses doesn't have any reverse scrolling mechanisms in it. It does > not do screen management very well at all when it comes to any kind of > screen scrolling. For example, open a line above (like 'O' in vi) > is incredibly inefficient. This is one reason why I hate emacs so much :-) You are, of course, referring to the BSD curses. The System V curses will scroll in both directions nicely if you tell it idlok. And I've never seen an emacs (or any other production editor) that uses the BSD curses. Mark
argv@turnpike.Eng.Sun.COM (Dan Heller) (10/18/90)
In article <1990Oct17.161513.24723@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: > > } An icon for the compose window would be a big improvement. > > As Don Lewis mentioned, it probably isn't possible, because the compose > > window is not its own process -- its just a child window in its own frame. > It seems to be possible in the Open Look mailtool. > I realize this may not apply to Sunview, however. I think it probably is possible in SunView too -- the difference is probably the fact that the compose frame is current a "child" of the main application frame. If it were a toplevel frame as well, then that'd get what you want. The problem is that it doesn't work for some older sunview's, I think. If someone wants to test this on a sun 3.5 system and let us know, we'll make the change. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
schaefer@ogicse.ogi.edu (Barton E. Schaefer) (10/22/90)
In article <1990Oct17.161513.24723@cbnewsu.att.com> mark@cbnewsu.att.com (Mark Horton) writes: } > if (iscurses) { } > m_ungetc(c); } > c = 'q'; } > } else } > bell(); } > } > and let me know how that works. } } It still beeps - no visible change. Yeah, I forgot that iscurses is set to false before the pager is invoked, then restored afterwards. We went round on this for quite a while, and decided that there's no good way to make it work without changing a good bit of the curses interface as well. Apologies. } > } (I wish space went on to the next message ala } > } n, and <CR> or <ESC> or something put you back in the top level menu.) } > } > bind ' ' display-next } > unbind '\n' } > unbind '\E' } } Thanks! Note that the latter two produce an error message. In that case you can omit them. The point is that any unbound key (plus any key bound to "quit") will return to the top level from the ...continue... prompt. -- Bart Schaefer schaefer@cse.ogi.edu