Re: Selection bug

Justus Winter writes: > David Bremner writes: > >> Justus Winter writes: >> >>> I think I found a reproducer: >>> >>> mkdir -p /tmp/selection-bug/{tmp,new,cur} >>> echo "[database] >>> path=/tmp/selection-bug" > /tm

Re: Selection bug

David Bremner writes: > Justus Winter writes: > >> I think I found a reproducer: >> >> mkdir -p /tmp/selection-bug/{tmp,new,cur} >> echo "[database] >> path=/tmp/selection-bug" > /tmp/selection-bug/notmuch-config >> NOTMUCH_CONFIG=/tmp/sel

Re: Selection bug

Hi David :) David Bremner writes: > Justus Winter writes: > >> there is a bug in notmuch emacs that is mildly annoying. Sometimes when >> I refresh my search buffer, and there are new mails, the topmost >> (i.e. newest) message seems to be selected (i.e. with green bac

Selection bug

Moin, there is a bug in notmuch emacs that is mildly annoying. Sometimes when I refresh my search buffer, and there are new mails, the topmost (i.e. newest) message seems to be selected (i.e. with green background), but in fact if i hit enter (or do any other state changing action like tagging),

Re: [PATCH] test: replace aging OpenPGP key used in the test suite

Michael J Gruber writes: > Am Do., 22. Sept. 2022 um 10:47 Uhr schrieb Justus Winter > : >> >> This replaces the old OpenPGPv4 key that is used in the test suite >> with a more modern OpenPGPv4 key. All cryptographic artifacts in the > > Both v4? Only one key file

[PATCH] test: replace aging OpenPGP key used in the test suite

This replaces the old OpenPGPv4 key that is used in the test suite with a more modern OpenPGPv4 key. All cryptographic artifacts in the test suite are updated accordingly. Having old cryptographic artifacts in the test suite presents a problem once the old algorithms are rejected by contemporary

Re: [PATCH 1/2] test: compute expected keyid from fingerprint

Tomi Ollila writes: > On Fri, Sep 09 2022, Justus Winter wrote: > >> --- >> test/T350-crypto.sh | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh >> index 3c6626b4..721cbfdd 100755

[PATCH 2/2] test: replace aging OpenPGP key used in the test suite

This replaces the old OpenPGPv4 key that is used in the test suite with a more modern OpenPGPv4 key. All cryptographic artifacts in the test suite are updated accordingly. Having old cryptographic artifacts in the test suite presents a problem once the old algorithms are rejected by contemporary

[PATCH 1/2] test: compute expected keyid from fingerprint

--- test/T350-crypto.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh index 3c6626b4..721cbfdd 100755 --- a/test/T350-crypto.sh +++ b/test/T350-crypto.sh @@ -467,7 +467,7 @@ expected='[[[{"id": "X", "Date": "Sat, 01 Jan 2000

Re: Sending mail succeeded but signaled failure

Dan Čermák writes: > Justus Winter writes: > >> David Bremner writes: >> >>> Justus Winter writes: >>> >>>> Hello, >>>> >>>> I just embarrassed myself a little by sending the same mail over and >>>&g

Re: Sending mail succeeded but signaled failure

David Bremner writes: > Justus Winter writes: > >> Hello, >> >> I just embarrassed myself a little by sending the same mail over and >> over again. The reason for that is that notmuch-emacs signaled failure, >> i.e. it displayed an error message i

Re: Sending mail succeeded but signaled failure

Hi Dan :) Dan Čermák writes: > Hi Justus, > > Justus Winter writes: > >> Hello, >> >> I just embarrassed myself a little by sending the same mail over and >> over again. The reason for that is that notmuch-emacs signaled failure, >> i.e. it displ

Sending mail succeeded but signaled failure

Hello, I just embarrassed myself a little by sending the same mail over and over again. The reason for that is that notmuch-emacs signaled failure, i.e. it displayed an error message in the status buffer and didn't close the compose buffer, yet it did in fact send the mail. I suspect that my

