Re: is "lei mark" a good name?

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

Eric Wong <e@80x24.org> wrote:
> 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.

OK, so I've gone ahead with "lei blob" so far...

"git show" has a plethora of options affecting diff generation
which would be redundant to have in lei.  "lei blob" can focus
on reconstructing and showing blobs.  The name also corresponds
to the JSON output field of "lei q".

I like "lei tag", more than "lei mark", since I think "tag" is
more commonly used for attaching metadata labels to stuff.

"lei tag" might still give people the idea that it's for
operating on git tags (because "lei blob" operates on git blobs);
but I don't think it's a huge risk since our code base does
nothing with git tags