<feed xmlns='http://www.w3.org/2005/Atom'>
<title>notmuch/util/Makefile.local, branch 0.38_rc2</title>
<subtitle>thread-based email index, search, and tagging</subtitle>
<id>https://git.notmuchmail.org/git/notmuch/atom?h=0.38_rc2</id>
<link rel='self' href='https://git.notmuchmail.org/git/notmuch/atom?h=0.38_rc2'/>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/'/>
<updated>2021-04-24T11:07:00Z</updated>
<entry>
<title>compat: rename {,notmuch_}canonicalize_file_name</title>
<updated>2021-04-24T11:07:00Z</updated>
<author>
<name>Đoàn Trần Công Danh</name>
<email>congdanhqx@gmail.com</email>
</author>
<published>2021-04-24T01:05:37Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=441a327051f5357175029709030a0ee51131379d'/>
<id>urn:sha1:441a327051f5357175029709030a0ee51131379d</id>
<content type='text'>
When compat canonicalize_file_name was introduced, it was limited to
C code only because it was used by C code only during that time.

&gt;From 5ec6fd4d, (lib/open: check for split configuration when creating
database., 2021-02-16), lib/open.cc, which is C++, relies on the
existent of canonicalize_file_name.

However, we can't blindly enable canonicalize_file_name for C++ code,
because different implementation has different additional signature for
C++ and users can arbitrarily add -DHAVE_CANONICALIZE_FILE_NAME=0 to
{C,CXX}FLAGS.

Let's move our implementation into a util library.

Helped-by: Tomi Ollila &lt;tomi.ollila@iki.fi&gt;
Signed-off-by: Đoàn Trần Công Danh &lt;congdanhqx@gmail.com&gt;
</content>
</entry>
<entry>
<title>emacs: Use makefile-gmake-mode in Makefile*s</title>
<updated>2020-08-10T00:14:36Z</updated>
<author>
<name>Jonas Bernoulli</name>
<email>jonas@bernoul.li</email>
</author>
<published>2020-08-08T11:49:49Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=c4541353765dec837c1c2f912b1bf6661827429c'/>
<id>urn:sha1:c4541353765dec837c1c2f912b1bf6661827429c</id>
<content type='text'>
Use `makefile-gmake-mode' instead of `makefile-mode' because the
former also highlights ifdef et al. while the latter does not.

"./Makefile.global" and one "Makefile.local" failed to specify any
major mode at all but doing so is necessary because Emacs does not
automatically figure out that these are Makefiles (of any flavor).
</content>
</entry>
<entry>
<title>repair: set up codebase for repair functionality</title>
<updated>2019-09-01T11:20:25Z</updated>
<author>
<name>Daniel Kahn Gillmor</name>
<email>dkg@fifthhorseman.net</email>
</author>
<published>2019-08-29T15:38:47Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=1b29822cf55eb53e1d45a71c2a3e4a2c2a4574d1'/>
<id>urn:sha1:1b29822cf55eb53e1d45a71c2a3e4a2c2a4574d1</id>
<content type='text'>
This adds no functionality directly, but is a useful starting point
for adding new repair functionality.

Signed-off-by: Daniel Kahn Gillmor &lt;dkg@fifthhorseman.net&gt;
</content>
</entry>
<entry>
<title>util: add unicode_word_utf8</title>
<updated>2019-05-25T09:51:12Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2019-03-26T02:07:24Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=781125c9e92a2b9a2b9fbe54adec28ddb60f35b1'/>
<id>urn:sha1:781125c9e92a2b9a2b9fbe54adec28ddb60f35b1</id>
<content type='text'>
This originally use Xapian::Unicode::is_wordchar, but that forces
clients to link directly to libxapian, which seems like it might be
busywork if nothing else.
</content>
</entry>
<entry>
<title>crypto: move into libnotmuch_util</title>
<updated>2017-10-20T10:58:10Z</updated>
<author>
<name>Daniel Kahn Gillmor</name>
<email>dkg@fifthhorseman.net</email>
</author>
<published>2017-10-17T19:09:55Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=197d67959bf459fc0f1f63a202d162a569535bf3'/>
<id>urn:sha1:197d67959bf459fc0f1f63a202d162a569535bf3</id>
<content type='text'>
This prepares us for using the crypto object in both libnotmuch and
the client.
</content>
</entry>
<entry>
<title>util: convenience function to create gmime stream for stdout</title>
<updated>2017-05-30T12:01:46Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2017-05-27T16:51:11Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=1e7dbf7abcf58407a5171e9030056f2ff9bec15a'/>
<id>urn:sha1:1e7dbf7abcf58407a5171e9030056f2ff9bec15a</id>
<content type='text'>
It turns out that our use of GMimeStreamPipe has only succeeded
because gmime has been ignoring some seek failures; this will no
longer be the case in gmime 3.0, so we use a GMimeStreamPipe, which
does not assume seekability, wrapped in a buffering stream.
</content>
</entry>
<entry>
<title>rename libutil.a to libnotmuch_util.a</title>
<updated>2017-03-19T00:37:43Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2017-03-14T11:10:07Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=c39f6361d0798aa8d0dcd0b91f6b86ab9dc21c75'/>
<id>urn:sha1:c39f6361d0798aa8d0dcd0b91f6b86ab9dc21c75</id>
<content type='text'>
Apparently some systems (MacOS?) have a system library called libutil
and the name conflict causes problems. Since this library is quite
notmuch specific, rename it to something less generic.
</content>
</entry>
<entry>
<title>util: add gz_readline</title>
<updated>2014-04-12T10:59:44Z</updated>
<author>
<name>David Bremner</name>
<email>david@tethera.net</email>
</author>
<published>2014-03-29T17:53:17Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=85d9219a62c23c3ff58b42a63b65390526b89b6b'/>
<id>urn:sha1:85d9219a62c23c3ff58b42a63b65390526b89b6b</id>
<content type='text'>
The idea is to provide a more or less drop in replacement for readline
to read from zlib/gzip streams.  Take the opportunity to replace
malloc with talloc.
</content>
</entry>
<entry>
<title>util: add talloc-extra.[ch]</title>
<updated>2012-12-31T01:12:11Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2012-12-17T03:12:51Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=0cfb8a24dc025335643a5cfa344c62e5584fb477'/>
<id>urn:sha1:0cfb8a24dc025335643a5cfa344c62e5584fb477</id>
<content type='text'>
These are intended to be simple wrappers to provide slightly better
debugging information than what talloc currently provides natively.
</content>
</entry>
<entry>
<title>util: add string-util.[ch]</title>
<updated>2012-12-08T14:56:11Z</updated>
<author>
<name>David Bremner</name>
<email>bremner@debian.org</email>
</author>
<published>2012-11-24T13:43:42Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=9ff72a83bda69e6c064bd8be9f201a4626bff54e'/>
<id>urn:sha1:9ff72a83bda69e6c064bd8be9f201a4626bff54e</id>
<content type='text'>
This is to give a home to strtok_len. It's a bit silly to add a header
for one routine, but it needs to be shared between several compilation
units (or at least that's the most natural design).
</content>
</entry>
</feed>
