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,
ilable
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110524/eda6a6b1/attachment.pgp>
ove.
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/pipermai
ehavior.
-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>
mail/notmuch/attachments/20110524/c186ae4a/attachment.pgp>
available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110524/3b6b9a1a/attachment.pgp>
7 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110524/658c35a8/attachment-0001.pgp>
"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
t available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110524/4390ff20/attachment.pgp>
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110524/86a6eb7a/attachment.pgp>
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
art --
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>
or.
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>
muchmail.org/pipermail/notmuch/attachments/20110524/dcd49c1d/attachment.pgp>
t 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>
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>
: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110524/8ccaad99/attachment.pgp>
Hi Carl,
thank you very much for your effort. Works well now with your patch.
regards
Matthias
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>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
43 matches
Mail list logo