Sending mail succeeded but signaled failure

Hello, I just embarrassed myself a little by sending the same mail over and over again. The reason for that is that notmuch-emacs signaled failure, i.e. it displayed an error message in the status buffer and didn't close the compose buffer, yet it did in fact send the mail. I suspect that my

Re: Emacs lagging for ~4min when opening from certain email.

Hi, na...@mailbox.org writes: > I have been using Notmuch with Emacs for a couple of days and it has > been working great, except for when I open mails from a certain sender > with S/MIME signed messages, Emacs will freeze up for about 4 minutes. > Opening the expandable signature inside of the

Machine-learning-based tagging solution prototype

'sup :) tl;dr: Please meet blaecksprutte[0], a machine-learning-based tagging solution for notmuch. This is a prototype, but I've been using it as my sole tagging solution for three years now. 0: https://github.com/teythoon/blaecksprutte Long version: When I started using notmuch, writing

Re: notmuch.readthedocs.org

David Bremner writes: > sending again with a signature. I am bremner on readthedocs.io Done. signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch.readthedocs.org

David Bremner writes: > David Bremner writes: > >> >> Hi Justus, Hi Ben; >> >> I notice these are a bit stale again. Is one of you planning on >> updating, or should we pass on maintence (or shut it down?) >> >> d > > Hi guys. > > Could one of you make me an admin? At minimum there needs to be

Re: New Python bindings

Floris Bruynooghe <f...@devork.be> writes: > On Wed, Mar 21 2018, Justus Winter wrote: >> >> Floris Bruynooghe <f...@devork.be> writes: >> >>> This is exactly what I have fixed in my alternative bindings which I >>> created around the end of last

New Python bindings (was: Crash with Python bindings)

Hi Floris :) Floris Bruynooghe writes: > This is exactly what I have fixed in my alternative bindings which I > created around the end of last year [0]. So we do have an idea of how > to fix this, at the time I said I do believe that it's possible to also > do this for the

Re: Crash with Python bindings

David Bremner writes: > "W. Trevor King" writes: > >> you can avoid the abort (which happens when q.__del__ is called after >> db.__del__). We could make that sort of cleanup easier with context >> managers for Query objects (we have them for databases

Re: notmuch_query_add_tag_exclude bug

David Bremner <da...@tethera.net> writes: > Justus Winter <jus...@sequoia-pgp.org> writes: > >> Hi :) >> >> so I found a weird bug with notmuch_query_add_tag_exclude. Apparently, >> when I exclude 'spam', and search for 'spam', I still get resul

notmuch_query_add_tag_exclude bug

Hi :) so I found a weird bug with notmuch_query_add_tag_exclude. Apparently, when I exclude 'spam', and search for 'spam', I still get results, but if I exclude 'spam', and search for 'is_a_spam', I get no results, even though there are mails tagged with that tag. ~~~ snip ~~~ import notmuch d

Re: [Bug] lingering gpg-agents from test suite

David Bremner writes: > Thanks to changes in gnupg 2.1.20, the agent started by the notmuch test > suite is no longer killed by deleting the home directory. > > So yay, we get to adapt to changes in gnupg, again. > > See also > >

Re: notmuch version/Python bindings

David Bremner writes: > Sebastian Spaeth writes: > >> Hi there, I did stop using notmuch, true. Let me know if I should hand >> over administration or if I shouldnsimply delete the package on pypi. >> > > Hi Sebastian; > > Thanks for the followup. If

Re: [Jakub Wilk] Bug#749890: python3-notmuch: missing header in mbox message -> NullPointerError

