Re: notmuch-emacs inline image display broken in emacs-29
Hello Alex and David, I also came across this issue: inline image are not displayed only when `notmuch-show-indent-content` is non-nil. However, even when `notmuch-show-indent-content` is `nil` they are displayed but cannot be hidden. As Alex Murray pointed out, the reason is that the function `mm-insert-image` is being changed in Emacs 29 to use `insert-image` instead of `put-image`. `insert-image` inserts images using the `display` property of a whitespace character. The effect is that when `indent-rigidly` is called in `notmuch-show-insert-msg`, whitespace is removed and hence the image is removed. I've filed a bug#62637 on bug-gnu-emacs to discuss this. An easy fix in `mm-insert-image` is use non-whitespace character (the second argument of `insert-image`) so that it is not deleted by `indent-rigidly`. This change actually makes indenting images work in the new version. The other issue is that hiding an overlay created around such an image does not seem to work (see bug#62637 for a discussion). A way to resolve this is to add some whitespace (like a newline) inside the overlay before the image, which seems to fix things. -- Al ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Reimagining notmuch-git/nmbug
Felipe Contreras writes: > On Mon, Apr 3, 2023 at 6:37 PM David Bremner wrote: > Or we could say that after jumping a certain threshold of lastmod we > delete all the messages and start from scratch, perhaps every 1000 > revisions. > > Or maybe the query could generate a virtual tag if a message was > deleted since the previous lastmod (e.g. "nm::deleted"). Then it would > be trivial for the remote helper to tell that to git. A complication here is that tags be attached to mail message documents in the database, so we would need to generate a so called "ghost message", and clean those up somehow. > I lean towards the threshold, because that way the user doesn't need > to do anything, and there's no modifications needed in libnotmuch. This sounds right. Can we use the detection of missing messages in wr_export to reset the appropriate counters? It looks like yes, given the call to store_lastmod. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Reimagining notmuch-git/nmbug
Felipe Contreras writes: > > I'm not familiar with git-annex, I would need to see an example of > such merging happening. I was confused, git-annex is using the builtin merge strategy "union", which is not eliminating duplicates or sorting, so probably not applicable here. I still have to try some merges between different machines to see what kind of conflicts can arise. > One advantage of using the fast-import format is that it's easy to > change it, or support multiple formats. > > In fact, the format could be specified in the URL, like > `nm::1:$HOME/mail` for the current notmuch-git format, and > `nm::2:$HOME/mail` for the new. This might also be a way to handle the "prefix" setting that nmbug / notmuch-git needs to only sync certain (e.g. notmuch::*) tags ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Selection bug
On Tue, Apr 04 2023, Justus Winter wrote: > My desktop now behaves exactly like my laptop, and it is really > annoying. Surely I'm not the only one with this problem. Can no one > else reproduce this? I haven't tried using the reproduction test, but I did just refresh my inbox and I saw the buggy behavior. So there's a random anecdote which suggests it might not be that hard to reproduce the bug, (perhaps doesn't require any special messages). In my case, it's less annoying because I have more than a screenful of messages in my inbox (for shame!) so the message with the green bar isn't even visible when emacs' point is moved to the message that is actually selected. So if I hadn't been intentionally looking for this behavior I likely would have never noticed. -Carl ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Data loss
On Tue, Apr 04 2023, Michael J. Gruber wrote: >> It's really unfortunate if notmuch-mutt makes it that easy to throw away >> your email. >> >> That sounds like a nasty bug that should be fixed in that program. > > To be fair to notmuch-mutt: > ``` > --output-dir DIR > > Store search results as (symlink) messages under maildir DIR. Beware: DIR will > be overwritten. (Default: F<~/.cache/notmuch/mutt/results/>) > ``` > So the default is safe, and the warning is there. It would be a bug > only if notmuch-mutt descended up and deleted a root dir or such. OK. It's definitely acting as documented. So maybe "bug" was a little harsh in my description. It could still be made safer, and I think it would be a good idea to change it. For example, notmuch-mutt currently happily creates a directory that doesn't already exists. That's safe and good. What it could also do is create some placeholder file like .NOTMUCH-MUTT-OUTPUT-DIR when it writes its output. And then it could check for that file's existence before removing a directory. -Carl ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
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" > /tmp/selection-bug/notmuch-config
>>> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch new
>>> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config emacs -q --eval "(require
>>> 'notmuch)"
>>> # M-x notmuch-hello, search for '*'
>>> notmuch show --format=raw id:87edvlanuh@tethera.net |
>>> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
>>> # refresh search buffer, press down once, i.e. navigate to "End of search
>>> results".
>>> notmuch show --format=raw id:87fsfuuxwn.fsf@thinkbox |
>>> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
>>> notmuch show --format=raw id:8735buw7gf@ngraves.fr |
>>> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
>>> # refresh search buffer, bug: Nicolas' mail is green, mine is opened on
>>> pressing enter.
>>
>> 1) Do you think the particular messages matter? I don't have
>>id:8735buw7gf@ngraves.fr
>
> Uh, you are right. I meant to pick mails form notmuch@, but this one is
> from another list. I actually reduced the example further:
>
> mkdir -p /tmp/selection-bug/{tmp,new,cur}
> echo "[database]
> path=/tmp/selection-bug" > /tmp/selection-bug/notmuch-config
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch new
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config emacs -q --eval "(require
> 'notmuch)"
> # M-x notmuch-hello, search for '*'
> notmuch show --format=raw id:87edvlanuh@tethera.net |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> # refresh search buffer, press down once, i.e. navigate to "End of search
> results".
> notmuch show --format=raw id:87fsfuuxwn.fsf@thinkbox |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> # refresh search buffer, bug: your mail is green, mine is opened on pressing
> enter.
>
> (I.e., just drop Nicolas' mail.)
>
> The bug can be seen even with just one mail, but then its impact is less
> severe:
>
> mkdir -p /tmp/selection-bug/{tmp,new,cur}
> echo "[database]
> path=/tmp/selection-bug" > /tmp/selection-bug/notmuch-config
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch new
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config emacs -q --eval "(require
> 'notmuch)"
> # M-x notmuch-hello, search for '*', press down once, i.e. navigate past the
> line "End of search results".
> notmuch show --format=raw id:87edvlanuh@tethera.net |
> NOTMUCH_CONFIG=/tmp/selection-bug/notmuch-config notmuch insert
> # refresh search buffer, bug: your mail is green, but in fact "End of search
> results" is selected and is "acted upon" when pressing enter.
>
>> 2) Just to be clear, that script has to be run manually, with the
>>comments corresponding to interactive actions in emacs?
>
> Yes.
>
> As additional data point, I cannot reproduce the problem on my Desktop
> which has the same emacs version but uses elpa-notmuch 0.31.4-2. On
> this system, if I run the reproducer, there is no line with a green
> background, so it is less misleading.
My desktop now behaves exactly like my laptop, and it is really
annoying. Surely I'm not the only one with this problem. Can no one
else reproduce this?
Best,
Justus
signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Data loss
Am Di., 4. Apr. 2023 um 00:54 Uhr schrieb Carl Worth : > > Ouch. > Yes, we're feeling with you, Fulvio :| > It's really unfortunate if notmuch-mutt makes it that easy to throw away > your email. > > That sounds like a nasty bug that should be fixed in that program. To be fair to notmuch-mutt: ``` --output-dir DIR Store search results as (symlink) messages under maildir DIR. Beware: DIR will be overwritten. (Default: F<~/.cache/notmuch/mutt/results/>) ``` So the default is safe, and the warning is there. It would be a bug only if notmuch-mutt descended up and deleted a root dir or such. Maybe naming the option `scratch-dir` or `cache-dir` or such could have helped, but otoh the name of the default is there. Note that neomutt incorporates notmuch-mutt's functionality, it might be a better choice for this and other reasons. > As for recovering, I suppose there _is_ a fair amount of detail in your > notmuch index from all of the position-indexed terms, (as long as you > haven't run "notmuch new" again since the mail was deleted). > > If you still have a large Xapian database in the notmuch database > directory, it would be theoretically possible to recover a lot of the > email content. But I don't know that anyone has ever written a recovery > tool to help with that process. > That is an interesting question for the insiders, indeed - can e-mail bodies be recovered fully (minus capitalisation, stemming)? In Fulvio's case I would try a file-system dump (if it's not too late) and a recovery tool depending on the fs type. Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
