unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
* search-tags and tag completion in notmuch.el
@ 2009-11-23  0:56 Jan Janak
  2009-11-26 15:23 ` On "search-tags" vs. "search --for tags" (was: search-tags and tag completion in notmuch.el) Carl Worth
  0 siblings, 1 reply; 2+ messages in thread
From: Jan Janak @ 2009-11-23  0:56 UTC (permalink / raw)
  To: notmuch

Hello,

The three patches I sent to the list a couple of minutes ago is another
revision of the patches that I had sent earlier. The first two patches
implement support for 'notmuch search-tags'. The last patch adds support
for tag completion to notmuch.el using the new command.

Right now 'notmuch search-tags' can only list all tags from the
database, it does not support search-terms yet (i.e. it cannot list tags
for a restricted set of messages or threads), but I am working on that
feature and I'm gonna send another patch implementing that soon. I think
sending more smaller incremental patches makes it easier to review them
(and for me personally it is easier to keep them up-to-date on top of
moving Carl's git repository).

I considered implementing 'notmuch search --output=tags' (as we
discussed in another email), but it turned out that:

  * Having 'notmuch search-tags' would be consistent with Carl's
    'notmuch search-messages'.

  * 'notmuch search' supports other command line options (--first,
    --max-threads, --sort) and these would only work when the user uses
    the command to search for messages. They would probably be useless
    if we use the command to search for tags and messages (well, at
    least some of them). Which means we would have to let the user know
    in the documentation, or disable some of them based on the value of
    the --output command line parameter, etc etc...

  * 'notmuch search-tags' is easier on fingers than 
    'notmuch search --output=tags' :-).

In any case, we should probably keep it consistent with other commands
and because Carl submitted 'notmuch search-messages", I did the same for
tags.

I'd personally prefer to use different commands for different kinds of
output rather than overloading 'notmuch search' with more command line
options, but it's just a personal preference. I can change the patch
again if we decide that we're going to overload 'notmuch search' rather
than add more commands.

Comments, ideas, and suggestions are welcome!

  -- Jan

^ permalink raw reply	[flat|nested] 2+ messages in thread

* On "search-tags" vs. "search --for tags" (was: search-tags and tag completion in notmuch.el)
  2009-11-23  0:56 search-tags and tag completion in notmuch.el Jan Janak
@ 2009-11-26 15:23 ` Carl Worth
  0 siblings, 0 replies; 2+ messages in thread
From: Carl Worth @ 2009-11-26 15:23 UTC (permalink / raw)
  To: Jan Janak, notmuch

On Mon, 23 Nov 2009 01:56:04 +0100, Jan Janak <jan@ryngle.com> wrote:
> I considered implementing 'notmuch search --output=tags' (as we
> discussed in another email), but it turned out that:
> 
>   * Having 'notmuch search-tags' would be consistent with Carl's
>     'notmuch search-messages'.

Yes, but I just put that out as an RFC. I didn't actually push it out in
that form, (and my big concern was overwhelming the user with a lot of
different top-level commands).

>   * 'notmuch search' supports other command line options (--first,
>     --max-threads, --sort) and these would only work when the user uses
>     the command to search for messages.

Fortunately, the --first and --max-threads options are gone now. So some
of that concern is gone now.

>   * 'notmuch search-tags' is easier on fingers than 
>     'notmuch search --output=tags' :-).

We can shorten the command with something like:

	notmuch search --for=tags

Is that any better? I don't love the '=' there, and might prefer:

	notmuch search --for tags

But that complicates the option parsing just a bit, (which I shouldn't
really care about since what we're designing here is an interface that
is easy for the user).

In any case, I don't expect people typing at the command-line to do
things like search for tags nearly as often as searching for
threads. And that's really the biggest reason I *do* want to put this
functionality behind a command-line option. I'd like to have a fairly
short number of top-level commands that are each something a person at
the command-line would be likely to use fairly regularly.

Thanks that are more likely to be used by scripts, (such as
--format=html), should be hidden behind options.

-Carl

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-11-26 15:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-23  0:56 search-tags and tag completion in notmuch.el Jan Janak
2009-11-26 15:23 ` On "search-tags" vs. "search --for tags" (was: search-tags and tag completion in notmuch.el) Carl Worth

Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).