i have a hazy memory of MH development starting on V5
as part of an Office Automation project for the USAF,
concurrent with "ze Bland Editor", er, the Rand Editor.
amusing aside:
George Goble, the Art Arfons of Unix on Minicomputers, loved the rand
editor and he was obsessed with seeing how fast
Date:Tue, 27 Feb 2007 17:01:12 -0600
From:Neil W Rickert <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| The notation "+folder" for identifying a mail folder goes back at
| least to ucbmail (/usr/ucb/Mail or /usr/ucb/mail or emulated by
| mailx).
I wouldn
On February 27, 2007, Norman Shapiro <[EMAIL PROTECTED]> wrote:
>
> I would also argue that the +folderName syntax for designating a file name is
> strange and unique to mh. If, at the time is was first conceived (by Bruce
> Borden) I had thought it through and had I realized that decades later p
Norman Shapiro <[EMAIL PROTECTED]> wrote on Feb 27, 2007:
>I would also argue that the +folderName syntax for designating a file name is
>strange and unique to mh.
The notation "+folder" for identifying a mail folder goes back at
least to ucbmail (/usr/ucb/Mail or /usr/ucb/mail or emulated by
ma
Joel Reicher <[EMAIL PROTECTED]> writes:
>> Norm sayeth:
>> >NO. I'm not quite happy with that, in that I would prefer that
>> >
>> >+ foobar
>> >
>> >mean the same thing as +foobar. That way wild card expansion in shell script
>> s
>> >and file name completion in interactive shells would be mu
> Norm sayeth:
> >NO. I'm not quite happy with that, in that I would prefer that
> >
> >+ foobar
> >
> >mean the same thing as +foobar. That way wild card expansion in shell script
> s
> >and file name completion in interactive shells would be much easier.
>
> No, MH semantics shuold be isolat
> > I still think that numeric folder names rise questions: Consider the
> > above example. cur = inbox/11100. What should "refile next:22 +foo" do?
> > Move the numeric folder? Leave a copy with the name ",1" around?
> > (Note that you can't have hardlinks to directories on the filesystems
> >
> > > This is even a more general bug: Try "refile +inbox/1; scan +inbox"
> > > for example. I think subfolders are a feature, numeric folder names
> > > probably are not. (Allowing them would rise quite some questions
> > > about the semantics of sequences and so on ...)
> >
> > The problem i
> > This is even a more general bug: Try "refile +inbox/1; scan +inbox"
> > for example. I think subfolders are a feature, numeric folder names
> > probably are not. (Allowing them would rise quite some questions
> > about the semantics of sequences and so on ...)
>
> The problem is not in the
Quoth Joel:
>If everyone's happy with "+" meaning the folder root and "@" meaning
>the current folder and anything following being interpreted the same
>as any pathspec would be then I'll clean up the code and try to get
>around to making sure it's documented properly too.
Yes, that sounds best to
Joel writes:
> > Joel Reicher <[EMAIL PROTECTED]> writes:
> > >If everyone's happy with "+" meaning the folder root and "@" meaning
> > >the current folder and anything following being interpreted the same
> > >as any pathspec would be then I'll clean up the code and try to get
> > >around to maki
Sorry for the noise everyone. I repeated my previous error of replying
directly to Norman again and it bounced. Below is just my earlier message.
> > Joel Reicher <[EMAIL PROTECTED]> writes:
> > >If everyone's happy with "+" meaning the folder root and "@" meaning
> > >the current folder and anyt
> Joel Reicher <[EMAIL PROTECTED]> writes:
> >If everyone's happy with "+" meaning the folder root and "@" meaning
> >the current folder and anything following being interpreted the same
> >as any pathspec would be then I'll clean up the code and try to get
> >around to making sure it's documented
Joel Reicher <[EMAIL PROTECTED]> writes:
>> Date:Mon, 26 Feb 2007 14:07:47 +1100
>> From:Joel Reicher <[EMAIL PROTECTED]>
>> Message-ID: <[EMAIL PROTECTED]>
>>
>> | In fact, there looks to be a host of inconsistent behaviour. "+/" will
>> | scan the root *directory*
> Date:Mon, 26 Feb 2007 14:07:47 +1100
> From:Joel Reicher <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | In fact, there looks to be a host of inconsistent behaviour. "+/" will
> | scan the root *directory*. "+.." does *not* scan the directory above
>
Date:Mon, 26 Feb 2007 14:07:47 +1100
From:Joel Reicher <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| In fact, there looks to be a host of inconsistent behaviour. "+/" will
| scan the root *directory*. "+.." does *not* scan the directory above
| the folder
On February 25, 2007, Dan Harkless <[EMAIL PROTECTED]> wrote:
> On February 25, 2007, Harald Geyer <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > I just realized that you can do "refile 1 +" and it works perfectly well,
> > that is: It does the only consistent thing to do and puts the message
> > dir
> I just realized that you can do "refile 1 +" and it works perfectly well,
> that is: It does the only consistent thing to do and puts the message
> directly into ~/Mail
That could very well be the most sensible behaviour. The semantics of
the +folder syntax are an absolute folder path, meaning t
> This is even a more general bug: Try "refile +inbox/1; scan +inbox"
> for example. I think subfolders are a feature, numeric folder names
> probably are not. (Allowing them would rise quite some questions
> about the semantics of sequences and so on ...)
The problem is not in the sequence, b
On February 25, 2007, Harald Geyer <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I just realized that you can do "refile 1 +" and it works perfectly well,
> that is: It does the only consistent thing to do and puts the message
> directly into ~/Mail
Yeah, I've run across that one as well (via typo). Cau
> >I just realized that you can do "refile 1 +" and it works perfectly well,
> >that is: It does the only consistent thing to do and puts the message
> >directly into ~/Mail
>
> That is surely a bug.
Yes, I did expect an error message, but after thinking about it, I don't
want nmh to prevent me f
Harald Geyer <[EMAIL PROTECTED]> wrote on Feb 25, 2007:
>I just realized that you can do "refile 1 +" and it works perfectly well,
>that is: It does the only consistent thing to do and puts the message
>directly into ~/Mail
That is surely a bug.
>Actually it seems that most commands work fairly
Hi!
I just realized that you can do "refile 1 +" and it works perfectly well,
that is: It does the only consistent thing to do and puts the message
directly into ~/Mail
Actually it seems that most commands work fairly well on "+" but there
is one anomaly: The current folder always gets set to "+i
23 matches
Mail list logo