Hi David! On Do, 03 Nov 2011, David Champion wrote:
> * On 03 Nov 2011, Cameron Simpson wrote: > > On 03Nov2011 10:05, Edward Morbius <dredmorb...@gmail.com> wrote: > > | Is there any facility similar to Gmail's named tags (other than > > | folders) for mutt? > > | > > | I'd like to be able to add (multiple) labels to a given message, > > | possible automatically (procmail, some imap tool, mutt folder hooks), > > | have mutt be aware of defined labels, and be able to quickly filter > > | messages by labels (including and/or/not Boolean logic). > > > > The X-Label: header is the usual convention for this in mutt-land. > > ... [good information elided] ... > > I wrote the X-Label code for mutt 11 years ago but recently have been > wishing for more capability and better integration with other keywording > standards and conventions. (X-Label was invented just for mutt because > there were no plausible conventions or standards yet.) > > If you use X-labels heavily and are comfortable building > mutt from source I encourage you to take a look at > https://bitbucket.org/dgc/mutt-dgc/qseries and apply at least up to the > complete-pattern-y patch. This is the direction that I'd like mutt > mainline to go in the future but I'm not comfortable pushing it until > it's had more field testing. (That said, I've been using it since > April without concern.) > > Here's the full mercurial commit log for these patches. The xlabel_ext > patch is actually quite old, but the others are new this year. > > --------------------------------------------------------------------------- > patch: hashwalk > > Add reentrant hash_walk() function for iterating down a hash table. > --------------------------------------------------------------------------- > patch: dgc.xlabel_ext > > Adds capability to edit x-labels inside mutt, and to sort by label. > --------------------------------------------------------------------------- > patch: xlabel_complete > > Adds label completion. > > A global label hash is added, to which labels are added as they're parsed > from a mailbox file or edited manually by the user. Reference counts are > kept in the hash table so that unused labels are removed from available > completions. Completion is available in the label editor only, but it may > be feasible to add for search expressions if the preceding text ends with > '~y'. > --------------------------------------------------------------------------- > patch: keywords > > Unify label/keyword handling. > > Since x-labels were added to mutt in 2000, a number of other approaches to > what we now call 'tagging' have also emerged. One of them was even made > standard in RFC 2822. This update unifies the handling of all these > strategies. > > We start by changing mutt's internal keyword storage from a single string > which may contain whitespace to a list of discrete keywords. This has > advantages for keyword completion as well as for portabilty among varying > "standards" for keyword storage. This may represent a significant change > for existing mutt users who have set x-labels containing spaces, and should > be regarded with suspicion. The advantages are significant, though. > > Next we allow mutt to parse keywords into this internal list from any of the > following headers: X-Label (freeform), X-Keywords (space-delimited), X > -Mozilla-Keys (space-delimited), and Keywords (RFC 2822, comma-space- > delimited). Mutt remembers which headers it sourced keywords from, and will > rewrite those headers when saving messages for compatibility with the mailer > of origin. > > (X-Label was specified as freeform text by mutt, its only known > implementation. X-Labels have been used both as a 'tagging' device, > probably with space delimiting, and as a 'memo' field, where space-delimited > parsing would ruin the semantics of the memo. By default mutt will not > split X-Labels at all. Set $xlabel_delimiter if your needs vary.) > > Finally we add the save_keywords boolean, which defaults to FALSE. When > true, this boolean causes mutt to always save all keywords to the Keywords: > header in addition to whatever origin headers were retained for > compatibility. > > Overall this represents convergence path for all competing > labelling/tagging/kewording systems toward one that is specified by RFC. > --------------------------------------------------------------------------- > patch: complete-pattern-y > > Permit tab completion of pattern expressions with ~y (labels). > --------------------------------------------------------------------------- Wow, this really looks interesting. Thanks for sharing. Hope something like this makes it into mutt soon. regards, Christian
