[Top][All Lists]

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

Re: PL support

From: Daniel Colascione
Subject: Re: PL support
Date: Mon, 11 May 2020 17:33:35 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 5/10/20 8:56 PM, Stefan Monnier wrote:
Richard wrote:
Some contributors are eagerly planning a sort of automatic facility to
"install external tools."  I'm disappointed to have to say that this
raises problems at various levels.  I doubt there is an acceptable way
to do it.

There is no doubt that acceptable ways to do it exist.

As a matter of fact, we *already* do that, typically in the form of
instructions in `Commentary:`, `INSTALL`, manuals, messages in
mailing-lists, etc...

These instructions raise various problems, indeed.

Other ways to "do that" would solve some of those problems, preserve
some of them, and introduce yet new ones.

There's a vast design space here, with many points in there which should
be very much acceptable to our usually conservative sensitivity of
"don't do anything without a very explicit user consent".

Daniel wrote:
You seem to be imagining a world in which Emacs installing external software
means that it runs distribution package manager tools or plops binaries in
/usr/bin. You can instead bundle known-good versions of external tools with
Emacs and run them in a controlled way from filesystem locations that Emacs
controls. Downloading revisions of these tools that hash to entries on an
Emacs whitelist is equivalent.

FWIW, I probably wouldn't like a solution where we bundle binaries of
external tools, since then we'd be bound (either by the license, or
morally anyway) to include the source as well, and then we'd have to
keep it up-to-date (and deal with somewhat automatic updates and

Why not? We don't even need to distribute binaries, really. We can just vendor any external tool that we need for core functionality and allow users (or, doubtlessly, distributions) to override our bundled tools with system-provided ones as desired. GCC does this already: consider how GCC vendors things like libquadmath andlibffi already. Would anything be wrong with our vendoring TreeSitter or some LSP servers, as source and free software?

If our vendored program gets a little out of date, so what? We'd install that vendored program in an Emacs-private location where it wouldn't do any harm to the rest of the system.

This said, that is still a very much acceptable point in the
design space for some cases.

A very different design point might be to try to guess the kind of
"package management" in use (msys, apt, guix, ...), then build
a sequence of commands to pass to that package management, show it to
the user, and ask them to run them (or to confirm that they want Emacs
to run them).

I'm not really in favor of this approach. I don't believe Emacs should try to be making system-wide changes, especially since it's not necessarily even installed system-wide.

Another design point is to display to the user a text box explaining
what they need to install and where they can find instructions to do so.

I think advanced functionality should Just Work out of the box. "Some assembly required" is a lot of friction.

reply via email to

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