From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: PL support Date: Mon, 11 May 2020 17:33:35 -0700 Message-ID: <9c4742ee-00f0-3d4b-eab8-1fb805b2b9db@dancol.org> References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <83pnbegsvm.fsf@gnu.org> <83imh5hby1.fsf@gnu.org> <2e4e8ce9-d857-f3e3-31cf-a40dee67bd25@yandex.ru> <83y2q1dsvh.fsf@gnu.org> <2468efa6-7dbd-8634-44cc-586bb6985f49@yandex.ru> <83pnbddrfd.fsf@gnu.org> <83k11ldpxs.fsf@gnu.org> <83imh5dnun.fsf@gnu.org> <2c09354e7994f0e61271ab0078256a9dc4202171.camel@k-7.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="84510"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Yuan Fu , seb@k-7.ch, emacs-devel@gnu.org To: Stefan Monnier , Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 12 02:35:58 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYItp-000LrJ-Ka for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 02:35:57 +0200 Original-Received: from localhost ([::1]:57888 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYIto-0002i4-HN for ged-emacs-devel@m.gmane-mx.org; Mon, 11 May 2020 20:35:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37230) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYIre-0001h1-NO for emacs-devel@gnu.org; Mon, 11 May 2020 20:33:42 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:52580) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYIrd-0004J4-Gg; Mon, 11 May 2020 20:33:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gbHlaDvMhNpCqD21gOHp4m18U0ebYHP+5CQrj8g6nB0=; b=IvKlU4ffzDFK+EarsI3jneKJwH UGke40DNOidKKOxgVnxeisT6J2YqTr6AW2VYx+LdEXZEfBZpBqFuWYW6kYCFppPmuSU5vQ0I9Lvu9 hKKklbFgJGr4DWIfP7+bcZBr4TFy+QConvB50Tlx9q4q/dND2BBg0ZG3+l8drqQFHkB38Q4kBQoFa fSxtqdyBE/qb8zNUaz5QJBJr99E6cUZetxdZaMeYzi4eoGbZ/yBzcncLSyMXA9EtbSZbI0eF3R/2g aVxB/WmAaxNMiRKLpS5hAb5piPblcLssgOhlxSd/wFr6T4gmAkUPfU9sSw2V/LkJ8ldVcut92TGaG 0dppFp8A==; Original-Received: from [2604:4080:1321:9a00:3d60:5fe6:8cb4:e9e6] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jYIrY-0000ZG-8Q; Mon, 11 May 2020 17:33:36 -0700 In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fedf:adf3; envelope-from=dancol@dancol.org; helo=dancol.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:249909 Archived-At: 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 > whatnot). 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.