Hi, Quoting David Bremner (2014-05-30 15:14:46) > this looks like a bug in the python bindings to me > > Package: python3-notmuch > Version: 0.18-3 > Severity: minor > > If a message starts with the "From " postmark (i.e., it's in the mbox > format), and you ask the get_header() method for a

Re: Bug#817964: notmuch: indexing daemon

Quoting David Bremner (2016-03-12 12:24:47) > Paul Wise writes: > > I expect the right interface to use for notifications of filesystem > > events is inotify since fanotify doesn't send rename events. This would > > require one inotify per directory. Fwiw, afew does exactly

Re: [PATCH] lib: have two definitions of NOTMUCH_DEPRECATED macro

Quoting Jani Nikula (2015-12-29 12:52:20) > > __has_extension() replacement was modeled after __has_attribute() > > definition in compat/function-attributes.h. Thanks Justus. Hum, I didn't even recall doing that. > > +/* clang provides this macro to test for support for language > > + *

Compilation failure with gcc 4.4.7

Hello, I just tried to compile notmuch with an oldish compiler, and that failed (if the compiler is indeed too old, then at least the error message should be more helpful): % ./configure --prefix=$HOME/stow/notmuch [...] Sanity checking C compilation environment... OK. Sanity checking C++

Re: [PATCH v2] add notmuch.Database.get_status_string()

Quoting Daniel Kahn Gillmor (2015-12-10 03:18:17) > Sorry about the first version, which didn't handle a NULL value > properly. Please only consider this v2 version. Applied, thanks. I changed it slightly to conform with our naming scheme. Justus signature.asc Description: signature

notmuch.readthedocs.org

Hey Sebastian, Quoting Sebastian Spaeth (2014-11-18 09:44:15) > Let me know if I should be deleting the site. Or hand it over, or > something :-). If I remember correctly, you handed notmuch.rtfd.org over to me. Or you deleted the project, and I created a new one in its place, I don't recall.

Re: notmuch.readthedocs.org

Hey Sebastian, Quoting Sebastian Spaeth (2014-11-18 09:44:15) Let me know if I should be deleting the site. Or hand it over, or something :-). If I remember correctly, you handed notmuch.rtfd.org over to me. Or you deleted the project, and I created a new one in its place, I don't recall.

notmuch.readthedocs.org

Quoting David Bremner (2014-11-16 21:23:21) > Ben Gamari writes: > > > > > David, perhaps you could update the description of the notmuch RtD > > project to reflect that fact that it is no longer describing the Python > > bindings? Indeed, the 0.14 version still documents the python bindings,

Re: notmuch.readthedocs.org

Quoting David Bremner (2014-11-16 21:23:21) Ben Gamari bgamari.f...@gmail.com writes: David, perhaps you could update the description of the notmuch RtD project to reflect that fact that it is no longer describing the Python bindings? Indeed, the 0.14 version still documents the python

Looking for the perfect mail client

Quoting Sepp Tannhuber (2014-10-23 12:47:10) > Peter Feigl schrieb am 19:38 Mittwoch, 22.Oktober 2014: > > Try strace or > > gdb to find out what really crashes notmuch. > Good idea. Can anybody help me to interprete the output: > https://gist.github.com/tannhuber/c7cae862f897efccd3cb Your

Re: Looking for the perfect mail client

Quoting Sepp Tannhuber (2014-10-23 12:47:10) Peter Feigl cra...@gmx.net schrieb am 19:38 Mittwoch, 22.Oktober 2014: Try strace or gdb to find out what really crashes notmuch. Good idea. Can anybody help me to interprete the output: https://gist.github.com/tannhuber/c7cae862f897efccd3cb

[PATCH] python: Add binding for notmuch_query_add_tag_exclude

Quoting David Bremner (2014-09-20 07:15:02) > Thibaut Horel writes: > > > Implemented as the method `exclude_tag` of the class `Query`. This method > > takes > > one argument, a string containing the name of the tag to exclude > > This tag looks pretty trivial. I'll merge it unless I hear

[PATCH 2/2] python: annotate all calls into libnotmuch with types

Hi :) Quoting David Bremner (2014-01-24 14:17:27) > Justus Winter <4winter at informatik.uni-hamburg.de> writes: > > > Quoting Justus Winter (2011-12-07 19:49:31) > > > And another one: > [stack trace snipped] > > #69 0x004e10be in PyRun_SimpleFil

