Re: Individual tag file lines and removing all tags?
* David Bremner: > My assumption is that the overhead of multiple invocations is only > noticible for (at a guess) 1000s of calls to notmuch-tag. Well, that certainly would mean that my proposal has negligible merit in terms of efficiency. Matters of convenience and aesthetics probably don't offer enough justification either. Unless somebody is bored and looking for things to do, that is. ;-) -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
* David Bremner: > Is there a benefit beyond simplifying this shell script (and maybe > aesthetics)? In addition to what you mentioned, and more importantly, I am thinking about efficiency. notmuch-tag(1) states that batch tagging operations are "more efficient than repeated notmuch tag invocations" (this is not qualified further). I don't know if the efficiency advantage of batch tagging would justify the time/effort required to implement the feature? -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Individual tag file lines and removing all tags?
* David Bremner: > As far as I understand your request, this would currently need 3 > different calls to notmuch-tag (or some scripting in e.g. python). I currently use a custom wrapper script to call notmuch-tag multiple times for this very reason. I would prefer being able to use the '-*' syntax shown in my OP with "notmuch tag --batch". Is this a reasonable new-feature-suggestion, or do you guys think it too exotic? Am I perhaps the only one who finds this useful? -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Individual tag file lines and removing all tags?
Looking at the notmuch-tag(1) man page, I wonder if something like the following tag file content is currently possible: -* +deleted -- folder:.Trash -* +ancient -- date:..10_years_ago +foo -- from:f...@example.com What I am trying to achieve with lines 1 and 2 is replacing all existing tags (symbolised by '-*') with the 'deleted' or 'ancient' tag, respectively. With line 3, I want to add the 'foo' tag, but leaving any existing tags untouched (this is already works, of course). Using both --batch and --remove-all simultaneously for notmuch-tag is not permitted, and rightly so, because the hypothetical semantics would seem odd. The remove-all-existing-tags step would probably need to apply to all tag file lines, which does not seem very useful to me. Does this paragraph even make sense? ;-) -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Recommended method to pair Notmuch with Neovim?
Side note for the morbidly curious: Getting notmuch-vim operational on my production servers took some work. Gentoo Linux's net-mail/notmuch ebuild does not currently create Ruby bindings (only Python). Given that Gentoo supports packages having multiple versions installed simultaneously, Ruby for instance, extending the ebuild is not trivial. I got it working specifically for my own machines, but my ebuild variant would not yet pass Gentoo's QA checks. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Recommended method to pair Notmuch with Neovim?
Jon Fineman wrote: > [database] > path=/home/jjf/Maildir > > > and is your Notmuch DB directory /full/path/to/your/Maildir/.notmuch , > > i.e. nested inside your Maildir folder? > Yes. Then our respective directory paths are similar. aerc still does not work for me, though. I had suspected that the nested directories might be causing trouble for me, but that's apparently not the case. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Recommended method to pair Notmuch with Neovim?
* Jon Fineman: > [jjf-notmuch] > maildir-store = ~/Maildir > source = notmuch://~/Maildir > outgoing = /usr/sbin/sendmail > default = INBOX Thanks, Jon. Alas, this does not work for me. Does your .notmuch-config contain something the following: [database] path=/full/path/to/your/Maildir and is your Notmuch DB directory /full/path/to/your/Maildir/.notmuch , i.e. nested inside your Maildir folder? -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Recommended method to pair Notmuch with Neovim?
* Felipe Contreras: > I just installed neovim-ruby and tried to send an email with > neovim+notmuch-vim: it was sent just fine. That's good to hear. Hopefully I am just doing something wrong, which would be easiest to fix (at least if I knew what that "something" was). Today I have compiled Vim 9 from source code; Ruby support included. I added the vim-plug plugin manager, installed notmuch-vim via Plug 'felipec/notmuch-vim' et voilà, it works. That includes sending email. Nice. Now I have a basis to familiarise myself with notmuch-vim. If only I could get it to work with Neovim, like you did, I'd be all set. > I'd be happy to consider other alternatives, but at this point which > are those? Anything that is fast and can use libnotmuch, probably? Go comes to mind. Or even Zig. > That's aerc, nothing to do with notmuch-vim. > > Are you getting the two confused? Yeah, sorry, that part of my response was related to Jon Fineman's latest message. I was doing too many things at once yesterday. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Recommended method to pair Notmuch with Neovim?
* Felipe Contreras: > neovim aims to support most of what vim does. At the time of me writing this, the Neovim tracker on GitHub lists a whopping 1380 open issues, so I'd imagine that goal has not yet been reached. ;-) > Did you install the "mail" gem as the installation instructions > recommend? I did indeed. The message header was sent during each of my tests, but not the body text. > It sounds better to you as a user. > > Just try to program a paginated list of items in Lua and you might > change your mind. I am grateful for you investing time and effort in your plugin, and I don't want to talk you out of using Ruby, if that is your language of choice. My choice would be different, but that is off topic. I'd be glad to get notmuch-vim working with Neovim, even if that means installing Ruby. Currently the log file looks like this: INFO 2023/04/18 07:27:20.254544 main.go:180: Starting up version 0.14.0-153-g6220711f90d7 +notmuch (go1.19.2 amd64 linux) DEBUG 2023/04/18 07:27:20.254639 crypto.go:36: no internal pgp keyring, using system gpg DEBUG 2023/04/18 07:27:20.263046 receive.go:30: Starting Unix server: /run/user/1000/aerc.sock DEBUG 2023/04/18 07:27:20.264202 main.go:136: Setting terminal title INFO 2023/04/18 07:27:20.269082 account.go:250: [Trial] connected. ERROR 2023/04/18 07:28:07.049184 status.go:129: Cannot perform action. Messages still loading DEBUG 2023/04/18 07:28:07.049322 status.go:104: Cannot perform action. Messages still loading aerc displays "(no folders)" and "(no messages)", on startup, so I thought I'd try the search function with "date:yesterday..", causing the "Message still loading" error. Running "notmuch search date:yesterday.." in a shell returns the expected results. > I would try in vim as well, just so you see how it's supposed to work. I guess I should do that. Right now, I don't know if my troubles are caused by me somehow screwing up the notmuch-vim configuration or by Neovim quirks. Speaking of my configuration: # Content of /home/trial/.config/aerc/accounts.conf [Trial] from = Trial User maildir-store = /home/trial/.mail source = notmuch:///home/trial outgoing = /usr/sbin/sendmail -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Recommended method to pair Notmuch with Neovim?
* in...@sindominio.net: > A different kind of alternative is to use aerc with nvim as an editor. I did not really have a separate mail client in mind, but I experimented with aerc today. I built aerc from its source code, with Notmuch support enabled. Alas, I am stuck at launch: - 8< - snip - 8< - INFO 2023/04/18 00:09:26.887462 main.go:180: Starting up version 0.14.0-153-g6220711f90d7 +notmuch (go1.19.2 amd64 linux) INFO 2023/04/18 00:09:26.897506 main.go:132: Terminal does not have status line support ERROR 2023/04/18 00:09:26.897669 worker.go:83: ProcessAction(*types.Connect) failure: could not connect to notmuch db: Something went wrong trying to read or write a file ERROR 2023/04/18 00:09:26.899454 account.go:359: [aerc Trial] unexpected error: could not connect to notmuch db: Something went wrong trying to read or write a file ERROR 2023/04/18 00:09:26.899498 status.go:129: aerc Trial: could not connect to notmuch db: Something went wrong trying to read or write a file - 8< - snip - 8< - Not very specific, as error messages go, and searching the Internet did not lead me to enlightenment. Would you perhaps be willing to share the contents of your ~/.config/aerc folder (anonymised, of course)? -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Recommended method to pair Notmuch with Neovim?
* Felipe Contreras: > There hasn't been any development because to be frank it just works. I did not mean to imply that "no repository changes" is necessarily a bad thing. However, Neovim being quite volatile, I intuitively expected some form of development for notmuch-vim being necessary to keep things working. > I've also started to rewrite it from scratch because a lot of it I > think can be done in a much simpler way, but that doesn't really > affect the users, it's just the maintenance of the code. That tells me you are still invested in the subject, which is a welcome thing to read. > I tried notmuch-vim on neovim with ruby support some time ago and it > worked fine. I think there was some issue with slowness, but they > fixed it. I don't really remember. I set up a virtual Ubuntu 22.04 Server with Notmuch for testing, and managed to get Ruby 3 support for Neovim [1] working. I then used your plugin via the "Lazy" package manager for Neovim. Some of the basics work. Navigating and searching look OK, but I have yet to manage to send email. So far, message bodies are always missing, so it is not usable yet. Neovim keeps reporting tons of errors when I try to compose and send email, and I have not yet delved deeper. [1] https://github.com/neovim/neovim-ruby > One alternative that I considered is to rewrite notmuch-vim in lua, > but that would probably require some libnotmuch bindings for lua, > which would take considerable amount of time to write. And that would > only work for neovim, not vim. >From what I understand, Vim 9 introduces a new, proprietary scripting language, while Neovim uses LUA? That seems to foreshadow lots of work if one wishes to provide plugins that work with both editors. > It might be better to just keep using ruby. It's a fantastic language, > there's already pretty good bindings for libnotmuch, and it works for > both vim and neovim. Ruby may be a worthwhile language, but in this particular scenario of Neovim and Notmuch, I see the end user's perspective: I don't need Ruby to run anything but notmuch-vim, so I don't want to install Ruby on various systems if it can be avoided. I'll do it if there is no alternative, but LUA sure sounds better than Ruby to me. Selfish, I know. ;-) > I think you should just give it a try. I began my experiments, but as stated above, I ran into issues that I have yet to figure out. Thank you for your response and for your plugin, Felipe. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Recommended method to pair Notmuch with Neovim?
Based on the Notmuch documentation [1] and Internet search results, Felipe Contreras' notmuch-vim plugin [2] used to be a popular method of combining Notmuch with Vim (at least classic Vim). However, there have not been any Git repository updates for this plugin for two years, while Neovim development has been very active during that time. Also, this particular plugin requires Ruby support in Vim, which I'd rather avoid, if possible. [1] https://git.notmuchmail.org/git/notmuch/blob/HEAD:/vim/README [2] https://github.com/felipec/notmuch-vim My questions are: 1. Do any of you fellow mailing list members use notmuch-vim with Neovim? 2. Can you recommend an alternative Notmuch/Neovim plugin? I am currently using Notmuch with Emacs, but I'd like to find a way to integrate Notmuch with Neovim instead. Your feedback is appreciated. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: ANNOUNCE: muchsync 7 released
* 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 an email to notmuch-le...@notmuchmail.org
Re: Dealing with Missing Date Headers
* Kevin Foley: > Has anyone ever dealt with missing "Date" headers? My emails from Etrade > in particular are missing them for whatever reason. Amazing, and not in a good way. There are only two required email headers, and Etrade manages to screw this up? Quoting RFC 5322 https://datatracker.ietf.org/doc/html/rfc5322#section-3.6 : The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional. This is something the message sender has to fix. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Handling Email Addresses Without Name
* Kevin Foley: > I realized I have a few messages, where the "from" address is missing > a name. For example, the from header is "j...@example.com" instead of > "John Doe ", which means the message won't show up > if I search "from:John". Using "from:jdoe" as a search term will match both variants. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: drop C-tab binding in hello mode, document .
* David Bremner: > - > + Are you sure you mean "backstab" with an "s"? I am currently watching a newbie play Dark Souls, so I am unsure. ;-) -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i an e-mail message?")
* Daniel Kahn Gillmor: > If we want e-mail to be able to offer a similar cadence and experience > -- if we want a decentralized, federated e-mail system to be able to > *compete* with messaging services, I think we do need to think about > these affordances. And who says that we want to (or should) compete with messaging services? I rarely use instant messaging services, and when I cannot avoid it, I see a lot of rubbish. I could easily do without 90% of all IMs received without feeling the least bit sad about it. ;-) This is a rather philosophical subject, but I see email as a tool for passing on meaningful information. A "thumbs up" response is of very little use to me personally. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i an e-mail message?")
* Daniel Kahn Gillmor: > https://www.rfc-editor.org/rfc/rfc9078.html > > In short form, this lets you "thumbs up" an e-mail message without > sending a longer reply. Oh my... Are "+1" replies not sufficient anymore for some people, or is this a means of allowing the authors to claim having created an RFC, no matter how useless it is? ;-) I believe that implementing this feature would be a waste of your talents, but that is of course for you to decide. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [ANN] notmuch-vim 0.7 released
* Felipe Contreras: > https://github.com/felipec/notmuch-vim > > I stopped working on it in 2014, but I'm back. Welcome back. This is an interesting plugin for sure. I'd like to package notmuch-vim for Gentoo Linux, but I have not been able to find information about licensing. Could you please add a LICENSE file to your Git repository? -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Please share recommendations of mail fetcher for notmuch on GNU
* Jorge P. de Morais Neto: > Could you then share your recommendation of mail fetcher for notmuch > on a GNU OS? If the server side uses the "maildir" format for storage (I do that with Dovecot), you may find Muchsync (http://www.muchsync.org) interesting. It allows synchronising both mail content and Notmuch data across different machines. The latter feature distinguishes Muchsync from the various IMAP sync tools. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: listing all the tags I've been using
* Kim Minh Kaplan: > notmuch search --output=tags '*' That's much nicer than my idea. Thanks. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: listing all the tags I've been using
* Alan Schmitt:
> I'm trying to document the tags I'm using for notmuch [...]
The following should get you started (untested, from memory):
notmuch dump | gawk -F '--' '{print $1}' | sort -u
Feel free to add some more AWK magic instead of the "sort -u" to
group/count by tag name.
-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Clashes between "version" files and C++ keyword
Building Notmuch on macOS is known to cause problems because the Notmuch
distribution archive contains two files named "version". These clash
with the keyword as defined in C++20 [1] and will likely
become obvious on other platforms as well once Compilers adopt the new
standard.
The two affected files in the Notmuch Git tree are
/bindings/python-cffi/version
/version
I suggest to rename them both to version.txt. The attached patch can
then be applied to make the necessary build file changes.
-Ralph
[1] https://en.cppreference.com/w/cpp/20#New_headers
diff --git Makefile.global Makefile.global
index cd489ef2..8477468d 100644
--- Makefile.global
+++ Makefile.global
@@ -17,7 +17,7 @@ else
DATE:=$(shell date +%F)
endif
-VERSION:=$(shell cat ${srcdir}/version)
+VERSION:=$(shell cat ${srcdir}/version.txt)
ELPA_VERSION:=$(subst ~,_,$(VERSION))
ifeq ($(filter release release-message pre-release update-versions,$(MAKECMDGOALS)),)
ifeq ($(IS_GIT),yes)
diff --git Makefile.local Makefile.local
index c65cee7c..dde7981b 100644
--- Makefile.local
+++ Makefile.local
@@ -19,7 +19,7 @@ endif
# Depend (also) on the file 'version'. In case of ifeq ($(IS_GIT),yes)
# this file may already have been updated.
-version.stamp: $(srcdir)/version
+version.stamp: $(srcdir)/version.txt
echo $(VERSION) > $@
$(TAR_FILE):
diff --git bindings/python-cffi/setup.py bindings/python-cffi/setup.py
index b0060835..cda52338 100644
--- bindings/python-cffi/setup.py
+++ bindings/python-cffi/setup.py
@@ -1,6 +1,6 @@
import setuptools
-with open('version') as fp:
+with open('version.txt') as fp:
VERSION = fp.read().strip()
setuptools.setup(
diff --git doc/conf.py doc/conf.py
index 94e266af..11bed51d 100644
--- doc/conf.py
+++ doc/conf.py
@@ -19,7 +19,7 @@ copyright = u'2009-2020, Carl Worth and many others'
location = os.path.dirname(__file__)
for pathdir in ['.', '..']:
-version_file = os.path.join(location,pathdir,'version')
+version_file = os.path.join(location,pathdir,'version.txt')
if os.path.exists(version_file):
with open(version_file,'r') as infile:
version=infile.read().replace('\n','')
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Dependencies should include "realpath"
* Tomi Ollila:
>> rsti_dir = os.path.abspath('emacs')
>
> Good suggestion, anyway, the simplest change would be just:
>
> - printf "rsti_dir = '%s'\n" $(realpath emacs)
> + printf "rsti_dir = '%s'\n" $(cd emacs && pwd -P)
Looks like "pwd -P" is part of the Open Group base spec for pwd, so it
should be available on supported platforms.
> Then, just for the record, I think open(rsti_dir+'/'+file) is fine,
> and I don't see it failing on any imaginable system notmuch work
> (now?;)
As they say, you have the right to your opinion. ;-) I don't think it is
"fine" at all. While rsti_dir+'/'+file may work, depending on the
platform used, os.path.join(rsti_dir, file) *will* work.
Quoting Python's "os" description, first sentence: "This module provides
a portable way of using operating system dependent functionality." I see
no viable reason not to use "os".
> I am even personally changing some os.path.join(...) commands to use
> that concatenation instead, just to reduce complexity and line count
> elsewhere...
I am sorry to hear that. There is nothing complex about using os.path,
and as far as I am concerned, correctness and ease of maintenance beats
a reduced line count every single time.
-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Dependencies should include "realpath"
* David Bremner:
> I'm not sure what an "overhaul" would involve.
Looking at conf.py, I find the following confusing:
lines = ['.. include:: /../emacs/rstdoc.rsti\n\n'] # in the source tree
for file in ('notmuch.rsti', 'notmuch-lib.rsti', 'notmuch-show.rsti',
'notmuch-tag.rsti'):
lines.extend(open(rsti_dir+'/'+file))
rst_epilog = ''.join(lines)
del lines
"lines" is of type List[str]. In a loop which uses "file" (a reserved
expression), open() returns file handles on success. The string (!) list
is then extended with file handles, and after the loop, members of the
list (one string, n file handles) are concatenated using an empty string.
What is the reasoning behind this code segment?
As for generating a config file with configure and then reading and
executing individual lines from Python: Why not write to doc/dyncf.py
and use "from .dyncf import tags, rsti_dir" in conf.py?
Maybe I am off on a tangent, though. It would help me if I knew what
problem you were actually trying to solve?`
-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Dependencies should include "realpath"
* David Bremner:
> Do you have a suggested replacement? I guess some inline perl with "use
> Cwd 'realpath'" would probably work, although I haven't tested it.
At a quick glance, that particular section of "configure" is run by
doc/conf.py to generate three lines of Python code and store the result
as sphinx.config, correct? If so, my preferred choice would be to use
Python to figure out the absolute path, e.g. like so:
rsti_dir = os.path.abspath('emacs')
This shows the generated result, and I assume that emacs is a directory
in the source tree? I also wonder if an absolute directory path is really
required for the doc-build to work.
The segment of conf.py which uses the generated config file does not
look convincing to me anyway. Apparently the original author did not
like it either, which is why the segment is labelled as "hacky". It
should probably be overhauled, and not only because it uses the
statement open(rsti_dir+'/'+file) which will potentially fail, depending
on the build platform.
-Ralph
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Dependencies should include "realpath"
Since this issue just came up related to my MacPorts port: The list of dependencies for notmuch should include "realpath". configure [1] relies on realpath to generate the value for rsti_dir. [1] https://git.notmuchmail.org/git?p=notmuch;a=blob;f=configure;h=40e8b2559e86b40985ef2c6dc142eb0104c3ddb6;hb=45193bab16c728ba892a5d45fc62ef59e2a6ef85#l1539 While Linux usually comes with realpath included, macOS does not, and I am not quite sure about BSD variants. -Ralph ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] completion: remove "setup" from the list of possible completions
* Tomi Ollila: > You're wrong and I am right... ;) "I'm sorry, if you were right, I would agree with you." (Dr. M. Sayer) :-) > note that I also have no notmuch-* commands in my PATH, so 'notm' > expands to 'notmuch ' ! \o/ FTW ;) I like aliases like "nme" for "Notmuch in Emacs". -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] completion: remove "setup" from the list of possible completions
* Tomi Ollila: > imo.the completions should primarily provide convenience to the > interactive user, to see all possible options (also those > seldomly.used) one can use help and namual pages... "Can use" being the operative term, not "should have to use". I would not want completion to omit certain commands, based on somebody else's notion of what is convenient, which in turn forces me to use other means of figuring out a seldom-used command I may or may not be aware of. If this means entering three characters instead of two, then three characters it is. Alternatively, make it a configurable option, with "convenient=false" being the default. I vote against the change. First world problems... ;-) -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python 3.x bindings support which versions, exactly?
* David Bremner: > That's another reason for me to get a release out the door soon. Given how long ago the old Python bindings were written, I can wait a bit longer for the improved version. ;-) Still, I am looking forward to the next Notmuch release. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python 3.x bindings support which versions, exactly?
* David Bremner: > The new bindings (modulename= notmuch2) should work with any python > recent 3.x. They still have a few rough edges afaiu, but definitely > new projects should target the new bindings. Alas, there are no release archives available yet which contain the new bindings. I was hoping to add Python 3.8 support for the Gentoo Linux package I maintain, but our ebuilds rely on tagged releases of the packaged software. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Python 3.x bindings support which versions, exactly?
Hello, having examined the source code, I assume that Notmuch's Python bindings should support Python 3.x for any given 'x'. However, reading the Travis logs at https://travis-ci.org/notmuch/notmuch and .travis.yml, the CI tests apparently run on Ubuntu 18.04 and use only Python 3.6. While I hope there won't be any problems with Python 3.7, 3.8 and 3.9, I wanted to ask here first if anybody has tested this yet? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: How to use notmuch on several devices
* moonmaill...@firemail.cc: > I just wonder, how to keep the inboxes the same/in sync and export/ > import notmuch configuration and how to use it on a new device? Personally, I find http://www.muchsync.org useful for this task. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Attach public key and encrypt by default
* Carolyn Knight-Serrano: > would it be possible to add or configure in support for automatically > adding your gpg public key to messages? As already mentioned, adding several KB of GPG key to the body of each of your messages would be very impolite, and it might get you flagged as a spammer. A possible alternative is Autocrypt (https://autocrypt.org/) which uses the message header, but the most bandwidth-friendly method is still a URL pointing to your self-hosted key material. Also there are publicly available key servers like http://pgp.mit.edu , with their own pros and cons. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Syncing of IMAP accounts
* Nicolas Bock: > I am using offlineimap to sync my email for use with notmuch. Try muchsync (http://www.muchsync.org) instead. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Workaround for Exchange-corrupted PGP/Mime structure
* Carl Worth: > What would anyone think about a workaround where notmuch-emacs could > grub around inside a "multipart/mixed" structure looking for child > parts that look like they really should have been a part of a > "multipart/encrypted" container? Personally, I see no reason to spend any effort in Notmuch to fix whatever Exchange has screwed up this week. Microsoft has more than enough resources to clean up their own messes, don't you think? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Notmuch, Emacs and pinentry -- oh my
* Daniel Kahn Gillmor: > This hypothetical subcommand would just protect the index. [...] you > will be able to read your mail without access to your long-term secret > key material [...] That sounds useful, as does the idea of (un)locking the index. As you may have seen on the GnuPG mailing list, I have not yet cracked the nut of pass phrase input in Emacs. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Notmuch, Emacs and pinentry -- oh my
* Daniel Kahn Gillmor: > Have you considered running gpg-agent in a dedicated terminal window, > and handling the gpg-agent prompts from that window? I tried that by setting GPG_TTY to a fixed terminal, but while this seemed to work on the first call, the second time I was prompted for a password it was echoed, in cleartext, to the terminal. Is there a better method to achieve what you proposed? > To be clear about your threat model here: [...] Barring break-ins, nobody but me is logging in on that particular server, so intercepting gpg-agent would be difficult. Access to the Notmuch index would not be any easier, unless somebody physically removed the hard drives. The lock/unlock operations to seems interesting, and, if it was based on strong encryption, I would feel more comfortable. Are you thinking of protecting just the index or the whole Maildir store? The latter would not work for me, because Dovecot needs to access the data, and if only the index is protected, I'd still need to decrypt messages within Emacs. Currently, decryption happens in whatever MUA I am using at that time, i.e. mostly Notmuch/Emacs and alternatively Thunderbird/Enigmail. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Notmuch, Emacs and pinentry -- oh my
* David Bremner: > My only (not always popular advice) w.r.t. pinentry is to use a > graphical pinentry if at all possible. I only access the server with a terminal, and that's where Emacs is running in. Curses is as graphical as it gets. ;-) > Not all Emacs binaries have support for emacs-pinentry built > in. Reading gpg passphrases (or root passwords) into the same > emacs as runs a mail or irc client makes me nervous personally [...] See https://www.gnu.org/software/emacs/news/NEWS.26.1, section "The pinentry.el library has been removed.", remarks about minibuffer vs. graphical pinentry programs. I have tried 'epa-pinentry-mode' with both loopback and nil, and I tried both with and without 'allow-emacs-pinentry' in gpg-agent.conf. It does not seem to make a difference what I try, though. As for the nuclear option of decoding on indexing: That worries me more than using Emacs with some form of pinentry and gpg-agent. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Notmuch, Emacs and pinentry -- oh my
Not being quite sure if this is the correct mailing list to ask, here we go anyway: Using Emacs as a Notmuch client, I occasionally come across email that is signed and/or encrypted. I am then prompted to a) decide if I trust the signator or b) to enter my PGP secret key's password. Alas, in these cases I can tell that Emacs expects input of me, but it only uses the bottom most two lines to do so, meaning that I cannot quite read what is expected of me. Assuming that pinentry is involved, I tried switching between pinentry-curses and pinentry-tty in my shell profile, but the result is unreadable in both cases. If I use commands like "pgp -d ..." in the shell, both pinentry variants work fine (in the case of curse, the prompt is smack in the middle of my terminal window, as expected). I have enabled 'allow-emacs-pinentry' in my gpg.conf, but that does not resolve the issue either, so I would be grateful for advice. Thanks. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Missing in 0.29.2 notmuch-dump.c: Fix output file being closed twice
* David Bremner: > That push was pushed to master, but not release. I guess at the time > it didn't seem serious enough to warrant a point release? I did not expect a point release for that patch in particular. However, given that the patch fixed a SIGABRT situation, I have assumed to see it included in whatever release came next. Version 0.29.2 happens to be the first release since the bugfix was accepted three months ago, hence my moderate disappointment that the fix is missing. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Indentation style
* Tomi Ollila: > I like mixed tabs and spaces. for example cursor moves faster... If that's the case, you're just not using the right keys to move around the source code. :-) In Vim, keys like W/B, +/- etc. ignore whitespaces anyway, and Emacs has equivalents. Rumour has it there are other editors out in the wild, but then, some people believe anything... ;-) I am aware this is a sensitive subject, but looking at the last 35+ years, I personally found that the only reliable way to avoid whitespace related hassle is to stick to spaces only. I am not in a position to decide this, of course, but I am glad that Python [1] even comes with a command line option which turns mixed indentation into errors, making it easy to spot these situations. -Ralph [1] https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Indentation style (was: [PATCH] notmuch-dump.c: Fix output file being closed twice)
* David Bremner: > I did have to revert one unrelated whitespace change. I knew I might run afoul of that the minute I read "Indent is 4 spaces with mixed tab/spaces and a tab width of 8" in the code style notes. ;-) In my experience, it is error-prone to mix tabs and spaces. Perhaps it would be useful to change to all spaces? Also, with an added editor mode line, supporting that style would be more convenient (for Emacs and Vim at least). -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] notmuch-dump.c: Fix output file being closed twice (V2)
This is version 2 of the patch, sorry for that. I had sent an older version by mistake. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] notmuch-dump.c: Fix output file being closed twice
Fixed: If the output file for a dump was non-writeable, gzclose_w()
was called twice on the output file handle, resulting in SIGABRT.
---
notmuch-dump.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/notmuch-dump.c b/notmuch-dump.c
index 505c1469..78282661 100644
--- a/notmuch-dump.c
+++ b/notmuch-dump.c
@@ -329,11 +329,12 @@ notmuch_database_dump (notmuch_database_t *notmuch,
}
}
-if (gzclose_w (output) != Z_OK) {
+ret = gzclose_w (output);
+output = NULL;
+if (ret) {
fprintf (stderr, "Error closing %s: %s\n", name_for_error,
gzerror (output, NULL));
ret = EXIT_FAILURE;
- output = NULL;
goto DONE;
}
--
2.21.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: SIGABRT if "notmuch dump" output file is not writeable
* David Bremner: > that's a message / abort from deep within libz. So odds of our being > able to fix it are pretty small. Based on a quick glance on notmuch_database_dump() in notmuch-dump.c, it seems to me that SIGABRT occurs in line 351: 350: if (ret != EXIT_SUCCESS && output) 351: (void) gzclose_w (output); gzclose_w(output) has already been called in line 332, before Notmuch attempts to rename the temp file to the output file. At that point, 'output' should be set to null as it is being checked later, but that erroneously only happens in case the close operation fails. The rename in line 341 fails because of permission/ownership issues, 'ret' contains the error code for that, 'output' is still non-null, so gzclose_w is called again -- ergo boom. I have not tested or debugged this so far, it is just a Mark-I-Eyeball analysis. I think I got it right, though. If you agree, I can provide a fix, which I will actually test. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: SIGABRT if "notmuch dump" output file is not writeable
* David Bremner: > I agree it's a bit ugly to look at. Ah, euphemisms. ;-) Personally, I associate "double free or corruption (!prev)" with memory trouble or situations where a library cannot recover from an error state and needs to bail out using abort(). Not being able to (over)write an existing file is not that serious, IMO. > Do you see any database corruption or more serious issues? No, and I don't expect any, as I am assuming that "notmuch dump" will only ever read the DB. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Bug: SIGABRT if "notmuch dump" output file is not writeable
This is what happens when calling "notmuch dump" (version 0.29.1) with an output file that is not writeable (tested with FISH and BASH): root > touch /tmp/out root > ls -l /tmp/out -rw-r--r-- 1 root root 0 Jul 22 20:36 /tmp/out nonroot > notmuch dump --output=/tmp/out Error renaming /tmp/out.kuZ9t5 to /tmp/out: Operation not permitted double free or corruption (!prev) fish: “notmuch dump --output=/tmp/out” terminated by signal SIGABRT (Abort) While it is understood that Notmuch cannot write to the specified output file, I don't think this should result in something as harsh as SIGABRT. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Notmuch support for GnuPG Web Key Directory
You may have followed a recent discussion on the GnuPG mailing list regarding poisoned keys on SKS key servers, and possible alternatives. I have set up a Web Key Directory (see https://wiki.gnupg.org/WKD), which is easy to do, and now I am wondering about Notmuch support for WKD. Has anybody considered this, and perhaps even compiled a list of necessary steps to implement it? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: replace use of gdb with LD_PRELOAD shims in T070-insert.sh
* Daniel Kahn Gillmor: > Do you think we could go ahead and apply these patches on master now > anyway, and fix them up subsequently to make sure they apply to MacOS? I still have not been able to set up any macOS based tests, because contractual work has kept me busy. I suggest you go ahead with the changes, and should I run into any unexpected issues in future builds, I'll speak up. I don't want to slow you folks down. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] configure: fix mktemp call for macOS
Add missing template to mktemp, as required by macOS / OS X.
Signed-off-by: Ralph Seichter
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 8b80f0e0..6e73b22e 100755
--- a/configure
+++ b/configure
@@ -529,7 +529,7 @@ int main () {
return 0;
}
EOF
-if ! TEMP_GPG=$(mktemp -d); then
+if ! TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XX"); then
printf 'No.\nCould not make tempdir for testing session-key support.\n'
errors=$((errors + 1))
elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c
${gmime_ldflags} -o _check_session_keys \
--
2.22.0
(This obsoletes id:87r27z63uk@ra.horus-it.com)
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: fix mktemp call for macOS
* Tomi Ollila:
> First, it would be better if
>
> TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XX")
>
> worked, then the behaviour on Linux would not change.
I'm trying to figure out if I can override $TMPDIR during the MacPorts
configure phase. According to the documentation, modifying environment
variables should work, but I am not quite there yet.
Corollary: I suggest we go for the method shown above for the time
being. I am not a fan of hardcoding paths either.
-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: fix mktemp call for macOS
* David Bremner:
> TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XX")
>
> (borrowed from test/test-lib.sh). This avoids hardcoding the temporary
> directory.
I had the same thought at first, but I want to ensure that the path
length does not cause trouble anymore.
> uname -v
Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019;
root:xnu-4903.261.4~2/RELEASE_X86_64
> echo $TMPDIR
/var/folders/m_/w5lk3r_1495dhnl4l0s96pr0gn/T/
That's my MacBook Pro with macOS 10.14.5 (Mojave). AFAIK, older versions
can have longer names. Also, I am concerned with accumulating clutter.
> grep clean_tmps_dirs /etc/defaults/periodic.conf
daily_clean_tmps_dirs="/tmp"
The /tmp directory will, with default settings, be cleaned periodically
by the OS, while $TMPDIR (which is user-specific) will not.
-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] configure: fix mktemp call for macOS
The mktemp call in configure is incompatible with /usr/bin/mktemp as
shipped with macOS, where it fails due to a missing parameter. I added
the missing template, and the call is now working with both Apple's
and GNU coreutils' mktemp.
Signed-off-by: Ralph Seichter
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 8b80f0e0..feebafcc 100755
--- a/configure
+++ b/configure
@@ -529,7 +529,7 @@ int main () {
return 0;
}
EOF
-if ! TEMP_GPG=$(mktemp -d); then
+if ! TEMP_GPG=$(mktemp -d /tmp/notmuch.XX); then
printf 'No.\nCould not make tempdir for testing session-key support.\n'
errors=$((errors + 1))
elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c
${gmime_ldflags} -o _check_session_keys \
--
2.21.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] doc: Makefile: stop build notmuch-emacs.info when not have emacs
* Doan Tran Cong Danh: > I don't know if this is a _good_ fix for this issue. Did you see id:20190611005024.22814-2-da...@tethera.net ? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Ye olde Apple mktemp
* Ralph Seichter: > The following local patch solves the issue for me [...] Well, it does solve the mktemp call failing due to a missing parameter. There is however additional fun [1] to be had once mktemp succeeds: -snip- Checking for GMime session key extraction support... gpg: can't connect to the agent: File name too long gpg: error getting the KEK: No agent running gpg: error reading '[stdin]': No agent running gpg: import from '[stdin]' failed: No agent running No. *** Error: Could not extract session keys from encrypted message. This is likely due to your GMime having been built against a old version of GPGME. Please try to rebuild your version of GMime against a more recent version of GPGME (at least GPGME 1.8.0). Your current GPGME development version is: 1.13.0-unknown -snip- I found a GNUPGHOME length limit mentioned in a Debian bug [2] and other places; looks like the Notmuch build is running into that limit. That configure does not regcognize GPGME 1.13.0 is of course only a minor issue, but the GnuPG error breaks the build. -Ralph [1] https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/88616/steps/install-port/logs/stdio [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847206 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] test: replace use of gdb with LD_PRELOAD shims in T070-insert.sh
* Daniel Kahn Gillmor: > Perhaps Ralph Seichter (explicitly cc'ed above) could comment on how > it'll affect homebrew? MacPorts, actually. ;-) I have not yet been able to look into this patch series, but I hope to be able to do so soonish. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Ye olde Apple mktemp
Another quirk that occurs during the configuration phase on older macOS
versions (when they were still called OS X, actually) in the MacPorts
build farm:
Checking for GMime session key extraction support...
usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
mktemp [-d] [-q] [-u] -t prefix
No.
Hooray for that ancient mktemp binary. :-/ The following local patch
solves the issue for me:
diff --git a/configure b/configure
index 8b80f0e0..fa715946 100755
--- a/configure
+++ b/configure
@@ -529,7 +529,7 @@ int main () {
return 0;
}
EOF
-if ! TEMP_GPG=$(mktemp -d); then
+if ! TEMP_GPG=$(mktemp -d -t /tmp); then
printf 'No.\nCould not make tempdir for testing session-key support.\n'
errors=$((errors + 1))
elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c
${gmime_ldflags} -o _check_session_keys \
Alas, "mktemp -d -t /tmp" is incompatible with GNU coreutils' mktemp,
while "mktemp -d -p /tmp" is not understood by Apple's variant because
of the "-p". I don't know what syntax would be universally acceptable.
Is there a way to pass platform-dependent parameters to mktemp with the
current build mechanics?
-Ralph
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: Attempt to install notmuch-emacs.info during --without-emacs build
MacPorts CI builds were successful as well. Thank you for the prompt fix, David. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: Attempt to install notmuch-emacs.info during --without-emacs build
* David Bremner: > Attempt #2; we need to delay expansion of INFO_TEXI_FILES until > WITH_EMACS is defined. Works nicely for my local builds. Now I need to wait for the CI builds to run. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: Attempt to install notmuch-emacs.info during --without-emacs build
* David Bremner: > The following seems to fix the problem, but I haven't tested it > extensively. As shown in https://monksofcool.net/tmp/6bmjUFL.log , your suggestion results in notmuch-emacs.info being generated but unfortunately not installed when Notmuch is built --with-emacs. Obviously that's better than a build failure for --without-emacs, but it is not quite ideal either. ;-) -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Bug: Attempt to install notmuch-emacs.info during --without-emacs build
MacPorts CI builds report the following [1]: DEBUG: system: cd "/opt/local/var/macports/build/_Users_vsts_agent_2.152.1_work_1_s_mail_notmuch/notmuch/work/notmuch-0.29" && ./configure --prefix=/opt/local --with-docs --without-emacs --without-ruby [...] Checking if emacs (>= 24) is available... No (so will not byte-compile emacs code) [...] /opt/local/var/macports/build/_Users_vsts_agent_2.152.1_work_1_s_mail_notmuch/notmuch/work/notmuch-0.29/doc/index.rst:7: WARNING: toctree contains reference to excluded document 'notmuch-emacs' WARNING: "texinfo_documents" config value references unknown document notmuch-emacs [...] install -m0644 doc/_build/texinfo/notmuch-address.info doc/_build/texinfo/notmuch-compact.info doc/_build/texinfo/notmuch-config.info doc/_build/texinfo/notmuch-count.info doc/_build/texinfo/notmuch-dump.info doc/_build/texinfo/notmuch-emacs-mua.info doc/_build/texinfo/notmuch-insert.info doc/_build/texinfo/notmuch-new.info doc/_build/texinfo/notmuch-reindex.info doc/_build/texinfo/notmuch-reply.info doc/_build/texinfo/notmuch-restore.info doc/_build/texinfo/notmuch-search.info doc/_build/texinfo/notmuch-show.info doc/_build/texinfo/notmuch-tag.info doc/_build/texinfo/notmuch.info doc/_build/texinfo/notmuch-hooks.info doc/_build/texinfo/notmuch-properties.info doc/_build/texinfo/notmuch-search-terms.info doc/_build/texinfo/notmuch-emacs.info /opt/local/var/macports/build/_Users_vsts_agent_2.152.1_work_1_s_mail_notmuch/notmuch/work/destroot/opt/local/share/info install: doc/_build/texinfo/notmuch-emacs.info: No such file or directory make: *** [install-info] Error 71 Why is the build trying to install texinfo/notmuch-emacs.info even though --without-emacs was specified during configuration and Emacs was not found during the sanity checks? [1] Full build log available at https://paste.z0k.xyz/8352cabdee6f.txt -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch release 0.29 now available
* David Bremner: > Yes, there was a brief discussion [...] Thanks. As I expected, it was my lack of attention that led to me being caught unawares. ;-) > I guess xz compression is something packagers will have to deal with. Of course, no worries. I am not miffed in any way, especially because it only amounts to adding a single option to my Portfile. I just wanted to make sure this was deliberate on your end before I open my pull request. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch release 0.29 now available
* David Bremner: > https://notmuchmail.org/releases/notmuch-0.29.tar.xz As the maintainer of Notmuch in MacPorts, I wonder why you chose to switch from a classical tarball to a .tar.xz archive? Did I miss some discussion on this mailing list? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: caching message arrival time
* Daniel Kahn Gillmor: > Since notmuch actually knows when it recieved the message [...] Not meaning to complicate things, but Notmuch does not receive messages at all. ;-) One needs to rely on some software to populate the Maildir tree (Dovecot LMTP in my case, Postfix or some other MTA for local delivery in other cases). Any software transporting the raw messages can, and sometimes must, manipulate the header data, and the order in which files within the Maildir tree are created is also not determined by Notmuch. As an example: My nightly backup script disables local delivery for the duration of the backup process. Once reactivated, delivery of queued messages resumes, but it is not guaranteed to happen in the order of arrival. So even the local MTA, although trusted, might induce issues in terms of delivery time. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: caching message arrival time
* Daniel Kahn Gillmor: > I'm working on Autocrypt integration for notmuch right now [...] Woot! :-) > I'm happy to explain more about my use case if people are interested > too. I'm interested. Right now I frankly don't know what knowing when a message was first seen by Notmuch might be useful for. That makes it a bit difficult for me to contemplate your questions. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [FEATURE] indexing arbitrary headers
* Daniel Kahn Gillmor: > I just wanted to point out that this specific request has now been > added to notmuch, thanks to David Bremner! Thanks indeed! I am very much looking forward to this feature. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Two "latest" releases available for download
I just realised that https://notmuchmail.org/releases/ holds both LATEST-notmuch-0.28.2.tar.gz and LATEST-notmuch-0.28.3.tar.gz, which seems to be one "latest" too many? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > Right, I think that point is clear now, that we're just talking about > changing the warning messages. Indeed. I am actually quite surprised how many reactions there were about this minor issue. I'm using the new.ignore settings you suggested, and I can live with that. The warning messages surprised me, is all. > I'm not saying I'm going to work on it, but I think I understand the > feature-request. I'd appreciate a change at some point in the future, time permitting, but I would not begrudge you spending your energy on more important issues. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* Eric: > I think that there will be lots of people (and organisations) who get > collections of email from elsewhere and want to add them all to their > own single collection for reference, archival, and research purposes. And how would dropping individual mail files into "cur" instead of any old folder limit that? > So that those emails would be forced into the IMAP folder structure, > making them visible (and possible distracting) there when viewed with > a traditional mail client? I don't know why you talk about "forced", and it is not an IMAP folder structure anyway. I have configured Dovecot to use a Maildir store specifically to allow Notmuch as a client in addition to IMAP. Other storage types like Multi-dbox would be more efficient for IMAP users. In my setup, I could circumvent Dovecot's LDA and have Postfix drop off mail directly in that same Maildir structure, but I want to enable users to use Sieve scripts. This works because Dovecot and Postfix have very similar ideas about how a Maildir store should look like. My point is: Maildir has a defined structure. I'm not against Notmuch supporting a wider range of layouts, but I think Notmuch should not complain about perfectly legitimate non-mail files found outside the Maildir scope. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* Daniel Kahn Gillmor: > as far as maildir goes, i think notmuch probably *shouldn't* be > looking at stuff in …/tmp/ -- right? You're right, I don't see why Notmuch would peek into "tmp". > I'd be sad if those files went away, but perhaps you're right that > we should only be looking at are things within any cur/ and new/ > subfolders within the message archive. I don't mean to reduce Notmuch usability to get rid of a few unwanted messages on stderr. What I suggest is to consider all files outside of "cur" and "new" to be legitimate non-mail files by default. If Notmuch chooses to inspect them and detects valid messages, then fine, but the default assumption should be non-mail. Think about how the files get there. You manually dumping some *.eml files in a directory is not exactly typical, IMO. ;-) I expect that in the majority of cases there is some MTA or fetchmail-like process storing mail files in a Maildir structure (flat, tree, or mixed like Dovecot does). I think that altering Notmuch's expectations about files outside of well-known subdirectories should be possible without sacrificing its flexibility. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > So the leading '/' isn't there to match for top level files. That's unexpected, so quite in tune with the thread subject. ;-) > ignore=/(^|/)dovecot[-.]/;/(maildirfolder|subscriptions)$/; I'll try that, thanks. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* Daniel Kahn Gillmor: > Why is "non-mail file found" in my maildir such a low priority? Because I do not agree with Notmuch's notion of what a non-mail file is. All files the Dovecot server uses for its own metadata are placed outside of "cur", "new", and "tmp". My understanding of the Maildir structure is that only these three subfolders in a given directory may contain mail files, so I expect Notmuch, as a default behaviour, to ignore whatever is stored outside of these subfolders. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* Ralph Seichter: > ignore=//dovecot[[:punct:]]/;/(maildirfolder|subscriptions)$/; Odd. I am currently adding this entry to some users' config files, and the expression //dovecot[[:punct:]]/ does not seem to work in all cases. Based on notmuch-search-terms(7) I assumed that Notmuch used POSIX.2 regular expressions, does it not? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > Are there warnings that you want to suppress that are not handleable > with the new.ignore facility? Sorry, I misunderstood your question, and new.ignore is sufficient for my current purposes: [new] ignore=//dovecot[[:punct:]]/;/(maildirfolder|subscriptions)$/; Thank you for pointing this feature out to me. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > I guess if you have a simple way of distinguishing the cases which you > want to consider as errrors, we can revisit the idea. Personally, I'd go with these decreasing levels of severity: Fatal: Execution must stop immediately to prevent damage, error message may or may not be displayed before exiting the process. Error: Serious trouble, program may or may not be able to recover, user intervention required. Warning: Minor trouble, program will recover without user intervention. Notice: Inform the user of a less-than-ideal situation (non-mail file found, deprecated functionality used, etc). Program will ignore the cause and carry on. I don't know if this is a fit for Notmuch, but it would be great if I could prevent warnings and notices from being reported by using a command line option. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > I could imagine more levels of quiet, but I don't know if it is worth > the trouble. I currently redirect stderr to /dev/null because the actual number of these "ignoring non-mail file" notices is much higher, but that means I don't get to see actual errors which is quite a disadvantage. An option like --veryquiet or --errorsonly would be helpful, but I can understand you asking if it would be worth the effort. For somebody like me who uses Dovecot as a backend it would be. ;-) > Could it maybe a wrapper script or hook invoked by notmuch new? Ah! The post-new hook called umask and caused the output. Thanks. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Unexpected output of "notmuch new --quiet"
Hi folks, I can't help but wonder why text like Note: Ignoring non-mail file: /home/foo/.maildir/.private/dovecot-uidlist Note: Ignoring non-mail file: /home/foo/.maildir/.work/dovecot.index.log 0022 is written when I run "notmuch new --quiet"? Only error conditions should be reported to stderr, so why are lines 1 and 2 written to stderr? Notes are not errors. Also, why is line #3, which represents the current umask value, written to stdout? I'm aware that the man page states "--quiet: Do not print progress or results.", but the output shown above is still unexpected. Perhaps somebody here can enlighten me. ;-) -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Autocrypt support
* Daniel Kahn Gillmor: > [...] if you'd like to help me strategize about next steps for getting > autocrypt support into notmuch itself, i'd welcome the collaboration. I'd be willing to help if you think I can actually be of use to you. ;-) I have, as of today, not even looked at the Notmuch architecture and source code. I do know a reasonable amount about GnuPG, RFC 5322 et al, though. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Autocrypt support
I'm not quite sure if this is a question of Notmuch's Emacs client or of Emacs in general, but I am trying to find information on Autocrypt support (see https://autocrypt.org/). The Enigmail addon for Thunderbird supports Autocrypt, and I wondered if/how Notmuch might be persuaded to support it as well? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Synchronize tags across machines without a mail server
* Dan Čermák: > Ralph Seichter writes: > >> * Pierre Neidhardt: >> >>> muchsync (http://www.muchsync.org/): Requires our own mail server if I >>> understand correctly. >> >> No. If you have a machine A with notmuch already set up, and want to >> sync to machine B, you only need SSH access from B to A (plus notmuch >> and muchsync installed on B). > > That's correct if you are fine with machine B only syncing with machine > A via muchsync and no longer with your mail servers via IMAP (or at > least I don't know a way how to make that work). Sorry for quoting the whole history here, but I don't see how your comment relates to me stating that muchsync does not require a "mail server"? If the MTA can deliver into Maildir (like Postfix can), one does not need an IMAP server at all. Muchsync can perform both content and metadata synchronisation, which takes care of my needs. I run it as a background job on my notebook. An IMAP server can be in the mix somewhere, but is not needed. That's all I am trying to say. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Synchronize tags across machines without a mail server
* Pierre Neidhardt: > muchsync (http://www.muchsync.org/): Requires our own mail server if I > understand correctly. No. If you have a machine A with notmuch already set up, and want to sync to machine B, you only need SSH access from B to A (plus notmuch and muchsync installed on B). -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: how do i split my email view (AKA I got a new job)
* Antoine Beaupré: > How can I make that "All tags" junk disappear? If it bugs you that much, you can use the "this page" link in "Customize Notmuch or this page". -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch release 0.28.3 now available
* David Bremner: > https://notmuchmail.org/releases/notmuch-0.28.3.tar.gz I'm looking at https://notmuchmail.org/releases/ right now, and I don't see any files for version 0.28.3. I made sure it is not a caching issue on my end. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Reply to content of "List-Post" header?
* Gregor Zattler: > my procmmail scripts recognize mailing list headers and in the end > there is a list of all mailing lists I ever got mails from [...] Interesting method. I don't use procmail, but I wrote a small shell script that scans my existing Maildir storage for List-Post headers and extracts the addresses. This works, in a fashion, but I wonder if/how it would be possible to make Notmuch understand List-Post natively? Or is this something that needs to be solved in Emacs' message composition? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Reply to content of "List-Post" header?
* Brian Sniffen: > You can set message-subscribed-addresses or its cousins; then > message-to-list-only will work for you. Ah, that's what was missing, thank you. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Reply to content of "List-Post" header?
* Gregor Zattler: > I do "R" for reply-to-all and then C-c C-l for message-to-list-only > which reduces the To: and Cc: to the mailing list address. I tried both "C-c C-l" and "M-x message-to-list-only" on several messages, but it does not seem to have any effect. I don't see any error reports, but nothing happens. > I don't know how this works, though. I assume it evaluates List- > headers. According to http://www.gnus.org/manual/big-message.html , Emacs Message mode processes the "Mail-Followup-To" header, which seems to be a rarity these days. "List-Post" et al apparently don't factor into it. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Reply to content of "List-Post" header?
Either my search-fu is lacking today, or there is really not much information to be found about this: Using Notmuch with Emacs, the keys "r" and "R" are bound to "reply to sender" and "reply to all", respectively. Neither is what I require when it comes to mailing lists. Is there any way to "reply to list", i.e. to only the address specified in the "List-Post" header? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: How do you synchronize your notmuch tags across multiple machines?
* Dan Čermák: > I have found muchsync, but unfortunately very little reports about how > well it works, which isn't necessarily a bad thing. Muchsync works well for me, although I only need to sync between two machines. It is quite fast after the initial synchronisation, and I did not have any problems yet. I reported a small error in the documentation, but that should be fixed by now. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: EMACS error "Package html2text is obsolete"
* Istvan Marko: > It defaults to shr as long as emacs was compiled with libxml. Thanks Istvan, that was the clue I needed. I rebuilt EMACS using libxml2 and now rendering HTML works. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
EMACS error "Package html2text is obsolete"
Hello list, I tried to access https://notmuchmail.org/pipermail/notmuch/ several times today, but it always resulted in a connection error, so I am now trying the mailing list. When I open a HTML message in the EMACS UI, the error message "Package html2text is obsolete!" is displayed. Is it possible to configure Notmuch to use SHR/EWW instead of html2text? -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
