Re: Noob dumb question (extending emacs)

[Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>]

Jean Louis wrote:

>> Yes, commands that are run very often and have no security
>> implications one can maybe be cool with a downgrade for
>> that reason, but commands that are used seldom and have
>> security implications, nope, that should be at the level of
>> the CLI alternative _or_ one should simply use the
>> CLI alternative.
>
> In science, if there is "security implication" then it has
> to be proven.

Well, this is gmane.emacs.help. And you don't have to prove
everything (obvious things) in science.

> That is why breaking crypto requires a proof which is
> usually program or exploit that breaks it, not just
> a theoretical statement.

OK, if you say so, but in general theoretical (or formal)
proofs rank much higher than "try and see" experiments which
only show that the observed outcome is one possibility.

Often if something is possible that is well-known since it has
been tested on the field, for fun or pleasure, long before it
reaches the world of PhD students ...

> It is not reasonable within Emacs environment and especially
> on this mailing list to keep recommending general
> CLI alternatives.

It is, if there is no alternative in Emacs that is at the same
level.

> What about cp, mv, we use it in Dired, should we start now
> recommending using external "cp" instead of Dired one?

Indeed, if the Dired ones are worse than the shell tools in areas
that are critical.

> I will use Emacs Lisp interface to external commands in
> cases where it is for some reason not possible to get
> equivalent speed and functionality from within Emacs.

I think it is possible but as long as no one does it doesn't
matter what anyone thinks. But if head(1) and pwgen(1) can do
it from C Emacs should be able to do it from C as well
(built-in, a so-called Lisp primitive), or from a
dynamic module, also in C ...

-- 
underground experts united
https://dataswamp.org/~incal