Re: [PATCH 2/2] python: annotate all calls into libnotmuch with types

Hi :) Quoting David Bremner (2014-01-24 14:17:27) Justus Winter 4win...@informatik.uni-hamburg.de writes: Quoting Justus Winter (2011-12-07 19:49:31) And another one: [stack trace snipped] #69 0x004e10be in PyRun_SimpleFileExFlags (fp=0xb99c10, filename=optimized out

[RFC PATCH] Python bindings: CDLL("libnotmuch.3.dylib") on Darwin

Quoting Tomi Ollila (2013-07-06 14:25:12) > On Tue, Jun 25 2013, Justus Winter <4winter at informatik.uni-hamburg.de> > wrote: > > > Quoting Tomi Ollila (2013-06-25 16:36:56) > >> Use os.uname() to check for 'Darwin' and load "libnotmuch.3.dyli

[RFC PATCH] Python bindings: CDLL("libnotmuch.3.dylib") on Darwin

Quoting Tomi Ollila (2013-06-25 16:36:56) > Use os.uname() to check for 'Darwin' and load "libnotmuch.3.dylib" > instead of "libnotmuch.so.3" if that is the case. > --- > > This is followup to thread starting from > > id:1369540418-94177-1-git-send-email-Julian at GrayVines.com > > For anyone

header continuation issue in notmuch frontend/alot/pythons email module

Quoting Austin Clements (2013-06-23 18:59:39) > Quoth Justus Winter on Jun 23 at 3:11 pm: > > Hi, > > > > I recently had a problem replying to a mail written by Thomas Schwinge > > using an oldish notmuch. Not sure if it has been fixed in more recent > > ve

header continuation issue in notmuch frontend/alot/pythons email module

Hi, I recently had a problem replying to a mail written by Thomas Schwinge using an oldish notmuch. Not sure if it has been fixed in more recent versions, but I think notmuch could improve uppon its header generation (see below). Problematic part of the mail: ~~~ snip ~~~ [...] To: someone at

DNS issues with notmuchmail.org

Hi, I'm experiencing a weird issue, the dns servers provided by my isp (once HanseNet, a local isp in Hamburg, Germany, then Alice, o2, not sure who owns them now) do not return the record for notmuchmail.org: % dig +short notmuchmail.org @213.191.74.12 % dig +short notmuchmail.org

[PATCH] Fix shared library loading in Python bindings.

Hi Julian :) Quoting Julian Berman (2013-05-26 05:53:38) > Specifically, fixes loading on OS X, where libnotmuch will be > a dylib.: > --- > bindings/python/notmuch/globals.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/bindings/python/notmuch/globals.py >

Re: [PATCH] Fix shared library loading in Python bindings.

Hi Julian :) Quoting Julian Berman (2013-05-26 05:53:38) Specifically, fixes loading on OS X, where libnotmuch will be a dylib.: --- bindings/python/notmuch/globals.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bindings/python/notmuch/globals.py

The Python bindings are now back on PyPI

Hi :) Quoting Julian Berman (2013-05-26 16:27:31) > I've queried gently to find out if anyone was interested in putting the Python > bindings back on PyPI a few times in IRC before, and didn't really see much > interest one way or the other. I saw a mailing list post that seemed > indifferent,

Re: The Python bindings are now back on PyPI

Hi :) Quoting Julian Berman (2013-05-26 16:27:31) I've queried gently to find out if anyone was interested in putting the Python bindings back on PyPI a few times in IRC before, and didn't really see much interest one way or the other. I saw a mailing list post that seemed indifferent, though

Re: Python Bindings missing on PyPI

Quoting Patrick Gerken (2013-05-22 12:08:30) Quoting Justus Winter (2013-05-21 14:54:02) Hi :) Quoting David Bremner (2013-05-20 16:32:32) Patrick Gerken notm...@patrick-gerken.de writes: I would not object to that, but David has a point here. If the version you get from pypi

Python Bindings missing on PyPI

