a python terminal gui?

[Sebastian Spaeth]

On Fri, 20 May 2011 15:00:23 -0700, Carl Worth  wrote:
> Is the name "cnotmuch" still current anywhere? Long ago, (perhaps a year
> ago last April when we incorporated the python bindings into the notmuch
> repository), we decided that the python bindings should be named
> "notmuch" rather than "cnotmuch".

Nah, should just be just "notmuch" nowadays. mmh, I *still* didn't get
to implement message_get_filenames... *sigh*

> I notice that notmuch/python/bindings/README does still mention
> "cnotmuch" in some of the explanatory text.

Ooops, leftovers. Someone fix it (or I might)

> (On a similar note, I also notice
> that this README doesn't provide installation instructions, nor is there
> anything like a "make install" target for the bindings. So this could
> probably be integrated more cleanly.)

Because it doesn't have to be installed to be used, you can use it in
place ;-). But yes, I'll explain how to do "python setup.py install" in
the README.

> Incidentally, the python-notmuch Debian package does provide "notmuch"
> rather than "cnotmuch".

Yes, notmuch is right.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: a python terminal gui?

[Sebastian Spaeth]

On Fri, 20 May 2011 15:00:23 -0700, Carl Worth cwo...@cworth.org wrote:
 Is the name cnotmuch still current anywhere? Long ago, (perhaps a year
 ago last April when we incorporated the python bindings into the notmuch
 repository), we decided that the python bindings should be named
 notmuch rather than cnotmuch.

Nah, should just be just notmuch nowadays. mmh, I *still* didn't get
to implement message_get_filenames... *sigh*

 I notice that notmuch/python/bindings/README does still mention
 cnotmuch in some of the explanatory text.

Ooops, leftovers. Someone fix it (or I might)

 (On a similar note, I also notice
 that this README doesn't provide installation instructions, nor is there
 anything like a make install target for the bindings. So this could
 probably be integrated more cleanly.)

Because it doesn't have to be installed to be used, you can use it in
place ;-). But yes, I'll explain how to do python setup.py install in
the README.

 Incidentally, the python-notmuch Debian package does provide notmuch
 rather than cnotmuch.

Yes, notmuch is right.

Sebastian


pgpo1sunXWnVH.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: a python terminal gui?

[Carl Worth]

On Tue, 24 May 2011 10:28:02 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
  I notice that notmuch/python/bindings/README does still mention
  cnotmuch in some of the explanatory text.
 
 Ooops, leftovers. Someone fix it (or I might)

I just went through this README and fixed everything that I could test.

I left one reference to cnotmuch as follows:

http://bitbucket.org/spaetz/cnotmuch

Is there a new URL for the source without cnotmuch in the name?

Otherwise, the instructions should be much better now, (since the old
instructions had easy_install cnotmuch which would lead a user to
install ancient bindings).

-Carl

-- 
carl.d.wo...@intel.com


pgphQVACFPTgX.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

a python terminal gui?

[Carl Worth]

On Sat, 21 May 2011 19:50:37 +0100, Patrick Totzke  wrote:
> 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?

The "count" operation should be something very fast, yes.

It might be worth some investigation to see if there's actually a
problem here or not.

> >   * 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.

Ah. Thanks. That definitely helps.

> Thanks, that's helpful. I guess it would make sense to place this under
> notmuch/contrib at a later point if it gets usable.

Sure. I'll be glad to do that. Just let me know when you want it.

> 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?

Hmmm... I do seem to be seeing that behavior.

The message from Mueen Nawaz (id:"87y620subn.fsf at fester.com") does not
have any In-Reply-To header, but it does contain the following:

References: <1305888097-sup-2343 at optimusprime>

which is the correct message ID for the original top-level message in
the thread.

So it looks like there's a bug here in notmuch not correctly stitching
this message to its parent in this case. It should be an easy test case
to add to the suite (and hopefully an easy bug to fix as well).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: a python terminal gui?

[Carl Worth]

On Sat, 21 May 2011 19:50:37 +0100, Patrick Totzke 
patricktot...@googlemail.com wrote:
 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?

The count operation should be something very fast, yes.

It might be worth some investigation to see if there's actually a
problem here or not.

* 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.

Ah. Thanks. That definitely helps.

 Thanks, that's helpful. I guess it would make sense to place this under
 notmuch/contrib at a later point if it gets usable.

Sure. I'll be glad to do that. Just let me know when you want it.

 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?

Hmmm... I do seem to be seeing that behavior.

The message from Mueen Nawaz (id:87y620subn@fester.com) does not
have any In-Reply-To header, but it does contain the following:

References: 1305888097-sup-2343@optimusprime

which is the correct message ID for the original top-level message in
the thread.

