compctl whitespace changes

compctl whitespace changes

[Phil Pennock]

I just moved my private box from zsh-3.0.8 to zsh-4.0.2.

I have a function which takes the name of a mailbox as a parameter and
starts mutt appropriately, and starts mutt in turn if more than one
parameter is passed.

This:
 compctl -g '~/Mail/Lists/*(D.:t)' lmutt
is what I've been using.

Because I used to use 3.1.x I remembered -W, so this:
 compctl -f -W ~/Mail/Lists lmutt
works just fine.

However, I was pushed into making the change because whereas before a
space would be appended to successful solutions, with zsh 4 this is no
longer the case.  The cursor is left immediately at the end of the
completed word.

Is this deliberate?  How do I override it if there are other instances
where it bites me and there's not a quick fix like this?

Or should I just be moving to the compsys stuff?

Thanks,
-- 
Occam's Razor-Slashed Wrists: The simplest possible solution to your problem
might just make you wish you were dead, so eliminate the possibility of
solutions which would be worse than none at all.   -- Benjy Feen

Re: compctl whitespace changes

[Sven Wischnowsky]

Phil Pennock wrote:

> I just moved my private box from zsh-3.0.8 to zsh-4.0.2.
> 
> I have a function which takes the name of a mailbox as a parameter and
> starts mutt appropriately, and starts mutt in turn if more than one
> parameter is passed.
> 
> This:
>  compctl -g '~/Mail/Lists/*(D.:t)' lmutt
> is what I've been using.
> 
> Because I used to use 3.1.x I remembered -W, so this:
>  compctl -f -W ~/Mail/Lists lmutt
> works just fine.

Hrm.  That's because it can't recognise them as filenames (because of
that `:t').  I don't remember the reason for that change, though, having
not used compctl for quite some time.

> However, I was pushed into making the change because whereas before a
> space would be appended to successful solutions, with zsh 4 this is no
> longer the case.  The cursor is left immediately at the end of the
> completed word.
> 
> Is this deliberate?  How do I override it if there are other instances
> where it bites me and there's not a quick fix like this?


One could always add `-S " "' to get the space.

> Or should I just be moving to the compsys stuff?

Probably a good idea anyway.  Something like:

  compdef _lmutt lmutt
  _lmutt () { _files -W ~/bin -g '*(.)' }

could get you started.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: compctl whitespace changes

[Bart Schaefer]

On Aug 8, 10:22am, Sven Wischnowsky wrote:
}
} > Or should I just be moving to the compsys stuff?
} 
}   compdef _lmutt lmutt
}   _lmutt () { _files -W ~/bin -g '*(.)' }
                         ?^^^^^?
} 
} could get you started.

Better might be

    _lmutt () { local maildirectory=~/Mail/Lists; _mutt "$@" }

(That maildirectory variable really ought to get changed to a style ...)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: compctl whitespace changes

[Phil Pennock]

On 2001-08-08 at 16:03 +0000, Bart Schaefer wrote:
> Better might be
> 
>     _lmutt () { local maildirectory=~/Mail/Lists; _mutt "$@" }

Okay, this has helped with my understanding a lot by pointing me at
things to examine.  Thanks.  However, its not correct by the spec I
gave.  lmutt takes _just_ the name of the mailbox as a parameter, not
with a -f.  So I'd say "lmutt zsh bugtraq" and, inside a loop over zsh &
bugtraq I'd fiddle with the xterm title (if appropriate) and start:
 mutt -f "+Lists/$i"

But Sven's answer works fine, module correcting "bin".

Looking into _mutt, I've seen a problem with Maildirs support.

With Maildir, you have your main Maildir, eg ~/Maildir/, and you can
have folders inside that, each of which has a name starting with a
period.  The normal one is .Trash, but others can be created.  The
current stuff doesn't handle this at all -- you might want a glob_dots
modifier in there.  Ideally mutt would understand folders itself, but
even so I'd still want zsh's tab-completion to allow me to start on a
folder.  :^)

So, what's happening here?  If I do "mutt -f +<TAB>" then I get a list
of files in the default $maildirectory.  If I do:
 compdef _imutt imutt
 _imutt () { setopt localoptions globdots; local
   maildirectory=~/Maildir; _mutt "$@" }
