Re: filtering headers from forwarded messages

2021-01-02 Thread Teemu Likonen
* 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 people, but doesn't really satisfy my
> goals.  When i want to forward a message, i want to forward the whole
> message -- multipart, with attachments, etc.  My goal when forwarding is
> to *not* mangle the message, but rather to supply it to the new
> recipient in a parseable way.  I just don't think that most recipients
> need to have access to (for example) the headers that are added by all
> the mail transport agents along my receipt path.  I want them filtered
> for privacy, which i think isn't unreasonable.

OK, that is reasonable. Somehow I thought that you wanted a
pretty-printed message (old inline style) but still valid email form.
But yes, it would be nice to filter headers like "Received", maybe
"DKIM-Signature" and various unofficial headers starting with "X-".

For a quick first step I would probably try running "C-u M-|"
(shell-command-on-region) in Emacs and pipe the forwarded message
through command like this:

formail -I Received -I DKIM-Signature -I X-Whatever

Probably after that I would integrate that shell command call in one
Emacs command and then implement the functionality in Emacs Lisp. But so
far I haven't cared enough.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


Re: filtering headers from forwarded messages

2020-12-30 Thread Teemu Likonen
* 2020-12-24 12:56:09-0500, Daniel Kahn Gillmor wrote:

>> On Wed 2020-01-08 10:25:50 -0500, Daniel Kahn Gillmor wrote:
>>> Thanks for the pointer! it looks like
>>> message-forward-{ignored,included}-headers should do (roughly) what
>>> i want. I'll try them out.

> Hm, it now looks to me like message-forward-ignored-headers isn't
> working since i upgraded to emacs 27.1. In particular, since:
>
> https://lists.defectivebydesign.org/archive/html/emacs-diffs/2018-04/msg00135.html

I don't know any automatic way to remove headers from an email message
that is stored as a MIME part.

When a forwarded message is stored as inline text (setq
message-forward-as-mime nil) then the message is rendered at the time of
composing the message. Unnecessary headers are removed, character
encodings are decoded etc.

When the forwarded message is stored as MIME type "message/rfc822" (setq
message-forward-as-mime t) then the message is meant to be rendered by
the receiver's email program which will decode all necessary headers,
especially MIME headers, convert between character sets and pretty-print
the message's headers and some of the MIME "text/*" parts.

Filtering or editing headers of email MIME part (message/rfc822) can be
tricky: there are message's main headers which tell the "Content-Type"
of the body, and the body can contain different MIME parts with some of
their own headers. If we filter too much or convert between character
sets the message is not proper message/rfc822 part anymore and can't be
rendered correctly.

What about forwarding a message as MIME part which is just "text/plain"
(and not "message/rfc822")? At least this can be done by setting (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. With some hackery one could write a semi-automatic function for
that.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


Re: [PATCH 1/2] Emacs: Add a new function for balancing bidi control chars

2020-08-16 Thread Teemu Likonen
* 2020-08-16 19:28:51+03, Tomi Ollila wrote:

> Good stuff -- implementation looks like port of the php code in 
>
>https://www.iamcal.com/understanding-bidirectional-text
>
> to emacs lisp... anyway nice implementation took be a bit of
> time for me to understand it...

I don't read PHP and didn't try to read that code at all but the idea is
simple enough.

> thoughts
>
> - is it slow to execute it always, pure lisp implementation;
>   (string-match "[\u202a-\u202e]") could be done before that.
>   (if it were executed often could loop with `looking-at`
>(and then moving point based on match-end) be faster...

I don't see any speed issues but if we want to optimize I would create a
new sanitize function which walks just once across the characters
without using regular expressions. But currently I think it's
unnecessary micro optimization.

> - *but* adding U+202C's in `notmuch-sanitize` is doing it too early, as
>   some functions truncate the strings afterwards if those are too long
>   (e.g. `notmuch-search-insert-authors`) so those get lost.. 

Good point. This would mean that we shouldn't do "bidi ctrl char
balancing" in notmuch-sanitize. We should call the new
notmuch-balance-bidi-ctrl-chars function in various places before
inserting arbitrary strings to buffer and before combining such strings
with other strings.

> (what I noticed when looking `notmuch-search-insert-authors` that it uses
>  `length` to check the length of a string -- but that also counts these bidi
>  mode changing "characters" (as one char). `string-width` would be better
>  there -- and probably in many other places.)

Yes, definitely string-width when truncating is based 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
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2] Emacs: Fix notmuch-message-summary-face definition

2020-08-16 Thread Teemu Likonen
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 color) (background light))
   ,@(and (>= emacs-major-version 27) '(:extend t))
   (:background "#f0f0f0"))
  (((class color) (background dark))
   ,@(and (>= emacs-major-version 27) '(:extend t))
   (:background "#303030")))

which produces:

((DISPLAY
  :extend t (:background "#f0f0f0"))
 (DISPLAY
  :extend t (:background "#303030")))

And that is wrong format.

This change fixes the face definition form to produce:

((DISPLAY
  :extend t :background "#f0f0f0")
 (DISPLAY
  :extend t :background "#303030"))

which follows the (DISPLAY . PLIST) format (see above).
---
 emacs/notmuch.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


* 2020-08-16 15:51:14+02, Jonas Bernoulli wrote:

> I would recommend that you
> - switch to using the new format
> - keep the `:extend' setting on its own line
> - keep the `:extend' at the beginning of the list

The new format is the only meaningful change but OK.

> - use `and' instead of `if' because
>   - it is better to use `when' instead of `if' when
> there is no ELSE part

I disagree with that. I think IF is more about return values and WHEN
about longer code with side effects.