Quoting Patrick Gerken (2013-05-22 12:08:30) > Quoting Justus Winter (2013-05-21 14:54:02) > > Hi :) > > > > Quoting David Bremner (2013-05-20 16:32:32) > > > Patrick Gerken writes: > > I would not object to that, but David has a point here. If the version

[RFC PATCH 1/1] add --stderr option

Quoting Tomi Ollila (2013-05-22 09:50:46) > On Tue, May 21 2013, Justus Winter <4winter at informatik.uni-hamburg.de> > wrote: > > > Quoting Tomi Ollila (2013-05-21 20:42:30) > >> --- > >> > >> Note quickly written unt

Re: [RFC PATCH 1/1] add --stderr option

Quoting Tomi Ollila (2013-05-22 09:50:46) On Tue, May 21 2013, Justus Winter 4win...@informatik.uni-hamburg.de wrote: Quoting Tomi Ollila (2013-05-21 20:42:30) --- Note quickly written untested code (but compiles!), just to show an idea... This implements (i hope) curl(1) --stderr

[RFC PATCH 1/1] add --stderr option

Quoting Tomi Ollila (2013-05-21 20:42:30) > --- > > Note quickly written untested code (but compiles!), just to show an idea... > > This implements (i hope) curl(1) --stderr option in notmuch(1): > >--stderr > Redirect all writes to stderr to the specified file instead.

Python Bindings missing on PyPI

Hi :) Quoting David Bremner (2013-05-20 16:32:32) > Patrick Gerken writes: > > Is there any rationale that prevents registering the python bindings > > on pypi? I believe the python bindings were once available on pypi, though that might have been a relict from the time the python bindings were

Re: Python Bindings missing on PyPI

Hi :) Quoting David Bremner (2013-05-20 16:32:32) Patrick Gerken notm...@patrick-gerken.de writes: Is there any rationale that prevents registering the python bindings on pypi? I believe the python bindings were once available on pypi, though that might have been a relict from the time the

Re: [RFC PATCH 1/1] add --stderr option

Quoting Tomi Ollila (2013-05-21 20:42:30) --- Note quickly written untested code (but compiles!), just to show an idea... This implements (i hope) curl(1) --stderr option in notmuch(1): --stderr file Redirect all writes to stderr to the specified file instead. If

Re: [PATCH] go: use a different goconfig package

Quoting David Bremner (2013-04-24 00:51:11) Justus Winter 4win...@informatik.uni-hamburg.de writes: The notmuch-addrlookup utility uses a third party library to read the notmuch configuration file. The previously used implementation at github.com/kless/goconfig vanished, so this patch

[PATCH] go: use a different goconfig package

ns differ at the API level, the code is updated accordingly. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- bindings/go/Makefile |4 ++-- bindings/go/src/notmuch-addrlookup/addrlookup.go | 14 ++ 2 files changed, 8 insertions

[PATCH] go: use a different goconfig package

, the code is updated accordingly. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- bindings/go/Makefile |4 ++-- bindings/go/src/notmuch-addrlookup/addrlookup.go | 14 ++ 2 files changed, 8 insertions(+), 10 deletions(-) diff --git

Python analogous for the CLI command

Hi Flavius :) welcome to notmuch :) Quoting Flavius Aspra (2013-04-18 10:11:37) > Can you give me some pointers on how to use the python module to get the JSON > data with notmuch effort, equivalent to the command: ^^^ hehe :) Ok, here it is: teythoon at thinkbox ~/tmp % cat

Re: Python analogous for the CLI command

Hi Flavius :) welcome to notmuch :) Quoting Flavius Aspra (2013-04-18 10:11:37) Can you give me some pointers on how to use the python module to get the JSON data with notmuch effort, equivalent to the command: ^^^ hehe :) Ok, here it is: teythoon@thinkbox ~/tmp % cat

[RFC/PATCH] python: search parent lib directory for libnotmuch.so

Quoting Jed Brown (2013-04-09 16:57:05) > Justus Winter <4winter at informatik.uni-hamburg.de> writes: > > > > May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch > > to a non-standard location as unprivileged user and to make this > >

