Emacs: Crypto: How to get automatic encryption?
Hi David, notmuch developers, On Wed, 04 Jan 2012 08:48:43 +, David Edmondson wrote: > On Wed, 04 Jan 2012 08:36:39 +, David Edmondson wrote: > > (if (and encrypt (dme:message-determine-encryption)) > > Oops. `encrypt' is set to `t' earlier if the code decides that I want to > encrypt outgoing mail (it's not set for work purposes, in essence). Thanks for your code. It works here too and is much appreciated. [Off topic: I'm working through the mime-security customisation at the moment. As far as I see now mime-security proposes all ultimately trusted keys for signing and does not filter this list of keys with the email address in the From: header. As a mutt user I'm used otherwise: mutt is configurable to only show a key selection menu if there are more than one key which fit the relevant address -- otherwise it uses this only one without further ado.] Ciao; Gregor -- 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/20120115/d8750632/attachment.pgp>
[PATCH] emacs: Don't attempt to colour tags in `notmuch-show-mode'.
On Tue, 27 Dec 2011 16:47:14 +, David Edmondson wrote: > The tags were coloured using text properties. Unfortunately that text > (the header line) also has an overlay, which overrides the text > properties. There's not point in applying text properties that will > never be seen. Pushed. d
[PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
On Wed, 28 Dec 2011 08:29:58 +, David Edmondson wrote: > As suggested by j4ni in #notmuch, rename > `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and > have it behave accordingly. pushed, d
[PATCH] test: don't bail out of `run_emacs' too early when missing prereqs
On Sat, 14 Jan 2012 10:09:37 +0100, Pieter Praet wrote: > When running the Emacs tests in verbose mode, only the first missing > prereq is reported because the `run_emacs' function is short-circuited > early: pushed. d
[PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
Quoth David Edmondson on Jan 15 at 11:55 am: > On Sat, 14 Jan 2012 10:29:31 +0100, Pieter Praet wrote: > > Might I ask, to what key(chord) have you bound this ? Due to its > > usefulness, I'm inclined to bind it to [SPC], but on second though, > > that might be a bit on the intense side... > > C-c= globally. That's clobbered in a couple of major modes, but not > enough to bother me so far. Might it make sense to bind this across the notmuch mode maps by default? This would at least make this feature more visible as well as quite useful to people who dedicate an Emacs instance to notmuch.
[PATCH 2/2] cli: pick the user's address in a group list as from address
On Sat, 14 Jan 2012 23:49:50 +0200, Jani Nikula wrote: > Messages received to a group list were not replied to using the from > address in the list. Fix it. > > Signed-off-by: Jani Nikula > --- Both LGTM. Tomi
[PATCH v3 04/10] notmuch-dump: add --format=(notmuch|sup)
On Sun, 15 Jan 2012 15:35:11 -0500, Austin Clements wrote: > We definitely need a round-trip-able dump format. Did you consider > using JSON to allow for future flexibility (e.g., expansion of what we > store in the database) and so we don't have to invent our own > encodings? A JSON format wouldn't necessarily be a reason *not* to > also have this format, especially considering how > shell-script-friendly this is (versus how shell-script-unfriendly JSON > is), I'm just curious what trade-offs you're considering. I was looking for something fairly close to what we have, to allow people to migrate their various scripts (e.g. nmbug) to the new format without too much pain. Maybe some small amount of header information at the start of the file would support extensibility, while still being shell script friendly. I'm also not too sure how much overhead the JSON quoting would induce. My tags file is currently about 10M, and on my old laptop takes about 15s to dump. That's a long 15s when I'm trying to sync my mail. For "normal" backup use, a little more overhead doesn't matter, although the stories of non-linear slowdowns that people report suggest we shouldn't get too cavalier about that. > You might want to call this format something more self-descriptive > like "text" or "hextext" or something in case we do want to expand in > the future. "sup" is probably fine for the legacy format since that's > set in stone at this point. yeah, I'm definitely open to better suggestions for a name
[PATCH] test: don't bail out of `run_emacs' too early when missing prereqs
On Sat, 14 Jan 2012 10:07:41 +0100, Pieter Praet wrote:
> On Thu, 12 Jan 2012 21:34:29 +0400, Dmitry Kurochkin gmail.com> wrote:
> > On Thu, 12 Jan 2012 18:16:59 +0100, Pieter Praet
> > wrote:
> > > When running the Emacs tests in verbose mode, only the first missing
> > > prereq is reported because the `run_emacs' function is short-circuited
> > > early:
> > >
> > > #+begin_example
> > > emacs: Testing emacs interface
> > > missing prerequisites: [0] emacs(1)
> > > skipping test: [0] Basic notmuch-hello view in emacs
> > > SKIP [0] Basic notmuch-hello view in emacs
> > > #+end_example
> > >
> > > This can lead to situations reminiscent of "dependency hell", so instead
> > > of returning based on each individual `test_require_external_prereq's exit
> > > status, we now do so by checking $test_subtest_missing_external_prereqs_:
> > >
> > > #+begin_example
> > > emacs: Testing emacs interface
> > > missing prerequisites: [0] dtach(1) emacs(1) emacsclient(1)
> > > skipping test: [0] Basic notmuch-hello view in emacs
> > > SKIP [0] Basic notmuch-hello view in emacs
> > > #+end_example
> > >
> > > Also add missing prereq for dtach(1).
> > >
> > > ---
> > > test/test-lib.sh |6 --
> > > 1 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/test/test-lib.sh b/test/test-lib.sh
> > > index 82767c0..6ec3882 100644
> > > --- a/test/test-lib.sh
> > > +++ b/test/test-lib.sh
> > > @@ -907,8 +907,10 @@ EOF
> > >
> > > test_emacs () {
> > > # test dependencies beforehand to avoid the waiting loop below
> > > - test_require_external_prereq emacs || return
> > > - test_require_external_prereq emacsclient || return
> > > + test_require_external_prereq dtach
> > > + test_require_external_prereq emacs
> > > + test_require_external_prereq emacsclient
> > > + test -z "$test_subtest_missing_external_prereqs_" || return
> >
> > There may be other missing dependencies before test_emacs() is called
> > and $test_subtest_missing_external_prereqs_ would not be blank. [...]
>
> True, hadn't though of that...
>
> > [...] Also, I
> > would like to keep the number of functions that use
> > $test_subtest_missing_external_prereqs_ minimal. [...]
>
> Could you elaborate on that?
>
This variable is supposed to be internal. I would like to be able to
change it's meaning or replace it with something better with minimal
changes in the other code. So I prefer it to be used only by few
"low-level" dependency functions.
This is not some strict rule, in other situation I may agree that using
$test_subtest_missing_external_prereqs_ directly is the best option.
But in this case, introducing a local variable with clean and simple
meaning is better IMO.
Regards,
Dmitry
> > [...] How about:
> >
> > missing_dependencies=
> > test_require_... dtach || missing_dependencies=1
> > test_require_... emacs || missing_dependencies=1
> > ...
> > test -z "$missing_dependencies" || return
> >
>
> Agreed! Patch follows.
>
> > Regards,
> > Dmitry
> >
> > >
> > > if [ -z "$EMACS_SERVER" ]; then
> > > server_name="notmuch-test-suite-$$"
> > > --
> > > 1.7.8.1
> > >
>
>
> Peace
>
> --
> Pieter
[PATCH] test: don't bail out of `run_emacs' too early when missing prereqs
On Sat, 14 Jan 2012 10:09:37 +0100, Pieter Praet wrote:
> When running the Emacs tests in verbose mode, only the first missing
> prereq is reported because the `run_emacs' function is short-circuited
> early:
>
> #+begin_example
> emacs: Testing emacs interface
> missing prerequisites: [0] emacs(1)
> skipping test: [0] Basic notmuch-hello view in emacs
> SKIP [0] Basic notmuch-hello view in emacs
> #+end_example
>
> This can lead to situations reminiscent of "dependency hell", so instead
> of returning based on each individual `test_require_external_prereq's exit
> status, we now do so only after checking all the prereqs:
>
> #+begin_example
> emacs: Testing emacs interface
> missing prerequisites: [0] dtach(1) emacs(1) emacsclient(1)
> skipping test: [0] Basic notmuch-hello view in emacs
> SKIP [0] Basic notmuch-hello view in emacs
> #+end_example
>
> Also added missing prereq for dtach(1).
looks good to me
Regards,
Dmitry
> ---
> test/test-lib.sh |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index 82767c0..d1fbc05 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -907,8 +907,11 @@ EOF
>
> test_emacs () {
> # test dependencies beforehand to avoid the waiting loop below
> - test_require_external_prereq emacs || return
> - test_require_external_prereq emacsclient || return
> + missing_dependencies=
> + test_require_external_prereq dtach || missing_dependencies=1
> + test_require_external_prereq emacs || missing_dependencies=1
> + test_require_external_prereq emacsclient || missing_dependencies=1
> + test -z "$missing_dependencies" || return
>
> if [ -z "$EMACS_SERVER" ]; then
> server_name="notmuch-test-suite-$$"
> --
> 1.7.8.1
>
Partial words on notmuch search?
Andrei Popescu writes: > After reading all the docs and a few experiments I don't see how to do > searches on partial words. If I missed the fine manual mentioning that > I'd be glad to RTFM, just please point me to the right FM :) That's OK - I asked the same question once. Use '*'. For example, Obam* should match "Obama".
[RFC] vim plugin rewrite II
On Sat, 14 Jan 2012 22:15:07 -0400, David Bremner wrote: > On Sat, 14 Jan 2012 08:54:43 +0100, anton at khirnov.net wrote: > > > > The advantages over current vim client are still the following: > > * sending and displaying/saving attachments > > * much better unicode support > > * tag name and search commands completion > > * proper representation of the thread structure > > * easier to extend thanks to python's massive standard library > > > > Please comment. > > Hi Anton; > > I'm not a vim user, so I probably can't say anything very helpful, but > it does sound like some nice improvements. Hopefully one of our vim > front-end users can comment a bit more. One thing I wondered about is > if your version is still completely synchronous, with the resulting > problems dealing with large (say, more than 1 messages) search > results? > Yes, it's still synchronous. I suppose making it asynchronous shouldn't be all that hard, i just never found enough time and motivation for that (it was never a huge problem here). -- Anton Khirnov
[PATCH v3 04/10] notmuch-dump: add --format=(notmuch|sup)
Quoth David Bremner on Jan 14 at 9:40 pm: > From: David Bremner > > sup is the old format, and remains the default. > > Each line of the notmuch format is "msg_id tag tag...tag" where each > space seperated token is 'hex-encoded' to remove troubling characters. > In particular this format won't have the same problem with e.g. spaces > in message-ids or tags; they will be round-trip-able. We definitely need a round-trip-able dump format. Did you consider using JSON to allow for future flexibility (e.g., expansion of what we store in the database) and so we don't have to invent our own encodings? A JSON format wouldn't necessarily be a reason *not* to also have this format, especially considering how shell-script-friendly this is (versus how shell-script-unfriendly JSON is), I'm just curious what trade-offs you're considering. You might want to call this format something more self-descriptive like "text" or "hextext" or something in case we do want to expand in the future. "sup" is probably fine for the legacy format since that's set in stone at this point.
[PATCH] Fix dependency generation for compat, test, and util
This adds source files in compat, test, and util to SRCS so that the top-level Makefile.local will generate dependency files for them. --- compat/Makefile.local |2 ++ test/Makefile.local |1 + util/Makefile.local |1 + 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/compat/Makefile.local b/compat/Makefile.local index 504eb71..13f16cd 100644 --- a/compat/Makefile.local +++ b/compat/Makefile.local @@ -12,3 +12,5 @@ endif ifneq ($(HAVE_STRCASESTR),1) notmuch_compat_srcs += $(dir)/strcasestr.c endif + +SRCS := $(SRCS) $(notmuch_compat_srcs) diff --git a/test/Makefile.local b/test/Makefile.local index fa2df73..4a6a4b1 100644 --- a/test/Makefile.local +++ b/test/Makefile.local @@ -28,6 +28,7 @@ test: all test-binaries check: test +SRCS := $(SRCS) $(smtp_dummy_srcs) CLEAN := $(CLEAN) $(dir)/smtp-dummy $(dir)/smtp-dummy.o \ $(dir)/symbol-test $(dir)/symbol-test.o \ $(dir)/arg-test $(dir)/arg-test.o diff --git a/util/Makefile.local b/util/Makefile.local index 26e4c3f..c7cae61 100644 --- a/util/Makefile.local +++ b/util/Makefile.local @@ -10,4 +10,5 @@ libutil_modules := $(libutil_c_srcs:.c=.o) $(dir)/libutil.a: $(libutil_modules) $(call quiet,AR) rcs $@ $^ +SRCS := $(SRCS) $(libutil_c_srcs) CLEAN := $(CLEAN) $(libutil_modules) $(dir)/libutil.a -- 1.7.7.3
[PATCH] Fix dependency generation for CLI sources
Previously, the dependency file list was generated before the CLI sources were added to SRCS, so dependency files weren't generated for CLI sources. This moves that code to after the CLI sources are added. --- Makefile.local |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile.local b/Makefile.local index d3bf947..1131dea 100644 --- a/Makefile.local +++ b/Makefile.local @@ -273,10 +273,6 @@ quiet ?= $($(shell echo $1 | sed -e s'/ .*//')) sed 's,'$$(basename $*)'\.o[ :]*,$*.o $@ : ,g' < $@. > $@; \ rm -f $@. -DEPS := $(SRCS:%.c=.deps/%.d) -DEPS := $(DEPS:%.cc=.deps/%.d) --include $(DEPS) - .PHONY : clean clean: rm -f $(CLEAN); rm -rf .deps @@ -350,3 +346,7 @@ install-desktop: SRCS := $(SRCS) $(notmuch_client_srcs) CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc + +DEPS := $(SRCS:%.c=.deps/%.d) +DEPS := $(DEPS:%.cc=.deps/%.d) +-include $(DEPS) -- 1.7.7.3
[PATCH 4/4] emacs: Use the new JSON reply format.
Hi Dmitry, On Thu, Jan 12, 2012 at 01:33, Dmitry Kurochkin wrote: > I did not follow the rest of the discussion, so sorry if I missed > something obvious. ?But why can't we render HTML parts in replies the > same way we do in notmuch-show (using `mm-display-part')? ?That should > not introduce a w3m.el requirement, would use the same renderer as > configured for show and hence would produce consistent output in show > and reply. Thanks for the suggestion - I've implemented this now and I think it's definitely the best way to go. New patches coming soon with all the suggested changes. -- Adam Wolfe Gordon
[PATCH] Output unmodified Content-Type header value for JSON format.
On Sun, 15 Jan 2012 11:52:40 +, David Edmondson wrote: > > Technically the IRC discussion was about not including *any* part > > content in the JSON output, and always using show --format=raw or > > similar to retrieve desired parts. Currently, notmuch includes part > > content in the JSON only for text/*, *except* when it's text/html. I > > assume non-text parts are omitted because binary data is hard to > > represent in JSON and text/html is omitted because some people don't > > need it. However, this leads to some peculiar asymmetry in the Emacs > > code where sometimes it pulls part content out of the JSON and > > sometimes it retrieves it using show --format=raw. This in turn leads > > to asymmetry in content encoding handling, since notmuch handles > > content encoding for parts included in the JSON (and there's no good > > way around that since JSON is Unicode), but not for parts retrieved as > > raw. > > Including the text output in the JSON results in significantly fewer > calls to 'notmuch' during the building of a typical `notmuch-show-mode' > buffer. Someone with one of those older, crankier computers could easily > test how much effect this has by changing > `notmuch-show-get-bodypart-content' slightly. Yes. I was mostly reiterating the IRC discussion for Pieter. Since this discussion, I've stabilized on the pre-fetching notion I described in id:"20120115003617.GH1801 at mit.edu", though I do think we should make this clear in the code: that the rule for whether the JSON includes a "content" key for a leaf part is internal to the CLI and that consumers should be prepared to use it if it's there and to retrieve the content separately if it's not. This is exactly how the Emacs code happens to work, it just hasn't been codified anywhere. Looking at it this way gives us more flexibility than the current code takes advantage of; for example we could omit content from the JSON if it's over some size threshold since the cost of sending that to a client that doesn't need it is high while the cost of having the client retrieve it for itself is relatively low. > > The idea discussed on IRC was to remove all part content from the JSON > > output and to always use show to retrieve it, possibly beefing up > > show's support for content decoding (and possibly introducing a way to > > retrieve multiple raw parts at once to avoid re-parsing). This would > > get the JSON format out of the business of guessing what consumers > > need, simplify the Emacs code, and normalize content encoding > > handling. > > Is there a real problem being solved here? Having a clean structure is > nice, except when it's not. The "real" problem is the asymmetry in encoding handling that started this discussion. Content included in the JSON is re-encoded by the CLI, while content retrieved via raw needs to be re-encoded by the client. OTOH, I don't understand the encoding story for HTML, since the encoding can come from either a header or from the body of the HTML. Does this make it strictly necessary for the client to handle the encoding?
[PATCH 1/1] Make buttons for attachments allow viewing as well as saving
Define a keymap for attachment buttons to allow multiple actions. Define 3 possible actions: save attachment: exactly as currently, view attachment: uses mailcap entry, view attachment with user chosen program Keymap on a button is: s for save, v for view and o for view with other program. Default (i.e. enter or mouse button) is save but is easily configurable e.g. set to view with (setq notmuch-show-part-button-default-action 'notmuch-show-part-view-action) One implementation detail: the view attachment function forces all attachments to be "displayed" using mailcap even if emacs could display them itself. Thus, for example, text/html appears in a browser and text/plain asks whether to save (on a standard debian setup) --- emacs/notmuch-show.el | 81 ++-- 1 files changed, 64 insertions(+), 17 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 03c1f6b..a1c0e63 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -281,10 +281,21 @@ message at DEPTH in the current thread." (run-hooks 'notmuch-show-markup-headers-hook) (define-button-type 'notmuch-show-part-button-type - 'action 'notmuch-show-part-button-action + 'action 'notmuch-show-part-button-default + 'keymap 'notmuch-show-part-button-map 'follow-link t 'face 'message-mml) +(defvar notmuch-show-part-button-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map button-map) + (define-key map "s" 'notmuch-show-part-button-save) + (define-key map "v" 'notmuch-show-part-button-view) + (define-key map "o" 'notmuch-show-part-button-interactively-view) +map) + "Submap for button commands") +(fset 'notmuch-show-part-button-map notmuch-show-part-button-map) + (defun notmuch-show-insert-part-header (nth content-type declared-type name comment) (let ((button)) (setq button @@ -299,29 +310,43 @@ message at DEPTH in the current thread." " ]") :type 'notmuch-show-part-button-type :notmuch-part nth - :notmuch-filename name)) + :notmuch-filename name + :notmuch-content-type content-type)) (insert "\n") ;; return button button)) ;; Functions handling particular MIME parts. +;; this function is kept for the tests and any external users (defun notmuch-show-save-part (message-id nth filename) + (notmuch-show-part-action 'notmuch-show-part-save-action message-id nth nil filename)) + +(defun notmuch-show-part-action (action message-id nth content-type filename) (let ((process-crypto notmuch-show-process-crypto)) (with-temp-buffer (setq notmuch-show-process-crypto process-crypto) ;; Always acquires the part via `notmuch part', even if it is ;; available in the JSON output. (insert (notmuch-show-get-bodypart-internal message-id nth)) - (let ((file (read-file-name - "Filename to save as: " - (or mailcap-download-directory "~/") - nil nil - filename))) - ;; Don't re-compress .gz & al. Arguably we should make - ;; `file-name-handler-alist' nil, but that would chop - ;; ange-ftp, which is reasonable to use here. - (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t) + (cond ((eq action 'notmuch-show-part-save-action) +(let ((file (read-file-name + "Filename to save as: " + (or mailcap-download-directory "~/") + nil nil + filename))) + ;; Don't re-compress .gz & al. Arguably we should make + ;; `file-name-handler-alist' nil, but that would chop + ;; ange-ftp, which is reasonable to use here. + (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t))) + ((eq action 'notmuch-show-part-view-action) +;; set mm-inlined-types to nil to force an external viewer +(let ((handle (mm-make-handle (current-buffer) (list content-type))) + (mm-inlined-types nil)) + (mm-display-part handle))) + ((eq action 'notmuch-show-part-interactively-view-action) +(let ((handle (mm-make-handle (current-buffer) (list content-type + (mm-interactively-view-part handle))) (defun notmuch-show-mm-display-part-inline (msg part nth content-type) "Use the mm-decode/mm-view functions to display a part in the @@ -1502,12 +1527,34 @@ buffer." ;; Commands typically bound to buttons. -(defun notmuch-show-part-button-action (button) - (let ((nth (button-get button :notmuch-part))) -(if nth - (notmuch-show-save-part (notmuch-show-get-message-id) nth - (button-get button :notmuch-filename)) - (message "Not a valid part (is it a fake part?)." +(defvar
[PATCH 0/1] emacs: allow viewing as well saving individual attachments
Hello This is a resubmission of (a tidied version) of id:"87mxehqhbl.fsf at r102.config". I have modified the emacs interface for handling attachments by adding a keymap to the attachment button. For example pressing v when on an attachment button views the attachment (using the mailcap method) and pressing s saves the attachment. I find this makes it a lot easier when dealing with message with lots of attachments. Other comments: "Viewing" a text/html button opens the part in the mailcap defined html viewer. "Viewing" a part with no mailcap entry just offers to save it. In this version I make the button default to saving (as currently) but this is easily customizable. I have also mapped the key "o" (other/open with) on a button to open with user chosen program. This could be split out into a separate patch if preferred. I have been using the previous version since I wrote it in the summer and not had any problems. This tidied version is less well tested but the logic should be the same; it seems to work correctly in all cases I can think to test. Best wishes Mark Mark Walters (1): Make buttons for attachments allow viewing as well as saving emacs/notmuch-show.el | 81 ++-- 1 files changed, 64 insertions(+), 17 deletions(-) -- 1.7.2.3
[PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
On Sat, 14 Jan 2012 10:29:31 +0100, Pieter Praet wrote: > Might I ask, to what key(chord) have you bound this ? Due to its > usefulness, I'm inclined to bind it to [SPC], but on second though, > that might be a bit on the intense side... C-c= globally. That's clobbered in a couple of major modes, but not enough to bother me so far. -- 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/20120115/2fe429df/attachment.pgp>
[PATCH] emacs: globally replace non-branching "(if (not ..." with "(unless ..."
On Sat, 14 Jan 2012 10:18:46 +0100, Pieter Praet wrote: > Does this really warrant a v2, or might we simply leave it as yet > another victim for Tomi's uncrustify-for-elisp [1] ? Pushing incorrectly indented code should be banned, in my opinion[1]. I'd be tempted to have some pre-commit hooks to detect it. Footnotes: [1] Though I've done it myself. -- 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/20120115/e87ac1a1/attachment-0001.pgp>
[PATCH] Output unmodified Content-Type header value for JSON format.
> Technically the IRC discussion was about not including *any* part > content in the JSON output, and always using show --format=raw or > similar to retrieve desired parts. Currently, notmuch includes part > content in the JSON only for text/*, *except* when it's text/html. I > assume non-text parts are omitted because binary data is hard to > represent in JSON and text/html is omitted because some people don't > need it. However, this leads to some peculiar asymmetry in the Emacs > code where sometimes it pulls part content out of the JSON and > sometimes it retrieves it using show --format=raw. This in turn leads > to asymmetry in content encoding handling, since notmuch handles > content encoding for parts included in the JSON (and there's no good > way around that since JSON is Unicode), but not for parts retrieved as > raw. Including the text output in the JSON results in significantly fewer calls to 'notmuch' during the building of a typical `notmuch-show-mode' buffer. Someone with one of those older, crankier computers could easily test how much effect this has by changing `notmuch-show-get-bodypart-content' slightly. > The idea discussed on IRC was to remove all part content from the JSON > output and to always use show to retrieve it, possibly beefing up > show's support for content decoding (and possibly introducing a way to > retrieve multiple raw parts at once to avoid re-parsing). This would > get the JSON format out of the business of guessing what consumers > need, simplify the Emacs code, and normalize content encoding > handling. Is there a real problem being solved here? Having a clean structure is nice, except when it's not. -- 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/20120115/c37bd4f5/attachment-0001.pgp>
[PATCH v3 09/10] random-dump.c: new test-binary to generate dump files
oc_new (NULL);
> +int num_lines = 500;
> +int max_tags = 10;
> +int message_id_len = 100;
> +int tag_len = 50;
> +int seed = 734569;
> +
> +int pad_tag = 0, pad_mid = 0;
> +
> +notmuch_opt_desc_t options[] = {
> + { NOTMUCH_OPT_INT, _lines, "num-lines", 'n', 0 },
> + { NOTMUCH_OPT_INT, _tags, "max-tags", 'm', 0 },
> + { NOTMUCH_OPT_INT, _id_len, "message-id-len", 'M', 0 },
> + { NOTMUCH_OPT_INT, _len, "tag-len", 't', 0 },
> + { NOTMUCH_OPT_INT, , "tag-len", 't', 0 },
s/tag-len/seed/
> + { 0, 0, 0, 0, 0 }
> +};
> +
> +int opt_index = parse_arguments (argc, argv, options, 1);
> +
> +if (opt_index < 0)
> + exit (1);
> +
> +pad_mid = ((int) log10 (num_lines) + 1);
> +pad_tag = ((int) log10 (max_tags)) + 1;
> +
> +srandom (seed);
> +
> +int line;
> +for (line = 0; line < num_lines; line++) {
> +
> + printf ("%0*d-", pad_mid, line);
> +
> + random_message_id (ctx, message_id_len);
> +
> + int num_tags = random () % (max_tags + 1);
> +
> + int j;
> + for (j = 0; j < num_tags; j++) {
> + printf (" %0*d-", pad_tag, j);
> + random_tag (ctx, tag_len);
> + }
> + putchar ('\n');
> +}
> +
> +talloc_free (ctx);
> +
> +return 0;
> +}
> --
> 1.7.7.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
-- next part --
An HTML attachment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20120115/48d4809f/attachment-0001.html>
[PATCH v3 09/10] random-dump.c: new test-binary to generate dump files
On Sun, 15 Jan 2012 10:05:15 +0200, Jani Nikula wrote:
> On Jan 15, 2012 3:41 AM, "David Bremner" wrote:
> >
> > From: David Bremner
> >
> > +notmuch_opt_desc_t options[] = {
> > + { NOTMUCH_OPT_INT, _lines, "num-lines", 'n', 0 },
> > + { NOTMUCH_OPT_INT, _tags, "max-tags", 'm', 0 },
> > + { NOTMUCH_OPT_INT, _id_len, "message-id-len", 'M', 0 },
> > + { NOTMUCH_OPT_INT, _len, "tag-len", 't', 0 },
> > + { NOTMUCH_OPT_INT, , "tag-len", 't', 0 },
>
> s/tag-len/seed/
>
Fixed, thanks.
d
[PATCH 0/4] Quoting HTML-only emails in replies redux
Given that we're now doing a bunch of work in emacs as part of the reply setup, why not just grab the content of the original message from the show buffer and quote that? The last time that approach was discussed Carl was against it because it moved the emacs UI away from the behaviour of the CLI, but it seems that we're already heading in that direction. -- 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/20120115/1ab0fa23/attachment-0001.pgp>
Re: [PATCH v3 09/10] random-dump.c: new test-binary to generate dump files
On Jan 15, 2012 3:41 AM, David Bremner da...@tethera.net wrote:
From: David Bremner brem...@debian.org
This binary creates a torture test dump file for the new dump
format.
---
test/Makefile.local |4 ++
test/basic |2 +-
test/random-dump.c | 144
+++
3 files changed, 149 insertions(+), 1 deletions(-)
create mode 100644 test/random-dump.c
diff --git a/test/Makefile.local b/test/Makefile.local
index ba697f4..b59f837 100644
--- a/test/Makefile.local
+++ b/test/Makefile.local
@@ -16,6 +16,9 @@ $(dir)/arg-test: $(dir)/arg-test.o
command-line-arguments.o util/libutil.a
$(dir)/hex-xcode: $(dir)/hex-xcode.o command-line-arguments.o
util/libutil.a
$(call quiet,CC) -I. $^ -o $@ -ltalloc
+$(dir)/random-dump: $(dir)/random-dump.o command-line-arguments.o
util/libutil.a
+ $(call quiet,CC) -I. $^ -o $@ -ltalloc -lm
+
$(dir)/smtp-dummy: $(smtp_dummy_modules)
$(call quiet,CC) $^ -o $@
@@ -25,6 +28,7 @@ $(dir)/symbol-test: $(dir)/symbol-test.o
.PHONY: test check
test-binaries: $(dir)/arg-test $(dir)/hex-xcode \
+ $(dir)/random-dump \
$(dir)/smtp-dummy $(dir)/symbol-test
test: all test-binaries
diff --git a/test/basic b/test/basic
index af57026..e3a6cef 100755
--- a/test/basic
+++ b/test/basic
@@ -54,7 +54,7 @@ test_begin_subtest 'Ensure that all available tests
will be run by notmuch-test'
eval $(sed -n -e '/^TESTS=$/,/^$/p' $TEST_DIRECTORY/notmuch-test)
tests_in_suite=$(for i in $TESTS; do echo $i; done | sort)
available=$(find $TEST_DIRECTORY -maxdepth 1 -type f -executable
-printf '%f\n' | \
-sed -r -e
/^(aggregate-results.sh|notmuch-test|smtp-dummy|test-verbose|symbol-test|arg-test|hex-xcode)$/d
| \
+sed -r -e
/^(aggregate-results.sh|notmuch-test|smtp-dummy|test-verbose|symbol-test|arg-test|hex-xcode|random-dump)$/d
| \
sort)
test_expect_equal $tests_in_suite $available
diff --git a/test/random-dump.c b/test/random-dump.c
new file mode 100644
index 000..1949425
--- /dev/null
+++ b/test/random-dump.c
@@ -0,0 +1,144 @@
+/*
+ Generate a random dump file in 'notmuch' format.
+ Generated message-id's and tags are intentionally nasty.
+
+ We restrict ourselves to 7 bit message-ids, because generating
+ random valid UTF-8 seems like work. And invalid UTF-8 can't be
+ round-tripped via Xapian.
+
+ */
+
+#include stdlib.h
+#include assert.h
+#include talloc.h
+#include string.h
+#include math.h
+#include hex-escape.h
+#include command-line-arguments.h
+
+static void
+hex_out (void *ctx, char *buf)
+{
+static char *encoded_buf = NULL;
+static size_t encoded_buf_size = 0;
+
+if (hex_encode (ctx, buf, encoded_buf, encoded_buf_size) !=
HEX_SUCCESS) {
+ fprintf (stderr, Hex encoding failed);
+ exit (1);
+}
+
+fputs (encoded_buf, stdout);
+}
+
+static void
+random_chars (char *buf, int from, int stop, int max_char,
+ const char *blacklist)
+{
+int i;
+
+for (i = from; i stop; i++) {
+ do {
+ buf[i] = ' ' + (random () % (max_char - ' '));
+ } while (blacklist strchr (blacklist, buf[i]));
+}
+}
+
+static void
+random_tag (void *ctx, size_t len)
+{
+static char *buf = NULL;
+static size_t buf_len = 0;
+
+int use = (random () % (len - 1)) + 1;
+
+if (len buf_len) {
+ buf = talloc_realloc (ctx, buf, char, len);
+ buf_len = len;
+}
+
+random_chars (buf, 0, use, 255, NULL);
+
+buf[use] = '\0';
+
+hex_out (ctx, buf);
+}
+
+static void
+random_message_id (void *ctx, size_t len)
+{
+static char *buf = NULL;
+static size_t buf_len = 0;
+
+int lhs_len = (random () % (len / 2 - 1)) + 1;
+
+int rhs_len = (random () % len / 2) + 1;
+
+const char *blacklist = \n\r@[]();
+
+if (len buf_len) {
+ buf = talloc_realloc (ctx, buf, char, len);
+ buf_len = len;
+}
+
+random_chars (buf, 0, lhs_len, 127, blacklist);
+
+buf[lhs_len] = '@';
+
+random_chars (buf, lhs_len + 1, lhs_len + rhs_len + 1, 127,
blacklist);
+
+hex_out (ctx, buf);
+}
+
+int
+main (int argc, char **argv)
+{
+
+void *ctx = talloc_new (NULL);
+int num_lines = 500;
+int max_tags = 10;
+int message_id_len = 100;
+int tag_len = 50;
+int seed = 734569;
+
+int pad_tag = 0, pad_mid = 0;
+
+notmuch_opt_desc_t options[] = {
+ { NOTMUCH_OPT_INT, num_lines, num-lines, 'n', 0 },
+ { NOTMUCH_OPT_INT, max_tags, max-tags, 'm', 0 },
+ { NOTMUCH_OPT_INT, message_id_len, message-id-len, 'M', 0 },
+ { NOTMUCH_OPT_INT, tag_len, tag-len, 't', 0 },
+ { NOTMUCH_OPT_INT, seed, tag-len, 't', 0 },
s/tag-len/seed/
+ { 0, 0, 0, 0, 0 }
+};
+
+int opt_index = parse_arguments (argc, argv, options, 1);
+
+if (opt_index 0)
+ exit (1);
+
+pad_mid
Re: [PATCH 0/4] Quoting HTML-only emails in replies redux
Given that we're now doing a bunch of work in emacs as part of the reply setup, why not just grab the content of the original message from the show buffer and quote that? The last time that approach was discussed Carl was against it because it moved the emacs UI away from the behaviour of the CLI, but it seems that we're already heading in that direction. pgpyQj9acKhOH.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Output unmodified Content-Type header value for JSON format.
Technically the IRC discussion was about not including *any* part content in the JSON output, and always using show --format=raw or similar to retrieve desired parts. Currently, notmuch includes part content in the JSON only for text/*, *except* when it's text/html. I assume non-text parts are omitted because binary data is hard to represent in JSON and text/html is omitted because some people don't need it. However, this leads to some peculiar asymmetry in the Emacs code where sometimes it pulls part content out of the JSON and sometimes it retrieves it using show --format=raw. This in turn leads to asymmetry in content encoding handling, since notmuch handles content encoding for parts included in the JSON (and there's no good way around that since JSON is Unicode), but not for parts retrieved as raw. Including the text output in the JSON results in significantly fewer calls to 'notmuch' during the building of a typical `notmuch-show-mode' buffer. Someone with one of those older, crankier computers could easily test how much effect this has by changing `notmuch-show-get-bodypart-content' slightly. The idea discussed on IRC was to remove all part content from the JSON output and to always use show to retrieve it, possibly beefing up show's support for content decoding (and possibly introducing a way to retrieve multiple raw parts at once to avoid re-parsing). This would get the JSON format out of the business of guessing what consumers need, simplify the Emacs code, and normalize content encoding handling. Is there a real problem being solved here? Having a clean structure is nice, except when it's not. pgpQcdKKYaD13.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: globally replace non-branching (if (not ... with (unless ...
On Sat, 14 Jan 2012 10:18:46 +0100, Pieter Praet pie...@praet.org wrote: Does this really warrant a v2, or might we simply leave it as yet another victim for Tomi's uncrustify-for-elisp [1] ? Pushing incorrectly indented code should be banned, in my opinion[1]. I'd be tempted to have some pre-commit hooks to detect it. Footnotes: [1] Though I've done it myself. pgpSjcYlWNUZf.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
On Sat, 14 Jan 2012 10:29:31 +0100, Pieter Praet pie...@praet.org wrote: Might I ask, to what key(chord) have you bound this ? Due to its usefulness, I'm inclined to bind it to [SPC], but on second though, that might be a bit on the intense side... C-c= globally. That's clobbered in a couple of major modes, but not enough to bother me so far. pgppjX1LeNMgl.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/1] emacs: allow viewing as well saving individual attachments
Hello This is a resubmission of (a tidied version) of id:87mxehqhbl.fsf@r102.config. I have modified the emacs interface for handling attachments by adding a keymap to the attachment button. For example pressing v when on an attachment button views the attachment (using the mailcap method) and pressing s saves the attachment. I find this makes it a lot easier when dealing with message with lots of attachments. Other comments: Viewing a text/html button opens the part in the mailcap defined html viewer. Viewing a part with no mailcap entry just offers to save it. In this version I make the button default to saving (as currently) but this is easily customizable. I have also mapped the key o (other/open with) on a button to open with user chosen program. This could be split out into a separate patch if preferred. I have been using the previous version since I wrote it in the summer and not had any problems. This tidied version is less well tested but the logic should be the same; it seems to work correctly in all cases I can think to test. Best wishes Mark Mark Walters (1): Make buttons for attachments allow viewing as well as saving emacs/notmuch-show.el | 81 ++-- 1 files changed, 64 insertions(+), 17 deletions(-) -- 1.7.2.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/1] Make buttons for attachments allow viewing as well as saving
Define a keymap for attachment buttons to allow multiple actions. Define 3 possible actions: save attachment: exactly as currently, view attachment: uses mailcap entry, view attachment with user chosen program Keymap on a button is: s for save, v for view and o for view with other program. Default (i.e. enter or mouse button) is save but is easily configurable e.g. set to view with (setq notmuch-show-part-button-default-action 'notmuch-show-part-view-action) One implementation detail: the view attachment function forces all attachments to be displayed using mailcap even if emacs could display them itself. Thus, for example, text/html appears in a browser and text/plain asks whether to save (on a standard debian setup) --- emacs/notmuch-show.el | 81 ++-- 1 files changed, 64 insertions(+), 17 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 03c1f6b..a1c0e63 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -281,10 +281,21 @@ message at DEPTH in the current thread. (run-hooks 'notmuch-show-markup-headers-hook) (define-button-type 'notmuch-show-part-button-type - 'action 'notmuch-show-part-button-action + 'action 'notmuch-show-part-button-default + 'keymap 'notmuch-show-part-button-map 'follow-link t 'face 'message-mml) +(defvar notmuch-show-part-button-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map button-map) + (define-key map s 'notmuch-show-part-button-save) + (define-key map v 'notmuch-show-part-button-view) + (define-key map o 'notmuch-show-part-button-interactively-view) +map) + Submap for button commands) +(fset 'notmuch-show-part-button-map notmuch-show-part-button-map) + (defun notmuch-show-insert-part-header (nth content-type declared-type optional name comment) (let ((button)) (setq button @@ -299,29 +310,43 @@ message at DEPTH in the current thread. ]) :type 'notmuch-show-part-button-type :notmuch-part nth - :notmuch-filename name)) + :notmuch-filename name + :notmuch-content-type content-type)) (insert \n) ;; return button button)) ;; Functions handling particular MIME parts. +;; this function is kept for the tests and any external users (defun notmuch-show-save-part (message-id nth optional filename) + (notmuch-show-part-action 'notmuch-show-part-save-action message-id nth nil filename)) + +(defun notmuch-show-part-action (action message-id nth content-type optional filename) (let ((process-crypto notmuch-show-process-crypto)) (with-temp-buffer (setq notmuch-show-process-crypto process-crypto) ;; Always acquires the part via `notmuch part', even if it is ;; available in the JSON output. (insert (notmuch-show-get-bodypart-internal message-id nth)) - (let ((file (read-file-name - Filename to save as: - (or mailcap-download-directory ~/) - nil nil - filename))) - ;; Don't re-compress .gz al. Arguably we should make - ;; `file-name-handler-alist' nil, but that would chop - ;; ange-ftp, which is reasonable to use here. - (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t) + (cond ((eq action 'notmuch-show-part-save-action) +(let ((file (read-file-name + Filename to save as: + (or mailcap-download-directory ~/) + nil nil + filename))) + ;; Don't re-compress .gz al. Arguably we should make + ;; `file-name-handler-alist' nil, but that would chop + ;; ange-ftp, which is reasonable to use here. + (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t))) + ((eq action 'notmuch-show-part-view-action) +;; set mm-inlined-types to nil to force an external viewer +(let ((handle (mm-make-handle (current-buffer) (list content-type))) + (mm-inlined-types nil)) + (mm-display-part handle))) + ((eq action 'notmuch-show-part-interactively-view-action) +(let ((handle (mm-make-handle (current-buffer) (list content-type + (mm-interactively-view-part handle))) (defun notmuch-show-mm-display-part-inline (msg part nth content-type) Use the mm-decode/mm-view functions to display a part in the @@ -1502,12 +1527,34 @@ buffer. ;; Commands typically bound to buttons. -(defun notmuch-show-part-button-action (button) - (let ((nth (button-get button :notmuch-part))) -(if nth - (notmuch-show-save-part (notmuch-show-get-message-id) nth - (button-get button :notmuch-filename)) - (message Not a valid part (is it a fake part?). +(defvar
Re: [PATCH v3 09/10] random-dump.c: new test-binary to generate dump files
On Sun, 15 Jan 2012 10:05:15 +0200, Jani Nikula j...@nikula.org wrote:
On Jan 15, 2012 3:41 AM, David Bremner da...@tethera.net wrote:
From: David Bremner brem...@debian.org
+notmuch_opt_desc_t options[] = {
+ { NOTMUCH_OPT_INT, num_lines, num-lines, 'n', 0 },
+ { NOTMUCH_OPT_INT, max_tags, max-tags, 'm', 0 },
+ { NOTMUCH_OPT_INT, message_id_len, message-id-len, 'M', 0 },
+ { NOTMUCH_OPT_INT, tag_len, tag-len, 't', 0 },
+ { NOTMUCH_OPT_INT, seed, tag-len, 't', 0 },
s/tag-len/seed/
Fixed, thanks.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: don't bail out of `run_emacs' too early when missing prereqs
On Sat, 14 Jan 2012 10:09:37 +0100, Pieter Praet pie...@praet.org wrote:
When running the Emacs tests in verbose mode, only the first missing
prereq is reported because the `run_emacs' function is short-circuited
early:
#+begin_example
emacs: Testing emacs interface
missing prerequisites: [0] emacs(1)
skipping test: [0] Basic notmuch-hello view in emacs
SKIP [0] Basic notmuch-hello view in emacs
#+end_example
This can lead to situations reminiscent of dependency hell, so instead
of returning based on each individual `test_require_external_prereq's exit
status, we now do so only after checking all the prereqs:
#+begin_example
emacs: Testing emacs interface
missing prerequisites: [0] dtach(1) emacs(1) emacsclient(1)
skipping test: [0] Basic notmuch-hello view in emacs
SKIP [0] Basic notmuch-hello view in emacs
#+end_example
Also added missing prereq for dtach(1).
looks good to me
Regards,
Dmitry
---
test/test-lib.sh |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 82767c0..d1fbc05 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -907,8 +907,11 @@ EOF
test_emacs () {
# test dependencies beforehand to avoid the waiting loop below
- test_require_external_prereq emacs || return
- test_require_external_prereq emacsclient || return
+ missing_dependencies=
+ test_require_external_prereq dtach || missing_dependencies=1
+ test_require_external_prereq emacs || missing_dependencies=1
+ test_require_external_prereq emacsclient || missing_dependencies=1
+ test -z $missing_dependencies || return
if [ -z $EMACS_SERVER ]; then
server_name=notmuch-test-suite-$$
--
1.7.8.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: don't bail out of `run_emacs' too early when missing prereqs
On Sat, 14 Jan 2012 10:07:41 +0100, Pieter Praet pie...@praet.org wrote:
On Thu, 12 Jan 2012 21:34:29 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
On Thu, 12 Jan 2012 18:16:59 +0100, Pieter Praet pie...@praet.org wrote:
When running the Emacs tests in verbose mode, only the first missing
prereq is reported because the `run_emacs' function is short-circuited
early:
#+begin_example
emacs: Testing emacs interface
missing prerequisites: [0] emacs(1)
skipping test: [0] Basic notmuch-hello view in emacs
SKIP [0] Basic notmuch-hello view in emacs
#+end_example
This can lead to situations reminiscent of dependency hell, so instead
of returning based on each individual `test_require_external_prereq's exit
status, we now do so by checking $test_subtest_missing_external_prereqs_:
#+begin_example
emacs: Testing emacs interface
missing prerequisites: [0] dtach(1) emacs(1) emacsclient(1)
skipping test: [0] Basic notmuch-hello view in emacs
SKIP [0] Basic notmuch-hello view in emacs
#+end_example
Also add missing prereq for dtach(1).
---
test/test-lib.sh |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 82767c0..6ec3882 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -907,8 +907,10 @@ EOF
test_emacs () {
# test dependencies beforehand to avoid the waiting loop below
- test_require_external_prereq emacs || return
- test_require_external_prereq emacsclient || return
+ test_require_external_prereq dtach
+ test_require_external_prereq emacs
+ test_require_external_prereq emacsclient
+ test -z $test_subtest_missing_external_prereqs_ || return
There may be other missing dependencies before test_emacs() is called
and $test_subtest_missing_external_prereqs_ would not be blank. [...]
True, hadn't though of that...
[...] Also, I
would like to keep the number of functions that use
$test_subtest_missing_external_prereqs_ minimal. [...]
Could you elaborate on that?
This variable is supposed to be internal. I would like to be able to
change it's meaning or replace it with something better with minimal
changes in the other code. So I prefer it to be used only by few
low-level dependency functions.
This is not some strict rule, in other situation I may agree that using
$test_subtest_missing_external_prereqs_ directly is the best option.
But in this case, introducing a local variable with clean and simple
meaning is better IMO.
Regards,
Dmitry
[...] How about:
missing_dependencies=
test_require_... dtach || missing_dependencies=1
test_require_... emacs || missing_dependencies=1
...
test -z $missing_dependencies || return
Agreed! Patch follows.
Regards,
Dmitry
if [ -z $EMACS_SERVER ]; then
server_name=notmuch-test-suite-$$
--
1.7.8.1
Peace
--
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] vim plugin rewrite II
On Sat, 14 Jan 2012 22:15:07 -0400, David Bremner da...@tethera.net wrote: On Sat, 14 Jan 2012 08:54:43 +0100, an...@khirnov.net wrote: The advantages over current vim client are still the following: * sending and displaying/saving attachments * much better unicode support * tag name and search commands completion * proper representation of the thread structure * easier to extend thanks to python's massive standard library Please comment. Hi Anton; I'm not a vim user, so I probably can't say anything very helpful, but it does sound like some nice improvements. Hopefully one of our vim front-end users can comment a bit more. One thing I wondered about is if your version is still completely synchronous, with the resulting problems dealing with large (say, more than 1 messages) search results? Yes, it's still synchronous. I suppose making it asynchronous shouldn't be all that hard, i just never found enough time and motivation for that (it was never a huge problem here). -- Anton Khirnov ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Output unmodified Content-Type header value for JSON format.
On Sun, 15 Jan 2012 11:52:40 +, David Edmondson d...@dme.org wrote: Technically the IRC discussion was about not including *any* part content in the JSON output, and always using show --format=raw or similar to retrieve desired parts. Currently, notmuch includes part content in the JSON only for text/*, *except* when it's text/html. I assume non-text parts are omitted because binary data is hard to represent in JSON and text/html is omitted because some people don't need it. However, this leads to some peculiar asymmetry in the Emacs code where sometimes it pulls part content out of the JSON and sometimes it retrieves it using show --format=raw. This in turn leads to asymmetry in content encoding handling, since notmuch handles content encoding for parts included in the JSON (and there's no good way around that since JSON is Unicode), but not for parts retrieved as raw. Including the text output in the JSON results in significantly fewer calls to 'notmuch' during the building of a typical `notmuch-show-mode' buffer. Someone with one of those older, crankier computers could easily test how much effect this has by changing `notmuch-show-get-bodypart-content' slightly. Yes. I was mostly reiterating the IRC discussion for Pieter. Since this discussion, I've stabilized on the pre-fetching notion I described in id:20120115003617.gh1...@mit.edu, though I do think we should make this clear in the code: that the rule for whether the JSON includes a content key for a leaf part is internal to the CLI and that consumers should be prepared to use it if it's there and to retrieve the content separately if it's not. This is exactly how the Emacs code happens to work, it just hasn't been codified anywhere. Looking at it this way gives us more flexibility than the current code takes advantage of; for example we could omit content from the JSON if it's over some size threshold since the cost of sending that to a client that doesn't need it is high while the cost of having the client retrieve it for itself is relatively low. The idea discussed on IRC was to remove all part content from the JSON output and to always use show to retrieve it, possibly beefing up show's support for content decoding (and possibly introducing a way to retrieve multiple raw parts at once to avoid re-parsing). This would get the JSON format out of the business of guessing what consumers need, simplify the Emacs code, and normalize content encoding handling. Is there a real problem being solved here? Having a clean structure is nice, except when it's not. The real problem is the asymmetry in encoding handling that started this discussion. Content included in the JSON is re-encoded by the CLI, while content retrieved via raw needs to be re-encoded by the client. OTOH, I don't understand the encoding story for HTML, since the encoding can come from either a header or from the body of the HTML. Does this make it strictly necessary for the client to handle the encoding? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] cli: pick the user's address in a group list as from address
On Sat, 14 Jan 2012 23:49:50 +0200, Jani Nikula j...@nikula.org wrote: Messages received to a group list were not replied to using the from address in the list. Fix it. Signed-off-by: Jani Nikula j...@nikula.org --- Both LGTM. Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fix dependency generation for CLI sources
Previously, the dependency file list was generated before the CLI sources were added to SRCS, so dependency files weren't generated for CLI sources. This moves that code to after the CLI sources are added. --- Makefile.local |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Makefile.local b/Makefile.local index d3bf947..1131dea 100644 --- a/Makefile.local +++ b/Makefile.local @@ -273,10 +273,6 @@ quiet ?= $($(shell echo $1 | sed -e s'/ .*//')) sed 's,'$$(basename $*)'\.o[ :]*,$*.o $@ : ,g' $@. $@; \ rm -f $@. -DEPS := $(SRCS:%.c=.deps/%.d) -DEPS := $(DEPS:%.cc=.deps/%.d) --include $(DEPS) - .PHONY : clean clean: rm -f $(CLEAN); rm -rf .deps @@ -350,3 +346,7 @@ install-desktop: SRCS := $(SRCS) $(notmuch_client_srcs) CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc + +DEPS := $(SRCS:%.c=.deps/%.d) +DEPS := $(DEPS:%.cc=.deps/%.d) +-include $(DEPS) -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fix dependency generation for compat, test, and util
This adds source files in compat, test, and util to SRCS so that the top-level Makefile.local will generate dependency files for them. --- compat/Makefile.local |2 ++ test/Makefile.local |1 + util/Makefile.local |1 + 3 files changed, 4 insertions(+), 0 deletions(-) diff --git a/compat/Makefile.local b/compat/Makefile.local index 504eb71..13f16cd 100644 --- a/compat/Makefile.local +++ b/compat/Makefile.local @@ -12,3 +12,5 @@ endif ifneq ($(HAVE_STRCASESTR),1) notmuch_compat_srcs += $(dir)/strcasestr.c endif + +SRCS := $(SRCS) $(notmuch_compat_srcs) diff --git a/test/Makefile.local b/test/Makefile.local index fa2df73..4a6a4b1 100644 --- a/test/Makefile.local +++ b/test/Makefile.local @@ -28,6 +28,7 @@ test: all test-binaries check: test +SRCS := $(SRCS) $(smtp_dummy_srcs) CLEAN := $(CLEAN) $(dir)/smtp-dummy $(dir)/smtp-dummy.o \ $(dir)/symbol-test $(dir)/symbol-test.o \ $(dir)/arg-test $(dir)/arg-test.o diff --git a/util/Makefile.local b/util/Makefile.local index 26e4c3f..c7cae61 100644 --- a/util/Makefile.local +++ b/util/Makefile.local @@ -10,4 +10,5 @@ libutil_modules := $(libutil_c_srcs:.c=.o) $(dir)/libutil.a: $(libutil_modules) $(call quiet,AR) rcs $@ $^ +SRCS := $(SRCS) $(libutil_c_srcs) CLEAN := $(CLEAN) $(libutil_modules) $(dir)/libutil.a -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 04/10] notmuch-dump: add --format=(notmuch|sup)
Quoth David Bremner on Jan 14 at 9:40 pm: From: David Bremner brem...@debian.org sup is the old format, and remains the default. Each line of the notmuch format is msg_id tag tag...tag where each space seperated token is 'hex-encoded' to remove troubling characters. In particular this format won't have the same problem with e.g. spaces in message-ids or tags; they will be round-trip-able. We definitely need a round-trip-able dump format. Did you consider using JSON to allow for future flexibility (e.g., expansion of what we store in the database) and so we don't have to invent our own encodings? A JSON format wouldn't necessarily be a reason *not* to also have this format, especially considering how shell-script-friendly this is (versus how shell-script-unfriendly JSON is), I'm just curious what trade-offs you're considering. You might want to call this format something more self-descriptive like text or hextext or something in case we do want to expand in the future. sup is probably fine for the legacy format since that's set in stone at this point. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/4] emacs: Use the new JSON reply format.
Hi Dmitry, On Thu, Jan 12, 2012 at 01:33, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: I did not follow the rest of the discussion, so sorry if I missed something obvious. But why can't we render HTML parts in replies the same way we do in notmuch-show (using `mm-display-part')? That should not introduce a w3m.el requirement, would use the same renderer as configured for show and hence would produce consistent output in show and reply. Thanks for the suggestion - I've implemented this now and I think it's definitely the best way to go. New patches coming soon with all the suggested changes. -- Adam Wolfe Gordon ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Partial words on notmuch search?
Hi everybody, I'm using notmuch 0.10.2 from Debian backports with Stefano Zacchiroli's mutt integration (but I've also tried the command line interface). After reading all the docs and a few experiments I don't see how to do searches on partial words. If I missed the fine manual mentioning that I'd be glad to RTFM, just please point me to the right FM :) Thanks, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Emacs: Crypto: How to get automatic encryption?
Hi David, notmuch developers, On Wed, 04 Jan 2012 08:48:43 +, David Edmondson d...@dme.org wrote: On Wed, 04 Jan 2012 08:36:39 +, David Edmondson d...@dme.org wrote: (if (and encrypt (dme:message-determine-encryption)) Oops. `encrypt' is set to `t' earlier if the code decides that I want to encrypt outgoing mail (it's not set for work purposes, in essence). Thanks for your code. It works here too and is much appreciated. [Off topic: I'm working through the mime-security customisation at the moment. As far as I see now mime-security proposes all ultimately trusted keys for signing and does not filter this list of keys with the email address in the From: header. As a mutt user I'm used otherwise: mutt is configurable to only show a key selection menu if there are more than one key which fit the relevant address -- otherwise it uses this only one without further ado.] Ciao; Gregor pgpR2Iu8y58nr.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 04/10] notmuch-dump: add --format=(notmuch|sup)
On Sun, 15 Jan 2012 15:35:11 -0500, Austin Clements amdra...@mit.edu wrote: We definitely need a round-trip-able dump format. Did you consider using JSON to allow for future flexibility (e.g., expansion of what we store in the database) and so we don't have to invent our own encodings? A JSON format wouldn't necessarily be a reason *not* to also have this format, especially considering how shell-script-friendly this is (versus how shell-script-unfriendly JSON is), I'm just curious what trade-offs you're considering. I was looking for something fairly close to what we have, to allow people to migrate their various scripts (e.g. nmbug) to the new format without too much pain. Maybe some small amount of header information at the start of the file would support extensibility, while still being shell script friendly. I'm also not too sure how much overhead the JSON quoting would induce. My tags file is currently about 10M, and on my old laptop takes about 15s to dump. That's a long 15s when I'm trying to sync my mail. For normal backup use, a little more overhead doesn't matter, although the stories of non-linear slowdowns that people report suggest we shouldn't get too cavalier about that. You might want to call this format something more self-descriptive like text or hextext or something in case we do want to expand in the future. sup is probably fine for the legacy format since that's set in stone at this point. yeah, I'm definitely open to better suggestions for a name ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Partial words on notmuch search?
Andrei Popescu andreimpope...@gmail.com writes: After reading all the docs and a few experiments I don't see how to do searches on partial words. If I missed the fine manual mentioning that I'd be glad to RTFM, just please point me to the right FM :) That's OK - I asked the same question once. Use '*'. For example, Obam* should match Obama. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: don't bail out of `run_emacs' too early when missing prereqs
On Sat, 14 Jan 2012 10:09:37 +0100, Pieter Praet pie...@praet.org wrote: When running the Emacs tests in verbose mode, only the first missing prereq is reported because the `run_emacs' function is short-circuited early: pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
On Wed, 28 Dec 2011 08:29:58 +, David Edmondson d...@dme.org wrote: As suggested by j4ni in #notmuch, rename `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and have it behave accordingly. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.
Quoth David Edmondson on Jan 15 at 11:55 am: On Sat, 14 Jan 2012 10:29:31 +0100, Pieter Praet pie...@praet.org wrote: Might I ask, to what key(chord) have you bound this ? Due to its usefulness, I'm inclined to bind it to [SPC], but on second though, that might be a bit on the intense side... C-c= globally. That's clobbered in a couple of major modes, but not enough to bother me so far. Might it make sense to bind this across the notmuch mode maps by default? This would at least make this feature more visible as well as quite useful to people who dedicate an Emacs instance to notmuch. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Don't attempt to colour tags in `notmuch-show-mode'.
On Tue, 27 Dec 2011 16:47:14 +, David Edmondson d...@dme.org wrote: The tags were coloured using text properties. Unfortunately that text (the header line) also has an overlay, which overrides the text properties. There's not point in applying text properties that will never be seen. Pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Quoting HTML-only emails in replies redux
On Sun, 15 Jan 2012 09:26:59 +, David Edmondson d...@dme.org wrote: Given that we're now doing a bunch of work in emacs as part of the reply setup, why not just grab the content of the original message from the show buffer and quote that? The last time that approach was discussed Carl was against it because it moved the emacs UI away from the behaviour of the CLI, but it seems that we're already heading in that direction. I have been watching this patch series with interest, because it seemed that when it landed it would be a good time for me to begin work on a patch to allow notmuch to function like other emacs MUAs in constructing the reply buffer internally to emacs, rather than through notmuch. This allows (at least) three things: - 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 to the list, not also to the original sender. Additionally, I like to reply from my university address if colleagues write to my Gmail one. If a lisp function is generating the replies, it can be made to run a hook allowing users to insert these or other custom behaviors. - The same reasoning as above, applied to signatures. (different ones for different recipients) - There exists at least one emacs package (supercite) which allows customization of the quoting of email replies. This automates the “Firstname” style quotes one sometimes sees, as well as many other possiblities. It defines a way for emacs MUAs to construct reply buffers to cooperate with it, which many of the big emacs MUAs obey (Gnus and Wanderlust certainly do). This is explained in the “hints to MUA authors” section of the supercite manual (distributed with Emacs). So, a +1 from me on this idea, from a different perspective. -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
