🚀 go-pugleaf

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