Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!bloom-beacon!Xylogics.COM!loverso
From: loverso@Xylogics.COM (John Robert LoVerso)
Newsgroups: comp.mail.mush
Subject: Re: **WARNING** Mush 7.0.0 scrambles mailbox
Message-ID: <8912152226.AA31825@xenna.Xylogics.COM>
Date: 15 Dec 89 22:26:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 109

Bart,

I was just composing a followup to my earlier mail when your's arrived,
so I'll interleave the two...

> Some more details, please -- is this before or after an update?

I didn't notice it until several (3?) days of use.  There were two splices,
in the low-numbered messages (<30 for both).  This is a straight local
maildrop using flock.  I never sort; I do a few updates a day, tend to
run a single mush all day (quitting when I leave) and then another at
night.  I try and delete old mail (really!  I do!).  New mail *always*
arrives for me.

As an additional data point, I noticed that my 7.0.1 was saying it was
saying it was 7.0.0.  After investigating, I found that the makefile
has no dependencies, so when I recompiled, everything that needed it
didn't get rebuild!  Thus it couldn't been the 7.0.1 patch that caused
the problem.  However, non of the .h's changed in a way that looks
like it would cause havoc, so...  Anyway, you should either give a
default (non /usr/include) list of dependencies in each of the makefiles.
Or include a reminder note in the patches.

As for my large mdrop; this gave me incentive to catch up on those old
messages (actually, that was what I doing in the first place when I
discovered the problem - I shudder to think what would've happened if
I hadn't looked at those old messages at all).  Anyway, my mdrop is
now down to a confortable 19 messages/25KB - and updating now only
takes 1 second, as opposed to the 25 seconds I was used to!

And, I'm also keeping close track of the mail thats in there to 
see if I get corruption again.

> } 1. File completion is too verbose
> }    In particular, it expands "+" into the pathname of my folder directory,
> 
> Listing is verbose because it's much more powerful than ... [it allows]
> 	*/*/*^D

(I didn't even know that)  However, if I say */*^D, I should see things like
	blax/ajax  blax/garbel  blax/zot  qup/rrr  qup/goble
not the absolute pathname in front of those paths.  If I say +blax/^D,
I'm only interested in
	+blax/ajax  +blax/garbel  +blax/zot
not
	/u6/loverso/Mail/blax/ajax  /u6/loverso/Mail/blax/garbel
	/u6/loverso/Mail/blax/zot
Its too much to parse!

> }    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 in intentional.

Ah, but it makes me type an extra character!  If I care'd where my $folder
was, I'd look at the variable.  100% of the time, I'm really just looking
to see which top-level folders I have, and ~^D is 33% faster to type than ~/^D.

> 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.

Ah, but ~^D will list all the valid names that can come after ~ - so why
shouldn't +^D list all the valid folder names? 

> }    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.

Not on real UNIX machines with inode caching 8-}.  You could #ifdef
the code with "SLOW_and_PUDGY".

> }    Lastly, completion doesn't work for "~w" et al in compose mode.
> 
> This statement is just plain wrong.

This is one of the things I was going to correct myself on.  When I was
testing that, I wasn't running with "set completion", so naturally it
didn't work for me!

> }    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.

I said that wrong; I meant "map!'s can NOT match initial newlines".
What you suggested is what I'm using.

> }    For that matter, Mush needn't supply a default From: line nor a default
> }    Date: at all.  My MTA does it for me.
> 
> PICKY_MAILER covers this.

I thought PICKY_MAILER did something else...  again, my mistake!

> } 4. Forwarding vs. resending

Sorry to rehash this up again - while going though my old mail, I came 
across the discussion you, Dan, and I had about this over the summer.
My only problem is that I really want to (sometimes) add a editorial
comment at the top of resent mail.  Mush then causes such mail to not
be resent, etc.  That's the behavior I want to elide...

Thanks for the quick response!

John