Re: Is it possible to search HTML contents of messages

[Gregor Zattler]

Hi David, Mohsin,
* David Bremner  [2024-09-02; 22:12 -03]:
> Mohsin Kaleem  writes:
>> David Bremner  writes:
> You can search any header if you index it first. See notmuch-config(1)
> for how to configure extra headers. Received seems like the most likely
> to have what you want. I'm curious how much it bloats the database, but
> I guess compared to all of the attachments people send these days it
> probably is not that bad.

I let notmuch index Received: headers
with this customization:

notmuch config set index.header.Received Received

But this only indexes the topmost
Received: header of every email, which
is uninformative because at least in
case of my mail setup, it always starts
with

Received: from localhost ([127.0.0.1] helo=

which I believe stems from fetchmail
handing the received email over to exim
for delivery.  Notmuch (sic!) of
interest there (besides the time stamp
but the indexing does not help with date
range searches on the received time stamps).

I would be really great if all Received:
headers were indexed.


Regards, Gregor
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Is it possible to search HTML contents of messages

[David Bremner]

Mohsin Kaleem  writes:

> David Bremner  writes:
>
>> Our strategy for indexing html hasn't changed much since the
>> beginning. We just remove all tags using a simple state
>> machine. Unfortunately the term you want to search for is an attribute
>> of an href tag. Offhand I can't think of a simple improvement that would
>> help.
>
> I see, would it be possible to search the properties of a message
> instead? Like the headers for example. Received from some .ru domain or
> something similar to that.
>

You can search any header if you index it first. See notmuch-config(1)
for how to configure extra headers. Received seems like the most likely
to have what you want. I'm curious how much it bloats the database, but
I guess compared to all of the attachments people send these days it
probably is not that bad.

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: WIP: git-remote-notmuch

[David Bremner]

David Bremner  writes:

> 3) The original script took a path to mail_root, but this doesn't
> really cover the possible split configurations; in particular it
> doesn't handle my (XDG) layout. The current code just looks for the
> "default" notmuch setup, and ignores the URL.  I am open to ideas for
> how a notmuch URL should look like. I'd imagine they should have the
> profile in them, but I'm not sure how much flexibility we need / want
> to suppot.

I guess some kind of key value scheme like

  notmuch://?profile=foo
  notmuch::?profile=foo
  
or

  notmuch://?config=.bar?database=fub/zub

would work, basically a thin wrapper around
notmuch_database_open_with_config.

There is still room for bikeshedding about the syntax.  We could throw
in "localhost" for future-proofing,

notmuch://localhost

would pass NULL to all 3 relevant parameters of n_d_o_w_c
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] Install notmuch-git during make install

[Michael J Gruber]

Am Fr., 23. Aug. 2024 um 17:46 Uhr schrieb Martin Jambor :
>
> Hi,
>
> On Thu, Aug 22 2024, Michael J Gruber wrote:
> > Am Do., 22. Aug. 2024 um 14:37 Uhr schrieb Martin Jambor :
> >>
> >> Hi,
> >>
> >> I have noticed that notmuch-git was not being copied to an appropriate
> >> destination during make install.  This patch adds that.
> >>
> >> ---
> >>  Makefile.local | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Makefile.local b/Makefile.local
> >> index 7699c208..34e8b882 100644
> >> --- a/Makefile.local
> >> +++ b/Makefile.local
> >> @@ -278,6 +278,7 @@ notmuch-shared: $(notmuch_client_modules) 
> >> lib/$(LINKER_NAME)
> >>  install: all install-man install-info
> >> mkdir -p "$(DESTDIR)$(prefix)/bin/"
> >> install notmuch-shared "$(DESTDIR)$(prefix)/bin/notmuch"
> >> +   install notmuch-git "$(DESTDIR)$(prefix)/bin/notmuch-git"
> >
> > notmuch-git(1) mentions nmbug, so we'd want to install that as well, don't 
> > we?
>
> I don't know.   I have never even contemplated using it but it looks
> much more like an internal tool to me.
>
> However, after a discussion about notmuch-git on the IRC I learned that
> there may be plans to change it, so perhaps even my patch should be
> postponed until after that.  I really don't know.

I just think that if the doc points to both we should install both.

In Debian and Fedora, we do so already - in a sub-package, that is. An
equivalent could be a make target which installs both but isn't
necessarily part of the install target.
nmbug is just a link to notmuch-git, btw.

Cheers
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[Alexander Adolf]

First of all, apologies for being late to the discussion, and for having
missed its initial part.

I have been tinkering with email address completion in message mode for
a while, and would like to add a few comments with the hope of providing
slightly bigger picture, and with the hope that it may help you in
deciding on possible ways forward.

The email completion in message.el is in a state of - let's say "layers
of history". Having code specific to several email address databases in
there doesn't seem to provide a clear road-map how future extensions
(for instance adding notmuch's address database) will work.
Notmuch-address's fiddling with message-completion-alist can get in the
way, and message-tab is a pain of its own.

I have hence experimented with removing all email address database
specific code from message.el, and making it use a single mechanism
only, EUDC (lisp/net/eudc.el). EUDC already has backends for querying
ldap, bbdb, mailabbrev, and ecomplete. Queries to EUDC deliver
aggregated results from all configured backends. I have thus written a
new EUDC backend so it can additionally query notmuch-address (code
attached for reference). Adapting that to any potential new notmuch
email address lookup would be no big deal, of course. Now, when I need
completion for an email address in (notmuch) message mode, it queries
EUDC, and I am presented a combined list of results from all EUDC
backends I have configured. Nice.

While this may be cool as an exercise, and for keeping in a personal
branch (which is what I'll do for the time being), it does not provide
any immediate benefit for the notmuch project, however, because there is
no indication as to whether and when in the future message.el may indeed
be updated to only use EUDC for email addresses.

In that light, tarsius's proposed notmuch-addr code, and without having
tried it, does seem like it could be a worthwhile improvement over the
current state of things. I'd therefore tend to welcome Antoine's
proposed steps. I'd also offer to test drive tarsius's code (or
variations of it) in my setup.


Hoping to have helped, and looking forward to your thoughts,

  --alexander




eudcb-notmuch-address.el
Description: application/emacs-lisp
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] Install notmuch-git during make install

[Martin Jambor]

Hi,

On Thu, Aug 22 2024, Michael J Gruber wrote:
> Am Do., 22. Aug. 2024 um 14:37 Uhr schrieb Martin Jambor :
>>
>> Hi,
>>
>> I have noticed that notmuch-git was not being copied to an appropriate
>> destination during make install.  This patch adds that.
>>
>> ---
>>  Makefile.local | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Makefile.local b/Makefile.local
>> index 7699c208..34e8b882 100644
>> --- a/Makefile.local
>> +++ b/Makefile.local
>> @@ -278,6 +278,7 @@ notmuch-shared: $(notmuch_client_modules) 
>> lib/$(LINKER_NAME)
>>  install: all install-man install-info
>> mkdir -p "$(DESTDIR)$(prefix)/bin/"
>> install notmuch-shared "$(DESTDIR)$(prefix)/bin/notmuch"
>> +   install notmuch-git "$(DESTDIR)$(prefix)/bin/notmuch-git"
>
> notmuch-git(1) mentions nmbug, so we'd want to install that as well, don't we?

I don't know.   I have never even contemplated using it but it looks
much more like an internal tool to me.

However, after a discussion about notmuch-git on the IRC I learned that
there may be plans to change it, so perhaps even my patch should be
postponed until after that.  I really don't know.

Martin

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] Install notmuch-git during make install

[David Bremner]

Michael J Gruber  writes:


> notmuch-git(1) mentions nmbug, so we'd want to install that as well, don't we?
>

FWIW, we do in Debian. But I am probably biased as one of the main users
of nmbug and the Debian package maintainer.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] Install notmuch-git during make install

[Michael J Gruber]

Am Do., 22. Aug. 2024 um 14:37 Uhr schrieb Martin Jambor :
>
> Hi,
>
> I have noticed that notmuch-git was not being copied to an appropriate
> destination during make install.  This patch adds that.
>
> ---
>  Makefile.local | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Makefile.local b/Makefile.local
> index 7699c208..34e8b882 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -278,6 +278,7 @@ notmuch-shared: $(notmuch_client_modules) 
> lib/$(LINKER_NAME)
>  install: all install-man install-info
> mkdir -p "$(DESTDIR)$(prefix)/bin/"
> install notmuch-shared "$(DESTDIR)$(prefix)/bin/notmuch"
> +   install notmuch-git "$(DESTDIR)$(prefix)/bin/notmuch-git"

notmuch-git(1) mentions nmbug, so we'd want to install that as well, don't we?

>  ifeq ($(MAKECMDGOALS), install)
> @echo ""
> @echo "Notmuch is now installed to $(DESTDIR)$(prefix)"
> --
> 2.46.0
>
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[David Bremner]

Antoine Beaupré  writes:

>
> I'm fine with that too, what's the next step? A patch that actually
> replaces the notmuch-address.el stuff with tarsis's? A reply to tarsius'
> original patch? :)
>
> I can try either, but don't have the latter in my archives, i think.


My plan is as follows.

1) release 0.39 soonish, after applying some fixes currently under review.
(particularly the refresh fixs in emacs).

2) Deprecate emacs older than 27.1 in 0.39.

3) wait for address completion patches to test

I'll try to test the functionality [1] at some point in that interval, but
if we are going to replace the existing address completion code we'll
need updates to the tests and documentation. Other people testing their
use cases would be welcome as well.

d

[1]: https://github.com/tarsius/notmuch-addr
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] emacs/mua: Correct autoload cookies

[David Bremner]

Pengji Zhang  writes:

> This is a follow-up to [1: 8d06dfce]. Per Info node '(elisp)Autoload',
> autoload cookies should start with ';;;###'.
>
> 1: 2024-04-04 8d06dfce175593aebae9a759c9167df4988a3444
>emacs: Autoload notmuch-user-agent related functions

applied to master, thanks
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[Antoine Beaupré]

On 2024-08-13 10:05:40, David Bremner wrote:
> Antoine Beaupré  writes:
>
>>
>> So I'm not sure what to do with this. This certainly seems really
>> precious stuff! Could we add this to notmuch-emacs, perhaps gated on the
>> Emacs version?
>>
>> Running Emacs 29.4 from Debian bookworm-backports here, in case that
>> matters.
>>
>
> I'm more interested in changing the baseline requirement for
> notmuch-emacs to emacs 27 than in shipping two address completion
> frameworks.  Emacs 27 is about 4 years old now, so should be available
> for most people (but not all).
>
> From a debian point of view, the last version that shipped with emacs
> pre-27 has fallen out of long term support a month ago, and even that
> version has emacs 27 in backports.  People on "enterprise" systems will
> probably be worse off, per usual.

I'm fine with that too, what's the next step? A patch that actually
replaces the notmuch-address.el stuff with tarsis's? A reply to tarsius'
original patch? :)

I can try either, but don't have the latter in my archives, i think.

-- 
The United States is a nation of laws:
badly written and randomly enforced.
- Frank Zappa
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[David Bremner]

Antoine Beaupré  writes:

>
> So I'm not sure what to do with this. This certainly seems really
> precious stuff! Could we add this to notmuch-emacs, perhaps gated on the
> Emacs version?
>
> Running Emacs 29.4 from Debian bookworm-backports here, in case that
> matters.
>

I'm more interested in changing the baseline requirement for
notmuch-emacs to emacs 27 than in shipping two address completion
frameworks.  Emacs 27 is about 4 years old now, so should be available
for most people (but not all).

From a debian point of view, the last version that shipped with emacs
pre-27 has fallen out of long term support a month ago, and even that
version has emacs 27 in backports.  People on "enterprise" systems will
probably be worse off, per usual.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Emacs: Generate autoloads during installation?

[David Bremner]

Pengji Zhang  writes:

>
> I wonder if we could generate and install a 'notmuch-autoloads.el' 
> file as well during installation, like mu4e[1]. So we only need to 
> load that file at Emacs startup, which should be much cheaper.

