🚀 go-pugleaf

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