id" ;;
*) exit $? ;;
esac
done
Then later process tags "learn-spam" and "learn-ham" by piping such
messages to "bogofilter -s" or "-n".
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F
ot; format. It will use "--offset=N" to skip
N output items, regardless of what they are: summary, threads,
messages, files, tags. [This is the wrong interpretation.]
So, how do we improve the notmuch-search manual so that everybody
understands "--offset=N" correctly?
--
* 2024-05-25 13:20:58+0200, Michael J. Gruber wrote:
>> Teemu Likonen writes:
>>> --offset=[-]N
>>> Skip displaying the first N results. With the leading '-',
>>> start at the Nth result from the end.
>>>
>>
* 2024-05-20 21:24:01+0300, Teemu Likonen wrote:
> It doesn't seem clear how offset is counted on command like
>
> notmuch search --output=files --offset=10 ...
>
> Does it skip 10 output files (which may belong to less than 10 messages)
> or does it skip 10 message
lts" but I think it can be interpreted either
as "displayed output results" or "search match results (messages)".
Perhaps the manual page needs a few more words to make it clear.
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B94
. It is a
nice fallback mode when threading is broken or complicated. Plain list
of timestamp-sorted messages help in this particular case because the
originally different threads (which are now the same thread) appeared in
different times.
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikon
* 2023-09-26 07:07:46-0300, David Bremner wrote:
> Teemu Likonen writes:
>> Perhaps my wish is that there was an easy way to break threads: mark a
>> message as origin of a new thread.
> How about if you delete the Message-ID, References, and In-Reply-To
> headers from th
hanism to mark messed threads automatically as read and move
on.
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
signature.asc
Description: PGP signature
___
notmuch mailing list -- notmu
* 2023-09-25 11:54:07+0300, Teemu Likonen wrote:
> Some person on debian-user mailing list seems to be sending messages
> with fixed Message-ID field: the same ID in different messages. In
> Notmuch it is creating trouble because it connects unrelated threads to
> one. The person h
the same message because the Message-ID is the same.
This is potentially a "denial of service" for Notmuch. Well, not quite,
but is harmful nonetheless. How would a Notmuch user fix the mess or
protect himself against it?
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
command you can use the
"--output" option:
--output=(summary|threads|messages|files|tags)
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
signature.asc
Description: PGP signature
__
here are too many mails for emacs to display
> comfortably.
I think it's normal to set saved searches so that they have a time
limit, like this:
to:something AND date:90days..
tag:something AND date:90days..
--
/// Teemu Likonen - .-.. https://www.iki.fi/
ct: " re) nil t)
(delete-region (match-beginning 1) (match-end 1)))
(defmacro my-with-message-headers (&rest body)
(declare (indent 0))
`(save-excursion
(save-restriction
(save-match-data
(message-narrow-to-head)
,@body
--
/// Teemu Likonen - .-.
dest-first))
notmuch-saved-searches)
:filter "tag:unread AND NOT tag:spam"
:hide-if-empty t))
(setq notmuch-hello-sections '(my-notmuch-hello-unread
notmuch-hello-insert-saved-searches
not
* 2020-12-31 17:39:23-0500, Daniel Kahn Gillmor wrote:
> On Wed 2020-12-30 12:46:02 +0200, Teemu Likonen wrote:
>> What about forwarding a message as MIME part which is just "text/plain"
>> (and not "message/rfc822")?
>
> This might be useful for some peop
etting (setq
message-forward-as-mime nil) and manually inserting Emacs MML tags in
the (notmuch-)message-mode buffer:
C-c RET p text/plain RET
or calling from Lisp code:
(mml-insert-part "text/plain")
The inserted MML tags need to be put manually around the forwarded
message.
ased on width and when
using tabular format in buffers. With that function zero-width
characters really have no width.
--
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450
signature.asc
Description: PGP signature
_
Emacs face definition forms are either
((DISPLAY . PLIST)
(DISPLAY . PLIST))
or
((DISPLAY PLIST) ;For backward compatibility.
(DISPLAY PLIST))
Commit a2388bc56e55da5d5695816818274f8a84b0ed92 (2020-08-08) follows
neither of the correct formats. It defines:
`class col
Emacs face definition forms are either
((DISPLAY . PLIST)
(DISPLAY . PLIST))
or
((DISPLAY PLIST) ;For backward compatibility.
(DISPLAY PLIST))
Commit a2388bc56e55da5d5695816818274f8a84b0ed92 (2020-08-08) follows
neither of the correct formats. It defines:
`class col
---
test/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Currently test/README file instructs user to download database files
with command:
make download-test-databases
That doesn't work for me. I got tests running after executing "make
download-corpus" instead. So maybe that'
* 2020-08-15 12:30:34+03, Teemu Likonen wrote:
> These patches continue the ideas written in message:
>
> id:87sgcuuzio@iki.fi
Here is a nice and relatively short reference for anyone who is
interested in the subject:
https://www.iamcal.com/understanding-bidirecti
The following Unicode's bidirectional control chars are modal so that
they push a new bidirectional rendering mode to a stack:
U+202A LEFT-TO-RIGHT EMBEDDING
U+202B RIGHT-TO-LEFT EMBEDDING
U+202D LEFT-TO-RIGHT OVERRIDE
U+202E RIGHT-TO-LEFT OVERRIDE
Every mode must be terminated wi
at it
calls the new function.
Teemu Likonen (2):
Emacs: Add a new function for balancing bidi control chars
Emacs: Call notmuch-balance-bidi-ctrl-chars in notmuch-sanitize
emacs/notmuch-lib.el | 57 +++-
1 file changed, 56 insertions(+), 1 deletion
---
emacs/notmuch-lib.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index e6252c6c..e0122f7a 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -527,7 +527,8 @@ function should be used when sanitizing arbitrary inp
Previously in message-show mode message's first header line (From
header) was always indented, even if user had turned thread
indentation off with "<" (notmuch-show-toggle-thread-indentation)
command.
This change modifies notmuch-show-insert-headerline function so that
it doesn't indent the first
* 2020-08-10 19:45:11+03, Teemu Likonen wrote:
> If we wanted to clean message headers from possible unpaired overrides
> we should clean all these:
>
> U+202A LEFT-TO-RIGHT EMBEDDING (push)
> U+202B RIGHT-TO-LEFT EMBEDDING (push)
> U+202C POP DIRECTIONAL FORMATTING
aracters and then
insert or remove some of them so that there are as many "push"
characters as "pop" characters.
--
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450
signature.asc
Description: PGP signature
___
Previously in message-show mode message's first header line (From
header) was always indented, even if user had turned thread
indentation off with "<" (notmuch-show-toggle-thread-indentation)
command.
This change modifies notmuch-show-insert-headerline function so that
it doesn't indent the first
Previously in message-show mode message's first header line (From
header) was always indented, even if user had turned thread
indentation off with "<" (notmuch-show-toggle-thread-indentation)
command.
This change modifies notmuch-show-insert-headerline function so that
it doesn't indent the first
nd I would like to test it but the patches
don't apply anymore. Would you like to send updated series?
--
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450
signature.asc
Description: PGP signature
_
In notmuch-show buffer insert invisible U+200E LEFT-TO-RIGHT MARK
character at the beginning of message header paragraph if the From
header contains a right-to-left character. This ensures that the
header paragraph is always rendered in left-to-right mode.
See Emacs Lisp reference manual section "
* 2020-08-06 17:50:36+03, Teemu Likonen wrote:
> But here is another idea for the whole thing: When displaying a message
> in notmuch-show buffer check if message's From header has any
> right-to-left characters and only if it does add invisible U+200E
> character at the beg
aces-n (* notmuch-show-indent-messages-width
depth))
+from
+" ("
+date
+") ("
+(notmuch-tag-format-tags tags tags)
+")\n")
(overlay-put (make-overlay start (point)) 'face
'notmuch-message-summary-face))
Insert invisible U+200E LEFT-TO-RIGHT MARK character at the beginning
of message header paragraph in notmuch-show buffer. The U+200E
character forces the header paragraph as left-to-right text even if
the header content started with right-to-left characters.
See Emacs Lisp reference manual section
* 2020-08-05 12:40:06+03, Teemu Likonen wrote:
> I think there are two options:
>
> 1. Add a string like "From: " in the beginning of notmuch-show header
> paragraph so that the paragraph always starts with left-to-right
> characters (those latin letters "
the code. I think that explains the purpose quite well. More verbose
explanation could be something like this:
;; Add invisible U+200E LEFT-TO-RIGHT MARK character to force the
;; header paragraph as left-to-right text even if some header's
;; content is right-to-left.
--
///
Insert invisible U+200E LEFT-TO-RIGHT MARK at the beginning of message
headers. It forces message headers to display as left-to-right text
even if there are strong directional characters in header's values.
See Emacs Lisp reference manual section "(elisp) Bidirectional
Display" for more info.
---
* 2020-08-03 10:37:11+03, Teemu Likonen wrote:
> From 4264a1b3561c132343fe6a74e8cf2548e5127c3e Mon Sep 17 00:00:00 2001
> From: Teemu Likonen
> Date: Mon, 3 Aug 2020 10:25:27 +0300
> Subject: [PATCH] Emacs: Force left-to-right display for message headers
Here's slightly
* 2020-08-03 09:13:35+03, Teemu Likonen wrote:
> I believe the header part can be switched to left-to-right mode by
> using function bidi-string-mark-left-to-right.
It seems that adding just a single U+200E LEFT-TO-RIGHT MARK character
(possibly with invisible text property) in the beginn
aracter is made invisible by giving it an
‘invisible’ text property of ‘t’ (*note Invisible Text::).
--
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450
signature.asc
Description: PGP signature
__
our tz-min 0) "Z")
((= tz-min 0)
(format "%s%02d" tz-sign tz-hour))
(t
(format "%s%02d:%02d" tz-sign tz-hour tz-min)))
(error string)))
--
/// Teemu
x27;s too difficult.
I do this: I press "Yes" (to trust "ultimately") but then immediately go
edit ~/.gnupg/trustlist.txt file and put "!" mark in the beginning of
that certificate authority's key fingerprint. It marks that key
untrusted (because I really don
Kevin Foley [2020-02-01T16:29:25-05] wrote:
> I'm getting unexpected results when trying to search for messages
> associated with an email address.
> $ notmuch search to:"exam...@email.com"
> My understanding is this should be treated as a phrase which means
> that exact phrase will be searched
Notmuch Emacs has quite limited status reporting of PGP signature
verification. I'm sure this is nothing new to you but perhaps I found
one more suboptimal case.
When verifying a signature made by an expired key (like this message:
id:87pnfjgnku@fifthhorseman.net) we get red status line: "Unkn
Jameson Graef Rollins [2020-01-14T11:55:36-08] wrote:
> Honestly I don't see the point of any user configuration here. Seems
> likely to only add confusion and possibly improperly deleted messages,
> which would be very bad.
>
> Just use the "deleted" tag only. It's already being used in multipl
Teemu Likonen [2020-01-14T07:01:08+02] wrote:
> notmuch search --exclude=false --output=files \
> --format=text0 SEARCH-TERMS
>
> I think that the "SEARCH-TERMS" part should be configurable, not
> hard-coded.
Obviously there is no need for configuration if
Daniel Kahn Gillmor [2020-01-13T17:28:38-05] wrote:
> So i'm proposing "notmuch purge", which could be something as simple as
> the equivalent of:
>
>notmuch search --output=files --format=text0 tag:deleted | \
> xargs --null --no-run-if-empty rm && \
> notmuch new --no-hooks
>
David Edmondson [2020-01-03T23:17:24Z] wrote:
> On Friday, 2020-01-03 at 09:04:00 -08, Steven Allen wrote:
>
>> It causes this function to fail with:
>>
>> let: Wrong type argument: null, t
>>
>> Support for this was removed from Emacs in April
>> 2019 (5c5e309527e6b582e2c04b83e7af45f3144863ac
Daniel Kahn Gillmor [2019-12-20T13:50:03-05] wrote:
> In notmuch-emacs, i can manually filter the headers by editing the
> reply compose buffer, of course, but it's kind of a pain, and it'd be
> nice to have it done automatically for me.
> Has anyone else considered this use case, or thought abou
William Casarin [2019-11-28T08:13:53-08] wrote:
> These patches bring notmuch-tree more in line with the user experience
> of notmuch-show by adding the x/X bindings.
>
> v2:
> - fix a bug when moving between open messages
> - include M-RET keybinding patch from
> id:20191113225752.26502-1-j.
Teemu Likonen [2019-11-20T10:10:43+02] wrote:
> William Casarin [2019-11-17T14:29:22-08] wrote:
>> These patches bring notmuch-tree more in line with the user experience
>> of notmuch-show by adding the x/X bindings.
>
> I have not tested the patch set yet but I think it i
William Casarin [2019-11-17T14:29:22-08] wrote:
> These patches bring notmuch-tree more in line with the user experience
> of notmuch-show by adding the x/X bindings.
I have not tested the patch set yet but I think it is very good idea to
add x/X keybindings to make tree view work similarly to sh
William Casarin [2019-11-13T14:57:52-08] wrote:
> This is an unbound function that is quite useful. It opens a selected
> thread in notmuch-tree from the current search query.
>
> Signed-off-by: William Casarin
Liked-and-Already-Used-by: Teemu Likonen
--
///
William Casarin [2019-11-13T00:00:04-08] wrote:
> This is an unbound function that is quite useful. It opens a selected
> thread in notmuch-tree from the current search query.
I agree that it is good idea to bind notmuch-tree-from-search-thread
command and thus make it show in "C-h m" *Help* buff
Teemu Likonen [2019-11-12T16:54:35+02] wrote:
> But indeed, a command like "notmuch-search-show-thread-tree" (M-RET,
> C-u RET, C-RET...) would be useful: open current thread directly in
> tree view and with current search terms.
But that is already there (without keybi
William Casarin [2019-11-12T05:59:09-08] wrote:
> Teemu Likonen writes:
>> Seems like the same as pressing Enter to select a thread and then Z
>> to see the thread it in tree view. No?
>
> Yes, but this has performance implications on large threads. Pressing
> Enter will
William Casarin [2019-11-12T05:17:46-08] wrote:
> I find myself doing `c i z Ctrl-v` to open the tree view for a
> specific thread, but perhaps it would make sense if there was a
> default keybind for this.
Seems like the same as pressing Enter to select a thread and then Z to
see the thread it i
Johan Parin [2019-11-11T00:16:17+01] wrote:
> My real frustration lies in the thread view. Typically threads will be
> partially read and I want to read only unread messages.
> I'm trying instead to use the tree view, this seems to me the more
> natural way to view threads. So I immediately do `Z
Teemu Likonen [2019-07-20T08:53:01+03] wrote:
> What WKD support would mean for Notmuch front-end programs?
> So, what is there left for Notmuch and email clients?
Oh, in email clients there is at least one thing to do in order to
support WKD: using gpg's "--sender" opt
Ralph Seichter [2019-07-10T21:58:00+02] wrote:
> 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?
W
David Bremner [2019-07-19T09:19:13-03] wrote:
> I'm not sure I follow you. It seems like this should be the behaviour
> also if the message is tagged with one exclude tag; i.e. it sounds
> like it is working as I expect. Can you explain how 2 exclude tags
> makes a difference for you?
I think "Al
Messages with two or more tags that make then excluded from searches can
make them difficult to find in Notmuch Emacs interface. Let's say we
have config:
[search]
exclude_tags=spam;deleted;
*notmuch-hello* buffer has "All tags" section which lists how many
messages there are for every ta
62 matches
Mail list logo