then when I do "imutt -f +<TAB>" I get nothing.  I've looked at the
special maildir handling, and AFAICS in _mailbox_cache() $dirboxes
should get the dot-directories and the while-loop should be happy, since
each folder contains its own {cur,new,tmp}/ ... but it's failing.  Que?

At the moment, I'll stick with the imutt() which is like lmutt() and
uses a compctl like the original one I gave, despite the fact that I
need to *gasp* press space myself manually because -W doesn't handle
names starting with a dot.


Do people feel that a supplied patch to add Maildir support into
$mailpath would be appropriate?  I'm happy to do the work, if it's not
considered a bad idea.

Thanks for the help,
-- 
Pentiums melt in your PC, not in your hand.

Re: compctl whitespace changes

[Bart Schaefer]

On Aug 9,  8:14am, Phil Pennock wrote:
}
} Looking into _mutt, I've seen a problem with Maildirs support.
} 
} With Maildir, you have your main Maildir, eg ~/Maildir/, and you can
} have folders inside that, each of which has a name starting with a
} period.  The normal one is .Trash, but others can be created.

Are you sure about this?  There's nothing in the maildir "spec" about
the format of the directory names, only their contents, and nothing in
the mutt documentation either that would indicate why every folder name
would be hidden with a leading dot.  I'd expect ".Trash" to be a special
(deliberately invisible) folder where deleted messages are moved before
purging.

} The current stuff doesn't handle this at all -- you might want a
} glob_dots modifier in there.

Completion deliberately (?) doesn't meddle with glob_dots in most cases
(it's neither set nor unset in _comp_options).  Any other mutt users out
there care to comment?

}  compdef _imutt imutt
}  _imutt () { setopt localoptions globdots; local
}    maildirectory=~/Maildir; _mutt "$@" }
} then when I do "imutt -f +<TAB>" I get nothing.

D'oh!  Of course you don't get anything, because _mailbox_cache assumes
that $maildirectory never changes, and none of the mailboxes already in
the cache it has built will match the ~/Maildir prefix.  So I led you
astray with that suggestion.

} Do people feel that a supplied patch to add Maildir support into
} $mailpath would be appropriate?  I'm happy to do the work, if it's not
} considered a bad idea.

It's already there.  "configure --enable-maildir-support ..."

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: compctl whitespace changes

[Phil Pennock]

On 2001-08-09 at 09:27 +0000, Bart Schaefer wrote:
> } With Maildir, you have your main Maildir, eg ~/Maildir/, and you can
> } have folders inside that, each of which has a name starting with a
> } period.  The normal one is .Trash, but others can be created.
> 
> Are you sure about this?  There's nothing in the maildir "spec" about
> the format of the directory names, only their contents, and nothing in
> the mutt documentation either that would indicate why every folder name
> would be hidden with a leading dot.  I'd expect ".Trash" to be a special
> (deliberately invisible) folder where deleted messages are moved before
> purging.

Mutt's Maildir support is minimal.  Not a good example.

I should've been more explicit and said Maildir++, which most software
aside from Dan Bernstein's uses, for various reasons.  It's a superset.

Example documentation:
 <http://www.courier-mta.org/maildirmake.html>

Something a quick google throws up:
 <http://www.exim.org/pipermail/exim-users/Week-of-Mon-20000103/015916.html>
which in passing demonstrates this being used.

> } Do people feel that a supplied patch to add Maildir support into
> } $mailpath would be appropriate?  I'm happy to do the work, if it's not
> } considered a bad idea.
> 
> It's already there.  "configure --enable-maildir-support ..."

