Re: [PATCH] test: cli: getting/setting/removing config values
On Sat, 14 Jan 2012 09:57:56 +0100, Pieter Praet wrote: > Full test coverage for getting, setting and removing options in > notmuch(1)'s config file ($NOTMUCH_CONFIG or $HOME/.notmuch-config). > > --- > + > +# FIXME: Not the most robust nor portable solution here... > +# Especially `hostname --domain' may have unwanted effects on > +# some platforms, e.g. setting your hostname to "--domain" ;) > +fallback_name="$(grep $(id -un) /etc/passwd | cut -d ":" -f 5 | cut -d "," > -f 1)" > +fallback_email="$(id -un)@$(hostname).$(hostname --domain)" I'm not sure how portable it is, but maybe dnsdomainname would at least have better failure modes. I also wondered about using getent instead of grep. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Please Update Current GLib Requirements For notmuch: - (glib-2.0 >= 2.14) + (glib-2.0 >= 2.22)
I've just tried to compile notmuch, after having downloaded it a few hours back, via: `git clone git://notmuchmail.org/git/notmuch`. Unfortunately, even though I seem to have all needed dependencies in place, during the build I ran into the following error: lib/query.cc: In function 'int _notmuch_threads_destructor(notmuch_threads_t*)': lib/query.cc:311: error: 'g_array_unref' was not declared in this scope Looking into this 'g_array_unref' function, I found that it should be provided by glib, but it seems that it isn't even defined in any of the header files installed by glib on this system (v2.20.3), although I did find it within /usr/include/glib-2.0/glib/garray.h on a system with a newer version (v2.24.2). Looking into its documentation, I found the following: http://developer.gnome.org/glib/2.31/glib-Arrays.html#g-array-unref And specifically note: "g_array_ref () ... Since 2.22" Now, unless I'm misinterpreting this, it seems to me that the documentation is stating that the function has only been available since glib v2.22... -- Sub --- DO NOT REPLY TO THIS MESSAGE, THIS ADDRESS IS NOT MONITORED
Re: [PATCH] emacs: globally replace non-branching "(if (not ..." with "(unless ..."
On Sat, 14 Jan 2012 10:14:57 +0100, Pieter Praet wrote: > On Fri, 13 Jan 2012 08:23:55 +, David Edmondson wrote: > > On Thu, 12 Jan 2012 18:33:06 +0100, Pieter Praet wrote: > > > Less code, same results, without sacrificing readability. > > > > +1, but why not replace non-branching `if' with `when' as well? > > I was planning to do that when the `unless' patch was accepted, ^^ submit > but after reading Xavier and Tomi's replies, I've changed my mind. I hadn't, though... > > Looking at "subr.el", it's actually more efficient to use `if' > (implemented in C) instead of `when' (a macro, which essentially > runs "if conf (progn ...)". > > The amount of non-branching "(if COND (progn ..." statements is very > limited though, so if inclined to "fix" them nonetheless, a patch > follows (relative to the previous one!). > > > Peace > > -- > Pieter Typsos FTW! -- Pieter ___ 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 Tue, 10 Jan 2012 22:15:02 +0200, Jani Nikula wrote: > I don't feel qualified to review, Allow me to disagree: your feeling and reality appear to be disjoint ATM :) Peace -- Pieter ___ 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 wrote: > As suggested by j4ni in #notmuch, rename > `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and > have it behave accordingly. > > Consider `message-mode' buffers to be of interest. > --- > emacs/notmuch.el | 42 ++ > 1 files changed, 30 insertions(+), 12 deletions(-) > > diff --git a/emacs/notmuch.el b/emacs/notmuch.el > index c678c93..6a44d49 100644 > --- a/emacs/notmuch.el > +++ b/emacs/notmuch.el > @@ -1055,21 +1055,39 @@ current search results AND that are tagged with the > given tag." >(interactive) >(notmuch-hello)) > > +(defun notmuch-interesting-buffer (b) > + "Is the current buffer of interest to a notmuch user?" > + (with-current-buffer b > +(memq major-mode '(notmuch-show-mode > +notmuch-search-mode > +notmuch-hello-mode > +message-mode > + > ;;;###autoload > -(defun notmuch-jump-to-recent-buffer () > - "Jump to the most recent notmuch buffer (search, show or hello). > +(defun notmuch-cycle-notmuch-buffers () > + "Cycle through any existing notmuch buffers (search, show or hello). > > -If no recent buffer is found, run `notmuch'." > +If the current buffer is the only notmuch buffer, bury it. If no > +notmuch buffers exist, run `notmuch'." >(interactive) > - (let ((last > - (loop for buffer in (buffer-list) > -if (with-current-buffer buffer > - (memq major-mode '(notmuch-show-mode > -notmuch-search-mode > -notmuch-hello-mode))) > -return buffer))) > -(if last > - (switch-to-buffer last) > + > + (let (start first) > +;; If the current buffer is a notmuch buffer, remember it and then > +;; bury it. > +(when (notmuch-interesting-buffer (current-buffer)) > + (setq start (current-buffer)) > + (bury-buffer)) > + > +;; Find the first notmuch buffer. > +(setq first (loop for buffer in (buffer-list) > + if (notmuch-interesting-buffer buffer) > + return buffer)) > + > +(if first > + ;; If the first one we found is any other than the starting > + ;; buffer, switch to it. > + (unless (eq first start) > + (switch-to-buffer first)) >(notmuch > > (setq mail-user-agent 'notmuch-user-agent) > -- > 1.7.7.3 Signed-off-by: Pieter Praet ! 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... Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Output unmodified Content-Type header value for JSON format.
On Thu, 12 Jan 2012 12:28:40 -0500, Austin Clements wrote: > Quoth Pieter Praet on Jan 12 at 6:07 pm: > > On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements > > wrote: > > > Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm: > > > > The open question seems to be how we handle the content encoding > > > > parameters. My argument is that those should either be used by notmuch > > > > to properly encode the content for the consumer. If that's not > > > > possible, then just those parameters needed by the consumer to decode > > > > the content should be output. > > > > > > If notmuch is going to include part content in the JSON output (which > > > perhaps it shouldn't, as per recent IRC discussions), then it must > > > handle content encodings because JSON must be Unicode and therefore > > > the content strings in the JSON must be Unicode. > > > > Having missed the IRC discussions: what is the rationale for not > > including (specific types of?) part content in the JSON output ? > > Eg. how about inline attached text/x-patch ? > > 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. > > 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. Full ACK. One concern though (IIUC): Due to the prevalence of retarded MUA's, not outputting 'text/plain' and/or 'text/html' parts is unfortunately all too often equivalent to not outputting anything at all, so wouldn't we, in essence, be reducing `show --format=json' to an ever-so-slightly augmented `search --format=json' ? Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: globally replace non-branching "(if (not ..." with "(unless ..."
On Fri, 13 Jan 2012 16:06:17 +, David Edmondson wrote: > On Thu, 12 Jan 2012 18:33:06 +0100, Pieter Praet wrote: > > Less code, same results, without sacrificing readability. > > Does this change correctly re-indent the line following the if/unless? It does... Or so I thought... I appear to have forgotten to correct the indentation @ `notmuch-hello-insert-tags'. Unfortunately git doesn't provide a way to diff the whitespace itself; (eg. "git diff --word-diff=color --word-diff-regex='[ \t]*'") Setting "color.diff.whitespace" (and perhaps expanding the scope of "core.whitespace") only colorizes *erroneous* whitespace... Does this really warrant a v2, or might we simply leave it as yet another victim for Tomi's uncrustify-for-elisp [1] ? Peace -- Pieter [1] id:"yf639bkexs3@taco2.nixu.fi" ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: globally replace non-branching "(if COND (progn ..." with "(when ..."
Less code, same results, without sacrificing readability. --- emacs/notmuch-show.el | 20 +--- emacs/notmuch-wash.el | 47 +++ emacs/notmuch.el | 28 +--- 3 files changed, 45 insertions(+), 50 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 0cbf354..1e190ae 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1226,11 +1226,10 @@ any effects from previous calls to ;; If a small number of lines from the previous message are ;; visible, realign so that the top of the current message is at ;; the top of the screen. - (if (<= (count-screen-lines (window-start) start-of-message) - next-screen-context-lines) - (progn - (goto-char (notmuch-show-message-top)) - (notmuch-show-message-adjust))) + (when (<= (count-screen-lines (window-start) start-of-message) + next-screen-context-lines) + (goto-char (notmuch-show-message-top)) + (notmuch-show-message-adjust)) ;; Move to the top left of the window. (goto-char (window-start))) (t @@ -1423,12 +1422,11 @@ argument, hide all of the messages." ;; Move to the next item in the search results, if any. (let ((parent-buffer notmuch-show-parent-buffer)) (notmuch-kill-this-buffer) -(if parent-buffer - (progn - (switch-to-buffer parent-buffer) - (forward-line) - (if show-next - (notmuch-search-show-thread)) +(when parent-buffer + (switch-to-buffer parent-buffer) + (forward-line) + (if show-next + (notmuch-search-show-thread) (defun notmuch-show-archive-thread () "Archive each message in thread, then show next thread from search. diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 5c1e830..67143e5 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -336,30 +336,29 @@ patch and then guesses the extent of the patch, there is scope for error." (goto-char (point-min)) - (if (re-search-forward diff-file-header-re nil t) - (progn - (beginning-of-line -1) - (let ((patch-start (point)) - (patch-end (point-max)) - part) - (goto-char patch-start) - (if (or - ;; Patch ends with signature. - (re-search-forward notmuch-wash-signature-regexp nil t) - ;; Patch ends with bugtraq comment. - (re-search-forward "^\\*\\*\\* " nil t)) - (setq patch-end (match-beginning 0))) - (save-restriction - (narrow-to-region patch-start patch-end) - (setq part (plist-put part :content-type "inline-patch-fake-part")) - (setq part (plist-put part :content (buffer-string))) - (setq part (plist-put part :id -1)) - (setq part (plist-put part :filename - (notmuch-wash-subject-to-patch-filename - (plist-get - (plist-get msg :headers) :Subject - (delete-region (point-min) (point-max)) - (notmuch-show-insert-bodypart nil part depth)) + (when (re-search-forward diff-file-header-re nil t) +(beginning-of-line -1) +(let ((patch-start (point)) + (patch-end (point-max)) + part) + (goto-char patch-start) + (if (or + ;; Patch ends with signature. + (re-search-forward notmuch-wash-signature-regexp nil t) + ;; Patch ends with bugtraq comment. + (re-search-forward "^\\*\\*\\* " nil t)) + (setq patch-end (match-beginning 0))) + (save-restriction + (narrow-to-region patch-start patch-end) + (setq part (plist-put part :content-type "inline-patch-fake-part")) + (setq part (plist-put part :content (buffer-string))) + (setq part (plist-put part :id -1)) + (setq part (plist-put part :filename + (notmuch-wash-subject-to-patch-filename + (plist-get + (plist-get msg :headers) :Subject + (delete-region (point-min) (point-max)) + (notmuch-show-insert-bodypart nil part depth) ;; diff --git a/emacs/notmuch.el b/emacs/notmuch.el index ba84494..0d37a74 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -631,17 +631,16 @@ This function advances the next thread when finished." (goto-char (point-max)) (if (eq status 'signal) (insert "Incomplete search results (search process was killed).\n")) - (if (eq status 'exit) - (progn - (if notmuch-search-process-filter-data - (insert (concat "Error: Unexpected output from notmuch search:\n" notmuch-search-process-filter-data))) - (insert
Re: [PATCH] emacs: globally replace non-branching "(if (not ..." with "(unless ..."
On Fri, 13 Jan 2012 08:23:55 +, David Edmondson wrote: > On Thu, 12 Jan 2012 18:33:06 +0100, Pieter Praet wrote: > > Less code, same results, without sacrificing readability. > > +1, but why not replace non-branching `if' with `when' as well? I was planning to do that when the `unless' patch was accepted, but after reading Xavier and Tomi's replies, I've changed my mind. Looking at "subr.el", it's actually more efficient to use `if' (implemented in C) instead of `when' (a macro, which essentially runs "if conf (progn ...)". The amount of non-branching "(if COND (progn ..." statements is very limited though, so if inclined to "fix" them nonetheless, a patch follows (relative to the previous one!). Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: don't bail out of `run_emacs' too early when missing prereqs
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).
---
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 Thu, 12 Jan 2012 21:34:29 +0400, Dmitry Kurochkin
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?
> [...] 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: [PATCH v2] emacs: logically group def{custom,face}s
On Fri, 13 Jan 2012 16:15:59 +, David Edmondson wrote: > On Thu, 12 Jan 2012 23:31:34 -0400, David Bremner wrote: > > On Thu, 12 Jan 2012 18:12:16 +0100, Pieter Praet wrote: > > > To allow for expansion whilst keeping everything tidy and organized, > > > move all defcustom/defface variables to the following subgroups, > > > defined in notmuch-lib.el: > > > > > > - Hello > > > - Search > > > - Show > > > - Send > > > - Crypto > > > - Hooks > > > - Appearance > > > - External Commands > > > > I didn't investigate too closely, but I noticed when I customize-group > > emacs, each subgroup has some explanatory text beside it. Did you omit > > that on purpose? > > That should be a requirement, I think. I agree; But for ~every rule, there are exceptions :) Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: logically group def{custom,face}s
To allow for expansion whilst keeping everything tidy and organized,
move all defcustom/defface variables to the following subgroups,
defined in notmuch-lib.el:
- Hello
- Search
- Show
- Send
- Crypto
- Hooks
- External Commands
- Appearance
As an added benefit, defcustom keyword args are now consistently
in order of appearance @ defcustom's docstring (OCD much?).
---
emacs/notmuch-address.el |3 +-
emacs/notmuch-crypto.el | 22 +---
emacs/notmuch-hello.el | 34 +--
emacs/notmuch-lib.el | 45 -
emacs/notmuch-maildir-fcc.el |6 ++--
emacs/notmuch-message.el |2 +-
emacs/notmuch-mua.el | 21 ++-
emacs/notmuch-show.el| 33 +++--
emacs/notmuch.el | 35
9 files changed, 132 insertions(+), 69 deletions(-)
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 8eba7a0..2e8b840 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -28,7 +28,8 @@
single argument and output a list of possible matches, one per
line."
:type 'string
- :group 'notmuch)
+ :group 'notmuch-send
+ :group 'notmuch-external)
(defvar notmuch-address-message-alist-member
'("^\\(Resent-\\)?\\(To\\|B?Cc\\|Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):"
diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
index ac30098..232c1a0 100644
--- a/emacs/notmuch-crypto.el
+++ b/emacs/notmuch-crypto.el
@@ -34,38 +34,44 @@ The effect of setting this variable can be seen temporarily
by
providing a prefix when viewing a signed or encrypted message, or
by providing a prefix when reloading the message in notmuch-show
mode."
- :group 'notmuch
- :type 'boolean)
+ :type 'boolean
+ :group 'notmuch-crypto)
(defface notmuch-crypto-part-header
'((t (:foreground "blue")))
"Face used for crypto parts headers."
- :group 'notmuch)
+ :group 'notmuch-crypto
+ :group 'notmuch-appearance)
(defface notmuch-crypto-signature-good
'((t (:background "green" :foreground "black")))
"Face used for good signatures."
- :group 'notmuch)
+ :group 'notmuch-crypto
+ :group 'notmuch-appearance)
(defface notmuch-crypto-signature-good-key
'((t (:background "orange" :foreground "black")))
"Face used for good signatures."
- :group 'notmuch)
+ :group 'notmuch-crypto
+ :group 'notmuch-appearance)
(defface notmuch-crypto-signature-bad
'((t (:background "red" :foreground "black")))
"Face used for bad signatures."
- :group 'notmuch)
+ :group 'notmuch-crypto
+ :group 'notmuch-appearance)
(defface notmuch-crypto-signature-unknown
'((t (:background "red" :foreground "black")))
"Face used for signatures of unknown status."
- :group 'notmuch)
+ :group 'notmuch-crypto
+ :group 'notmuch-appearance)
(defface notmuch-crypto-decryption
'((t (:background "purple" :foreground "black")))
"Face used for encryption/decryption status messages."
- :group 'notmuch)
+ :group 'notmuch-crypto
+ :group 'notmuch-appearance)
(define-button-type 'notmuch-crypto-status-button-type
'action (lambda (button) (message (button-get button 'help-echo)))
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 02017ce..2493a26 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -35,12 +35,12 @@
(defcustom notmuch-recent-searches-max 10
"The number of recent searches to store and display."
:type 'integer
- :group 'notmuch)
+ :group 'notmuch-hello)
(defcustom notmuch-show-empty-saved-searches nil
"Should saved searches with no messages be listed?"
:type 'boolean
- :group 'notmuch)
+ :group 'notmuch-hello)
(defun notmuch-sort-saved-searches (alist)
"Generate an alphabetically sorted saved searches alist."
@@ -60,7 +60,7 @@ alist to be used."
(const :tag "Sort alphabetically" notmuch-sort-saved-searches)
(function :tag "Custom sort function"
:value notmuch-sort-saved-searches))
- :group 'notmuch)
+ :group 'notmuch-hello)
(defvar notmuch-hello-indent 4
"How much to indent non-headers.")
@@ -68,12 +68,13 @@ alist to be used."
(defcustom notmuch-show-logo t
"Should the notmuch logo be shown?"
:type 'boolean
- :group 'notmuch)
+ :group 'notmuch-hello
+ :group 'notmuch-appearance)
(defcustom notmuch-show-all-tags-list nil
"Should all tags be shown in the notmuch-hello view?"
:type 'boolean
- :group 'notmuch)
+ :group 'notmuch-hello)
(defcustom notmuch-hello-tag-list-make-query nil
"Function or string to generate queries for the all tags list.
@@ -89,12 +90,12 @@ should return a filter for that tag, or nil to hide the
tag."
(string :tag "Custom filter"
:value "tag:unread")
(function :tag "Custom filter function"))
- :group 'notmuch)
+ :group 'notmuc
Re: [PATCH v2] emacs: logically group def{custom,face}s
On Thu, 12 Jan 2012 23:31:34 -0400, David Bremner wrote: > On Thu, 12 Jan 2012 18:12:16 +0100, Pieter Praet wrote: > > To allow for expansion whilst keeping everything tidy and organized, > > move all defcustom/defface variables to the following subgroups, > > defined in notmuch-lib.el: > > > > - Hello > > - Search > > - Show > > - Send > > - Crypto > > - Hooks > > - Appearance > > - External Commands > > I didn't investigate too closely, but I noticed when I customize-group > emacs, each subgroup has some explanatory text beside it. Did you omit > that on purpose? > That is correct. Coming up with decent docstrings is hard :) Also, the group names are fairly descriptive in and of themselves IMO. Anyways, I've given it a shot, but (I hope!) people will come up with much better descriptions, so this probably isn't the end of it... Patch follows. > d Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] NEWS: fix some old typos and trailing whitespace
On Thu, 12 Jan 2012 23:11:35 -0400, David Bremner wrote: > On Thu, 12 Jan 2012 18:06:14 +0100, Pieter Praet wrote: > > That would indeed have been the most sensible thing to do. > > > > Could someone (who -unlike me- has already submitted his/her public SSH > > key for commit access) add something along those lines to the Patch > > Formatting guidelines [1] ? Perhaps just quote Carl's statement [2] ? > > > > Hi Pieter; > > It's a wiki, anyone can push. > Oh, I wasn't aware of this. (changed recently?) http://notmuchmail.org/patchformatting/ has been amended! > d Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] Output unmodified Content-Type header value for JSON format.
On Thu, 12 Jan 2012 23:16:29 -0400, David Bremner wrote: > On Thu, 12 Jan 2012 18:08:08 +0100, Pieter Praet wrote: > > > > - The previous point is a bit of a counterargument to this, but in > > > > I couls separate it. I made is a single patch to avoid having a > > > revision with broken emacs UI (and tests). > > > > > > I'd like to propose to always apply patch series on a *topic* branch > > which would then be merged back into 'master', thus avoiding this issue > > altogether whilst making it more obvious which patches belong together > > (eg. for easier cross-referencing with the ML). > > Hi Pieter; > > Sorry, I must have lost the thread somewhere. What application are you > thinking about, and what issue do you think that topic branches avoid? > No specific application; In the case of patch series, it may occur that an individual commit leaves the code in a broken state. One might argue that devs need to ensure that the project builds cleanly at every commit, but this can be prohibitively time-consuming or even simply impossible due to the need to keep changes atomic and area-specific (eg. changes to the binary and the Emacs UI should be separate commits irrespective of their relation). So it would make sense to consistently apply (certain, or perhaps all?) patch series on an ad-hoc branch which would then be merged back into 'master', instead of being directly applied on 'master'. Aside from preventing broken builds (as was Dmitry's reason to consolidate a series touching on multiple distinct "spheres" of the code into a single patch), series of related commits would also be clearly delineated/clustered, facilitating source archaeology. (and all without making the commit log exude the odor of entropy incarnate) > d > Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: cli: getting/setting/removing config values
Full test coverage for getting, setting and removing options in
notmuch(1)'s config file ($NOTMUCH_CONFIG or $HOME/.notmuch-config).
---
Please *do* take note of the FIXME in the last test!
test/config | 88 +
test/notmuch-test |1 +
2 files changed, 89 insertions(+), 0 deletions(-)
create mode 100755 test/config
diff --git a/test/config b/test/config
new file mode 100755
index 000..ee3126c
--- /dev/null
+++ b/test/config
@@ -0,0 +1,88 @@
+#!/usr/bin/env bash
+test_description='notmuch config'
+. ./test-lib.sh
+
+
+config_options=(
+"database.path"
+"user.name"
+"user.primary_email"
+"user.other_email"
+"new.tags"
+"maildir.synchronize_flags"
+)
+
+
+test_begin_subtest 'getting config: "config get ."'
+echo -n "" > OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get "${i}"
+done >> OUTPUT
+cat >EXPECTED <. [values ...]"'
+notmuch config set database.path /path/to/maildir
+notmuch config set user.name "User Name"
+notmuch config set user.primary_email primary_em...@notmuchmail.org
+notmuch config set user.other_email a...@notmuchmail.org a...@notmuchmail.org
+notmuch config set new.tags tag1 tag2 tag3
+notmuch config set maildir.synchronize_flags false
+echo -n "" > OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get "${i}"
+done >> OUTPUT
+cat >EXPECTED <."'
+notmuch config set database.path
+notmuch config set user.name
+notmuch config set user.primary_email
+notmuch config set user.other_email
+notmuch config set new.tags
+notmuch config set maildir.synchronize_flags
+echo -n "" > OUTPUT
+for i in ${config_options[*]} ; do
+notmuch config get "${i}"
+done >> OUTPUT
+
+# FIXME: Not the most robust nor portable solution here...
+# Especially `hostname --domain' may have unwanted effects on
+# some platforms, e.g. setting your hostname to "--domain" ;)
+fallback_name="$(grep $(id -un) /etc/passwd | cut -d ":" -f 5 | cut -d "," -f
1)"
+fallback_email="$(id -un)@$(hostname).$(hostname --domain)"
+
+cat >EXPECTED
Re: [PATCH] test: cli: getting/setting/removing config values
On Thu, 12 Jan 2012 23:42:04 -0400, David Bremner wrote: > On Thu, 12 Jan 2012 18:30:01 +0100, Pieter Praet wrote: > > Should have come before commit 1df71b55 > > This doesn't seem like an especially helpful commit > message. Editorializing is ok, I guess, but maybe keep it below the > '---' ? > You're right. The message I was trying to convey (quite tersely), was that these tests were written in response to commit 1df71b55 (and should probably be retroactively ran on 1df71b55~1). I realize now that it could potentially be wrongly interpreted as criticism of sorts, which of course wasn't my intention. Anyways, I ran the tests on both 1df71b55~1 and 1df71b55, and -as expected- everything checks out fine. Amended patch follows. > d Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: revised patch for gmime init, with test.
On Fri, 13 Jan 2012 05:05:35 -0400, David Bremner wrote:
> On Thu, 12 Jan 2012 23:46:46 -0400, David Bremner wrote:
> > On Thu, 12 Jan 2012 18:25:38 +0100, Pieter Praet wrote:
> > > On Sat, 31 Dec 2011 23:22:46 -0400, David Bremner
> > > wrote:
> >
> > > with differing hashes), this has the potential of causing confusion
> > > and/or quite some extra work when debugging using git-bisect(1), so
> > > I'd like to propose that bugfixes for (to-be-)released code are only
> > > applied on the 'maint' branch ('release' in the case of Notmuch),
> > > and then immediately merged back into 'master'. In fact, this would
> > > preferrably happen after *every* (series of) commit(s) on the 'maint'
> > > branch, to prevent issues like [1].
> >
> > There is some merit it to this. On the other hand, it makes the history
> > messier. [1] would have also been prevented by making the patch against
> > the right branch.
>
> I thought about this a bit more, and I agree that at least the release
> candidates (basically anything tagged on branch release) ought to be
> merged back to master. Since any series of bugfix patches seems to be
> cause for a new release candidate, this should avoid the need to have
> doubly applied patches.
>
Thanks!
> I'm less convinced about the need to merge every little doc change and
> debian packaging change back to master right away. This might be a
> purely aesthetic objection; [...]
See my previous reply [1].
> [...] I'm not sure if the extra merge commits
> cause any problems for e.g. bisection.
>
Infrequent merging increases the possibility of bugs due to unforeseen
interactions between commits on different branches, which is likely to
require one to do a multitude of fake merges (`git merge --no-commit')
in order to properly track down the offending commit, so... frequent
merging would actually *prevent* issues when bisecting.
> d
Peace
--
Pieter
[1] id:"878vlar7ka@praet.org"
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: revised patch for gmime init, with test.
On Thu, 12 Jan 2012 23:46:46 -0400, David Bremner wrote:
> On Thu, 12 Jan 2012 18:25:38 +0100, Pieter Praet wrote:
> > On Sat, 31 Dec 2011 23:22:46 -0400, David Bremner wrote:
>
> > with differing hashes), this has the potential of causing confusion
> > and/or quite some extra work when debugging using git-bisect(1), so
> > I'd like to propose that bugfixes for (to-be-)released code are only
> > applied on the 'maint' branch ('release' in the case of Notmuch),
> > and then immediately merged back into 'master'. In fact, this would
> > preferrably happen after *every* (series of) commit(s) on the 'maint'
> > branch, to prevent issues like [1].
>
> There is some merit it to this. On the other hand, it makes the history
> messier. [...]
This *can* get rather messy when interlacing the 'master'/'maint' merges
with non-rebased changesets pulled from other repos (most often aren't
rebased in advance since they've already been published), which is a
common occurence in the magit [1] repo.
But take Org-mode [2] for example (which is an *extremely* active project),
where non-rebased changesets are rare(ish), and where the 'maint' branch
is constantly being merged back into 'master', resulting in a very clean
ladder-like commit log, eg. :
--******---**---*---*--- master
\ / / \
*---*---*-*---*--- maint
0.11 bugfix NEWSbugfix 0.12~rc1
> [...] [1] would have also been prevented by making the patch against
> the right branch.
>
True, but if we can obviate the need to check if we're on the right
branch altogether, without causing any unwanted side-effects, wouldn't
it be counterproductive not to?
Peace
--
Pieter
[1] git://github.com/magit/magit.git
[2] git://orgmode.org/org-mode.git
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] vim plugin rewrite II
Hi,
this is a followup to my mail from spring where i presented a partial
rewrite of the vim plugin using python. There weren't many comments back
then, so I hope there will be more now.
I've changed the filenames so my version now coexists with the current
vim plugin. You can find it in
git://git.khirnov.net/git/notmuch
branch vim. Simply copy vim/plugin/{nm_vim.py,notmuch-vimpy.vim} to the
vim plugins dir and vim/syntax/{nm_vimpy*} to the vim syntax dir and run
:NMVimpy() in vim. You'll need vim with python support and
python-notmuch bindings.
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.
--
Anton Khirnov
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
