Re: [PATCH v2] emacs: call notmuch-show instead of notmuch-search in buttonised id: links
On Thu, 22 Dec 2011 20:59:12 -0800, Jameson Graef Rollins wrote: > Since message-ids necessarily match just a single message, there's no > reason to do a search for the id before viewing the actual message; > the search just becomes an extra screen to click through. Clicking on > an id: links now just jumps straight to the message itself. It's often useful to see a message in context, particularly as it's common for people to reference id:'s when referring to a thread (thread: is instance local, as I recall). Is there a simple way from `notmuch-show' to jump out to the result of `notmuch-search' for the current id:? Maybe we could bind ^ to something like `notmuch-show-in-context'. pgpzm0vBdtU4S.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
On Thu, 22 Dec 2011 09:29:55 -0500, Aaron Ecay wrote: > Would the problem you had with previous-s-c-prop-change be fixed by the > patch to the original function I sent in the thread starting at > id:"m2y5u5cykp.fsf at kcals.intra.maillard.im" ? AFAIK it does. /Xavier
[PATCH] emacs: fix off-by-one bug in notmuch-show-archive
Hey Aaron, On Thu, 22 Dec 2011 09:24:20 -0500, Aaron Ecay wrote: > Text properties change between characters; prev-s-c-property-change > returns the position after the change. Thus, it is still inside the > invisible region. This patch works for me (at least on all the messages I tested it on). Thank you very much ! /Xavier
Filter one-post thread only ?
Hi, In order to clean up and to trash out as many posts as possible in several mailing lists I did not check lately, I am trying to find a way to limit the current display to messages matching this requirements: 1. post older than 1 month 2. one-message thread only (a post and no followup/answer). Do you think this can be done ? In case you do, then how ? :D Thank you very much. /Xavier
[PATCH v2] emacs: call notmuch-show instead of notmuch-search in buttonised id: links
Since message-ids necessarily match just a single message, there's no reason to do a search for the id before viewing the actual message; the search just becomes an extra screen to click through. Clicking on an id: links now just jumps straight to the message itself. --- This just fixes the subject of the patch, which had a typo. Sorry. emacs/notmuch-show.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 98db8f2..623d521 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -803,7 +803,7 @@ a corresponding notmuch search." (remove-overlays (match-beginning 0) (match-end 0) 'goto-address t) (make-text-button (match-beginning 0) (match-end 0) 'action `(lambda (arg) - (notmuch-search ,(match-string-no-properties 0))) + (notmuch-show ,(match-string-no-properties 0))) 'follow-link t 'help-echo "Mouse-1, RET: search for this message" 'face goto-address-mail-face -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] emacs: call notmuch-show instead of notmuch-search in buttonised id: links
Since message-ids necessarily match just a single message, there's no reason to do a search for the id before viewing the actual message; the search just becomes an extra screen to click through. Clicking on an id: links now just jumps straight to the message itself. --- This just fixes the subject of the patch, which had a typo. Sorry. emacs/notmuch-show.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 98db8f2..623d521 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -803,7 +803,7 @@ a corresponding notmuch search." (remove-overlays (match-beginning 0) (match-end 0) 'goto-address t) (make-text-button (match-beginning 0) (match-end 0) 'action `(lambda (arg) - (notmuch-search ,(match-string-no-properties 0))) + (notmuch-show ,(match-string-no-properties 0))) 'follow-link t 'help-echo "Mouse-1, RET: search for this message" 'face goto-address-mail-face -- 1.7.7.3
[PATCH] emacs: call notmuch-show instead notmuch-search in buttonised id: links
Since message-ids necessarily match just a single message, there's no reason to do a search for the id before viewing the actual message; the search just becomes an extra screen to click through. Clicking on an id: links now just jumps straight to the message itself. --- emacs/notmuch-show.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 98db8f2..623d521 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -803,7 +803,7 @@ a corresponding notmuch search." (remove-overlays (match-beginning 0) (match-end 0) 'goto-address t) (make-text-button (match-beginning 0) (match-end 0) 'action `(lambda (arg) - (notmuch-search ,(match-string-no-properties 0))) + (notmuch-show ,(match-string-no-properties 0))) 'follow-link t 'help-echo "Mouse-1, RET: search for this message" 'face goto-address-mail-face -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: call notmuch-show instead notmuch-search in buttonised id: links
Since message-ids necessarily match just a single message, there's no reason to do a search for the id before viewing the actual message; the search just becomes an extra screen to click through. Clicking on an id: links now just jumps straight to the message itself. --- emacs/notmuch-show.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 98db8f2..623d521 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -803,7 +803,7 @@ a corresponding notmuch search." (remove-overlays (match-beginning 0) (match-end 0) 'goto-address t) (make-text-button (match-beginning 0) (match-end 0) 'action `(lambda (arg) - (notmuch-search ,(match-string-no-properties 0))) + (notmuch-show ,(match-string-no-properties 0))) 'follow-link t 'help-echo "Mouse-1, RET: search for this message" 'face goto-address-mail-face -- 1.7.7.3
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
On Thu, 22 Dec 2011 19:25:59 +, David Edmondson wrote:
> if (write(2, msg, sizeof(msg)-1) {
Sigh.
if (write(2, msg, sizeof(msg)-1) != sizeof(msg)-1) {
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111222/95efcc95/attachment.pgp>
[alot] Introducing myself, asking various questions
On Sun, Dec 18, 2011 at 9:32 PM, Patrick Totzke wrote: >>.. however I have the >>impression that it may be trying to do too much for my needs, which may >>be peculiar. I have installed offlineimap+notmuch+alot on a slow laptop >>running Debian wheezy. > I guess most of us use offlineimap or getmail in combination > with notmuch. And Debian is also popular choice afaik, > so you're in good company :) Personally I prefer mbsync (isync) because it's much more efficient, and it's not written in python :) -- Felipe Contreras
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
On Thu, 22 Dec 2011 14:03:05 -0500, Austin Clements wrote:
> > In general I agree, but what would we do if writing an error message to
> > stderr fails?
>
> This was discussed on IRC, but calls to write(2) should never be bare.
> I believe it's marked warn_unused_result not because libc is so
> concerned with people checking for error returns (otherwise all sorts
> of things would be marked warn_unused_result) but because even a
> successful write can be a short write. Hence, not checking the result
> is a bug, even if you don't care about errors.
As I said, the principle is sound. What would do in this specific case?
static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
write(2, msg, sizeof(msg)-1);
interrupted = 1;
}
Just this?
if (write(2, msg, sizeof(msg)-1) {
/* Appease the compiler. */;
}
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20111222/c2441045/attachment.pgp>
[RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
On Thu, 22 Dec 2011 09:29:55 -0500, Aaron Ecay wrote: > Would the problem you had with previous-s-c-prop-change be fixed by the > patch to the original function I sent in the thread starting at > id:"m2y5u5cykp.fsf at kcals.intra.maillard.im" ? I think so, yes. Re-writing the new version I posted to use `previous-single-char-property-value' in the way that you describe: ((let ((visible-bottom (notmuch-show-message-bottom))) (while (invisible-p visible-bottom) (setq visible-bottom (max (point-min) (1- (previous-single-char-property-change visible-bottom 'invisible) (> visible-bottom (window-end))) ;; The end of this message is not visible - scroll. (scroll-up) nil) seems to work in quick testing. I'd vote to integrate your change if it seems correct to everyone else, then I'll argue for a re-write separately. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111222/26c23248/attachment.pgp>
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
Quoth David Edmondson on Dec 22 at 7:25 pm:
> On Thu, 22 Dec 2011 14:03:05 -0500, Austin Clements
> wrote:
> > > In general I agree, but what would we do if writing an error message to
> > > stderr fails?
> >
> > This was discussed on IRC, but calls to write(2) should never be bare.
> > I believe it's marked warn_unused_result not because libc is so
> > concerned with people checking for error returns (otherwise all sorts
> > of things would be marked warn_unused_result) but because even a
> > successful write can be a short write. Hence, not checking the result
> > is a bug, even if you don't care about errors.
>
> As I said, the principle is sound. What would do in this specific case?
>
> static void
> handle_sigint (unused (int sig))
> {
> static char msg[] = "Stopping... \n";
>
> write(2, msg, sizeof(msg)-1);
> interrupted = 1;
> }
>
> Just this?
>
> if (write(2, msg, sizeof(msg)-1) {
> /* Appease the compiler. */;
> }
Maybe I missed something, but what's wrong with using a standard write
loop (like j4ni suggested on IRC)? In my mind this isn't about
appeasing the compiler; the compiler is pointing out a real bug.
Patch coming in a moment...
I'm not sure what to do about the specific case of fwrite, though
judging by
http://sourceware.org/bugzilla/show_bug.cgi?id=11959
I'm not the only person who thinks that fwrite being
warn_unused_result is odd.
[PATCH] Properly handle short writes in sigint handlers
Even if we don't care about errors from write(2), it's still necessary
to handle short writes in order to use write correctly. Some versions
of glibc even mark write as warn_unused_result because of this, so our
previous usage would trigger compiler warnings.
---
notmuch-new.c |5 -
notmuch-tag.c |6 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 3512de7..fc09bbb 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -66,8 +66,11 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
+const char *pos = msg, *end = msg + sizeof (msg) - 1;
+ssize_t c = 0;
-(void) write(2, msg, sizeof(msg)-1);
+for (; pos < end && c >= 0; pos += c)
+ c = write (2, pos, end - pos);
interrupted = 1;
}
diff --git a/notmuch-tag.c b/notmuch-tag.c
index 292c5da..0d4873d 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,11 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
-(void) write(2, msg, sizeof(msg)-1);
+const char *pos = msg, *end = msg + sizeof (msg) - 1;
+ssize_t c = 0;
+
+for (; pos < end && c >= 0; pos += c)
+ c = write (2, pos, end - pos);
interrupted = 1;
}
--
1.7.7.3
Re: Filter one-post thread only ?
On Thu, 22 Dec 2011 21:45:14 +0100, Xavier Maillard wrote: > Hi, > > In order to clean up and to trash out as many posts as possible in > several mailing lists I did not check lately, I am trying to find a way > to limit the current display to messages matching this requirements: > > 1. post older than 1 month See the last paragraphs of 'notmuch help search-terms'. Some people use lisp to generate the timestamp ranges in searches. There's an old draft patchset for user friendly date range searches [1]. I am writing a better one, but that's very much a low priority background process. It's not too far from surpassing the earlier version in quality, though. BR, Jani. [1] id:"cover.1312964528.git.j...@nikula.org" ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: fix off-by-one bug in notmuch-show-archive
On Thu, 22 Dec 2011 09:24:20 -0500, Aaron Ecay wrote: > Text properties change between characters; prev-s-c-property-change > returns the position after the change. Thus, it is still inside the > invisible region. Thanks Aaron! I just tested this and it does seem to fix the issue. Definitely +1 for this. jamie. pgp681qkJJBh1.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: fix off-by-one bug in notmuch-show-archive
On Thu, 22 Dec 2011 09:24:20 -0500, Aaron Ecay wrote: > Text properties change between characters; prev-s-c-property-change > returns the position after the change. Thus, it is still inside the > invisible region. Thanks Aaron! I just tested this and it does seem to fix the issue. Definitely +1 for this. 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/20111222/013364ef/attachment.pgp>
Re: [RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
On Thu, 22 Dec 2011 09:29:55 -0500, Aaron Ecay wrote: > Would the problem you had with previous-s-c-prop-change be fixed by the > patch to the original function I sent in the thread starting at > id:"m2y5u5cykp@kcals.intra.maillard.im" ? AFAIK it does. /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: fix off-by-one bug in notmuch-show-archive
Hey Aaron, On Thu, 22 Dec 2011 09:24:20 -0500, Aaron Ecay wrote: > Text properties change between characters; prev-s-c-property-change > returns the position after the change. Thus, it is still inside the > invisible region. This patch works for me (at least on all the messages I tested it on). Thank you very much ! /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
Quoth David Edmondson on Dec 22 at 7:21 am: > On Thu, 22 Dec 2011 02:03:45 -0500, Austin Clements > wrote: > > I must admit I haven't been following the warnings problem very > > closely, but perhaps we shouldn't be ignoring these return codes? > > In general I agree, but what would we do if writing an error message to > stderr fails? This was discussed on IRC, but calls to write(2) should never be bare. I believe it's marked warn_unused_result not because libc is so concerned with people checking for error returns (otherwise all sorts of things would be marked warn_unused_result) but because even a successful write can be a short write. Hence, not checking the result is a bug, even if you don't care about errors. fwrite's a little trickier, since it will only short-write on an error, so to me it seems perfectly legitimate to ignore the result if you don't care about errors. I don't seem to have whatever glibc version the buildbot does that marks these warn_unused_result, but I can reproduce it by adding __attribute__((warn_unused_result)) ssize_t write(int fd, const void *buf, size_t count); __attribute__((warn_unused_result)) size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream); to notmuch-client.h. Testing with these, if I add any form of result checking, even if it does nothing in most cases, GCC is quiet.
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
Hi David. Perhaps I am missing something here. But I do not get any warnings when building with GCC 4.6.2 with -Wall -Werror (-O2 and -O0). I do not like adding any complex hacks to make the build warning-free on old GCC versions. If this happens on the build bot, we should just update it or ignore the warnings. Regards, Dmitry
[alot] announcing v0.2 aka. "robot santa"
Hi again, I have merged the packaging stuff to upstream master and moved the debian directory to /packaging. An include file for help2man as well as a generated man page for the upcomming release 0.21 can be found in /docs/man. Let me know if there's anything else I can do, /p
[RFC][PATCH v3] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
The advance/rewind functions had become complex, which made it hard to determine who they are expected to behave. Re-implement them simply in order to poll user-experience and expectation. --- This one passes the test suite and, consequently, works better when the last open message in a thread has trailing invisible text. emacs/notmuch-show.el | 124 +--- 1 files changed, 65 insertions(+), 59 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 46525aa..9fec499 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1156,38 +1156,49 @@ Some useful entries are: ;; Commands typically bound to keys. (defun notmuch-show-advance () - "Advance through thread. + "Advance through the current thread. -If the current message in the thread is not yet fully visible, -scroll by a near screenful to read more of the message. +Scroll the current message if the end of it is not visible, +otherwise move to the next message. -Otherwise, (the end of the current message is already within the -current window), advance to the next open message." +Return `t' if we are at the end of the last message, otherwise +`nil'." (interactive) - (let* ((end-of-this-message (notmuch-show-message-bottom)) -(visible-end-of-this-message (1- end-of-this-message)) -(ret nil)) -(while (invisible-p visible-end-of-this-message) - (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) -(cond - ;; Ideally we would test `end-of-this-message' against the result - ;; of `window-end', but that doesn't account for the fact that - ;; the end of the message might be hidden. - ((and visible-end-of-this-message - (> visible-end-of-this-message (window-end))) - ;; The bottom of this message is not visible - scroll. - (scroll-up nil)) - - ((not (= end-of-this-message (point-max))) - ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - change the return value - (setq ret t))) -ret)) + (cond + ((eobp) +;; If we are at the end of the buffer then move to the next +;; thread. +t) + + ;; Ideally we would simply do: + ;; + ;; ((> (notmuch-show-message-bottom) (window-end)) + ;; + ;; here, but that fails if the trailing text in the buffer is + ;; invisible (`window-end' returns the last visible character, + ;; which can then be smaller than `notmuch-show-message-bottom'). + ;; + ;; So we need to find the last _visible_ character of the + ;; message. We do this by checking the invisibility of the + ;; characters from `notmuch-show-message-bottom'-1 towards the start + ;; of the message. When we find a non-invisible character, we test + ;; to see whether it is visible in the window. + + ((let ((visible-bottom + (save-excursion +(goto-char (1- (notmuch-show-message-bottom))) +(while (invisible-p (point)) + (backward-char)) +(point + (> visible-bottom (window-end))) +;; The end of this message is not visible - scroll. +(scroll-up) +nil) + + (t +;; Show the start of the next message. +(notmuch-show-next-open-message) +nil))) (defun notmuch-show-advance-and-archive () "Advance through thread and archive. @@ -1201,44 +1212,39 @@ from each message), kills the buffer, and displays the next thread from the search from which this thread was originally shown." (interactive) - (if (notmuch-show-advance) - (notmuch-show-archive-thread))) + (when (notmuch-show-advance) +(notmuch-show-archive-thread))) (defun notmuch-show-rewind () - "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + "Move backwards through a thread, the counterpart to \\[notmuch-show-advance-and-archive]." -Specifically, if the beginning of the previous email is fewer -than `window-height' lines from the current point, move to it -just like `notmuch-show-previous-message'. - -Otherwise, just scroll down a screenful of the current message. - -This command does not modify any message tags, (it does not undo -any effects from previous calls to -`notmuch-show-advance-and-archive'." (interactive) - (let ((start-of-message (notmuch-show-message-top)) - (start-of-window (window-start))) + (let ((start-of-message (notmuch-show-message-top))) (cond - ;; Either this message is properly aligned with the start of the - ;; window or the start of this message is not visible on the - ;; screen - scroll. - ((or (= start-of-message start-of-window) - (< start-of-message start-of-window)) + ((= start-of-message (point)) + ;; If the cursor is at the start of the current message, mo
Filter one-post thread only ?
Hi, In order to clean up and to trash out as many posts as possible in several mailing lists I did not check lately, I am trying to find a way to limit the current display to messages matching this requirements: 1. post older than 1 month 2. one-message thread only (a post and no followup/answer). Do you think this can be done ? In case you do, then how ? :D Thank you very much. /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
The advance/rewind functions had become complex, which made it hard to determine who they are expected to behave. Re-implement them simply in order to poll user-experience and expectation. --- Re-introduce the detection of invisible trailers. Using `previous-single-char-property-change' just didn't work in my testing, so back to the original approach. Dmitry: can you explain why you needed to change it? emacs/notmuch-show.el | 126 ++--- 1 files changed, 67 insertions(+), 59 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 46525aa..258814e 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1156,38 +1156,51 @@ Some useful entries are: ;; Commands typically bound to keys. (defun notmuch-show-advance () - "Advance through thread. + "Advance through the current thread. -If the current message in the thread is not yet fully visible, -scroll by a near screenful to read more of the message. +Scroll the current message if the end of it is not visible, +otherwise move to the next message. -Otherwise, (the end of the current message is already within the -current window), advance to the next open message." +Return `t' if we are at the end of the last message, otherwise +`nil'." (interactive) - (let* ((end-of-this-message (notmuch-show-message-bottom)) -(visible-end-of-this-message (1- end-of-this-message)) -(ret nil)) -(while (invisible-p visible-end-of-this-message) - (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) -(cond - ;; Ideally we would test `end-of-this-message' against the result - ;; of `window-end', but that doesn't account for the fact that - ;; the end of the message might be hidden. - ((and visible-end-of-this-message - (> visible-end-of-this-message (window-end))) - ;; The bottom of this message is not visible - scroll. - (scroll-up nil)) - - ((not (= end-of-this-message (point-max))) - ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - change the return value - (setq ret t))) -ret)) + (cond + ((eobp) +;; If we are at the end of the buffer then move to the next +;; thread. +t) + + ;; Ideally we would simply do: + ;; + ;; ((> (notmuch-show-message-bottom) (window-end)) + ;; + ;; here, but that fails if the trailing text in the buffer is + ;; invisible (`window-end' returns the last visible character, + ;; which can then be smaller than `notmuch-show-message-bottom'). + ;; + ;; So we need to find the last _visible_ character of the + ;; message. We do this by checking the invisibility of the + ;; characters from `notmuch-show-message-bottom' towards the start + ;; of the message. When we find a non-invisible character, we test + ;; to see whether it is visible in the window (i.e. less than + ;; `window-end'). + + ((let* ((visible-bottom (notmuch-show-message-bottom)) + (visible-bottom + (save-excursion + (goto-char visible-bottom) + (while (invisible-p (point)) + (backward-char)) + (point + (> visible-bottom (window-end))) +;; The end of this message is not visible - scroll. +(scroll-up) +nil) + + (t +;; Show the start of the next message. +(notmuch-show-next-open-message) +nil))) (defun notmuch-show-advance-and-archive () "Advance through thread and archive. @@ -1201,44 +1214,39 @@ from each message), kills the buffer, and displays the next thread from the search from which this thread was originally shown." (interactive) - (if (notmuch-show-advance) - (notmuch-show-archive-thread))) + (when (notmuch-show-advance) +(notmuch-show-archive-thread))) (defun notmuch-show-rewind () - "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + "Move backwards through a thread, the counterpart to \\[notmuch-show-advance-and-archive]." -Specifically, if the beginning of the previous email is fewer -than `window-height' lines from the current point, move to it -just like `notmuch-show-previous-message'. - -Otherwise, just scroll down a screenful of the current message. - -This command does not modify any message tags, (it does not undo -any effects from previous calls to -`notmuch-show-advance-and-archive'." (interactive) - (let ((start-of-message (notmuch-show-message-top)) - (start-of-window (window-start))) + (let ((start-of-message (notmuch-show-message-top))) (cond - ;; Either this message is properly aligned with the start of the - ;; window or the start of this message is not visible on the - ;; screen - scroll. - ((or (= start-of-message star
[PATCH] Properly handle short writes in sigint handlers
Even if we don't care about errors from write(2), it's still necessary
to handle short writes in order to use write correctly. Some versions
of glibc even mark write as warn_unused_result because of this, so our
previous usage would trigger compiler warnings.
---
notmuch-new.c |5 -
notmuch-tag.c |6 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 3512de7..fc09bbb 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -66,8 +66,11 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
+const char *pos = msg, *end = msg + sizeof (msg) - 1;
+ssize_t c = 0;
-(void) write(2, msg, sizeof(msg)-1);
+for (; pos < end && c >= 0; pos += c)
+ c = write (2, pos, end - pos);
interrupted = 1;
}
diff --git a/notmuch-tag.c b/notmuch-tag.c
index 292c5da..0d4873d 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -26,7 +26,11 @@ static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
-(void) write(2, msg, sizeof(msg)-1);
+const char *pos = msg, *end = msg + sizeof (msg) - 1;
+ssize_t c = 0;
+
+for (; pos < end && c >= 0; pos += c)
+ c = write (2, pos, end - pos);
interrupted = 1;
}
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
Quoth David Edmondson on Dec 22 at 7:25 pm:
> On Thu, 22 Dec 2011 14:03:05 -0500, Austin Clements wrote:
> > > In general I agree, but what would we do if writing an error message to
> > > stderr fails?
> >
> > This was discussed on IRC, but calls to write(2) should never be bare.
> > I believe it's marked warn_unused_result not because libc is so
> > concerned with people checking for error returns (otherwise all sorts
> > of things would be marked warn_unused_result) but because even a
> > successful write can be a short write. Hence, not checking the result
> > is a bug, even if you don't care about errors.
>
> As I said, the principle is sound. What would do in this specific case?
>
> static void
> handle_sigint (unused (int sig))
> {
> static char msg[] = "Stopping... \n";
>
> write(2, msg, sizeof(msg)-1);
> interrupted = 1;
> }
>
> Just this?
>
> if (write(2, msg, sizeof(msg)-1) {
> /* Appease the compiler. */;
> }
Maybe I missed something, but what's wrong with using a standard write
loop (like j4ni suggested on IRC)? In my mind this isn't about
appeasing the compiler; the compiler is pointing out a real bug.
Patch coming in a moment...
I'm not sure what to do about the specific case of fwrite, though
judging by
http://sourceware.org/bugzilla/show_bug.cgi?id=11959
I'm not the only person who thinks that fwrite being
warn_unused_result is odd.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
On Thu, 22 Dec 2011 19:25:59 +, David Edmondson wrote:
> if (write(2, msg, sizeof(msg)-1) {
Sigh.
if (write(2, msg, sizeof(msg)-1) != sizeof(msg)-1) {
pgpPz75aviMiw.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
The advance/rewind functions had become complex, which made it hard to determine who they are expected to behave. Re-implement them simply in order to poll user-experience and expectation. --- This is intended to be for discussion! The current rewind implementation didn't behave as I expected, so I re-wrote it. The current advance implementation doesn't work if an open message within a thread ends with hidden text (e.g. a signature) (I suspect that relates do the end of the message and the signature having different invisible properties, but didn't check that) and was complicated, so I wrote a simpler version. My aim was not to replicate the current behaviour perfectly, rather to produce something that did what seemed reasonable. Your mileage may vary. This doesn't currently pass the test suite. We might decide that's a bug in the suite, of course. emacs/notmuch-show.el | 104 + 1 files changed, 45 insertions(+), 59 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 46525aa..ab1e89f 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1156,38 +1156,29 @@ Some useful entries are: ;; Commands typically bound to keys. (defun notmuch-show-advance () - "Advance through thread. + "Advance through the current thread. -If the current message in the thread is not yet fully visible, -scroll by a near screenful to read more of the message. +Scroll the current message if the end of it is not visible, +otherwise move to the next message. -Otherwise, (the end of the current message is already within the -current window), advance to the next open message." +Return `t' if we are at the end of the last message, otherwise +`nil'." (interactive) - (let* ((end-of-this-message (notmuch-show-message-bottom)) -(visible-end-of-this-message (1- end-of-this-message)) -(ret nil)) -(while (invisible-p visible-end-of-this-message) - (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) -(cond - ;; Ideally we would test `end-of-this-message' against the result - ;; of `window-end', but that doesn't account for the fact that - ;; the end of the message might be hidden. - ((and visible-end-of-this-message - (> visible-end-of-this-message (window-end))) - ;; The bottom of this message is not visible - scroll. - (scroll-up nil)) - - ((not (= end-of-this-message (point-max))) - ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - change the return value - (setq ret t))) -ret)) + (cond + ((eobp) +;; If we are at the end of the buffer then move to the next +;; thread. +t) + + ((> (notmuch-show-message-bottom) (window-end)) +;; The end of this message is not visible - scroll. +(scroll-up) +nil) + + (t +;; Show the start of the next message. +(notmuch-show-next-open-message) +nil))) (defun notmuch-show-advance-and-archive () "Advance through thread and archive. @@ -1201,44 +1192,39 @@ from each message), kills the buffer, and displays the next thread from the search from which this thread was originally shown." (interactive) - (if (notmuch-show-advance) - (notmuch-show-archive-thread))) + (when (notmuch-show-advance) +(notmuch-show-archive-thread))) (defun notmuch-show-rewind () - "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + "Move backwards through a thread, the counterpart to \\[notmuch-show-advance-and-archive]." -Specifically, if the beginning of the previous email is fewer -than `window-height' lines from the current point, move to it -just like `notmuch-show-previous-message'. - -Otherwise, just scroll down a screenful of the current message. - -This command does not modify any message tags, (it does not undo -any effects from previous calls to -`notmuch-show-advance-and-archive'." (interactive) - (let ((start-of-message (notmuch-show-message-top)) - (start-of-window (window-start))) + (let ((start-of-message (notmuch-show-message-top))) (cond - ;; Either this message is properly aligned with the start of the - ;; window or the start of this message is not visible on the - ;; screen - scroll. - ((or (= start-of-message start-of-window) - (< start-of-message start-of-window)) + ((= start-of-message (point)) + ;; If the cursor is at the start of the current message, move to + ;; the previous open message. + (notmuch-show-previous-open-message)) + + ((< start-of-message (window-start)) + ;; If the start of the current message is not visible, scroll + ;; down. (scroll-down) - ;; If a small number of lines from the previous messa
Re: [RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
On Thu, 22 Dec 2011 14:03:05 -0500, Austin Clements wrote:
> > In general I agree, but what would we do if writing an error message to
> > stderr fails?
>
> This was discussed on IRC, but calls to write(2) should never be bare.
> I believe it's marked warn_unused_result not because libc is so
> concerned with people checking for error returns (otherwise all sorts
> of things would be marked warn_unused_result) but because even a
> successful write can be a short write. Hence, not checking the result
> is a bug, even if you don't care about errors.
As I said, the principle is sound. What would do in this specific case?
static void
handle_sigint (unused (int sig))
{
static char msg[] = "Stopping... \n";
write(2, msg, sizeof(msg)-1);
interrupted = 1;
}
Just this?
if (write(2, msg, sizeof(msg)-1) {
/* Appease the compiler. */;
}
pgpD0SkqZ7Gwx.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
On Thu, 22 Dec 2011 13:32:15 +0400, Dmitry Kurochkin wrote: > Perhaps I am missing something here. But I do not get any warnings when > building with GCC 4.6.2 with -Wall -Werror (-O2 and -O0). I do not like > adding any complex hacks to make the build warning-free on old GCC > versions. If this happens on the build bot, we should just update it or > ignore the warnings. I don't see the warnings on my Debian testing system either. It would be good to understand what is running on the buildbot. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111222/0c948532/attachment.pgp>
Re: [RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
Quoth David Edmondson on Dec 22 at 7:21 am: > On Thu, 22 Dec 2011 02:03:45 -0500, Austin Clements wrote: > > I must admit I haven't been following the warnings problem very > > closely, but perhaps we shouldn't be ignoring these return codes? > > In general I agree, but what would we do if writing an error message to > stderr fails? This was discussed on IRC, but calls to write(2) should never be bare. I believe it's marked warn_unused_result not because libc is so concerned with people checking for error returns (otherwise all sorts of things would be marked warn_unused_result) but because even a successful write can be a short write. Hence, not checking the result is a bug, even if you don't care about errors. fwrite's a little trickier, since it will only short-write on an error, so to me it seems perfectly legitimate to ignore the result if you don't care about errors. I don't seem to have whatever glibc version the buildbot does that marks these warn_unused_result, but I can reproduce it by adding __attribute__((warn_unused_result)) ssize_t write(int fd, const void *buf, size_t count); __attribute__((warn_unused_result)) size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream); to notmuch-client.h. Testing with these, if I add any form of result checking, even if it does nothing in most cases, GCC is quiet. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] test: add test for `notmuch-hello-refresh-hook'
On Wed, 21 Dec 2011 22:18:26 +0400, Dmitry Kurochkin wrote: > Test that `notmuch-hello-refresh-hook' is called once when > `notmuch-hello' is called and twice when calling > `notmuch-hello-update' after that. > > The tests are very similar to tests for `notmuch-hello-mode-hook'. +1 -- both patches. Tomi
Re: [alot] Introducing myself, asking various questions
On Sun, Dec 18, 2011 at 9:32 PM, Patrick Totzke wrote: >>.. however I have the >>impression that it may be trying to do too much for my needs, which may >>be peculiar. I have installed offlineimap+notmuch+alot on a slow laptop >>running Debian wheezy. > I guess most of us use offlineimap or getmail in combination > with notmuch. And Debian is also popular choice afaik, > so you're in good company :) Personally I prefer mbsync (isync) because it's much more efficient, and it's not written in python :) -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: put the last search on top of recent searches in notmuch-hello
On Thu, 22 Dec 2011 04:23:50 +0400, Dmitry Kurochkin wrote: > Notmuch-hello stores a list of recent searches. Before the change, if > a search from this list is repeated, the recent search list is not > changed. The patch makes repeated recent searches move to the head of > the list. I.e. the last search is always on top of the recent search > list, which is what one would expect from a history list. > --- +1 Tomi
[RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
David, Would the problem you had with previous-s-c-prop-change be fixed by the patch to the original function I sent in the thread starting at id:"m2y5u5cykp.fsf at kcals.intra.maillard.im" ? -- Aaron Ecay
[PATCH] emacs: fix off-by-one bug in notmuch-show-archive
Text properties change between characters; prev-s-c-property-change returns the position after the change. Thus, it is still inside the invisible region. --- emacs/notmuch-show.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index f52f233..905c9ec 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1169,8 +1169,9 @@ current window), advance to the next open message." (ret nil)) (while (invisible-p visible-end-of-this-message) (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) + (max (point-min) +(1- (previous-single-char-property-change + visible-end-of-this-message 'invisible) (cond ;; Ideally we would test `end-of-this-message' against the result ;; of `window-end', but that doesn't account for the fact that -- 1.7.8
[BUG?] Pressing SPACEbar is not doing what's expected.
Hi Jamie, On Wed, 21 Dec 2011 15:19:24 -0800, Jameson Graef Rollins wrote: > On Thu, 22 Dec 2011 00:08:38 +0100, Xavier Maillard wrote: > > What happens here is just what is described in paragraph 2. Although I > > am in situation described in first paragraph, pressing SPC just advance > > to next message and never scroll to see the next part of the current > > message. > > Hi, Xavier. I have noticed this as well, and it's definitely a bug and > not a feature (there's no way to change this behavior). I think it has > to do with there being hidden text at the end of the current message, > and notmuch somehow assuming that it is at the end of the message when > it's really not. Well, the good news is that I am not alone :D At the beginning, I thought it was me. > This issue has actually been addressed once, with a patch in fact [0]. > However, somehow my patch to split the "and-archive" bit out of the > notmuch-show-advance-and-archive function [1] seems to have exposed a > problem. I hope you (notmuch hackers) will find a solution to this bug. Take care guys and thank you for such an awesome tool ! /Xavier
[PATCH v2 1/2] emacs: Fix notmuch-hello-tag-list-make-query defcustom
On Tue, 20 Dec 2011 21:53:13 +0200, Jani Nikula wrote: > It was not possible to define custom filters or filter functions because > the types were const. Remove const to allow editing. Pushed both. d
[PATCH] emacs: put the last search on top of recent searches in notmuch-hello
On Thu, 22 Dec 2011 04:23:50 +0400, Dmitry Kurochkin wrote: > Notmuch-hello stores a list of recent searches. Before the change, if > a search from this list is repeated, the recent search list is not > changed. The patch makes repeated recent searches move to the head of > the list. Pushed. d
[PATCH 1/2] test: add general Emacs hook counter
On Wed, 21 Dec 2011 22:18:25 +0400, Dmitry Kurochkin wrote: > Replace `notmuch-hello-mode-hook-counter' with general `hook-counter' > and `add-hook-counter' functions to allow counting calls for any hook. Pushed, d
Re: [RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
On Thu, 22 Dec 2011 09:29:55 -0500, Aaron Ecay wrote: > Would the problem you had with previous-s-c-prop-change be fixed by the > patch to the original function I sent in the thread starting at > id:"m2y5u5cykp@kcals.intra.maillard.im" ? I think so, yes. Re-writing the new version I posted to use `previous-single-char-property-value' in the way that you describe: ((let ((visible-bottom (notmuch-show-message-bottom))) (while (invisible-p visible-bottom) (setq visible-bottom (max (point-min) (1- (previous-single-char-property-change visible-bottom 'invisible) (> visible-bottom (window-end))) ;; The end of this message is not visible - scroll. (scroll-up) nil) seems to work in quick testing. I'd vote to integrate your change if it seems correct to everyone else, then I'll argue for a re-write separately. pgpnOwSnhep3d.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] emacs: rename notmuch-decimal-separator to notmuch-hello-thousands-separator
On Wed, 21 Dec 2011 14:44:18 +0100, Thomas Jost wrote: > In 123,456.78, "." is the decimal separator, but "," is the thousands > separator. > --- This and the next one are both pushed. d
[PATCH] emacs: Don't prompt the user to choose from zero matching addresses.
On Wed, 21 Dec 2011 12:35:27 +, David Edmondson wrote: > If the address matching function generates no matches, don't prompt > the user to choose between them (!). Instead, generate a message to > report that there were no matches. pushed, d
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
On Thu, 22 Dec 2011 02:03:45 -0500, Austin Clements wrote: > I must admit I haven't been following the warnings problem very > closely, but perhaps we shouldn't be ignoring these return codes? In general I agree, but what would we do if writing an error message to stderr fails? dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111222/ce550721/attachment-0001.pgp>
have "notmuch help" call man?
On Wed, 21 Dec 2011 20:53:08 -0800, Jameson Graef Rollins wrote: > * There are a couple of formatting issues (notmuch.1, notmuch-config.1, > notmuch-reply.1). I'm sure there are. Can you be more specific? I suspect I might fix a different set of problems than you found ;). > * The notmuch part command is completely deprecated, so I don't think > there's really any reason to include a man page for it. I'm not sure if removing that would be "doing too many things at once"; it is in the current man page. But maybe that was an oversight? > * There's no man page for restore (notmuch-restore.1). Currently the symlink to notmuch-dump.1.gz is installed at runtime. I agree this is a bit inconvenient for testing; I think it should work to have symlinks in the source just for the convenience of testers. > It also occurs to me while looking through this: do we really need a > separate "setup" command? I guess notmuch-setup is a UI convenience mainly for people who want to re-run setup. It doesn't feel as natural to me to run notmuch without arguments in this case. I couldn't really justify that, though. Thanks for the review, David
[PATCH] emacs: put the last search on top of recent searches in notmuch-hello
On Thu, 22 Dec 2011 04:23:50 +0400, Dmitry Kurochkin wrote: > Notmuch-hello stores a list of recent searches. Before the change, if > a search from this list is repeated, the recent search list is not > changed. The patch makes repeated recent searches move to the head of > the list. I.e. the last search is always on top of the recent search > list, which is what one would expect from a history list. Looks good. dme. -- David Edmondson, http://dme.org -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111222/778bbeab/attachment.pgp>
Re: [RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
David, Would the problem you had with previous-s-c-prop-change be fixed by the patch to the original function I sent in the thread starting at id:"m2y5u5cykp@kcals.intra.maillard.im" ? -- Aaron Ecay ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: fix off-by-one bug in notmuch-show-archive
Text properties change between characters; prev-s-c-property-change returns the position after the change. Thus, it is still inside the invisible region. --- emacs/notmuch-show.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index f52f233..905c9ec 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1169,8 +1169,9 @@ current window), advance to the next open message." (ret nil)) (while (invisible-p visible-end-of-this-message) (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) + (max (point-min) +(1- (previous-single-char-property-change + visible-end-of-this-message 'invisible) (cond ;; Ideally we would test `end-of-this-message' against the result ;; of `window-end', but that doesn't account for the fact that -- 1.7.8 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [alot] announcing v0.2 aka. "robot santa"
Hi again, I have merged the packaging stuff to upstream master and moved the debian directory to /packaging. An include file for help2man as well as a generated man page for the upcomming release 0.21 can be found in /docs/man. Let me know if there's anything else I can do, /p ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH v3] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
The advance/rewind functions had become complex, which made it hard to determine who they are expected to behave. Re-implement them simply in order to poll user-experience and expectation. --- This one passes the test suite and, consequently, works better when the last open message in a thread has trailing invisible text. emacs/notmuch-show.el | 124 +--- 1 files changed, 65 insertions(+), 59 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 46525aa..9fec499 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1156,38 +1156,49 @@ Some useful entries are: ;; Commands typically bound to keys. (defun notmuch-show-advance () - "Advance through thread. + "Advance through the current thread. -If the current message in the thread is not yet fully visible, -scroll by a near screenful to read more of the message. +Scroll the current message if the end of it is not visible, +otherwise move to the next message. -Otherwise, (the end of the current message is already within the -current window), advance to the next open message." +Return `t' if we are at the end of the last message, otherwise +`nil'." (interactive) - (let* ((end-of-this-message (notmuch-show-message-bottom)) -(visible-end-of-this-message (1- end-of-this-message)) -(ret nil)) -(while (invisible-p visible-end-of-this-message) - (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) -(cond - ;; Ideally we would test `end-of-this-message' against the result - ;; of `window-end', but that doesn't account for the fact that - ;; the end of the message might be hidden. - ((and visible-end-of-this-message - (> visible-end-of-this-message (window-end))) - ;; The bottom of this message is not visible - scroll. - (scroll-up nil)) - - ((not (= end-of-this-message (point-max))) - ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - change the return value - (setq ret t))) -ret)) + (cond + ((eobp) +;; If we are at the end of the buffer then move to the next +;; thread. +t) + + ;; Ideally we would simply do: + ;; + ;; ((> (notmuch-show-message-bottom) (window-end)) + ;; + ;; here, but that fails if the trailing text in the buffer is + ;; invisible (`window-end' returns the last visible character, + ;; which can then be smaller than `notmuch-show-message-bottom'). + ;; + ;; So we need to find the last _visible_ character of the + ;; message. We do this by checking the invisibility of the + ;; characters from `notmuch-show-message-bottom'-1 towards the start + ;; of the message. When we find a non-invisible character, we test + ;; to see whether it is visible in the window. + + ((let ((visible-bottom + (save-excursion +(goto-char (1- (notmuch-show-message-bottom))) +(while (invisible-p (point)) + (backward-char)) +(point + (> visible-bottom (window-end))) +;; The end of this message is not visible - scroll. +(scroll-up) +nil) + + (t +;; Show the start of the next message. +(notmuch-show-next-open-message) +nil))) (defun notmuch-show-advance-and-archive () "Advance through thread and archive. @@ -1201,44 +1212,39 @@ from each message), kills the buffer, and displays the next thread from the search from which this thread was originally shown." (interactive) - (if (notmuch-show-advance) - (notmuch-show-archive-thread))) + (when (notmuch-show-advance) +(notmuch-show-archive-thread))) (defun notmuch-show-rewind () - "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + "Move backwards through a thread, the counterpart to \\[notmuch-show-advance-and-archive]." -Specifically, if the beginning of the previous email is fewer -than `window-height' lines from the current point, move to it -just like `notmuch-show-previous-message'. - -Otherwise, just scroll down a screenful of the current message. - -This command does not modify any message tags, (it does not undo -any effects from previous calls to -`notmuch-show-advance-and-archive'." (interactive) - (let ((start-of-message (notmuch-show-message-top)) - (start-of-window (window-start))) + (let ((start-of-message (notmuch-show-message-top))) (cond - ;; Either this message is properly aligned with the start of the - ;; window or the start of this message is not visible on the - ;; screen - scroll. - ((or (= start-of-message start-of-window) - (< start-of-message start-of-window)) + ((= start-of-message (point)) + ;; If the cursor is at the start of the current messa
[PATCH] emacs: put the last search on top of recent searches in notmuch-hello
Notmuch-hello stores a list of recent searches. Before the change, if a search from this list is repeated, the recent search list is not changed. The patch makes repeated recent searches move to the head of the list. I.e. the last search is always on top of the recent search list, which is what one would expect from a history list. --- emacs/notmuch-hello.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index f892ff7..2fb0cfc 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -154,8 +154,9 @@ Typically \",\" in the US and UK and \".\" in Europe." (defvar notmuch-hello-recent-searches nil) (defun notmuch-hello-remember-search (search) - (if (not (member search notmuch-hello-recent-searches)) - (push search notmuch-hello-recent-searches)) + (setq notmuch-hello-recent-searches + (delete search notmuch-hello-recent-searches)) + (push search notmuch-hello-recent-searches) (if (> (length notmuch-hello-recent-searches) notmuch-recent-searches-max) (setq notmuch-hello-recent-searches (butlast notmuch-hello-recent-searches -- 1.7.7.3
[RFC][PATCH v2] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
The advance/rewind functions had become complex, which made it hard to determine who they are expected to behave. Re-implement them simply in order to poll user-experience and expectation. --- Re-introduce the detection of invisible trailers. Using `previous-single-char-property-change' just didn't work in my testing, so back to the original approach. Dmitry: can you explain why you needed to change it? emacs/notmuch-show.el | 126 ++--- 1 files changed, 67 insertions(+), 59 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 46525aa..258814e 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1156,38 +1156,51 @@ Some useful entries are: ;; Commands typically bound to keys. (defun notmuch-show-advance () - "Advance through thread. + "Advance through the current thread. -If the current message in the thread is not yet fully visible, -scroll by a near screenful to read more of the message. +Scroll the current message if the end of it is not visible, +otherwise move to the next message. -Otherwise, (the end of the current message is already within the -current window), advance to the next open message." +Return `t' if we are at the end of the last message, otherwise +`nil'." (interactive) - (let* ((end-of-this-message (notmuch-show-message-bottom)) -(visible-end-of-this-message (1- end-of-this-message)) -(ret nil)) -(while (invisible-p visible-end-of-this-message) - (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) -(cond - ;; Ideally we would test `end-of-this-message' against the result - ;; of `window-end', but that doesn't account for the fact that - ;; the end of the message might be hidden. - ((and visible-end-of-this-message - (> visible-end-of-this-message (window-end))) - ;; The bottom of this message is not visible - scroll. - (scroll-up nil)) - - ((not (= end-of-this-message (point-max))) - ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - change the return value - (setq ret t))) -ret)) + (cond + ((eobp) +;; If we are at the end of the buffer then move to the next +;; thread. +t) + + ;; Ideally we would simply do: + ;; + ;; ((> (notmuch-show-message-bottom) (window-end)) + ;; + ;; here, but that fails if the trailing text in the buffer is + ;; invisible (`window-end' returns the last visible character, + ;; which can then be smaller than `notmuch-show-message-bottom'). + ;; + ;; So we need to find the last _visible_ character of the + ;; message. We do this by checking the invisibility of the + ;; characters from `notmuch-show-message-bottom' towards the start + ;; of the message. When we find a non-invisible character, we test + ;; to see whether it is visible in the window (i.e. less than + ;; `window-end'). + + ((let* ((visible-bottom (notmuch-show-message-bottom)) + (visible-bottom + (save-excursion + (goto-char visible-bottom) + (while (invisible-p (point)) + (backward-char)) + (point + (> visible-bottom (window-end))) +;; The end of this message is not visible - scroll. +(scroll-up) +nil) + + (t +;; Show the start of the next message. +(notmuch-show-next-open-message) +nil))) (defun notmuch-show-advance-and-archive () "Advance through thread and archive. @@ -1201,44 +1214,39 @@ from each message), kills the buffer, and displays the next thread from the search from which this thread was originally shown." (interactive) - (if (notmuch-show-advance) - (notmuch-show-archive-thread))) + (when (notmuch-show-advance) +(notmuch-show-archive-thread))) (defun notmuch-show-rewind () - "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + "Move backwards through a thread, the counterpart to \\[notmuch-show-advance-and-archive]." -Specifically, if the beginning of the previous email is fewer -than `window-height' lines from the current point, move to it -just like `notmuch-show-previous-message'. - -Otherwise, just scroll down a screenful of the current message. - -This command does not modify any message tags, (it does not undo -any effects from previous calls to -`notmuch-show-advance-and-archive'." (interactive) - (let ((start-of-message (notmuch-show-message-top)) - (start-of-window (window-start))) + (let ((start-of-message (notmuch-show-message-top))) (cond - ;; Either this message is properly aligned with the start of the - ;; window or the start of this message is not visible on the - ;; screen - scroll. - ((or (= start-of-messag
Re: [PATCH v2 1/2] emacs: Fix notmuch-hello-tag-list-make-query defcustom
On Tue, 20 Dec 2011 21:53:13 +0200, Jani Nikula wrote: > It was not possible to define custom filters or filter functions because > the types were const. Remove const to allow editing. Pushed both. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: put the last search on top of recent searches in notmuch-hello
On Thu, 22 Dec 2011 04:23:50 +0400, Dmitry Kurochkin wrote: > Notmuch-hello stores a list of recent searches. Before the change, if > a search from this list is repeated, the recent search list is not > changed. The patch makes repeated recent searches move to the head of > the list. Pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] test: add general Emacs hook counter
On Wed, 21 Dec 2011 22:18:25 +0400, Dmitry Kurochkin wrote: > Replace `notmuch-hello-mode-hook-counter' with general `hook-counter' > and `add-hook-counter' functions to allow counting calls for any hook. Pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] emacs: Re-implement advance/rewind functions of notmuch-show-mode.
The advance/rewind functions had become complex, which made it hard to determine who they are expected to behave. Re-implement them simply in order to poll user-experience and expectation. --- This is intended to be for discussion! The current rewind implementation didn't behave as I expected, so I re-wrote it. The current advance implementation doesn't work if an open message within a thread ends with hidden text (e.g. a signature) (I suspect that relates do the end of the message and the signature having different invisible properties, but didn't check that) and was complicated, so I wrote a simpler version. My aim was not to replicate the current behaviour perfectly, rather to produce something that did what seemed reasonable. Your mileage may vary. This doesn't currently pass the test suite. We might decide that's a bug in the suite, of course. emacs/notmuch-show.el | 104 + 1 files changed, 45 insertions(+), 59 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 46525aa..ab1e89f 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1156,38 +1156,29 @@ Some useful entries are: ;; Commands typically bound to keys. (defun notmuch-show-advance () - "Advance through thread. + "Advance through the current thread. -If the current message in the thread is not yet fully visible, -scroll by a near screenful to read more of the message. +Scroll the current message if the end of it is not visible, +otherwise move to the next message. -Otherwise, (the end of the current message is already within the -current window), advance to the next open message." +Return `t' if we are at the end of the last message, otherwise +`nil'." (interactive) - (let* ((end-of-this-message (notmuch-show-message-bottom)) -(visible-end-of-this-message (1- end-of-this-message)) -(ret nil)) -(while (invisible-p visible-end-of-this-message) - (setq visible-end-of-this-message - (previous-single-char-property-change visible-end-of-this-message - 'invisible))) -(cond - ;; Ideally we would test `end-of-this-message' against the result - ;; of `window-end', but that doesn't account for the fact that - ;; the end of the message might be hidden. - ((and visible-end-of-this-message - (> visible-end-of-this-message (window-end))) - ;; The bottom of this message is not visible - scroll. - (scroll-up nil)) - - ((not (= end-of-this-message (point-max))) - ;; This is not the last message - move to the next visible one. - (notmuch-show-next-open-message)) - - (t - ;; This is the last message - change the return value - (setq ret t))) -ret)) + (cond + ((eobp) +;; If we are at the end of the buffer then move to the next +;; thread. +t) + + ((> (notmuch-show-message-bottom) (window-end)) +;; The end of this message is not visible - scroll. +(scroll-up) +nil) + + (t +;; Show the start of the next message. +(notmuch-show-next-open-message) +nil))) (defun notmuch-show-advance-and-archive () "Advance through thread and archive. @@ -1201,44 +1192,39 @@ from each message), kills the buffer, and displays the next thread from the search from which this thread was originally shown." (interactive) - (if (notmuch-show-advance) - (notmuch-show-archive-thread))) + (when (notmuch-show-advance) +(notmuch-show-archive-thread))) (defun notmuch-show-rewind () - "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]). + "Move backwards through a thread, the counterpart to \\[notmuch-show-advance-and-archive]." -Specifically, if the beginning of the previous email is fewer -than `window-height' lines from the current point, move to it -just like `notmuch-show-previous-message'. - -Otherwise, just scroll down a screenful of the current message. - -This command does not modify any message tags, (it does not undo -any effects from previous calls to -`notmuch-show-advance-and-archive'." (interactive) - (let ((start-of-message (notmuch-show-message-top)) - (start-of-window (window-start))) + (let ((start-of-message (notmuch-show-message-top))) (cond - ;; Either this message is properly aligned with the start of the - ;; window or the start of this message is not visible on the - ;; screen - scroll. - ((or (= start-of-message start-of-window) - (< start-of-message start-of-window)) + ((= start-of-message (point)) + ;; If the cursor is at the start of the current message, move to + ;; the previous open message. + (notmuch-show-previous-open-message)) + + ((< start-of-message (window-start)) + ;; If the start of the current message is not visible, scroll + ;; down. (scroll-down) - ;; If a small number of lines from the previous
Re: [PATCH 1/2] emacs: rename notmuch-decimal-separator to notmuch-hello-thousands-separator
On Wed, 21 Dec 2011 14:44:18 +0100, Thomas Jost wrote: > In 123,456.78, "." is the decimal separator, but "," is the thousands > separator. > --- This and the next one are both pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Don't prompt the user to choose from zero matching addresses.
On Wed, 21 Dec 2011 12:35:27 +, David Edmondson wrote: > If the address matching function generates no matches, don't prompt > the user to choose between them (!). Instead, generate a message to > report that there were no matches. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
On Thu, 22 Dec 2011 13:32:15 +0400, Dmitry Kurochkin wrote: > Perhaps I am missing something here. But I do not get any warnings when > building with GCC 4.6.2 with -Wall -Werror (-O2 and -O0). I do not like > adding any complex hacks to make the build warning-free on old GCC > versions. If this happens on the build bot, we should just update it or > ignore the warnings. I don't see the warnings on my Debian testing system either. It would be good to understand what is running on the buildbot. pgpQBWKlwsLfj.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: have "notmuch help" call man?
On Wed, 21 Dec 2011 20:53:08 -0800, Jameson Graef Rollins wrote: > * There are a couple of formatting issues (notmuch.1, notmuch-config.1, > notmuch-reply.1). I'm sure there are. Can you be more specific? I suspect I might fix a different set of problems than you found ;). > * The notmuch part command is completely deprecated, so I don't think > there's really any reason to include a man page for it. I'm not sure if removing that would be "doing too many things at once"; it is in the current man page. But maybe that was an oversight? > * There's no man page for restore (notmuch-restore.1). Currently the symlink to notmuch-dump.1.gz is installed at runtime. I agree this is a bit inconvenient for testing; I think it should work to have symlinks in the source just for the convenience of testers. > It also occurs to me while looking through this: do we really need a > separate "setup" command? I guess notmuch-setup is a UI convenience mainly for people who want to re-run setup. It doesn't feel as natural to me to run notmuch without arguments in this case. I couldn't really justify that, though. Thanks for the review, David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
I must admit I haven't been following the warnings problem very
closely, but perhaps we shouldn't be ignoring these return codes?
Quoth David Edmondson on Dec 21 at 9:38 pm:
> ---
>
> The mechanism used here works for me in an isolated test case and no
> warnings appear when using it as below, but I'm unsure why the
> original warning that it is intended to address didn't appear when I
> build. Any thoughts?
>
> compat/compat.h |6 ++
> notmuch-new.c |2 +-
> notmuch-show.c |2 +-
> notmuch-tag.c |2 +-
> 4 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/compat/compat.h b/compat/compat.h
> index 7767fe8..1160301 100644
> --- a/compat/compat.h
> +++ b/compat/compat.h
> @@ -30,6 +30,12 @@
> extern "C" {
> #endif
>
> +#ifdef __GNUC__
> +#define ignore_result(x) ({ __typeof__(x) z = x; (void) sizeof (z); })
> +#else /* !__GNUC__ */
> +#define ignore_result(x) x
> +#endif /* __GNUC__ */
> +
> #if !HAVE_GETLINE
> #include
> #include
> diff --git a/notmuch-new.c b/notmuch-new.c
> index 3512de7..0ac04cc 100644
> --- a/notmuch-new.c
> +++ b/notmuch-new.c
> @@ -67,7 +67,7 @@ handle_sigint (unused (int sig))
> {
> static char msg[] = "Stopping... \n";
>
> -(void) write(2, msg, sizeof(msg)-1);
> +ignore_result(write(STDERR_FILENO, msg, sizeof(msg)-1));
> interrupted = 1;
> }
>
> diff --git a/notmuch-show.c b/notmuch-show.c
> index 19fb49f..681f778 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -866,7 +866,7 @@ do_show_single (void *ctx,
>
> while (!feof (file)) {
> size = fread (buf, 1, sizeof (buf), file);
> - (void) fwrite (buf, size, 1, stdout);
> + ignore_result(fwrite (buf, size, 1, stdout));
> }
>
> fclose (file);
> diff --git a/notmuch-tag.c b/notmuch-tag.c
> index 292c5da..2cbfdc3 100644
> --- a/notmuch-tag.c
> +++ b/notmuch-tag.c
> @@ -26,7 +26,7 @@ static void
> handle_sigint (unused (int sig))
> {
> static char msg[] = "Stopping... \n";
> -(void) write(2, msg, sizeof(msg)-1);
> +ignore_result(write(STDERR_FILENO, msg, sizeof(msg)-1));
> interrupted = 1;
> }
>
[PATCH 2/2] test: add test for `notmuch-hello-refresh-hook'
On Wed, 21 Dec 2011 22:49:13 +0100, Thomas Jost wrote: > On Wed, 21 Dec 2011 22:18:26 +0400, Dmitry Kurochkin gmail.com> wrote: > > Test that `notmuch-hello-refresh-hook' is called once when > > `notmuch-hello' is called and twice when calling > > `notmuch-hello-update' after that. > > > > The tests are very similar to tests for `notmuch-hello-mode-hook'. > > Quite nice, better than what I sent earlier [1] :) > > However I'm not sure that notmuch-hello.el is the right place for this > kind of stuff; notmuch-lib.el may be better (so that it can also be used > in other hooks. > These patches do not touch notmuch-hello.el. The functions are added to test/test-lib.el. Regards, Dmitry > Regards, > Thomas > > [1] id:"1324473189-8622-1-git-send-email-schnouki at schnouki.net" > > > > --- > > test/emacs | 19 +++ > > test/test-lib.el |1 + > > 2 files changed, 20 insertions(+), 0 deletions(-) > > > > diff --git a/test/emacs b/test/emacs > > index dffad0f..ca82445 100755 > > --- a/test/emacs > > +++ b/test/emacs > > @@ -495,4 +495,23 @@ counter=$(test_emacs \ > > ) > > test_expect_equal "$counter" 1 > > > > +test_begin_subtest "notmuch-hello-refresh hook is called" > > +counter=$(test_emacs \ > > +'(let ((notmuch-hello-refresh-hook-counter 0)) > > + (kill-buffer "*notmuch-hello*") > > + (notmuch-hello) > > + notmuch-hello-refresh-hook-counter)' > > +) > > +test_expect_equal "$counter" 1 > > + > > +test_begin_subtest "notmuch-hello-refresh hook is called on updates" > > +counter=$(test_emacs \ > > +'(let ((notmuch-hello-refresh-hook-counter 0)) > > + (kill-buffer "*notmuch-hello*") > > + (notmuch-hello) > > + (notmuch-hello-update) > > + notmuch-hello-refresh-hook-counter)' > > +) > > +test_expect_equal "$counter" 2 > > + > > test_done > > diff --git a/test/test-lib.el b/test/test-lib.el > > index 83b8a65..3b817c3 100644 > > --- a/test/test-lib.el > > +++ b/test/test-lib.el > > @@ -75,3 +75,4 @@ nothing." > >(add-hook hook (apply-partially 'hook-counter hook))) > > > > (add-hook-counter 'notmuch-hello-mode-hook) > > +(add-hook-counter 'notmuch-hello-refresh-hook) > > -- > > 1.7.7.3 > > > > ___ > > notmuch mailing list > > notmuch at notmuchmail.org > > http://notmuchmail.org/mailman/listinfo/notmuch > > -- > Thomas/Schnouki
Re: [RFC][PATCH] notmuch: Workaround to allow ignoring non-void function return.
Hi David. Perhaps I am missing something here. But I do not get any warnings when building with GCC 4.6.2 with -Wall -Werror (-O2 and -O0). I do not like adding any complex hacks to make the build warning-free on old GCC versions. If this happens on the build bot, we should just update it or ignore the warnings. Regards, Dmitry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: add test for `notmuch-hello-refresh-hook'
On Wed, 21 Dec 2011 22:18:26 +0400, Dmitry Kurochkin wrote: > Test that `notmuch-hello-refresh-hook' is called once when > `notmuch-hello' is called and twice when calling > `notmuch-hello-update' after that. > > The tests are very similar to tests for `notmuch-hello-mode-hook'. +1 -- both patches. Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[BUG?] Pressing SPACEbar is not doing what's expected.
Hi, I recently upgraded my notmuch installation here (passing from 0.6 or such to latest 0.10.x series). Problem is now, pressing SPACE in a notmuch-show buffer no longer scroll in the message as it used to do. SPC is bound to run command notmuch-show-advance-and-archive and its docstring says: This command is intended to be one of the simplest ways to process a thread of email. It does the following: If the current message in the thread is not yet fully visible, scroll by a near screenful to read more of the message. Otherwise, (the end of the current message is already within the current window), advance to the next open message. Finally, if there is no further message to advance to, and this last message is already read, then archive the entire current thread, (remove the "inbox" tag from each message). Also kill this buffer, and display the next thread from the search from which this thread was originally shown. What happens here is just what is described in paragraph 2. Although I am in situation described in first paragraph, pressing SPC just advance to next message and never scroll to see the next part of the current message. How can I change this behaviour ? Does I need to do something in my .emacs file ? Thank you very much. /Xavier
