GNU bug report logs - #18513
24.3; message-mode sends unencrypted on error

Previous Next

Package: emacs;

Reported by: David Bremner <david <at> tethera.net>

Date: Sat, 20 Sep 2014 06:14:01 UTC

Severity: normal

Found in version 24.3

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, David Bremner <david <at> tethera.net>
Cc: 18513 <at> debbugs.gnu.org, Daiki Ueno <ueno <at> gnu.org>
Subject: bug#18513: 24.3; message-mode sends unencrypted on error
Date: Tue, 24 Sep 2019 12:49:50 +0200
[Message part 1 (text/plain, inline)]
On Mon 2019-09-23 15:53:50 +0200, Lars Ingebrigtsen wrote:
> David Bremner <david <at> tethera.net> writes:
>
>> I don't think the fact that we can't do a perfect job is a reason not to
>> improve the error checking. There are many errors that can be detected
>> that currently are not. Is erroring on an unknown mml tag (which
>> nonethless actually looks like a tag) actually difficult?
>
> 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 since the goal of this bug report, afaict, is to reduce user error
when composing and sending mail in mml-mode, UI/UX feedback choices are
pretty critical to making this work right.

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?

Even better UX would be a distinct textual style between a
valid/actionable mml-tag and an mml-tag that has an error in it, so that
the user oomposing the buffer has immediate feedback about potentially
problematic strings.

Thanks for maintaining MML!

       --dkg
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 5 years and 291 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.