From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Lars Ingebrigtsen <larsi@gnus.org>, David Bremner <david@tethera.net>
Cc: 18513@debbugs.gnu.org, Daiki Ueno <ueno@gnu.org>
Subject: bug#18513: 24.3; message-mode sends unencrypted on error
Date: Tue, 24 Sep 2019 12:49:50 +0200 [thread overview]
Message-ID: <87lfuem0j5.fsf@fifthhorseman.net> (raw)
In-Reply-To: <87ftkn6rv5.fsf@gnus.org>
[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]
On Mon 2019-09-23 15:53:50 +0200, Lars Ingebrigtsen wrote:
> David Bremner <david@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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2019-09-24 10:49 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 [this message]
2019-09-25 13:05 ` Lars Ingebrigtsen
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=87lfuem0j5.fsf@fifthhorseman.net \
--to=dkg@fifthhorseman.net \
--cc=18513@debbugs.gnu.org \
--cc=david@tethera.net \
--cc=larsi@gnus.org \
--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.