So it looks like there's a bug here in notmuch not correctly stitching
this message to its parent in this case. It should be an easy test case
to add to the suite (and hopefully an easy bug to fix as well).

-Carl


pgpMWqSqTQmuX.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

a python terminal gui?

[Patrick Totzke]

Hi Again,
sorry if this comes as a repost..

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 what
> 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 anything
> 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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 

a python terminal gui?

[Patrick Totzke]

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 what
> 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 anything
> 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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

Re: a python terminal gui?

[Patrick Totzke]

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 what
 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 anything
 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


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: a python terminal gui?

[Patrick Totzke]

Hi Again,
sorry if this comes as a repost..

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 what
 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 anything
 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


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

a python terminal gui?

[Mueen Nawaz]

Patrick Totzke 
writes:


> * use libraries wherever possible. Therefore, instead of
>   programming raw curses, I go for the urwid toolkit: It's a bit like gtk,
>   you create a bunch of widgets and put them together in a tree-like structure
>   and the library handles redrawing the screen and redirecting key presses 
> etc.
>   I'm aware of some arguments against urwid (PEP8 compatibility, slow py3k 
> awareness),
>   but consider the advantages:

Not too long ago, I felt likewise and even looked at urwid for precisely
this goal. Unfortunately, real life interfered, and continues to do so,
so it may be a long time before I can fiddle with it. 

This, IMO, is much needed. I personally think I have most of the things
I need (as opposed to want) working in Emacs, and as an Emacs user, I'd
like to stick to Emacs. 

However, I know Python, and don't know elisp - so it'd be great to have
a Python interface. If there's a feature I want, I could one day try
implementing it in that interface, show to everyone here how cool it is,
and hopefully some soul will feel deprived and port it to the Emacs
interface ;-)

I'd encourage you to post this on the Wiki on the notmuch web site. 

On a side note, I see that someone created an entry for notmuch on Open
Hatch (openhatch.org). However, no requests for features has been
added. I really don't know how effective Open Hatch is, but Carl or
someone else may want to consider utilizing it. 

(For those still confused, Open Hatch is a web site that encourages
people to contribute to open source projects - via code, via docs, via
web maintenance, etc. It seems to integrate with existing bug tracking
sites, and has a bunch of other cool features as well. You can see their
Google Tech Talk at: http://www.youtube.com/watch?v=Qt3yPm7mKEc)

a python terminal gui?

[Carl Worth]

On Fri, 20 May 2011 11:47:41 +0100, Patrick Totzke  wrote:
> Hi all,

Hi Patrick. Welcome to notmuch.

> First of all, Thanks to everybody involved in the project. Using notmuch is
> good fun

I'm really pleased that you are finding notmuch to be fun and useful.

> 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? ;-)

> I'm aware of existing proposed guis: vala-notmuch, notsomuch, I have also 
> seen 
> a minimal non-oop python gui that doesn't use the python bindings and
> whose name 

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.

Anyway, I'm quite pleased to see you working on this and I wish you lots
of success.

>   On the other hand, cnotmuch and all other libs I (plan to) use in this 
> project
>   were easy_installed without any problems.

Is the name "cnotmuch" still current anywhere? Long ago, (perhaps a year
ago last April when we incorporated the python bindings into the notmuch
repository), we decided that the python bindings should be named
"notmuch" rather than "cnotmuch".

I notice that notmuch/python/bindings/README does still mention
"cnotmuch" in some of the explanatory text. But, significantly, it has
"import notmuch" in its code example. (On a similar note, I also notice
that this README doesn't provide installation instructions, nor is there
anything like a "make install" target for the bindings. So this could
probably be integrated more cleanly.)

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.

Incidentally, the python-notmuch Debian package does provide "notmuch"
rather than "cnotmuch".

> You can find the code at here: https://github.com/pazz/notmuch-gui 

I've got the code and was able to run it after changing each occurrence
of:

from cnotmuch.notmuch import ...
to:
from notmuch import

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?


Anyway, I was able to get the "i" and "u" keybindings to work at least.

Here are a few of my immediate thoughts:

  * 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 what
you need to dill the current screen?

  * I was a bit surprised that 'i' and 'u' kept opening new buffers
rather than switching to an existing buffer.

  * The '/' key didn't seem to do anything for me, so I wasn't able to
actually do any custom searches.

> I consider all of this to be a proof-of-concept, any part of this proposal
> is up for discussion.

It looks like a fine start to me. Please let me know if there's anything
I can do to help with this, (in terms of hosting the code or anything
else).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

a python terminal gui?

[Patrick Totzke]

Hi all,

