Hi David,
* David Bremner [24. Jan. 2014]:
> Mark Walters writes:
>> I have looked at this and I think this is not notmuch's fault: I think
>> it is a mua doing strange things:
>>
>> One of the mails has an in-reply-to header which looks like
>>
>> In-reply-to: Message from Carsten Dominik of
On Sun, Jan 26 2014, Jani Nikula wrote:
> This does not cover all the possible paths notmuch new could output
> stuff, but it's better than nothing.
> ---
LGTM.
Tomi
> test/T050-new.sh | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/test/T050-new.sh
On Sun, Jan 26 2014, Mark Walters wrote:
> I don't have anything older than 23.4 anymore so I am afraid I can't
> test. My recollection is that I upgraded to 23.4 the problem went away
> so I forgot about it.
Fine, I prepare and test the patch then ;/
Tomi
> (I couldn't see easily what
On Sun, Jan 26 2014, David Bremner wrote:
> We cache the result so that we can call the function many places
> without worrying about the cost.
> ---
> thanks to Tomi for catching the typos (uncommitted changes on my end).
Series LGTM.
Tomi
>
> emacs/notmuch-lib.el | 11 +++
> 1 file
This does not cover all the possible paths notmuch new could output
stuff, but it's better than nothing.
---
test/T050-new.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/T050-new.sh b/test/T050-new.sh
index f27423d..b7668ff 100755
--- a/test/T050-new.sh
+++
Hi
I experimented with this and it didn't always seem to rebuild VERSION
when it should. Looking at the file .git/HEAD that just seems to be the
branch name not the commit id (unless in detached HEAD state)
This link
Gregor Zattler writes:
> Today I produced another mbox with the very same command but with
> a now larger email corpus freshly indexed with a fresh notmuch.
> The mbox contains (according to mutt) 507 messages in 34 threads.
> One of them is the thread I searched for.
>
> I grepped for the 7
This version LGTM +1.
(Just for the record there was some discussion on irc about switching to
the *notmuch errors* buffer but that is more complex and fragile so
let's go with this simple and effective solution.)
Best wishes
Mark
On Sun, 26 Jan 2014, David Bremner wrote:
> We cache the
I don't have anything older than 23.4 anymore so I am afraid I can't
test. My recollection is that I upgraded to 23.4 the problem went away
so I forgot about it.
(I couldn't see easily what version of emacs debian stable has now as
seemed to be called 45.)
Best wishes
Mark
On Sat, 25 Jan
LGTM +1.
Best wishes
Mark
On Sun, 26 Jan 2014, Jani Nikula wrote:
> This does not cover all the possible paths notmuch new could output
> stuff, but it's better than nothing.
> ---
> test/T050-new.sh | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/test/T050-new.sh
We cache the result so that we can call the function many places
without worrying about the cost.
---
thanks to Tomi for catching the typos (uncommitted changes on my end).
emacs/notmuch-lib.el | 11 +++
1 file changed, 11 insertions(+)
diff --git a/emacs/notmuch-lib.el
This is meant to be the friendly entrypoint, so let's do something
better than the mangled output described in
id:5228989D.8030607 at fifthhorseman.net
---
emacs/notmuch-hello.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index
If the CLI seems borked, signal an error, and log a suggestion for the
user about how to recover.
---
emacs/notmuch-lib.el | 7 +++
1 file changed, 7 insertions(+)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index dcdfbdc..c195652 100644
--- a/emacs/notmuch-lib.el
+++
We cache the result so that we can call the function many places
without worrying about the cost.
---
emacs/notmuch-lib.el | 11 +++
1 file changed, 11 insertions(+)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 2be409b..dcdfbdc 100644
--- a/emacs/notmuch-lib.el
+++
Dear notmuch developers,
notmuch new quits operation if it hit's a dangling symlink:
Error reading file
/home/grfz/notmuch2/Mail/findex/cur/123456789.684055.mairix:2,: No such file or
directory
Note: A fatal error was encountered: Something went wrong trying
to read or write a file Processed
On Sun, Jan 26 2014, David Bremner wrote:
> Tomi Ollila writes:
>> +#if POSIX_2008_REALPATH
>> filename = realpath (config->filename, NULL);
>> +#else
>> +/* compatibility with minor effort, not elegance, is the ruling factor
>> + in these (two) else branches... */
>> +char
On Sun, Jan 26 2014, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> How about doing it with defadvice with something like:
>>
>> (from http://comments.gmane.org/gmane.emacs.bugs/27856 one can notice
>> this happening with emacs 23.3 -- David can check whether 23.4 if
>> affected)
>
> It's
Tomi Ollila writes:
>
> We could also create
>
> char * realpath2008 (const char * path, char * resolved_path)
> {
> if (resolved_path == NULL) {
> resolved_path = malloc (MAX_PATH);
> if (resolved_path == NULL)
> return NULL;
>
Gregor Zattler writes:
>
> I consider this to be a bug. Instead notmuch should simply
> ignore the symlink.
>
Since there is a test for specifically this behaviour, I'd have to say
it's a design decision you don't agree with, not a bug ;).
In any case, if there is just a few broken symlinks,
Jani Nikula writes:
> Here's an assortment of notmuch new fixes, non-functional cleanups, and
> the oft-requested --quiet option.
>
pushed. Would be nice to have a simple test for the --quiet option.
d
David Bremner writes:
> Clarify that using the directory after destroying the corresponding
> database is not permitted.
>
> This is implicit in the description of notmuch_database_destroy, but
> it doesn't hurt to be explicit, and we do express similar "ownership"
> relationships at other
Tomi Ollila writes:
> All implicit rules in notmuch Makefiles are "pattern rules"; Deleting the
> default suffixes (to support obsolete, old-fashioned "suffix rules") from
> make reduces the output of 'make -d' by 40 to 90 percent, helping e.g.
> debugging make problems.
pushed.
d
Tomi Ollila writes:
>
> (describe-variable 'minibuffer-setup-hook)
>
> -> (ido-minibuffer-setup rfn-eshadow-setup-minibuffer
> minibuffer-history-isearch-setup minibuffer-history-initialize)
>
> SO, although permanent, consistent w/ newer emacs versions...
>
Yeah, the other hook is set
This version file will be as prerequisite to the target files
that use the version info for some purpose, like printing
it to the user to examine. The contents of the VERSION file
is seldom read by the build system itself as the $(VERSION)
variable has the same information.
---
Makefile.local |
On Sat, Jan 25 2014, Tomi Ollila wrote:
> Check whether realpath(3) supports the resolved_path == NULL feature,
> standardized in POSIX.1-2008.
>
> This is tested by executing the realpath(3) with NULL as second
> argument and the program is expected to SIGSEGV in case the
> feature is not
On Sun, Jan 26 2014, David Bremner da...@tethera.net wrote:
Tomi Ollila tomi.oll...@iki.fi writes:
How about doing it with defadvice with something like:
(from http://comments.gmane.org/gmane.emacs.bugs/27856 one can notice
this happening with emacs 23.3 -- David can check whether 23.4 if
On Sun, Jan 26 2014, David Bremner da...@tethera.net wrote:
Tomi Ollila tomi.oll...@iki.fi writes:
+#if POSIX_2008_REALPATH
filename = realpath (config-filename, NULL);
+#else
+/* compatibility with minor effort, not elegance, is the ruling factor
+ in these (two) else
Dear notmuch developers,
notmuch new quits operation if it hit's a dangling symlink:
Error reading file
/home/grfz/notmuch2/Mail/findex/cur/123456789.684055.mairix:2,: No such file or
directory
Note: A fatal error was encountered: Something went wrong trying
to read or write a file Processed
Tomi Ollila tomi.oll...@iki.fi writes:
(describe-variable 'minibuffer-setup-hook)
- (ido-minibuffer-setup rfn-eshadow-setup-minibuffer
minibuffer-history-isearch-setup minibuffer-history-initialize)
SO, although permanent, consistent w/ newer emacs versions...
Yeah, the other hook is set
Tomi Ollila tomi.oll...@iki.fi writes:
All implicit rules in notmuch Makefiles are pattern rules; Deleting the
default suffixes (to support obsolete, old-fashioned suffix rules) from
make reduces the output of 'make -d' by 40 to 90 percent, helping e.g.
debugging make problems.
pushed.
d
David Bremner da...@tethera.net writes:
Clarify that using the directory after destroying the corresponding
database is not permitted.
This is implicit in the description of notmuch_database_destroy, but
it doesn't hurt to be explicit, and we do express similar ownership
relationships at
Jani Nikula j...@nikula.org writes:
Here's an assortment of notmuch new fixes, non-functional cleanups, and
the oft-requested --quiet option.
pushed. Would be nice to have a simple test for the --quiet option.
d
___
notmuch mailing list
Gregor Zattler telegr...@gmx.net writes:
I consider this to be a bug. Instead notmuch should simply
ignore the symlink.
Since there is a test for specifically this behaviour, I'd have to say
it's a design decision you don't agree with, not a bug ;).
In any case, if there is just a few
We cache the result so that we can call the function many places
without worrying about the cost.
---
emacs/notmuch-lib.el | 11 +++
1 file changed, 11 insertions(+)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 2be409b..dcdfbdc 100644
--- a/emacs/notmuch-lib.el
+++
This is meant to be the friendly entrypoint, so let's do something
better than the mangled output described in
id:5228989d.8030...@fifthhorseman.net
---
emacs/notmuch-hello.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index
If the CLI seems borked, signal an error, and log a suggestion for the
user about how to recover.
---
emacs/notmuch-lib.el | 7 +++
1 file changed, 7 insertions(+)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index dcdfbdc..c195652 100644
--- a/emacs/notmuch-lib.el
+++
This does not cover all the possible paths notmuch new could output
stuff, but it's better than nothing.
---
test/T050-new.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/T050-new.sh b/test/T050-new.sh
index f27423d..b7668ff 100755
--- a/test/T050-new.sh
+++
LGTM +1.
Best wishes
Mark
On Sun, 26 Jan 2014, Jani Nikula j...@nikula.org wrote:
This does not cover all the possible paths notmuch new could output
stuff, but it's better than nothing.
---
test/T050-new.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git
I don't have anything older than 23.4 anymore so I am afraid I can't
test. My recollection is that I upgraded to 23.4 the problem went away
so I forgot about it.
(I couldn't see easily what version of emacs debian stable has now as
seemed to be called 45.)
Best wishes
Mark
On Sat, 25 Jan
This version LGTM +1.
(Just for the record there was some discussion on irc about switching to
the *notmuch errors* buffer but that is more complex and fragile so
let's go with this simple and effective solution.)
Best wishes
Mark
On Sun, 26 Jan 2014, David Bremner da...@tethera.net wrote:
On Sun, Jan 26 2014, Mark Walters markwalters1...@gmail.com wrote:
I don't have anything older than 23.4 anymore so I am afraid I can't
test. My recollection is that I upgraded to 23.4 the problem went away
so I forgot about it.
Fine, I prepare and test the patch then ;/
Tomi
(I couldn't
Hi
I experimented with this and it didn't always seem to rebuild VERSION
when it should. Looking at the file .git/HEAD that just seems to be the
branch name not the commit id (unless in detached HEAD state)
This link
On Sun, Jan 26 2014, Jani Nikula j...@nikula.org wrote:
This does not cover all the possible paths notmuch new could output
stuff, but it's better than nothing.
---
LGTM.
Tomi
test/T050-new.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/T050-new.sh
David Bremner da...@tethera.net writes:
Michael Hudson-Doyle michael.hud...@canonical.com writes:
The attached gzipped mbox appears to trip up the emacs interface. The
problem seems to come from the message with id
CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2c...@mail.gmail.com.
I
Hi David,
* David Bremner da...@tethera.net [24. Jan. 2014]:
Mark Walters markwalters1...@gmail.com writes:
I have looked at this and I think this is not notmuch's fault: I think
it is a mua doing strange things:
One of the mails has an in-reply-to header which looks like
In-reply-to:
Gregor Zattler telegr...@gmx.net writes:
Today I produced another mbox with the very same command but with
a now larger email corpus freshly indexed with a fresh notmuch.
The mbox contains (according to mutt) 507 messages in 34 threads.
One of them is the thread I searched for.
I grepped
Hi David,
* David Bremner da...@tethera.net [26. Jan. 2014]:
Gregor Zattler telegr...@gmx.net writes:
I consider this to be a bug. Instead notmuch should simply
ignore the symlink.
Since there is a test for specifically this behaviour, I'd have to say
it's a design decision you don't
Hi David,
* David Bremner da...@tethera.net [26. Jan. 2014]:
Gregor Zattler telegr...@gmx.net writes:
Today I produced another mbox with the very same command but with
a now larger email corpus freshly indexed with a fresh notmuch.
The mbox contains (according to mutt) 507 messages in 34
48 matches
Mail list logo
