Re: persistent data feature

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: tom@logand.com, galex-713@galex-713.eu, emacs-devel@gnu.org
> Date: Sun, 12 Dec 2021 22:42:41 -0500
> 
>   > > Also I find the trend of linking everything into the emacs process
>   > > concerning:
> 
>   > What's the alternative? to reinvent all the wheels in Emacs's own
>   > code? to use external programs? something else?  Rejecting a trend for
>   > which there are no better alternatives is not smart.
> 
> For any given facility, I see these alternatives to consider:
> (1) Link it in statically.
> (2) Use an external program in a subprocess.
> (3) Use a dynamically linked module.
> (4) Write it in Lisp.
> (5) Decline to support it.

I think (1) and (3) are the same, for the purpose of this sub-thread,
since the issue raised was how many external libraries we depend on.
(2) is only viable if the amount of stuff flowing back and forth
between Emacs and the program is relatively small, otherwise it's just
bad design and worse performance.  (4) is not relevant because that's
normally the first solution we try, and if we decided that Lisp cannot
handle it well enough, or not at all (like with drawing images on the
Emacs display), we are way past that when we get to the decision
point.  Declining to support a useful capability when there's a
reasonable way of supporting it is silly.

So we are left with (1) and (3), which are usually indistinguishable
(except in weird cases like libgcc).

> If we conclude that we are using (1) too readily,
> that wouldn't imply we should reject it entirely henceforth,
> but would lead us to be more ready to choose the others.

Once again, (1) and (3) are the same.  I think nowadays people prefer
shared libraries for reasons of system maintenance, and its infeasible
to try to force users or distros to use only static linking (nor do I
see any reasons for that, either technical or political, as long as we
are talking about Free Software anyway).