[PATCH] emacs: Put notmuch-print-mechanism in custom group notmuch-show
--- emacs/notmuch-print.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el index 6653d97..8c18f4b 100644 --- a/emacs/notmuch-print.el +++ b/emacs/notmuch-print.el @@ -25,7 +25,7 @@ (defcustom notmuch-print-mechanism 'notmuch-print-lpr "How should printing be done?" - :group 'notmuch + :group 'notmuch-show :type '(choice (function :tag "Use lpr" notmuch-print-lpr) (function :tag "Use ps-print" notmuch-print-ps-print) -- 1.7.9.1
[PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello
--- emacs/notmuch-hello.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 71d37b8..f10d98d 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -226,7 +226,7 @@ by an additional filter query. Similarly, the count of messages displayed next to the buttons can be generated by applying a different filter to the tag query. These filters are also supported for \"Customized queries section\" items." - :group 'notmuch + :group 'notmuch-hello :type '(repeat (choice (function-item notmuch-hello-insert-header) -- 1.7.9.1
[PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred "deleted" tag name.
On Sun, Apr 15 2012, Tomi Ollila wrote: > id:"1326826969-23545-1-git-send-email-jrollins at finestructure.net" > > Does just "delete" -> "deleted" change: the only question I have left > is that should that be left as is, this change made, or just drop > the "delete" coloring altogether ? Sorry, yes, I suppose this patch should still be applied. Excludes for "deleted" are the default, I believe, so if we are going to refer to it in documentation we should probably be consistent. On Sun, Apr 15 2012, Jameson Graef Rollins wrote: > On Sun, Apr 15 2012, Mark Walters wrote: >> I think the rest of the series (which provides keybindings for >> adding/removing the delete tag to messages/threads) is worthwhile >> particularly now the exclude stuff is fairly complete (feedback at the >> time looked positive). > > Sorry, I wish I could have purged all of these series from the list. > After a very protracted discussion on the topic it was decided that > notmuch will not support any delete tagging operations. Users who wish > to do so can add support on their own: I think my reaction here was a little strong. I'm not remembering how I got the impression that there was more opposition to adding delete keybindings than there was support. I suppose now that excludes work so well one (not me) might consider revisiting the issue. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120415/d937054f/attachment.pgp>
some stale patches dropped from the review queue
Sorry, I'm out of touch with nmbug at the moment. I'll try to get reacquainted. In the mean time... > id:1325986015-22510-3-git-send-email-jrollins at finestructure.net > id:1325986015-22510-4-git-send-email-jrollins at finestructure.net > id:1325986015-22510-5-git-send-email-jrollins at finestructure.net This series is definitely obsolete. > Obsolete - AFAICT there was a more recent version of each of these > posted: > > id:1333149350-22616-2-git-send-email-novalazy at gmail.com > id:1333149350-22616-3-git-send-email-novalazy at gmail.com > id:1333149350-22616-4-git-send-email-novalazy at gmail.com > id:1333149350-22616-5-git-send-email-novalazy at gmail.com > id:1333149350-22616-6-git-send-email-novalazy at gmail.com This series is obsoleted by a later version: id:"1334367666-10954-1-git-send-email-novalazy at gmail.com" > id:1333845338-22960-2-git-send-email-jrollins at finestructure.net > id:1333845338-22960-3-git-send-email-jrollins at finestructure.net > id:1333845338-22960-4-git-send-email-jrollins at finestructure.net > id:1333845338-22960-5-git-send-email-jrollins at finestructure.net > id:1333845338-22960-6-git-send-email-jrollins at finestructure.net > id:1333845338-22960-7-git-send-email-jrollins at finestructure.net > id:1333845338-22960-8-git-send-email-jrollins at finestructure.net > id:1333845338-22960-9-git-send-email-jrollins at finestructure.net This series is obsoleted by a later version: id:"1334429574-12918-1-git-send-email-jrollins at finestructure.net" jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120415/8cc37493/attachment.pgp>
[PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred "deleted" tag name.
On Sun, Apr 15 2012, Mark Walters wrote: > On Tue, 17 Jan 2012, Jameson Graef Rollins > wrote: >> No functional change here. The help message previously referred to >> the "delete" tag, but "deleted" is now preferred, so hopefully this >> will reduce any potential confusion. > > This patch is trivially correct regardless of the rest of the > series. Agreed. +1 > > I think the rest of the series (which provides keybindings for > adding/removing the delete tag to messages/threads) is worthwhile > particularly now the exclude stuff is fairly complete (feedback at the > time looked positive). > > Patch 2/3 needs simple but genuine rebasing as the names of the > tagging functions have changed though. Why not :) > > Best wishes > > Mark Tomi > >> --- >> emacs/notmuch.el |4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/emacs/notmuch.el b/emacs/notmuch.el >> index e4bca51..67ecd3a 100644 >> --- a/emacs/notmuch.el >> +++ b/emacs/notmuch.el >> @@ -660,12 +660,12 @@ This function advances the next thread when finished." >> Here is an example of how to color search results based on tags. >> (the following text would be placed in your ~/.emacs file): >> >> - (setq notmuch-search-line-faces '((\"delete\" . (:foreground \"red\" >> + (setq notmuch-search-line-faces '((\"deleted\" . (:foreground \"red\" >>:background \"blue\")) >> (\"unread\" . (:foreground \"green\" >> >> The attributes defined for matching tags are merged, with later >> -attributes overriding earlier. A message having both \"delete\" >> +attributes overriding earlier. A message having both \"deleted\" >> and \"unread\" tags with the above settings would have a green >> foreground and blue background." >>:type '(alist :key-type (string) :value-type (custom-face-edit)) >> -- >> 1.7.7.3 >> >> ___ >> notmuch mailing list >> notmuch at notmuchmail.org >> http://notmuchmail.org/mailman/listinfo/notmuch > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: Don't move to the next thread unless the cursor is at the end of the buffer.
On Sun, Apr 15 2012, Mark Walters wrote: > On Tue, 31 Jan 2012, David Edmondson wrote: >> When using the spacebar to scroll through a thread, hitting 'space' >> when the bottom of the last message is visible should take the cursor >> to the end of the buffer rather than immediately archiving the thread >> and moving to the next thread. > > Hi > > This patch looks good to me; (but if people prefer the current behaviour then > can we mark this notmuch::wontfix so it leaves the review queue) I would definitely like to see this patch applied. Less surprising as there is no indication we have reached the bottom of the buffer. > Best wishes > > Mark Tomi > >> --- >> emacs/notmuch-show.el |5 + >> 1 files changed, 5 insertions(+), 0 deletions(-) >> >> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el >> index ec72ff8..3f54de0 100644 >> --- a/emacs/notmuch-show.el >> +++ b/emacs/notmuch-show.el >> @@ -1319,6 +1319,11 @@ current window), advance to the next open message." >>;; This is not the last message - move to the next visible one. >>(notmuch-show-next-open-message)) >> >> + ((not (= (point) (point-max))) >> + ;; This is the last message, but the cursor is not at the end of >> + ;; the buffer. Move it there. >> + (goto-char (point-max))) >> + >> (t >>;; This is the last message - change the return value >>(setq ret t))) >> -- >> 1.7.8.3 >> >> ___ >> notmuch mailing list >> notmuch at notmuchmail.org >> http://notmuchmail.org/mailman/listinfo/notmuch > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[No Subject]
On Sun, Apr 15 2012, Jameson Graef Rollins wrote: > A previous patch [0] replaced blank subject lines with '[No Subject]' > in search and show mode. Apparently this was needed to circumvent > some bug in the printing code, but there was no need for it search or > show, and it is definitely not desirable, so we undo it here (a revert > is no longer feasible). We should not be modifying strings in the > original message without good reason, or without a clear indication > that we are doing so, neither of which apply in this case. For > further discussion see [0]. > > [0] id:"1327918561-16245-3-git-send-email-dme at dme.org" > --- I agree. LGTM. Tomi > Sorry, there was a small bug in the previous version (notmuch-print.el > was mistakenly modified). > > emacs/notmuch-show.el |5 + > emacs/notmuch.el |5 ++--- > 2 files changed, 3 insertions(+), 7 deletions(-) > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el > index 30b26d1..1e55099 100644 > --- a/emacs/notmuch-show.el > +++ b/emacs/notmuch-show.el > @@ -1075,7 +1075,7 @@ function is used." >(run-hooks 'notmuch-show-hook)) > > ;; Set the header line to the subject of the first message. > -(setq header-line-format (notmuch-show-strip-re > (notmuch-show-get-pretty-subject) > +(setq header-line-format (notmuch-show-strip-re > (notmuch-show-get-subject) > > (defun notmuch-show-capture-state () >"Capture the state of the current buffer. > @@ -1375,9 +1375,6 @@ current thread." > (defun notmuch-show-get-depth () >(notmuch-show-get-prop :depth)) > > -(defun notmuch-show-get-pretty-subject () > - (notmuch-prettify-subject (notmuch-show-get-subject))) > - > (defun notmuch-show-set-tags (tags) >"Set the tags of the current message." >(notmuch-show-set-prop :tags tags) > diff --git a/emacs/notmuch.el b/emacs/notmuch.el > index ba833e6..326645d 100644 > --- a/emacs/notmuch.el > +++ b/emacs/notmuch.el > @@ -507,7 +507,7 @@ Complete list of currently available key bindings: >"Display the currently selected thread." >(interactive) >(let ((thread-id (notmuch-search-find-thread-id)) > - (subject (notmuch-prettify-subject (notmuch-search-find-subject > + (subject (notmuch-search-find-subject))) > (if (> (length thread-id) 0) > (notmuch-show thread-id > (current-buffer) > @@ -877,8 +877,7 @@ non-authors is found, assume that all of the authors > match." > ;; We currently just throw away excluded matches. > (unless (eq (aref count 1) ?0) > (let ((beg (point))) > - (notmuch-search-show-result date count authors > - (notmuch-prettify-subject > subject) tags) > + (notmuch-search-show-result date count authors > subject tags) > (notmuch-search-color-line beg (point) tag-list) > (put-text-property beg (point) > 'notmuch-search-thread-id thread-id) > (put-text-property beg (point) > 'notmuch-search-authors authors) > -- > 1.7.9.5 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines
On Fri, 17 Feb 2012, Daniel Schoepe wrote: > This introduces a variable to control after how many characters a line > is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the > window width if it is lower). Hi This looks ok but I wonder if slightly different behaviour might be preferable (and looks simple to implement): rather then always wrapping at min of notmuch-wash-wrap-lines-length and window-width wrap at min of (notmuch-wash-wrap-lines-length + depth) and window-width. Then if you have a wide buffer you can still get 80 chars (say) of useful text even for well nested messages whilst not having very long lines anywhere. Best wishes Mark > --- > emacs/notmuch-wash.el | 36 ++-- > 1 files changed, 26 insertions(+), 10 deletions(-) > > diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el > index 56981d0..7d003a2 100644 > --- a/emacs/notmuch-wash.el > +++ b/emacs/notmuch-wash.el > @@ -87,6 +87,14 @@ If there is one more line than the sum of > `notmuch-wash-citation-lines-suffix', show that, otherwise > collapse the remaining lines into a button.") > > +(defvar notmuch-wash-wrap-lines-length nil > + "Wrap line after at most this many characters. > + > +If this is nil, lines in messages will be wrapped to fit in the > +current window. If this is a number, lines will be wrapped after > +this many characters or at the window width (whichever one is > +lower).") > + > (defun notmuch-wash-toggle-invisible-action (cite-button) >(let ((invis-spec (button-get cite-button 'invisibility-spec))) > (if (invisible-p invis-spec) > @@ -276,16 +284,24 @@ Perform several transformations on the message body: > ;; > > (defun notmuch-wash-wrap-long-lines (msg depth) > - "Wrap any long lines in the message to the width of the window. > - > -When doing so, maintaining citation leaders in the wrapped text." > - > - (let ((coolj-wrap-follows-window-size nil) > - (fill-column (- (window-width) > - depth > - ;; 2 to avoid poor interaction with > - ;; `word-wrap'. > - 2))) > + "Wrap long lines in the message. > + > +If `notmuch-wash-wrap-lines-length' is a number, this will wrap > +the message lines to the minimum of the width of the window or > +its value. Otherwise, this function will wrap long lines in the > +message at the window width. When doing so, citation leaders in > +the wrapped text are maintained." > + > + (let* ((coolj-wrap-follows-window-size nil) > + (limit (if (numberp notmuch-wash-wrap-lines-length) > + (min notmuch-wash-wrap-lines-length > + (window-width)) > + (window-width))) > + (fill-column (- limit > + depth > + ;; 2 to avoid poor interaction with > + ;; `word-wrap'. > + 2))) > (coolj-wrap-region (point-min) (point-max > > ;; > -- > 1.7.9 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred "deleted" tag name.
On Tue, 17 Jan 2012, Jameson Graef Rollins wrote: > No functional change here. The help message previously referred to > the "delete" tag, but "deleted" is now preferred, so hopefully this > will reduce any potential confusion. This patch is trivially correct regardless of the rest of the series. I think the rest of the series (which provides keybindings for adding/removing the delete tag to messages/threads) is worthwhile particularly now the exclude stuff is fairly complete (feedback at the time looked positive). Patch 2/3 needs simple but genuine rebasing as the names of the tagging functions have changed though. Best wishes Mark > --- > emacs/notmuch.el |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/emacs/notmuch.el b/emacs/notmuch.el > index e4bca51..67ecd3a 100644 > --- a/emacs/notmuch.el > +++ b/emacs/notmuch.el > @@ -660,12 +660,12 @@ This function advances the next thread when finished." > Here is an example of how to color search results based on tags. > (the following text would be placed in your ~/.emacs file): > > - (setq notmuch-search-line-faces '((\"delete\" . (:foreground \"red\" > + (setq notmuch-search-line-faces '((\"deleted\" . (:foreground \"red\" > :background \"blue\")) > (\"unread\" . (:foreground \"green\" > > The attributes defined for matching tags are merged, with later > -attributes overriding earlier. A message having both \"delete\" > +attributes overriding earlier. A message having both \"deleted\" > and \"unread\" tags with the above settings would have a green > foreground and blue background." >:type '(alist :key-type (string) :value-type (custom-face-edit)) > -- > 1.7.7.3 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: Don't move to the next thread unless the cursor is at the end of the buffer.
On Tue, 31 Jan 2012, David Edmondson wrote: > When using the spacebar to scroll through a thread, hitting 'space' > when the bottom of the last message is visible should take the cursor > to the end of the buffer rather than immediately archiving the thread > and moving to the next thread. Hi This patch looks good to me; (but if people prefer the current behaviour then can we mark this notmuch::wontfix so it leaves the review queue) Best wishes Mark > --- > emacs/notmuch-show.el |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el > index ec72ff8..3f54de0 100644 > --- a/emacs/notmuch-show.el > +++ b/emacs/notmuch-show.el > @@ -1319,6 +1319,11 @@ current window), advance to the next open message." >;; This is not the last message - move to the next visible one. >(notmuch-show-next-open-message)) > > + ((not (= (point) (point-max))) > + ;; This is the last message, but the cursor is not at the end of > + ;; the buffer. Move it there. > + (goto-char (point-max))) > + > (t >;; This is the last message - change the return value >(setq ret t))) > -- > 1.7.8.3 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred "deleted" tag name.
On Sun, Apr 15 2012, Mark Walters wrote: > This patch is trivially correct regardless of the rest of the > series. > > I think the rest of the series (which provides keybindings for > adding/removing the delete tag to messages/threads) is worthwhile > particularly now the exclude stuff is fairly complete (feedback at the > time looked positive). Sorry, I wish I could have purged all of these series from the list. After a very protracted discussion on the topic it was decided that notmuch will not support any delete tagging operations. Users who wish to do so can add support on their own: id:"87sjgk2xzf.fsf at servo.finestructure.net" http://notmuchmail.org/excluding/ I highly recommend *not* re-starting this discussion. There is no solution that will satisfy everyone. Just let it be. Move on. Nothing to see here. These are not the tags you're looking for... jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120415/237d9eec/attachment.pgp>
[PATCH v3 1/4] emacs: Let the user choose where to compose new mails
Jameson Graef Rollins writes: > I think the issues that David was experiencing have to do with flakiness > in emacs's dedicated windows, not in this patch itself. Thomas, Did you have a change to investigate this as proposed in id:"87zke0aifa.fsf at thor.loria.fr"? d
[PATCH 0/6] Finish show rewrite
Austin Clements writes: > The long-awaited and oft-belated conclusion of the show rewrite. All > of the formatters have been converted to the new style, so this series > just rips out unused code and does a little cleanup. > pushed, d
[PATCH v2] Record dependencies during build instead of before
Austin Clements writes: > This patch eliminates the dependency generation rules and instead > generates dependency files as a side-effect of the regular build rule. pushed, d
[PATCH] lib: work around talloc_steal usage from C++ code
Jani Nikula writes: > Implicit typecast from 'void *' to 'T *' is okay in C, but not in > C++. In talloc_steal, an explicit cast is provided for type safety in > some GCC versions. Otherwise, a cast is required. Provide a template > function for this to maintain type safety, and redefine talloc_steal > to use it. pushed, d
[PATCH v2 0/6] batch tagging support: "notmuch tag --stdin"
Jani Nikula writes: > I'm totally fine with modifying the proposed format (e.g. change "T" to > "tag", make things compatible with a future general batch mode), but to > be absolutely clear: I will not implement a general batch command > mode. I was thinking about the best way of making the interface extensible, and it might be better have a kind of modal interface, where some well defined escape at the beginning of the line introduces a mode switch. This has two apparent advantages: it avoids duplication of redundant information at the beginning of each line, and for input to a subcommand it could be optional. something like * tag +foo +bar msg.id at blah +glub -glog other.msg.id at blog vs * restore foo bar msg.id at blah glub glog other.msg.id at blog where a hypothetical general batch interface could take those two files concatenated together, and the "*" lines would be optional feeding to tag and restore respectively. I guess the current proposal is to have the restore format and tag format a bit closer * restore +foo +bar msg.id at blah +glub +glog other.msg.id at blog This looks like it would be a 2% space increase for my tags. I guess I could live with that. Another option would be to have the '+' be optional for tag as well; I suppose then tags starting with + would be ambiguous, which is probably a bad idea. d
[PATCH 2/2] emacs: new mua mailto: URI handler
Jameson Graef Rollins writes: > On Sat, Apr 14 2012, Jani Nikula wrote: >> I was doing this purely based on whether the patches apply or not. > > I'm so sorry, Jani. You are correct that this patch requires a small > rebase fix to apply to master. I'm not sure how I missed it previously. No problem. Thanks for checking again; I was worried we might have a bug somewhere. :) Jani.
some stale patches dropped from the review queue
I have tagged the following patches notmuch::stale, removing them from the review queue [1], purely based on they not applying to master anymore (see [2] for tag definitions). Please rebase your patches against master and resubmit if you think they're still relevant. If you think this is in error, please complain. BR, Jani. [1] http://nmbug.tethera.net/status/ [2] http://notmuchmail.org/nmbug/ id:1310874973-28437-1-git-send-email-anarcat at koumbit.org id:1310874973-28437-2-git-send-email-anarcat at koumbit.org id:1316999137-28257-8-git-send-email-4winter at informatik.uni-hamburg.de id:1319884807-7206-1-git-send-email-thomas at schwinge.name id:1323766883-17607-1-git-send-email-tomi.ollila at iki.fi id:1323766883-17607-2-git-send-email-tomi.ollila at iki.fi id:1325006003-27152-1-git-send-email-dme at dme.org id:1325160490-23472-1-git-send-email-dme at dme.org id:1325160490-23472-2-git-send-email-dme at dme.org id:1325975294-646-2-git-send-email-jrollins at finestructure.net id:1325975294-646-3-git-send-email-jrollins at finestructure.net id:1325975294-646-4-git-send-email-jrollins at finestructure.net id:1325975294-646-5-git-send-email-jrollins at finestructure.net id:1327601789-6040-2-git-send-email-dme at dme.org id:1327601789-6040-3-git-send-email-dme at dme.org id:1326826969-23545-2-git-send-email-jrollins at finestructure.net id:1326826969-23545-3-git-send-email-jrollins at finestructure.net id:1328141050-30356-3-git-send-email-dmitry.kurochkin at gmail.com
[PATCH 2/2] emacs: new mua mailto: URI handler
Jameson Graef Rollins writes: > On Sat, Apr 14 2012, Jani Nikula wrote: >> I'm going through the review queue right now, tagging notmuch::stale any >> patches that don't apply on master. I was just about to nmbug push stale >> on this one (2/2). Is that in error? Care to verify? > > Yes, it is an error. This patch applies to master. Did you in fact > verify that it doesn't? You should not be tagging patches stale if they > in fact still apply to master. If they still need review or something > else that's a different matter. Please don't mark things as stale if > they are not. My nmfirehose script flagged the patch as not applying, and I verified this (and all of them) by hand, using the emacs interface to save the patch. No, I'm not intentionally tagging patches stale if they apply, but I'll stop for now in case there's a bug somewhere (incl. PEBKAC) breaking the patches and thus making them not apply. > Obviously I still care about this patch, or I wouldn't have re-commented > on it. I was doing this purely based on whether the patches apply or not. BR, Jani.
using bbdb with autocompletion
On Thu, Apr 12 2012, David Belohrad wrote: > Dear All, > before I was using gnus to read my emails. This was setup together with > bbdb such, that every email address I got an email delivered got stored > into the bbdb database. > > The config was following: > > --- > ;; IF USING GNUS TO FETCH MAIL: > (if (locate-library "bbdb") > ;; bbdb to automatically create email address list > (progn > (require 'bbdb) > (bbdb-initialize) > (add-hook 'gnus-startup-hook 'bbdb-insinuate-gnus) > (add-hook 'gnus-startup-hook 'bbdb-insinuate-message) > (add-hook 'message-setup-hook 'bbdb-define-all-aliases) > > (setq bbdb/news-auto-create-p t) > (setq bbdb-complete-name-allow-cycling t) > (setq bbdb-complete-mail-allow-cycling t) > (setq bbdb-complete-name-full-completion t) > (setq bbdb-completion-type 'primary-or-name) > (setq bbdb-use-pop-up nil) > ;; set BBDB to AFS so we have the access from all computers to the same > bbdb database! > (setq bbdb-file "/afs/cern.ch/user/b/belohrad/private/bbdb") > (setq bbdb-offer-save 1) > (setq bbdb-electric-p t) > (message "bbdb initialized") > ) > (message "bbdb is missing: address lookup will not work")) > -- > > The problem I have with this now is, that when using notmuch to read > emails, the email addresses do not automatically add to bbdb. So when I > write an email, I can only choose 'To:' email address, which is already > in the bbdb from the times I was using gnus. But all new addresses are > not added. > > How can I setup notmuch properly so with each email arrived it checks > against email address and stores it in the bbdb as in case of gnus? There is (too) brief notice about that in http://notmuchmail.org/emacstips/#index13h2 There is just little bit more information in notmuch archives about that -- I did not dig deeper though. If you're interested you could figure that out and update the wiki page. I'm, using this: id:"m2ehtm1w7p.fsf at guru.guru-group.fi" :D (currently my last mail on nottoomuch-addresses.sh) > thanks for any help. > > -- > .david. Tomi
[PATCH v2 0/6] batch tagging support: "notmuch tag --stdin"
Jameson Graef Rollins writes: > On Sat, Apr 14 2012, Jani Nikula wrote: >> This series adds support for batch tagging through stdin to "notmuch >> tag". This should be useful and efficient for e.g. initial tagging >> scripts. Also, this adds locking around a batch of tag changes, which is >> also useful for initial tagging scripts. See the test patch for an >> example using a "here document". > > My issues from v1 still stand. I would rather see some unification with > the existing tag file format, rather than introduce a second format, > with it's increased maintenance burden and confusion to users. Either > that or a more general batch command interface. The existing dump/restore file format is a dead end. It fails magnificently with tags and message-ids that have spaces or some other special characters in them. It doesn't support removal of tags. There's zero room for extensibility. I can't imagine how that could be used for notmuch tag. David originally wrote the dump/restore patches id:"1324214111-32079-1-git-send-email-david at tethera.net" to add a "notmuch" format (yes, a second format) in addition to the "sup" format we currently have, to fix the issues with special characters. That too lacked features to support batch tagging in notmuch new. The format proposed here would fix the issues and work with notmuch tag, and it would be obvious to use for anyone who has used notmuch tag. I see a general batch command interface overkill. Too many problems to solve for little gain (see the previous thread for details). What other notmuch commands than tag would really benefit from it? If you want to do search or show or whatever, the general batch command interface to use is /bin/sh. For notmuch tag, particularly in connection with notmuch new, there's a clear benefit in having a batch mode: if you have "new" in new.tags, and do initial tagging on the "new" tagged messages (e.g. in post-new hook), you don't want anyone messing with the database while you're processing the messages tagged "new". The batch tagging of this series keeps the db locked for the duration of such initial tagging. I'm totally fine with modifying the proposed format (e.g. change "T" to "tag", make things compatible with a future general batch mode), but to be absolutely clear: I will not implement a general batch command mode. If that is deemed to be what is wanted, that's okay too. I can share my WIP patches for dump/restore, and focus on something else. BR, Jani.
[PATCH 2/2] emacs: new mua mailto: URI handler
Jameson Graef Rollins writes: > On Sun, Jan 29 2012, Jameson Graef Rollins > wrote: >> The new function 'notmuch-mua-mailto' provides an interactive handler >> for rfc6068 "mailto:; URIs. It attempts to implement the rfc6068 >> specification: http://tools.ietf.org/html/rfc6068 > > I am using and finding this patch useful. It has no conflict with > anything when not used. Is there any other objection with pushing it? I'm going through the review queue right now, tagging notmuch::stale any patches that don't apply on master. I was just about to nmbug push stale on this one (2/2). Is that in error? Care to verify? BR, Jani.
Re: [PATCH v2 0/6] batch tagging support: notmuch tag --stdin
Jani Nikula j...@nikula.org writes: I'm totally fine with modifying the proposed format (e.g. change T to tag, make things compatible with a future general batch mode), but to be absolutely clear: I will not implement a general batch command mode. I was thinking about the best way of making the interface extensible, and it might be better have a kind of modal interface, where some well defined escape at the beginning of the line introduces a mode switch. This has two apparent advantages: it avoids duplication of redundant information at the beginning of each line, and for input to a subcommand it could be optional. something like * tag +foo +bar msg.id@blah +glub -glog other.msg.id@blog vs * restore foo bar msg.id@blah glub glog other.msg.id@blog where a hypothetical general batch interface could take those two files concatenated together, and the * lines would be optional feeding to tag and restore respectively. I guess the current proposal is to have the restore format and tag format a bit closer * restore +foo +bar msg.id@blah +glub +glog other.msg.id@blog This looks like it would be a 2% space increase for my tags. I guess I could live with that. Another option would be to have the '+' be optional for tag as well; I suppose then tags starting with + would be ambiguous, which is probably a bad idea. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib: work around talloc_steal usage from C++ code
Jani Nikula j...@nikula.org writes: Implicit typecast from 'void *' to 'T *' is okay in C, but not in C++. In talloc_steal, an explicit cast is provided for type safety in some GCC versions. Otherwise, a cast is required. Provide a template function for this to maintain type safety, and redefine talloc_steal to use it. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] Record dependencies during build instead of before
Austin Clements amdra...@mit.edu writes: This patch eliminates the dependency generation rules and instead generates dependency files as a side-effect of the regular build rule. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/6] Finish show rewrite
Austin Clements amdra...@mit.edu writes: The long-awaited and oft-belated conclusion of the show rewrite. All of the formatters have been converted to the new style, so this series just rips out unused code and does a little cleanup. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails
Jameson Graef Rollins jroll...@finestructure.net writes: I think the issues that David was experiencing have to do with flakiness in emacs's dedicated windows, not in this patch itself. Thomas, Did you have a change to investigate this as proposed in id:87zke0aifa@thor.loria.fr? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] emacs: Don't move to the next thread unless the cursor is at the end of the buffer.
On Tue, 31 Jan 2012, David Edmondson d...@dme.org wrote: When using the spacebar to scroll through a thread, hitting 'space' when the bottom of the last message is visible should take the cursor to the end of the buffer rather than immediately archiving the thread and moving to the next thread. Hi This patch looks good to me; (but if people prefer the current behaviour then can we mark this notmuch::wontfix so it leaves the review queue) Best wishes Mark --- emacs/notmuch-show.el |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index ec72ff8..3f54de0 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1319,6 +1319,11 @@ current window), advance to the next open message. ;; This is not the last message - move to the next visible one. (notmuch-show-next-open-message)) + ((not (= (point) (point-max))) + ;; This is the last message, but the cursor is not at the end of + ;; the buffer. Move it there. + (goto-char (point-max))) + (t ;; This is the last message - change the return value (setq ret t))) -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[No Subject]
On Sun, Apr 15 2012, Jameson Graef Rollins jroll...@finestructure.net wrote: A previous patch [0] replaced blank subject lines with '[No Subject]' in search and show mode. Apparently this was needed to circumvent some bug in the printing code, but there was no need for it search or show, and it is definitely not desirable, so we undo it here (a revert is no longer feasible). We should not be modifying strings in the original message without good reason, or without a clear indication that we are doing so, neither of which apply in this case. For further discussion see [0]. [0] id:1327918561-16245-3-git-send-email-...@dme.org --- I agree. LGTM. Tomi Sorry, there was a small bug in the previous version (notmuch-print.el was mistakenly modified). emacs/notmuch-show.el |5 + emacs/notmuch.el |5 ++--- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 30b26d1..1e55099 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1075,7 +1075,7 @@ function is used. (run-hooks 'notmuch-show-hook)) ;; Set the header line to the subject of the first message. -(setq header-line-format (notmuch-show-strip-re (notmuch-show-get-pretty-subject) +(setq header-line-format (notmuch-show-strip-re (notmuch-show-get-subject) (defun notmuch-show-capture-state () Capture the state of the current buffer. @@ -1375,9 +1375,6 @@ current thread. (defun notmuch-show-get-depth () (notmuch-show-get-prop :depth)) -(defun notmuch-show-get-pretty-subject () - (notmuch-prettify-subject (notmuch-show-get-subject))) - (defun notmuch-show-set-tags (tags) Set the tags of the current message. (notmuch-show-set-prop :tags tags) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index ba833e6..326645d 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -507,7 +507,7 @@ Complete list of currently available key bindings: Display the currently selected thread. (interactive) (let ((thread-id (notmuch-search-find-thread-id)) - (subject (notmuch-prettify-subject (notmuch-search-find-subject + (subject (notmuch-search-find-subject))) (if ( (length thread-id) 0) (notmuch-show thread-id (current-buffer) @@ -877,8 +877,7 @@ non-authors is found, assume that all of the authors match. ;; We currently just throw away excluded matches. (unless (eq (aref count 1) ?0) (let ((beg (point))) - (notmuch-search-show-result date count authors - (notmuch-prettify-subject subject) tags) + (notmuch-search-show-result date count authors subject tags) (notmuch-search-color-line beg (point) tag-list) (put-text-property beg (point) 'notmuch-search-thread-id thread-id) (put-text-property beg (point) 'notmuch-search-authors authors) -- 1.7.9.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred deleted tag name.
On Tue, 17 Jan 2012, Jameson Graef Rollins jroll...@finestructure.net wrote: No functional change here. The help message previously referred to the delete tag, but deleted is now preferred, so hopefully this will reduce any potential confusion. This patch is trivially correct regardless of the rest of the series. I think the rest of the series (which provides keybindings for adding/removing the delete tag to messages/threads) is worthwhile particularly now the exclude stuff is fairly complete (feedback at the time looked positive). Patch 2/3 needs simple but genuine rebasing as the names of the tagging functions have changed though. Best wishes Mark --- emacs/notmuch.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index e4bca51..67ecd3a 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -660,12 +660,12 @@ This function advances the next thread when finished. Here is an example of how to color search results based on tags. (the following text would be placed in your ~/.emacs file): - (setq notmuch-search-line-faces '((\delete\ . (:foreground \red\ + (setq notmuch-search-line-faces '((\deleted\ . (:foreground \red\ :background \blue\)) (\unread\ . (:foreground \green\ The attributes defined for matching tags are merged, with later -attributes overriding earlier. A message having both \delete\ +attributes overriding earlier. A message having both \deleted\ and \unread\ tags with the above settings would have a green foreground and blue background. :type '(alist :key-type (string) :value-type (custom-face-edit)) -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] emacs: Don't move to the next thread unless the cursor is at the end of the buffer.
On Sun, Apr 15 2012, Mark Walters wrote: On Tue, 31 Jan 2012, David Edmondson d...@dme.org wrote: When using the spacebar to scroll through a thread, hitting 'space' when the bottom of the last message is visible should take the cursor to the end of the buffer rather than immediately archiving the thread and moving to the next thread. Hi This patch looks good to me; (but if people prefer the current behaviour then can we mark this notmuch::wontfix so it leaves the review queue) I would definitely like to see this patch applied. Less surprising as there is no indication we have reached the bottom of the buffer. Best wishes Mark Tomi --- emacs/notmuch-show.el |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index ec72ff8..3f54de0 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1319,6 +1319,11 @@ current window), advance to the next open message. ;; This is not the last message - move to the next visible one. (notmuch-show-next-open-message)) + ((not (= (point) (point-max))) + ;; This is the last message, but the cursor is not at the end of + ;; the buffer. Move it there. + (goto-char (point-max))) + (t ;; This is the last message - change the return value (setq ret t))) -- 1.7.8.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add configurable wrapping width for notmuch-wash-wrap-long-lines
On Fri, 17 Feb 2012, Daniel Schoepe dan...@schoepe.org wrote: This introduces a variable to control after how many characters a line is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the window width if it is lower). Hi This looks ok but I wonder if slightly different behaviour might be preferable (and looks simple to implement): rather then always wrapping at min of notmuch-wash-wrap-lines-length and window-width wrap at min of (notmuch-wash-wrap-lines-length + depth) and window-width. Then if you have a wide buffer you can still get 80 chars (say) of useful text even for well nested messages whilst not having very long lines anywhere. Best wishes Mark --- emacs/notmuch-wash.el | 36 ++-- 1 files changed, 26 insertions(+), 10 deletions(-) diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el index 56981d0..7d003a2 100644 --- a/emacs/notmuch-wash.el +++ b/emacs/notmuch-wash.el @@ -87,6 +87,14 @@ If there is one more line than the sum of `notmuch-wash-citation-lines-suffix', show that, otherwise collapse the remaining lines into a button.) +(defvar notmuch-wash-wrap-lines-length nil + Wrap line after at most this many characters. + +If this is nil, lines in messages will be wrapped to fit in the +current window. If this is a number, lines will be wrapped after +this many characters or at the window width (whichever one is +lower).) + (defun notmuch-wash-toggle-invisible-action (cite-button) (let ((invis-spec (button-get cite-button 'invisibility-spec))) (if (invisible-p invis-spec) @@ -276,16 +284,24 @@ Perform several transformations on the message body: ;; (defun notmuch-wash-wrap-long-lines (msg depth) - Wrap any long lines in the message to the width of the window. - -When doing so, maintaining citation leaders in the wrapped text. - - (let ((coolj-wrap-follows-window-size nil) - (fill-column (- (window-width) - depth - ;; 2 to avoid poor interaction with - ;; `word-wrap'. - 2))) + Wrap long lines in the message. + +If `notmuch-wash-wrap-lines-length' is a number, this will wrap +the message lines to the minimum of the width of the window or +its value. Otherwise, this function will wrap long lines in the +message at the window width. When doing so, citation leaders in +the wrapped text are maintained. + + (let* ((coolj-wrap-follows-window-size nil) + (limit (if (numberp notmuch-wash-wrap-lines-length) + (min notmuch-wash-wrap-lines-length + (window-width)) + (window-width))) + (fill-column (- limit + depth + ;; 2 to avoid poor interaction with + ;; `word-wrap'. + 2))) (coolj-wrap-region (point-min) (point-max ;; -- 1.7.9 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred deleted tag name.
On Sun, Apr 15 2012, Mark Walters wrote: On Tue, 17 Jan 2012, Jameson Graef Rollins jroll...@finestructure.net wrote: No functional change here. The help message previously referred to the delete tag, but deleted is now preferred, so hopefully this will reduce any potential confusion. This patch is trivially correct regardless of the rest of the series. Agreed. +1 I think the rest of the series (which provides keybindings for adding/removing the delete tag to messages/threads) is worthwhile particularly now the exclude stuff is fairly complete (feedback at the time looked positive). Patch 2/3 needs simple but genuine rebasing as the names of the tagging functions have changed though. Why not :) Best wishes Mark Tomi --- emacs/notmuch.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index e4bca51..67ecd3a 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -660,12 +660,12 @@ This function advances the next thread when finished. Here is an example of how to color search results based on tags. (the following text would be placed in your ~/.emacs file): - (setq notmuch-search-line-faces '((\delete\ . (:foreground \red\ + (setq notmuch-search-line-faces '((\deleted\ . (:foreground \red\ :background \blue\)) (\unread\ . (:foreground \green\ The attributes defined for matching tags are merged, with later -attributes overriding earlier. A message having both \delete\ +attributes overriding earlier. A message having both \deleted\ and \unread\ tags with the above settings would have a green foreground and blue background. :type '(alist :key-type (string) :value-type (custom-face-edit)) -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred deleted tag name.
On Sun, Apr 15 2012, Mark Walters markwalters1...@gmail.com wrote: This patch is trivially correct regardless of the rest of the series. I think the rest of the series (which provides keybindings for adding/removing the delete tag to messages/threads) is worthwhile particularly now the exclude stuff is fairly complete (feedback at the time looked positive). Sorry, I wish I could have purged all of these series from the list. After a very protracted discussion on the topic it was decided that notmuch will not support any delete tagging operations. Users who wish to do so can add support on their own: id:87sjgk2xzf@servo.finestructure.net http://notmuchmail.org/excluding/ I highly recommend *not* re-starting this discussion. There is no solution that will satisfy everyone. Just let it be. Move on. Nothing to see here. These are not the tags you're looking for... jamie. pgpFYChSlpPCH.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: some stale patches dropped from the review queue
On Sun, 15 Apr 2012, Jani Nikula j...@nikula.org wrote: I have tagged the following patches notmuch::stale, removing them from the review queue [1], purely based on they not applying to master anymore (see [2] for tag definitions). Please rebase your patches against master and resubmit if you think they're still relevant. If you think this is in error, please complain. BR, Jani. [1] http://nmbug.tethera.net/status/ [2] http://notmuchmail.org/nmbug/ 2nd batch, with some notmuch::obsolete tagged patches listed separately at the end. There are still plenty of patches in the review queue that need to be decided on. This was a simple technical clean up based on whether the patches still apply or not. Also, only the stale patches and patches from the stale patch on in each series were tagged, sometimes leaving behind half a series that does apply. They are still in the queue. id:1326591624-15493-10-git-send-email-da...@tethera.net id:1326591624-15493-11-git-send-email-da...@tethera.net id:1326591624-15493-4-git-send-email-da...@tethera.net id:1326591624-15493-5-git-send-email-da...@tethera.net id:1326591624-15493-6-git-send-email-da...@tethera.net id:1326591624-15493-7-git-send-email-da...@tethera.net id:1326591624-15493-8-git-send-email-da...@tethera.net id:1326591624-15493-9-git-send-email-da...@tethera.net id:1330122640-18895-6-git-send-email-pie...@praet.org id:1330122640-18895-7-git-send-email-pie...@praet.org id:1325986015-22510-3-git-send-email-jroll...@finestructure.net id:1325986015-22510-4-git-send-email-jroll...@finestructure.net id:1325986015-22510-5-git-send-email-jroll...@finestructure.net id:1334077496-9172-2-git-send-email-markwalters1...@gmail.com id:1334077496-9172-3-git-send-email-markwalters1...@gmail.com id:1332171061-27983-3-git-send-email-markwalters1...@gmail.com id:1331149792-17192-1-git-send-email-pie...@praet.org id:1329936214-30959-4-git-send-email-pie...@praet.org id:1329936214-30959-5-git-send-email-pie...@praet.org id:1329936214-30959-6-git-send-email-pie...@praet.org id:1329936214-30959-7-git-send-email-pie...@praet.org id:1329319688-16056-1-git-send-email-awg+notm...@xvx.ca id:1328688139-3865-3-git-send-email-...@dme.org id:1328604377-20121-2-git-send-email-...@dme.org id:1328568490-18473-1-git-send-email-...@dme.org id:1328542748-19530-3-git-send-email-...@dme.org id:1328542748-19530-4-git-send-email-...@dme.org id:1328542748-19530-5-git-send-email-...@dme.org id:1323796305-28789-4-git-send-email-schno...@schnouki.net id:1323796305-28789-5-git-send-email-schno...@schnouki.net id:1323796305-28789-6-git-send-email-schno...@schnouki.net Obsolete - AFAICT there was a more recent version of each of these posted: id:1333149350-22616-2-git-send-email-noval...@gmail.com id:1333149350-22616-3-git-send-email-noval...@gmail.com id:1333149350-22616-4-git-send-email-noval...@gmail.com id:1333149350-22616-5-git-send-email-noval...@gmail.com id:1333149350-22616-6-git-send-email-noval...@gmail.com id:1333845338-22960-2-git-send-email-jroll...@finestructure.net id:1333845338-22960-3-git-send-email-jroll...@finestructure.net id:1333845338-22960-4-git-send-email-jroll...@finestructure.net id:1333845338-22960-5-git-send-email-jroll...@finestructure.net id:1333845338-22960-6-git-send-email-jroll...@finestructure.net id:1333845338-22960-7-git-send-email-jroll...@finestructure.net id:1333845338-22960-8-git-send-email-jroll...@finestructure.net id:1333845338-22960-9-git-send-email-jroll...@finestructure.net id:1332635232-15269-2-git-send-email-awg+notm...@xvx.ca id:1332635232-15269-3-git-send-email-awg+notm...@xvx.ca ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/4] Explicitly type void* pointers
I tagged this patch notmuch::obsolete (see [1]) as the template
workaround was pushed to master (commit
de0557477d908be26615e8fda9f5eb62bed68b65).
Jani.
[1] http://nmbug.tethera.net/status/
On Mon, 09 Apr 2012, vladimir.ma...@oracle.com wrote:
From: Vladimir Marek vlma...@volny.cz
Signed-off-by: Vladimir Marek vlma...@volny.cz
---
lib/database.cc |2 +-
lib/message.cc |2 +-
lib/thread.cc |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 16c4354..3c82632 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1361,7 +1361,7 @@ _resolve_message_id_to_thread_id (notmuch_database_t
*notmuch,
return status;
if (message) {
- *thread_id_ret = talloc_steal (ctx,
+ *thread_id_ret = (const char*)talloc_steal (ctx,
notmuch_message_get_thread_id (message));
notmuch_message_destroy (message);
diff --git a/lib/message.cc b/lib/message.cc
index 0075425..d56d442 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -220,7 +220,7 @@ _notmuch_message_create_for_message_id
(notmuch_database_t *notmuch,
message_id,
message);
if (message)
- return talloc_steal (notmuch, message);
+ return (notmuch_message_t*) talloc_steal (notmuch, message);
else if (*status_ret)
return NULL;
diff --git a/lib/thread.cc b/lib/thread.cc
index e976d64..d41ff3e 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -225,7 +225,7 @@ _thread_add_message (notmuch_thread_t *thread,
char *clean_author;
_notmuch_message_list_add_message (thread-message_list,
-talloc_steal (thread, message));
+(_notmuch_message*)talloc_steal (thread,
message));
thread-total_messages++;
g_hash_table_insert (thread-message_hash,
--
1.7.3.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: incrontab?
Hi Adam, interestingly, your 'G' short-cut hint works out of the box! What happens is, that when one presses 'G', this invokes notmuch-hello-poll-and-update. This function calls 'notmuch-poll', which does exactly what I want. I.e. it runs 'notmuch new' if no polling script is specified. In my case however this invokes 'remote-notmuch new' which asks notmuch installed at the server to tag new emails. Lovely. (footnote: It suits me excellently because I'm not seeking for 'mail push' service and rather read my emails whenever I decide to do and not whenever an email arrives - this is why I consider not calling notmuch-poll before every invocation of (notmuch) not as a bug, but just minor annoyance which can be tweaked away if desired) There is just one slightly weird thing. This is when 'notmuch' is opened, the focus goes directly to search button instead of 'inbox' messages (or something else), which is imho more interesting than going into search. Because at first what one wants to do is to look into new emails. Another disadvantage of going directly into search box is, that all shortcuts get inhibited. Is there any way how to set default focus to something else? thanks a lot david Adam Wolfe Gordon awg+notm...@xvx.ca writes: Hi David, On Thu, Apr 12, 2012 at 02:25, David Belohrad da...@belohrad.ch wrote: is somebody using incrontab to issue 'notmuch new'? I've tried but with only partial success. I have setup incrotab to run 'notmuch new' when something changes in my Maildir. However it is not reliable. E.g. sometimes it works out of the box, sometimes it seems that 'notmuch new' is simply not invoked at all even if I see in /var/log/mail.log, that a new mail was delivered correctly to the folder. Anyone really uses this setup? I don't use incrontab, but I do use my own inotify-based script for updating notmuch: https://gist.github.com/1952483 . I haven't had any trouble with it. I have reverted back to crontab to issue 'notmuch new' every 5 minutes. And frankly speaking, I'm rather thinking to run this command from emacs directly everytime I either start notmuch, or refresh view using '=' on notmuch-hello buffer. You could probably do this with notmuch-hello-refresh-hook, but it will be a bit tricky: the hook is executed after the notmuch-hello buffer is refreshed, so you'd have to have it refresh after notmuch new completes, without running the hook infinitely. A better approach might be to use advice. Something like (completely untested): (defadvice notmuch-hello-update (before notmuch-new) (call-process notmuch nil nil nil new)) Hope that helps, -- Adam ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: incrontab?
Quoth David Belohrad on Apr 15 at 11:39 pm: There is just one slightly weird thing. This is when 'notmuch' is opened, the focus goes directly to search button instead of 'inbox' messages (or something else), which is imho more interesting than going into search. Because at first what one wants to do is to look into new emails. Another disadvantage of going directly into search box is, that all shortcuts get inhibited. Is there any way how to set default focus to something else? This is generally considered to be a bug, but nobody's been brave enough to fix it yet. You can, however, remove the search box entirely by customizing notmuch-hello-sections, which has the side-effect of fixing this (you can still search by hitting 's', so the search box itself is of limited utility). ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello
--- emacs/notmuch-hello.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 71d37b8..f10d98d 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -226,7 +226,7 @@ by an additional filter query. Similarly, the count of messages displayed next to the buttons can be generated by applying a different filter to the tag query. These filters are also supported for \Customized queries section\ items. - :group 'notmuch + :group 'notmuch-hello :type '(repeat (choice (function-item notmuch-hello-insert-header) -- 1.7.9.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Put notmuch-print-mechanism in custom group notmuch-show
--- emacs/notmuch-print.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el index 6653d97..8c18f4b 100644 --- a/emacs/notmuch-print.el +++ b/emacs/notmuch-print.el @@ -25,7 +25,7 @@ (defcustom notmuch-print-mechanism 'notmuch-print-lpr How should printing be done? - :group 'notmuch + :group 'notmuch-show :type '(choice (function :tag Use lpr notmuch-print-lpr) (function :tag Use ps-print notmuch-print-ps-print) -- 1.7.9.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred deleted tag name.
On Sun, Apr 15 2012, Jameson Graef Rollins jroll...@finestructure.net wrote: On Sun, Apr 15 2012, Mark Walters markwalters1...@gmail.com wrote: This patch is trivially correct regardless of the rest of the series. I think the rest of the series (which provides keybindings for adding/removing the delete tag to messages/threads) is worthwhile particularly now the exclude stuff is fairly complete (feedback at the time looked positive). Sorry, I wish I could have purged all of these series from the list. After a very protracted discussion on the topic it was decided that notmuch will not support any delete tagging operations. Users who wish to do so can add support on their own: id:87sjgk2xzf@servo.finestructure.net http://notmuchmail.org/excluding/ I highly recommend *not* re-starting this discussion. There is no solution that will satisfy everyone. Just let it be. Move on. Nothing to see here. These are not the tags you're looking for... id:1326826969-23545-1-git-send-email-jroll...@finestructure.net Does just delete - deleted change: the only question I have left is that should that be left as is, this change made, or just drop the delete coloring altogether ? jamie. Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: some stale patches dropped from the review queue
Sorry, I'm out of touch with nmbug at the moment. I'll try to get reacquainted. In the mean time... id:1325986015-22510-3-git-send-email-jroll...@finestructure.net id:1325986015-22510-4-git-send-email-jroll...@finestructure.net id:1325986015-22510-5-git-send-email-jroll...@finestructure.net This series is definitely obsolete. Obsolete - AFAICT there was a more recent version of each of these posted: id:1333149350-22616-2-git-send-email-noval...@gmail.com id:1333149350-22616-3-git-send-email-noval...@gmail.com id:1333149350-22616-4-git-send-email-noval...@gmail.com id:1333149350-22616-5-git-send-email-noval...@gmail.com id:1333149350-22616-6-git-send-email-noval...@gmail.com This series is obsoleted by a later version: id:1334367666-10954-1-git-send-email-noval...@gmail.com id:1333845338-22960-2-git-send-email-jroll...@finestructure.net id:1333845338-22960-3-git-send-email-jroll...@finestructure.net id:1333845338-22960-4-git-send-email-jroll...@finestructure.net id:1333845338-22960-5-git-send-email-jroll...@finestructure.net id:1333845338-22960-6-git-send-email-jroll...@finestructure.net id:1333845338-22960-7-git-send-email-jroll...@finestructure.net id:1333845338-22960-8-git-send-email-jroll...@finestructure.net id:1333845338-22960-9-git-send-email-jroll...@finestructure.net This series is obsoleted by a later version: id:1334429574-12918-1-git-send-email-jroll...@finestructure.net jamie. pgp4cLzGEesZR.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/3] emacs: modify help message for notmuch-search-line-faces to reflect preferred deleted tag name.
On Sun, Apr 15 2012, Tomi Ollila tomi.oll...@iki.fi wrote: id:1326826969-23545-1-git-send-email-jroll...@finestructure.net Does just delete - deleted change: the only question I have left is that should that be left as is, this change made, or just drop the delete coloring altogether ? Sorry, yes, I suppose this patch should still be applied. Excludes for deleted are the default, I believe, so if we are going to refer to it in documentation we should probably be consistent. On Sun, Apr 15 2012, Jameson Graef Rollins jroll...@finestructure.net wrote: On Sun, Apr 15 2012, Mark Walters markwalters1...@gmail.com wrote: I think the rest of the series (which provides keybindings for adding/removing the delete tag to messages/threads) is worthwhile particularly now the exclude stuff is fairly complete (feedback at the time looked positive). Sorry, I wish I could have purged all of these series from the list. After a very protracted discussion on the topic it was decided that notmuch will not support any delete tagging operations. Users who wish to do so can add support on their own: I think my reaction here was a little strong. I'm not remembering how I got the impression that there was more opposition to adding delete keybindings than there was support. I suppose now that excludes work so well one (not me) might consider revisiting the issue. jamie. pgpRZEZLTXWxA.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