Currently notmuch-autoloads.el is generated by package.el
during installation. To try it out, run

make elpa

then

M-x package-install-file notmuch-emacs-$version.tar

I guess as long as it did not break the various package.el workflows, we
could consider running the same auto-generation code at build time.


___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: git:// download of notmuch is currently broken

[Michael J Gruber]

Am So., 11. Aug. 2024 um 21:12 Uhr schrieb Tomi Ollila :
>
> On Sat, Aug 10 2024, David Bremner wrote:
>
> > Apparently recent security related changes for git have broken our setup
> > for download of the notmuch repo via git:// protocol. I think not much
> > people use that, as it's been broken for months and nobody noticed until
> > recently.

I noticed, switched to https and went ahead.

> > Anyway, it's on my list of things to fix, but it's not really a
> > priority. I'd welcome _good_ reasons why people cannot switch to to
> > https, that might cause me to re-prioritize

Port-wise, https:// should be possible for even more people than git://

> I recall the git:// worked to pull 2024-06-15 14:54 -0300 Marc Fargas ...
>
> Since then this change
>
>   #url = git://notmuchmail.org/git/notmuch
>   url = http://git.notmuchmail.org/git/notmuch

Disabling git:// by default follows a step taken by github about 2
years ago. The point is that https:// is encrypted and the
authenticity of the server endpoint is checked "in the ssl sense".
Offering/using that via http works but defeats the purpose. [Also,
setting up https:// user authentication may or may not be easier than
ssh.]

Cheers
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[Antoine Beaupré]

On 2024-08-11 10:36:07, Liam Hupfer wrote:
> Antoine Beaupré  writes:
>
>> I should have posted a followup to this patch already, and must say it’s
>> really not ready at all.
>>
>> I have found myself in the situation where my address completion is now
>> completely broken. I don’t even *know* how to restore the previous
>> behavior.
>>
>> So clearly, this patch should be ignored for now… But I do feel we
>> should somehow figure out how to hook ourselves in there. There’s
>> probably a way to do some asynchronous thing here, and indeed that’s how
>> even the normal tab completion works, from what I gathered.
>>
>> But this is getting way too deep for me.
>>
>> I will definitely need to look at this again soon though because my
>> stuff is broken, I will try to keep you updated.
>
> As you mentioned upthread, there have been [previous attempts] at this,
> the first of which was by (Emacs household name!) Jonas Bernoulli in
> [[PATCH 0/3] emacs: allow opting out of notmuch’s address completion]. He
> implemented a separate package, available from MELPA and [GitHub -
> tarsius/notmuch-addr: An alternative to notmuch-address.el].
>
> notmuch-addr works great for me with Corfu. Perhaps it can someday ship
> with Notmuch as an alternative to notmuch-address or even replace it
> outright when notmuch moves the minimum supported Emacs version to 27.1.

Oh! This is actually pretty interesting, i didn't realize tarsius made a
standalone package for this...

I have just tested this briefly and it *seems* to work well. For some
reason, the *first* call to it was very slow, with Emacs hanging along
with the message "Collecting email addresses..." in the message
bar... Further calls were near instantaneous even after spawning a new
buffer...

So I'm not sure what to do with this. This certainly seems really
precious stuff! Could we add this to notmuch-emacs, perhaps gated on the
Emacs version?

Running Emacs 29.4 from Debian bookworm-backports here, in case that
matters.

a.
-- 
Dr. King’s major assumption was that if you are nonviolent, if you
suffer, your opponent will see your suffering and will be moved to
change his heart. He only made one fallacious assumption: In order for
nonviolence to work, your opponent must have a conscience. The United
States has none.- Stokely Carmichael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: git:// download of notmuch is currently broken

[Tomi Ollila]

On Sat, Aug 10 2024, David Bremner wrote:

> Apparently recent security related changes for git have broken our setup
> for download of the notmuch repo via git:// protocol. I think not much
> people use that, as it's been broken for months and nobody noticed until
> recently.
>
> Anyway, it's on my list of things to fix, but it's not really a
> priority. I'd welcome _good_ reasons why people cannot switch to to
> https, that might cause me to re-prioritize

I recall the git:// worked to pull 2024-06-15 14:54 -0300 Marc Fargas ...

Since then this change

  #url = git://notmuchmail.org/git/notmuch
  url = http://git.notmuchmail.org/git/notmuch

and pull changed my HEAD to

4e85abda (2024-08-09 10:18 -0300 David Bremner) 

>
> The notmuch-wiki repo (which is the main reason to support git://
> currently) should be working fine.

There my current HEAD is b84bed0 (2024-05-26 09:10 -0300 David Bremner)

I'd be fine if this changed to http[s] for whatever reason.

>
> d

Tomi
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [RFC PATCH] CLI/reply: Remove Received by domain From detection

[Liam Hupfer]

Bumping this patch ([[RFC PATCH] CLI/reply: Remove Received by domain
>From detection]). See the rationale there.

Does anyone depend on notmuch-reply’s fallback to Received by parsing?
Adding Carl Worth, who applied the initial implementation by Dirk
Hohndel (who doesn’t seem to be around) in [Re: [PATCH 2/2] guess From
address from Received headers], and Jani Nikula, who has refactored the
code more recently.

Note that my patch only removes step 4 from the below steps to derive
the From address:

1. Scan Reply-to, From, To, Cc, Bcc headers for a user address
2. Scan Envelope-to, X-Original-To, Delivered-To headers for a user
   address
3. Scan Received headers for “for ”
4. Scan the “by” portion of Received headers for the domain part of user
   addresses
5. Fall back to the primary user address

Please let me know what you think! Thanks,

—Liam


[[RFC PATCH] CLI/reply: Remove Received by domain
>From detection] 
><https://nmbug.notmuchmail.org/nmweb/show/87r0eq36x4.fsf%40hpfr.net>

[Re: [PATCH 2/2] guess From
address from Received headers] 
<https://nmbug.notmuchmail.org/nmweb/show/87aatg6n6x.fsf%40yoom.home.cworth.org>
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[Liam Hupfer]

Antoine Beaupré  writes:

> I should have posted a followup to this patch already, and must say it’s
> really not ready at all.
>
> I have found myself in the situation where my address completion is now
> completely broken. I don’t even *know* how to restore the previous
> behavior.
>
> So clearly, this patch should be ignored for now… But I do feel we
> should somehow figure out how to hook ourselves in there. There’s
> probably a way to do some asynchronous thing here, and indeed that’s how
> even the normal tab completion works, from what I gathered.
>
> But this is getting way too deep for me.
>
> I will definitely need to look at this again soon though because my
> stuff is broken, I will try to keep you updated.

As you mentioned upthread, there have been [previous attempts] at this,
the first of which was by (Emacs household name!) Jonas Bernoulli in
[[PATCH 0/3] emacs: allow opting out of notmuch’s address completion]. He
implemented a separate package, available from MELPA and [GitHub -
tarsius/notmuch-addr: An alternative to notmuch-address.el].

notmuch-addr works great for me with Corfu. Perhaps it can someday ship
with Notmuch as an alternative to notmuch-address or even replace it
outright when notmuch moves the minimum supported Emacs version to 27.1.

—Liam


[previous attempts] 

[[PATCH 0/3] emacs: allow opting out of notmuch’s address completion] 


[GitHub -
tarsius/notmuch-addr: An alternative to notmuch-address.el] 

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[David Bremner]

Antoine Beaupré  writes:

>
> I should have posted a followup to this patch already, and must say it's
> really not ready at all.
>
> I have found myself in the situation where my address completion is now
> completely broken. I don't even *know* how to restore the previous
> behavior.
>
> So clearly, this patch should be ignored for now... But I do feel we
> should somehow figure out how to hook ourselves in there. There's
> probably a way to do some asynchronous thing here, and indeed that's how
> even the normal tab completion works, from what I gathered.

Thanks for the update / explanation. Indeed, the existing address completion
stuff is pretty complex.

d

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[Antoine Beaupré]

On 2024-08-06 07:30:30, David Bremner wrote:
> Antoine Beaupré  writes:
>
>>
>> Now, it seems to me a simple fix is to implement a proper
>> capf (`completion-at-point-function') for notmuch. And that, in turn,
>> is actually pretty simple compared to the code hidden underneath
>> `notmuch-address-expand-name', which not only finds completion
>> candidates, but also does the whole trouble of editing the buffer.
>
> Disclaimer: I have not looked at 'capf' before today.
>
> Did you see the note at the end of docstring for completion-at-point
> functions
>
> NOTE: These functions should be cheap to run since they’re sometimes
> run from ‘post-command-hook’; and they should ideally only choose
> which kind of completion table to use, and not pre-filter it based
> on the current text between START and END (e.g., they should not
> obey ‘completion-styles’).
>
> I'm not sure how expensive #notmuch-address-options is with the
> defaults, but calling it from post-command-hook does sound like it could
> be problematic.
>
> A second question I have about this change is how can we test
> completion? It is quite complex already, and I'm nervous about breakage.

I should have posted a followup to this patch already, and must say it's
really not ready at all.

I have found myself in the situation where my address completion is now
completely broken. I don't even *know* how to restore the previous
behavior.

So clearly, this patch should be ignored for now... But I do feel we
should somehow figure out how to hook ourselves in there. There's
probably a way to do some asynchronous thing here, and indeed that's how
even the normal tab completion works, from what I gathered.

But this is getting way too deep for me.

I will definitely need to look at this again soon though because my
stuff is broken, I will try to keep you updated.

a.
-- 
It is better to sit alone than in company with the bad; and it is better
still to sit with the good than alone. It better to speak to a seeker of
knowledge than to remain silent; but silence is better than idle words.
- Imam Bukhari
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Selection bug

[David Bremner]

David Bremner  writes:

> David Bremner  writes:
>
>>
>> This reproduces the problem for me. Indeed it looks a bit like a similar
>> "cursor jumping" problem I have seen (and someone else has reported on
>> IRC). I will see if I can figure anything more out now that I have a
>> reproducer.
>
> I think the following is a (simpler) reproducer of the same problem.
>
> 1) Do a search with at least 10 results
>
> 2) goto line 10
>
> 3) hit 'g'
>
> For me this consistently leaves the point on line 10 but the hl-line bar
> on line 1. I have not debugged it yet, but the proximate cause is that
> when notmuch-hl-line-mode is called, (point) is 1, so the bar ends up on
> the first line. The whys and wherefores I don't know yet.

I have been slowly trying to debug this. It is a kind of heisenbug
because the position of the hl-line-mode bar is affected by using the
debugger (because hl-line-mode uses post-command-hook).

My current understanding is

0) the refresh calls notmuch-search to rebuild the buffer contents.

1) hl-line-highlight is being called via notmuch-search-hook

2) notmuch-search-hook is being invoked asynchronously from
   notmuch-search-process-filter.

3) There is a buffer local variable notmuch--search-hook-run used to
   make sure this happens only once per call to notmuch-search.

4) Unfortunately when the hook is invoked, (point) is 1, and that
   is how the hl-line-mode bar ends up on the first line, rather than
   where the (point) is after the refresh completes.

A) one question is why notmuch-search-hook is being run so early. I
vaguely remember some discussion / reason for this but I have not dug it
up.

B) I have some hope this can be fixed by use of the existing variable
   notmuch-search-target-line, but it's a bit tricky because
   at the point where the hook is invoked, the buffer does not have
   that many lines yet.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] Fix saved-search buffer titles

[Rudolf Adamkovič]

David Bremner  writes:

> If you can make a reproducer that does not rely on your private notmuch
> config (query:list), I might be able to turn that into a test.

The reproducer does not rely on anything private.  Simply evaluate the
expression, say using C-x C-e.  You should see it evaluate to the
ACTUAL, as opposed to the EXPECTED, value.

Rudy
-- 
"Great minds discuss ideas; average minds discuss events; small minds
discuss people."  --- Anna Eleanor Roosevelt (1884-1962)

