Kevin Boulain writes:
> So, is Notmuch expected to be thread safe? There are some indications it
> should be (e.g.: lib/init.cc has locking) but all instances of
> Xapian::Query::MatchAll would have to be replaced.
> Xapian states it's thread safe:
>
David Bremner writes:
> This one use a more reasonable error code. As far as showing up every
> time, it does if I use --full-scan. That is the same (for me) as
> non-email files.
series applied to master.
d
___
notmuch mailing list --
"Jose A. Ortega Ruiz" writes:
> On Mon, Dec 26 2022, David Bremner wrote:
>
>> Amended by db: Copy docstring to manual and edit for presentation. Add
>> two tests.
>
> Thanks for the grunt work, David. Just a comment on a sloppy comment of
> mine below:
>
>> --- a/emacs/notmuch-tree.el
>> +++
Jon Fineman writes:
> When I try and open one specific email, I get a message of
> "Fontifying..." and then the mouse pointer turns into a watch.
>
> If I C-G it breaks out and shows the email message with a red warning
> at the top of "[some mark read tag changes may have failed]", but
> since
David Bremner writes:
> Michael J Gruber writes:
>
>>
>> Yes, the extra ones all are ghosts, and I slowly remember that they
>> scared me in the past already ...
>>
>> These ghosts appear to be pretty common. It happens all the time that
>> I am joined to an existing discussion thread where I
Michael J Gruber writes:
>
> Yes, the extra ones all are ghosts, and I slowly remember that they
> scared me in the past already ...
>
> These ghosts appear to be pretty common. It happens all the time that
> I am joined to an existing discussion thread where I do not have all
> references.
I
Am Di., 14. Feb. 2023 um 02:47 Uhr schrieb David Bremner :
>
> Michael J Gruber writes:
>
> > That is really weird:
> > ```
> > xapian-delve -t G00021229 .
> > Posting List for term 'G00021229' (termfreq 115, collfreq 0,
> > wdf_max 0): 146259 ...
> > ```
> > with 115 record
Michael J Gruber writes:
> That is really weird:
> ```
> xapian-delve -t G00021229 .
> Posting List for term 'G00021229' (termfreq 115, collfreq 0,
> wdf_max 0): 146259 ...
> ```
> with 115 record numbers, all different.
> Doing `xapian-delve -1r` for each of them and grepping
Am Mo., 13. Feb. 2023 um 21:23 Uhr schrieb David Bremner :
>
> Michael J Gruber writes:
> >
> > It has 5, as confirmed by the search output and that of `notmuch
> > count`. But it is matched by `count 115`.
> > `xapian-check` is happy. (There used to be some issue with additional
> > thread
Michael J Gruber writes:
>
> It has 5, as confirmed by the search output and that of `notmuch
> count`. But it is matched by `count 115`.
> `xapian-check` is happy. (There used to be some issue with additional
> thread entries at some point.)
>
> Michael
A simple test to try is
% xapian-delve
Am Mo., 13. Feb. 2023 um 17:32 Uhr schrieb David Bremner :
>
> Michael J Gruber writes:
>
> > I am getting a few surprising matches, e.g.
> > ```
> > notmuch search --query=sexp '(thread (count 115)))'
> > thread:00021229 2021-05-17 [5/5] Michael J Gruber ... redacted
> > notmuch count
Michael J Gruber writes:
> I am getting a few surprising matches, e.g.
> ```
> notmuch search --query=sexp '(thread (count 115)))'
> thread:00021229 2021-05-17 [5/5] Michael J Gruber ... redacted
> notmuch count --exclude=false thread:00021229
> 5
> ```
> It could be some
Am Mo., 13. Feb. 2023 um 13:26 Uhr schrieb David Bremner :
>
> So for this only supports counting messages in threads, and the sexp
> based query parser. It seems useful to expand it to other fields
> (from, e.g.). I'm not sure how motivated I am to shim this into the
> infix query parser, but we
Vishal Chourasia writes:
> Thanks! Installing the emacs-notmuch package from epel 8 worked.
>
Great, thanks for letting us know.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Thanks! Installing the emacs-notmuch package from epel 8 worked.
On 2/9/23 20:10, David Bremner wrote:
Vishal Chourasia writes:
On 2/7/23 19:53, David Bremner wrote:
Which distribution? At least on Debian based distributions, the emacs
interface is packaged seperately as elpa-notmuch
RHEL
Vishal Chourasia writes:
> On 2/7/23 19:53, David Bremner wrote:
>> Which distribution? At least on Debian based distributions, the emacs
>> interface is packaged seperately as elpa-notmuch
> RHEL
Fedora has a separate emacs-notmuch package. Perhaps that also exists in
RHEL? The page
RHEL
On 2/7/23 19:53, David Bremner wrote:
Vishal Chourasia writes:
Greetings,
where can I find the notmuch.el file when notmuch was installed from the
distribution's package repository?
# notmuch --version
notmuch 0.35
Which distribution? At least on Debian based distributions, the
On 2/7/23 19:53, David Bremner wrote:
Which distribution? At least on Debian based distributions, the emacs
interface is packaged seperately as elpa-notmuch
RHEL
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to
Vishal Chourasia writes:
> Greetings,
>
>
> where can I find the notmuch.el file when notmuch was installed from the
> distribution's package repository?
>
> # notmuch --version
> notmuch 0.35
Which distribution? At least on Debian based distributions, the emacs
interface is packaged
Daniel,
too late, i realized that my suggestion of link-hint isn't exactly a
match, as it is "missing" a "link-hint-display-hint" (or some such)
function.
i just now suggested such a function, but the below, which is *not*
fully formed, might occasionally be helpful if you do install link-hint
On Fri Jan 27, 2023 at 3:05 PM CET, Greg Minshall wrote:
> you might think of using the link-hint package.
I was going to say the same thing. link-hint is an essential part of my
workflow. Since I mostly use notmuch-tree, I have this:
```
(defun inwit/notmuch-tree-open-link ()
"Avy select
Daniel Kahn Gillmor wrote:
> When using notmuch-emacs, and looking at a text/html part, i sometimes
> want to know where a given link is pointing to without clicking on it --
> e.g. to open it in an alternate browser.
you might think of using the link-hint
Hi Daniel,
* Daniel Kahn Gillmor [2023-01-26; 15:52 -05]:
> Hey notmuch folks--
>
> When using notmuch-emacs, and looking at a text/html part, i sometimes
> want to know where a given link is pointing to without clicking on it --
> e.g. to open it in an alternate browser.
>
> it appears that by
Daniel Kahn Gillmor writes:
> it appears that by positioning the point somewhere within the link and
> doing "M-x shr-copy-url" i can copy the target of the link to the kill
> ring.
> I think it can be added to the mode-map in emacs/notmuch-show.el. does
> anyone have a preference about what
Just a wild guess: have you tried installing the emacs package
exec-path-from-shell (from melpa)?
On 18/01/2023 19:16, David Bremner wrote:
ricardomart...@riseup.net writes:
> Ok, so I tested this. I tried stopping the systemd unit of the emacs
> server, opened an emacs instance, and started
ricardomart...@riseup.net writes:
> Ok, so I tested this. I tried stopping the systemd unit of the emacs
> server, opened an emacs instance, and started the server from within
> emacs (M-x server-start ). Connected to this server in a new frame
> ($ emacsclient -nc) and tried executing notmuch
>> What is the output of M-x notmuch-version for both emacsclient and emacs?
Both show notmuch version 0.37.
>> ... and how are you starting the emacs server?
I started as a systemd user unit. I'm using GNU Emacs 30.0.50
Development version 2f05f48918ec on master branch; build date
2023-01-07.
Am Mi., 18. Jan. 2023 um 15:40 Uhr schrieb David Bremner :
>
> ricardomart...@riseup.net writes:
>
> >
> > When I try to run notmuch from the emacsclient instance (M-x notmuch
> > ), I get an error
> > "notmuch count --batch failed
> > Please check that the notmuch CLI is new enough to support
ricardomart...@riseup.net writes:
>
> When I try to run notmuch from the emacsclient instance (M-x notmuch
> ), I get an error
> "notmuch count --batch failed
> Please check that the notmuch CLI is new enough to support `count
> --batch'. In general we recommend running matching versions of
> the
* David Mazieres:
> I've just released version 7 of muchsync [...]
Thanks, David. I have updated the corresponding MacPorts port, and
version 7 is now also available there.
-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send
On Fri Jan 6, 2023 at 12:36 PM CET, David Bremner wrote:
> Although this patch won't apply anymore, thanks for inspiring the work that
> lead to supporting undo. Unfortunately I stole the name
> "notmuch-tag-history" for a buffer local variable, so I guess someone
> interested in a global history
Daniel Kahn Gillmor writes:
> Just a nudge on this patch:
>
> any chance we can have it applied in the notmuch tree?
>
> --dkg
>
Applied to master.
d
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to
Just a nudge on this patch:
any chance we can have it applied in the notmuch tree?
--dkg
On Fri 2022-11-11 05:16:31 -0500, Daniel Kahn Gillmor wrote:
> On Wed 2022-11-02 18:02:00 -0300, David Bremner wrote:
>> Daniel Kahn Gillmor writes:
>>
>>> GnuPG upstream has supported pkg-config since
inwit writes:
> Save a list of every tag change in the new variable notmuch-tag-history.
> ---
> Storing the full history of tags can prove useful for a) repeated tag
> changes as in [0] and b) eventually logging and undoing tag changes.
>
> This is my first commit in elisp. I expect turbulences
Tomi Ollila writes:
>
> Good progress -- bash has:
>
> $ bash -c 'set' | grep UID
> EUID=1001
> UID=1001
I made that change.
> another question is whether test_subtest_broken_for_root
> is good name. perhaps it is tolerable enough
I couldn't think of anything better, but am happy to search
On Wed, Jan 04 2023, David Bremner wrote:
> File permission errors e.g., are hard to trigger as root.
> ---
> test/T050-new.sh | 1 +
> test/T150-tagging.sh | 1 +
> test/test-lib.sh | 6 ++
> 3 files changed, 8 insertions(+)
>
> diff --git a/test/T050-new.sh b/test/T050-new.sh
>
David Bremner writes:
> Once gunzipped, this message (a bounced spam message) causes
> notmuch-show-mode to crash part way through redisplay in emacs 27. It
> seems fine in emacs-28.0.50 (Sept 26, after some related Gnus changes by
> larsi).
>
> It seems related to [1], but there is no crypto
Perhaps a case for exec-path-from-shell [1]?
[1] https://github.com/purcell/exec-path-from-shell
--alex
--
www.condition-alpha.com / @c_alpha
Sent from my iPhone; apologies for brevity and autocorrect weirdness.
> On 29. Dec 2022, at 14:20, David Bremner wrote:
>
> Boruch Baum writes:
Boruch Baum writes:
> I wasn't sure the best way to report a bug against it, so I hope by
> sending it to thislist it will find its proper home.
Sure that's fine. Or report a debian bug using reportbug, which saves
you copying down the relevant versions. In particular it's possibly
relevant
Tomi Ollila writes:
> On Sat, Dec 03 2022, David Bremner wrote:
>
>> _notmuch_message_delete can return (at least)
>> NOTMUCH_STATUS_XAPIAN_EXCEPTION, which we should not ignore.
>
> Series LGTM
> Tomi
Series applied to master.
d
___
notmuch mailing
David Bremner writes:
> We use notmuch search in two places in notmuch-git.py: to find which
> tags have a given prefix, and to see if message with given id exists
> locally. In both cases we do not want the presence of exclude tags
> (e.g. deleted) to change the results.
> ---
> notmuch-git.py
David Bremner writes:
> David Bremner writes:
>
>> This tests the issue reported by Thibault in id:87wn9w4xus@thb.lt
>> ---
>>
>> I could not duplicate the problem here. Maybe it depends on the version of
>> gmime?
>> I have 3.2.9 here.
>
> Now that I have gmime 3.2.13 I can confirm your
On Mon, Dec 26 2022, David Bremner wrote:
> Amended by db: Copy docstring to manual and edit for presentation. Add
> two tests.
Thanks for the grunt work, David. Just a comment on a sloppy comment of
mine below:
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -1014,7 +1014,10
On Sat, Dec 03 2022, David Bremner wrote:
> _notmuch_message_delete can return (at least)
> NOTMUCH_STATUS_XAPIAN_EXCEPTION, which we should not ignore.
Series LGTM
Tomi
> ---
> lib/database.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/database.cc
On Sat, Dec 03 2022, Thomas Schneider wrote:
> Tomi Ollila writes:
>
>> On Fri, Dec 02 2022, Thomas Schneider wrote:
>>
>>> As per strcasestr(3) of glibc and FreeBSD, the header that defines
>>> strcasestr() is string.h, not strings.h. This may cause compilation,
>>> and thus detection whether
Hello,
On Wed 21 Dec 2022 at 07:53AM -04, David Bremner wrote:
> Sean Whitton writes:
>
>>
>> I know that you don't want to commit notmuch-pkg.el to git, and that's
>> in fact undesirable from a NonGNU ELPA point of view, it turns out. But
>> given how there is already version.txt and
Bogdan Ruslanovich Drozd writes:
> In `notmuch-message-mode' subject can be truncated.
>
> How to reproduce:
>
> 1. Send an email message to yourself with the subject “test abcdf fdcba
>12345 54321 qwerty ytrewq 09876 67890 =- -= zxcv vcxz m,./ /.,m asdf
>fdsa ';lk kl;' qaz zaq ]'/ /']
Stefan Monnier writes:
>> I know that you don't want to commit notmuch-pkg.el to git, and that's
>> in fact undesirable from a NonGNU ELPA point of view, it turns out. But
>> given how there is already version.txt and version.py, could we have a
>> header in notmuch.el too, do you think?
>
>
Sean Whitton writes:
>
> I know that you don't want to commit notmuch-pkg.el to git, and that's
> in fact undesirable from a NonGNU ELPA point of view, it turns out. But
> given how there is already version.txt and version.py, could we have a
> header in notmuch.el too, do you think?
The
> I know that you don't want to commit notmuch-pkg.el to git, and that's
> in fact undesirable from a NonGNU ELPA point of view, it turns out. But
> given how there is already version.txt and version.py, could we have a
> header in notmuch.el too, do you think?
BTW, in an ideal world (from the
Hello notmuch maintainers,
As discussed on IRC, I'm seeing if I can add notmuch.el to NonGNU ELPA.
Currently the build is failing and Stefan Monnier, who designed the
packaging scripts, suggests adding a Version: header to notmuch.el:
On Tue 20 Dec 2022 at 02:44PM -05, Stefan Monnier wrote:
>>
On Mon, Dec 12 2022, Jose A. Ortega Ruiz wrote:
> took a second look, and yes, it's close but not quite. there are cases
> (when the message is not the first but its depth is 0) where its outline
> level doesn't match the depth. we could store the depth and then repeat
> the computation
On Mon, Dec 12 2022, David Bremner wrote:
> jao writes:
>>>
>>> As mentioned in my previous reply, I'm still not 100% clear on why we
>>> need both depth and level.
>>
>> i might be misremembering, but i think depth is just an auxiliarly
>> argument taken by that function to know whether it's
"Jose A. Ortega Ruiz" writes:
>
> the intent is to know whether the notmuch-tree-message-buffer is
> displaying the message the point in notmuch-tree is at, so it's not
> enough that there's a window showing it. but yes, you're right that's
> not a good way of checking. Perhaps this:
>
>
On Mon, Dec 12 2022, David Bremner wrote:
+ (buffer-name notmuch-tree-message-buffer
>>>
>>> At first glance, depending on the buffer name seems fragile?
>>
>> not sure why, or how to make it more robust...
>
> It depends on the buffer being named after the message-id. If
On Mon, Dec 12 2022, David Bremner wrote:
> jao writes:
>>>
>>> As mentioned in my previous reply, I'm still not 100% clear on why we
>>> need both depth and level.
>>
>> i might be misremembering, but i think depth is just an auxiliarly
>> argument taken by that function to know whether it's
jao writes:
>>
>> As mentioned in my previous reply, I'm still not 100% clear on why we
>> need both depth and level.
>
> i might be misremembering, but i think depth is just an auxiliarly
> argument taken by that function to know whether it's inserting the tip
> of a tree or not, not a real
Thanks for your comments, David. Unfortunately, i won't be able to work
on this for quite a few months. I am hoping someone else might perhaps
take the patch over and fix the issues you pinpoint below. I'm adding
just a handful quick comments:
On Sun, Dec 11 2022, David Bremner wrote:
[...]
jao writes:
> +(defcustom notmuch-tree-outline-visibility 'hide-others
> + "Default state of the forest outline for `notmuch-tree-outline-mode'.
> +
> +This variable controls the state of a forest initially and after
> +a movement command. If set to nil, all trees are displayed while
> +the
Emmanuel Beffara writes:
> Hello,
>
> I am stumbling upon what looks to be a bug.
>
> Sometimes I receive messages where a header entry consists of several chunks
> of base64-encoded quoted utf-8 text. For instance:
>
> Subject:
>
backup.tags" before some bold
>> experiments.
>
> a question: i'm still starting, experimenting, and i assume at some
> point i will throw my accumulated notmuch database away, and do a "new"
> to re-build from scratch. given that, are there any dangers i should
> worry about
l starting, experimenting, and i assume at some
point i will throw my accumulated notmuch database away, and do a "new"
to re-build from scratch. given that, are there any dangers i should
worry about while experimenting boldly?
cheers, Greg
Greg Minshall writes:
> hi. apologies if this is an FAQ.
>
> i'm exploring notmuch (via the emacs front-end). i have 1.2M e-mail
> messages sorted into 200 or so nmh folders. (*)
>
> after running `notmuch new`, i end up with 1.2M "unread" messages, all
> in "inbox".
>
> i would like to end
> Maybe afew [0] is what you're looking for.
thanks, that certainly gives me something to chew over.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Maybe afew [0] is what you're looking for.
[0] https://github.com/afewmail/afew
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
jao writes:
>
> diff --git a/doc/notmuch-emacs.rst b/doc/notmuch-emacs.rst
> index 846f5e67..b5f88a98 100644
> --- a/doc/notmuch-emacs.rst
> +++ b/doc/notmuch-emacs.rst
> @@ -606,6 +606,29 @@ can be controlled by the variable
> ``notmuch-search-oldest-first``.
> See also
Tomi Ollila writes:
> On Fri, Dec 02 2022, Thomas Schneider wrote:
>
>> As per strcasestr(3) of glibc and FreeBSD, the header that defines
>> strcasestr() is string.h, not strings.h. This may cause compilation,
>> and thus detection whether an (optimised) version is available, to
>> fail even
michaeljgruber+grubix+...@gmail.com writes:
> From: Michael J Gruber
>
> `notmuch search` behaves differently depending on the output option: It
> either outputs information pertaining to all threads with matching
> messages (summary, threads) or to all matching messages (messages,
> files,
On Fri, Dec 02 2022, Thomas Schneider wrote:
> As per strcasestr(3) of glibc and FreeBSD, the header that defines
> strcasestr() is string.h, not strings.h. This may cause compilation,
> and thus detection whether an (optimised) version is available, to
> fail even if the function is available,
November 29, 2022 5:44 PM, "David Bremner" wrote:
> mail...@z01d.net writes:
>
>> I'm running :
>> notmuch search --output=files --format=text folder:user@domain/INBOX
>>
>> For this query I get results mixed in from user@domain/Sent folder in
>> addition to expected results
>> from the INBOX
mail...@z01d.net writes:
> I'm running :
> notmuch search --output=files --format=text folder:user@domain/INBOX
>
> For this query I get results mixed in from user@domain/Sent folder in
> addition to expected results from the INBOX folder.
>
> For similar query to a different
Matt Armstrong writes:
[...]
> 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?
I've wanted something like this too and will be happy if someone points
out an existing
close 59147
thanks
> From: Gregor Zattler
> Cc: bug-gnu-em...@gnu.org, notmuch@notmuchmail.org
> Date: Fri, 18 Nov 2022 12:38:51 +0100
>
> Hi Eli,
> * Eli Zaretskii [2022-11-09; 16:43 +02]:
> > OK. I installed a possible fix. Can you update from Git, rebuild,
> > and see if it eliminates the
Hi Eli,
* Eli Zaretskii [2022-11-09; 16:43 +02]:
> OK. I installed a possible fix. Can you update from Git, rebuild,
> and see if it eliminates the assertions?
I did so same day. Before the problem was rather frequent.
But since the new build I did not encounter similar
problems.
Thank you
On Tue, Nov 15 2022, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> and then grepping thru notmuch source code:
>>
>> notmuch-tree.el:497: (delete-region (point) (1+ (line-end-position)))
>>
>> -- it looks to me this could be simpler and faster alternative.
>>
>
> Applied to master with
Tomi Ollila writes:
>
> and then grepping thru notmuch source code:
>
> notmuch-tree.el:497: (delete-region (point) (1+ (line-end-position)))
>
> -- it looks to me this could be simpler and faster alternative.
>
Applied to master with your suggested modification. Thanks for the
review.
d
el
> @@ -452,14 +452,20 @@ operation on the contents of the current buffer."
> (defun notmuch-show-update-tags (tags)
>"Update the displayed tags of the current message."
>(save-excursion
> -(goto-char (notmuch-show-message-top))
> -(when (re-search-forward "
Hi Eli,
* Eli Zaretskii [2022-11-09; 16:43 +02]:
> OK. I installed a possible fix. Can you update from Git, rebuild,
> and see if it eliminates the assertions?
sure, I fetched/pulled and did "make". I'm writing with
this new build. I will report back, if further assertions
show up (not till
s)
(buffer-string)))
(full-prompt
(concat table "\n\n"
(propertize prompt 'face 'minibuffer-prompt)))
;; By default, the minibuffer applies the minibuffer face to
;; the entire prompt. However, we want to clearly
Hi Eli,
* Eli Zaretskii [2022-11-09; 15:21 +02]:
>> From: Gregor Zattler
>> Date: Wed, 09 Nov 2022 13:37:13 +0100
>>
>> Dear Emacs and notmuch developers, lately Emacs often
>> hangs/crashes/stops while I'm working. I cannot reproduce
>> with emacs -Q, because I need at least org-mode and
On Wed 2022-11-02 18:02:00 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> GnuPG upstream has supported pkg-config since gpgme version 1.13 and
>> gpg-error 1.33, and now prefers the use of pkg-config by default,
>> instead of relying on gpg-error-config and gpgme-config.
>>
>> As
On Wed 2022-11-09 12:58:18 -0800, Jameson Graef Rollins wrote:
> Personally I think it would make sense to have % cycle through
> duplicates, with some indicator of which duplicate we're currently on.
> I wouldn't even bother with the suggested prefixed behavior if we just
> had the cycle
On Wed, Nov 09 2022, Daniel Kahn Gillmor wrote:
> On Wed 2022-11-09 09:53:26 -0500, Daniel Kahn Gillmor wrote:
>> The functionality here, switching between duplicates in the emacs
>> frontend, is great. I needed to use it today, because i had two copies
>> of an e-mail message, one with a valid
On Wed 2022-11-09 09:53:26 -0500, Daniel Kahn Gillmor wrote:
> The functionality here, switching between duplicates in the emacs
> frontend, is great. I needed to use it today, because i had two copies
> of an e-mail message, one with a valid signature and one with a damaged
> signature. It Just
omplicated to add things like
> "select all messages in this thread". With that selection mechanism in
> place, one could at any moment ask for the list of marked messages and
> their properties, which contain all the information needed to perform
> operations such as replies or taggi
On Fri 2022-07-01 18:45:39 -0300, David Bremner wrote:
> This obsoletes the WIP series [1]. Compared to that series, this one
> includes somewhat improved documentation, better error handling, and
> implements the --duplicate argument for notmuch-reply, and uses it in
> the emacs front end.
>
>
> From: Gregor Zattler
> Cc: bug-gnu-em...@gnu.org, notmuch@notmuchmail.org
> Date: Wed, 09 Nov 2022 15:35:01 +0100
>
> > The backtrace seems to indicate that it reads from the minibuffer, but
> > in that case, does it mean the mini-window was 7-lines high in this
> > case?
>
> quite possible,
> From: Gregor Zattler
> Cc: bug-gnu-em...@gnu.org, notmuch@notmuchmail.org
> Date: Wed, 09 Nov 2022 14:49:15 +0100
>
> > What does the below produce:
> >
> > (gdb) frame 2
> > (gdb) p matrix->nrows
>
> (gdb) frame 2
> #2 0x5559d310 in matrix_row (matrix=0x5d44d470, row=8) at
> From: Gregor Zattler
> Date: Wed, 09 Nov 2022 13:37:13 +0100
>
> Dear Emacs and notmuch developers, lately Emacs often
> hangs/crashes/stops while I'm working. I cannot reproduce
> with emacs -Q, because I need at least org-mode and notmuch
> for work.
>
> Anyway, here is a (x)backtrace from
mation needed to perform
operations such as replies or tagging (the latter being much easier to
implement; the part about multiple replies needs a bit more work, but
possibly one could re-use whatever functions gnus is already providing
to compose the reply buffer--notmuch already uses some of th
Matt Armstrong writes:
> A feature I miss from Gnus is being able to reply to multiple emails at
> once. Has anyone else found to be a missing feature?
I have, and support your request.
But not only to reply, but more generally to act on (tag, reply,
forward) multiple emails.
Of course I can
Jonathan Wilner writes:
> I love this feature! I hope it could get mainstreamed. :-)
Yes, seems like a nice idea to me.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
On Sat, Nov 05 2022, David Bremner wrote:
> Tomi Ollila writes:
>
>
>> Is this getting too complex (well, we may have other stuff with
>> similar complexity there ;/) ?
>>
>> Is there any better solutions ?
>
> I want to try redrawing the whole headerline. It should be more robust
> against
Tomi Ollila writes:
> Is this getting too complex (well, we may have other stuff with
> similar complexity there ;/) ?
>
> Is there any better solutions ?
I want to try redrawing the whole headerline. It should be more robust
against headerline format changes, but replacing the headerline has
Russell Sim writes:
> OTHER-HEADERS are expected to be passed as strings, to match the
> implementation of `compose-mail'. But the "From" header is currently
> expected to be passed as a symbol. Instead the "From" header can be
> safely added after converting all the headers to symbols.
Robin Jarry writes:
> notmuch search does not output header values. However, when browsing
> through a large email corpus, it can be time saving to be able to
> paginate without running notmuch show for each message/thread.
>
> Add --offset and --limit options to notmuch show. This is inspired
Matt Armstrong writes:
> notmuch-search-insert-authors now sets the evaporate property on the
> ellipsis overlays. Emacs will delete them when the buffer contents
> are zeroed out, which happens with `notmuch-refresh-buffer`. This
> prevents them from being collapsed to zero-width overlays in
On Fri, Nov 04 2022, jao wrote:
> This is essentiall the same as the previously sent v 6, rebased over
> the current master branch. Since that previous version has not
> elicited special enthusiasm, yet i use it all the time, so if you guys
> think it's not worth integrating into notmuch-emacs
I love this feature! I hope it could get mainstreamed. :-)
jao writes:
This is essentiall the same as the previously sent v 6, rebased over
the current master branch. Since that previous version has not
elicited special enthusiasm, yet i use it all the time, so if you guys
think it's not
Daniel Kahn Gillmor writes:
> GnuPG upstream has supported pkg-config since gpgme version 1.13 and
> gpg-error 1.33, and now prefers the use of pkg-config by default,
> instead of relying on gpg-error-config and gpgme-config.
>
> As of libgpg-error 1.46, upstream deliberately does not ship
>
501 - 600 of 17173 matches
Mail list logo
