Re: Noob dumb question (extending emacs)

[Jean Louis <bugs@gnu.support>]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-10-24 21:22]:
> 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. That is why breaking crypto requires a proof which is usually
program or exploit that breaks it, not just a theoretical statement.

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

What about cp, mv, we use it in Dired, should we start now
recommending using external "cp" instead of Dired one? As much as
possible we strive to integrate features into Emacs, not the other way
around. 

> Note that you can still use your (or any other) Elisp
> interface ...
> 
> I think this is much more the practical approach BTW!

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.

For example GNU `mail' utility is very handy and powerful to construct
emails, I rather use that one, then the Emacs way of constructing
emails. I will rather use `mutt' as Emacs offers none of email clients
nearly so fast and functional as `mutt'. I have tried my best to find
similarly functional client in Emacs and I have tried them all,
solutions are slow and lack features I need. For Xournalapp, I will
use Emacs and database to track locations of Xournal notes, but
external program must be invoked to modify such note. 

But if user does not want to integrate stuff in Emacs Lisp, such will
use more external commands. Many will use their graphical file
managers instead of Dired, that is up to individual's desires.

> 2. the skilled and scientific and practical approach: rewire
>    Elisp to be at that same level (practical as in doing it,
>    but also as in sharing it in the FOSS world)

If program modifies Emacs and is published, it has to be with
GPLv3 license or compatible one. Is it clear?

> 3. other approach: write it in ELisp, and after a nontrivial
>    effort the outcome will still not be as good as the CLI
>    tool

That is too general statement, it seem to come from your experience in
which I did not participate. Outcome of Emacs Lisp may be equally good
as other external command. I wonder how you, who I know you to have
written many Emacs Lisp programs now speaks contradictory.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/