Hi
On Tue, 07 Oct 2014, Jesse Rosenthal jrosent...@jhu.edu wrote:
Currently the thread is named based on either the oldest or newest
matching message (depending on the search order). If this message has
an empty subject, though, the thread will show up with an empty
subject in the search
On Wed, Oct 29 2014, David Edmondson d...@dme.org wrote:
[lines dropped -- no way to open ;)]
space. Maybe that's because you need it in the following function to
separate the from/to/cc elements? That kind of interaction between the
two functions is icky.
[lines dropped -- no way to open
By the way, this discussion brings up another problem. I wasn't able to
write a test for this (to address the below concerns) because the test
suite for thread-naming supplies some sort of auto-generated subject
for threads with empty subjects. So we can't test behavior for dealing
with empty
dear all,
thanks for fruitful hints. Based on what you've done I have setup it as
follows:
1) the capture template, which uses clipboard buffer to setup the
data. So my org-capture-templates contains this entry:
(@ Email outgoing sync. USED INTERNALLY entry (file+datetree (concat
Thanks for taking a look.
Tomi Ollila tomi.oll...@iki.fi writes:
IMO it is a bit silly to scan through the whole string and use the return
value of 0 (vs != 0) to have effect. we should probably have something like
#define EMPTY_STRING(s) ((s)[0] == '\0')
and use that instead.
Good point.
a small correction. THIS:
(kill-new (concat [[notmuch:id: (replace-regexp-in-string []
msg-id) ][ (replace-regexp-in-string [\]\\[] _ subject) ]]))
is the correct way how to make the link and the subject into the kill
ring. The thing is, that subject must not contain [] (as e.g. [O]) so I
have
On Wed, Oct 29 2014, Jesse Rosenthal jrosent...@jhu.edu wrote:
By the way, this discussion brings up another problem. I wasn't able to
write a test for this (to address the below concerns) because the test
suite for thread-naming supplies some sort of auto-generated subject
for threads with
[I'm not sure why the below reply did not go to the list. Later replies
did, so I assume there must have been so problem in the sending. Mark,
apologies if you get this twice.]
Hi,
Thanks for taking a look at this.
Mark Walters markwalters1...@gmail.com writes:
I approve of the change in the
On Wed, Oct 29 2014, David Belohrad wrote:
- 'standard' behaviour is, that the email sent becomes read-only so with
'q' keystroke I can bury the buffer with the email. However when I
have implemented this, I have noticed that when I 'confirm' the
template, I go back into the buffer 'sent
Hi David,
yes. That works perfectly and solves both issues at the same time. Now
it is perfect!
.d.
David Edmondson d...@dme.org writes:
On Wed, Oct 29 2014, David Belohrad wrote:
- 'standard' behaviour is, that the email sent becomes read-only so with
'q' keystroke I can bury the
Hi,
Thanks for taking a look at this.
Mark Walters markwalters1...@gmail.com writes:
I approve of the change in the output but I am unsure about the
implementation. It would be nice to have a clear rule about which
subject is taken. Eg:
if sort is oldest first then it is the
When a user hits 'q' in a notmuch buffer, kill the buffer only if
there are no other windows currently showing it.
---
emacs/notmuch-lib.el | 13 +
emacs/notmuch-show.el | 2 +-
emacs/notmuch-tree.el | 2 +-
emacs/notmuch.el | 4 ++--
4 files changed, 13 insertions(+), 8
emacs: Improve the behaviour of the 'q' binding.
When a user hits 'q' in a notmuch buffer, kill the buffer only if
there are no other windows currently showing it.
v2:
- Change the name of `notmuch-kill-this-buffer' to be clearer.
David Edmondson (1):
emacs: Improve the behaviour of the 'q'
Hi
On Wed, 29 Oct 2014, Jesse Rosenthal jrosent...@jhu.edu wrote:
[I'm not sure why the below reply did not go to the list. Later replies
did, so I assume there must have been so problem in the sending. Mark,
apologies if you get this twice.]
Hi,
Thanks for taking a look at this.
Mark
Consider:
: disaster-area; notmuch search --output=files id:87hbph5yww@aw.hh.sledj.net
/home/dme/Maildir/mail/list/notmuch/xx01550
: disaster-area; notmuch search --duplicate=2 --output=files
id:87hbph5yww@aw.hh.sledj.net
: disaster-area; notmuch search --duplicate=2 --output=messages
Adding a terminal slash to a directory name when using --path causes the
search to fail. Removing the terminal slash produces results.
Given that many shells will add the terminal slash during completion,
this is lame(-ish).
___
notmuch mailing list
On Wed, Oct 29 2014, David Edmondson d...@dme.org wrote:
Adding a terminal slash to a directory name when using --path causes the
search to fail. Removing the terminal slash produces results.
Given that many shells will add the terminal slash during completion,
this is lame(-ish).
Except
Check the supported combination, and bail out for other combinations.
---
notmuch-search.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/notmuch-search.c b/notmuch-search.c
index bc9be4593ecc..3bb5a7fbc885 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -387,6 +387,11 @@
On Fri, 11 Jul 2014, Tomi Ollila tomi.oll...@iki.fi wrote:
Highlights:
* notmuch-emacs-mua without arguments runs (notmuch-hello)
* runs emacs(1) in case emacsclient(1) fails to connect to running emacs
* takes -nw option
* handles mailto:
* --from option when sending non-mailto: way
On Wed, 29 Oct 2014, David Edmondson d...@dme.org wrote:
On Tue, Oct 28 2014, Jani Nikula wrote:
Stash From/To/Cc as --to/--to/--cc, respectively, and Message-Id as
--in-reply-to, suitable for pasting to git send-email command line.
---
emacs/notmuch-show.el | 25 +
Currently the thread is named based on either the oldest or newest
matching message (depending on the search order). If this message has
an empty subject, though, the thread will show up with an empty
subject in the search results. (See the thread starting with
At the moment, the test-lib fills in any missing headers. This makes
it impossible to test our handling of empty subjects. This will
allow us to use a special dummy subject -- `@FORCE_EMPTY` -- to force
the subject to remain empty.
---
test/test-lib.sh | 2 ++
1 file changed, 2 insertions(+)
This is the second go at avoiding empty thread names. The differences
from the first version are:
* Compare empty strings by checking for '\0' in first character
(using a macro) as suggested by Tomi Ollila.
* Make sure that threads are titled correctly regardless of sorting
order. In
On Mon, Oct 27 2014, Michal Sojka wrote:
> Hi all,
>
> this is v4 of the search --output=address series. It obsoletes v3 that
> starts at id:1413150093-8383-1-git-send-email-sojkam1 at fel.cvut.cz.
>
> It addresses most comments made by Mark Walters and others. In
> addition to v3, it also
On Mon, Oct 20 2014, Jani Nikula wrote:
> Apparently the test binaries are built with minimal LDFLAGS, only
> adding dependency specific LDFLAGS as needed. However because some of
> the test binaries incorporate notmuch object files, it is necessary to
> use the same link flags as notmuch. For
On Tue, Oct 07 2014, Jesse Rosenthal wrote:
> Currently the thread is named based on either the oldest or newest
> matching message (depending on the search order). If this message has
> an empty subject, though, the thread will show up with an empty
> subject in the search results. (See the
Hi
On Tue, 07 Oct 2014, Jesse Rosenthal wrote:
> Currently the thread is named based on either the oldest or newest
> matching message (depending on the search order). If this message has
> an empty subject, though, the thread will show up with an empty
> subject in the search results. (See the
On Tue, Oct 28 2014, Jani Nikula wrote:
> Stash From/To/Cc as --to/--to/--cc, respectively, and Message-Id as
> --in-reply-to, suitable for pasting to git send-email command line.
> ---
> emacs/notmuch-show.el | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git
On Wed, Oct 29 2014, David Edmondson wrote:
> [lines dropped -- no way to open ;)]
> space. Maybe that's because you need it in the following function to
> separate the from/to/cc elements? That kind of interaction between the
> two functions is icky.
> [lines dropped -- no way to open ;)]
> to
By the way, this discussion brings up another problem. I wasn't able to
write a test for this (to address the below concerns) because the test
suite for thread-naming supplies some sort of auto-generated subject
for threads with empty subjects. So we can't test behavior for dealing
with empty
dear all,
thanks for fruitful hints. Based on what you've done I have setup it as
follows:
1) the capture template, which uses clipboard buffer to setup the
data. So my org-capture-templates contains this entry:
("@" "Email outgoing sync. USED INTERNALLY" entry (file+datetree (concat
Thanks for taking a look.
Tomi Ollila writes:
> IMO it is a bit silly to scan through the whole string and use the return
> value of 0 (vs != 0) to have effect. we should probably have something like
> #define EMPTY_STRING(s) ((s)[0] == '\0')
> and use that instead.
Good point. Will put in
Hmm, that's strange -- my inital detailed response to Mark's message
didn't go through to the list. I wonder if it's being filtered or
something.
a small correction. THIS:
(kill-new (concat "[[notmuch:id:" (replace-regexp-in-string "[<>]" ""
msg-id) "][" (replace-regexp-in-string "[\]\\[]" "_" subject) "]]"))
is the correct way how to make the link and the subject into the kill
ring. The thing is, that subject must not contain [] (as
On Wed, Oct 29 2014, Jesse Rosenthal wrote:
> By the way, this discussion brings up another problem. I wasn't able to
> write a test for this (to address the below concerns) because the test
> suite for thread-naming supplies some sort of auto-generated subject
> for threads with empty subjects.
[I'm not sure why the below reply did not go to the list. Later replies
did, so I assume there must have been so problem in the sending. Mark,
apologies if you get this twice.]
Hi,
Thanks for taking a look at this.
Mark Walters writes:
> I approve of the change in the output but I am unsure
On Wed, Oct 29 2014, David Belohrad wrote:
> - 'standard' behaviour is, that the email sent becomes read-only so with
> 'q' keystroke I can bury the buffer with the email. However when I
> have implemented this, I have noticed that when I 'confirm' the
> template, I go back into the buffer
Hi David,
yes. That works perfectly and solves both issues at the same time. Now
it is perfect!
.d.
David Edmondson writes:
> On Wed, Oct 29 2014, David Belohrad wrote:
>> - 'standard' behaviour is, that the email sent becomes read-only so with
>> 'q' keystroke I can bury the buffer with
Hi,
Thanks for taking a look at this.
Mark Walters writes:
> I approve of the change in the output but I am unsure about the
> implementation. It would be nice to have a clear rule about which
> subject is taken. Eg:
>
> if sort is oldest first then it is the subject of the oldest
>
emacs: Improve the behaviour of the 'q' binding.
When a user hits 'q' in a notmuch buffer, kill the buffer only if
there are no other windows currently showing it.
v2:
- Change the name of `notmuch-kill-this-buffer' to be clearer.
David Edmondson (1):
emacs: Improve the behaviour of the 'q'
When a user hits 'q' in a notmuch buffer, kill the buffer only if
there are no other windows currently showing it.
---
emacs/notmuch-lib.el | 13 +
emacs/notmuch-show.el | 2 +-
emacs/notmuch-tree.el | 2 +-
emacs/notmuch.el | 4 ++--
4 files changed, 13 insertions(+), 8
Hi
On Wed, 29 Oct 2014, Jesse Rosenthal wrote:
> [I'm not sure why the below reply did not go to the list. Later replies
> did, so I assume there must have been so problem in the sending. Mark,
> apologies if you get this twice.]
>
> Hi,
>
> Thanks for taking a look at this.
>
> Mark Walters
Consider:
: disaster-area; notmuch search --output=files id:87hbph5yww.fsf at
aw.hh.sledj.net
/home/dme/Maildir/mail/list/notmuch/xx01550
: disaster-area; notmuch search --duplicate=2 --output=files id:87hbph5yww.fsf
at aw.hh.sledj.net
: disaster-area; notmuch search --duplicate=2
Adding a terminal slash to a directory name when using --path causes the
search to fail. Removing the terminal slash produces results.
Given that many shells will add the terminal slash during completion,
this is lame(-ish).
This mail id:1405026779-29966-1-git-send-email-tomi.ollila at iki.fi
has not got much attention, probably due it is marked as 'draft'
and as it was not marked 'needs-review' in nmbug (this is now changed).
As the script is IMO in good condition (is IMO feature-complete and robust)
the draftness
On Wed, Oct 29 2014, David Edmondson wrote:
> Adding a terminal slash to a directory name when using --path causes the
> search to fail. Removing the terminal slash produces results.
>
> Given that many shells will add the terminal slash during completion,
> this is lame(-ish).
Except zsh(1)
Check the supported combination, and bail out for other combinations.
---
notmuch-search.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/notmuch-search.c b/notmuch-search.c
index bc9be4593ecc..3bb5a7fbc885 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -387,6 +387,11 @@
On Wed, 29 Oct 2014, David Edmondson wrote:
> Adding a terminal slash to a directory name when using --path causes the
> search to fail. Removing the terminal slash produces results.
I think you mean path:, not --path. Anyway, the reason for this
behaviour is that the path components are indexed
On Fri, 11 Jul 2014, Tomi Ollila wrote:
> Highlights:
>
> * notmuch-emacs-mua without arguments runs (notmuch-hello)
>
> * runs emacs(1) in case emacsclient(1) fails to connect to running emacs
>
> * takes -nw option
>
> * handles mailto:
>
> * --from option when sending non-mailto: way
>
> * -i
On Wed, 29 Oct 2014, David Edmondson wrote:
> On Tue, Oct 28 2014, Jani Nikula wrote:
>> Stash From/To/Cc as --to/--to/--cc, respectively, and Message-Id as
>> --in-reply-to, suitable for pasting to git send-email command line.
>> ---
>> emacs/notmuch-show.el | 25 +
>> 1
We test all empty subjects, and then empty subjects followed by
non-empty subjects (searching both oldest- and newest-first).
---
test/T200-thread-naming.sh | 32
1 file changed, 32 insertions(+)
diff --git a/test/T200-thread-naming.sh
Currently the thread is named based on either the oldest or newest
matching message (depending on the search order). If this message has
an empty subject, though, the thread will show up with an empty
subject in the search results. (See the thread starting with
At the moment, the test-lib fills in any missing headers. This makes
it impossible to test our handling of empty subjects. This will
allow us to use a special dummy subject -- `@FORCE_EMPTY` -- to force
the subject to remain empty.
---
test/test-lib.sh | 2 ++
1 file changed, 2 insertions(+)
This is the second go at avoiding empty thread names. The differences
from the first version are:
* Compare empty strings by checking for '\0' in first character
(using a macro) as suggested by Tomi Ollila.
* Make sure that threads are titled correctly regardless of sorting
order. In
54 matches
Mail list logo