[RFC/PATCH] python: search parent lib directory for libnotmuch.so

Hi Jed, Quoting Jed Brown (2013-04-09 04:47:26) > If libnotmuch.so is installed to a path that is not searched by > dlopen(3), we must import it using an absolute path because the Python > bindings do not have the luxury of RPATH linking. So strip off the > trailing directories from the install

Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so

Hi Jed, Quoting Jed Brown (2013-04-09 04:47:26) If libnotmuch.so is installed to a path that is not searched by dlopen(3), we must import it using an absolute path because the Python bindings do not have the luxury of RPATH linking. So strip off the trailing directories from the install

Re: [RFC/PATCH] python: search parent lib directory for libnotmuch.so

Quoting Jed Brown (2013-04-09 16:57:05) Justus Winter 4win...@informatik.uni-hamburg.de writes: May I ask why you cannot use LD_LIBRARY_PATH? I too install libnotmuch to a non-standard location as unprivileged user and to make this library available I add its path to LD_LIBRARY_PATH

[PATCH 2/3] Go bindings: wrap notmuch_message_get_date

Quoting Julius Plenz (2013-03-02 15:50:55) > -// TODO: wrap notmuch_message_get_date > +func (self *Message) GetDate() time.Time { It's customary to name the receiver just m for the type Message. I realize that the rest of the code uses self too, but I'd love to see this converted and maybe we

[PATCH 1/3] Go bindings: clean up the documentation

Hi Julius, Quoting Julius Plenz (2013-03-02 15:50:54) > Most of the copy is either misleading or not helpful; remove that, and > add useful comments where it?s helping. > --- > [...] > +// Open an existing notmuch database located at 'path'. By default the > +// database should be opened for

Re: [PATCH 1/3] Go bindings: clean up the documentation

Hi Julius, Quoting Julius Plenz (2013-03-02 15:50:54) Most of the copypaste is either misleading or not helpful; remove that, and add useful comments where it’s helping. --- [...] +// Open an existing notmuch database located at 'path'. By default the +// database should be opened for

Re: [PATCH 2/3] Go bindings: wrap notmuch_message_get_date

Quoting Julius Plenz (2013-03-02 15:50:55) -// TODO: wrap notmuch_message_get_date +func (self *Message) GetDate() time.Time { It's customary to name the receiver just m for the type Message. I realize that the rest of the code uses self too, but I'd love to see this converted and maybe we

Re: nbook: a notmuch based address book written in python

Hi Suvayu :) welcome to notmuch and python. Quoting Patrick Totzke (2012-10-13 18:58:51) And If I look for my own name, this takes over a minute, eventually dying. This could be an issue with libnotmuch though. Possibly, your algorithm takes very long and then reads from an initially

[PATCH 6/6] Avoid potentially dereferencing a NULL pointer

GMIME_IS_MULTIPART and GMIME_IS_MESSAGE both handle NULL pointers gracefully, but the G_OBJECT_TYPE used in the error handling block dereferences it without checking it first. Fix this by checking whether parent->part is valid. Found using the clang static analyzer. Signed-off-by: Justus Win

[PATCH 4/6] Fix the COERCE_STATUS macro

Fix the COERCE_STATUS macro to handle _internal_error being declared as void function. Note that the function _internal_error does not return. Evaluating to NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --

[PATCH 2/6] Provide a NORETURN_ATTRIBUTE macro similar to PRINTF_ATTRIBUTE

This attribute is understood by gcc since version 2.5. clang provides support for testing for function attributes using __has_attribute. For other compilers this macro evaluates to the empty string. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- compat/fu

[PATCH 1/6] Provide a __has_attribute compatibility macro

__has_attribute is defined by clang and tests whether a given function attribute is supported by clang. Add a compatibility macro for other compilers. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- compat/function-attributes.h | 31

RFC: Annotate internal_error with the attribute noreturn 2nd patchset

