Option --all of tagging commands should apply to matched messages only

[guludo]

Is your feature request related to a problem? Please describe. Currently the option --all redoes the query to apply modifications to the tags. This could be problematic in the following scenario:

1. User does a search;
2. New email(s) that would match the user's query arrive but the user hasn't refreshed the search buffer yet;
3. User decides to use some tagging command with --all (e.g. untag --all inbox,unread);
4. We end up applying the modifications to the new email(s) from (2) from behind the user's back.

Describe the solution you'd like IMO, we should apply the modifications to only the currently matched messages.

[pazz]

Quoting Gustavo José de Sousa (2024-01-12 11:50:21)

Describe the solution you'd like IMO, we should apply the modifications to only the currently matched messages.

I don't think this is possible because what happens is alot extracts the query from the buffer and fires up a (notmuch) tag command for that string. The search buffer does not really have a reference to all matches..

[guludo]

Yeah, that would require some partial re-implementation, we would need to keep the set of matched msgids for this.

So, is this a wontfix?

[pazz]

I suppose it is a wontfix, yes. The thing is that the set of matched IDs can be huge. Just search for * and you get all messages, which can take up lots of space and is very inefficient to store explicitly, however you do this.

Quoting Gustavo José de Sousa (2024-01-12 17:56:23)

Yeah, that would require some partial re-implementation, we would need to keep the set of matched msgids for this.

So, is this a wontfix?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: <pazz/alot/issues/ @.***>

[lucc]

Can we fix this specific problem (with new mail arriving) by appending a date:..when_the_original_query_was_executed to the tag/untag query?

[guludo]

Can we fix this specific problem (with new mail arriving) by appending a date:..when_the_original_query_was_executed to the tag/untag query?

From man notmuch-search-terms, the date: prefix is for the Date: header, so I'm afraid that wouldn't really work.

[guludo]

I suppose it is a wontfix, yes. The thing is that the set of matched IDs can be huge. Just search for * and you get all messages, which can take up lots of space and is very inefficient to store explicitly, however you do this. Quoting Gustavo José de Sousa (2024-01-12 17:56:23) … Yeah, that would require some partial re-implementation, we would need to keep the set of matched msgids for this. So, is this a wontfix? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: <pazz/alot/issues/ @.***>

I see your point.

Well, in the common use case, I would expect searches that are interesting to the user not to return a huge among of results. Thinking about that, maybe we could have an --all-matched option that would only work if the current search did not reach a certain limit of matched messages? Otherwise it could bail out with an error message.

I think a limit of 1000 messages would be a reasonable one: extrapolating to message ids of 100 bytes each, we would store about 98KiB of msgid content plus some overhead from the data structure.

Maybe this limit could also be a configurable value.

[pazz]

One thing to consider is also that one may have several buffers open with overlapping matches. If you then toggle a tag based on the matches when the buffer was opened you run into weirdness.

In any case, I am not strongly opposed to any suggestions in principle. If you whip something up and people like it, I will merge it. P

Quoting Gustavo José de Sousa (2024-01-15 13:21:12)

I suppose it is a wontfix, yes. The thing is that the set of matched IDs
can be huge. Just search for * and you get all messages, which can take up
lots of space and is very inefficient to store explicitly, however you do
this. Quoting Gustavo José de Sousa (2024-01-12 17:56:23)
…
Yeah, that would require some partial re-implementation, we would need to
keep the set of matched msgids for this. So, is this a wontfix? — Reply to
this email directly, view it on GitHub, or unsubscribe. You are receiving
this because you commented.Message ID: <pazz/alot/issues/ @.**>

I see your point.

Well, in the common use case, I would expect searches that are interesting to the user not to return a huge among of results. Thinking about that, maybe we could have an --all-matched option that would only work if the current search did not reach a certain limit of matched messages? Otherwise it could bail out with an error message.

I think a limit of 1000 messages would be a reasonable one: extrapolating to message ids of 100 bytes each, we would store about 98KiB of msgid content plus some overhead from the data structure.

Maybe this limit could also be a configurable value.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: <pazz/alot/issues/ @.***>