Rudolf Adamkovič  [he/him]
http://adamkovic.org
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Carriage returns in subject line cause problems in unthreaded and tree mode

[David Bremner]

Tomi Ollila  writes:

>
> -- and is the behavior different in some other modes (I (mostly) just use 
> notmuch-search and notmuch-show modes so cannot recall how other views
> look like...
>

Yes, the issue is exactly making the behaviour consistent between
modes. It's not just ^M but also tabs that cause messiness.

In the end I decided to apply the change to master, since the code
changes are relatively small (I admit the impact on the test suite is
larger than desirable).

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] CLI/show: warn if crypto options are used with mbox format

[David Bremner]

David Bremner  writes:

> This limitation seems somewhat hard to fix, but at least try to warn
> users when combining crypto operations with mbox output format.
>
> Because the default is --decrypt=auto, the warning is omitted if
> --decrypt=auto is specified. While this is not great, it seems more
> wrong to always warn, or to change the default because of this.

Applied to master, with some minor whitespace cleanup.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] implement a capf for address completion

[David Bremner]

Antoine Beaupré  writes:

>
> Now, it seems to me a simple fix is to implement a proper
> capf (`completion-at-point-function') for notmuch. And that, in turn,
> is actually pretty simple compared to the code hidden underneath
> `notmuch-address-expand-name', which not only finds completion
> candidates, but also does the whole trouble of editing the buffer.

Disclaimer: I have not looked at 'capf' before today.

Did you see the note at the end of docstring for completion-at-point
functions

NOTE: These functions should be cheap to run since they’re sometimes
run from ‘post-command-hook’; and they should ideally only choose
which kind of completion table to use, and not pre-filter it based
on the current text between START and END (e.g., they should not
obey ‘completion-styles’).

I'm not sure how expensive #notmuch-address-options is with the
defaults, but calling it from post-command-hook does sound like it could
be problematic.

A second question I have about this change is how can we test
completion? It is quite complex already, and I'm nervous about breakage.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] Fix saved-search buffer titles

[David Bremner]

Rudolf Adamkovič  writes:

> From c0cb08a843b5c904642da639f94c4a5e43d1ef14 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
> Date: Wed, 13 Dec 2023 22:39:02 +0100
> Subject: [PATCH] emacs: Fix saved-search buffer titles
>
> REPRODUCTION STEPS:
>
>   (let ((notmuch-saved-searches
>  (list (list :name "Emacs List"
>  :query "query:lists-emacs")
>(list :name "All Lists"
>  :query "query:lists"
> (notmuch-search-buffer-title "query:lists-emacs" ))
>
> ACTUAL:
>
>   "*notmuch-saved-search-[ All Lists ]-emacs*"
>
> EXPECTED:
>
>"*notmuch-saved-search-Emacs List*"

If you can make a reproducer that does not rely on your private notmuch
config (query:list), I might be able to turn that into a test.

> +   (cl-loop with match
> +with match-length = 0
> +for candidate in notmuch-saved-searches
> +for length = (let* ((query* (notmuch-saved-search-get
> + candidate
> + :query))
> +(regexp (concat "^"
> +(regexp-quote query*
> +   (and (string-match regexp query)
> +(length (match-string 0 query
> +if (and length (> length match-length))
> +do (setq match candidate
> + match-length length)
> +finally return match))

Sorry, I don't really speak cl-loop. You can either hope someone else
reviews it and convinces me, or try a less intrusive restructuring of
the existing code.


___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] devel: document emacs keybindings u and U

[David Bremner]

David Bremner  writes:

> Thanks to changing the column widths to accomodate longer function
> names, the diff is rather large, but the content is two new rows for
> 'u' and 'U'

applied to master.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 0/4] Bug fixes for Debian packaging

[David Bremner]

Nicholas D Steeves  writes:

> James McCoy (1):
>   Convert notmuch-vim to Vim addon policy 2.0
>
> Nicholas D Steeves (3):
>   Add changelog entry for James McCoy's work
>   Allow neomutt to fulfill the "mutt" requirement of notmuch-mutt, and
>   Add Astroid as an alternative Recommends; this one is a GU

Series applied to release branch and uploaded to Debian unstable
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: bug: filename points to wrong location

[David Bremner]

Thorben Günther  writes:

> I noticed this when investigating an aerc bug report [1].
>
> When the notmuch config contains a different location for
> database.mail_root (e.g. ~/.mail/user) and database.path (unset,
> should default to ~/.local/share/notmuch/default), the filepath returned
> by "notmuch_message_get_filename" points to the database path instead of
> the mail_root path.
> Here is a simple reproduction in python [2], that uses the problematic
> "notmuch_message_get_filename".
> "notmuch show" on the other hand does have the correct filename/path.
>
>
> [1]: https://todo.sr.ht/~rjarry/aerc/106
> [2]: https://paste.xenrox.net/~xenrox/d7048c7b5392df940586b42673aeba97c176d489

According to an IRC comment from Thorben, this issue can be fixed on the
aerc side by changing the call to notmuch_database_open_with_config.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 1/3] Add Astroid as an alternative Recommends; this one is a GUI client…

[David Bremner]

Nicholas D Steeves  writes:

>
> I have an old clone from https://git.notmuchmail.org/git/notmuch; and I
> track two branches: debian/unstable and release.  I made sure both were
> up to date.  The presence of debian/unstable usually indicates DEP14
> layout, and I noticed all the other debian/codename remote branches...
>

Sorry, I'm not much for following DEP** even in Debian specific repos
(which this one is not). Anyway, thanks for resending the patches, I'll
try to have a look today.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 1/3] Add Astroid as an alternative Recommends; this one is a GUI client…

[Nicholas D Steeves]

David Bremner  writes:

> Hi Nicholas;
>
> Thanks for the patches.

You're welcome.

> Unfortunately they are against 5 year old version of notmuch and don't
> apply.

Oh no.

> On debian you can try
>
> $ debcheckout notmuch
>
> For debian only stuff, patches against the release branch (default) are
> fine.
>
> Cheers,
>
> d

I have an old clone from https://git.notmuchmail.org/git/notmuch; and I
track two branches: debian/unstable and release.  I made sure both were
up to date.  The presence of debian/unstable usually indicates DEP14
layout, and I noticed all the other debian/codename remote branches...

Yup, I didn't inspect things beyond that, and it seemed like master was
the upstream devel branch and that release was the upstream release
branch.

Ah well, rebasing now (and checking again if BTS patches apply cleanly).  I'll 
send a new patch series soon.

Cheers,
Nick


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 1/3] Add Astroid as an alternative Recommends; this one is a GUI client…

[David Bremner]

Nicholas D Steeves  writes:

> that may be less intimidating for new users.
> ---
>  debian/changelog | 7 +++
>  debian/control   | 2 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/debian/changelog b/debian/changelog
> index 72a52546..442e22ed 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +notmuch (0.29.1-3) UNRELEASED; urgency=medium
> +
> +  * Add Astroid as an alternative Recommends; this one is a GUI client that
> +may be less intimidating for new users.
> +
> + -- Nicholas D Steeves   Fri, 02 Aug 2024 16:37:20 -0400
> +

Hi Nicholas;

Thanks for the patches.

Unfortunately they are against 5 year old version of notmuch and don't
apply.

On debian you can try

$ debcheckout notmuch

For debian only stuff, patches against the release branch (default) are
fine.

Cheers,

d

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 2/2] Add notmuch-search-show-or-unthread

[David Bremner]

Sandra Snan  writes:

> David Bremner  writes:
>> 1) can you make a test (probably something in T465 can serve as 
>> a model
>
> What does T465 refer to?

test/T465-emacs-unthreaded.sh

>
> But if the treshhold is too big it won't prevent any crashes, 
> overloads, or uncomfortably unergonomic thread view. It needs to 
> be within a useful range. Maybe 35, 40 or so. I've been sticking 
> with the "< 11" threshold I sent in the patch.
>
I suggested a large value to make it "opt in", but if there is a broader
consensus I'm fine with a more "active" default.

>> There is a slight performance penalty from add notmuch count; 
>> I'm not sure if this is noticable.
>
> Right. Since my machine is very fast I've not noticed any 
> slowdown at all.

Let's get the function into master and documented and go from
their. Hopefully a few users will give us feedback on performance impact
(if any).

You can preview the documentation with e.g.

   make sphinx-html && firefox _build/html/notmuch-emacs.html

The docs in doc/notmuch-emacs.rst are sortof "semi-automated"; in
cheerful violation of Emacs documentation standards they use the
function docstrings in the manual.

At least the customize can be added, and if it makes sense with our
current level of indecision, the function could be added also (although
the docs are user focused, so they mainly talk about keybindings).

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 2/2] Add notmuch-search-show-or-unthread

[Sandra Snan]

David Bremner  writes:
1) can you make a test (probably something in T465 can serve as 
a model


What does T465 refer to?

2) Should this be bound by default, or is the function in the 
next patch always the one users will want?


The latter since it prevents crashes. I've been dogfooding this 
since I made it. It's been so great since I have huge threads 
that used to overload Emacs and that's finally no longer a 
problem.


"Big" is hardcoded to ten messages or lower, if we want to 
introduce a variable for that instead, that might be great.


Yes, I think a defcustom is called for.


Right. Even if we find the perfect number and set that as the 
default, it's just good Emacs practice to make it a defcustom.


Some of that explanation can maybe go in the docstring of the 
newly defined customize variable


I'll try!

emacs wants to indent this line differently, so please follow 
its lead here.


Wilco!

One option is to replace the default notmuch-search-show-thread 
binding


Yes, that's what I've done locally. An even stronger step in that 
direction would be to make this the new 
notmuch-search-show-thread.


and just set the threshhold very high so that most users will 
not notice the change.


But if the treshhold is too big it won't prevent any crashes, 
overloads, or uncomfortably unergonomic thread view. It needs to 
be within a useful range. Maybe 35, 40 or so. I've been sticking 
with the "< 11" threshold I sent in the patch.


There is a slight performance penalty from add notmuch count; 
I'm not sure if this is noticable.


Right. Since my machine is very fast I've not noticed any 
slowdown at all. It's instant. A drawback of working on a fast 
machine, I don't know what's too slow for more retro-minded 
users. But even though my machine is fast it still couldn't 
handle the big threads. 
___

notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] config: allow custom separators in author lists

[David Bremner]

Lars Kotthoff  writes:

> Thanks David, I've attached the modified patch that I think addresses
> all your comments -- I'm still not 100% sure about the whitespace
> though.

tweaked version applied to master.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] config: allow custom separators in author lists

[Lars Kotthoff]

Thanks David, I've attached the modified patch that I think addresses all your 
comments -- I'm still not 100% sure about the whitespace though.

Thanks,

Lars


On Thu, 25 Jul 2024 17:33:48 +0900, David Bremner  wrote:
> Lars Kotthoff  writes:
> 
> > Sorry, I dropped the ball on this -- here's the patch again with space/tab 
> > inconsistencies fixed. I wasn't entirely sure about this as it's 
> > inconsistent in the existing source, so I tried to make it as consistent as 
> > possible. Cover included again below.
> >
> 
> Hi Lars,
> 
> Thanks for sticking with this, and sorry I did not respond to the first
> thread. There are still one or two minor whitespace issues.  If you have
> "uncrustify" installed, then ./devel/check-notmuch-commit && git diff
> will find the ones I'm thinking of. You can ignore the problems you
> didn't introduce.
> 
> > The attached patch allows to customize the default ", " and "| "
> > separators in author lists. The main rationale for supporting this is
> > that the Python API uses the same functionality to get the list of
> > authors -- if I want to separate them again afterwards, I have to
> > split the returned string, which is error-prone with comma separators
> > (e.g. name in email address is of form Lastname, Firstname).
> 
> Can you add a brief summary of the motivation to the commit message?
> 
> >  test/T030-config.sh |  2 ++
> >  test/T055-path-config.sh|  4 
> >  test/T590-libconfig.sh  | 10 ++
> 
> Thanks for adjusting the existing test suite.
> 
> Can you also add a simple test to check the functionality you
> introduced? Testing the CLI is fine, or if you prefer something in the
> style of test/T590-libconfig.sh
> 
From 60aab0c8a9a8164abb32ea306b7fd894a18a2477 Mon Sep 17 00:00:00 2001
From: Lars Kotthoff 
Date: Fri, 22 Dec 2023 14:06:34 -0700
Subject: [PATCH] config: allow custom separators in author lists to allow to distinguish between commas separating authors and separating first and last names

---
 NEWS| 11 +++
 doc/man1/notmuch-config.rst | 13 +
 lib/config.cc   |  8 
 lib/notmuch.h   |  2 ++
 lib/thread.cc   | 19 ++-
 test/T030-config.sh |  2 ++
 test/T055-path-config.sh|  4 
 test/T590-libconfig.sh  | 10 ++
 8 files changed, 64 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index 315f4136..b306d095 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+Notmuch 0.39 (UNRELEASED)
+=
+
+General
+---
+
+Allow to customize the separator between individual and matched and non-matched
+authors when showing threads. See `search.authors_separator` and
+`search.authors_matched_separator` in notmuch-config(1).
+
+
 Notmuch 0.38.2 (2023-12-01)
 ===
 
diff --git a/doc/man1/notmuch-config.rst b/doc/man1/notmuch-config.rst
index bd34afa4..5106655f 100644
--- a/doc/man1/notmuch-config.rst
+++ b/doc/man1/notmuch-config.rst
@@ -273,6 +273,19 @@ paths are presumed relative to `$HOME` for items in section
 Default: empty list. Note that :any:`notmuch-setup(1)` puts
 ``deleted;spam`` here when creating new configuration file.
 
+.. nmconfig:: search.authors_separator
+
+The string to separate authors when showing a thread.
+
+Default: ,
+
+.. nmconfig:: search.authors_matched_separator
+
+The string to separate matched from non-matched authors when showing a
+thread.
+
+Default: |
+
 .. nmconfig:: show.extra_headers
 
 By default :any:`notmuch-show(1)` includes the following headers
diff --git a/lib/config.cc b/lib/config.cc
index 6cd15fab..a3102dce 100644
--- a/lib/config.cc
+++ b/lib/config.cc
@@ -608,6 +608,10 @@ _notmuch_config_key_to_string (notmuch_config_key_t key)
 	return "database.autocommit";
 case NOTMUCH_CONFIG_EXTRA_HEADERS:
 	return "show.extra_headers";
+case NOTMUCH_CONFIG_AUTHORS_SEPARATOR:
+	return "search.authors_separator";
+case NOTMUCH_CONFIG_AUTHORS_MATCHED_SEPARATOR:
+	return "search.authors_matched_separator";
 case NOTMUCH_CONFIG_INDEX_AS_TEXT:
 	return "index.as_text";
 default:
@@ -658,6 +662,10 @@ _notmuch_config_default (notmuch_database_t *notmuch, notmuch_config_key_t key)
 	return "";
 case NOTMUCH_CONFIG_AUTOCOMMIT:
 	return "8000";
+case NOTMUCH_CONFIG_AUTHORS_SEPARATOR:
+	return ", ";
+case NOTMUCH_CONFIG_AUTHORS_MATCHED_SEPARATOR:
+	return "| ";
 case NOTMUCH_CONFIG_EXTRA_HEADERS:
 case NOTMUCH_CONFIG_HOOK_DIR:
 case NOTMUCH_CONFIG_BACKUP_DIR:
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 4e2b0fa4..937fa24e 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -2565,6 +2565,8 @@ typedef enum {
 NOTMUCH_CONFIG_AUTOCOMMIT,
 NOTMUCH_CONFIG_EXTRA_HEADERS,
 NOTMUCH_CONFIG_INDEX_AS_TEXT,
+NOTMUCH_CONFIG_AUTHORS_SEPARATOR,
+NOTMUCH_CONFIG_AUTHORS_MATCHED_SEPARATOR,
 NOTMUCH_CONFIG_LAST
 } notmuch_config_key_t;
 
diff --git a/lib/thread.

Re: [PATCH 2/2] Add notmuch-search-show-or-unthread

[David Bremner]

Sandra Snan  writes:
>
> It shells out to notmuch count to see if the thread is big or small.
> "Big" is hardcoded to ten messages or lower, if we want to introduce a
> variable for that instead, that might be great.

Yes, I think a defcustom is called for.

>
> It's a deliberate choice to count all the messages in the thread, not
> just ones that are part of the search (a.k.a. the ones that will show
> up in the unthreaded view if the thread is big). The reason for that
> is that that's the number that matters when it comes to how well
> `notmuch-search-show-thread` can handle it. That's by design. So if
> there's a thread with 10 messages and four of them show up in the
> search (maybe because they have a particular tag or date), it'll see
> that the thread is big and "explode" it and then show those four new
> messages in a flat view.

Some of that explanation can maybe go in the docstring of the newly
defined customize variable
>  
> +(defun notmuch-search-show-or-unthread ()
> +  "If the thread is small, show it the normal notmuch way, and if
> +it's big, show the messages separatley in a buffer so you can
> +visit them individually."
> +  (interactive)
> +  (let ((thread-id (notmuch-search-find-thread-id)))
> +(if thread-id
> + (if (< 11 (notmuch-call-notmuch-sexp "count" thread-id))
> + (notmuch-search-unthread-thread)
> + (notmuch-search-show-thread))
emacs wants to indent this line differently, so please follow its lead here.

> +  (message "No such thread with that id found!")
> +  nil)))

I guess we should think about a default binding for this. One option is
to replace the default notmuch-search-show-thread binding, and just set
the threshhold very high so that most users will not notice the
change. There is a slight performance penalty from add notmuch count;
I'm not sure if this is noticable. 
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 1/2] Add notmuch-search-unthread-thread

[David Bremner]

Sandra Snan  writes:

> +  (interactive "P")
> +  (let ((thread-id (notmuch-search-find-thread-id)))
> +(if thread-id
> + (notmuch-unthreaded (if entire thread-id
> +   (concat notmuch-search-query-string " and " 
> thread-id)))
> +  (message "No such thread with that id found!")
> +  nil)))
> +

