🚀 go-pugleaf

In article <8912151519.AA05853@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes:
} [I] have about 450 peices (1.1MB) of mail (some unanswered) in my
} maildrop.  This morning I was doing to do my monthly cleaning and
} see if I can get that number down a bit.  When I went back to
} message 1, I found that chunks of recent mail (from last week) had
} been overlayed onto the beginning of my maildrop - leaving me with
} bits and pieces of those messages.  This is not good!

Some more details, please -- is this before or after an update?  (If before,
something in the temp file handling is getting confused; if after, then the
problem is with writing back to the folder and is even more serious.)  Are
you using any kind of NFS mounting of your "maildrop"?  What sorts of things
did you do (sorting, deleting, how many updates, etc.)?  Did new mail arrive
while you were working?

Incidentally, I ran 7.0.1 just now on a 500 message folder amounting to
more than 2MB, randomly deleted about 200 messages with assorted "pick"
commands, read several other messages, and updated, with no problems.

} 1. File completion is too verbose
} 
}    In particular, it expands "+" into the pathname of my folder directory,

I presume you're complaining about file listing, e.g. with ^D, not just
completion.  Listing is verbose because it's much more powerful than (say)
csh ^D listing -- you can list any globbing pattern, not just the files
in a particular directory.  Csh ^D displays only the file names, not the
preceding path; but what confusion there would be if you typed

	*/*/*^D

and got only the "tail" of every path that was generated!  Even removing
common prefixes is insufficient, because you still might chop off something
that was generated by the glob pattern, leaving the user with no idea where
the listed files really are.

I will look into special-casing to csh-like behavior when there is no glob
pattern at all.

}    Actually, to be more specific, typing +^D just says "/u6/loverso/Mail/" -
}    I need to type +/^D to get it to list out the individual folders.  This
}    is misleading, because +foo^D lists folders that start with +foo - no "/"
}    is required.

This in intentional.  In effect, "+foo" expands to "$folder/foo" but "+"
expands only to "$folder".  You have to type ~/^D to list files in your
home directory; that's the analogy on which listing with +/^D is based.
+/foo^D will work, too, so I don't see how the / is "misleading".  

The reason the / appears at the end of "/u6/loverso/Mail/" has to do with
the expansion of "+" by routines that have been around far longer than
globbing and completion, and which were too well entrenched to revise.

}    Additionally, I have many subfolders (over 250 in several levels of
}    subdirectories).  At the minimum, it would be useful to have directories
}    listed with a trailing "/" on them.

This was considered but rejected because it requires a stat() on every
file in the listing.  On many systems, this would cause a very noticable
slowing of the completion routines.

}    I've looked at the completion code and its very simple (and clean!).

Thank you. :-)

}    Lastly, completion doesn't work for "~w" et al in compose mode.

This statement is just plain wrong.  Completion works in compose mode.
In fact, it works ANYWHERE in compose mode, so don't bind your completion
characters to things you habitually type in messages.

There DOES have to be a space between the "~w" and whatever you are 
completing, or mush will try to find a file in your home directory (~)
whose name begins with "w" ....

} 2. Including headers in forwarded mail
}    [ In some cases I ]
}    just want minimal headers included with ~I; I can do this by settin
}    alwaysignore.  However, to get all the headers, I need to unset
}    this variable.  This is a little clumsy.
} 
}    I tried to make a map! to handle it, but found map!'s can match
}    initial newlines (I only want the `command' recognized at BOL).

I handle this sort of thing by mapping a control character (somthing not
usually typed, like ^F) to newline/tilde-command/newline, e.g.

    map! \CF '\n~:unset alwaysignore\n~I\n~:set alwaysignore\n'

You can leave off the leading "\n" if you're confident you'll only be
typing it at the beginning of a line.

} 3. From: line handling
}    I need to change my `From:' at my discretion at certain times.  I know
}    who I am - why do I need to prove it to Mush?  If I fill in a From:
}    line that has my address in a different domain, it tosses it out
}    (silently).  I don't want Mush changing this at all.

Put your other selves in the "alts" list; mush will allow the From: line
to contain any of your alternate selves, as long as you've told it about
them.

}    For that matter, Mush needn't supply a default From: line nor a default
}    Date: at all.  My MTA does it for me.  Perhaps a SMART_MTA define might
}    be in order?

PICKY_MAILER covers this.

}    BTW, in the BUGS section of the manaul page, comment about "edit_hdrs"
}    and changing the From: line is out of date.

It's not in the BUGS section, but I found it and corrected it.  Thanks.

} 4. Forwarding vs. resending
}    I'm butting up against the "resent" mail restriction again.  I.e.,
}    if you "mail -f" and never take the message into an editor, the
}    message goes out as "resent" mail, in which "resent-" headers are
}    generated.  This loses if you have auto_edit set.

It "loses"?  If by this you mean that -f ignores $autoedit, then I guess
that's a loss.  Or do you mean that you have no choice of NOT getting
autoedit behavior with "mail -ef"?  That complaint I could understand,
though an editor is required to add anything above a such a message.

Why not

    cmd resend "mail -f"
    cmd forward "mail -ef"

}    Note that the "mail" command now has a "-U" switch, it would be nice
}    if "mail -f" didn't assume this; i.e., the current "mail -f" behavior
}    would be replaced by "mail -fU".

I'll file the suggestion for discussion with Dan.
-- 
Bart Schaefer     "Miserable miscreant!  Question MY integrity, will you?"
               "I have to see some *evidence* of it before I can question it."
                                                            -- Calvin & Hobbes
schaefer@cse.ogi.edu (used to be cse.ogc.edu)