*sigh*  Thank you.  I did check the run-time docs.  And I just
double-checked:
~/zsh-4.0.2/Doc%; fgrep -i maildir **/*.yo
Zsh/compctl.yo:example(compctl -/ -W ~/Mail maildirs)

Further, the entry for $mailpath in zshparam(1) is a little misleading,
as it makes explicit reference to what happens when an entry is a
directory:
             If an element is a directory instead  of  a
     file the shell will recursively check every file in
     every subdirectory of the element.

I'll just go rebuild zsh ...  (serves me right for using *BSD Ports)

Thanks,
-- 
PHB:     It needs to be so easy that your mother could use it.
Dilbert: My mother isn't a moron.  Maybe we could use your mother as a test.
PHB:     What makes you think my mother is a moron?
Dilbert: She fed you.

Re: compctl whitespace changes

[Will Yardley]

Bart Schaefer wrote:
> On Aug 9,  8:14am, Phil Pennock wrote:
 
> } With Maildir, you have your main Maildir, eg ~/Maildir/, and you can }
> have folders inside that, each of which has a name starting with a }
> period.  The normal one is .Trash, but others can be created.
 
> Are you sure about this?  There's nothing in the maildir "spec" about the
> format of the directory names, only their contents, and nothing in the mutt
> documentation either that would indicate why every folder name would be
> hidden with a leading dot.  I'd expect ".Trash" to be a special
> (deliberately invisible) folder where deleted messages are moved before
> purging.

Oops - accidentally replied to Bart instead of the list... apologies.

I think it's created by a POP or IMAP client usually.  I don't use IMAP or
POP anymore since it's more convenient to my mutt setup to put maildirs
inside mail/, but courier IMAP puts everything in folders starting with dot
(or at least that's how it works on our system, so 'Trash' over IMAP would be
Maildir/.Trash.  

I do know that mutt lets you choose if you want to set the 'Trashed' flag
which is an option only available if you're using Maildir, so that may also
use the .Trash option??  I put all my mail in 'mail/Trash/' but there is
still a .Trash directory in my maildir; I'm not sure when or how it got
there. It's totally empty though.

zugzug# tree
.
|-- cur
|-- maildirfolder
|-- new
`-- tmp

3 directories, 1 file
zugzug# pwd
/home/william/Maildir/.Trash

When I used dot subfolders from courier IMAP i had to change my mutt file
mask around to display them properly.  I haven't used the zsh functions
mentioned; just thought I'd throw in my $0.02 regarding the Maildir
question...

w

----- End forwarded message -----

Re: compctl whitespace changes

[Phil Pennock]

On 2001-08-09 at 03:07 -0700, Will Yardley wrote:
> I think it's created by a POP or IMAP client usually.  I don't use IMAP or
> POP anymore since it's more convenient to my mutt setup to put maildirs
> inside mail/, but courier IMAP puts everything in folders starting with dot
> (or at least that's how it works on our system, so 'Trash' over IMAP would be
> Maildir/.Trash.  

Yeah.  It's all because IMAP uses dot as a hierarchy separator.  But if
you want a deeper hierarchy, you don't actually recurse.  You'd have
something like:
 Maildir/.Company
 Maildir/.Company.Management
 Maildir/.Company.Management.Crap
(and in many cases fold the last two into one *coughs*)

> When I used dot subfolders from courier IMAP i had to change my mutt file
> mask around to display them properly.

It's possible that this issue is courier specific, since that's what I'm
using for serving IMAP (but not for the actual delivery); but my
understanding is that it's Maildir++ which is used by several
applications.  Little things which still let Maildir programs function,
some; eg, S=size in the filename, so that you only need to readdir()
without 500 stat() calls so as to find out how large the files are.

The original Maildir simply doesn't provide any support for sub-folders.
But enough people are using them that it makes sense for zsh to
understand it.

I'm sticking with compctl for that one for now.  I still _understand_
that and don't need to read 231 60-line functions to figure out what's
going on.   *ducks*
-- 
A guru went to the dentist and said, "I'd like to transcend dental medication."

Re: compctl whitespace changes

[Bart Schaefer]

On Aug 10, 10:59am, Phil Pennock wrote:
} Subject: Re: compctl whitespace changes
}
} On 2001-08-09 at 03:07 -0700, Will Yardley wrote:
} > I think it's created by a POP or IMAP client usually.
} 
} Yeah.  It's all because IMAP uses dot as a hierarchy separator.

IMAP can use almost anything it likes as a hierarchy separator.  Don't
make claims for the whole protocol based on the courier implementation.
It is also notorious for taking assorted liberties with the protocol
that most of the other IMAP server writers are unhappy about.

} But enough people are using them that it makes sense for zsh to
} understand it.

I have a certain ambivalence about this, having worked on both email
clients and IMAP servers.  If the file structure is being created by a
local delivery agent for use by an IMAP server, then it's that server
(or a local user agent designed to work with the same structure) that
should interpret the folder names, not your shell.

Suppose Company.Management decides to change to the Cyrus server.  Then
all your mail files will disappear and you'll have a database interface
to deal with.  A lot of people use that, too -- probably a lot more than
use Courier IMAP.  That's not, by itself, a reason.

If your mail system uses ordinary files and leaves you in complete control
of what they're named and where to put them, then it makes sense for the
shell to understand it, because obviously the designers of the mail system
*intended* other programs to understand it.

Nevertheless, if someone can actually find me a reasonable description of
"Maildir++" (the description on the courier pages didn't say anything
about hierarchy, for example) I'll think about how _mailboxes might be
adjusted to cope with it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: compctl whitespace changes

[Phil Pennock]

On 2001-08-10 at 15:56 +0000, Bart Schaefer wrote:
> IMAP can use almost anything it likes as a hierarchy separator.  Don't
> make claims for the whole protocol based on the courier implementation.

I was going on the documentation, not the implementation.  But I can
well believe that they made overbroad claims.

> It is also notorious for taking assorted liberties with the protocol
> that most of the other IMAP server writers are unhappy about.

Ah.  Interesting.  I'd be grateful if you could provide me with
references for this in private email (since the closest that my googles
for it are returning are complaints about Outlook's implementation).

> I have a certain ambivalence about this, having worked on both email
> clients and IMAP servers.  If the file structure is being created by a
> local delivery agent for use by an IMAP server, then it's that server
> (or a local user agent designed to work with the same structure) that
> should interpret the folder names, not your shell.

The structure is chosen for the server functionality (under the mistaken
belief that it was standard -- thanks for the correction).  The box has
local accounts.  Remote IMAP/SSL is offered as well, if the user simply
creates ~/Maildir/; subfolders are made with maildirmake(1), procmail
delivers.  I tend to not use IMAP/SSL, so instead I just start mutt
directly on the folder name.  I have some mail go into those folders,
since I believe in eating your own dog-food and using the services
sometimes.

> Suppose Company.Management decides to change to the Cyrus server.  Then
> all your mail files will disappear and you'll have a database interface
> to deal with.  A lot of people use that, too -- probably a lot more than
> use Courier IMAP.  That's not, by itself, a reason.

I've not looked too closely at Cyrus, simply because it is a total black
box.  If it provides a tool to extract a list of folders and
sub-folders, my approach would have been to use compctl -K or -k.

Since I believed that the use of . as a folder hierarchy separator was
standard, I suggested it.  I now withdraw that suggestion.  Sorry for
the time-wasting.

> Nevertheless, if someone can actually find me a reasonable description of
> "Maildir++" (the description on the courier pages didn't say anything
> about hierarchy, for example) I'll think about how _mailboxes might be
> adjusted to cope with it.

<http://www.inter7.com/courierimap/README.maildirquota.html>
 "Maildir++ adds a couple of things to a standard Maildir: folders and
  quotas" ....
It actually says something different about hierarchy to:
 <http://www.courier-mta.org/maildirmake.html>
section "FOLDERS", fourth paragraph, which is what I was going on.

So the only thing that can be said is "there exist directories which
look like maildirs themselves, having their own {cur,new,tmp}/ sets,
whose name starts with a dot, inside the main directory".  That's
the only Maildir++ change which mutt might want to be aware of.  I had
thought that more systems than just Courier used Maildir++.
-- 
To a first approximation, security is always at odds with convenience. Security
is the business of denying access, so it can't help make things less convenient.
To improve security without materially compromising convenience requires
fundamental breakthroughs. -- Crispin Cowan

Re: compctl whitespace changes

[Bart Schaefer]

On Aug 10,  6:36pm, Phil Pennock wrote:
> Subject: Re: compctl whitespace changes
> On 2001-08-10 at 15:56 +0000, Bart Schaefer wrote:
> > IMAP can use almost anything it likes as a hierarchy separator.  Don't
> > make claims for the whole protocol based on the courier implementation.
> 
> I was going on the documentation, not the implementation.  But I can
> well believe that they made overbroad claims.

There are two widely-used hierarchy delimiters, dot and slash.  Generally
servers that present a usenet-news-style hierarchy use dot, and those that
expose the filesystem hierarchy use slash.

But in reality, the hierarchy delimiter is reported by the server as part
of the protocol exchange with the client, so the only way to know how to
interpret a mailbox name is to actually use the protocol.

> So the only thing that can be said is "there exist directories which
> look like maildirs themselves, having their own {cur,new,tmp}/ sets,
> whose name starts with a dot, inside the main directory".  That's
> the only Maildir++ change which mutt might want to be aware of.  I had
> thought that more systems than just Courier used Maildir++.

It's entirely possible that there are other systems using it.  I'd just
never heard of it before.