Quoting David Bremner (2012-09-24 12:44:04) > Justus Winter <4winter at informatik.uni-hamburg.de> writes: > > > We need to discuss where those kind of macro definitions abstracting > > away compiler differences should go. None of the files in util > > includes notm

[PATCH 4/5] Annotate internal_error with the attribute noreturn

statement that was placed there to appease the compiler. Functions annotated with noreturn are not supposed to return any values. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- util/error_util.c |4 +--- util/error_util.h |4 ++-- 2 files changed, 3 insertions

[PATCH 3/5] Fix the COERCE_STATUS macro

Fix the COERCE_STATUS macro to handle _internal_error being declared as void function. Note that the function _internal_error does not return. Evaluating to NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --

[PATCH 2/5] RFC: Provide a NORETURN_ATTRIBUTE macro similar to PRINTF_ATTRIBUTE

to be discussed is where this kind of macro should be defined. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- util/error_util.h | 16 1 file changed, 16 insertions(+) diff --git a/util/error_util.h b/util/error_util.h index 1b11047..27e119f 100644 ---

[PATCH 1/5] RFC: Provide a __has_attribute compatibility macro

be defined. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- util/error_util.h |8 1 file changed, 8 insertions(+) diff --git a/util/error_util.h b/util/error_util.h index bb15822..1b11047 100644 --- a/util/error_util.h +++ b/util/error_util.h @@ -23,6

RFC: Annotate internal_error with the attribute noreturn 2nd patchset

Thanks for your feedback. I've updated the patch series accordingly. We need to discuss where those kind of macro definitions abstracting away compiler differences should go. None of the files in util includes notmuch-private.h, so I was unsure whether it's okay to put them there. Justus

RFC: Annotate internal_error with the attribute noreturn 2nd patchset

Thanks for your feedback. I've updated the patch series accordingly. We need to discuss where those kind of macro definitions abstracting away compiler differences should go. None of the files in util includes notmuch-private.h, so I was unsure whether it's okay to put them there. Justus

[PATCH 4/5] Annotate internal_error with the attribute noreturn

statement that was placed there to appease the compiler. Functions annotated with noreturn are not supposed to return any values. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- util/error_util.c |4 +--- util/error_util.h |4 ++-- 2 files changed, 3 insertions(+), 5

[PATCH 1/5] RFC: Provide a __has_attribute compatibility macro

be defined. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- util/error_util.h |8 1 file changed, 8 insertions(+) diff --git a/util/error_util.h b/util/error_util.h index bb15822..1b11047 100644 --- a/util/error_util.h +++ b/util/error_util.h @@ -23,6 +23,14

[PATCH 5/5] Avoid potentially dereferencing a NULL pointer

GMIME_IS_MULTIPART and GMIME_IS_MESSAGE both handle NULL pointers gracefully, but the G_OBJECT_TYPE used in the error handling block dereferences it without checking it first. Fix this by checking whether parent-part is valid. Found using the clang static analyzer. Signed-off-by: Justus Winter

[PATCH 3/5] Fix the COERCE_STATUS macro

Fix the COERCE_STATUS macro to handle _internal_error being declared as void function. Note that the function _internal_error does not return. Evaluating to NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- lib

[PATCH 2/5] RFC: Provide a NORETURN_ATTRIBUTE macro similar to PRINTF_ATTRIBUTE

to be discussed is where this kind of macro should be defined. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- util/error_util.h | 16 1 file changed, 16 insertions(+) diff --git a/util/error_util.h b/util/error_util.h index 1b11047..27e119f 100644 --- a/util

Re: RFC: Annotate internal_error with the attribute noreturn 2nd patchset

Quoting David Bremner (2012-09-24 12:44:04) Justus Winter 4win...@informatik.uni-hamburg.de writes: We need to discuss where those kind of macro definitions abstracting away compiler differences should go. None of the files in util includes notmuch-private.h, so I was unsure whether it's

Re: [PATCH 2/2] Avoid potentially dereferencing a NULL pointer

