Hello David,

Many thanks for your swift response, and explanations.

David Bremner <david@tethera.net> writes:

> [...]
>> Any technical reason for "from" having a regex search, but "to" not?
>
> Yes, it is purely technical. The regex support relies on the existence
> of a Xapian value slot for the field in question. It isn't clear what
> the time / space impact of adding another value slot would be. It is
> probably not unbearable, but someone needs to do the tests.

Showing of my lack of knowledge about Xapian, and hence what a "value
slot" in that context is, it seems that for giving me the suggested, new
regex capability on the "to" field would require extending the db
schema, an would therefore and inevitably have a performance impact
which would need to be evaluated before committing to adding this
feature.

Understood, and fair enough.

Is there a "wish list" of sorts, and if so, could it perhaps seem
worthwhile adding this to the wish list?

>>> id:<message-id> or mid:<message-id> or mid:/<regex>/
>>>        For id: and mid:, message ID values are the literal contents of
>>>        the Message-ID: header of email messages, but without the '<',
>>>        '>' delimiters.
>>
>> Similar thing here: "id:" and "mid:" can be used interchangeably, except
>> for regex search. Adding "id:/regex/" would seem most useful to me.
>>
>
> This was intentional, to avoid breaking existing scripts / internals
> that rely on treating id: as the primary key for the database. At least
> that was the concensus when we added it. It seems like one answer would
> be for you to just use mid: all the time, since it already has the
> behaviour you like.
> [...]

I see, thanks for the insight. In that light, what would be your take on
featuring "id" less prominently in the documentation, so as to foster
the sole use of "mid" for all new script developments?

You could maybe even go as far as marking "id" as "deprecated and kept
for backwards compatibility with legacy scripts only"; but without
actually ever removing it, of course, since as you say it's needed for
internal purposes.


My intent on both points is not to give the impression anything were
broken, but to have the query language and its documentation cause as
little confusion as possible, even for the casual user (i.e. myself).


Many thanks and looking forward to your thoughts,

  --alexander
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org