mu.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2019-12-22	move parser/utils to utils, Mux->Mu	Dirk-Jan C. Binnema
	Move the parser utils to utils/ and rename the Mux namespace into Mu.
2019-03-24	mu: fix utf-8 flatten	djcb

2019-03-23	utils: small optimization in utf8_flatten	djcb
	In the common path, avoid building an unneeded std::string. This should up in some profiles.
2019-01-11	parser: fix clang-7.0.1 warnings	Ulrich Ölmann
	Without this commit clang++-7.0.1 whines \| CXX parser.lo \| parser.cc:138:15: warning: braces around scalar initializer [-Wbraced-scalar-init] \| return Tree({{Node::Type::Range}, \| ^~~~~~~~~~~~~~~~~~~
2018-11-11	parser: avoid query parsing error	djcb
	See #1261.
2018-11-04	add optional support for building with asan	djcb

2018-05-19	only use OP_WILDCARD for xapian >= 1.3.3	djcb
	It's not available for earlier versions.
2018-05-19	query-parser: special-case wildcards	djcb
	We were transforming wild-card searches into regular-expression searches; while that works, it's also significantly slower. So, instead, special-case wildcards, and use the Xapian machinery for wildcard queries.
2018-03-31	parser/tests: allow for DST change	djcb
	e.g. 21d / 2w are subject to DST; update the tolerance.
2018-03-10	mu: _XOPEN_SOURCE: fix typo	djcb

2018-02-17	lib/parser: fix month days	djcb
	In the olden days, we stored dates like e.g. 20180131121234, and do a lexicographical check. With that, we could use e.g. upper-limits 201802312359 for "all dates in Feb 2018", even if Feb doesn't have 31 days. However, nowadays we use time_t values, and g_date_time_new_local raises errors for non-existent days; easiest fix is to massage things a bit; so let's do that. Fixes issue #1197.
2018-02-11	lib/parser: use g_vasprintf, _XOPEN_SOURCE	djcb
	Attempt to restore building on Cygwin.
2017-12-03	parser: promote single value to a range for range-fields	djcb
	Treat e.g. 'date:20170101' as 'date:20170101..20170101', just like the Xapian parser does.
2017-11-04	parser: small regex optimization	djcb

2017-11-04	parser/utils: enforce 64-bit times on 32-bit platforms	djcb
	don't assume a 64-bit platform.
2017-11-04	parser: handle implicit 'and not'	djcb

2017-10-31	parser: fix and-not precedence	djcb
	For now, don't treat "and not" specially; this gets us back into a somewhat working state. At some point, we probably _do_ want to special-case and_not though (since Xapian supports it).
2017-10-29	mu: some optimizations	djcb
	add fast-path for (common) plain-ascii. fix silly static misuse. should improve indexing with some single-digit percentage.
2017-10-28	tokenizer: clean unicode-aware	djcb

2017-10-28	parser: add more tests	djcb

2017-10-27	phrases: only allow for index fields	djcb

2017-10-27	parser: fix some post-c++14 code	djcb
	don't require anything post c++14
2017-10-27	query-parser: cleanup source string	djcb
	Ensure there's no non-' ' whitespace, and no trailing/leading spaces.
2017-10-26	query-parser: support phrase queries	djcb

2017-10-25	integrate new query parser	djcb

2017-10-24	lib: implement new query parser	djcb
	mu's query parser is the piece of software that turns your queries into something the Xapian database can understand. So, if you query "maildir:/inbox and subject:bla" this must be translated into a Xapian::Query object which will retrieve the sought after messages. Since mu's beginning, almost a decade ago, this parser was based on Xapian's default Xapian::QueryParser. It works okay, but wasn't really designed for the mu use-case, and had a bit of trouble with anything that's not A..Z (think: spaces, special characters, unicode etc.). Over the years, mu added quite a bit of pre-processing trickery to deal with that. Still, there were corner cases and bugs that were practically unfixable. The solution to all of this is to have a custom query processor that replaces Xapian's, and write it from the ground up to deal with the special characters etc. I wrote one, as part of my "future, post-1.0 mu" reseach project, and I have now backported it to the mu 0.9.19. From a technical perspective, this is a major cleanup, and allows us to get rid of much of the fragile preprocessing both for indexing and querying. From and end-user perspective this (hopefully) means that many of the little parsing issues are gone, and it opens the way for some new features. From an end-user perspective: - better support for special characters. - regexp search! yes, you can now search for regular expressions, e.g. subject:/h.ll?o/ will find subjects with hallo, hello, halo, philosophy, ... As you can imagine, this can be a _heavy_ operation on the database, and might take quite a bit longer than a normal query; but it can be quite useful.