From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Renaming eglot -- or at least add an alias? Date: Wed, 12 Oct 2022 09:04:13 +0300 Message-ID: <83r0zdd1cy.fsf@gnu.org> References: <83pmfdduix.fsf@gnu.org> <86wn9ji3ma.fsf@gmail.com> <86tu4lsnqk.fsf@gmail.com> <8335c0p2fn.fsf@gnu.org> <83leproov6.fsf@gnu.org> <83fsfzonwn.fsf@gnu.org> <5a1e604c-4500-a476-da3d-259d9057a7f0@yandex.ru> <838rlromxu.fsf@gnu.org> <83h70dk3wf.fsf@gnu.org> <83fsfxk30x.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37516"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 12 08:11:45 2022 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 1oiUy1-0009cS-74 for ged-emacs-devel@m.gmane-mx.org; Wed, 12 Oct 2022 08:11:45 +0200 Original-Received: from localhost ([::1]:35002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiUxw-0002eo-I8 for ged-emacs-devel@m.gmane-mx.org; Wed, 12 Oct 2022 02:11:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiUqi-0006xP-Jv for emacs-devel@gnu.org; Wed, 12 Oct 2022 02:04:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57434) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiUqi-0007Ms-CI for emacs-devel@gnu.org; Wed, 12 Oct 2022 02:04:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BIXMGjRSfBY2aArhYNWQoKZkv16Fzcx9Af8ixqrnSf0=; b=OdZtZc8yxe2X ZFKrxRK2d2XoLFZtP6Tt5/WuGh4O1AlZP/I4fO55ThYViI9G8YSctpqCybvD6I9RTZppM4pgI40oC IJXsDZM3Co9Rg+jzb06HT/roZ9WIxJX/QFwXoH560IZC/bmr8Pj/SzUBsYJipXdFwnhFVTFd8evjY 7XeI54iBPgYOHqLFrzoOWyrA77HBCmltP9n46cgUlkL80KYeF7s/TEkL1qw1P/jaqWhlL6cmnk9AR EGXSVROcGNCJv4pmkUus2gCv/GNASCFzGLSkeoRWB6HCFPDxp6W9NWEGGieqFua0mlhTiWGOqPKzv 46qS7ShmSIBgypI1fH0AoQ==; Original-Received: from [87.69.77.57] (port=4698 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiUqc-0004XL-BP; Wed, 12 Oct 2022 02:04:07 -0400 In-Reply-To: (message from Richard Stallman on Tue, 11 Oct 2022 17:15:28 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:297572 Archived-At: > From: Richard Stallman > Cc: emacs-devel@gnu.org > Date: Tue, 11 Oct 2022 17:15:28 -0400 > > > So, at least in principle, the functionalities based on these two > > could overlap. If that is indeed so, we'd need to decide whether we > > support the overlapping functionalities or use each one of these > > packages for capabilities that are disjoint, whereby each > > functionality is supported by the package that does it best (for some > > value of "best"). > > I suggest that we define the principal user interface to enable or > disable the user-level features, not the implementation mechanisms. > > We could have a way to enable or disable multiple user-level features > at once, and/or ways to enable or disable specific user-level features > one by one. But they should not be tied to implementation mechanisms. > > Of course, we can offer the user additional control over which > implementation mechanisms to use for this or that. If it is not too > hard or worth the trouble, why not? But such fine control should be > for those who want to be wizards. > > People who just want some smarter editing features should not need to > know what is implemented by Eglot, what is implemented by Tree-sitter, > and what is implemented in some other way. This discussion is primarily about our design and implementation decisions: whether some features need to have more than one "back-end" or just one, decided by us. AFAIU, we haven't made the final decisions yet. Whether and how users will control that comes later. If we decide that each feature will have only one "back-end", the part of selecting a "back-end" is automatically resolved to a non-issue. Regardless of the Tree-sitter vs Eglot issue, we already have this kind of problem with tree-sitter alone, in modes that can perform fontification based either on the font-lock-keywords machinery or using tree-sitter. We'd probably need to give users control which one to choose, even if tree-sitter is installed and available, at least in the short run. > A few weeks ago, I expected we would want to have an Eglot manual, but > now I think that is the wrong way to organize our documentation. We > should organize it by functionalities, each functionality described in > its proper place in the Emacs manual. The Emacs manual will shortly mention Eglot where relevant, and point to the Eglot manual. Description of the functionalities which Eglot enhances don't need to be modified, not as a rule. But we cannot avoid having an Eglot manual, because there's Eglot-specific stuff for which the Emacs manual is not the right place. We have a separate Tramp manual for the same basic reasons, although Tramp is well integrated into Emacs and editing remote files is largely transparent (except for the fact that various commands could be slower with remote files). There's also the non-negligible consideration of the sheer volume of the Emacs manual. With time and experience, and maybe if we add other "back-ends" with similar functionalities, we could rearrange the manuals and the stuff each one of them says. But I see no reason for making such decisions now. Our manuals are not Holy Scripture, they can be changed as we see fit any time we find it necessary. Eglot has a significant community of users, and they are already used to its current command and variable names; we are not starting the naming game from scratch. So any "abstraction" of the UI and the names we'd like to do will have to be slow and with backward-compatible aliases anyway.