I have some patches that seem to fix/avoid this problem now.   (It is
amazing what one can achieve when mains power fails, long enough for
UPS's to run out, and all that is left operational is the laptop and
First, I put in some defensive code into the area where the problem was
occurring, so that if exmh is attempting (for any reason) to expand a
sequence that isn't either a number, or a range of numbers (or a list of
such things) it will simply ignore the trash, rather than giving a traceback.
foreach range [split [string trim $sequence]] {
set parts [split [string trim $range] -]
That is amending proc MhSeqExpand which is where the error was occurring
before (the code assumes that $range is either NNN or NNN-MMM so we should
probably make sure that's true - issue an error instead of just "continue"
if you like, but I don't think an error is needed).
But that just allowed me to create a similar problem, in another place,
by typing "NNN-" ... and rather than continue to fight fires like this,
I thought I should think more about Brent's suggestion.   But rather than
have the selection code actually validate the input, which would mean it
would have to know what is to be valid, I decided that the right thing to
do is just to ignore any errors caused by invalid input, so I just stuck
a "catch" around the MsgShow that is processing the nonsense that the
This way, any later expansion to what MsgShow treats as legal (maybe
allowing a sequence name, like "prev" or "next", or anything else can
be handled just there, without someone needing to remember that they have
to go fix the selection processing code to allow it.
But, while I was playing there, I noticed something I never new before.
If you type "66+" the "66" changes to "67" (and so on, for each + that
is typed).   I suspect that's perhaps an artifact of "+ is bound to a
different function so it can be used as a toggle between changing the
current and the target folder, but it has to mean something if the current
input mode is a message number, so let it mean...", but now I found it,
I think its nice.    But if we can type 66+ why not 66- as well?  That
kind of limitation bugs me, so I fixed it.
And then I wondered about folders with names containing '+' - the special
use of + as the toggle character means there's no way to type those from
the keyboard.   So I fixed that as well.   This makes two different
restrictions - there's no way to type a folder name that has a name
beginning with '+' (but such a thing in MH would be a pain to use anyway,
so I doubt this will bother anyone), and it is now only possible to
toggle between typing the current & target folder name when the name
being typed is empty.   I'm less happy about that part, but I think I
can live with it in order to allow folder names with +'s in them to
Then, since I was there anyway, I decided to do something about another
feature that has always bugged me.   In "normal" keyboard mode, 's' is
the key used to show a message.    But if you've just typed 123, and
the FTOC is highlighting 123 as the current message, and you want to now
show that message, you can't type 's', you have to type \r instead.
So I "fixed" this one as well.   "Fixed" here is in quotes, as it assumes
that the keybinding for MsgShow is 's', if you change that to something
else, it will remain 's' in here.   I don't know enough tk/tcl to have it
discover what key is bound to a function in the external world in order
to bind the same one here.   \r continues to work of course.
And now I got started in fixing irritants in this code, I also made it
clear the status line if you abort message/folder entry mode (^C or ^G).
Previously it used to leave the prompt sitting there until the next
message appeared, which made it less than obvious that the keyboard had
In any case, what follows is the patch that does all of that.   I believe
that if you apply this, then the one above is probably not needed, the
"catch" around the "MsgShow" will hide the problem (I don't think we really
need to fix Brent's way of invoking it).   Or include it anyway, just
for completeness (I haven't run an exmh with the following patch, but not
the previous one, so I don't know for sure that all will be OK then).
+    bind $w <Key-minus>	{SelectPrev %W }
+    bind $w <Key-s>	{SelectReturn %W %A}
bind $w <BackSpace>	{SelectBackSpace %W}
bind $w <Control-h>	{SelectBackSpace %W}
+	catch { Msg_Change $select(sel) noshow }
set select(toggle) [list [lindex $select(toggle) 1] [lindex $select(toggle) 0]]
set select(prompt) "[lindex $select(toggle) 0] Folder:"