First of all, Thanks to everybody involved in the project. Using notmuch is
good fun and I totally agree that the spin-off/rewrite of sup is a great idea.
However, as a vim user I feel that the one thing that's truly missing is a 
maintainable, feature-rich commandline GUI. Let's change that.
I'm aware of existing proposed guis: vala-notmuch, notsomuch, I have also seen 
a minimal non-oop python gui that doesn't use the python bindings and whose 
name 
I forgot.

This is a proposal for a terminal gui, written in python.
Currently, it is more a sketch of a framework, so let me explain the key ideas 
here:

* I use python because I personally am heavily biased in the python vs. ruby 
discussion:
  I've been working with python for a while and have never used ruby anywhere 
else than 
  for my sup-mail config. I find rubys syntax highly unintuitive, had (and 
still have)
  problems to install/work with up-to-date ruby-gems on my ubuntu system.
  Also, I read somewhere? that sup is based on a email library that is no 
longer maintained.
  I know these are only my personal, non representative and maybe uninformed 
impressions,
  but I have the feeling that I'm not alone here.
  On the other hand, cnotmuch and all other libs I (plan to) use in this project
  were easy_installed without any problems.

* I want a gui that looks and feels like sup, without the ugly parts.

* use libraries wherever possible. Therefore, instead of
  programming raw curses, I go for the urwid toolkit: It's a bit like gtk,
  you create a bunch of widgets and put them together in a tree-like structure
  and the library handles redrawing the screen and redirecting key presses etc.
  I'm aware of some arguments against urwid (PEP8 compatibility, slow py3k 
awareness),
  but consider the advantages:
   - no boring and error-prone ncurses hacking
   - possibly multiple frontends (curses, web)
   - correct display of unicode chars
   - a lot of ready-made widgets are available (textboxes, selectable lists). 
There's even
 an additional widget-lib called urwid-sat that defines widgets for 
password inputs etc.
   - ready made colour theming for mono/16/256 colours.

  one might also look around for a mutt/abook contact lib

You can find the code at here: https://github.com/pazz/notmuch-gui 
Obviously, there is a lot that's missing, but I think having this framework 
makes it easier
for anyone to contribute. For example, to be able to display mails,
one could code a urwid.Widget that can display a given email.message.Message.
That widget will then be used in a widget that displays a whole notmuch.thread
which we could put inside a new buffer class that extends my ng.buffer.Buffer
So far, there are only two modi (ng.buffer.Buffer subclasses):
a bufferlist and one to display thread search results.

I consider all of this to be a proof-of-concept, any part of this proposal
is up for discussion. I'd be interested in any feedback whatsoever, and happy
to delegate work to anybody willing to contribute. I'm aware that the code
is not pretty, probably not the sleekest oop design and non-conforming 
with a lot of conventions. Hit me :)

Cheers,
/pazz

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 

a python terminal gui?

[Patrick Totzke]

Hi all,

First of all, Thanks to everybody involved in the project. Using notmuch is
good fun and I totally agree that the spin-off/rewrite of sup is a great idea.
However, as a vim user I feel that the one thing that's truly missing is a 
maintainable, feature-rich commandline GUI. Let's change that.
I'm aware of existing proposed guis: vala-notmuch, notsomuch, I have also seen 
a minimal non-oop python gui that doesn't use the python bindings and whose 
name 
I forgot.

This is a proposal for a terminal gui, written in python.
Currently, it is more a sketch of a framework, so let me explain the key ideas 
here:

* I use python because I personally am heavily biased in the python vs. ruby 
discussion:
  I've been working with python for a while and have never used ruby anywhere 
else than 
  for my sup-mail config. I find rubys syntax highly unintuitive, had (and 
still have)
  problems to install/work with up-to-date ruby-gems on my ubuntu system.
  Also, I read somewhere™ that sup is based on a email library that is no 
longer maintained.
  I know these are only my personal, non representative and maybe uninformed 
impressions,
  but I have the feeling that I'm not alone here.
  On the other hand, cnotmuch and all other libs I (plan to) use in this project
  were easy_installed without any problems.

* I want a gui that looks and feels like sup, without the ugly parts.

* use libraries wherever possible. Therefore, instead of
  programming raw curses, I go for the urwid toolkit: It's a bit like gtk,
  you create a bunch of widgets and put them together in a tree-like structure
  and the library handles redrawing the screen and redirecting key presses etc.
  I'm aware of some arguments against urwid (PEP8 compatibility, slow py3k 
awareness),
  but consider the advantages:
   - no boring and error-prone ncurses hacking
   - possibly multiple frontends (curses, web)
   - correct display of unicode chars
   - a lot of ready-made widgets are available (textboxes, selectable lists). 
There's even
 an additional widget-lib called urwid-sat that defines widgets for 
password inputs etc.
   - ready made colour theming for mono/16/256 colours.
   
  one might also look around for a mutt/abook contact lib

