Re: is "lei mark" a good name?

[Eric Wong <e@80x24.org>]

Kyle Meyer <kyle@kyleam.com> wrote:
> Eric Wong writes:
> 
> > It can set/unset volatile metadata for any number of messages.
> >
> > "Volatile metadata" being "labels" (aka "mailboxes" in
> > JMAP-speak) and "keywords" (seen|flagged|answered|...),
> > (aka "flags" in IMAP/Maildir-speak).
> >
> > 	"lei mark +kw:seen"		# makes sense
> 
> > 	"lei mark +L:some-folder-name"	# might sound odd...
> >
> >
> > AFAIK, notmuch uses "notmuch tag" which combines both labels
> > and keywords into one thing: "tags".  But I'm also not a
> > notmuch user...
> 
> (I am, though I still might be wrong.)  Notmuch allows arbitrary tags to
> be associated with message IDs.  It has some automatic tags like
> "attachment", "encrypted", and "signed" that it adds when indexing.

Hmm..., JMAP has a "hasAttachment" property to search on.

> By default, it also syncs some maildir flags to its tags (e.g., "F ->
> flagged", "R -> replied", "No S -> unread").
> 
> As far as I understand, tags are never connected up to the maildir
> folder/location, though Notmuch does support a separate "folder:..."
> search term.

I've been thinking about storing source location data, too.
Having the source of an email in lei/store would make it easier
and faster to export keywords back to IMAP/Maildir.

> So, I guess in JMAP terms, Notmuch tags would be "mailboxes" (a subset
> of which are synced with maildir flags).

The arbitrary nm tags (and "attachment|signed|encrypted) would be
"mailboxes", yes.  But the Maildir flags are JMAP keywords:

	# LeiToMail.pm:
	my %kw2char = ( # Maildir characters
		draft => 'D',
		flagged => 'F',
		answered => 'R',
		seen => 'S'
	);

> > Would "lei tag" be better?
> 
> Neither one really jumps out to me as better.  "mark" sounds fine to me,
> and I don't find "tag" any more or less odd for the +L case above.

OK.  I'm still on the fence...

On one hand, "tag" is probably a more familiar term to users of
existing software.  Not just notmuch, but also other software
for music metadata, software (debtags), etc...

On the other hand, lei will support "lei show" to wrap "git show"
with SolverGit support.  Thus I'm worried "lei tag" might
be misconstrued as a wrapper for "git tag"...

But now that I think about it more; "lei show" probably won't
treat git tree/tag/commit objects any differently than "git show".
Perhaps "lei show" can be named "lei blob", instead.

Originally, I intended "lei show" to do something with commit
objects; but we already have "lei p2q" which lends itself
better to composability.