Hi Sandra;

This seems reasonable enough. Two questions

1) can you make a test (probably something in T465 can serve as a model

2) Should this be bound by default, or is the function in the next patch
always the one users will want?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] Check for erroneous subjects

[David Bremner]

Tony Zorman  writes:

> Hi,
>
> this adds a new custom variable, `notmuch-mua-subject-regexp`, and an
> associated function, `notmuch-mua-subject-check`, to warn the user when
> the subject contains potentially troublesome things (e.g., nothing at
> all). The idea is the same as `notmuch-mua-attachment-regexp`—which has
> saved my skin quite a few times in the past—but for the subject instead
> of an attachment. By default, it checks for empty subjects, as that
> seems to be a reasonable thing to safeguard against.

Applied to master. Thanks for writing such nice tests.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v2 2/2] lib: thread-safe s-expression query parser

[David Bremner]

Kevin Boulain  writes:

> Follow-up of 6273966d, now that sfsexp 1.4.1 doesn't rely on globals
> anymore by default (https://github.com/mjsottile/sfsexp/issues/21).
>
> This simply defers the initial query generation to use the thread-safe
> helper (xapian_query_match_all) instead of Xapian::Query::MatchAll.

I squashed to the two commits together, so the test is now
more like a regression test. While the testing situation is not ideal,
this is an improvement on the status quo, so I've applied the change to
master.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] emacs/hello: refresh hello directly

[David Bremner]

David Bremner  writes:

> According to the now deleted commentary, the hack of using run-at-time
> was needed for Emacs 24. It seems to be no longer needed for Emacs
> 28.2, and removing it makes further changes to the code simpler.

applied to master
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] CLI/git: add reset command

[David Bremner]

David Bremner  writes:

> Sometimes merging is not what we want with tags; in particular it
> tends to keep tags in the local repo that have been removed elsewhere.
> This commit provides a new reset command; the reset itself is trivial,
> but the work is to provide a safety check that uses the existing
> --force and git.safe_fraction machinery.

Applied to master. Although I did not receive any feedback, I have been
using this code myself for a while now.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] config: allow custom separators in author lists

[David Bremner]

Lars Kotthoff  writes:

> Sorry, I dropped the ball on this -- here's the patch again with space/tab 
> inconsistencies fixed. I wasn't entirely sure about this as it's inconsistent 
> in the existing source, so I tried to make it as consistent as possible. 
> Cover included again below.
>

Hi Lars,

Thanks for sticking with this, and sorry I did not respond to the first
thread. There are still one or two minor whitespace issues.  If you have
"uncrustify" installed, then ./devel/check-notmuch-commit && git diff
will find the ones I'm thinking of. You can ignore the problems you
didn't introduce.

> The attached patch allows to customize the default ", " and "| "
> separators in author lists. The main rationale for supporting this is
> that the Python API uses the same functionality to get the list of
> authors -- if I want to separate them again afterwards, I have to
> split the returned string, which is error-prone with comma separators
> (e.g. name in email address is of form Lastname, Firstname).

Can you add a brief summary of the motivation to the commit message?

>  test/T030-config.sh |  2 ++
>  test/T055-path-config.sh|  4 
>  test/T590-libconfig.sh  | 10 ++

Thanks for adjusting the existing test suite.

Can you also add a simple test to check the functionality you
introduced? Testing the CLI is fine, or if you prefer something in the
style of test/T590-libconfig.sh
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Editing the raw mail file?

[David Bremner]

Morten Kjeldgaard  writes:
> I would love to have just one function that carries out both tasks,
> opening the file in a temporary buffer, and after you finish with C-c
> C-c, it automatically does the reindexing for you. Unfortunately it's
> above my current Elisp skills to write this.
>

Maybe something like the re-edit draft as new interface (e), although
allowing arbitrary edits is a bit of a footgun, so we'd probably want to
make people confirm "are you sure, this could destroy your message" or
similar. I'm too far behind to do this myself, but I'll (eventually)
look at patches if someone wants to work something up.

d

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Editing the raw mail file?

[Morten Kjeldgaard]

David Bremner  wrote:

> you can use "c F" to copy the file name of the current message into the
> the kill ring, then just yank wherever useful (e.g. to visit the file in
> emacs).
>
> After editing you will need to reindex that file. One way would be
> to use "c i" to copy the message id into the kill ring, then yank it
> into a shell command like
>
>  notmuch reindex id:
>
> If that seems to do what you want, then the steps can be automated
> within emacs.

It works! But as you suggested I made two functions to make it easier, I
enclose them below in case others could benefit. One function opens the
mbox file in an edit buffer, the other runs the reindexing, both need to
be run in the context of the message.

I would love to have just one function that carries out both tasks,
opening the file in a temporary buffer, and after you finish with C-c
C-c, it automatically does the reindexing for you. Unfortunately it's
above my current Elisp skills to write this.

Thanks for your help!
Cheers,
Morten

---8<- snip ---
(defun mok/notmuch-edit-raw-mail ()
  "Within the context of a mail message, open the raw mbox file in a buffer."
  (interactive)
  (let ((mbox-file-name (notmuch-show-get-filename)))
(message "edit %s" mbox-file-name)
(find-file mbox-file-name)))

(defun mok/notmuch-reindex-id ()
  "Within the context of a mail message, reindex the message to update header 
information"
  (interactive)
  (let ((id (notmuch-show-get-message-id)))
(message "reindex %s" id)
(notmuch--call-process notmuch-command nil t nil "reindex" id)))
---8<- snip ---
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Editing the raw mail file?

[David Bremner]

Morten Kjeldgaard  writes:

>
> It's tedious to use the notmuch CLI client to search for the mail and
> then copy/paste the filename, and edit it to correct the date. It would
> be so much easier if it were possible to edit the raw file directly in
> Emacs. I can use 'V' to view the raw file, and then 'E' to be allowed to
> edit it, but Emacs has no idea of what file it is editing.
>
> Is there a way to solve this problem? Notmuch of course already knows
> the original filename.

