From: Lars Ingebrigtsen <larsi@gnus.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: David Bremner <david@tethera.net>,
18513@debbugs.gnu.org, Daiki Ueno <ueno@gnu.org>
Subject: bug#18513: 24.3; message-mode sends unencrypted on error
Date: Wed, 25 Sep 2019 15:05:06 +0200 [thread overview]
Message-ID: <87y2ycv859.fsf@gnus.org> (raw)
In-Reply-To: <87lfuem0j5.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 24 Sep 2019 12:49:50 +0200")
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>> It's not difficult to bug out on <#unknown>, but since Message mode
>> buffers mostly free text, doing so would lead to people having their
>> emails fail if they were to type such a thing by hand. MML is only
>> recognised if it's one of the keywords it er recognises.
>
> It seems to me that there's a sensible balance to be struck, where MML
> can carve out a recognizable, predictable space, while still not causing
> unncessary failures.
>
> For example, it could try to interpret every sequence that starts with
> the two characters U+003C LESS-THAN SIGN, U+0023 NUMBER, and ends with
> U+003E GREATER-THAN SIGN, if those characters are all on a single
> line. (does mml handle tags split across multiple lines?)
But that would trigger on this <#no-mml tag> and would annoy people.
> I do note that mml-mode itself offers some help, because it seems to
> apply a different textual style to strings that mml will act on. As
> long as the user can visually distinguish between these textual styles,
> and assuming that the matching rules in mml-mode are precisely aligned
> with the mml-based transformation that happens just before a buffer is
> sent, then the user has some amount of feedback -- but i'm not sure that
> both of those assumptions holds in a buffer during arbitrary editing.
> Does it?
I think so.
But perhaps there should be a secondary level of testing for
encryption-related commands. That is, if you've typed `C-c C-m c p'
(for instance), and then the MML parser doesn't find any encryption tags
in the buffer, then it could ask something like "You indicated that you
wanted this to be encrypted, but it won't be; send anyway?"
I mean, you may have used that command and then removed the "secure"
tag because you changed your mind, so completely refusing to send
probably isn't a good idea.
This warning stuff could be done via a buffer-local variable, I
guess... Although that wouldn't survive a round trip to the drafts
group.
Perhaps a header?
User-Wants-Encryption: yes
?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2019-09-25 13:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-20 6:12 bug#18513: 24.3; message-mode sends unencrypted on error David Bremner
2014-09-29 11:09 ` Daiki Ueno
2014-09-29 12:14 ` David Bremner
2014-09-30 1:36 ` Daiki Ueno
2019-09-23 11:46 ` Lars Ingebrigtsen
2019-09-23 12:18 ` David Bremner
2019-09-23 13:53 ` Lars Ingebrigtsen
2019-09-24 10:49 ` Daniel Kahn Gillmor
2019-09-25 13:05 ` Lars Ingebrigtsen [this message]
2014-10-01 1:28 ` Glenn Morris
2014-10-01 2:32 ` Daiki Ueno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2ycv859.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=18513@debbugs.gnu.org \
--cc=david@tethera.net \
--cc=dkg@fifthhorseman.net \
--cc=ueno@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.