Re: libnettle/libhogweed WIP

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Thu, 20 Apr 2017 17:59:51 +0200
> 
> These are encryption primitives.  Stuffing code that guesses What I Mean
> into these primitives doesn't seem like the most productive way to
> proceed.  If somebody later wants to add a DWIM framework on top of
> these primitives (to, say, automatically encrypt everything that Emacs
> saves), that's a different thing.
> 
> But the primitives themselves should, in my opinion, be functional and
> predictable: You give them explicit inputs and you always get the same
> result back.

You can have predictability if you bind coding-system-for-write to
whatever you want.  Just like you do with file and process I/O.

> Encryption is also often used in conjunction with various protocols, and
> (as opposed to saving files locally) the local user's preferences are
> irrelevant to how the octets are supposed to be encoded on the wire.

How is this different from sending the stiff unencrypted via the same
protocols?

Once again, please tell why the considerations you raise do NOT apply
to write-region, insert-file-contents, send-string etc., because if
they do apply, we already have very reasonable solutions for them,
which are well-tested by time and many users.  In the I/O department,
experience shows that most users and programmers don't want/need this
level of control, so the heuristics that does TRT without burdening
users/programmers is a Good Thing.