be a
very frequent problem with email messages that are not on this listserv
:), it would be nice to fix it. Maybe you could change the regex that
matches id:?s to require a little more structure ? an at-sign, perhaps.
Or even requiring more than (say) 5 non-space characters after the
message id w
The benefits of `visual-line-mode' were that it wrapped long lines
> in received messages. With `notmuch-wash-wrap-long-lines' now default
> behaviour, this is no longer required.
+1
--
Aaron Ecay
On Mon, 16 Jan 2012 08:39:30 +, David Edmondson wrote:
> On Mon, 16 Jan 2012 02:38:38 -0500, Aaron Ecay wrote:
> > - Greater flexibility in the construction of address lists. For example,
> > there are some email lists where I want replies to list mail to go only
> &g
it seems like this is the case.)
If you do:
M-x set-variable RET debug-on-quit RET t RET
then trigger the loop and press C-g, you should get a buffer showing a
backtrace of the lisp stack. What does that say?
Thanks,
--
Aaron Ecay
+1 on this series from me. (Minor comments on a couple of the patches
to follow.)
--
Aaron Ecay
+ ;; given, tags will be removed instead of added.
This should be a docstring instead of a comment. (This applies equally
to the old version)
--
Aaron Ecay
will be
> +\"unarchived\" (ie. the \"inbox\" tag will be added instead of
> +removed)."
> + (interactive)
If this function uses the prefix arg, its interactive call should be
?(interactive "P")?. This applies equally to the -thread variant in
patch 2/6, but I made the comment here because that diff doesn?t show
the function contiguously.
--
Aaron Ecay
+1
--
Aaron Ecay
r ()
(notmuch-with-temp-part-buffer
id part-number #'notmuch-show-part-button-whatever-worker))
It would be the latter function that the key would be bound to. If a
macro is used, the split between the worker and glue fns can be
abandoned, and only one function is needed:
(defun notmuch-show-part-button-whatever ()
(notmuch-with-temp-part-buffer
;; do stuff...
))
A further advantage is if interactive arguments (e.g. C-u prefix) are
needed for the function, there is no need to thread them through as
arguments of notmuch-with-temp-part-buffer.
--
Aaron Ecay
t instead of a documentation string,
| but that is no longer the case--documentation strings now take up
| very little space in a running Emacs.
`----
--
Aaron Ecay
based on Aaron's review - the comments were very useful in
> improving things - thanks!
You?re welcome! The patch LGTM.
--
Aaron Ecay
we pick (and I vote for allowing runtime use.)
Aaron
Footnotes:
[1] He specifically objects to the way that the cl package uses keyword
arguments, calling it un-Elisp-like. He has resisted past efforts
to merge cl functions into Elisp core, although they are slowly
diffusing across the barrier.
--
Aaron Ecay
> to inline.
>
> This fixes the display of attached image/jpeg parts, for example.
I had suggested the same approach in a message that only Dmitry got
(accursed new reply bindings!) LGTM.
--
Aaron Ecay
Emacs message-mode uses certain text strings to indicate how to attach
files to outgoing mail. If these are present in the text of an email,
and a user is tricked into replying to the message, the user?s files
could be exposed.
---
To demonstrate this, open a reply to this message then remove the
mitigate this, whatever reply mechanism winds up being used should
call mml-quote-region on the reply text (as message-cite-original does).
I just sent a patch to the list to do this in the current version of
notmuch, which should show up in
id:"1326998589-37187-1-git-send-email-aaronecay at gmail.com" .
--
Aaron Ecay
show
buffer that says:
- 6 messages hidden -
instead of the 6 (or however many) individual messages.
--
Aaron Ecay
t, and sending the reply will produce the original
single-quoted tag again.
--
Aaron Ecay
sn?t
mean that we should break that usage.
>
> >
> > (defun notmuch-mua-forward-message ()
> >(message-forward)
>
> Speaking of future-proofing, it would be good to have a test.
It would. ;) I?ll work on one.
--
Aaron Ecay
case is a security hole, then the hole is in the user?s brain
and not in notmuch. :)
--
Aaron Ecay
On Thu, 19 Jan 2012 21:46:46 -0700, Adam Wolfe Gordon
wrote:
> On Thu, Jan 19, 2012 at 11:45, Aaron Ecay wrote:
> > Shouldn?t this just use message-insert-formatted-citation-line?
>
> Yes, good idea. I just tried this and it almost works. The only
> issue is that the de
files to email very often, but I?ll let you know
how it works out.
Thanks a lot,
--
Aaron Ecay
The test is broken at this time; the next commit will introduce a fix.
---
Thanks for the reminder, Austin. Things got hectic, and it took a
little bludgeoning to get the test suite to behave. I *think* I got
it, although I am by no means confident. Specifically, I am seeing
some unrelated(?) t
Emacs message-mode uses certain text strings to indicate how to attach
files to outgoing mail. If these are present in the text of an email,
and a user is tricked into replying to the message, the user?s files
could be exposed.
---
NEWS | 18 ++
emacs/notmuch-mua
it anymore.
Maybe you could use a combination of ‘make-obsolete’ (for byte-compiler
warnings) and ‘display-warning’ (for runtime)? I understand the desire
to phase the function out eventually rather than have an eternal stub,
but intentionally breaking .emacs is a really d
e to prevent peoples emacs startup
> from failing.
Guess who wrote a reply before catching up on all the list mail. :P
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
+ (subject (plist-get headers :Subject))
> + (to (plist-get headers :To))
> + (cc (plist-get headers :Cc)))
> +
> +(eval directive)))
This code is not compatible with lexical binding in emacs >= 24, which I
assume notmuch will eventually want to adopt. What’s so bad about
--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen:
[...]
> TextCat is in Perl. I don't know if there's a C or C++ implementation but
> it isn't a huge piece of code - finding a good technique was the clever part
> of it.
The same algorithm is implemented in C here:
http://www.mnogosearch.org/g
Makes the following improvements:
- fix up doc strings
- suppress the creation of unnecessary let-bindings
- create overlays lazily (to avoid creating many overlays for threads
that do not get colored)
Signed-off-by: Aaron Ecay
---
notmuch.el | 29 ++---
1 files
--- 2010ko Otsailak 7an, "Aneesh Kumar K. V"-ek idatzi zuen:
> Doesn't 92c4dcc641e9dfb5f65026ebae5cedc8eb1d9e21 help you achive something
> similar ?
That commit allows colors to be applied to the tag name only, whereas this
patch applies the color to the whole line. Which method(s) notmuch shoul
Makes the following improvements:
- fix up doc strings
- suppress the creation of unnecessary let-bindings
- create overlays lazily (to avoid creating many overlays for threads
that do not get colored)
Signed-off-by: Aaron Ecay
---
emacs/notmuch.el | 21 ++---
1 files
In the process of updating to the latest sources, I've discovered that notmuch
no longer builds on OS X. As a reply to this email, I'll be sending 4
patches. The first two are bugfixes; the third adds the infrastructure to the
Makefiles to build a shared library on OS X, since the Mach-O conventi
Since the binaries contain C++ code, it is necessary to use the C++
linker, or errors result on some platforms (OS X).
Signed-off-by: Aaron Ecay
---
Makefile.local |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.local b/Makefile.local
index 71525e2..9e753cd
Must set extra_c(xx)flags before including subdir Makefile.local's,
so that there is a blank slate that the subdirs can add on to.
Must include subdir Makefile.local's before global one, otherwise
the compat sources are not added to the list of those to be
compiled.
Signed-off-by:
This patch adds a configure check for OS X (actually Darwin),
and sets up the Makefiles to build a proper shared library on
that platform.
Signed-off-by: Aaron Ecay
---
Makefile |2 +-
Makefile.local |2 +-
configure | 13 +
lib/Makefile.local | 16
Otherwise, symbol not found errors result on OS X. I am not sure
this is the correct solution for the problem, but it gets the build
working.
Signed-off-by: Aaron Ecay
---
Makefile.local |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.local b/Makefile.local
--- 2010ko Apirilak 12an, Tomas Carnecky-ek idatzi zuen:
>
> Adding that function to compat/ probably is the way to go, but the whole
> compat mechanism doesn't work here. It's like if compat/Makefile.local was
> not included in the top-level makefile, notmuch_compat_srcs is empty
> there. Any ide
--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen:
[...]
> TextCat is in Perl. I don't know if there's a C or C++ implementation but
> it isn't a huge piece of code - finding a good technique was the clever part
> of it.
The same algorithm is implemented in C here:
http://www.mnogosearch.org/g
Makes the following improvements:
- fix up doc strings
- suppress the creation of unnecessary let-bindings
- create overlays lazily (to avoid creating many overlays for threads
that do not get colored)
Signed-off-by: Aaron Ecay
---
notmuch.el | 29 ++---
1 files
--- 2010ko Otsailak 7an, "Aneesh Kumar K. V"-ek idatzi zuen:
> Doesn't 92c4dcc641e9dfb5f65026ebae5cedc8eb1d9e21 help you achive something
> similar ?
That commit allows colors to be applied to the tag name only, whereas this
patch applies the color to the whole line. Which method(s) notmuch shoul
Makes the following improvements:
- fix up doc strings
- suppress the creation of unnecessary let-bindings
- create overlays lazily (to avoid creating many overlays for threads
that do not get colored)
Signed-off-by: Aaron Ecay
---
emacs/notmuch.el | 21 ++---
1 files
In the process of updating to the latest sources, I've discovered that notmuch
no longer builds on OS X. As a reply to this email, I'll be sending 4
patches. The first two are bugfixes; the third adds the infrastructure to the
Makefiles to build a shared library on OS X, since the Mach-O conventi
Since the binaries contain C++ code, it is necessary to use the C++
linker, or errors result on some platforms (OS X).
Signed-off-by: Aaron Ecay
---
Makefile.local |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.local b/Makefile.local
index 71525e2..9e753cd
Must set extra_c(xx)flags before including subdir Makefile.local's,
so that there is a blank slate that the subdirs can add on to.
Must include subdir Makefile.local's before global one, otherwise
the compat sources are not added to the list of those to be
compiled.
Signed-off-by:
This patch adds a configure check for OS X (actually Darwin),
and sets up the Makefiles to build a proper shared library on
that platform.
Signed-off-by: Aaron Ecay
---
Makefile |2 +-
Makefile.local |2 +-
configure | 13 +
lib/Makefile.local | 16
Otherwise, symbol not found errors result on OS X. I am not sure
this is the correct solution for the problem, but it gets the build
working.
Signed-off-by: Aaron Ecay
---
Makefile.local |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.local b/Makefile.local
--- 2010ko Apirilak 12an, Tomas Carnecky-ek idatzi zuen:
>
> Adding that function to compat/ probably is the way to go, but the whole
> compat mechanism doesn't work here. It's like if compat/Makefile.local was
> not included in the top-level makefile, notmuch_compat_srcs is empty
> there. Any ide
Dear all,
I just pulled the last couple weeks' worth of changes and rebuilt
notmuch, only to have the new binary give a segfault on "notmuch new"
(running on OS X.6). The error message printed was:
(process:21821): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to
call g_type_init()
And the
Signed-off-by: Aaron Ecay
---
notmuch.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/notmuch.c b/notmuch.c
index 3973e35..f9d6629 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -579,6 +579,7 @@ main (int argc, char *argv[])
local = talloc_new (NULL
The Glib docs state "Prior to any use of the type system, g_type_init() has to
be called".[1] To not do so can lead to segfaults. The g_type system is
currently used by various "filters" that operate on uuencoded text, message
headers, etc.
[1]
http://developer.gnome.org/gobject/2.28/gobject-Typ
function,
to future-proof against such changes. This is adapted from the approach
taken by message-mail, a similar function built into emacs.
This patch was originally submitted by richardmu...@gmail.com on Aug. 1:
id:"877h6x6oor@veracitynetworks.com"
Signed-off-by: Aaron Ecay
---
>From the emacs changelog:
** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and
passes it to the mail user agent function. This argument specifies an
action for returning to the caller after finishing with the mail.
This is currently used by Rmail to delete a mail window.
>From the emacs changelog:
** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and
passes it to the mail user agent function. This argument specifies an
action for returning to the caller after finishing with the mail.
This is currently used by Rmail to delete a mail window.
>From the emacs changelog:
** `compose-mail' now accepts an optional 8th arg, RETURN-ACTION, and
passes it to the mail user agent function. This argument specifies an
action for returning to the caller after finishing with the mail.
This is currently used by Rmail to delete a mail window.
On some systems (incl. OS X 10.6), mktemp expects an argument giving it
the place to put the new temporary file.
---
On my machine without this patch, make prints a message from mktemp
about expecting an argument each time it is run. At some point, make
got into a situation where it would print t
Parallel to ignoring .so for linux.
---
.gitignore |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 9468e30..d64ec9f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,6 +9,7 @@ notmuch.sym
notmuch-shared
notmuch.1.gz
libnotmuch.so*
+libnotmuch*
This generates byte-compiler warnings on (at least) current trunk
versions of Emacs. The quote is not necessary; lambda forms are
self-quoting.
---
emacs/notmuch-crypto.el |4 +-
emacs/notmuch-hello.el | 64 +-
emacs/notmuch-maildir-fcc.el
makefile is called unconditionally, on all systems. So
it doesn't matter if one does "make debian-snapshot" or not, the error
is still generated.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
es the broader problem.
Aaron
* I think that inhibit -> nil, block -> ".*" should achieve this, but I’m
not sure/haven’t tested
** For example, Gmail makes you click a link at the top of an email
before it will load any network ima
(Please excuse the lack of inline comments on the patch – the original
patch email is so old that I had deleted it from my archives!)
progn...set-buffer should be with-current-buffer
or...eq...eq... would be cleaner as (memq major-mode '(foo bar baz))
Otherwise, LGTM
--
Aaron
ically unrolls it into a native Lisp loop. Thus
the performance hit, if any, is negligible.)
>
> ... memq is also nice; in case used the list should be done beforehand with
> (let* ...
Given the fact about loop, let* isn’t really applicable.
--
Aaron Ecay
__
function.
Aaron
[1] I see that (featurep 'gnus) returns t for me, so that horse is
already out of the barn. But it isn’t something we should be
seeking to perpetuate.
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmuch
Text properties change between characters; prev-s-c-property-change
returns the position after the change. Thus, it is still inside the
invisible region.
---
emacs/notmuch-show.el |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-sh
David,
Would the problem you had with previous-s-c-prop-change be fixed by the
patch to the original function I sent in the thread starting at
id:"m2y5u5cykp@kcals.intra.maillard.im" ?
--
Aaron Ecay
___
notmuch mailing list
notmuch@notmu
probably better emacs citizenship to not use such a
standard key for a different purpose.
--
Aaron Ecay
101 - 164 of 164 matches
Mail list logo