>   - it is better to use `and' instead of `when` when
> the form is about the returned value, not some
> side-effect

To me AND is more like multiple condition for "if all the forms are
non-nil" and IF is more about return values. Obviously they are
techinally the same.

Nevertheless, I changed my IF's to AND's so there is now the smallest
possible diff in this version.


diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index babddbb6..04123595 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -275,10 +275,10 @@ there will be called at other points of notmuch 
execution."
 (defface notmuch-message-summary-face
   `class color) (background light))
  ,@(and (>= emacs-major-version 27) '(:extend t))
- (:background "#f0f0f0"))
+ :background "#f0f0f0")
 (((class color) (background dark))
  ,@(and (>= emacs-major-version 27) '(:extend t))
- (:background "#303030")))
+ :background "#303030"))
   "Face for the single-line message summary in notmuch-show-mode."
   :group 'notmuch-show
   :group 'notmuch-faces)
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] Emacs: Fix notmuch-message-summary-face definition

2020-08-16 Thread Teemu Likonen
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 color) (background light))
   ,@(and (>= emacs-major-version 27) '(:extend t))
   (:background "#f0f0f0"))
  (((class color) (background dark))
   ,@(and (>= emacs-major-version 27) '(:extend t))
   (:background "#303030")))

which produces:

((DISPLAY
  :extend t (:background "#f0f0f0"))
 (DISPLAY
  :extend t (:background "#303030")))

And that is wrong format.

This change fixes the face definition form to produce:

((DISPLAY
  (:background "#f0f0f0" :extend t))
 (DISPLAY
  (:background "#303030" :extend t)))

