Re: a python terminal gui?
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
Re: a python terminal gui?
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
a python terminal gui?
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: <http://notmuchmail.org/pipermail/notmuch/attachments/20110521/3e676a26/attachment.pgp>
[notmuch] Mail in git
On Sat, 21 May 2011 09:05:54 +0200, martin f krafft wrote: > Has anyone worked on this since? No, haven't had the cycles... and SSD helped a bit to delay urgency. -- Stewart Smith
a python terminal gui?
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: <http://notmuchmail.org/pipermail/notmuch/attachments/20110521/b288c2ab/attachment.pgp>
[notmuch] Mail in git
also sprach Stewart Smith [2010.02.17.1107 +0100]: > On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith flamingspork.com> wrote: > > Using fast-import is interesting. Does it update the working tree? The > > big thing I wanted to avoid was creating a working tree (another million > > inodes being created is not ever what I need) > > > > Also interesting is the mention of creating packs on the fly... this > > could save the time in first writing the object and then packing it (as > > my script does). > > > > I'm going to play with this > > and I did. Has anyone worked on this since? -- martin | http://madduck.net/ | http://two.sentenc.es/ "one should never allow one's mind and one's foot to wander at the same time." -- edward perkins (yes, the librarian) spamtraps: madduck.bogus at madduck.net -- next part -- A non-text attachment was scrubbed... Name: digital_signature_gpg.asc Type: application/pgp-signature Size: 1124 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110521/ce09ef58/attachment.pgp>
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-cafe at haskell.org"
Date: Sat, 21 May 2011 04:04:31 +0200
[ multipart/mixed ]
[ text/html ]
___ Haskell-Cafe mailing
list Haskell-Cafe at 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
...
Re: [notmuch] Mail in git
On Sat, 21 May 2011 09:05:54 +0200, martin f krafft wrote: > Has anyone worked on this since? No, haven't had the cycles... and SSD helped a bit to delay urgency. -- Stewart Smith ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Mail in git
also sprach Stewart Smith [2010.02.17.1107 +0100]: > On Wed, 17 Feb 2010 11:21:51 +1100, Stewart Smith > wrote: > > Using fast-import is interesting. Does it update the working tree? The > > big thing I wanted to avoid was creating a working tree (another million > > inodes being created is not ever what I need) > > > > Also interesting is the mention of creating packs on the fly... this > > could save the time in first writing the object and then packing it (as > > my script does). > > > > I'm going to play with this > > and I did. Has anyone worked on this since? -- martin | http://madduck.net/ | http://two.sentenc.es/ "one should never allow one's mind and one's foot to wander at the same time." -- edward perkins (yes, the librarian) spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