you can use "c F" to copy the file name of the current message into the
the kill ring, then just yank wherever useful (e.g. to visit the file in
emacs).

After editing you will need to reindex that file. One way would be
to use "c i" to copy the message id into the kill ring, then yank it
into a shell command like

 notmuch reindex id:

If that seems to do what you want, then the steps can be automated
within emacs.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Error when running notmuch new

[David Bremner]

Aidan Jones  writes:


>> 
>> This is the only line that caught my eye.
>> 
>> Can you try
>> 
>> $ notmuch config set maildir.synchronize_flags true
>
> That did it. Thanks for the help!

Glad to hear it. We should try to provide a more informative error
message here.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Error when running notmuch new

[Aidan Jones]

Sent with Proton Mail secure email.

On Thursday, June 27th, 2024 at 10:39 AM, David Bremner  
wrote:

> Aidan Jones arjones...@protonmail.ch writes:
> 
> 
> 
> > maildir.synchronize_flags=sync
> 
> 
> This is the only line that caught my eye.
> 
> Can you try
> 
> $ notmuch config set maildir.synchronize_flags true

That did it. Thanks for the help!
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Error when running notmuch new

[David Bremner]

Aidan Jones  writes:


> maildir.synchronize_flags=sync

This is the only line that caught my eye.

Can you try

$ notmuch config set maildir.synchronize_flags true

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Error when running notmuch new

[Aidan Jones]

Sent with Proton Mail secure email.

On Wednesday, June 26th, 2024 at 3:44 PM, David Bremner  
wrote:

> Aidan Jones arjones...@protonmail.ch writes:
> 
> > I am new to notmuch, so I apologize if this is just an operator
> > error. I have a local maildir created using offlineimap. I have ran
> > notmuch setup and configured notmuch to use the maildir as its
> > archive. However, running notmuch new returns 'notmuch new: Illegal
> > argument for function' Any ideas what I am doing wrong?
> 
> 
> Can you share your configuration? It sounds like it might be a bad
> regex.
> 
> d

I don't see any regex in the output of 'notmuch config list', which is attached 
as a file. The only configuring I've done is through the 'notmuch setup' 
command.

Thanks,
Aidanbuilt_with.compact=true
built_with.field_processor=true
built_with.retry_lock=true
built_with.sexp_queries=false
database.autocommit=8000
database.backup_dir=/home/user/.mail/protonmail/.notmuch/backups
database.hook_dir=/home/user/.mail/protonmail/.notmuch/hooks
database.mail_root=/home/user/.mail/protonmail
database.path=/home/user/.mail/protonmail
index.as_text=
maildir.synchronize_flags=sync
new.ignore=
new.tags=inbox;unread;
search.exclude_tags=ignore
user.name=Aidan Jones
user.primary_email=arjones...@protonmail.ch
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Error when running notmuch new

[David Bremner]

Aidan Jones  writes:

> I am new to notmuch, so I apologize if this is just an operator
> error. I have a local maildir created using offlineimap. I have ran
> notmuch setup and configured notmuch to use the maildir as its
> archive. However, running notmuch new returns 'notmuch new: Illegal
> argument for function' Any ideas what I am doing wrong?

Can you share your configuration? It sounds like it might be a bad
regex.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: desktop file to open mailto URLs in Emacs notmuch-message-mode

[Arun Isaac]

Hi Tomi,

>> Lovely! This is exactly what I am looking for. But, in addition, we also
>> need another desktop file that uses emacsclient instead of emacs. It
>> would be great if notmuch provided that.
>
> That is kinda provided, if u get the ./emacs/notmuch-emacs-mua.desktop
> file and did
>
> @@ -38 +38 @@ NO_WINDOW=
> -USE_EMACSCLIENT=
> +USE_EMACSCLIENT=yes
>
> there ;D

Yes, we're almost there. It would be nice if such a desktop file is
provided (in addition to the notmuch-emacs-mua.desktop that we already
provide) along with notmuch so that users don't have to make that
modification themselves. In other words, provide something like a
notmuch-emacsclient-mua.desktop. That would make for a slightly smoother
user experience.

Thanks,
Arun
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: desktop file to open mailto URLs in Emacs notmuch-message-mode

[Tomi Ollila]

On Tue, Jun 18 2024, Arun Isaac wrote:

> Hi David,
>
>> There is emacs/notmuch-mua-mail.desktop in the source. This seems to do
>> what you ask for?
>
> Lovely! This is exactly what I am looking for. But, in addition, we also
> need another desktop file that uses emacsclient instead of emacs. It
> would be great if notmuch provided that.

That is kinda provided, if u get the ./emacs/notmuch-emacs-mua.desktop
file and did

@@ -38 +38 @@ NO_WINDOW=
-USE_EMACSCLIENT=
+USE_EMACSCLIENT=yes

there ;D

>
> Thanks,
> Arun

Tomi
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Selection bug

[David Bremner]

David Bremner  writes:

>
> This reproduces the problem for me. Indeed it looks a bit like a similar
> "cursor jumping" problem I have seen (and someone else has reported on
> IRC). I will see if I can figure anything more out now that I have a
> reproducer.

I think the following is a (simpler) reproducer of the same problem.

1) Do a search with at least 10 results

2) goto line 10

3) hit 'g'

For me this consistently leaves the point on line 10 but the hl-line bar
on line 1. I have not debugged it yet, but the proximate cause is that
when notmuch-hl-line-mode is called, (point) is 1, so the bar ends up on
the first line. The whys and wherefores I don't know yet.


___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v2 2/2] Replace `delete-line` with its definition

[David Bremner]

michaeljgruber+grubix+...@gmail.com writes:

> From: Michael J Gruber 
>
> 37c022ae ("Use `without-restriction` in 
> `with-temporary-notmuch-message-buffer`", 2024-03-14)
> introduced `delete-line` in a test, but this is Emacs 29 and above only.
> Replace it with its (almost) definition.

both v2 patches applied to master.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v2 2/2] Replace `delete-line` with its definition

[Michael J Gruber]

Am Di., 18. Juni 2024 um 07:58 Uhr schrieb Marc Fargas
:
>
> Hi,
>
> El lun. 17 de jun. 2024, David escribió:
> >
> >> From: Michael J Gruber 
> >>
> >> 37c022ae ("Use `without-restriction` in 
> >> `with-temporary-notmuch-message-buffer`", 2024-03-14)
> >> introduced `delete-line` in a test, but this is Emacs 29 and above only.
> >> Replace it with its (almost) definition.
> >
> > The changes look reasonable to me. But so did the last ones ;P.

:-)

Builds: https://copr.fedorainfracloud.org/coprs/mjg/notmuch-git/build/7621439/
Source: 
https://copr-dist-git.fedorainfracloud.org/cgit/mjg/notmuch-git/notmuch.git/tree/?id=365e56a86826e13bdb6f716993ad33d5d570b7b6

>>  Any
> > feedback Marc?
>
> Ok for me! And sorry for not considering backwards compatibility on my
> patch :(

I just happen to test against old versions because I maintain notmuch
for Fedora and EPEL, i.e. extra packages for RHEL and such, and they
often come with older versions as a stable base platform.

Cheers
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v2 2/2] Replace `delete-line` with its definition

[Marc Fargas]

Hi,

