DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma;
	h=subject:from:to:in-reply-to:references:date:message-id:user-agent
	:content-transfer-encoding:mime-version:content-type;
	b=RO+avPu1ITqqU2my3pIF3+fgMEjPCxwsv6Zxfu7jAQ0XedT6H2waINa0ZmKzT+6vAg
	U6h0Pwlz3atT/8Y+BnGpZ9vpnrgkfkwvBjQKBqP3xlploZCUUdtfsJQ/KxEm3o3MtLKX
	RhiAfYE9EDy8YKfnV8JP8dnPci0HQG1ducmAE=
Subject: Re: a python terminal gui?
From: Patrick Totzke <patricktotzke@googlemail.com>
To: notmuch@notmuchmail.org
In-reply-to: <87pqndoww8.fsf@yoom.home.cworth.org>
References: <1305888097-sup-2343@optimusprime>
	<87pqndoww8.fsf@yoom.home.cworth.org>
Date: Sat, 21 May 2011 15:53:56 +0100
Message-Id: <1305989550-sup-9586@brick>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-1305989636-651577-22279-1925-1-=";
	protocol="application/pgp-signature"
Precedence: list


--=-1305989636-651577-22279-1925-1-=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Again,

Excerpts from Carl Worth's message of Fri May 20 23:00:23 +0100 2011:
> > However, as a vim user I feel that the one thing that's truly missing=
 is a =

> > maintainable, feature-rich commandline GUI.
> =

> "... that's not implemented in emacs" you mean? ;-)
of course :D

> It's funny to me that you used the name "notmuch-gui" since I've always=

> understood the 'G' in GUI to indicate "graphical", to distinguish from
> non-graphical terminal interfaces like you propose here.
I always intuitively understood "graphical" as anything visual.
But your right, http://en.wikipedia.org/wiki/Graphical_user_interface
suggests that a curses-like interface is not a GUI nor a CLI.
Anyhow, I agree that at some point I'll need a real name.

> I believe all new code should be doing "import notmuch" rather than
> "import cnotmuch", and if there is any package that installs bindings
> that work as "cnotmuch" we should get those updated right away.
Thanks for the clarification. I assume I'll always get the current
bindings distributed with notmuch itself.
A make target inside notmuch/bindings/python would indeed be helpful.

> > You can find the code at here: https://github.com/pazz/notmuch-gui =

> I was a bit surprised to see so many results in my initial view. I'd
> expect a default view to be tag:inbox rather than tag:unread. (I didn't=

> realize I had over 100 thousand messages with the unread tag, but
> apparently I do.) Perhaps that's a sup default that I've long since
> forgotten?
Yep, its an artefact of my debugging behaviour. Having the initial
buffer show the inbox makes total sense and is also what sup does.

>   * The interface blocks for a while when searching for something (like=

>     "tag:unread" in my case) that returns a *lot* of results. Are you
>     somehow sucking in all the results immediately rather than just wha=
t
>     you need to dill the current screen?
That is surprising! I only fill the screen by iterating over an initial
part of the iterator returned by Query.search_threads()
I do a second query to count the messages by Query.count_messages(),
but I'd guess that this translates to some sort of "SELECT COUNT"
and should also be fast. Maybe there's some copying going on =

at lower levels?

>   * I was a bit surprised that 'i' and 'u' kept opening new buffers
>     rather than switching to an existing buffer.
It shouldn't be like this, I agree. I'm just annoyed that sup treats
the inbox view different from other searches, in terms of keybindings.
But nevertheless one could have "I" point to a unique inbox search
buffer.

>   * The '/' key didn't seem to do anything for me, so I wasn't able to
>     actually do any custom searches.
This is because it really is "\" :P that was a typo in the README.

> It looks like a fine start to me. Please let me know if there's anythin=
g
> I can do to help with this, (in terms of hosting the code or anything
> else).
Thanks, that's helpful. I guess it would make sense to place this under
notmuch/contrib at a later point if it gets usable.

Ah I have question regarding "toplevel" messages in threads:
How can it be that a mail that is not the one that started a thread
is contained in thread.get_toplevel_messages() ?
The only thing I can think of is that a user somehow forced two threads
to become one. Take this very thread for example. Why do I get
Mueen Nawaz's reply as a toplevel message? does this mean
that messages header has incorrect Reply-to headers set?

@Mueen Nawaz: It's a good idea to post this on the wiki. Will do.

Cheers,
/p

--=-1305989636-651577-22279-1925-1-=
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3X0gQACgkQlDQDZ9fWxaoMkQCgzX4RQU6FjA4hYmjbR2yMMSJY
o7MAoMWFtps2ZoLqnNZGDY2LTY7gWSXk
=fLnp
-----END PGP SIGNATURE-----

--=-1305989636-651577-22279-1925-1-=--