emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Imports / inclusion of s.el into Emacs


From: João Távora
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Thu, 7 May 2020 11:14:31 +0100

On Thu, May 7, 2020 at 3:45 AM Richard Stallman <address@hidden> wrote:
>
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     not to let widely used and Free software into our
>   > universe just because we don't have the technical apparatus to
>   > control the damage it would bring with it.
>
> You have stated an inaccurate picture of the situation, but I can't
> respond to that statement on a technical level because you have mixed
> personal criticism into it.  If you bring up the issues in purely
> techical terms, I can respond in that way.

You've completely misunderstood me, Richard. I was not attacking your
position at all, much less attack you personally. Or Stefan.  I *agree* with
you: puting s.el in Emacs or GNU ELPA is not good *for* exactly the reasons
you state.  But I also *agree*  with Stefan, when he laments that that library
which is free software and used widely in third party package can't easily
be added to GNU ELPA and/or Emacs.

Now, what I stated is that it would be immoral to permit this to continue:
Immoral is a strong word. I should have used "unfair" or "untenable".
Let me try again:

  Is is untenable not to let widely used and Free software into our universe
  just because we don't have the technical apparatus to control the damage.

Q: What damage is that? A: Namespace pollution from a package with a
very short prefix.

Q: What could we do to control it? A: Change the package to not have a very
short prefix. Q: What is the problem with that? A: Many package users like it
and already use it with the short prefix.

Q: So what could we do, technically, to remedy the situation? A: Provide
a way for the package to have a longer prefix *and*  package users
to use it with a short prefix.

This is my only and main contribution to this discussion.  I have surveyed
existing solutions to last question and have counted about 4 or 5 existing
ones, and many new ideas.

Thank you,
João



reply via email to

[Prev in Thread] Current Thread [Next in Thread]