From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tom Gillespie Newsgroups: gmane.emacs.devel Subject: Re: Discoverability (was: Changes for 28) Date: Tue, 8 Sep 2020 21:36:37 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13366"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 09 06:37:26 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 1kFrrK-0003OV-NJ for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Sep 2020 06:37:26 +0200 Original-Received: from localhost ([::1]:45916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFrrJ-0006y1-QJ for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Sep 2020 00:37:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFrqq-0006SC-EK for emacs-devel@gnu.org; Wed, 09 Sep 2020 00:36:56 -0400 Original-Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:39990) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kFrqk-00039P-Db for emacs-devel@gnu.org; Wed, 09 Sep 2020 00:36:51 -0400 Original-Received: by mail-wr1-x432.google.com with SMTP id j2so1374906wrx.7 for ; Tue, 08 Sep 2020 21:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lhk1nt9Ov67CjyUtjtkppOwkhjG8U/SDKN4aZ8Awi0k=; b=CbtBvBN9EtIn/Qw1iS98Ys3jPgPRs25+KIql5vWAkr3Qzj9oCCEyXVMAcKa1KhRxfR WR7WT9zbFfo3KPvVqlwsNkqvLe3T1Jb4VYvgEva2MZyECRECwNnfnBO9FbSPvy1YYRdc ypvhctSy+mWTgPeDXDzRhClUWxB+upufBF6Cg+p5NlInMC22lj5esDOr8aSg2o5Ib9DZ cCGPw1fR0IZN7IiA3HS1zVC28Fa6x8HsZaWA/aj7tjkgvirqjyqJ3bgutdsG0vvqTbxB DjCv+g2e/2I9EgpGeAJrMqqCFcQb3Xx+Qaz6IhEAsQEZO1X1qKJHv+tvBAU9di/Fpk62 7/MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lhk1nt9Ov67CjyUtjtkppOwkhjG8U/SDKN4aZ8Awi0k=; b=B2pxXE+aH0/pR3ZveTjTx3gSI7zMxzn48An2U+kpONfo1ymcf4vReymWAE6J0iS0/x Kjo1WaTd1dk9Uz3lKeMECo+rOY6uV376jMi68vmiXiCQny+u53aYUjlc6YZHnq7norXb oAZryQoikPm39KunZyu6kIBUrBWNkZ9LjuM2eQtTpRj0D6iheS6eBTJYS9DQhDVS65Fr fZAEvtlCXZuNz2F9285lGr58Mclh930g5f9d0/NcBVkVS/418LRZxQTeFrRumUlMFddp XDWHhtxoeMax+56badqbEYTlmQvjRlt4jLxsW0UDApWJe8aBz9LiJvibY6OCGrPmcGar LHMw== X-Gm-Message-State: AOAM532UUgeGN5f/ca1VckRhRpEYoIASgYEOdKu2LUwx43Gy8dCZG9uc WwiTzF/vKRx4CeTAyecAv77vNNl+/Tzj4ZbaSX8= X-Google-Smtp-Source: ABdhPJwpCMwTr+eMWwMkS7LgOas/HTJDJ6ef8aJsVwEz2ms1MiLGNqFcwl+GHxrk4b4PJjBN41JPV1yG/vYKTDdwv5o= X-Received: by 2002:a5d:684b:: with SMTP id o11mr1810312wrw.101.1599626208469; Tue, 08 Sep 2020 21:36:48 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::432; envelope-from=tgbugs@gmail.com; helo=mail-wr1-x432.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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:254845 Archived-At: Hi Stefan, Thank you for the opportunity to clarify some of my points. Best, Tom I will add that I am heartened by other ongoing discussions that indicate a desire to figure out how to make it possible to On Tue, Sep 8, 2020 at 7:52 PM Stefan Kangas wrote: > I find the analogy to be fundamentally broken. We jest that Emacs is an > operating system, but really it is not. It's a text editor. I do not think that it is a jest. Further, I think that to treat it as such fundamentally undermines real responsibility that Emacs has as a piece of core infrastructure. It may be a just a text editor to you, but to others it is a language runtime no different than the JVM, and to yet others it is the heart of their livelihood. Emacs is as far from notepad.exe (or ed if you prefer the default editor) as a nuclear missile submarine is from a hollowed out log. Yes, both are technically seacraft, but a hollowed out log filled with any number of angry pointy stick weidling men is unlikely to be able to lay waste multiple cities in a matter of minutes. > I don't see how the "don't break userspace" maxim of Linux kernel > development could be applied to Emacs in any meaningful way. We deal in > Lisp, not ABI:s. The example was not intended to be about the superficial implementation details of the particular technology. It has to do with the responsibility that a project has toward its downstream users. Projects that treat their user's time with contempt wither and die unless they have a government mandated monopoly or the like. Emac's has slightly more leeway than the kernel, but if we want Emacs to be infrastructure then we have to treat it as such. Every second that a user has to spend fixing something that broke because of a change in Emacs has to be weighed against the potential benefit. Those seconds are no different from the seconds that some userspace developer (almost never) has to spend fixing something that was broken by the kernel. Furthermore, the risk for us as developers is that we are isolated from the realities faced by other users and are massively biased toward decisions that benefit us and make our work easier. Therefore it seems like a good idea to approach any changes to default behavior with great care since it is especially difficult for a project like this to do the user studies or collect the telemetry required to ensure that those changes don't break countless workflows. > > That means that certain seemingly simple and quick > > solutions, like changing defaults, are forever off the table. Please excuse my hyperbole, and allow me to amend that statement to include "If we entertain the possibility that this means that ...". > If so, it's a new rule. AFAICT, defaults both can and do change. > See NEWS for Emacs 27.1. As a sufferer under some of those changes, I am well aware of the pain that such divergences cause the users. I acknowledge that sometimes those changes need to be made for sake of consistency with larger refactorings. However, the fact that they do happen should be viewed as a failure of engineering and not an excuse for future failures.