You can find the code at here: https://github.com/pazz/notmuch-gui 
Obviously, there is a lot that's missing, but I think having this framework 
makes it easier
for anyone to contribute. For example, to be able to display mails,
one could code a urwid.Widget that can display a given email.message.Message.
That widget will then be used in a widget that displays a whole notmuch.thread
which we could put inside a new buffer class that extends my ng.buffer.Buffer
So far, there are only two modi (ng.buffer.Buffer subclasses):
a bufferlist and one to display thread search results.

I consider all of this to be a proof-of-concept, any part of this proposal
is up for discussion. I'd be interested in any feedback whatsoever, and happy
to delegate work to anybody willing to contribute. I'm aware that the code
is not pretty, probably not the sleekest oop design and non-conforming 
with a lot of conventions. Hit me :)

Cheers,
/pazz



signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: a python terminal gui?

[Carl Worth]

On Fri, 20 May 2011 11:47:41 +0100, Patrick Totzke 
patricktot...@googlemail.com wrote:
 Hi all,

Hi Patrick. Welcome to notmuch.

 First of all, Thanks to everybody involved in the project. Using notmuch is
 good fun

I'm really pleased that you are finding notmuch to be fun and useful.

 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? ;-)

 I'm aware of existing proposed guis: vala-notmuch, notsomuch, I have also 
 seen 
 a minimal non-oop python gui that doesn't use the python bindings and
 whose name 

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.

Anyway, I'm quite pleased to see you working on this and I wish you lots
of success.

   On the other hand, cnotmuch and all other libs I (plan to) use in this 
 project
   were easy_installed without any problems.

Is the name cnotmuch still current anywhere? Long ago, (perhaps a year
ago last April when we incorporated the python bindings into the notmuch
repository), we decided that the python bindings should be named
notmuch rather than cnotmuch.

I notice that notmuch/python/bindings/README does still mention
cnotmuch in some of the explanatory text. But, significantly, it has
import notmuch in its code example. (On a similar note, I also notice
that this README doesn't provide installation instructions, nor is there
anything like a make install target for the bindings. So this could
probably be integrated more cleanly.)

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.

Incidentally, the python-notmuch Debian package does provide notmuch
rather than cnotmuch.

 You can find the code at here: https://github.com/pazz/notmuch-gui 

I've got the code and was able to run it after changing each occurrence
of:

from cnotmuch.notmuch import ...
to:
from notmuch import

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?


Anyway, I was able to get the i and u keybindings to work at least.

Here are a few of my immediate thoughts:

  * 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 what
you need to dill the current screen?

  * I was a bit surprised that 'i' and 'u' kept opening new buffers
rather than switching to an existing buffer.

  * The '/' key didn't seem to do anything for me, so I wasn't able to
actually do any custom searches.

 I consider all of this to be a proof-of-concept, any part of this proposal
 is up for discussion.

It looks like a fine start to me. Please let me know if there's anything
I can do to help with this, (in terms of hosting the code or anything
else).

-Carl


pgp2ey3v64bGN.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: a python terminal gui?

[Mueen Nawaz]

Patrick Totzke patricktot...@googlemail.com
writes:


 * use libraries wherever possible. Therefore, instead of
   programming raw curses, I go for the urwid toolkit: It's a bit like gtk,
   you create a bunch of widgets and put them together in a tree-like structure
   and the library handles redrawing the screen and redirecting key presses 
 etc.
   I'm aware of some arguments against urwid (PEP8 compatibility, slow py3k 
 awareness),
   but consider the advantages:

Not too long ago, I felt likewise and even looked at urwid for precisely
this goal. Unfortunately, real life interfered, and continues to do so,
so it may be a long time before I can fiddle with it. 

This, IMO, is much needed. I personally think I have most of the things
I need (as opposed to want) working in Emacs, and as an Emacs user, I'd
like to stick to Emacs. 

However, I know Python, and don't know elisp - so it'd be great to have
a Python interface. If there's a feature I want, I could one day try
implementing it in that interface, show to everyone here how cool it is,
and hopefully some soul will feel deprived and port it to the Emacs
interface ;-)

I'd encourage you to post this on the Wiki on the notmuch web site. 

On a side note, I see that someone created an entry for notmuch on Open
Hatch (openhatch.org). However, no requests for features has been
added. I really don't know how effective Open Hatch is, but Carl or
someone else may want to consider utilizing it. 

(For those still confused, Open Hatch is a web site that encourages
people to contribute to open source projects - via code, via docs, via
web maintenance, etc. It seems to integrate with existing bug tracking
sites, and has a bunch of other cool features as well. You can see their
Google Tech Talk at: http://www.youtube.com/watch?v=Qt3yPm7mKEc)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch