From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Renaming eglot -- or at least add an alias? Date: Mon, 03 Oct 2022 08:30:28 +1100 Message-ID: <867d1hub5n.fsf@gmail.com> References: <83pmfdduix.fsf@gnu.org> <86sfk7hse3.fsf@gmail.com> <8735c6tq6t.fsf@posteo.net> <87r0zq2uea.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27924"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.0; emacs 29.0.50 Cc: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , emacs-devel@gnu.org, Richard Stallman To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 03 00:14:36 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 1of7EK-000749-DR for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 00:14:36 +0200 Original-Received: from localhost ([::1]:42026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of7EJ-0005zV-Ch for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 18:14:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of7DI-00056Y-Q5 for emacs-devel@gnu.org; Sun, 02 Oct 2022 18:13:32 -0400 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:45977) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1of7DG-0002yG-U7; Sun, 02 Oct 2022 18:13:32 -0400 Original-Received: by mail-pf1-x432.google.com with SMTP id c3so3841063pfb.12; Sun, 02 Oct 2022 15:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:from:to:cc:subject:date; bh=2o/FOBTJH8D55SGYmg0RTWdOpBZzoOdb+3H3EJanVJU=; b=QUK63kEmm/veT93/QMyakoxKkUdFSy7HCk+K3QZRCY+6kS3QspmJm92DAYa6ud43br aHljipPWObFix0dZTKgYxShL8XPBVd3gZBenBGoK5yd2Y6RCNhKi/AwWCSp9MOqWDrxn Ne8tgbi+W2QNEwlvL/NoI0dla3JrEw8gQw/G+B66wksgkEHlc638NsZEa/gQyB8NWOdu Ko9iUZV3t9E/UpXtREy4rWgVSVFDf/8B8KxNZzIiqBZxU5OrJg4UqvEgYBXb+q4fvDSx DF12JZDeUiJhz4nEeSbdlYZaEEtz1CXawegGpdIPoNPeP2cDk6QJlU+3qb2gi4htqKuC Y9ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to :cc:subject:date; bh=2o/FOBTJH8D55SGYmg0RTWdOpBZzoOdb+3H3EJanVJU=; b=BTwPi6JaZqxkfA2e2BUlMNxfcrqOm0+peT+7XV1UpMf6+RZv86qP3MPEtQKlTGwh3P BixW4F26SSofdUYCfdCKCyBEp1GgOXUlrnGBgrp0iZ0DggGqu0lBJR+NmQ8fFnvFr5gE oWgEY2vwt4hEVP1sSivTkEE9gXa4Xv/pnCGIjboLlvW6NKTU2S0WYw7/91kkSUMy5IrF TU5wCmvYnZFLMIuVnGnhkqpsgLjlk8PLshCcyLpzQxAtg1q6kQ46W8h8Uu58JNDxz0bm pebcyurMp1F1pbbQdyATl25kdO9T5oB3Y/lb4oy8KRVTJO6aVSCAAOPj0us9njRhEAGN cmEQ== X-Gm-Message-State: ACrzQf0jEmIdQjyz5H66H+YZxWUBq9Fg0AEpGd+PJvV/MGwzTsvhEHRS d9LUfqLZZsnqWiUIUjXL0r4polfOM8M= X-Google-Smtp-Source: AMsMyM5q2VHZr6EnpeauHRunPp5LZVLAOXan62qWraimp1897WKcKr1+acTXuHUlk9934t7x0xZzmg== X-Received: by 2002:a63:d118:0:b0:43c:1440:6486 with SMTP id k24-20020a63d118000000b0043c14406486mr16666800pgg.92.1664748808762; Sun, 02 Oct 2022 15:13:28 -0700 (PDT) Original-Received: from dingbat (124-169-22-230.dyn.iinet.net.au. [124.169.22.230]) by smtp.gmail.com with ESMTPSA id b15-20020a170903228f00b001781cad59e3sm5866765plh.108.2022.10.02.15.13.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Oct 2022 15:13:28 -0700 (PDT) In-reply-to: <87r0zq2uea.fsf@posteo.net> Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x432.google.com 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.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:296711 Archived-At: Philip Kaludercic writes: > Jo=C3=A3o T=C3=A1vora writes: > >> On Sun, Oct 2, 2022 at 12:34 PM Philip Kaludercic >> wrote: >> >>> The idea behind the name (Emacs polyGLOT) is not intuitive. >> >> Since when are names "intuitive"? Do I have any intuition about who >> you are or what you do from your name alone? Names are abstract >> indirections by definition (with some 20th century structuralist and >> post-structuralist caveats that I really don't think apply here). > > Intuitive in the sense that you can reasonably infer information given > previous experiences. I know that [languagename]-mode is usually a > major mode for a language. A package name like "hl-diff" gives a rough > idea of what the package is about, when you know that "hl" stands for > highlight. Something like "highlight-parentheses" is obvious. If you > know about VC, then "vc-fossil" is an intuitive name. > > In my opinion, non-intuitive names are among other things: bbdb, cape, > cider, delight, ement, helm, rich-minority, tiny, ... (this is just a > random selection from skimming through the package list) > All your examples are for libraries/modules with a very simple single purpose. I don't think anyone disagrees it is good to have a name which can assist in deducing the functionality. However, this isn't always possible. It seems to be something very difficult for packages which fulfil multiple functions or for packages where there are multiple different implementations. Consider templating libraries. I know of at least 4 fairly popular ones - one of them, yasnippet even has 'ya' for 'yet another'. I saw a new templating solution recently - what chance has that author got of finding a name which is going to be intuitive and isn't already used or will be confused with other packages with similar functionality? Even in this discussion, we are struggling to find a good intuitive name primarily because one of the most intuitive names (which also tends to follow Emacs 'styule') has already been taken i.e. lsp-mode. None of the names I've seen suggested are of any real improvement and in many cases, I find them misleading as they imply a functionality which the package does not provide.=20 >> I have no problem admitting "Emacs polyglot" is mostly a half-assed pret= ext >> to justify a distinctive, easy to type name. I wouldn't fixate on it. >> >> Some people like its sound and uniqueness. A demographic you are not pa= rt >> of, I comprehend that. You can't always please everyone. > > I get that. > >>> I don't even think it is necessary to rename the implementation as long >>> as at least one auto-loaded alias is available. >> >> What is this idea? Say you make M-x philip an auto-loaded alias for M-x >> eglot. > > Where "M-x philip" is a stand-in for some of the suggestions I made > before like "M-x ide-mode"? > >> Say I go with that, then what? What about M-x eglot-rename, M-x >> eglot-reconnect, >> M-x eglot-shutdown and all the eglot- user variables, etc? >> They keep the same names? What good is that really? Alias all of them? >> No thanks, there are enough confused users already: I want to communicate >> with them as unequivocally as possible > > Honestly, I think that commands like eglot-rename should either be > aliased or wrapped by some other prefix-less command > (e.g. "rename-symbol"). User options are more tricky, that is true. I doubt that would work well. The functionality 'rename symbol' is a common term and one which many language modes also implement. Why would eglot (or whatever it ends up being called) be able to 'own' that name?=20 > > A more radical idea, but that might be something for Emacs 30+ could be > to just enable Elgot by default when everything necessary for using it > is available. Then new users wouldn't have to bother with finding out > what the right packages, user options, etc. are and could just use it > OOTB. That would be assuming that anyone with an LSP server installed > is actually interested in using it. > I think this misses the main strength of Emacs. Emacs is largely about being able to craft the experience you want. It isn't meant to be a clone of all other editors where everything comes 'out of the box' based on what some other people believe is the right setup. Besides, there is no such thing as 'a language server' - there are different servers for different languages and it is quite likely there will be multiple different language servers for a single language (already the case with some languages like javascript). I also think this boat has sailed. We already have sufficient numbers of packages which for whatever reason, don't have 'intuitive' names. In fact, it is probably impossible to achieve such a thing given differences in languages, cultures, technical backgrounds etc. We don't even seem to be consistent here. We have been asked to come up with a new name which is intuitive, but does not involve jargon or require inherent technical knowledge. How is this going wiht respect to other packages, for example, the very interesting tree-sitter? What is that going to be called? The term tree-sitter is very jargon and technical based. Anyone not familiar with lisp is unlikely to know what that is. The point is, we already have to rely on package description and not package name for meaning. This is unlikely to change. If someone was able to suggest a good name, I'm sure it would be adopted, but nobody has. So gar, eglot seems to be as good as any other suggestion IMO, especially at this 11th hour when hard working dedicated maintainers are trying hard to get this package merged into emacs and release Eamcs 29. I also suspect, given all the information and documentation out there about eglot, changing branding now would just be detrimental to both that package and Emacs. At the end of the day, I think the name given to a package should be up to the developer(s) of that package. We can provide guidelines and recommendations, but the final decision should rest with those who actually do all the work.