From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Renaming eglot -- or at least add an alias? Date: Mon, 03 Oct 2022 11:21:40 +0000 Message-ID: <87mtadb1a3.fsf@posteo.net> References: <83pmfdduix.fsf@gnu.org> <86sfk7hse3.fsf@gmail.com> <8735c6tq6t.fsf@posteo.net> <87r0zq2uea.fsf@posteo.net> <87mtae2pgb.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="18831"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tim Cross , emacs-devel@gnu.org, Richard Stallman To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 03 13:23:52 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 1ofJY8-0004im-Jr for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 13:23:52 +0200 Original-Received: from localhost ([::1]:46160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofJY7-0004YX-4E for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 07:23:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofJWI-0003pr-KI for emacs-devel@gnu.org; Mon, 03 Oct 2022 07:21:58 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:56487) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofJW4-0001lo-CG for emacs-devel@gnu.org; Mon, 03 Oct 2022 07:21:58 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id DDFFE240099 for ; Mon, 3 Oct 2022 13:21:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1664796101; bh=LpIeR3Nobh1peB52kuJzUsqdCq6AVkiO8NzLrLHHFRg=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Ono4juJSUF832OCXp3Oee11ORcb0EMGX6kQm4mAR+Oi8KDIo5FExOJsid65ixsGl5 ZyiQG6ywjPNSXeQFDv4IgWUZR2eiudSzjG98FSjfCHAHoP2F0jFBQdx8IA/r2AygdG ouGYCTu2S52AITZx27n2MkXeSVc6RPWbcAmDSJdVSz5BqrBPn9nNuQbIvUioEWwhlP tkIejTyH/zAD6AneBRoWZYeV2wg5mivsOKwL84fnsnxmWv0lbu2Ho9WavsgThrpyO0 Ywgq9bUmnn7Lxu2CqMGFxelQIy1sPr6WUloon7TdIVl7315+dcOL4fpJ60qrqyLNZo lwE2dJguHAWhg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Mgz1d1f6bz9rxK; Mon, 3 Oct 2022 13:21:41 +0200 (CEST) In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Sun, 2 Oct 2022 21:07:49 +0100") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:296738 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Sun, Oct 2, 2022 at 4:52 PM Philip Kaludercic wro= te: > >> > Those are all phrases in disguise. Even "hl" is really two things. >> >> I guess so? What is the other thing? > > I just meant "hl" is a itself made of "high" and "light", two unbreakable > signs. I see, but then again those are the two syllables that constitute the word, so it isn't totally arbitrary. >> > One could have come up with a short phrase instead of Eglot, say >> > "emacs-very-bueno" or sth like that. That would probably be more > intuitive. >> > But also probably silly, and easy to miss the target. >> I am under the impression that we are talking past one another. Yes, I >> agree that "emacs-very-bueno" and "Eglot" are equally opaque, > > No, the first is not as opaque, it carries more meaning that it's somethi= ng > that enhances Emacs (also tried to carry the meaning of "joke" in my > destitute sense of humor). Interestingly enough it only does that if you are familiar with the non-English word "bueno". That being said, I get your point but am not convinced. >> but why is >> that important? I am saying that it might be good to _at the very >> least_ add an alias for `eglot-ensure' consisting of only English words. > > Such words would be "turn-on-eglot-if-its-not-on-yet". I am getting more and more confused. What does this have to do with what I said? >> Also, do you have comments on the other suggestions form my previous >> message? > > I don't think the conditions are there to turn Eglot on by default. Langu= age > servers are a big variable. They are lots and lots of code we have no > control > over and there are very many of them. It's not like relying on "ls" or > "git". > > Even if they were, I'm not convinced that's a good idea. *Maybe* Eglot > could > become more transparent (major modes could using it as a library to do > major-mody things) but never entirely invisible, I think. Meaning I think > the > user should never completely forget that there is a language server > connection currently tied to some major modes of a project, and managing > those buffers. I am curious to hear why you think this should be. Is it not preferable to make use of the tools the environment is providing instead of falling back on approximate heuristics like grepping for where a variable occurred or using TAGS-files for definitions and completion? > The command M-x eglot-list-connections doesn't exist yet, but I will add = it > soon > for convenience and debugging purposes and to help reinforce this structu= re. That will be nice to have. > I think the popularity of `eglot-ensure`, while convenient, has somewhat > erased this sense of structure for some users, which sometimes makes users > have unrealistic expectations of how Eglot works, and hard to penetrate b= ug > reports. I recommend M-x eglot instead. To be fair, I do that too, and this is why I wanted to prose adding an alias to make it easier to remember the command. We enthusiasts often overestimate the readiness of more casual users when it comes to remembering commands, bindings, packages, etc. If possible, and I still think it is, we should try to help.