[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, May 24, 2011 at 6:16 PM, Dmitry Kurochkin wrote: > When a user clicks the button, the cursor is somewhere inside the old > label. ?If we save the point as a marker, after step 3 it would end up > at the position where the old label was. ?If the new label is inserted > before the old one, that means after the new label. ?So the cursor jumps > from inside the button to the position after the button. ?Since the new > button is placed at the same position where the old one was, restoring > the point to the same offset it was at the beginning works as we need. Saving point this way is a bit dangerous, though. For example, if you're near the end of the buffer and shorten the label, attempting to restore the point could result in an error (or, a more benign example: the cursor could wind up outside the label so pressing RET repeatedly won't toggle it). Unfortunately, I don't know of a clean solution to this, but I think I would rather the cursor move, but stay within the label (probably moving to the beginning), than have problems like the above.
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Wed, 25 May 2011 03:27:51 +0400, Dmitry Kurochkin wrote: > (button-end cite-button) would move the point outside the button - to > the next character after it. OK. Your fix addresses my off-by-one bug. I've just pushed the whole series, with your final amended fix, (and some updates I made to its commit message). Thanks again, Dmitry. This will be a nice refinement in the interface. -Carl -- carl.d.worth at intel.com -- 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/20110524/eda6a6b1/attachment.pgp>
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, 24 May 2011 18:43:41 -0400, Austin Clements wrote: > Saving point this way is a bit dangerous, though. For example, if > you're near the end of the buffer and shorten the label, attempting to > restore the point could result in an error (or, a more benign example: > the cursor could wind up outside the label so pressing RET repeatedly > won't toggle it). > > Unfortunately, I don't know of a clean solution to this, but I think I > would rather the cursor move, but stay within the label (probably > moving to the beginning), than have problems like the above. Here's my fix. Let me know what you think. -Carl -- next part -- A non-text attachment was scrubbed... Name: 0001-Carefully-preverse-point-when-changing-button-text-i.patch Type: text/x-diff Size: 1707 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110524/7a1c98d7/attachment.patch> -- 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/20110524/7a1c98d7/attachment.pgp>
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, 24 May 2011 18:43:41 -0400, Austin Clements wrote: > Saving point this way is a bit dangerous, though. For example, if > you're near the end of the buffer and shorten the label, attempting to > restore the point could result in an error (or, a more benign example: > the cursor could wind up outside the label so pressing RET repeatedly > won't toggle it). Without the patch to change save-excursion to an integer, point is already moving outside the button, (so that repeatedly pressing RET doesn't toggle). I'm exploring a proper fix now to get reliable behavior. -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/20110524/0b19e500/attachment.pgp>
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Wed, 25 May 2011 02:16:06 +0400, Dmitry Kurochkin wrote: > Since the newbutton is placed at the same position where the old one was, > restoring > the point to the same offset it was at the beginning works as we need. Thanks for explaining this. I'll experiment a bit and push the series, perhaps with a change to the last commit message. -Carl -- carl.d.worth at intel.com -- 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/20110524/c186ae4a/attachment.pgp>
problems with multipart/mixed
On Tue, 24 May 2011 14:01:35 -0700, Dirk Hohndel wrote: > Pulled the latest. Fixes the reply issue - but frequently gets emacs to > dump core. Looking at the backtrace reminds me why I hate emace some > times :-) - it appears to happen in a memmove - but everything else in > the backtrave is useless Yikes! That's definitely bad news. Let's coordinate off-list to see if I can replicate that problem with the message you've got. > Not an improvement. Indeed not. The only previous cases we've hit where notmuch was reliably crashing emacs was a buffer-overflow in emacs triggered by some giant email messages (spam usually). In that case, the emacs authors were really quick about finding and fixing the bug. Will hope for something similar here once we can replicate the problem. -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/20110524/3b6b9a1a/attachment.pgp>
[PATCH] emacs: Make the queries used in the all-tags section
On Tue, 24 May 2011 23:01:16 +0200, Daniel Schoepe wrote: > Another option would be to also allow various symbols like 'unread (meaning > "tag:TAG and tag:unread") for "popular" queries in addition to a > function. Or, for a case like this the variable could accept a simple string to append: "and tag:unread" That would be easy to use and still quite flexible. -Carl -- carl.d.worth at intel.com -- 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/20110524/658c35a8/attachment-0001.pgp>
[PATCH] emacs: Allow user to choose "From" address when composing a new message.
In order to select a From address, the user simply presses M instead of
m to begin composing a message. By default the list of names/addresses
to be used during completion will be automatically generated by the
settings in the notmuch configuration file. The user can customize
the notmuch-identities variable to provide an alternate list.
---
emacs/notmuch-hello.el |3 ++-
emacs/notmuch-mua.el | 40 ++--
emacs/notmuch.el |3 ++-
3 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index e58dd24..5f3bcc8 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -298,7 +298,8 @@ should be. Returns a cons cell `(tags-per-line width)'."
(define-key map "=" 'notmuch-hello-update)
(define-key map "G" 'notmuch-hello-poll-and-update)
(define-key map (kbd "") 'widget-backward)
-(define-key map "m" 'notmuch-mua-mail)
+(define-key map "m" 'notmuch-mua-new-mail)
+(define-key map "M" 'notmuch-mua-new-mail-prompt-for-sender)
(define-key map "s" 'notmuch-hello-goto-search)
map)
"Keymap for \"notmuch hello\" buffers.")
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index dc7b386..76bcba4 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -118,8 +118,7 @@ list."
(defun notmuch-mua-mail ( to subject other-headers continue
switch-function yank-action send-actions)
- "Invoke the notmuch mail composition window."
- (interactive)
+ "Invoke the notmuch mail composition window with optional headers."
(when notmuch-mua-user-agent-function
(let ((user-agent (funcall notmuch-mua-user-agent-function)))
@@ -138,6 +137,43 @@ list."
(message-goto-to))
+(defcustom notmuch-identities nil
+ "Identities that can be used as the From: address when composing a new
message.
+
+If this variable is left unset, then a list will be constructed from the
+name and addresses configured in the notmuch configuration file."
+ :group 'notmuch
+ :type '(repeat string))
+
+(defun notmuch-mua-sender-collection ()
+ (if notmuch-identities
+ notmuch-identities
+(mapcar (lambda (address)
+ (concat (notmuch-user-name) " <" address ">"))
+ (cons (notmuch-user-primary-email) (notmuch-user-other-email)
+
+(defun notmuch-mua-new-mail-from ( sender)
+ (if sender
+ (notmuch-mua-mail nil nil (list (cons 'from sender)))
+(notmuch-mua-mail)))
+
+(defvar notmuch-mua-sender-history nil)
+
+(defun notmuch-mua-new-mail ( prompt-for-sender)
+ "Begin composing a new email with notmuch."
+ (interactive "P")
+ (if prompt-for-sender
+ (let* ((collection (notmuch-mua-sender-collection))
+(sender (ido-completing-read "Send mail From: " collection
+ nil 'confirm nil
'notmuch-mua-sender-history (car collection
+ (notmuch-mua-new-mail-from sender))
+(notmuch-mua-mail)))
+
+(defun notmuch-mua-new-mail-prompt-for-sender ()
+ "Begin composing a new email with notmuch, and prompt for the From: address."
+ (interactive)
+ (notmuch-mua-new-mail t))
+
(defun notmuch-mua-send-and-exit ( arg)
(interactive "P")
(message-send-and-exit arg))
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 64f72a0..0c1c8d0 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -204,7 +204,8 @@ For a mouse binding, return nil."
(define-key map "p" 'notmuch-search-previous-thread)
(define-key map "n" 'notmuch-search-next-thread)
(define-key map "r" 'notmuch-search-reply-to-thread)
-(define-key map "m" 'notmuch-mua-mail)
+(define-key map "m" 'notmuch-mua-new-mail)
+(define-key map "M" 'notmuch-mua-new-mail-prompt-for-sender)
(define-key map "s" 'notmuch-search)
(define-key map "o" 'notmuch-search-toggle-order)
(define-key map "c" 'notmuch-search-stash-map)
--
1.7.5.1
-- 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/20110524/d21218ee/attachment.pgp>
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Wed, 25 May 2011 00:43:20 +0400, Dmitry Kurochkin wrote: > Now, looking at Emacs source code, save_excursion_save() uses > point_marker() to save the point. As you said above, markers are > updated when the corresponding text is updated. That explains why the > cursor jumps when using `save-excursion'. > > On the other hand, `point' returns position as an integer. Which is > just what we need. Ah. So that explains why your patch is actually making a difference. But I've usually had "jumping cursor" problems when using an integer, (and switching to a marker fixes it). For example, imagine the following operation: User positions cursor on some word Our code saves point as an integer Some operation inserts new text before point Our code restores the cursor to the saved integer This sequence restores point to the same integer position in the buffer, but logically makes the cursor appear to "jump" to the user, (since the cursor will no longer be on the word it was on before but will now be earlier in the buffer). The fix for the above is to switch from an integer to a marker. So I'm curious to know the case you're hitting where you getbetter behavior by switching from a marker to an integer. Can you describe it in a bit more detail? -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/20110524/4390ff20/attachment.pgp>
Multiple sender identities (composing)
On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith wrote: > Thought I'd share this bit of my .emacs snippet that may be useful to go > on the emacs tips page. Hi Stewart, Thanks for sharing this functionality. I've wanted something like this, but I'm extremely reluctant to put fancy things like this in my .emacs file. The problem I have is that I don't want to restrict nice features to the people who manage to configure their emacs "just so". I'd much rather have this functionality inside notmuch itself, and without requiring any configuration (by default). I'll reply with a patch I just wrote attempting to implement that. By default, it generates the list of addresses by looking in your notmuch configuration file. It also provides a customizable list of addresses that the user can provide (notmuch-identities). The patch doesn't make all new composition buffers prompt for the address. Instead, the original 'm' key does no prompting as its always done. And a new 'M' key prompts. I did use ido-completing-read rather than completing-read. I did that because otherwise it's a pain to complete addresses. For example, imagine I have the following: Carl Worth Carl Worth Carl Worth To select my intel address hit "C [TAB]", "a [TAB]", "i [TAB]" which is random enough that I can't memorize it but have to instead slowly watch. With ido I can just type "intel [ENTER]" which is nice and quick (and I can get trained to type less if sufficient. One thing I don't like about ido is that the input area is extremely cluttered from the beginning with all the possible inputs. I wish it instead waiting for some explicit keypress (such as pressing ENTER while the input is still ambiguous) before displaying possible matches. I don't know what trouble you had with ido on Ubuntu, but hopefully you can work that out. I did implement support for completion history. I did not implement support for doing completion when forwarding. A nice addition would be an easy keybinding for doing the same completion to change the From header while composing a message. Anyway, I'm throwing this out for feedback, testing, and suggestions. Please let me know if you try and out and if you think we should push this code. -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/20110524/86a6eb7a/attachment.pgp>
problems with multipart/mixed
Pulled the latest. Fixes the reply issue - but frequently gets emacs to dump core. Looking at the backtrace reminds me why I hate emace some times :-) - it appears to happen in a memmove - but everything else in the backtrave is useless Not an improvement. /D On Tue, 24 May 2011 12:50:20 -0700, Carl Worth wrote: Non-text part: multipart/signed > On Mon, 23 May 2011 19:46:41 -0700, Dirk Hohndel > wrote: > > Hehe, as the reply below shows... there's still something screwy even > > with the latest git version... in multipart messages things just go > > wrong. Whether I reply (this below should have included your text/plain > > part as quote) > > You caught me again, on two points: > > 1. Our multipart testing wasn't testing "notmuch reply" > > 2. I wasn't actually running the latest code in my own use > > I've addressed both of those problems, which made it easy to find and > fix the segfault that was causing the missing data in the reply > buffer. I will hopefully be in a good habit now of creating a Debian > package and installing and using it locally as part of my testing of > major changes. > > Meanwhile, I did just push Jameson's recent new-show-part branch (along > with some updates from me). This should complete the big upheaval of > changes to how multipart messages are handled. From here, Jameson will > rebase his crypto branch so we can verify signatures and decrypt > messages within emacs. > > > or whether I try to see the html part of a text/plain + > > text/html multipart message... > > This is an area where there have been some recent feature changes---and > again, sadly, there's still some missing testing of the emacs features. > > The change I am seeing is that previously whenever a message had both a > text/plain part and a corresponding text/html part (withing > multipart/alternative), emacs would render both of them. > > Instead, I'm now seeing the text/plain part followed by: > > [ text/html (not shown) ] > > As far as that goes, this hiding of the HTML by default is exactly what > I want. (If people don't want this, there's a > notmuch-show-all-multipart/alternative-parts variable that can be > tweaked. Or just do "M-x customize-group notmuch" and find the setting > there.) > > Meanwhile, I can imagine that some people might actually need to view > the HTML part that's initially not shown. I just tried hitting 'V' on > the "(not shown)" button and I got several image-viewer windows, each > showing one of the contained images. That's not ideal---it would be > better to get some web browser to display the entire message formatted > correctly. > > Maybe that's just something I need to customize on my end, (though, if > so, I think notmuch could do a better job arranging that for the user). > > So contributions would be welcome in this area, (both functional > improvements to the emacs interface as well as additional testing of > those emacs features). > > -Carl > > -- > carl.d.worth at intel.com Non-text part: application/pgp-signature -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] emacs: Make the queries used in the all-tags section
On Fri, 20 May 2011 01:18:35 +0200, Daniel Schoepe wrote: > From the commit message: > > emacs: Make queries used in the all-tags section configurable > > This patch adds a customization variable that controls what queries > are used to construct the all-tags section in notmuch-hello. It allows > the user to specify a function to construct the query given a tag. It > also allows hiding tags by returning nil. This seems like a useful feature, but perhaps it's a little too general? I'm imagining a user wanting to use this functionality but not knowing anything about writing an emacs-lisp function. For such a user, this variable won't provide much of a feature. I think that might be an argument for dropping this variable from the notmuch customization group. That customization page is starting to get crowded, and if there are things there that can't be easily manipulated with the available controls, I think they're mostly just clutter. Perhaps this could be addressed by allowing this variable to be an alist instead of (or in addition to) a function. What do you think? -Carl -- carl.d.worth at intel.com -- 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/20110524/63f6e37e/attachment.pgp>
[BUG] [PATCH] Fix appending of Received headers
On Tue, 17 May 2011 12:10:32 +1000, Stewart Smith wrote: > We're not properly concatenating the Received headers if we parse them > while requesting a header that isn't Received. Thanks, Stewart. The fix looks clearly correct. > this fixes notmuch-reply address detection in a bunch of situations. But can we go one step beyond "a bunch of situations"? Could you send a message that demonstrates this bug? Or better yet, extend the test/from-guessing test case to expose the bug? I'd prefer to fix the test suite here so that we don't later regress on this behavior. Thanks, -Carl -- carl.d.worth at intel.com -- 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/20110524/e2f9068c/attachment.pgp>
[PATCH] emacs: Add notmuch-before/after-tag-hook
On Mon, 16 May 2011 22:48:24 +0200, Daniel Schoepe wrote: Non-text part: multipart/mixed Non-text part: multipart/signed Non-text part: multipart/mixed > From the commit message: > > emacs: add notmuch-before- and notmuch-after-tag-hook Thanks, Daniel. This looks like a nice piece of functionality in a nice, clean patch. This is pushed out to the master branch of notmuch now. -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/20110524/dcd49c1d/attachment.pgp>
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Mon, 23 May 2011 19:29:46 +0400, Dmitry Kurochkin wrote: > Before the change, save-excursion was used to save the point. > But the restored position is affected by buffer modifications, > which results in jumping cursor. The patch saves and restores > point explicitly by using a variable instead of save-excursion. Dmitry, Thanks so much for the improvement to the button text! This will be a nice thing to add. But this patch confuses me. I can understand how a buffer-position variable can cause the cursor to jump. That's usually the kind of thing that can be fixed by switching from an integer position to a marker instead, (since markers are updated when the corresponding text is updated). But in this case, I don't see how: (let ((old-point (point))) ... code here ... (goto-char old-point)) is distinct from: (save-excursion ... code here ... ) except that save-excursion actually does the right thing in the case of abnormal exit (throw or error). Can you help me understand what I'm missing here? -Carl -- carl.d.worth at intel.com -- 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/20110524/002c6264/attachment.pgp>
Deprecated notmuch "part" and "search-tags" commands
I just merged some changes by Jameson to move from the "notmuch part --part=X" command to instead use "notmuch show --part=X". This is fundamentally more powerful since the various --format=text|json|raw options can now be used while limiting which message parts are show with --part. [*] It's also a nice code reduction. But I didn't want to break existing interfaces that might be calling "notmuch part", (for example, somebody updating the notmuch command-line but still using the older emacs interface). So I just added simple support to the notmuch main program to support aliases. With this, the "notmuch part" command is still supported by being treated as an alias for "notmuch show --format=raw". With the alias support in place, I also switched "notmuch search-tags" to now be an alias for "notmuch search --output=tags *". That was a further code reduction. Currently, the aliases are not documented at all---the idea being that they exist only to support interfaces still using deprecated commands. I just wanted everyone to be aware of these recent changes. I'd be glad to take any feedback here. Let me know. Me, I'm quite happy to see the list of commands from "notmuch help" get shorter by two commands, (without any reduction in available functionality). -Carl [*] Though the JSON formatter still gives up on non-text parts. We might want to extend it to encapsulate non-text parts within the json output somehow. -- carl.d.worth at intel.com -- 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/20110524/4b2b9b72/attachment.pgp>
problems with multipart/mixed
On Mon, 23 May 2011 19:46:41 -0700, Dirk Hohndel wrote: > Hehe, as the reply below shows... there's still something screwy even > with the latest git version... in multipart messages things just go > wrong. Whether I reply (this below should have included your text/plain > part as quote) You caught me again, on two points: 1. Our multipart testing wasn't testing "notmuch reply" 2. I wasn't actually running the latest code in my own use I've addressed both of those problems, which made it easy to find and fix the segfault that was causing the missing data in the reply buffer. I will hopefully be in a good habit now of creating a Debian package and installing and using it locally as part of my testing of major changes. Meanwhile, I did just push Jameson's recent new-show-part branch (along with some updates from me). This should complete the big upheaval of changes to how multipart messages are handled. From here, Jameson will rebase his crypto branch so we can verify signatures and decrypt messages within emacs. > or whether I try to see the html part of a text/plain + > text/html multipart message... This is an area where there have been some recent feature changes---and again, sadly, there's still some missing testing of the emacs features. The change I am seeing is that previously whenever a message had both a text/plain part and a corresponding text/html part (withing multipart/alternative), emacs would render both of them. Instead, I'm now seeing the text/plain part followed by: [ text/html (not shown) ] As far as that goes, this hiding of the HTML by default is exactly what I want. (If people don't want this, there's a notmuch-show-all-multipart/alternative-parts variable that can be tweaked. Or just do "M-x customize-group notmuch" and find the setting there.) Meanwhile, I can imagine that some people might actually need to view the HTML part that's initially not shown. I just tried hitting 'V' on the "(not shown)" button and I got several image-viewer windows, each showing one of the contained images. That's not ideal---it would be better to get some web browser to display the entire message formatted correctly. Maybe that's just something I need to customize on my end, (though, if so, I think notmuch could do a better job arranging that for the user). So contributions would be welcome in this area, (both functional improvements to the emacs interface as well as additional testing of those emacs features). -Carl -- carl.d.worth at intel.com -- 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/20110524/8ccaad99/attachment.pgp>
[BUG] multipart ID of show != part
Hi Carl, thank you very much for your effort. Works well now with your patch. regards Matthias
a python terminal gui?
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: <http://notmuchmail.org/pipermail/notmuch/attachments/20110524/0305ae08/attachment.pgp>
Re: a python terminal gui?
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: [BUG] multipart ID of show != part
Hi Carl, thank you very much for your effort. Works well now with your patch. regards Matthias ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
On Mon, 23 May 2011 19:46:41 -0700, Dirk Hohndel hohn...@infradead.org wrote: Hehe, as the reply below shows... there's still something screwy even with the latest git version... in multipart messages things just go wrong. Whether I reply (this below should have included your text/plain part as quote) You caught me again, on two points: 1. Our multipart testing wasn't testing notmuch reply 2. I wasn't actually running the latest code in my own use I've addressed both of those problems, which made it easy to find and fix the segfault that was causing the missing data in the reply buffer. I will hopefully be in a good habit now of creating a Debian package and installing and using it locally as part of my testing of major changes. Meanwhile, I did just push Jameson's recent new-show-part branch (along with some updates from me). This should complete the big upheaval of changes to how multipart messages are handled. From here, Jameson will rebase his crypto branch so we can verify signatures and decrypt messages within emacs. or whether I try to see the html part of a text/plain + text/html multipart message... This is an area where there have been some recent feature changes---and again, sadly, there's still some missing testing of the emacs features. The change I am seeing is that previously whenever a message had both a text/plain part and a corresponding text/html part (withing multipart/alternative), emacs would render both of them. Instead, I'm now seeing the text/plain part followed by: [ text/html (not shown) ] As far as that goes, this hiding of the HTML by default is exactly what I want. (If people don't want this, there's a notmuch-show-all-multipart/alternative-parts variable that can be tweaked. Or just do M-x customize-group notmuch and find the setting there.) Meanwhile, I can imagine that some people might actually need to view the HTML part that's initially not shown. I just tried hitting 'V' on the (not shown) button and I got several image-viewer windows, each showing one of the contained images. That's not ideal---it would be better to get some web browser to display the entire message formatted correctly. Maybe that's just something I need to customize on my end, (though, if so, I think notmuch could do a better job arranging that for the user). So contributions would be welcome in this area, (both functional improvements to the emacs interface as well as additional testing of those emacs features). -Carl -- carl.d.wo...@intel.com pgpZi10VFpcf4.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Deprecated notmuch part and search-tags commands
I just merged some changes by Jameson to move from the notmuch part --part=X command to instead use notmuch show --part=X. This is fundamentally more powerful since the various --format=text|json|raw options can now be used while limiting which message parts are show with --part. [*] It's also a nice code reduction. But I didn't want to break existing interfaces that might be calling notmuch part, (for example, somebody updating the notmuch command-line but still using the older emacs interface). So I just added simple support to the notmuch main program to support aliases. With this, the notmuch part command is still supported by being treated as an alias for notmuch show --format=raw. With the alias support in place, I also switched notmuch search-tags to now be an alias for notmuch search --output=tags *. That was a further code reduction. Currently, the aliases are not documented at all---the idea being that they exist only to support interfaces still using deprecated commands. I just wanted everyone to be aware of these recent changes. I'd be glad to take any feedback here. Let me know. Me, I'm quite happy to see the list of commands from notmuch help get shorter by two commands, (without any reduction in available functionality). -Carl [*] Though the JSON formatter still gives up on non-text parts. We might want to extend it to encapsulate non-text parts within the json output somehow. -- carl.d.wo...@intel.com pgpnt0nwXiseg.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: a python terminal gui?
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
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Mon, 23 May 2011 19:29:46 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Before the change, save-excursion was used to save the point. But the restored position is affected by buffer modifications, which results in jumping cursor. The patch saves and restores point explicitly by using a variable instead of save-excursion. Dmitry, Thanks so much for the improvement to the button text! This will be a nice thing to add. But this patch confuses me. I can understand how a buffer-position variable can cause the cursor to jump. That's usually the kind of thing that can be fixed by switching from an integer position to a marker instead, (since markers are updated when the corresponding text is updated). But in this case, I don't see how: (let ((old-point (point))) ... code here ... (goto-char old-point)) is distinct from: (save-excursion ... code here ... ) except that save-excursion actually does the right thing in the case of abnormal exit (throw or error). Can you help me understand what I'm missing here? -Carl -- carl.d.wo...@intel.com pgpjWjqFStd2F.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add notmuch-before/after-tag-hook
On Mon, 16 May 2011 22:48:24 +0200, Daniel Schoepe daniel.scho...@googlemail.com wrote: Non-text part: multipart/mixed Non-text part: multipart/signed Non-text part: multipart/mixed From the commit message: emacs: add notmuch-before- and notmuch-after-tag-hook Thanks, Daniel. This looks like a nice piece of functionality in a nice, clean patch. This is pushed out to the master branch of notmuch now. -Carl pgpnhP9H8CuL7.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] [PATCH] Fix appending of Received headers
On Tue, 17 May 2011 12:10:32 +1000, Stewart Smith stew...@flamingspork.com wrote: We're not properly concatenating the Received headers if we parse them while requesting a header that isn't Received. Thanks, Stewart. The fix looks clearly correct. this fixes notmuch-reply address detection in a bunch of situations. But can we go one step beyond a bunch of situations? Could you send a message that demonstrates this bug? Or better yet, extend the test/from-guessing test case to expose the bug? I'd prefer to fix the test suite here so that we don't later regress on this behavior. Thanks, -Carl -- carl.d.wo...@intel.com pgp3Uva8bMkPX.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Make the queries used in the all-tags section
On Fri, 20 May 2011 01:18:35 +0200, Daniel Schoepe daniel.scho...@googlemail.com wrote: From the commit message: emacs: Make queries used in the all-tags section configurable This patch adds a customization variable that controls what queries are used to construct the all-tags section in notmuch-hello. It allows the user to specify a function to construct the query given a tag. It also allows hiding tags by returning nil. This seems like a useful feature, but perhaps it's a little too general? I'm imagining a user wanting to use this functionality but not knowing anything about writing an emacs-lisp function. For such a user, this variable won't provide much of a feature. I think that might be an argument for dropping this variable from the notmuch customization group. That customization page is starting to get crowded, and if there are things there that can't be easily manipulated with the available controls, I think they're mostly just clutter. Perhaps this could be addressed by allowing this variable to be an alist instead of (or in addition to) a function. What do you think? -Carl -- carl.d.wo...@intel.com pgpNBVzApkaBQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
Hi Carl. On Tue, 24 May 2011 13:20:56 -0700, Carl Worth cwo...@cworth.org wrote: On Mon, 23 May 2011 19:29:46 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Before the change, save-excursion was used to save the point. But the restored position is affected by buffer modifications, which results in jumping cursor. The patch saves and restores point explicitly by using a variable instead of save-excursion. Dmitry, Thanks so much for the improvement to the button text! This will be a nice thing to add. But this patch confuses me. I can understand how a buffer-position variable can cause the cursor to jump. That's usually the kind of thing that can be fixed by switching from an integer position to a marker instead, (since markers are updated when the corresponding text is updated). So we need to switch from marker to an integer position, right? But in this case, I don't see how: (let ((old-point (point))) ... code here ... (goto-char old-point)) is distinct from: (save-excursion ... code here ... ) except that save-excursion actually does the right thing in the case of abnormal exit (throw or error). Can you help me understand what I'm missing here? Unfortunately, I am not an Emacs lisp expert. I just noticed that the cursor jumps and did the first thing that came to mind. And it worked. Now, looking at Emacs source code, save_excursion_save() uses point_marker() to save the point. As you said above, markers are updated when the corresponding text is updated. That explains why the cursor jumps when using `save-excursion'. On the other hand, `point' returns position as an integer. Which is just what we need. Regards, Dmitry -Carl -- carl.d.wo...@intel.com Non-text part: application/pgp-signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Make the queries used in the all-tags section
On Tue, 24 May 2011 13:39:44 -0700, Carl Worth cwo...@cworth.org wrote: This seems like a useful feature, but perhaps it's a little too general? I'm imagining a user wanting to use this functionality but not knowing anything about writing an emacs-lisp function. For such a user, this variable won't provide much of a feature. I think that might be an argument for dropping this variable from the notmuch customization group. That customization page is starting to get crowded, and if there are things there that can't be easily manipulated with the available controls, I think they're mostly just clutter. Perhaps this could be addressed by allowing this variable to be an alist instead of (or in addition to) a function. What do you think? Yes, allowing both, an alist or a function for this variable seems better than forcing the user to write a function, but how should the alist control the behaviour? I don't think people would like having to specify a query for each of their tags, and since, by assumption, they cannot write a function to automate this, they probably wouldn't be much better off. (Except of course, if they only wanted to change it for a few individual tags). Another option would be to also allow various symbols like 'unread (meaning tag:TAG and tag:unread) for popular queries in addition to a function. Cheers, Daniel pgpOJ7O9XYw1L.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
Pulled the latest. Fixes the reply issue - but frequently gets emacs to dump core. Looking at the backtrace reminds me why I hate emace some times :-) - it appears to happen in a memmove - but everything else in the backtrave is useless Not an improvement. /D On Tue, 24 May 2011 12:50:20 -0700, Carl Worth cwo...@cworth.org wrote: Non-text part: multipart/signed On Mon, 23 May 2011 19:46:41 -0700, Dirk Hohndel hohn...@infradead.org wrote: Hehe, as the reply below shows... there's still something screwy even with the latest git version... in multipart messages things just go wrong. Whether I reply (this below should have included your text/plain part as quote) You caught me again, on two points: 1. Our multipart testing wasn't testing notmuch reply 2. I wasn't actually running the latest code in my own use I've addressed both of those problems, which made it easy to find and fix the segfault that was causing the missing data in the reply buffer. I will hopefully be in a good habit now of creating a Debian package and installing and using it locally as part of my testing of major changes. Meanwhile, I did just push Jameson's recent new-show-part branch (along with some updates from me). This should complete the big upheaval of changes to how multipart messages are handled. From here, Jameson will rebase his crypto branch so we can verify signatures and decrypt messages within emacs. or whether I try to see the html part of a text/plain + text/html multipart message... This is an area where there have been some recent feature changes---and again, sadly, there's still some missing testing of the emacs features. The change I am seeing is that previously whenever a message had both a text/plain part and a corresponding text/html part (withing multipart/alternative), emacs would render both of them. Instead, I'm now seeing the text/plain part followed by: [ text/html (not shown) ] As far as that goes, this hiding of the HTML by default is exactly what I want. (If people don't want this, there's a notmuch-show-all-multipart/alternative-parts variable that can be tweaked. Or just do M-x customize-group notmuch and find the setting there.) Meanwhile, I can imagine that some people might actually need to view the HTML part that's initially not shown. I just tried hitting 'V' on the (not shown) button and I got several image-viewer windows, each showing one of the contained images. That's not ideal---it would be better to get some web browser to display the entire message formatted correctly. Maybe that's just something I need to customize on my end, (though, if so, I think notmuch could do a better job arranging that for the user). So contributions would be welcome in this area, (both functional improvements to the emacs interface as well as additional testing of those emacs features). -Carl -- carl.d.wo...@intel.com Non-text part: application/pgp-signature -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Multiple sender identities (composing)
On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith stew...@flamingspork.com wrote: Thought I'd share this bit of my .emacs snippet that may be useful to go on the emacs tips page. Hi Stewart, Thanks for sharing this functionality. I've wanted something like this, but I'm extremely reluctant to put fancy things like this in my .emacs file. The problem I have is that I don't want to restrict nice features to the people who manage to configure their emacs just so. I'd much rather have this functionality inside notmuch itself, and without requiring any configuration (by default). I'll reply with a patch I just wrote attempting to implement that. By default, it generates the list of addresses by looking in your notmuch configuration file. It also provides a customizable list of addresses that the user can provide (notmuch-identities). The patch doesn't make all new composition buffers prompt for the address. Instead, the original 'm' key does no prompting as its always done. And a new 'M' key prompts. I did use ido-completing-read rather than completing-read. I did that because otherwise it's a pain to complete addresses. For example, imagine I have the following: Carl Worth cwo...@cworth.org Carl Worth carl.d.wo...@intel.com Carl Worth carl.d.wo...@gmail.com To select my intel address hit C [TAB], a [TAB], i [TAB] which is random enough that I can't memorize it but have to instead slowly watch. With ido I can just type intel [ENTER] which is nice and quick (and I can get trained to type less if sufficient. One thing I don't like about ido is that the input area is extremely cluttered from the beginning with all the possible inputs. I wish it instead waiting for some explicit keypress (such as pressing ENTER while the input is still ambiguous) before displaying possible matches. I don't know what trouble you had with ido on Ubuntu, but hopefully you can work that out. I did implement support for completion history. I did not implement support for doing completion when forwarding. A nice addition would be an easy keybinding for doing the same completion to change the From header while composing a message. Anyway, I'm throwing this out for feedback, testing, and suggestions. Please let me know if you try and out and if you think we should push this code. -Carl pgpzPE712iFHg.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Allow user to choose From address when composing a new message.
In order to select a From address, the user simply presses M instead of m to begin composing a message. By default the list of names/addresses to be used during completion will be automatically generated by the settings in the notmuch configuration file. The user can customize the notmuch-identities variable to provide an alternate list. --- emacs/notmuch-hello.el |3 ++- emacs/notmuch-mua.el | 40 ++-- emacs/notmuch.el |3 ++- 3 files changed, 42 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index e58dd24..5f3bcc8 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -298,7 +298,8 @@ should be. Returns a cons cell `(tags-per-line width)'. (define-key map = 'notmuch-hello-update) (define-key map G 'notmuch-hello-poll-and-update) (define-key map (kbd C-tab) 'widget-backward) -(define-key map m 'notmuch-mua-mail) +(define-key map m 'notmuch-mua-new-mail) +(define-key map M 'notmuch-mua-new-mail-prompt-for-sender) (define-key map s 'notmuch-hello-goto-search) map) Keymap for \notmuch hello\ buffers.) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index dc7b386..76bcba4 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -118,8 +118,7 @@ list. (defun notmuch-mua-mail (optional to subject other-headers continue switch-function yank-action send-actions) - Invoke the notmuch mail composition window. - (interactive) + Invoke the notmuch mail composition window with optional headers. (when notmuch-mua-user-agent-function (let ((user-agent (funcall notmuch-mua-user-agent-function))) @@ -138,6 +137,43 @@ list. (message-goto-to)) +(defcustom notmuch-identities nil + Identities that can be used as the From: address when composing a new message. + +If this variable is left unset, then a list will be constructed from the +name and addresses configured in the notmuch configuration file. + :group 'notmuch + :type '(repeat string)) + +(defun notmuch-mua-sender-collection () + (if notmuch-identities + notmuch-identities +(mapcar (lambda (address) + (concat (notmuch-user-name) address )) + (cons (notmuch-user-primary-email) (notmuch-user-other-email) + +(defun notmuch-mua-new-mail-from (optional sender) + (if sender + (notmuch-mua-mail nil nil (list (cons 'from sender))) +(notmuch-mua-mail))) + +(defvar notmuch-mua-sender-history nil) + +(defun notmuch-mua-new-mail (optional prompt-for-sender) + Begin composing a new email with notmuch. + (interactive P) + (if prompt-for-sender + (let* ((collection (notmuch-mua-sender-collection)) +(sender (ido-completing-read Send mail From: collection + nil 'confirm nil 'notmuch-mua-sender-history (car collection + (notmuch-mua-new-mail-from sender)) +(notmuch-mua-mail))) + +(defun notmuch-mua-new-mail-prompt-for-sender () + Begin composing a new email with notmuch, and prompt for the From: address. + (interactive) + (notmuch-mua-new-mail t)) + (defun notmuch-mua-send-and-exit (optional arg) (interactive P) (message-send-and-exit arg)) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 64f72a0..0c1c8d0 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -204,7 +204,8 @@ For a mouse binding, return nil. (define-key map p 'notmuch-search-previous-thread) (define-key map n 'notmuch-search-next-thread) (define-key map r 'notmuch-search-reply-to-thread) -(define-key map m 'notmuch-mua-mail) +(define-key map m 'notmuch-mua-new-mail) +(define-key map M 'notmuch-mua-new-mail-prompt-for-sender) (define-key map s 'notmuch-search) (define-key map o 'notmuch-search-toggle-order) (define-key map c 'notmuch-search-stash-map) -- 1.7.5.1 pgpoMLQmYgyHI.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
On Tue, 24 May 2011 14:01:35 -0700, Dirk Hohndel hohn...@infradead.org wrote: Pulled the latest. Fixes the reply issue - but frequently gets emacs to dump core. Looking at the backtrace reminds me why I hate emace some times :-) - it appears to happen in a memmove - but everything else in the backtrave is useless Yikes! That's definitely bad news. Let's coordinate off-list to see if I can replicate that problem with the message you've got. Not an improvement. Indeed not. The only previous cases we've hit where notmuch was reliably crashing emacs was a buffer-overflow in emacs triggered by some giant email messages (spam usually). In that case, the emacs authors were really quick about finding and fixing the bug. Will hope for something similar here once we can replicate the problem. -Carl pgp716bvDBD9T.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, 24 May 2011 15:01:04 -0700, Carl Worth cwo...@cworth.org wrote: On Wed, 25 May 2011 00:43:20 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Now, looking at Emacs source code, save_excursion_save() uses point_marker() to save the point. As you said above, markers are updated when the corresponding text is updated. That explains why the cursor jumps when using `save-excursion'. On the other hand, `point' returns position as an integer. Which is just what we need. Ah. So that explains why your patch is actually making a difference. But I've usually had jumping cursor problems when using an integer, (and switching to a marker fixes it). For example, imagine the following operation: User positions cursor on some word Our code saves point as an integer Some operation inserts new text before point Our code restores the cursor to the saved integer This sequence restores point to the same integer position in the buffer, but logically makes the cursor appear to jump to the user, (since the cursor will no longer be on the word it was on before but will now be earlier in the buffer). The fix for the above is to switch from an integer to a marker. Ah, I see now. So I'm curious to know the case you're hitting where you getbetter behavior by switching from a marker to an integer. Can you describe it in a bit more detail? I did not find a better way to update the button label than to: 1. insert the new label 2. move the button overlay from the old label to the new one 3. remove the old label When a user clicks the button, the cursor is somewhere inside the old label. If we save the point as a marker, after step 3 it would end up at the position where the old label was. If the new label is inserted before the old one, that means after the new label. So the cursor jumps from inside the button to the position after the button. Since the new button is placed at the same position where the old one was, restoring the point to the same offset it was at the beginning works as we need. Regards, Dmitry -Carl Non-text part: application/pgp-signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, May 24, 2011 at 6:16 PM, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: When a user clicks the button, the cursor is somewhere inside the old label. If we save the point as a marker, after step 3 it would end up at the position where the old label was. If the new label is inserted before the old one, that means after the new label. So the cursor jumps from inside the button to the position after the button. Since the new button is placed at the same position where the old one was, restoring the point to the same offset it was at the beginning works as we need. Saving point this way is a bit dangerous, though. For example, if you're near the end of the buffer and shorten the label, attempting to restore the point could result in an error (or, a more benign example: the cursor could wind up outside the label so pressing RET repeatedly won't toggle it). Unfortunately, I don't know of a clean solution to this, but I think I would rather the cursor move, but stay within the label (probably moving to the beginning), than have problems like the above. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, 24 May 2011 18:43:41 -0400, Austin Clements amdra...@mit.edu wrote: Saving point this way is a bit dangerous, though. For example, if you're near the end of the buffer and shorten the label, attempting to restore the point could result in an error (or, a more benign example: the cursor could wind up outside the label so pressing RET repeatedly won't toggle it). Without the patch to change save-excursion to an integer, point is already moving outside the button, (so that repeatedly pressing RET doesn't toggle). I'm exploring a proper fix now to get reliable behavior. -Carl pgpiqVNCj7RTl.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, 24 May 2011 18:43:41 -0400, Austin Clements amdra...@mit.edu wrote: On Tue, May 24, 2011 at 6:16 PM, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: When a user clicks the button, the cursor is somewhere inside the old label. If we save the point as a marker, after step 3 it would end up at the position where the old label was. If the new label is inserted before the old one, that means after the new label. So the cursor jumps from inside the button to the position after the button. Since the new button is placed at the same position where the old one was, restoring the point to the same offset it was at the beginning works as we need. Saving point this way is a bit dangerous, though. For example, if you're near the end of the buffer and shorten the label, attempting to restore the point could result in an error (or, a more benign example: the cursor could wind up outside the label so pressing RET repeatedly won't toggle it). Unfortunately, I don't know of a clean solution to this, but I think I would rather the cursor move, but stay within the label (probably moving to the beginning), than have problems like the above. Good point. I will send an amended patch that moved to min(old-pos, new-button-end - 1). This leaves the cursor in place when possible and avoids problems with out-of-bounds position (assuming the label is not empty). Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
Before the change, save-excursion was used to save the point. But the restored position is affected by buffer modifications, which results in jumping cursor. The patch saves and restores point explicitly by using a variable instead of save-excursion. --- emacs/notmuch-wash.el | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 863459e..115c3bb 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -82,13 +82,14 @@ collapse the remaining lines into a button.) (let* ((new-start (button-start cite-button)) (overlay (button-get cite-button 'overlay)) (button-label (notmuch-wash-button-label overlay)) +(old-point (point)) (inhibit-read-only t)) -(save-excursion - (goto-char new-start) - (insert button-label) - (let ((old-end (button-end cite-button))) - (move-overlay cite-button new-start (point)) - (delete-region (point) old-end +(goto-char new-start) +(insert button-label) +(let ((old-end (button-end cite-button))) + (move-overlay cite-button new-start (point)) + (delete-region (point) old-end)) +(goto-char (min old-point (1- (button-end cite-button) (force-window-update) (redisplay t)) -- 1.7.5.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, 24 May 2011 18:43:41 -0400, Austin Clements amdra...@mit.edu wrote: Saving point this way is a bit dangerous, though. For example, if you're near the end of the buffer and shorten the label, attempting to restore the point could result in an error (or, a more benign example: the cursor could wind up outside the label so pressing RET repeatedly won't toggle it). Unfortunately, I don't know of a clean solution to this, but I think I would rather the cursor move, but stay within the label (probably moving to the beginning), than have problems like the above. Here's my fix. Let me know what you think. -Carl From a32e02bf0d2b57d51695f7d4ea6cdda9acb21322 Mon Sep 17 00:00:00 2001 From: Carl Worth cwo...@cworth.org Date: Mon, 23 May 2011 19:29:46 +0400 Subject: [PATCH] Carefully preverse point when changing button text in `notmuch-wash-toggle-invisible-action'. Previously, save-excursion was used to attempt to save the point, but this was unreliable since the region containing the marker saved by save-excursion was deleted. Instead, we save an integer position indicating the offset of point within the old button. Then, we restore point to the same offset within the new button, (but cap the offset to avoid leaving the button entirely). --- emacs/notmuch-wash.el | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 8455eee..3dceb8b 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -82,13 +82,14 @@ collapse the remaining lines into a button.) (let* ((new-start (button-start cite-button)) (overlay (button-get cite-button 'overlay)) (button-label (notmuch-wash-button-label overlay)) + (button-offset (- (point) new-start)) (inhibit-read-only t)) -(save-excursion - (goto-char new-start) - (insert button-label) - (let ((old-end (button-end cite-button))) - (move-overlay cite-button new-start (point)) - (delete-region (point) old-end +(goto-char new-start) +(insert button-label) +(let ((old-end (button-end cite-button))) + (move-overlay cite-button new-start (point)) + (delete-region (point) old-end)) +(goto-char (min (button-end cite-button) (+ new-start button-offset (force-window-update) (redisplay t)) -- 1.7.5.1 pgpZUpuiAlgqJ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Tue, 24 May 2011 16:20:34 -0700, Carl Worth cwo...@cworth.org wrote: On Tue, 24 May 2011 18:43:41 -0400, Austin Clements amdra...@mit.edu wrote: Saving point this way is a bit dangerous, though. For example, if you're near the end of the buffer and shorten the label, attempting to restore the point could result in an error (or, a more benign example: the cursor could wind up outside the label so pressing RET repeatedly won't toggle it). Unfortunately, I don't know of a clean solution to this, but I think I would rather the cursor move, but stay within the label (probably moving to the beginning), than have problems like the above. Here's my fix. Let me know what you think. (button-end cite-button) would move the point outside the button - to the next character after it. Regards, Dmitry -Carl From a32e02bf0d2b57d51695f7d4ea6cdda9acb21322 Mon Sep 17 00:00:00 2001 From: Carl Worth cwo...@cworth.org Date: Mon, 23 May 2011 19:29:46 +0400 Subject: [PATCH] Carefully preverse point when changing button text in `notmuch-wash-toggle-invisible-action'. Previously, save-excursion was used to attempt to save the point, but this was unreliable since the region containing the marker saved by save-excursion was deleted. Instead, we save an integer position indicating the offset of point within the old button. Then, we restore point to the same offset within the new button, (but cap the offset to avoid leaving the button entirely). --- emacs/notmuch-wash.el | 13 +++-- 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 8455eee..3dceb8b 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -82,13 +82,14 @@ collapse the remaining lines into a button.) (let* ((new-start (button-start cite-button)) (overlay (button-get cite-button 'overlay)) (button-label (notmuch-wash-button-label overlay)) + (button-offset (- (point) new-start)) (inhibit-read-only t)) -(save-excursion - (goto-char new-start) - (insert button-label) - (let ((old-end (button-end cite-button))) - (move-overlay cite-button new-start (point)) - (delete-region (point) old-end +(goto-char new-start) +(insert button-label) +(let ((old-end (button-end cite-button))) + (move-overlay cite-button new-start (point)) + (delete-region (point) old-end)) +(goto-char (min (button-end cite-button) (+ new-start button-offset (force-window-update) (redisplay t)) -- 1.7.5.1 Non-text part: application/pgp-signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Save and restore point explicitly in `notmuch-wash-toggle-invisible-action'.
On Wed, 25 May 2011 03:27:51 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: (button-end cite-button) would move the point outside the button - to the next character after it. OK. Your fix addresses my off-by-one bug. I've just pushed the whole series, with your final amended fix, (and some updates I made to its commit message). Thanks again, Dmitry. This will be a nice refinement in the interface. -Carl -- carl.d.wo...@intel.com pgpxM97c1bPaF.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Make the queries used in the all-tags section
Out of curiosity, what use cases do you envision for this? So far I've only heard two, both of which seem like great ideas, but neither of which require such a heavy-handed solution: displaying unread counts for tags rather than total counts, and hiding unused tags. I would argue that we *always* want to display unread counts (maybe in addition to total counts, or maybe not). In fact, I'm generally surprised by how little notmuch treats the unread specially, given how important that tag is to the user. For example, I would similarly find unread counts in the search results far more useful than the count of messages matching the query. Hiding unused tags also seems like a genuinely useful feature, and could be accomplished with a very simple customization UI (perhaps even linked directly from the hello buffer). It seems to me like anything more sophisticated is better suited to a saved search. On Thu, May 19, 2011 at 7:18 PM, Daniel Schoepe daniel.scho...@googlemail.com wrote: From the commit message: emacs: Make queries used in the all-tags section configurable This patch adds a customization variable that controls what queries are used to construct the all-tags section in notmuch-hello. It allows the user to specify a function to construct the query given a tag. It also allows hiding tags by returning nil. Possible uses would be things like displaying the unread count for tags instead of all messages with that tag and/or hiding uninteresting tags like signed or encrypted. -- Daniel ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