El lun. 17 de jun. 2024, David escribió:
>
>> From: Michael J Gruber 
>>
>> 37c022ae ("Use `without-restriction` in 
>> `with-temporary-notmuch-message-buffer`", 2024-03-14)
>> introduced `delete-line` in a test, but this is Emacs 29 and above only.
>> Replace it with its (almost) definition.
>
> The changes look reasonable to me. But so did the last ones ;P. Any
> feedback Marc?

Ok for me! And sorry for not considering backwards compatibility on my
patch :(

marc
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: desktop file to open mailto URLs in Emacs notmuch-message-mode

[Arun Isaac]

Hi David,

> There is emacs/notmuch-mua-mail.desktop in the source. This seems to do
> what you ask for?

Lovely! This is exactly what I am looking for. But, in addition, we also
need another desktop file that uses emacsclient instead of emacs. It
would be great if notmuch provided that.

Thanks,
Arun
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v2 2/2] Replace `delete-line` with its definition

[David Bremner]

michaeljgruber+grubix+...@gmail.com writes:

> From: Michael J Gruber 
>
> 37c022ae ("Use `without-restriction` in 
> `with-temporary-notmuch-message-buffer`", 2024-03-14)
> introduced `delete-line` in a test, but this is Emacs 29 and above only.
> Replace it with its (almost) definition.

The changes look reasonable to me. But so did the last ones ;P. Any
feedback Marc?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el, needs without-restriction to properly save draft

[David Bremner]

Marc Fargas  writes:

> Hi,
>
> El lun. 17 de jun. 2024, Marc escribió:
>>
>> El lun. 17 de jun. 2024, Michael escribió:
 (...)
>>>
>>> Does this depend on emacs version by any chance, i.e. is
>>> `without-restriction` defined on all emacsen? In Fedora's copr
>>> infrastructure, all builds succeed but some tests fail with
>>> `Symbol'€™s function definition is void: without-restriction`. The
>>> picture is the following:
>
> So, I will have to update the patch in order to make the use of
> `without-restriction` conditional on its availability.
>
> I asked on Emacs chat @ Matrix on how to do this nicely and yantar92
> (org contributor) proposed the following macro:
>
>(defmacro notmuch--without-restriction (&rest body)
>  "Run BODY within `without-restriction', when it is available."
>  (declare (debug (body)))
>  (if (fboundp 'without-restriction)
>  `(without-restriction ,@body)
>`(progn ,@body)))

Assuming fboundp works for macros (without-restriction is a macro), then
sure
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el, needs without-restriction to properly save draft

[Marc Fargas]

Hi,

El lun. 17 de jun. 2024, Marc escribió:
>
> El lun. 17 de jun. 2024, Michael escribió:
>>> (...)
>>
>> Does this depend on emacs version by any chance, i.e. is
>> `without-restriction` defined on all emacsen? In Fedora's copr
>> infrastructure, all builds succeed but some tests fail with
>> `Symbol'€™s function definition is void: without-restriction`. The
>> picture is the following:

So, I will have to update the patch in order to make the use of
`without-restriction` conditional on its availability.

I asked on Emacs chat @ Matrix on how to do this nicely and yantar92
(org contributor) proposed the following macro:

   (defmacro notmuch--without-restriction (&rest body)
 "Run BODY within `without-restriction', when it is available."
 (declare (debug (body)))
 (if (fboundp 'without-restriction)
 `(without-restriction ,@body)
   `(progn ,@body)))

David, would such solution be OK? If so I'll prepare a new patch.

Marc
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el, needs without-restriction to properly save draft

[Marc Fargas]

Hi,

El lun. 17 de jun. 2024, Michael escribió:
>> (...)
>
> Does this depend on emacs version by any chance, i.e. is
> `without-restriction` defined on all emacsen? In Fedora's copr
> infrastructure, all builds succeed but some tests fail with
> `Symbol'€™s function definition is void: without-restriction`. The
> picture is the following:

Apparently it was introduced in Emacs 29[1]. Strange that tests pass at
all on previous versions.

What is the earliest Emacs version supported by notmuch? I can't find
any specific version in notmuch documentation.

The patch could be updated to only use without-restriction when
available, of course.

marc

[1]: 
https://github.com/emacs-mirror/emacs/blob/7be66d8223e49489b2803c0ff027f1824d774441/etc/NEWS.29#L3512
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el, needs without-restriction to properly save draft

[David Bremner]

David Bremner  writes:

> Marc Fargas  writes:
>
>> Hi,
>>
>> El lun. 17 de jun. 2024, Michael escribió:
 (...)
>>>
>>> Does this depend on emacs version by any chance, i.e. is
>>> `without-restriction` defined on all emacsen? In Fedora's copr
>>> infrastructure, all builds succeed but some tests fail with
>>> `Symbol'€™s function definition is void: without-restriction`. The
>>> picture is the following:
>>
>> Apparently it was introduced in Emacs 29[1]. Strange that tests pass at
>> all on previous versions.
>>
>> What is the earliest Emacs version supported by notmuch? I can't find
>> any specific version in notmuch documentation.
>
> According to the docs, it is supposed to work with 25.1. Personally I
> would be fine updating this to 26.x or 27.x, but of course that won't
> help you here.

Using "docs", loosly here. This is the most recent announcement in NEWS,
which matches emacs/notmuch-pkg.el.tmpl
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el, needs without-restriction to properly save draft

[David Bremner]

Marc Fargas  writes:

> Hi,
>
> El lun. 17 de jun. 2024, Michael escribió:
>>> (...)
>>
>> Does this depend on emacs version by any chance, i.e. is
>> `without-restriction` defined on all emacsen? In Fedora's copr
>> infrastructure, all builds succeed but some tests fail with
>> `Symbol'€™s function definition is void: without-restriction`. The
>> picture is the following:
>
> Apparently it was introduced in Emacs 29[1]. Strange that tests pass at
> all on previous versions.
>
> What is the earliest Emacs version supported by notmuch? I can't find
> any specific version in notmuch documentation.

According to the docs, it is supposed to work with 25.1. Personally I
would be fine updating this to 26.x or 27.x, but of course that won't
help you here.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el, needs without-restriction to properly save draft

[Michael J Gruber]

Am Sa., 15. Juni 2024 um 19:57 Uhr schrieb David Bremner :
>
> Marc Fargas  writes:
>
> > Hi again,
> >
> > El dom. 24 de mar. 2024, Marc escribió:
> >> El mié. 13 de mar. 2024, Carl escribió:
> >>> (...)
> >>> Could you put your fix together in the form of a git-appliable patch?
> >>> Such as by applying it to the notmuch source, running `git commit` and
> >>> then `git format-patch HEAD~` or similar.
> >>
> >> Please disregard the previous patch, consider the one attached
> >> here. Hope I did the "format-patch" thing properly.
> >>
> >> I had to move the `without-restriction` call to the top of the
> >> `with-temporary-notmuch-message-buffer` defmacro. It does work properly
> >> now.
>
> Applied to master. Sorry for the long-ish silence.
>

Does this depend on emacs version by any chance, i.e. is
`without-restriction` defined on all emacsen? In Fedora's copr
infrastructure, all builds succeed but some tests fail with
`Symbol'€™s function definition is void: without-restriction`. The
picture is the following:

PASS:
centos-stream+epel-next-8 with emacs 26.1-11.el8
rhel+epel-8 with emacs 26.1-11.el8
fedora-39 with emacs 29.3-1.fc39
(plus all newer fedoras)

FAIL:
centos-stream+epel-next-9 with emacs 27.2-9.el9
rhel+epel-9 with emacs 27.2-9.el9

Yes, RHEL 8 is EOled.

I find it strange that tests pass on both emacs 26 and 29 but not
27.2. But said code path is not executed on emacs 26 at all?

The failing 42 tests are mostly around json and crypto, but not all.

Cheers
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el, needs without-restriction to properly save draft

[David Bremner]

Marc Fargas  writes:

> Hi again,
>
> El dom. 24 de mar. 2024, Marc escribió:
>> El mié. 13 de mar. 2024, Carl escribió:
>>> (...)
>>> Could you put your fix together in the form of a git-appliable patch?
>>> Such as by applying it to the notmuch source, running `git commit` and
>>> then `git format-patch HEAD~` or similar.
>>
>> Please disregard the previous patch, consider the one attached
>> here. Hope I did the "format-patch" thing properly.
>>
>> I had to move the `without-restriction` call to the top of the
>> `with-temporary-notmuch-message-buffer` defmacro. It does work properly
>> now.

Applied to master. Sorry for the long-ish silence.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] test/cli: Add known broken test for (missing) quoting in From

[David Bremner]

David Bremner  writes:

> In [1], Jakub Wilk observes that the current behaviour is confusing
> since it looks like there are two mailboxes in From, while in fact
> there is only one.  It seems to me that notmuch should at least quote
> the display-name part of a mailbox if it has "funny" characters in it,
> and perhaps always quote it. Either way will require changing the
> indexing code, since the structure is lost when writing the headers to
> the database.
>

applied to master.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Emacs: text/calendar rendering fix

[David Bremner]

David Bremner  writes:

> The actual fix here is quite trivial, but it takes some work to test.
> Compared to the previous version in the thread at [1], this updates
> the 3rd patch in the series to actually duplicate the problem, and
> adds the 4th patch with the actual fix.
>
> [1]: id:m2wmneguh8@gmail.com

Thread applied to master.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: desktop file to open mailto URLs in Emacs notmuch-message-mode

[David Bremner]

Arun Isaac  writes:

> This is a feature request.
>
> Emacs comes with emacs-mail.desktop and emacsclient-mail.desktop files
> that allows opening mailto URLs in message-mode. Can we provide similar
> desktop files for notmuch-emacs so that one can open mailto URLs in
> notmuch-message-mode?

There is emacs/notmuch-mua-mail.desktop in the source. This seems to do
what you ask for?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: How to disable image and PDF preview in emacs notmuch-show buffer?

[David Bremner]

Viktor Larkin  writes:

> Hello, David. Seems like I've got it wrong. Could you please provide an
> example of how I should change mm-inline-override-types? I've tried this
> way
>
> (setq mm-inline-override-types '("image/.*"))
>
> It didn't work as I expect it to. I still see images in notmuch-show
> buffer as images, not as attachments.

I used M-x customize variable and your example worked fine for me. I
guess you will either need to use customize or find the right
incantation (setq-default maybe, but I did not test it).

Hope this helps

d

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: How to disable image and PDF preview in emacs notmuch-show buffer?

[Viktor Larkin]

Hello, David. Seems like I've got it wrong. Could you please provide an
example of how I should change mm-inline-override-types? I've tried this
way

(setq mm-inline-override-types '("image/.*"))

It didn't work as I expect it to. I still see images in notmuch-show
buffer as images, not as attachments.

Cheers.

David Bremner  writes:

> curiousbarbar...@posteo.net writes:
>
>> Hello.
>>
>> Is it possible to disable preview of images and PDF files in 
>> notmuch-show buffer in emacs? I've tried to set gnus-inhibit-image to t, 
>> but it looks like it doesn't affect previewing. Any possible built-in 
>> solutions?
>>
>> Emacs 29.2
>> notmuch 0.37
>
> Try customizing mm-inline-override-types. Note that notmuch normally
> adds "application/.*" to this, but won't if you customize it, so you may
> want to add in to your list.
>
> d

-- 
С уважением,
В. А. Ларкин
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] emacs: Autoload notmuch-user-agent related functions

[David Bremner]

Jelle Licht  writes:

> Thanks for applying the patch, but I just noticed I made a mistake; each
> of the lines now have a ";;;#autoload" comment, instead of the proper
> ";;;###autoload" cookie. My apologies. Should I send a patch fixing
> this, or will you push a fix yourself?

Please send a patch, thanks

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] emacs: Autoload notmuch-user-agent related functions

[Jelle Licht]

Hi David,

David Bremner  writes:

> jli...@fsfe.org writes:
>
>>  
>>  ;;; _
>> -
>> +;;;#autoload
>>  (define-mail-user-agent 'notmuch-user-agent
>>'notmuch-mua-mail
>>'notmuch-mua-send-and-exit
>
> Applied to master with the deleted blank line put back

Thanks for applying the patch, but I just noticed I made a mistake; each
of the lines now have a ";;;#autoload" comment, instead of the proper
";;;###autoload" cookie. My apologies. Should I send a patch fixing
this, or will you push a fix yourself?

Kind regards,
Jelle Licht
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: How to disable image and PDF preview in emacs notmuch-show buffer?

[David Bremner]

curiousbarbar...@posteo.net writes:

> Hello.
>
> Is it possible to disable preview of images and PDF files in 
> notmuch-show buffer in emacs? I've tried to set gnus-inhibit-image to t, 
> but it looks like it doesn't affect previewing. Any possible built-in 
> solutions?
>
> Emacs 29.2
> notmuch 0.37

Try customizing mm-inline-override-types. Note that notmuch normally
adds "application/.*" to this, but won't if you customize it, so you may
want to add in to your list.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Selection bug

[David Bremner]

Justus Winter  writes:

> David Bremner  writes:
>
> 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

This reproduces the problem for me. Indeed it looks a bit like a similar
"cursor jumping" problem I have seen (and someone else has reported on
IRC). I will see if I can figure anything more out now that I have a
reproducer.

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH] emacs: Allow customizing :excluded in notmuch-saved-searches

[David Bremner]

mohk...@kisara.moe writes:

> From: Mohsin Kaleem 
>

applied to master, with a slightly expanded commit message.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 1/4] test: re-enable duplicate UI tests in T460-emacs-tree

[David Bremner]

David Bremner  writes:

> These were disabled (accidentally?) in f63d14a8c12a.
> ---
>  test/T460-emacs-tree.sh | 2 --
>  1 file changed, 2 deletions(-)

applied to master.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 3/3] WIP/test: add tests for rendering text/calendar parts

[Al Haji-Ali]

Ah, apologies. I should've done more testing.

Turns out I have `find-file-visit-truename` set to non-nil which causes the 
behaviour I describe.

Best regards,
-- Al

On 28/05/2024, David Bremner wrote:
> Al Haji-Ali  writes:
>
>>
>> On my setup (MacOS, Emacs 29.1) this prints something like
>>
>> ,
>> | Filename: /Users/al/link-tmp/notmuch-ical7MtHvd
>> | get-file-buffer: nil
>> | find-buffer-visiting: #
>> | buffer-file-name: /private/tmp/notmuch-ical7MtHvd
>> `
>
> Here it prints
>
> Filename: /home/bremner/link-tmp/notmuch-icalDC01xk
> get-file-buffer: #
> find-buffer-visiting: #
> buffer-file-name: /home/bremner/link-tmp/notmuch-icalDC01xk
>
> So I guess this is some system dependent (or emacs dependent; I have
> 29.3 here) behaviour. I can convert the test to a regression test after
> the change is applied. It's not as nice, but it's better than not
> testing it at all.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 3/3] WIP/test: add tests for rendering text/calendar parts

[David Bremner]

Al Haji-Ali  writes:

>
> On my setup (MacOS, Emacs 29.1) this prints something like
>
> ,
> | Filename: /Users/al/link-tmp/notmuch-ical7MtHvd
> | get-file-buffer: nil
> | find-buffer-visiting: #
> | buffer-file-name: /private/tmp/notmuch-ical7MtHvd
> `

Here it prints

Filename: /home/bremner/link-tmp/notmuch-icalDC01xk
get-file-buffer: #
find-buffer-visiting: #
buffer-file-name: /home/bremner/link-tmp/notmuch-icalDC01xk

So I guess this is some system dependent (or emacs dependent; I have
29.3 here) behaviour. I can convert the test to a regression test after
the change is applied. It's not as nice, but it's better than not
testing it at all.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH 3/3] WIP/test: add tests for rendering text/calendar parts

[Al Haji-Ali]

Yes, that is strange. Based on just looking at the test code, I think this test 
should indeed fail (I am not able to run in on my machine). In a similar 
situation, my inline calendar text shows