Quoting Austin Clements (2012-09-22 18:19:08) Quoth Justus Winter on Sep 21 at 2:50 pm: GMIME_IS_MULTIPART and GMIME_IS_MESSAGE both handle NULL pointers gracefully, but the G_OBJECT_TYPE used in the error handling block dereferences it without checking it first. Fix this by checking

[PATCH 5/6] Annotate internal_error with the attribute noreturn

statement that was placed there to appease the compiler. Functions annotated with noreturn are not supposed to return any values. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- util/error_util.c |4 +--- util/error_util.h |6 -- 2 files changed, 5 insertions(+), 5

[PATCH 1/6] Provide a __has_attribute compatibility macro

__has_attribute is defined by clang and tests whether a given function attribute is supported by clang. Add a compatibility macro for other compilers. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- compat/function-attributes.h | 31 +++ 1 file

[PATCH 3/6] Extend compat/README

Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- compat/README |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/compat/README b/compat/README index 38e2e14..12aacf4 100644 --- a/compat/README +++ b/compat/README @@ -1,6 +1,6 @@ notmuch/compat

[PATCH 4/6] Fix the COERCE_STATUS macro

Fix the COERCE_STATUS macro to handle _internal_error being declared as void function. Note that the function _internal_error does not return. Evaluating to NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- lib

[PATCH 6/6] Avoid potentially dereferencing a NULL pointer

GMIME_IS_MULTIPART and GMIME_IS_MESSAGE both handle NULL pointers gracefully, but the G_OBJECT_TYPE used in the error handling block dereferences it without checking it first. Fix this by checking whether parent-part is valid. Found using the clang static analyzer. Signed-off-by: Justus Winter

[PATCH 2/6] Provide a NORETURN_ATTRIBUTE macro similar to PRINTF_ATTRIBUTE

This attribute is understood by gcc since version 2.5. clang provides support for testing for function attributes using __has_attribute. For other compilers this macro evaluates to the empty string. Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de --- compat/function-attributes.h

[PATCH 2/2] Avoid potentially dereferencing a NULL pointer

GMIME_IS_MULTIPART and GMIME_IS_MESSAGE both handle NULL pointers gracefully, but the G_OBJECT_TYPE used in the error handling block dereferences it without checking it first. Fix this by checking whether parent->part is valid. Found using the clang static analyzer. Signed-off-by: Justus Win

[PATCH 1/2] Annotate internal_error with the attribute noreturn

statement that was placed there to appease the compiler. Functions annotated with noreturn are not supposed to return any values. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- util/error_util.c |2 -- util/error_util.h |2 +- 2 files changed, 1 insertion

[PATCH 2/2] Avoid potentially dereferencing a NULL pointer

GMIME_IS_MULTIPART and GMIME_IS_MESSAGE both handle NULL pointers gracefully, but the G_OBJECT_TYPE used in the error handling block dereferences it without checking it first. Fix this by checking whether parent-part is valid. Found using the clang static analyzer. Signed-off-by: Justus Winter

Better Gmail handling by not using Notmuch tags

Quoting Damien Cassou (2012-09-13 17:15:30) > On Thu, Sep 13, 2012 at 5:13 PM, Jeremy Nickurak > wrote: > > Gmail doesn't have folders, of course, it has labels, which are > > approximately equivalent to notmuch tags. The key difference being that a > > message can only be in one folder, but it

Re: Better Gmail handling by not using Notmuch tags

Quoting Damien Cassou (2012-09-13 17:15:30) On Thu, Sep 13, 2012 at 5:13 PM, Jeremy Nickurak not-m...@trk.nickurak.ca wrote: Gmail doesn't have folders, of course, it has labels, which are approximately equivalent to notmuch tags. The key difference being that a message can only be in one

Re: ‘class Xapian::Database’ has no member named ‘close’

Quoting Jani Nikula (2012-08-14 14:57:13) > > Is close() really required though? The comment justifies it saying > > that: > > > > Many Xapian objects hold references to the database, so merely > > deleting the database may not suffice to close it. Thus, we > > explicitly close

  1   2   3   4   >