PATCH: _mutt, _mailboxes

PATCH: _mutt, _mailboxes

[Clint Adams]

This is my stab at completion for mutt.  I imagine that the
_mailboxes function would be useful for completing the -f arguments
of elm and pine, after some tweaking.

diff -cN --recursive Completion/User.old/_mailboxes Completion/User/_mailboxes
*** Completion/User.old/_mailboxes      Wed Dec 31 19:00:00 1969
--- Completion/User/_mailboxes  Wed Sep 15 17:21:44 1999
***************
*** 0 ****
--- 1,32 ----
+ #autoload
+ 
+ # This is needlessly mutt-biased and should be fixed.
+ 
+ local expl muttboxes mboxes dirboxes MHboxes maildirboxes muttrc="~/.muttrc" m
aildirectory="~/Mail"
+ 
+ test -f "$compconfig[muttrc_path]" && muttrc=$compconfig[muttrc_path]
+ test -f "$compconfig[maildirectory]" && maildirectory=$compconfig[maildirector
y]
+ 
+ if (( ! $+_mailbox_cache )) then
+ 
+ test ${muttrc} || test -f ${~muttrc} && muttboxes=( ${(@)$(grep mailboxes ${~m
uttrc})[2,-1]} )
+ 
+ mboxes=(${~maildirectory}/*(^/))
+ dirboxes=(${~maildirectory}/*(/))
+ 
+ for i in $dirboxes
+ do 
+ if test -d "${i}/cur"
+ then
+ maildirboxes=($maildirboxes $i)
+ else
+ MHboxes=($MHboxes $i)
+ fi
+ done
+ 
+ _mailbox_cache=(\! \< \> $muttboxes $mboxes $maildirboxes $MHboxes)
+ 
+ fi
+ 
+ _description expl 'mailbox specification'
+ compadd "$@" "$expl[@]" - "$_mailbox_cache[@]"
diff -cN --recursive Completion/User.old/_mutt Completion/User/_mutt
*** Completion/User.old/_mutt   Wed Dec 31 19:00:00 1969
--- Completion/User/_mutt       Wed Sep 15 17:21:44 1999
***************
*** 0 ****
--- 1,39 ----
+ #compdef mutt
+ 
+ local state line muttrc="~/.muttrc" ret=1
+ 
+  _arguments \
+  '::recipient:->userhost' \
+  '-a:MIME attachment:_files' \
+  '-b:BCC recipient:->userhost' \
+  '-c:CC recipient:->userhost' \
+  '-e:post-init configuration:' \
+  '-f+:mailbox:_mailboxes' \
+  '-F+:init file:_files' \
+  '-h+:help' \
+  '-H+:draft file:_files' \
+  '-i:include file:_files' \
+  '-m+:default mailbox type:(mbox MMDF MH Maildir)' \
+  '-n+:bypass system configuration:' \
+  '-p+:resume postponed message:' \
+  '-R+:open in read-only mode:' \
+  '-s+:subject:' \
+  '-v+:version:' \
+  '-x+:emulate mailx compose:' \
+  '-y+:start listing mailboxes:' \
+  '-z+:start only if new messages:' \
+  '-Z+:open first mailbox with new mail:' && ret=0
+ 
+ if [[ "$state" = userhost ]]; then
+       if compset -P '*@'; then
+         _description expl 'remote host name'
+         _hosts "$expl[@]" -q -S,
+         return
+       else
+           _description expl 'login name'
+           _users "$expl[@]" -q -S@ && ret=0
+         fi
+       fi
+ 
+ return ret
+ fi

Re: PATCH: _mutt, _mailboxes

[Bart Schaefer]

On Sep 15,  5:30pm, Clint Adams wrote:
} Subject: PATCH: _mutt, _mailboxes
}
} This is my stab at completion for mutt.  I imagine that the
} _mailboxes function would be useful for completing the -f arguments
} of elm and pine, after some tweaking.
} 
} + test -f "$compconfig[muttrc_path]" && muttrc=$compconfig[muttrc_path]
} + test -f "$compconfig[maildirectory]" && maildirectory=$compconfig[maildirectory]

The following are updates to _mailboxes to make it somewhat more generic.

Other completers don't use compconfig for anything as application-specific
as "muttrc_path", so instead I've simply made it recognize the existing
settings of $muttrc and $maildirectory if there are any.  I've added the
paramter $pinedirectory to that set, as Pine by default uses ~/mail where
mutt, mush, zmail, and plain ol' mail all use ~/Mail; I could have stabbed
at ~/nsmail (netscape communicator) and various other programs' directory
names; but I don't really even like the idea of _mailboxes handling the
maildir and MH formats, so I didn't.

Nevertheless, I did improve (I hope) the handling of MH format as well, to
do a better job of recognizing nested mailbox hierarchy.

I don't use mutt, so I don't know what ( \! \< \> ) are; do they really
represent mailbox names?  If not, they should be in _mutt and not here.
As I didn't know, I simply relegated them to the same collection of names
as those grepped from the .muttrc file, and didn't include them at all if
there is no such collection.

One thing I didn't do yet is handle a leading "+" in the word that is
being completed and treat it as referring to the maildirectory.

Index: Completion/User/_mailboxes
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Completion/User/_mailboxes,v
retrieving revision 1.1
diff -u -r1.1 _mailboxes
--- _mailboxes	1999/09/18 17:26:25	1.1
+++ _mailboxes	1999/09/18 23:22:02
@@ -1,30 +1,41 @@
 #autoload
 
-# This is needlessly mutt-biased and should be fixed.
+emulate -L zsh
+setopt nullglob
 
-local expl muttboxes mboxes dirboxes MHboxes maildirboxes muttrc="~/.muttrc" maildirectory="~/Mail"
+# This is still needlessly mutt-biased and should be fixed.
 
-test -f "$compconfig[muttrc_path]" && muttrc=$compconfig[muttrc_path]
-test -f "$compconfig[maildirectory]" && maildirectory=$compconfig[maildirectory]
+local -U muttboxes mboxes dirboxes MHboxes maildirboxes
+local i j expl muttrc="${muttrc:-~/.muttrc}"
+local pinedirectory="${pinedirectory:-~/mail}"
+local maildirectory="${maildirectory:-~/Mail}"
 
 if (( ! $+_mailbox_cache )) then
 
-test ${muttrc} || test -f ${~muttrc} && muttboxes=( ${(@)$(grep mailboxes ${~muttrc})[2,-1]} )
+[[ -f "${~muttrc}" ]] && muttboxes=( ${$(grep mailboxes ${~muttrc})[2,-1]} )
 
-mboxes=(${~maildirectory}/*(^/))
-dirboxes=(${~maildirectory}/*(/))
+mboxes=( ${~maildirectory}/*(^/) ${~pinedirectory}/**/*(.) )
+dirboxes=( ${~maildirectory}/*(/) )
 
-for i in $dirboxes
+while (( $#dirboxes ))
 do 
-if test -d "${i}/cur"
-then
-maildirboxes=($maildirboxes $i)
-else
-MHboxes=($MHboxes $i)
-fi
+    i=$dirboxes[1]
+    shift dirboxes
+    if [[ -d "$i/cur" ]]
+    then
+	maildirboxes=( $maildirboxes $i )
+    elif j=( $i/<1-> ) && [[ -n "$j" ]]
+    then
+	MHboxes=( $MHboxes $i )
+    else
+	mboxes=( $mboxes $i/*(.) )
+	dirboxes=( $dirboxes $i/*(/) )
+    fi
 done
 
-_mailbox_cache=(\! \< \> $muttboxes $mboxes $maildirboxes $MHboxes)
+[[ -n "$muttboxes" ]] &&
+    _mailbox_cache=(\! \< \> $muttboxes)
+_mailbox_cache=($_mailbox_cache $mboxes $maildirboxes $MHboxes)
 
 fi
 
 

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

Re: PATCH: _mutt, _mailboxes

[Clint Adams]

> I don't use mutt, so I don't know what ( \! \< \> ) are; do they really
> represent mailbox names?  If not, they should be in _mutt and not here.

In elm they mean "spoolfile," "sent," and "received" respectively.
In mutt they mean "$spool," "$record," and "$mbox" respectively.

> One thing I didn't do yet is handle a leading "+" in the word that is
> being completed and treat it as referring to the maildirectory.

Also, in both elm and mutt, a '=' or '+' followed by the folder
name means that the file is in the mail directory.  i.e., +test
is ~/Mail/test, just like in MH.

Re: PATCH: _mutt, _mailboxes

[Sven Wischnowsky]

I wrote:

> Adam Spiers wrote:
> 
> > Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> > > And while I'm at it... I'm the only one who writes option
> > > descriptions, it seems, which I can understand considering how tedious 
> > > that is. So my question is: if an option gets only one argument,
> > > should we turn it's description automatically into the
> > > option-description? Probably prefixed by something like `specify: '?
> > 
> > Sounds like a good idea.  How about a configuration key which in this
> > case would be something like `specify: %s'?
> 
> Yep. It's `autodescribe_options' (and the sequence is `%d', for
> `description').

Oops. We won't want that for undescribed long options. And not for
empty descriptions.

Bye
 Sven

diff -u oldcompletion/Base/_arguments Completion/Base/_arguments
--- oldcompletion/Base/_arguments	Fri Sep 17 11:07:34 1999
+++ Completion/Base/_arguments	Fri Sep 17 13:20:38 1999
@@ -126,7 +126,7 @@
       # Then we walk through the descriptions plus a few builtin ones.
 
       set -- "$@" '*=FILE*:file:_files' \
-             '*=(DIR|PATH)*:directory:_files -/' '*:unknown:'
+             '*=(DIR|PATH)*:directory:_files -/' '*: :'
 
       while (( $# )); do
 
@@ -219,8 +219,8 @@
       1="${1/\[$descr\]}"
     elif [[ -n "$compconfig[autodescribe_options]" &&
             "$1" = [-+][^:]##:[^:]#[^\\]:[^:]# ]]; then
-      descr="${${(M)${1#*:}#*[^\\]:}[1,-2]}"
-      descr="${compconfig[autodescribe_options]//\\%d/$descr}"
+      descr="${${${${(M)${1#*:}#*[^\\]:}[1,-2]}## #}%% #}"
+      [[ -n "$descr" ]] && descr="${compconfig[autodescribe_options]//\\%d/$descr}"
     fi
 
     # Description for both the `-foo' and `+foo' form?

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

Re: PATCH: _mutt, _mailboxes

[Sven Wischnowsky]

Adam Spiers wrote:

> Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> > And while I'm at it... I'm the only one who writes option
> > descriptions, it seems, which I can understand considering how tedious 
> > that is. So my question is: if an option gets only one argument,
> > should we turn it's description automatically into the
> > option-description? Probably prefixed by something like `specify: '?
> 
> Sounds like a good idea.  How about a configuration key which in this
> case would be something like `specify: %s'?

Yep. It's `autodescribe_options' (and the sequence is `%d', for
`description').


Bye
 Sven

diff -u oldcompletion/Base/_arguments Completion/Base/_arguments
--- oldcompletion/Base/_arguments	Fri Sep 17 09:32:37 1999
+++ Completion/Base/_arguments	Fri Sep 17 10:55:39 1999
@@ -217,6 +217,10 @@
     if [[ "$1" = *\[*\](|:*) ]]; then
       descr="${${1#*\[}%%\]*}"
       1="${1/\[$descr\]}"
+    elif [[ -n "$compconfig[autodescribe_options]" &&
+            "$1" = [-+][^:]##:[^:]#[^\\]:[^:]# ]]; then
+      descr="${${(M)${1#*:}#*[^\\]:}[1,-2]}"
+      descr="${compconfig[autodescribe_options]//\\%d/$descr}"
     fi
 
     # Description for both the `-foo' and `+foo' form?
diff -u od/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- od/Zsh/compsys.yo	Fri Sep 17 10:29:27 1999
+++ Doc/Zsh/compsys.yo	Fri Sep 17 11:01:21 1999
@@ -799,7 +799,12 @@
 explanation strings should be printed when options are listed. If it
 is set to a non-empty string and it doesn't contain the substring
 `tt(!)var(command)', where `var(command)' is the name of the command
-that is completed for, the descriptions will be shown.
+that is completed for, the descriptions will be shown. If no
+explanation string is given but the tt(autodescribe_options) key is
+set and only one argument is described for this var(opt-spec), the
+option will be described by the value of tt(autodescribe_options) with 
+any appearance of the sequence `tt(%d)' in it replaced by the
+description for the first argument.
 )
 enditem()
 
@@ -1165,6 +1170,13 @@
 listed. If the value string contains substrings of the form
 `tt(!)var(command)', this will not be done for any of these
 var(command)s.
+)
+item(tt(autodescribe_options))(
+If set, this string will be used as the description for options which
+are not described by the completion function, but that have exactly
+one argument. The sequence `tt(%d)' in the value will be replaced by
+the description for this argument. Depending on personal preferences,
+it may be useful to set this key to something like `tt(specify: %d)'.
 )
 item(tt(describe_values))(
 Like tt(describe_options), but used when completing value lists.

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

Re: PATCH: _mutt, _mailboxes

[Adam Spiers]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> And while I'm at it... I'm the only one who writes option
> descriptions, it seems, which I can understand considering how tedious 
> that is. So my question is: if an option gets only one argument,
> should we turn it's description automatically into the
> option-description? Probably prefixed by something like `specify: '?

Sounds like a good idea.  How about a configuration key which in this
case would be something like `specify: %s'?

Adam

Re: PATCH: _mutt, _mailboxes

[Sven Wischnowsky]

Clint Adams wrote:

> This is my stab at completion for mutt.  I imagine that the
> _mailboxes function would be useful for completing the -f arguments
> of elm and pine, after some tweaking.
> 
> ...
>
> +  '-h+:help' \

I thought I mentioned that in the docs, but it seems like I forgot it: 
the `:' after the message is needed even if the action is empty.

And while I'm at it... I'm the only one who writes option
descriptions, it seems, which I can understand considering how tedious 
that is. So my question is: if an option gets only one argument,
should we turn it's description automatically into the
option-description? Probably prefixed by something like `specify: '?

Bye
 Sven

diff -u od/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- od/Zsh/compsys.yo	Thu Sep 16 14:16:06 1999
+++ Doc/Zsh/compsys.yo	Thu Sep 16 15:06:49 1999
@@ -839,7 +839,10 @@
 
 In places where no sensible matches can be generated, the action
 should consist of only a space. This will make the var(message) be
-displayed but no possible completions listed.
+displayed but no possible completions listed. Note that even in this
+case the colon at the end of the var(message) is needed. The only case 
+where it can be left is when neither a var(message), nor a var(action) 
+is given.
 
 To include a colon in the var(message) or the var(action), it has to
 be preceded by a backslash.
--- oldcompletion/User/_mutt	Thu Sep 16 15:00:18 1999
+++ Completion/User/_mutt	Thu Sep 16 15:07:05 1999
@@ -10,7 +10,7 @@
  '-e:post-init configuration:' \
  '-f+:mailbox:_mailboxes' \
  '-F+:init file:_files' \
- '-h+:help' \
+ '-h+:help:' \
  '-H+:draft file:_files' \
  '-i:include file:_files' \
  '-m+:default mailbox type:(mbox MMDF MH Maildir)' \

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