,
| !!! Bodypart handler `notmuch-show-insert-part-text/calendar' threw an error:
| !!! Wrong type argument: stringp, nil
| !!! Bodypart handler `notmuch-show-insert-part-*/*' threw an error:
| !!! Wrong type argument: char-or-string-p, gnus-decoded
`

To see the basic issue, check what this code outputs on your setup:
,
| (let ((tmp-link  "~/link-tmp"))
|   (make-symbolic-link "/tmp/" tmp-link)
|   (let* ((temporary-file-directory tmp-link)
|  (file (make-temp-file "notmuch-ical")))
| (find-file-noselect file)
| (message
|  "Filename: %s
| get-file-buffer: %S
| find-buffer-visiting: %S
| buffer-file-name: %s"
|  file
|  (get-file-buffer file)
|  (find-buffer-visiting file)
|  (buffer-file-name (find-buffer-visiting file)))
| (kill-buffer (find-buffer-visiting file))
| (delete-file tmp-link)
| (delete-file file)))
| 
`

On my setup (MacOS, Emacs 29.1) this prints something like

,
| Filename: /Users/al/link-tmp/notmuch-ical7MtHvd
| get-file-buffer: nil
| find-buffer-visiting: #
| buffer-file-name: /private/tmp/notmuch-ical7MtHvd
`

So `get-file-buffer` returns nil. Reason is that the buffer-file-name has the 
resolved path (without symlinks). The documentation for `get-file-buffer` says: 
"The buffer's buffer-file-name must match exactly the expansion of FILENAME". 
`find-buffer-visiting` gets the truename of the filename before looking for its 
buffer.

The function `notmuch-show-insert-part-text/calendar` essentially does the same 
as my code above. Note also that `find-buffer-visiting` is used instead of 
`get-file-buffer` in `icalendar-import-buffer` for example. 

-- Al

On 26/05/2024, David Bremner wrote:

> The second test should apparently fail, but it doesn't.
> ---
>  test/T450-emacs-show.sh | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh
> index 438a7b9b..85851e70 100755
> --- a/test/T450-emacs-show.sh
> +++ b/test/T450-emacs-show.sh
> @@ -340,6 +340,32 @@ This meeting will could have been an email
>  EOF
>  test_expect_equal_file EXPECTED OUTPUT
>  
> +test_begin_subtest "display of text/calendar, symlinked tmpdir"
> +test_subtest_known_broken
> +mkdir real-tmp
> +ln -s real-tmp tmp
> +test_emacs "(let ((notmuch-show-all-multipart/alternative-parts t)
> +(temporary-file-directory \"tmp\"))
> +(notmuch-show 
> \"id:yt3pr01mb10572efc9f7c81f9446214768ce...@yt3pr01mb10572.canprd01.prod.outlook.com\"))
> + (test-visible-output \"OUTPUT\")"
> +cat < EXPECTED
> +David Bremner  (1970-01-01) (inbox)
> +Subject: test
> +To: "da...@tethera.net" 
> +Date: Thu, 01 Jan 1970 00:00:00 +
> +
> +[ multipart/alternative ]
> +[ text/plain ]
> +This meeting will could have been an email
> +[ text/calendar ]
> +%%(and (diary-cyclic 1 5 27 2024) (diary-block 5 27 2024 8 27 2024)) 
> 17:00-17:30 test [In-person]
> + Desc: This meeting will could have been an email
> +
> +
> + Organizer: mailto:brem...@example.com
> +EOF
> +test_expect_equal_file EXPECTED OUTPUT
> +
>  test_begin_subtest "tar not inlined by default"
>  test_emacs '(notmuch-show "id:874llc2bkp@curie.anarc.at")
>   (test-visible-output "OUTPUT")'
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Meaning of offset in notmuch search --output=files --offset=

[Teemu Likonen]

* 2024-05-27 09:05:01-0400, Daniel Kahn Gillmor wrote:

> I don't see much difference between any of these versions,

Then it needs more work still. We want to make it clear for everybody,
don't we? Let's go back to my original confusion. Currently it reads:

--offset=[-]N
Skip displaying the first N results. With the leading '-',
start at the Nth result from the end.

What "results"? The search match or the output? Two interpretations:

 1. "Notmuch search" results an internal message list. "--offset=N" will
skip N messages in the internal message list and then starts
printing the rest of the messages in the "--output" format. [This is
what Notmuch really does.]

 2. "Notmuch search" results an internal message list and it starts
printing them in "--output" format. It will use "--offset=N" to skip
N output items, regardless of what they are: summary, threads,
messages, files, tags. [This is the wrong interpretation.]

So, how do we improve the notmuch-search manual so that everybody
understands "--offset=N" correctly?

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Meaning of offset in notmuch search --output=files --offset=

[Daniel Kahn Gillmor]

On Sun 2024-05-26 10:57:14 +0300, Teemu Likonen wrote:
> * 2024-05-25 13:20:58+0200, Michael J. Gruber wrote:
>
>>> Teemu Likonen  writes:
 --offset=[-]N
 Skip displaying the first N results. With the leading '-',
 start at the Nth result from the end.

 What if we change the first sentence to "Skip displaying the first N
 search results"?
>
>> Maybe even "Skip displaying output for the first N search results", in
>> an effort to hint at said difference?
>
> Yours is better than the current and mine. Thanks.

I don't see much difference between any of these versions, but i also
don't think any of them make the text concretely worse.  So if more
people understand what is meant by the version suggested by Michael J
Gruber, i'd be fine with going with that version.

  --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Xapian commits unexpectedly slow

[Matthew Schauer]

On Sun, May 26, 2024 at 09:12:57AM -0300, David Bremner wrote:
> Apologies, it looks like I never replied to this thread. Probably you
> are not longer interested, but I can make a few observations, mainly
> that there are a few relevant improvements in later notmuch.

Wow!  What reminded you of this after all this time?

A lot certainly has changed since then.  I don't remember whether my
problem was ever resolved on that machine, but a few months later I
moved to a new laptop with an SSD, and I've now been a happy Notmuch
user for several years.  I think we can move on from this.

Thanks for continuing to work on improving this great tool!

--
Matthew Schauer
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: emacs warnings related to notmuch

[David Bremner]

Daniel Kahn Gillmor  writes:

> Hey notmuch folks--
>
> when i launch emacs these days i see the following in my *Warnings*
> buffer:
>
> Warning (comp): notmuch-hello.el:719:22: Warning: docstring wider than 80 
> characters Disable showing Disable logging
> Warning (comp): notmuch-hello.el:855:8: Warning: docstring wider than 80 
> characters Disable showing Disable logging
> Warning (comp): notmuch-hello.el:489:15: Warning: the function 
> ‘notmuch-search-format-buffer-name’ is not known to be defined. Disable 
> showing Disable logging
> Warning (comp): notmuch-show.el:2479:8: Warning: docstring wider than 80 
> characters Disable showing Disable logging

These should be fixed in the next (major) release of notmuch, i.e. 0.39
and not 0.38.4 (if the latter happens).

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch.el question: reading all messages in thread

[David Bremner]

Matt Armstrong  writes:

> Sometimes a notmuch query matches only a subset of messages in a thread.
> When this happens only that subset of messages will be "open".  Many
> notmuch commands operate on the "open" messages only.  For example: SPC,
> 'n', 'p'.
>
> Often this is what I want.  It works well when I'm looking for a
> specific piece of information, or when I am interested in reading only
> the unread messages in a long thread that I have seen previously.
>
> Often this is not what I want.  I'm interested in seeing all messages
> when I am looking for entire conversations where a topic is being
> discussed.  E.g. when I want to re-read a long forgotten thread, or one
> that surfaced through specific search terms that appear only in a few of
> the messages in the thread.

In notmuch-show mode, M- opens all messages. 

> I looked for a way to easily re-query a tree view buffer such that all
> messages in all threads shown are "open" but did not find it.  Does this
> exist?

Not exactly an answer, but maybe this helps someone:

In tree-mode I would suggest using "N" and "P" to ignore the open/closed
status of a message. Or just move using the arrow keys / mouse and hit
return on the message you want to read.

If you really rarely want to the "*-matching-message" versions, then you
could swap the bindings
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Xapian commits unexpectedly slow

[David Bremner]

Matthew Schauer  writes:

>
> Nifty!  Here are the results -- I assume you know how to interpret them
> better than I do:
>
> T00-new.sh: Testing notmuch new [0.4 large]
> Wall(s) Usr(s)  Sys(s)  Res(K)  In/Out(512B)
>   Initial notmuch new   1163.05 854.26  45.97   444304  2343120/13645200
>   notmuch new #22.230.020.0393842144/8
>   notmuch new #30.010.010.0094600/8
>   notmuch new #40.010.010.0094280/8
>   notmuch new #50.010.000.0094680/8
>   notmuch new #60.010.010.0096920/8
>   new (52374 mv)1351.01 537.75  235.45  959524  1027288/8531616
>   new (52374 mv back)   834.15  489.27  213.97  967040  184/4754016
>   new (52374 cp)747.23  284.03  105.51  941992  0/4007120
>

Apologies, it looks like I never replied to this thread. Probably you
are not longer interested, but I can make a few observations, mainly
that there are a few relevant improvements in later notmuch.

1) This is about 3x slower than my current benchmark machine [1]. My
current machine is probably 4 years newer, so I would expect some
improvement in performance. 

2) I don't know if this is typical for spinning rust, but about about
25% of the time is (apparently) IO wait, since it it does not show up in
CPU time.  I do have access to a machine with both SSD and spinning
rust, but the latter is in some complicated RAID formation, so I don't
know how representative the results would be.

3) Some time after you reported these issues I implemented an
"autocommit" parameter, which should should help avoid large Xapian
large commits.

4) Your results show that notmuch new could be extra slow when dealing
with moving files on disk. This should be somewhat improved by changes
in notmuch 0.32 (I also see fairly dramatic impovements in
notmuch-reindex relative to notmuch new, but the underlying cause is
less clear).

[1] e.g. https://notmuchmail.org/perf-test-results/2024-05-26-minkowski/
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Multiple files per message in emacs

[David Bremner]

Rafael Ávila de Espíndola  writes:

> Rafael Ávila de Espíndola  writes:
>
>>> If you can build from source, there is new support for viewing
>>> duplicates in master.
>>
>
> Just tested with 0.37 and it works. One thing that still seems to be
> missing is handling different tags. For example, there is no way to mark
> a new duplicated message as read.

Catching up on old messages in the mailing list, I'm not sure I
understand the desired behaviour. In principle if you get a second copy
of the same message, it should inherit the read/unread status of the
other copies (since tags are associated with message-ids). There are
some known limitations/bugs with that, but they are not emacs related
afaik.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Meaning of offset in notmuch search --output=files --offset=

[Teemu Likonen]

* 2024-05-25 13:20:58+0200, Michael J. Gruber wrote:

>> Teemu Likonen  writes:
>>> --offset=[-]N
>>> Skip displaying the first N results. With the leading '-',
>>> start at the Nth result from the end.
>>>
>>> What if we change the first sentence to "Skip displaying the first N
>>> search results"?

> Maybe even "Skip displaying output for the first N search results", in
> an effort to hint at said difference?

Yours is better than the current and mine. Thanks.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Meaning of offset in notmuch search --output=files --offset=

[Michael J Gruber]

Am Sa., 25. Mai 2024 um 12:06 Uhr schrieb David Bremner :
>
> Teemu Likonen  writes:
>
> >
> >> Perhaps the manual page needs a few more words to make it clear.
> >
> > --offset=[-]N
> > Skip displaying the first N results. With the leading '-',
> > start at the Nth result from the end.
> >
> > What if we change the first sentence to "Skip displaying the first N
> > search results"?
>
> For me personally that doesn't make it that much clearer, but I'm
> willing to follow a concensus if there is one.

... because it was clear to you before, already ;-)

Once you are aware of the conceptual difference between "search" and
"output", the change makes it clearer.

Maybe even "Skip displaying output for the first N search results", in
an effort to hint at said difference?

Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Meaning of offset in notmuch search --output=files --offset=

[David Bremner]

Teemu Likonen  writes:

>
>> Perhaps the manual page needs a few more words to make it clear.
>
> --offset=[-]N
> Skip displaying the first N results. With the leading '-',
> start at the Nth result from the end.
>
> What if we change the first sentence to "Skip displaying the first N
> search results"?

For me personally that doesn't make it that much clearer, but I'm
willing to follow a concensus if there is one.

d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Meaning of offset in notmuch search --output=files --offset=

[Teemu Likonen]

* 2024-05-20 21:24:01+0300, Teemu Likonen wrote:

> It doesn't seem clear how offset is counted on command like
>
> notmuch search --output=files --offset=10 ...
>
> Does it skip 10 output files (which may belong to less than 10 messages)
> or does it skip 10 messages (so it possibly skips more than 10 files)?
> Manual page speaks of "results" but I think it can be interpreted either
> as "displayed output results" or "search match results (messages)".

I tested and the answer is: --offset option skips that many search match
messages. So it looks to me that command

notmuch search --output=files --offset=10 ...

internally lists all matched messages, skips to the offset, and then
starts printing the file names of the rest of the message list.

> Perhaps the manual page needs a few more words to make it clear.

--offset=[-]N
Skip displaying the first N results. With the leading '-',
start at the Nth result from the end.

What if we change the first sentence to "Skip displaying the first N
search results"?

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch-search not excluding excluded tags

[richardhstanton]

I added the following definitions to my init.el file, which seems to solve the 
problem:

(defun org-notmuch-search-open (path _)
  "Follow a notmuch search link specified by PATH."
  (notmuch-search path notmuch-search-oldest-first 
notmuch-search-hide-excluded))


(defun notmuch-search-default(path)
  "Add default options to notmuch-search"
  (notmuch-search path notmuch-search-oldest-first 
notmuch-search-hide-excluded))


> On May 21, 2024, at 6:32 AM, David Bremner  wrote:
> 
> erik colson  writes:
> 
>> 
>> Thanks for the hint, but tried setting the var with setq-default, but
>> still same issue.. :
>> 
>>  notmuch-search-hide-excluded is a variable defined in ‘notmuch-lib.el’.
>> 
>>  Its value is nil
>>  Original value was t
>>  Local in buffer *notmuch-saved-tree-1week and unread*; global value is t
>> 
>>  Hide mail tagged with a excluded tag.
>> 
> 
> Hmm. I can't duplicate that here. Can you try with a minimal
> configuration? If you have the source you can run "./devel/try-emacs-mua
> -q" to run without any personal configuration.
> 
> Another thing to try is to hit "i" in a search view and see if it
> toggles properly.
> 
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch-search not excluding excluded tags

[David Bremner]

erik colson  writes:

>
> Thanks for the hint, but tried setting the var with setq-default, but
> still same issue.. :
>
>   notmuch-search-hide-excluded is a variable defined in ‘notmuch-lib.el’.
>   
>   Its value is nil
>   Original value was t
>   Local in buffer *notmuch-saved-tree-1week and unread*; global value is t
>   
>   Hide mail tagged with a excluded tag.
>

Hmm. I can't duplicate that here. Can you try with a minimal
configuration? If you have the source you can run "./devel/try-emacs-mua
-q" to run without any personal configuration.

Another thing to try is to hit "i" in a search view and see if it
toggles properly.

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch-search not excluding excluded tags

[erik colson]

David Bremner  writes:

> It might matter how you are setting notmuch-search-hide-excluded. It
> is buffer-local (that changed recently, I think) so you need to either
> use customize or setq-default.

Hi,

Thanks for the hint, but tried setting the var with setq-default, but
still same issue.. :

  notmuch-search-hide-excluded is a variable defined in ‘notmuch-lib.el’.
  
  Its value is nil
  Original value was t
  Local in buffer *notmuch-saved-tree-1week and unread*; global value is t
  
  Hide mail tagged with a excluded tag.

-- 
erik colson - T:0475.83.75.66
BEAVER NV/SA - BE0417.279.944
Woluwelaan 8 - 1831 Diegem
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch-search not excluding excluded tags

[David Bremner]

erik colson  writes:
> Hi,
>
> I recently upgraded from an older version in which excluded tags in the
> notmuch config were nicely hidden.  Now I have exactly the same problem
> as Stanton described.  I can see notmuch-search-hide-excluded is set
> globally to t, but in every search buffer it seems to be set to nil.  I
> can't figure what code I should change for thi to work as before..

It might matter how you are setting notmuch-search-hide-excluded. It
is buffer-local (that changed recently, I think) so you need to either
use customize or setq-default.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch-search not excluding excluded tags

[erik colson]

David Bremner  writes:

> Richard Stanton  writes:
>
>> I have spam and trash defined as excluded tags for notmuch searches and when 
>> I run (at the command line) the command
>>
>> notmuch search tag:unread
>>
>> I get a list of unread messages that does *not* include unread spam or trash 
>> emails. But when I put the following into my *scratch* buffer and execute it:
>>
>> (notmuch-search “tag:unread”)
>>
>> I now get ALL unread messages, including those tagged as spam or trash. Am I 
>> missing something?

Hi,

I recently upgraded from an older version in which excluded tags in the
notmuch config were nicely hidden.  Now I have exactly the same problem
as Stanton described.  I can see notmuch-search-hide-excluded is set
globally to t, but in every search buffer it seems to be set to nil.  I
can't figure what code I should change for thi to work as before..

thx
-- 
erik colson - T:0475.83.75.66
BEAVER NV/SA - BE0417.279.944
Woluwelaan 8 - 1831 Diegem
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH 1/4] test: re-enable duplicate UI tests in T460-emacs-tree

[David Bremner]

These were disabled (accidentally?) in f63d14a8c12a.
---
 test/T460-emacs-tree.sh | 2 --
 1 file changed, 2 deletions(-)

diff --git a/test/T460-emacs-tree.sh b/test/T460-emacs-tree.sh
index 6ef5c54a..9388a8ed 100755
--- a/test/T460-emacs-tree.sh
+++ b/test/T460-emacs-tree.sh
@@ -222,8 +222,6 @@ test_emacs '(let ((notmuch-tree-outline-enabled t))
 # folding all messages by height or depth should look the same
 test_expect_equal_file $EXPECTED/notmuch-tree-tag-inbox OUTPUT
 
-test_done
-
 add_email_corpus duplicate
 
 ID3=87r2ecrr6x@zephyr.silentflame.com
-- 
2.43.0

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Carriage returns in subject line cause problems in unthreaded and tree mode

[Tomi Ollila]

On Thu, May 16 2024, Richard Stanton wrote:

> Today I received an email with (raw) subject line
>
> Subject: =?UTF-8?B?8J+Pi++4jw==?= A SALE to boost your
>  =?UTF-8?Q?workout=0D=0A?=
>
> When displayed in Emacs in either unthreaded or tree mode, “^M” appears after 
> the word “workout”, and the displayed line is split into two, like this:
>
>  Today 07:12  Jabra🏋️ A SALE to boost your workout^M
>(important inbox)
>
> It would probably be a good idea to check for, and remove, carriage return 
> characters in the subject line.

It depends how common it is to see those (ugly?) ^M characters there?

... and is it so that the Newline(=0A) splits the line in two.

-- and is the behavior different in some other modes (I (mostly) just use 
notmuch-search and notmuch-show modes so cannot recall how other views
look like...

The problem would be worse if carriage return (=0D) moved the cursor
to the beginning of line and following text ovewrote what were there.

Tomi

> (Note that the message displays fine in the default threaded mode.)
>
> Richard Stanton
>
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: I don't understand the results of this search query, is this a bug?

[Renaud B.]

Hello,

Thanks a lot for your answers, I'm happy to have received such thoughtful
replies. Like you both pointed out, and from what I get, Notmuch works with
message-ids, and since it may happen that several files in different
folders have the same message-id, it explains what I was seeing.

My goal was to try to sync somehow how emails on my computer are organized
using Notmuch and its tags with folders on the IMAP servers of the many
email accounts I'm syncing to my ~/mail dir, using mbsync. I guess this is
a common endeavour some people want, so for example if you browse one of
your email account using a webmail interface, or an app on your phone, then
there is some continuity between how your emails are sorted on your
computer and how you find them on other interfaces. But I also see that
this isn't that simple to implement. Being centered on message-ids, Notmuch
doesn't seem to easily be able to recognize on which email account an email
is (like in cases where one of my email account send an email to another of
my account, or when some of my accounts receive the same email from
somewhere else... basically, when there are duplicates). I also found out
that moving email files might disrupt mbsync, so it is another issue I
would need to look at.

I also understand the important differences between organizing emails using
tags, and using folders. I just wanted to see if, with some shell
scripting, I could arrange something somewhat similar. But it seems harder
to do than I hoped.

I am still new to Notmuch, I use it on Emacs, maybe my efforts weren't
necessary, and so I will keep using it and see how my needs and preferences
go.

Thanks again for your replies, much appreciated!
Renaud


Le mar. 14 mai 2024, à 04 h 19, Michael J Gruber <
michaeljgruber+grubix+...@gmail.com> a écrit :

> Am Mo., 13. Mai 2024 um 23:38 Uhr schrieb Carl Worth :
> >
> > Hi Renaud,
> >
> > I was able to see similar behavior in my own mail store. And I agree
> > that this behavior is confusing!
> >
> > The documentation for the --files option of notmuch search documents the
> > cause (and predicts that this will be confusing):
> >
> 
> > In general, I'm not a fan of software documenting "this may be
> > confusing". That suggests the authors of the documentation know that the
>
> :-)
>
> > software is not behaving as the user intends, so it would be preferable
> > for the software to behave as intended. That said, I also understand the
> > implementation details that lead to this behavior. So I wouldn't be
> > opposed to improving the behavior of notmuch to reduce this behavior,
> > (but that implementation might not be trivial or even fully feasible).
>
> I wouldn't call it an implementation detail in this case, though,
> rather than the guiding principle of notmuch: it is all about
> *messages* as identified by a mid.
>
> Consequently, notmuch stores information by message, searches by
> message and outputs information by message. This in turn has
> consequences, for better or worse, e.g. when different mail files with
> the same mid have different (maildir) flags. But without grasping the
> main guiding principle you'll get confused sooner or later.
>
> As soon as you introduce "do what I mean" into the CLI design the
> outcome depends on the "I" implementing it, who may "mean" very
> different things compared to the "I" using the CLI. This creates
> confusion which cannot be resolved by pointing out a guiding
> principle, but rather "when we do x it is often convenient to imply y
> and that's why do z". You can witness that to some extent in git's
> CLI.
>
> Also, dwim'ing in the case at hand seems difficult - you'd have to
> extract "path:" tokens from a possibly complex query, track logical
> operators applying to them and filter the output accordingly. Compare
> that to "find -type f dirWhichIWant" which would have solved OP's use
> case ...
>
> Cheers
> Michael
>
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: I don't understand the results of this search query, is this a bug?

[Michael J Gruber]

Am Mo., 13. Mai 2024 um 23:38 Uhr schrieb Carl Worth :
>
> Hi Renaud,
>
> I was able to see similar behavior in my own mail store. And I agree
> that this behavior is confusing!
>
> The documentation for the --files option of notmuch search documents the
> cause (and predicts that this will be confusing):
>

> In general, I'm not a fan of software documenting "this may be
> confusing". That suggests the authors of the documentation know that the

:-)

> software is not behaving as the user intends, so it would be preferable
> for the software to behave as intended. That said, I also understand the
> implementation details that lead to this behavior. So I wouldn't be
> opposed to improving the behavior of notmuch to reduce this behavior,
> (but that implementation might not be trivial or even fully feasible).

I wouldn't call it an implementation detail in this case, though,
rather than the guiding principle of notmuch: it is all about
*messages* as identified by a mid.

Consequently, notmuch stores information by message, searches by
message and outputs information by message. This in turn has
consequences, for better or worse, e.g. when different mail files with
the same mid have different (maildir) flags. But without grasping the
main guiding principle you'll get confused sooner or later.

As soon as you introduce "do what I mean" into the CLI design the
outcome depends on the "I" implementing it, who may "mean" very
different things compared to the "I" using the CLI. This creates
confusion which cannot be resolved by pointing out a guiding
principle, but rather "when we do x it is often convenient to imply y
and that's why do z". You can witness that to some extent in git's
CLI.

Also, dwim'ing in the case at hand seems difficult - you'd have to
extract "path:" tokens from a possibly complex query, track logical
operators applying to them and filter the output accordingly. Compare
that to "find -type f dirWhichIWant" which would have solved OP's use
case ...

Cheers
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org