which follows the (DISPLAY PLIST) format (see above).
---
 emacs/notmuch.el | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index babddbb6..16227b5c 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -274,11 +274,9 @@ there will be called at other points of notmuch execution."
 
 (defface notmuch-message-summary-face
   `class color) (background light))
- ,@(and (>= emacs-major-version 27) '(:extend t))
- (:background "#f0f0f0"))
+ (:background "#f0f0f0" ,@(if (>= emacs-major-version 27) '(:extend t
 (((class color) (background dark))
- ,@(and (>= emacs-major-version 27) '(:extend t))
- (:background "#303030")))
+ (:background "#303030" ,@(if (>= emacs-major-version 27) '(:extend t)
   "Face for the single-line message summary in notmuch-show-mode."
   :group 'notmuch-show
   :group 'notmuch-faces)
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] Fix database instructions in test/README: make download-corpus

2020-08-15 Thread Teemu Likonen
---
 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's the correct Makefile target.
If so, this patch should go in.


diff --git a/test/README b/test/README
index 3f54af58..d2a1fdb3 100644
--- a/test/README
+++ b/test/README
@@ -82,7 +82,7 @@ The following command-line options are available when running 
tests:
 Certain tests require precomputed databases to complete. You can fetch these
 databases with
 
-   make download-test-databases
+   make download-corpus
 
 If you do not download the test databases, the relevant tests will be
 skipped.
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 0/2] Balance bidi control chars

2020-08-15 Thread Teemu Likonen
* 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-bidirectional-text

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


[PATCH 1/2] Emacs: Add a new function for balancing bidi control chars

2020-08-15 Thread Teemu Likonen
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 with with character U+202C POP
DIRECTIONAL FORMATTING which pops the mode from the stack. The stack
is per paragraph. A new text paragraph resets the rendering mode
changed by these control characters.

This change adds a new function "notmuch-balance-bidi-ctrl-chars"
which reads its STRING argument and ensures that all push
characters (U+202A, U+202B, U+202D, U+202E) have a pop character
pair (U+202C). The function may add more U+202C characters at the end
of the returned string, or it may remove some U+202C characters. The
returned string is safe in the sense that it won't change the
surrounding bidirectional rendering mode. This function should be used
when sanitizing arbitrary input.
---
 emacs/notmuch-lib.el | 54 
 1 file changed, 54 insertions(+)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 118faf1e..e6252c6c 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -469,6 +469,60 @@ be displayed."
"[No Subject]"
   subject)))
 
+
+(defun notmuch-balance-bidi-ctrl-chars (string)
+  "Balance bidirectional control chars in STRING.
+
+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 and U+202E RIGHT-TO-LEFT OVERRIDE.
+Every mode must be terminated with with character U+202C POP
+DIRECTIONAL FORMATTING which pops the mode from the stack. The
+stack is per paragraph. A new text paragraph resets the rendering
+mode changed by these control characters.
+
+This function reads the STRING argument and ensures that all push
+characters (U+202A, U+202B, U+202D, U+202E) have a pop character
+pair (U+202C). The function may add more U+202C characters at the
+end of the returned string, or it may remove some U+202C
+characters. The returned string is safe in the sense that it
+won't change the surrounding bidirectional rendering mode. This
+function should be used when sanitizing arbitrary input."
+
+  (let ((new-string nil)
+   (stack-count 0))
+
+(cl-flet ((push-char-p (c)
+   ;; U+202A LEFT-TO-RIGHT EMBEDDING
+   ;; U+202B RIGHT-TO-LEFT EMBEDDING
+   ;; U+202D LEFT-TO-RIGHT OVERRIDE
+   ;; U+202E RIGHT-TO-LEFT OVERRIDE
+   (cl-find c '(?\u202a ?\u202b ?\u202d ?\u202e)))
+ (pop-char-p (c)
+   ;; U+202C POP DIRECTIONAL FORMATTING
+   (eql c ?\u202c)))
+
+  (cl-loop for char across string
+  do (cond ((push-char-p char)
+(cl-incf stack-count)
+(push char new-string))
+   ((and (pop-char-p char)
+ (cl-plusp stack-count))
+(cl-decf stack-count)
+(push char new-string))
+   ((and (pop-char-p char)
+ (not (cl-plusp stack-count)))
+;; The stack is empty. Ignore this pop character.
+)
+   (t (push char new-string)
+
+;; Add possible missing pop characters.
+(cl-loop repeat stack-count
+do (push ?\x202c new-string))
+
+(seq-into (nreverse new-string) 'string)))
+
 (defun notmuch-sanitize (str)
   "Sanitize control character in STR.
 
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 0/2] Balance bidi control chars

2020-08-15 Thread Teemu Likonen
These patches continue the ideas written in message:

id:87sgcuuzio@iki.fi

The first patch adds an new function which can be used to balance
Unicode's bidirectional control characters in its string argument. The
seconds patch modifies old "notmuch-sanitize" function so that 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(-)

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


[PATCH 2/2] Emacs: Call notmuch-balance-bidi-ctrl-chars in notmuch-sanitize

2020-08-15 Thread Teemu Likonen
---
 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 input."
   "Sanitize control character in STR.
 
 This includes newlines, tabs, and other funny characters."
-  (replace-regexp-in-string "[[:cntrl:]\x7f\u2028\u2029]+" " " str))
+  (notmuch-balance-bidi-ctrl-chars
+   (replace-regexp-in-string "[[:cntrl:]\x7f\u2028\u2029]+" " " str)))
 
 (defun notmuch-escape-boolean-term (term)
   "Escape a boolean term for use in a query.
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v3] Emacs: Indent first header line only when indentation is turned on

2020-08-15 Thread Teemu Likonen
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 header line if notmuch-show-indent-content
variable is nil.

This change also modifies tests so that they expect this new output
format:
test/emacs-show.expected-output/notmuch-show-indent-thread-content-off
---
 emacs/notmuch-show.el|  5 -
 .../notmuch-show-indent-thread-content-off   | 12 ++--
 2 files changed, 10 insertions(+), 7 deletions(-)


* 2020-08-12 20:38:06-03, David Bremner wrote:
> the test "notmuch-show: disable indentation of thread content (w/
> notmuch-show-toggle-thread-indentation)" in T450-emacs-show needs to be
> adjusted for this change (i.e. it fails as is).

Thanks. This version has updated test output files.


diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 0eb27e33..444b2a45 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -474,7 +474,10 @@ message at DEPTH in the current thread."
   ;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
   ;; the header paragraph as left-to-right text.
   (insert (propertize (string ?\x200e) 'invisible t)))
-(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
+(insert (if notmuch-show-indent-content
+   (notmuch-show-spaces-n (* notmuch-show-indent-messages-width
+ depth))
+ "")
from
" ("
date
diff --git 
a/test/emacs-show.expected-output/notmuch-show-indent-thread-content-off 
b/test/emacs-show.expected-output/notmuch-show-indent-thread-content-off
index 1a06374d..0bb58330 100644
--- a/test/emacs-show.expected-output/notmuch-show-indent-thread-content-off
+++ b/test/emacs-show.expected-output/notmuch-show-indent-thread-content-off
@@ -31,8 +31,8 @@ Cheers,
 [ application/pgp-signature ]
 [ text/plain ]
 [ 4-line signature. Click/Enter to show. ]
- Mikhail Gusarov  (2009-11-17) (inbox signed unread)
-  Lars Kellogg-Stedman  (2009-11-17) (inbox signed)
+Mikhail Gusarov  (2009-11-17) (inbox signed unread)
+Lars Kellogg-Stedman  (2009-11-17) (inbox signed)
 Subject: Re: [notmuch] Working with Maildir storage?
 To: Mikhail Gusarov 
 Cc: notmuch@notmuchmail.org
@@ -57,9 +57,9 @@ It doesn't look like the patch is in git yet.
 [ application/pgp-signature ]
 [ text/plain ]
 [ 4-line signature. Click/Enter to show. ]
-   Mikhail Gusarov  (2009-11-17) (inbox unread)
-   Keith Packard  (2009-11-17) (inbox unread)
-Lars Kellogg-Stedman  (2009-11-18) (inbox signed 
unread)
+Mikhail Gusarov  (2009-11-17) (inbox unread)
+Keith Packard  (2009-11-17) (inbox unread)
+Lars Kellogg-Stedman  (2009-11-18) (inbox signed unread)
 Subject: Re: [notmuch] Working with Maildir storage?
 To: Keith Packard 
 Cc: notmuch@notmuchmail.org
@@ -79,4 +79,4 @@ missing "#include " (for the uint32_t on line 466).
 [ application/pgp-signature ]
 [ text/plain ]
 [ 4-line signature. Click/Enter to show. ]
- Carl Worth  (2009-11-18) (inbox unread)
+Carl Worth  (2009-11-18) (inbox unread)
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Sanitize bidi control chars

2020-08-10 Thread Teemu Likonen
* 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 (pop)
> U+202D LEFT-TO-RIGHT OVERRIDE (push)
> U+202E RIGHT-TO-LEFT OVERRIDE (push)
>
> Or we could even try to be clever and count those characters and then
> insert or remove some of them so that there are as many "push"
> characters as "pop" characters.

Below is an example Emacs Lisp function to balance those "push" and
"pop" bidi control chars. This kind of code could be used to sanitize
message headers or any arbitrary text coming from user.

I'm not even sure if such thing should be done in Emacs or in lower
level Notmuch code. Anyway, I tried to add it to notmuch-sanitize
function. Now Tomi's message didn't switch direction of other text
anymore (in notmuch-search-mode buffer).


(defun notmuch-balance-bidi-ctrl-chars (string)
  (let ((new nil)
(stack-count 0))

(cl-flet ((push-char-p (c)
;; U+202A LEFT-TO-RIGHT EMBEDDING
;; U+202B RIGHT-TO-LEFT EMBEDDING
;; U+202D LEFT-TO-RIGHT OVERRIDE
;; U+202E RIGHT-TO-LEFT OVERRIDE
(cl-find c '(?\x202a ?\x202b ?\x202d ?\x202e)))
  (pop-char-p (c)
;; U+202C POP DIRECTIONAL FORMATTING
(eql c ?\x202c)))

  (cl-loop
   for char across string
   do (cond ((push-char-p char)
 (cl-incf stack-count)
 (push char new))
((and (pop-char-p char)
  (cl-plusp stack-count))
 (cl-decf stack-count)
 (push char new))
((and (pop-char-p char)
  (not (cl-plusp stack-count)))
 ;; The stack is empty. Ignore this pop char.
 )
(t (push char new)

;; Add missing pops.
(cl-loop
 repeat stack-count
 do (push ?\x202c new))

(seq-into (nreverse new) 'string)))



-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


Re: [PATCH v5] Emacs: Ensure left-to-right display for message headers

2020-08-10 Thread Teemu Likonen
* 2020-08-09 23:12:28+03, utf wrote:

> How about this =D

> From: contains U+202E (LEFT-TO-RIGHT OVERRIDE) (in
> =?utf-8?Q?T=E2=80=AEomi?=)

Indeed message's header fields can contain such override characters. The
override mode should be terminated with U+202C POP DIRECTIONAL
FORMATTING within the same header field. That POP character pops the
override mode from the direction mode stack and returns to the previous
mode. Those characters can mess any text badly when not used in
controlled pairs of "push" and "pop".

I'll write "abc abc abc" series but the middle "abc" have RIGHT-TO-LEFT
OVERRIDE before "a" and POP DIRECTIONAL FORMATTING after "c". In Emacs
try using C-f and C-b commands to move the cursor above the text:

abc ‮abc‬ abc

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 (pop)
U+202D LEFT-TO-RIGHT OVERRIDE (push)
U+202E RIGHT-TO-LEFT OVERRIDE (push)

Or we could even try to be clever and count those characters 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
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2] Emacs: Indent first header line only when indentation is turned on

2020-08-10 Thread Teemu Likonen
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 header line if notmuch-show-indent-content
variable is nil.
---
 emacs/notmuch-show.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)


* 2020-08-10 11:19:10+01, David Edmondson wrote:
>> +(insert (notmuch-show-spaces-n
>> + (if notmuch-show-indent-content
>> + (* notmuch-show-indent-messages-width depth)
>> +   0))
>
> Couldn't you also elide the call to `notmuch-show-spaces-n'?

Indeed.



diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 0eb27e33..444b2a45 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -474,7 +474,10 @@ message at DEPTH in the current thread."
   ;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
   ;; the header paragraph as left-to-right text.
   (insert (propertize (string ?\x200e) 'invisible t)))
-(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
+(insert (if notmuch-show-indent-content
+   (notmuch-show-spaces-n (* notmuch-show-indent-messages-width
+ depth))
+ "")
from
" ("
date
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] Emacs: Indent first header line only when indentation is turned on

2020-08-09 Thread Teemu Likonen
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 header line if notmuch-show-indent-content
variable is nil.
---
 emacs/notmuch-show.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 0eb27e33..2310017a 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -474,7 +474,10 @@ message at DEPTH in the current thread."
   ;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
   ;; the header paragraph as left-to-right text.
   (insert (propertize (string ?\x200e) 'invisible t)))
-(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
+(insert (notmuch-show-spaces-n
+(if notmuch-show-indent-content
+(* notmuch-show-indent-messages-width depth)
+  0))
from
" ("
date
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 2/3] emacs/tree: enable moving to next thread in search results

2020-08-07 Thread Teemu Likonen
* 2020-04-23 17:07:04-07, William Casarin wrote:

> which I will send in a v2 once this gets some Concept ACKs. Feel free
> to test in the meantime! Hopefully this makes tree-mode more usable
> for people who only use notmuch-show.
>
> Basic usage following the previous emacs/tree improvements:
>
> Press M-Enter on a thread from search-mode to enter that thread in
> notmuch-tree mode. With these patches, M-n and M-p move between search
> result threads, and A works as you would expect as well (archive and
> then move to next thread)

This is a good improvement and 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
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v5] Emacs: Ensure left-to-right display for message headers

2020-08-06 Thread Teemu Likonen
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 "(elisp) Bidirectional
Display" for more info.
---
 emacs/notmuch-show.el | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)


As the commit description says this version inserts U+200E
LEFT-TO-RIGHT MARK only if the first header line (From header)
contains a right-to-left character.

This version is probably friendlier to the current test files which
don't expect to see U+200E LEFT-TO-RIGHT MARK in the output.


diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index c9170466..0eb27e33 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -466,10 +466,16 @@ unchanged ADDRESS if parsing fails."
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
-  (let ((start (point)))
+  (let ((start (point))
+   (from (notmuch-sanitize
+  (notmuch-show-clean-address (plist-get headers :From)
+(when (string-match "\\cR" from)
+  ;; If the From header has a right-to-left character add
+  ;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
+  ;; the header paragraph as left-to-right text.
+  (insert (propertize (string ?\x200e) 'invisible t)))
 (insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
-   (notmuch-sanitize
-(notmuch-show-clean-address (plist-get headers :From)))
+   from
" ("
date
") ("
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v4] Emacs: Force left-to-right display for message headers

2020-08-06 Thread Teemu Likonen
* 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 beginning, otherwise don't bother. This way those tests
> probably won't be affected. What do you think?
>
> Below is a quick try on the top of my previous (v4) patch. I'll do a
> proper patch later.

Better version which is not based on any patches but the Git version:


diff --git c/emacs/notmuch-show.el w/emacs/notmuch-show.el
index c9170466..0eb27e33 100644
--- c/emacs/notmuch-show.el
+++ w/emacs/notmuch-show.el
@@ -466,10 +466,16 @@ unchanged ADDRESS if parsing fails."
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
-  (let ((start (point)))
+  (let ((start (point))
+   (from (notmuch-sanitize
+  (notmuch-show-clean-address (plist-get headers :From)
+(when (string-match "\\cR" from)
+  ;; If the From header has a right-to-left character add
+  ;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
+  ;; the header paragraph as left-to-right text.
+  (insert (propertize (string ?\x200e) 'invisible t)))
 (insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
-   (notmuch-sanitize
-(notmuch-show-clean-address (plist-get headers :From)))
+   from
" ("
date
") ("

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


Re: [PATCH v4] Emacs: Force left-to-right display for message headers

2020-08-06 Thread Teemu Likonen
* 2020-08-06 09:04:50-03, David Bremner wrote:

> This causes 10 tests to fail for me. At a guess, the added
> LEFT-TO-RIGHT MARK should probably be stripped out in the test
> framework. Either that or added to test output files. The latter
> sounds easy to miss when editing.

For the first time I ran the tests and got over 60 test fails. :-) I'm
probably doing something wrong and have to study the test framework
better.

I don't know which tests are related to the U+200E LEFT-TO-RIGHT MARK
patch but if test output files are representing the content of
notmuch-show-mode buffer then I think U+200E belongs in those expected
output files, even if the character is invisible.

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 beginning, otherwise don't bother. This way those tests
probably won't be affected. What do you think?

Below is a quick try on the top of my previous (v4) patch. I'll do a
proper patch later.


diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
index 6548891f..6b7d70d9 100644
--- i/emacs/notmuch-show.el
+++ w/emacs/notmuch-show.el
@@ -465,22 +465,23 @@ unchanged ADDRESS if parsing fails."
 
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
-  (let ((start (point)))
-(insert (propertize (string ?\x200e) 'invisible t)
-   ;; Add invisible U+200E LEFT-TO-RIGHT MARK character (see
-   ;; above) to force the header paragraph as left-to-right
-   ;; text even if the header content started with
-   ;; right-to-left characters.
-   (notmuch-show-spaces-n (* notmuch-show-indent-messages-width depth))
-   (notmuch-sanitize
-(notmuch-show-clean-address (plist-get headers :From)))
-   " ("
-   date
-   ") ("
-   (notmuch-tag-format-tags tags tags)
-   ")\n")
+  (let ((start (point))
+(from (notmuch-sanitize
+   (notmuch-show-clean-address (plist-get headers :From)
+(insert (when (string-match "\\cR" from)
+  ;; If the From header has a right-to-left character add
+  ;; invisible U+200E LEFT-TO-RIGHT MARK character which
+  ;; forces the header paragraph as left-to-right text.
+  (propertize (string ?\x200e) 'invisible t))
+(notmuch-show-spaces-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)))
 
 (defun notmuch-show-insert-header (header header-value)
   "Insert a single header."


-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


[PATCH v4] Emacs: Force left-to-right display for message headers

2020-08-05 Thread Teemu Likonen
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 "(elisp) Bidirectional
Display" for more info.

Reviewed-by: David Edmondson 
---
 emacs/notmuch-show.el | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index c9170466..6548891f 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -466,9 +466,14 @@ unchanged ADDRESS if parsing fails."
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
+(insert (propertize (string ?\x200e) 'invisible t)
+   ;; Add invisible U+200E LEFT-TO-RIGHT MARK character (see
+   ;; above) to force the header paragraph as left-to-right
+   ;; text even if the header content started with
+   ;; right-to-left characters.
+   (notmuch-show-spaces-n (* notmuch-show-indent-messages-width depth))
(notmuch-sanitize
 (notmuch-show-clean-address (plist-get headers :From)))
" ("
date
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v3] Emacs: Force left-to-right display for message headers

2020-08-05 Thread Teemu Likonen
* 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 "From").
>
>  2. Add invisible characters that force left-to-right text for the
> paragraph. Character U+200E LEFT-TO-RIGHT MARK is meant for
> controlling exactly that.

 3. Bad option: (setq bidi-paragraph-direction 'left-to-right) for the
whole notmuch-show buffer. This is not good idea because also the
message body is forced to left-to-right direction (even if it
    contained right-to-left text).

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


Re: [PATCH v3] Emacs: Force left-to-right display for message headers

2020-08-05 Thread Teemu Likonen
* 2020-08-05 09:45:23+01, David Edmondson wrote:

> I've no idea if this is the appropriate approach to addressing this, but
> the resulting behaviour is obviously an improvement over what happens
> now.

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 "From").

 2. Add invisible characters that force left-to-right text for the
paragraph. Character U+200E LEFT-TO-RIGHT MARK is meant for
controlling exactly that.

My patch implements the option 2 and...

> It would make sense to add some commentary to the code as well as the
> commit message explaining the reason for inserting the seemingly
> arbitrary character.

...it has at least comment

; U+200E LEFT-TO-RIGHT MARK

in 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.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


[PATCH v3] Emacs: Force left-to-right display for message headers

2020-08-04 Thread Teemu Likonen
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.
---

> This message can be applied with "git am --scissors".

Sorry, it doesn't apply with "git am". Maybe PGP/MIME or
quoted-printable encoding messed it up. This time I try with "git
send-email".


 emacs/notmuch-show.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index c9170466..c45db57d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -466,9 +466,10 @@ unchanged ADDRESS if parsing fails."
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
+(insert (propertize (string ?\x200e) 'invisible t) ; U+200E LEFT-TO-RIGHT 
MARK
+   (notmuch-show-spaces-n (* notmuch-show-indent-messages-width depth))
(notmuch-sanitize
 (notmuch-show-clean-address (plist-get headers :From)))
" ("
date
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2] Emacs: Force left-to-right display for message headers

2020-08-04 Thread Teemu Likonen
* 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 better patch with (string ?\x200e) instead of (string
#x200e) because STRING function wants characters as argument.
Conceptually:

  ?\x200e  = character
  #x200e   = integer

In the current Emacs they are both integers (8206).

This message can be applied with "git am --scissors".

--- 8< 
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.
---
 emacs/notmuch-show.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index c9170466..c45db57d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -466,9 +466,10 @@ unchanged ADDRESS if parsing fails."
 (defun notmuch-show-insert-headerline (headers date tags depth)
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
+(insert (propertize (string ?\x200e) 'invisible t) ; U+200E LEFT-TO-RIGHT 
MARK
+   (notmuch-show-spaces-n (* notmuch-show-indent-messages-width depth))
(notmuch-sanitize
 (notmuch-show-clean-address (plist-get headers :From)))
    " ("
date
-- 
2.20.1




-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


Re: Message headers in right-to-left mode in Emacs notmuch-show-mode

2020-08-03 Thread Teemu Likonen
* 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 beginning of message
header paragraph will do. The attached (inline) patch does it.

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

Insert 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.
---
 emacs/notmuch-show.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index c9170466..87f68bc8 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -467,7 +467,8 @@ unchanged ADDRESS if parsing fails."
   "Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread."
   (let ((start (point)))
-(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width depth))
+(insert (propertize (string #x200e) 'invisible t) ; U+200E LEFT-TO-RIGHT MARK
+	(notmuch-show-spaces-n (* notmuch-show-indent-messages-width depth))
 	(notmuch-sanitize
 	 (notmuch-show-clean-address (plist-get headers :From)))
 	" ("
-- 
2.20.1


-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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


Message headers in right-to-left mode in Emacs notmuch-show-mode

2020-08-03 Thread Teemu Likonen
Emacs uses setting bidi-paragraph-direction=nil by default which means
that paragraph's text direction can change automatically, for example:
right-to-left. A quote from the variable's description:

If this is nil (the default), the direction of each paragraph is
determined by the first strong directional character of its text.

So, in notmuch-show-mode the message header paragraph is switched to
right-to-left mode if headers contain a "strong directional"
right-to-left character.

The result can be seen in the attached jpg image which displays part of
the message 
<https://lists.debian.org/debian-devel/2020/06/msg00099.html>.

I think message headers should always be in left-to-right mode but
message contents should follow the Emacs default (choose automatically
from the content). I believe the header part can be switched to
left-to-right mode by using function bidi-string-mark-left-to-right.
Below is a relevant quote from Emacs Lisp reference manual.

Unfortunately I don't know Notmuch Emacs code (at least not yet). So
this message is mainly for documenting the current behavior.


Emacs Lisp reference manual, section "Bidirectional Display".

https://www.gnu.org/software/emacs/manual/html_node/elisp/Bidirectional-Display.html#Bidirectional-Display


Bidirectional reordering can have surprising and unpleasant effects
when two strings with bidirectional content are juxtaposed in a
buffer, or otherwise programmatically concatenated into a string of
text. A typical problematic case is when a buffer consists of
sequences of text fields separated by whitespace or punctuation
characters, like Buffer Menu mode or Rmail Summary Mode. Because the
punctuation characters used as separators have “weak
directionality”, they take on the directionality of surrounding
text. As result, a numeric field that follows a field with
bidirectional content can be displayed _to the left_ of the
preceding field, messing up the expected layout. There are several
ways to avoid this problem:

   − Append the special character U+200E LEFT-TO-RIGHT MARK, or LRM,
 to the end of each field that may have bidirectional content,
 or prepend it to the beginning of the following field. The
 function ‘bidi-string-mark-left-to-right’, described below,
 comes in handy for this purpose. (In a right-to-left paragraph,
 use U+200F RIGHT-TO-LEFT MARK, or RLM, instead.) This is one of
 the solutions recommended by the UBA.

   − Include the tab character in the field separator. The tab
 character plays the role of “segment separator” in
 bidirectional reordering, causing the text on either side to be
 reordered separately.

   − Separate fields with a ‘display’ property or overlay with a
 property value of the form ‘(space . PROPS)’ (*note Specified
 Space::). Emacs treats this display specification as a
 “paragraph separator”, and reorders the text on either side
 separately.

 -- Function: bidi-string-mark-left-to-right string

 This function returns its argument STRING, possibly modified,
 such that the result can be safely concatenated with another
 string, or juxtaposed with another string in a buffer, without
 disrupting the relative layout of this string and the next one
 on display. If the string returned by this function is
 displayed as part of a left-to-right paragraph, it will always
 appear on display to the left of the text that follows it. The
 function works by examining the characters of its argument, and
 if any of those characters could cause reordering on display,
 the function appends the LRM character to the string. The
 appended LRM character 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
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: timezone in notmuch

2020-04-15 Thread Teemu Likonen
Tomi Ollila [2020-04-15T23:17:32+03] wrote:

> I use this:
>
> https://github.com/domo141/nottoomuch/blob/master/build/01-date-local.patch
>
> I've been thinking if some hook could be added to notmuch-emacs so
> that such a custom date mangling can be done outside of the
> notmuch-emacs source...

Formerly I used Emacs Gnus and its hook to change the date. For this
discussion I adapted the idea to Notmuch. The code below is based on
idea that after article display there is a hook which can do anything
user wants. I wanted ISO 8601 date.



;; Add a hook for changing article's date string.
(add-hook 'some-article-display-hook 'tl-notmuch-custom-article-date)


(defmacro notmuch-narrow-to-article-headers ( body)
  ;; Implement macro which uses NARROW function to narrow current buffer
  ;; to article's headers only.
  `(progn ,@body))


(defun tl-notmuch-custom-article-date ()
  (save-excursion
(save-match-data
  (notmuch-narrow-to-article-headers
   (goto-char (point-min))
   (when (re-search-forward "^Date: \\(.+\\)$" nil t)
 (let ((inhibit-read-only t))
   (replace-match (tl-message-date-string-iso
   (match-string-no-properties 1))
  nil t nil 1)))


(defun tl-message-date-string-iso (string)
  ;; Parse message date STRING and return ISO 8601 time string.
  (require 'parse-time)
  (condition-case nil
  (let* ((date-list (parse-time-string string))
 (year (nth 5 date-list))
 (month (nth 4 date-list))
 (day (nth 3 date-list))
 (hour (nth 2 date-list))
 (min (nth 1 date-list))
 (sec (nth 0 date-list))
 (tz-total-sec (nth 8 date-list)))

(format "%04d-%02d-%02dT%02d:%02d:%02d%s"
year month day hour min sec
(if (not tz-total-sec)
""
  (let* ((tz-sign (if (>= tz-total-sec 0) "+" "-"))
 (tz-hour (truncate (abs tz-total-sec) 3600))
 (tz-min (truncate (- (abs tz-total-sec)
  (* tz-hour 3600))
   60)))
(cond
 ((= tz-hour 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 Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Ultimate trust

2020-03-21 Thread Teemu Likonen
Tomas Nordin [2020-03-21T15:37:36+01] wrote:

> This is probably a dumb question and not really an issue for Notmuch.

Excellent questions but partly difficult to answer.

> But it is when using notmuch (through emacs) I get this Gnome pop-up.
> See attached image. Some senders are attaching some sort of signature
> that I get to trust or cancel.

The sender's mail client has used gpgsm or similar program to digitally
sign the message content. The sender's key that made the message
signature has been certified by some certificate authority. And you are
asked if you trust this certificate authority to certify other's keys.

> What does people do in this case, I tend to cancel it. How should I
> relate to the question. How do I know if I could ultimately trust
> something as asked.

That is the difficult part. The right answer is probably that user
should carefully check the certificate authority's key fingerprint,
compare it to the fingerprint that the authority has published somewhere
else, study the certificate authority's reputation in certifying
people's keys, or something like that.

And almost nobody does that because it'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't know). Then: "gpgconf --reload
gpg-agent".

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Searching for an Exact Email Address

2020-02-01 Thread Teemu Likonen
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 for, is this correct?

Double quotes are special characters in your shell and it interprets
them so that notmuch doesn't get them. There are different ways in shell
to escape special characters:

to:\"exam...@email.com\"
'to:"exam...@email.com"'

The shell built-in "set" is useful for testing parameters:

$ set -- to:"exam...@email.com" to:\"exam...@email.com\"
$ printf '%s\n' "$@"
to:exam...@email.com
to:"exam...@email.com"

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Suboptimal status line for PGP signature verification

2020-01-25 Thread Teemu Likonen
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: "Unknown
key [...] or unsupported algorithm". The key is not unknown to me; it is
in my keyring. The signature is good but the signing subkey is just
expired.

In a better world we would probably have more information in the status
line: (1) good or bad signature and (2) key's validity: full, marginal,
expired key, tofu conflict, never...

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: proposing "notmuch purge"

2020-01-14 Thread Teemu Likonen
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 multiple
> place to mean that the message should be deleted.

That is indeed simple. Here is just one more point of view for deleting.

I like "trashcan with expiry time": I manually mark some messages
"deleted" which make them disappear because "deleted" messages are
excluded from searches. The messages are really deleted when they are
older than 30 days.

So I tend to prefer user's own search terms in "notmuch purge". My purge
command would be something like this:

notmuch purge --no-db-update \
"(" tag:deleted OR tag:spam ")" AND date:..30days

In my system that kind of operation runs automatically in pre-new hook.
Then new messages are fetched from server and the database is updated.

If "deleted" is hard-coded tag name for unconditional purging operation
the trashcan functionality can be built with some other tag like
"trash".

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: proposing "notmuch purge"

2020-01-13 Thread Teemu Likonen
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 purging is just a
command that user runs manually or in his own scripts: "notmuch purge
SEARCH-TERMS". Configuration is needed if some (mail client) operation
does purging automatically.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: proposing "notmuch purge"

2020-01-13 Thread Teemu Likonen
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
>
> (credit for the pipeline above goes to anarcat, in Cc; i added the
> "notmuch new --no-hooks" part, because i would want the items gone from
> the db as well)

I agree with the proposal but I would like to add one important point to
the discussion and semantics. If the implementation goes through
"notmuch search" we should understand what search.exclude_tags does.

Let's say a user has this settings: "search.exclude_tags=deleted;spam".
Then "notmuch search tag:deleted" will not find messages which have both
of the excluded tags, "deleted" and "spam". We would need "notmuch
search --exclude=false tag:deleted" to really find all messages with
tag:deleted. So here's the search semantics I propose:

notmuch search --exclude=false --output=files \
--format=text0 SEARCH-TERMS

I think that the "SEARCH-TERMS" part should be configurable, not
hard-coded. A user could have setting like
"search.purge_tags=deleted;spam" and that would lead to search terms
"tag:deleted OR tag:spam" in the purge operation.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: don't start processes stopped

2020-01-08 Thread Teemu Likonen
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) because it never
>> worked correctly (apparently).
>>
>> This also shouldn't be necessary as sentinels will not be called
>> unless emacs is idle or waiting for input. Therefore, the
>> `process-put' calls immediately following the `make-process' call
>> should always complete before the sentinel is first called.
>
> Reviewed-by: David Edmondson 

And tested by me: the patch fixes the key retrieval problem.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: filtering headers from forwarded messages

2019-12-30 Thread Teemu Likonen
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 about how to make
> it easy/simple to do the right thing when using Notmuch? Are there
> other factors that are worth considering?

The underlying message-mode has these variables:

message-forward-as-mime
message-forward-before-signature
message-forward-ignored-headers
message-forward-included-headers
message-forward-show-mml

I have not studied those very closely but at least I know that when
-as-mime is nil user can use -included-headers to set what headers user
wants to include.


-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v2 0/8] Port notmuch-show's x/X bindings to notmuch-tree

2019-12-04 Thread Teemu Likonen
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...@jb55.com

A minor inconvenience: In "show" mode X key
(notmuch-show-archive-thread-then-exit) archives, exits and moves the
cursor above the next thread in the list. In "tree" mode this new X key
(notmuch-tree-archive-thread-then-exit) does not move the cursor to the
next thread.


-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 0/7] Port notmuch-show's x/X bindings to notmuch-tree

2019-11-27 Thread Teemu Likonen
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 is very good idea
> to add x/X keybindings to make tree view work similarly to show view.

Now I have been using the patch set some days and it works as expected.
Usually I open a thread with M-TAB (notmuch-tree-from-search-thread) and
if I then find thread uninteresting I hit "X"
(notmuch-tree-archive-thread-then-exit) and continue browsing the thread
list.

I'm quite experienced with Emacs Lisp (and Common Lisp) but I don't know
Notmuch Emacs code to give educated comments on this patch set's code.
From user's side it works and I support this feature. Thanks!

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 0/7] Port notmuch-show's x/X bindings to notmuch-tree

2019-11-20 Thread Teemu Likonen
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 show view.
Perhaps I will try the patch set later. Would you mind sending a fixed
version of "PATCH 5/7" (see id:87mucuay8p@jb55.com)?

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: bind M-RET to notmuch-tree-from-search-thread

2019-11-13 Thread Teemu Likonen
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 

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: bind C-u Z to notmuch-tree-from-search-thread

2019-11-13 Thread 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* buffer. I prefer M-RET
because
  - it is quick to type
  - it feels like variant of RET (notmuch-search-show-thread).

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unread handling

2019-11-12 Thread Teemu Likonen
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 keybinding):

(defun notmuch-tree-from-search-thread ()
  "Show the selected thread with notmuch-tree"
  (interactive)
  (notmuch-tree (notmuch-search-find-thread-id)
notmuch-search-query-string
nil
(notmuch-prettify-subject (notmuch-search-find-subject))
t))

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unread handling

2019-11-12 Thread Teemu Likonen
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 load all of the messages. Opening tree view with the thread
> id is much faster, as it only loads the messages when you click them
> from what I can tell.

Ah, I see. I have "notmuch-show-only-matching-messages" variable non-nil
and my daily searches have some limiting terms like "tag:unread" or
"date:90days.." so RET (notmuch-search-show-thread) command won't show
very large number of messages.

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.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unread handling

2019-11-12 Thread Teemu Likonen
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 in tree view. No?

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unread handling

2019-11-11 Thread Teemu Likonen
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' whenever I enter
> a thread. I would like to have the option to enter tree view
> automatically for a thread from the search buffer. Is it possible?

It seems to me that using search term tag:unread will help you. Try this
in the *hello* buffer:

z tag:unread

You'll go directly to tree view and unread messages will show with
normal colours and read messages with grey colour. Commands "n" and "p"
will skip over read messages ("N" and "P" won't). You can configure
saved searches to start with tree view.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch support for GnuPG Web Key Directory

2019-07-20 Thread Teemu Likonen
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" option with the sender's email
address when signing a message (if that email user ID is in sender's
key). The "--sender" option includes that email in the signature so WKD
lookup can use that. More information in gpg(1) manual page, especially
in options "--sender" and "--auto-key-retrieve".

I recently added Emacs's message-mode (and epg) that very feature. It's
in the development branch (master) since commit
emacs-26.1-6339-g74579d3d2b (2019-07-13).

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=74579d3d2bb82f300a6f2d81b7b559f0a24061db

Variable mml-secure-openpgp-sign-with-sender has to be non-nil.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch support for GnuPG Web Key Directory

2019-07-19 Thread Teemu Likonen
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?

What WKD support would mean for Notmuch front-end programs? I know that
WKD is a key locating technology for GnuPG or OpenPGP keys in general
but it seems to me that it is GnuPG's job. With "auto-key-locate"
settings in place a command like

gpg --encrypt --recipient person@domain

would include WKD key lookup if the recipient's key isn't found from the
local keyring. Also, signature checking with "auto-key-retrieve" option
in GnuPG 2.2.17 will prefer WKD over keyservers (by default).

So, what is there left for Notmuch and email clients? Do you mean a
button like "Locate message sender's key" which would run a command like
this:

gpg --auto-key-locate clear,nodefault,wkd,keyserver \
--locate-key person@domain

(Or use --locate-external-key which is in GnuPG 2.2.17.)

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Emacs: UI problems with messages excluded by several tags

2019-07-19 Thread Teemu Likonen
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 "All tags" section should show every tags and the count
regardless of exclude settings. It does that now if there is only one
excluding tag for a message. Messages are hidden if there are more
excluding tags.

Let's test:

$ notmuch config set search.exclude_tags exclude-1 exclude-2

Now add "exclude-1" tag for some message and it will show in "All tags"
section with count 1.

All tags: [hide]

   1 exclude-1

Now add also "exclude-2" tag for the same massage and see the "All tags"
section again.

All tags: [hide]

   [neither exclude-1 nor exclude-2 here]

I think the section should show both tags and when a tag clicked it
should show all messages with that tag.

All tags: [hide]

   1 exclude-1  1 exclude-2

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Emacs: UI problems with messages excluded by several tags

2019-07-18 Thread Teemu Likonen
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 tag. However, if a message has two
different excluding tags (like "spam" and "deleted") then that message
is not shown anywhere in the "All tags" list. The message count does not
show it and the message does not show in the search when user clicks the
tag.

My opinion:

 1. "notmuch count" command should have --exclude option like "notmuch
search" and Emacs interface should use --exclude=false in "All tags"
section.
 
 2. When clicking a tag in "All tags" section the search operation
should use --exclude=false because in these searches user (most
likely) wants all messages by a tag regardless of other excluding
tags.

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch