[PATCH] emacs: Make the queries used in the all-tags section
a python terminal gui?
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: <http://notmuchmail.org/pipermail/notmuch/attachments/20110520/b29a4e88/attachment.pgp>
a python terminal gui?
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: <http://notmuchmail.org/pipermail/notmuch/attachments/20110520/7dafe66c/attachment.pgp>
My mail configuration
On Wed, 23 Feb 2011 09:22:57 -0500, Ben Gamari wrote: > Here is my mail sorting script that has been slowly evolving for almost > a year now. It uses the Python bindings, along with Bogofilter for spam > filtering. There is also an update-spam script which brings the > Bogofilter database in to synchronization with the notmuch tags. On this > note, if someone wants to implement the ability to hide certain tags > (say, those matching /\..+/) in the emacs interface it would be greatly > appreciated. I have notmuch configured such that all new mail starts > with just the "new" tag. The sorting script then takes it from > there. Hope this will give folks some ideas. Hi Ben, After a few previous tries, I finally came up with a notmuch setup that works for me, and it's largely thanks to your example, which I've modified slightly (of course ;) to suit my own purposes. The thing that I really liked was the 'watch' tag for mailing list messages, but after initial experimentation with it, I still felt paranoid about missing stuff that I cared about, since anything that does not go through my inbox is unlikely to ever show up on my radar. The solution I chose was to have an 'unwatch' tag (which could do with a better name, maybe 'ignore', or 'skip-inbox') that I apply to threads that I have no interest in. I also decided that (for me) this was not really tied to mailing list messages. My change made the script quite a bit simpler, (it gets rid of the unseen tag for one thing,) though at the cost of some of the original functionality, I realize. So, while I doubt this will be massively useful to you, or other people with a lot of list traffic with a very high noise-to-signal ratio, it may be of interest to others who have use cases more like my own. I put my copies under version control here: http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/sort_mail.py http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/update_junk.py (Though I'm not sure I changed anything substantial in the second one.) Also I made some simple keybindings to mark stuff as junk/unwatch in my .emacs: http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/.emacs#L552 Hope someone finds this of use, -- eric casteleijn https://launchpad.net/~thisfred
a python terminal gui?
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?
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?
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 pgp2ey3v64bGN.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: My mail configuration
On Wed, 23 Feb 2011 09:22:57 -0500, Ben Gamari wrote: > Here is my mail sorting script that has been slowly evolving for almost > a year now. It uses the Python bindings, along with Bogofilter for spam > filtering. There is also an update-spam script which brings the > Bogofilter database in to synchronization with the notmuch tags. On this > note, if someone wants to implement the ability to hide certain tags > (say, those matching /\..+/) in the emacs interface it would be greatly > appreciated. I have notmuch configured such that all new mail starts > with just the "new" tag. The sorting script then takes it from > there. Hope this will give folks some ideas. Hi Ben, After a few previous tries, I finally came up with a notmuch setup that works for me, and it's largely thanks to your example, which I've modified slightly (of course ;) to suit my own purposes. The thing that I really liked was the 'watch' tag for mailing list messages, but after initial experimentation with it, I still felt paranoid about missing stuff that I cared about, since anything that does not go through my inbox is unlikely to ever show up on my radar. The solution I chose was to have an 'unwatch' tag (which could do with a better name, maybe 'ignore', or 'skip-inbox') that I apply to threads that I have no interest in. I also decided that (for me) this was not really tied to mailing list messages. My change made the script quite a bit simpler, (it gets rid of the unseen tag for one thing,) though at the cost of some of the original functionality, I realize. So, while I doubt this will be massively useful to you, or other people with a lot of list traffic with a very high noise-to-signal ratio, it may be of interest to others who have use cases more like my own. I put my copies under version control here: http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/sort_mail.py http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/update_junk.py (Though I'm not sure I changed anything substantial in the second one.) Also I made some simple keybindings to mark stuff as junk/unwatch in my .emacs: http://bazaar.launchpad.net/~thisfred/+junk/scripts/view/head:/.emacs#L552 Hope someone finds this of use, -- eric casteleijn https://launchpad.net/~thisfred ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: a python terminal gui?
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) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
problems with multipart/mixed
Hi all,
I am using notmuch / emacs as my main mail client now for several months
and loosely follow master.
After an update yesterday I now have problems with some multipart/mixed
mails from mailing lists which are displayed for example as follows (I
could also provide the raw mail if needed):
8<--
Subject: [Haskell-cafe] Can't access map value with key.
To: "haskell-c...@haskell.org"
Date: Sat, 21 May 2011 04:04:31 +0200
[ multipart/mixed ]
[ text/html ]
___ Haskell-Cafe mailing
list haskell-c...@haskell.org http://
www.haskell.org/mailman/listinfo/haskell-cafe
[ ATT1.c: text/plain ]
[ 4-line signature. Click/Enter to toggle visibility. ]
8<--
i.e. the html part is not displayed. I'd like to have it displayed
inline (using w3m), just as other html mails and just like it worked
before (at least I think it worked). I probably just missed a simple
configuration option.
My notmuch config in .emacs (and my message mode config) is at the end
of this mail. From the git logs I saw that there have been some changes
to multipart handling and new variables, but I could not really find a
solution.
Perhaps someone can point out where my current config is broken.
best regards
Matthias
;; f_r notmuch
(require 'notmuch)
(setq message-send-mail-function 'smtpmail-send-it)
(setq smtpmail-smtp-server MYSMTP)
(setq smtpmail-smtp-service 25)
(setq user-mail-address MYMAIL)
(setq message-default-mail-headers "Cc: MYMAIL\nBcc: \n")
(setq message-auto-save-directory "~/MailNoBackup/drafts")
(add-hook 'message-mode-hook '(lambda () (flyspell-mode t)))
(add-hook 'message-mode-hook '(lambda () (footnote-mode t)))
;; message-mode stuff
(setq mm-text-html-renderer 'w3m)
(setq mm-attachment-override-types '("image/.*"))
(setq w3m-display-inline-image t)
(setq mm-inline-text-html-with-images "")
;; gnus stuff
...
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
