Renaming eglot -- or at least add an alias?

Renaming eglot -- or at least add an alias?

[Stefan Kangas]

Hi all, João,

Now that we're getting closer to merging eglot, I think it is our last
chance to (re-)consider that "eglot" is not the ideal name.  It has some
charm, of course, but it is quite non-descriptive and it's hard (read:
impossible) to understand what it does based on the name alone.[1]

As for names, lsp-mode would be the obvious choice, but some other
package has occupied that prefix (too bad).  I therefore propose
renaming it to elsp-mode and using the elsp-* prefix for it.

At the very least, we should consider adding some alias, like
`start-lsp', and/or `lsp-start'.[2]

Footnotes:
[1]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02828.html

[2]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02818.html

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Hi all, João,
>
> Now that we're getting closer to merging eglot, I think it is our last
> chance to (re-)consider that "eglot" is not the ideal name.  It has some
> charm, of course, but it is quite non-descriptive and it's hard (read:
> impossible) to understand what it does based on the name alone.[1]

I can only agree.  Especially because there are a number of packages
starting with "el...", which makes misreading the package name as
"elgot" very easy (which is still how I pronounce the package when
speaking to this day).

> As for names, lsp-mode would be the obvious choice, but some other
> package has occupied that prefix (too bad).  I therefore propose
> renaming it to elsp-mode and using the elsp-* prefix for it.
>
> At the very least, we should consider adding some alias, like
> `start-lsp', and/or `lsp-start'.[2]

I think that even using the word "lsp" suffers from the same issue, as a
lot of people still have no idea what LSP is (even if they are using
it).  I don't have a better suggestion but maybe mentioning the word
"intelligence" or "ide" would be better.

> Footnotes:
> [1]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02828.html
>
> [2]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02818.html

Re: Renaming eglot -- or at least add an alias?

[Payas Relekar]

>> Now that we're getting closer to merging eglot, I think it is our last
>> chance to (re-)consider that "eglot" is not the ideal name.  It has some
>> charm, of course, but it is quite non-descriptive and it's hard (read:
>> impossible) to understand what it does based on the name alone.[1]
>
> I can only agree.  Especially because there are a number of packages
> starting with "el...", which makes misreading the package name as
> "elgot" very easy (which is still how I pronounce the package when
> speaking to this day).
>
>> As for names, lsp-mode would be the obvious choice, but some other
>> package has occupied that prefix (too bad).  I therefore propose
>> renaming it to elsp-mode and using the elsp-* prefix for it.
>>
>> At the very least, we should consider adding some alias, like
>> `start-lsp', and/or `lsp-start'.[2]
>
> I think that even using the word "lsp" suffers from the same issue, as a
> lot of people still have no idea what LSP is (even if they are using
> it).  I don't have a better suggestion but maybe mentioning the word
> "intelligence" or "ide" would be better.

How about intellisense? Asking because Microsoft does own the trademark,
and I'm not sure if we can use it for similar product.

elsp-mode, while terse is not the first thing one might think.
codesense, codesmart or some such might be better.
--

Re: Renaming eglot -- or at least add an alias?

[Theodor Thornhill]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Hi all, João,
>>
>> Now that we're getting closer to merging eglot, I think it is our last
>> chance to (re-)consider that "eglot" is not the ideal name.  It has some
>> charm, of course, but it is quite non-descriptive and it's hard (read:
>> impossible) to understand what it does based on the name alone.[1]
>
> I can only agree.  Especially because there are a number of packages
> starting with "el...", which makes misreading the package name as
> "elgot" very easy (which is still how I pronounce the package when
> speaking to this day).
>
>> As for names, lsp-mode would be the obvious choice, but some other
>> package has occupied that prefix (too bad).  I therefore propose
>> renaming it to elsp-mode and using the elsp-* prefix for it.
>>

I like elsp, so much so that my play-fork of eglot is named exactly
that[0]. 


>> At the very least, we should consider adding some alias, like
>> `start-lsp', and/or `lsp-start'.[2]
>
> I think that even using the word "lsp" suffers from the same issue, as a
> lot of people still have no idea what LSP is (even if they are using
> it).  I don't have a better suggestion but maybe mentioning the word
> "intelligence" or "ide" would be better.
>

I think referring to it as an integration with lsp by its name should be
just fine.  It is exactly that, and why not refer to it like the rest of
the ecosystem?  As a tangent I remember the discussions we had here on
tree-sitter, and whether it should be called ts, treesit, tree-sitter
etc.  I don't understand why referring to it by what it actually is is a
problem.  In this case, elsp, or elsp-mode seems like the obvious
choice, considering that the better name already is taken.  In addition,
neither LSP or tree-sitter looks like tech that will vanish the next
week, so relying on users learning what it is in time should be fine,
IMO.

Theo

[0]: https://git.sr.ht/~theo/elsp

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 30 Sep 2022 01:04:46 -0700
> Cc: João Távora <joaotavora@gmail.com>
> 
> Hi all, João,
> 
> Now that we're getting closer to merging eglot, I think it is our last
> chance to (re-)consider that "eglot" is not the ideal name.  It has some
> charm, of course, but it is quite non-descriptive and it's hard (read:
> impossible) to understand what it does based on the name alone.[1]

Sorry, no.  We will not start a dispute about renaming eglot, because
that would delay its merge, and we don't have time for that luxury.
We want eglot to be part of Emacs 29.

As for more basic arguments why not rename it: this package is not a
new one, it is used by many people as a 3rd-party package.  So it's
too late to rename it.

So, no: eglot will rename eglot, and will be merged with Emacs under
that name.  It might be sub-optimal, but there are more important
considerations at stake.

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Hi all, João,
>
> Now that we're getting closer to merging eglot, I think it is our last
> chance to (re-)consider that "eglot" is not the ideal name.  It has some
> charm, of course, but it is quite non-descriptive and it's hard (read:
> impossible) to understand what it does based on the name alone.[1]
>
> As for names, lsp-mode would be the obvious choice, but some other
> package has occupied that prefix (too bad).  I therefore propose
> renaming it to elsp-mode and using the elsp-* prefix for it.
>
> At the very least, we should consider adding some alias, like
> `start-lsp', and/or `lsp-start'.[2]
>
> Footnotes:
> [1]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02828.html
>
> [2]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02818.html

I think I've said this before as well.  That would be a great idea.
What about language-server-mode, though, as `elsp' is still not very
descriptive?

However, the more pressing problem is that (as I've said) searching for
"language server" in Customize does not reveal much of value.

Re: Renaming eglot -- or at least add an alias?

[João Távora]

Stefan Kangas <stefankangas@gmail.com> writes:

> Hi all, João,
>
> I therefore propose
> renaming it to elsp-mode and using the elsp-* prefix for it.

I'm not sure this is a great idea.

It seems to directly violate two of the items I listed in the plan I
sent some time ago
(https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01583.html)

* The current GNU ELPA "eglot" package is of type :url.  The plan is to
  simply transition it to :core in GNU ELPA This has obvious advantages,
  such as not needing to change a user configuration to continue
  receiving updates on the same package.

* Another item on that list required that, for a transient period, the
  GitHub hosting can continue to mirror the upstream
  lisp/progmodes/eglot.el file and the GitHub eglot-tests.el can
  continue to work with no changes..

  Also current users a git clone of the GitHub repo will continue to
  work unimpeded.

I think adding one or two aliases wouldn't hurt this directly, but a
"renaming" definitely would.  But then what symbols would you add the
alias to? `M-x eglot`? What about all the other externals ones?
Variables, commands, API symbols?

Even if the fallout from that were somehow acceptable, I think adding
the three-letter sequence "lsp" into the the mix will just fuel even
more confusion between the two Emacs LSP clients. I mean, even with the
current unmistakable "eglot"/"lsp" names, I remember people asking why
some snippet of lsp-mode.el config doesn't work with eglot.el.

I don't think current popular packages such named TRAMP, ido, ElDoc,
Flymake are that much better at describing accurately what they do in
their short names.  Or "Emacs", for that matter.  I think naming has had
little bearing on their adoption.

It's debatable that "LSP" is even a good "descriptive" thing to put into
the name of a package.  For a total newbie to Emacs or to programming,
what even is "LSP", what does it mean?  It's, quite literally, a lower
level implementation detail concerning an implementation protocol.  If
it weren't for the occasional need to shop around for "language servers"
on your system package manager, the user shouldn't even know about it.
If a more complete Emacs distribution, say a "Doom" or a "Bliss" Emacs
would just bundle these server programs, then "LSP" would be totally
meaningless.

I'm not sure any of this would more would-be Emacs maintainers will
start engaging with Eglot maintenance, setting up servers to help
reproduce bugs and understand the architecture of the package.  Those
are the real things needed to propel Eglot adoption, in my sincere
opinion.

João

PS: As you may have guessed, despite being out of this particular loop,
I'm not too hot on the current renaming symbol trend.  I think for
example, having renamed `current-line` to `array-current-line` bring us
little in exchange for the confusion and byte-compilation noise it
introduces. Namespacing problems should be solved with proper
namespacing systems.

Re: Renaming eglot -- or at least add an alias?

[Daniel Martín]

Stefan Kangas <stefankangas@gmail.com> writes:

> Hi all, João,
>
> Now that we're getting closer to merging eglot, I think it is our last
> chance to (re-)consider that "eglot" is not the ideal name.  It has some
> charm, of course, but it is quite non-descriptive and it's hard (read:
> impossible) to understand what it does based on the name alone.[1]
>
> As for names, lsp-mode would be the obvious choice, but some other
> package has occupied that prefix (too bad).  I therefore propose
> renaming it to elsp-mode and using the elsp-* prefix for it.
>
> At the very least, we should consider adding some alias, like
> `start-lsp', and/or `lsp-start'.[2]
>
> Footnotes:
> [1]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02828.html
>
> [2]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02818.html

Right now under "Maining Large Programs" in the Emacs manual the closest
package to Eglot is EDE (Emacs Development Environment), so perhaps the
name could be EDE-LSP or something like that.

Re: Renaming eglot -- or at least add an alias?

[Daniel Martín]

Daniel Martín <mardani29@yahoo.es> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Hi all, João,
>>
>> Now that we're getting closer to merging eglot, I think it is our last
>> chance to (re-)consider that "eglot" is not the ideal name.  It has some
>> charm, of course, but it is quite non-descriptive and it's hard (read:
>> impossible) to understand what it does based on the name alone.[1]
>>
>> As for names, lsp-mode would be the obvious choice, but some other
>> package has occupied that prefix (too bad).  I therefore propose
>> renaming it to elsp-mode and using the elsp-* prefix for it.
>>
>> At the very least, we should consider adding some alias, like
>> `start-lsp', and/or `lsp-start'.[2]
>>
>> Footnotes:
>> [1]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02828.html
>>
>> [2]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02818.html
>
> Right now under "Maining Large Programs" in the Emacs manual the closest
> package to Eglot is EDE (Emacs Development Environment), so perhaps the
> name could be EDE-LSP or something like that.

After a second look, perhaps Semantic is a closer match (under "Editing
Programs"), so the name could be Semantic-LSP.

Re: Renaming eglot -- or at least add an alias?

[Basil L. Contovounesios]

Philip Kaludercic [2022-09-30 08:27 +0000] wrote:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Now that we're getting closer to merging eglot, I think it is our last
>> chance to (re-)consider that "eglot" is not the ideal name.  It has some
>> charm, of course, but it is quite non-descriptive and it's hard (read:
>> impossible) to understand what it does based on the name alone.[1]
>
> I can only agree.  Especially because there are a number of packages
> starting with "el...", which makes misreading the package name as
> "elgot" very easy (which is still how I pronounce the package when
> speaking to this day).

If we just changed the default language of Emacs to Greek, "Eglot" would
automatically become a lot more palatable ;).  Maybe for Emacs 30 🤞.

-- 
Basil "playing with global-cheat-mode enabled"

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

On Fri, Sep 30, 2022 at 12:33 PM Basil L. Contovounesios <contovob@tcd.ie>
wrote:

> > I can only agree.  Especially because there are a number of packages
> > starting with "el...", which makes misreading the package name as
> > "elgot" very easy (which is still how I pronounce the package when
> > speaking to this day).
>
> If we just changed the default language of Emacs to Greek, "Eglot" would
> automatically become a lot more palatable ;).  Maybe for Emacs 30 🤞.


Google translate doesn't get the pun, but it does tell me that "eglot" is
latvian
for "spruce up".  So yeah, I was totally thinking latvian.

João

[-- Attachment #2: Type: text/html, Size: 1044 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Basil L. Contovounesios]

João Távora [2022-09-30 12:38 +0100] wrote:

> On Fri, Sep 30, 2022 at 12:33 PM Basil L. Contovounesios <contovob@tcd.ie> wrote:
>
>  > I can only agree.  Especially because there are a number of packages
>  > starting with "el...", which makes misreading the package name as
>  > "elgot" very easy (which is still how I pronounce the package when
>  > speaking to this day).
>
>  If we just changed the default language of Emacs to Greek, "Eglot" would
>  automatically become a lot more palatable ;).  Maybe for Emacs 30 🤞.
>
> Google translate doesn't get the pun,

No pun; the Greek root glot is equivalent to Latin lingua (and English
tongue), so to me "Eglot" isn't jarring at all and is sufficiently
descriptive.

> but it does tell me that "eglot" is latvian
> for "spruce up".  So yeah, I was totally thinking latvian.

Language Sprucing Protocol has my vote.

-- 
Basil

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Fri, Sep 30, 2022 at 1:18 PM Basil L. Contovounesios <contovob@tcd.ie>
wrote:

> João Távora [2022-09-30 12:38 +0100] wrote:
>
> > On Fri, Sep 30, 2022 at 12:33 PM Basil L. Contovounesios <
> contovob@tcd.ie> wrote:
> >
> >  > I can only agree.  Especially because there are a number of packages
> >  > starting with "el...", which makes misreading the package name as
> >  > "elgot" very easy (which is still how I pronounce the package when
> >  > speaking to this day).
> >
> >  If we just changed the default language of Emacs to Greek, "Eglot" would
> >  automatically become a lot more palatable ;).  Maybe for Emacs 30 🤞.
> >
> > Google translate doesn't get the pun,
>
> No pun; the Greek root glot is equivalent to Latin lingua (and English
> tongue), so to me "Eglot" isn't jarring at all and is sufficiently
> descriptive.
>

Doh, of course. I'm a bit embarassed, I forgot portuguese has so many words
of Greek origin (glote means throat, for example).

João

[-- Attachment #2: Type: text/html, Size: 1519 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Rudolf Adamkovič]

Theodor Thornhill <theo@thornhill.no> writes:

> I don't understand why referring to it by what it actually is is a
> problem.  In this case, elsp, or elsp-mode seems like the obvious
> choice, considering that the better name already is taken.

+1 but all the way through, i.e. drop the nonsensical 'e'.

The official website [0] calls Eglot an "LSP client".  So, why cannot we
say that?  LSP Client mode.  I find 'lsp-client' descriptive, and less
cryptic, than 'elsp'.  And it also matches the official nomenclature.

[0]: https://langserver.org/

Rudy
-- 
"Chop your own wood and it will warm you twice."
-- Henry Ford; Francis Kinloch, 1819; Henry David Thoreau, 1854

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Renaming eglot -- or at least add an alias?

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> As for names, lsp-mode would be the obvious choice, but some other
> package has occupied that prefix (too bad).  I therefore propose
> renaming it to elsp-mode and using the elsp-* prefix for it.

I think "eglot" is a fine name, and we shouldn't change it.

(And "elsp" sounds like somebody was typing "elisp" in a hurry.  🙂)

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Daniel Martín <mardani29@yahoo.es> writes:

> Right now under "Maining Large Programs" in the Emacs manual the closest
> package to Eglot is EDE (Emacs Development Environment), so perhaps the
> name could be EDE-LSP or something like that.

What does Eglot have to do with EDE exactly?

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Daniel Martín <mardani29@yahoo.es> writes:

> After a second look, perhaps Semantic is a closer match (under "Editing
> Programs"), so the name could be Semantic-LSP.

But eglot is not at all related to Semantic, and I cannot simply type
"C-c , J" in a buffer with Eglot enabled to jump to a given tag.  (Does
LSP even generate tags?)

Re: Renaming eglot -- or at least add an alias?

[Robert Pluim]

>>>>> On Fri, 30 Sep 2022 14:33:17 +0300, "Basil L. Contovounesios" <contovob@tcd.ie> said:

    Basil> If we just changed the default language of Emacs to Greek, "Eglot" would
    Basil> automatically become a lot more palatable ;).  Maybe for Emacs 30 🤞.

Classical Greek or Modern Greek? I do admit I spell 'λ' with a 'b' 😀

Robert
-- 

Re: Renaming eglot -- or at least add an alias?

[Basil L. Contovounesios]

Robert Pluim [2022-09-30 15:26 +0200] wrote:

>>>>>> On Fri, 30 Sep 2022 14:33:17 +0300, "Basil L. Contovounesios" <contovob@tcd.ie> said:
>
>     Basil> If we just changed the default language of Emacs to Greek, "Eglot" would
>     Basil> automatically become a lot more palatable ;).  Maybe for Emacs 30 🤞.
>
> Classical Greek or Modern Greek?

Emacs strikes me as more of a Modern Classic.

> I do admit I spell 'λ' with a 'b' 😀

What's next?  Spelling 'π' with numbers?!

-- 
Basil

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Sorry, no.  We will not start a dispute about renaming eglot, because
  > that would delay its merge, and we don't have time for that luxury.
  > We want eglot to be part of Emacs 29.

We can make this decision in a week.

Now, before including a package in Emacs, is the last good time
to choose a helpful name.

The policy that "We have left the issue so long that it is too late to
choose a better name" leads predictably to accumulation of unhelpful
names.  I speculate that this has been at work for decades, resulting
in so many unhelpful package names now in Emacs.

  > As for more basic arguments why not rename it: this package is not a
  > new one, it is used by many people as a 3rd-party package.

We can keep `eglot' as an alias for years or decades, or forever,
if we choose a helpful name as the principal one.

If there is no workable way to define alias names for packages, we
should create one now.  The crucial thing is to have the various names
in the _list of packages_, with the more helpful name preferred.

The names of the package's entry points are less crucial.  We know how
to give them aliases, but if they are numerous, that would be more
nuisance than it's worth.  How many entry points does this package
actually have?

Given the existence of multiple packages for dealing with language
servers, calling one of them just "language server" or "lsp" seems
bad.  Rather, helpful names will show people (1) what job all these
packages do and (2) that they are different ways to do it.

Ideally, also, also what is special about each of these packags, if we
can come up with good ways to do that.  It may not be practical.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 01 Oct 2022 05:28:53 -0400
> 
>   > Sorry, no.  We will not start a dispute about renaming eglot, because
>   > that would delay its merge, and we don't have time for that luxury.
>   > We want eglot to be part of Emacs 29.
> 
> We can make this decision in a week.

That's not possible, not with these decisions.

And even a week's delay is too much.

>   > As for more basic arguments why not rename it: this package is not a
>   > new one, it is used by many people as a 3rd-party package.
> 
> We can keep `eglot' as an alias for years or decades, or forever,
> if we choose a helpful name as the principal one.
> 
> If there is no workable way to define alias names for packages, we
> should create one now.

That again is not something to consider so close to cutting the
release branch.  We have enough to do with landing Eglot to keep us
busy till then.

> The crucial thing is to have the various names
> in the _list of packages_, with the more helpful name preferred.

One more package with a name that needs a description is not a
catastrophe.  We already have a few.

Please help me get Emacs 29 on time and also with enough features to
justify a major release.  I _need_ that help, and I need the
understanding to go with it.  I do NOT need proposals that will make
the job harder.  Please bear with me.

Re: Renaming eglot -- or at least add an alias?

[Stefan Monnier]

>   > Sorry, no.  We will not start a dispute about renaming eglot, because
>   > that would delay its merge, and we don't have time for that luxury.
>   > We want eglot to be part of Emacs 29.
>
> We can make this decision in a week.
>
> Now, before including a package in Emacs, is the last good time
> to choose a helpful name.

I don't see any reason why Emacs has to follow Apple's footsteps and
call one of its MUAs "Mail", one of its LSP clients "LSP", etc..

Emacs is about choice, so while as Emacs maintainers we do spend a fair
bit of time trying to consolidate the various options out there so as to
reduce the need for users to make choices, we should force packages to
be named after their functionality, since that leads to inevitably more
name conflicts.

And in the present case, for *very* little benefit since the name "LSP"
is not nearly as widely known as you might expect: most users don't look
for an "LSP client" (because they have no idea what is "LSP") but they
look for some way to get maybe some "IDE functionality" or "code
completion" or things like that.


        Stefan

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 01 Oct 2022 05:28:53 -0400
>> 
>>   > Sorry, no.  We will not start a dispute about renaming eglot, because
>>   > that would delay its merge, and we don't have time for that luxury.
>>   > We want eglot to be part of Emacs 29.
>> 
>> We can make this decision in a week.
>
> That's not possible, not with these decisions.
>
> And even a week's delay is too much.

I don't know what decisions have been made, but is there a reason why
delays aren't possible?  Is there some deadline?  Or is this just a
"principle thing", to avoid pushing the deadline ahead all the time?

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 01 Oct 2022 15:33:34 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Richard Stallman <rms@gnu.org>
> >> Cc: emacs-devel@gnu.org
> >> Date: Sat, 01 Oct 2022 05:28:53 -0400
> >> 
> >>   > Sorry, no.  We will not start a dispute about renaming eglot, because
> >>   > that would delay its merge, and we don't have time for that luxury.
> >>   > We want eglot to be part of Emacs 29.
> >> 
> >> We can make this decision in a week.
> >
> > That's not possible, not with these decisions.
> >
> > And even a week's delay is too much.
> 
> I don't know what decisions have been made, but is there a reason why
> delays aren't possible?  Is there some deadline?

The deadline is that we want to have Eglot in Emacs 29, and the
release branch is expected in late November.

Re: Renaming eglot -- or at least add an alias?

[Stefan Monnier]

> Emacs is about choice, so while as Emacs maintainers we do spend a fair
> bit of time trying to consolidate the various options out there so as to
> reduce the need for users to make choices, we should force packages to
                                                      ^
                                                     not

Duh!


        Stefan

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Sorry, no.  We will not start a dispute about renaming eglot, because
>   > that would delay its merge, and we don't have time for that luxury.
>   > We want eglot to be part of Emacs 29.
>
> We can make this decision in a week.
>
> Now, before including a package in Emacs, is the last good time
> to choose a helpful name.
>
> The policy that "We have left the issue so long that it is too late to
> choose a better name" leads predictably to accumulation of unhelpful
> names.  I speculate that this has been at work for decades, resulting
> in so many unhelpful package names now in Emacs.
>
>   > As for more basic arguments why not rename it: this package is not a
>   > new one, it is used by many people as a 3rd-party package.
>
> We can keep `eglot' as an alias for years or decades, or forever,
> if we choose a helpful name as the principal one.
>
> If there is no workable way to define alias names for packages, we
> should create one now.  The crucial thing is to have the various names
> in the _list of packages_, with the more helpful name preferred.
>
> The names of the package's entry points are less crucial.  We know how
> to give them aliases, but if they are numerous, that would be more
> nuisance than it's worth.  How many entry points does this package
> actually have?
>
> Given the existence of multiple packages for dealing with language
> servers, calling one of them just "language server" or "lsp" seems
> bad.  Rather, helpful names will show people (1) what job all these
> packages do and (2) that they are different ways to do it.
>
> Ideally, also, also what is special about each of these packags, if we
> can come up with good ways to do that.  It may not be practical.

While I can agree with the sentiment underlying this, I'm not sure I
agree with the practicality. The space of available meaningful names
which convey a meaningful description of what a module/library does
which are also not ridiculously long and are unique is actually quite
small. Naming things is difficult.

Given the most obvious and descriptive names are already taken, combined
with the fact eglot is already well known and scattered through
documentation and web pages all over the net, the pressure and tight
time line to get out Emacs 29 and the fact none of the suggested
alternative names are any more informative than eglot (many likely to
cause confusion with elisp and other elisp utilities), I think accept
this one and move on.

In reality, very few packages/modules actually provide any real meaning
based on just their name. It is too short to convey much. It is the
package description we rely on. In some ways, a distinctive name like
eglot is actually a positive - when I see it, I say "Hmm, I wonder what
that is?" and look at the description. Due to its distinctive name, I
will also remember that and what it does.

I also note that eglot is likely going to struggle to gain acceptance
over lsp-mode, which definitely has a much larger user base. Being
bundled in Emacs will certainly help. However, trying to change names
now will not help and runs the risk of further confusing the user base.

Besides, eglot aka Emacs Polyglot isn't a bad name and nothing better
has been proposed.

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No pun; the Greek root glot is equivalent to Latin lingua (and English
  > tongue), so to me "Eglot" isn't jarring at all and is sufficiently
  > descriptive.

I know about that Greek root, but the name "Eglot" conveys no meaning
to me.  If we imagina thet the package's name were "E-lanmguage", it
would still convey no meaning to me.  So many things in Emacs are
related to languages (either human or programming) and do different
things with them, that this doesn't say much.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Now, before including a package in Emacs, is the last good time
  > > to choose a helpful name.

  > I don't see any reason why Emacs has to follow Apple's footsteps and
  > call one of its MUAs "Mail", one of its LSP clients "LSP", etc..

I agree with you about that.  The idea of calling it "LSP" did not
come from me; that is not a particularly helpful name, anyway.  Most
users won't know what that means.  I said so in the message you're
replying to.

What I argue for is that we should give it a name that clearly says
what job it does.  There are many ways to do that.

  > Emacs is about choice, so while as Emacs maintainers we do spend a fair
  > bit of time trying to consolidate the various options out there so as to
  > reduce the need for users to make choices, we should force packages to
  > be named after their functionality, since that leads to inevitably more
  > name conflicts.

I agree, but I think we're miscommunicating.


Can anyone suggest a way to describe the job that Eglot does, NOT
using technical jargon, or implementation details such as "LSP"?
Would the word "parse" be good?  "Code-analyze"?
I never used Eglot so I don't know what it does.




-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

>
> Can anyone suggest a way to describe the job that Eglot does, NOT
> using technical jargon, or implementation details such as "LSP"?

Isn't that the crux of the issue - it seems nobody has any suggestion
any better than eglot. Quite a few of the suggestion are worse.

One thing you could do is just call the package eglot-lsp, which might
give you the additional name info you seem to desire. The package
namespace could remain eglot-*, so perhaps would not have the overhead
and delay to release of Emacs 29 which a full rename would cause. 

Personally, I would just stick with eglot as I think this whole argument
regarding the need for package names to describe their functionality is
misguided. Great if you can do it, but should not be a necessity. 

In general, it seems only very simple and single purpose packages lend
themselves to clear descriptive names. For example, tempo, skeleton and
flycheck. Few packages which perform multiple functions seem to have the
sort of descriptive name you are after. The name closest to function I
can think of for eglot would be lsp-client, but that is too close to
lsp-mode and in general, too close to 'lisp' and 'elisp'. Using the full
name i.e. language-server-protocol-client is cumbersome, we be shortened
in actual use and will likely result in confusion with lsp-mode.  

A good name is the one which you can easily remember and
communicate. Once you are told what eglot does, you will remember
it. You don't need its function to be in the name.

> Would the word "parse" be good?  "Code-analyze"?
> I never used Eglot so I don't know what it does.

No, none of those words/terms are appropriate. Eglot is essentially just
a client for servers which implement the language server protocol. It
simply takes the data provided by those servers and uses it to annotate
your code using flymake. It is just the glue between a language server
and flymake - we could call it language-glue or ide-glue! Neither are
jargon or too technical (I doubt IDE is considered jargon or technical
these days). 

If you are going to insist on a new name, I would suggest you also need
to understand what eglot is and what the language server protocol
architecture is about. Without these key elements, you are unlikely to
be in a position to judge the suitability of the name.

See for example

https://whatacold.io/blog/2022-01-22-emacs-eglot-lsp/
https://langserver.org/

Re: Renaming eglot -- or at least add an alias?

[Yilkal Argaw]

> Personally, I would just stick with eglot as I think this whole argument
> regarding the need for package names to describe their functionality is
> misguided. Great if you can do it, but should not be a necessity.

I agree. There is also the issue of the already established user base
and documentation (including unofficial documentation that accumulated
over the life cycle of the package by users documenting how they use
it, how people should use, solutions to questions and issues etc). I
don't think it is possible to backtrack and change them all to refer
to a new name.

“Who knows a man's name, holds that man's life in his keeping”
― Ursula K. Le Guin, A Wizard of Earthsea

with regards
Yilkal A.

On Sun, Oct 2, 2022 at 5:28 AM Tim Cross <theophilusx@gmail.com> wrote:
>
>
> Richard Stallman <rms@gnu.org> writes:
>
> >
> > Can anyone suggest a way to describe the job that Eglot does, NOT
> > using technical jargon, or implementation details such as "LSP"?
>
> Isn't that the crux of the issue - it seems nobody has any suggestion
> any better than eglot. Quite a few of the suggestion are worse.
>
> One thing you could do is just call the package eglot-lsp, which might
> give you the additional name info you seem to desire. The package
> namespace could remain eglot-*, so perhaps would not have the overhead
> and delay to release of Emacs 29 which a full rename would cause.
>
> Personally, I would just stick with eglot as I think this whole argument
> regarding the need for package names to describe their functionality is
> misguided. Great if you can do it, but should not be a necessity.
>
> In general, it seems only very simple and single purpose packages lend
> themselves to clear descriptive names. For example, tempo, skeleton and
> flycheck. Few packages which perform multiple functions seem to have the
> sort of descriptive name you are after. The name closest to function I
> can think of for eglot would be lsp-client, but that is too close to
> lsp-mode and in general, too close to 'lisp' and 'elisp'. Using the full
> name i.e. language-server-protocol-client is cumbersome, we be shortened
> in actual use and will likely result in confusion with lsp-mode.
>
> A good name is the one which you can easily remember and
> communicate. Once you are told what eglot does, you will remember
> it. You don't need its function to be in the name.
>
> > Would the word "parse" be good?  "Code-analyze"?
> > I never used Eglot so I don't know what it does.
>
> No, none of those words/terms are appropriate. Eglot is essentially just
> a client for servers which implement the language server protocol. It
> simply takes the data provided by those servers and uses it to annotate
> your code using flymake. It is just the glue between a language server
> and flymake - we could call it language-glue or ide-glue! Neither are
> jargon or too technical (I doubt IDE is considered jargon or technical
> these days).
>
> If you are going to insist on a new name, I would suggest you also need
> to understand what eglot is and what the language server protocol
> architecture is about. Without these key elements, you are unlikely to
> be in a position to judge the suitability of the name.
>
> See for example
>
> https://whatacold.io/blog/2022-01-22-emacs-eglot-lsp/
> https://langserver.org/
>

Re: Renaming eglot -- or at least add an alias?

[Christopher M. Miles]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]


Stefan Kangas <stefankangas@gmail.com> writes:

> Hi all, João,
>
> Now that we're getting closer to merging eglot, I think it is our last
> chance to (re-)consider that "eglot" is not the ideal name.  It has some
> charm, of course, but it is quite non-descriptive and it's hard (read:
> impossible) to understand what it does based on the name alone.[1]
>
> As for names, lsp-mode would be the obvious choice, but some other
> package has occupied that prefix (too bad).  I therefore propose
> renaming it to elsp-mode and using the elsp-* prefix for it.
>

I agree, eglot really is not a good obvious name for understand what it does.

> At the very least, we should consider adding some alias, like
> `start-lsp', and/or `lsp-start'.[2]
>
> Footnotes:
> [1]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02828.html
>
> [2]  https://lists.gnu.org/r/emacs-devel/2020-05/msg02818.html


-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Tim Cross <theophilusx@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Can anyone suggest a way to describe the job that Eglot does, NOT
>> using technical jargon, or implementation details such as "LSP"?

Some ideas of the top of my head:

- ide-mode
- integrated-development-mode
- {smart,intelligent,clever}-mode
- programming-mode
- syntax-mode

I don't even think it is necessary to rename the implementation as long
as at least one auto-loaded alias is available.

> Isn't that the crux of the issue - it seems nobody has any suggestion
> any better than eglot. Quite a few of the suggestion are worse.

Which ones were worse?  The only one I recall was "Elsp", as it is just
one letter away from "Elisp".

> One thing you could do is just call the package eglot-lsp, which might
> give you the additional name info you seem to desire. The package
> namespace could remain eglot-*, so perhaps would not have the overhead
> and delay to release of Emacs 29 which a full rename would cause. 

> Personally, I would just stick with eglot as I think this whole argument
> regarding the need for package names to describe their functionality is
> misguided. Great if you can do it, but should not be a necessity. 
>
> In general, it seems only very simple and single purpose packages lend
> themselves to clear descriptive names. For example, tempo, skeleton and
> flycheck. 

I wouldn't say that tempo or skeleton are descriptive...

>           Few packages which perform multiple functions seem to have the
> sort of descriptive name you are after. The name closest to function I
> can think of for eglot would be lsp-client, but that is too close to
> lsp-mode and in general, too close to 'lisp' and 'elisp'. Using the full
> name i.e. language-server-protocol-client is cumbersome, we be shortened
> in actual use and will likely result in confusion with lsp-mode.  
>
> A good name is the one which you can easily remember and
> communicate. Once you are told what eglot does, you will remember
> it. You don't need its function to be in the name.

I've said it before, but "eglot" is a particularly bad name in this
respect and harder to memorise.  The idea behind the name (Emacs
polyGLOT) is not intuitive.  Upon hearing it for the first time you
might as well think it is called "egg-lot" or "iglot", it is easy to
misread it as "elgot".  All of which make about as much sense to someone
who is learning about this for the first time.

Either way, I see this as a particularly short-sighted way to look at
the issue.  It might be the easier option right now, but I expect many
users in the future to stumble over this issue for no reason at all.

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

On Sun, Oct 2, 2022 at 12:34 PM Philip Kaludercic <philipk@posteo.net>
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).

I have no problem admitting "Emacs polyglot" is mostly a half-assed pretext
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 part
of, I comprehend that. You can't always please everyone.

> 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.

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

João

[-- Attachment #2: Type: text/html, Size: 2214 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> On Sun, Oct 2, 2022 at 12:34 PM Philip Kaludercic <philipk@posteo.net>
> 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)

> I have no problem admitting "Emacs polyglot" is mostly a half-assed pretext
> 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 part
> 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.

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.

> João

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

On Sun, Oct 2, 2022 at 3:05 PM Philip Kaludercic <philipk@posteo.net> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > 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.
>

Those are all phrases in disguise.  Even "hl" is really two things.

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.

None of this makes any difference to the fact that Eglot is the best
name for referring to exactly what Eglot is.

João

[-- Attachment #2: Type: text/html, Size: 1837 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Manuel Uberti]

On 02/10/22 16:42, João Távora wrote:
> None of this makes any difference to the fact that Eglot is the best
> name for referring to exactly what Eglot is.

FWIW, because I seem to be in the minority here, I really like the name 
Eglot.

To me the name is:

- Clear enough: "glot" makes sense to me, just as the "e" makes me think 
of "emacs" or "elisp" when it's the first letter of an Emacs package 
name (it may not always mean that, of course).

- Short enough: I can quickly type `M-x eglot` and work with whatever 
project I have on my hands.

- Unique enough: I only have to learn what it is about once to refer to 
it or use it without mistakenly thinking of something else.

As long as Eglot comes up when looking for "Emacs LSP" in the manual (or 
on the web), is the name really an issue?

-- 
Manuel Uberti
https://manueluberti.eu

Re: Renaming eglot -- or at least add an alias?

[Lars Ingebrigtsen]

Manuel Uberti <manuel.uberti@inventati.org> writes:

> FWIW, because I seem to be in the minority here, I really like the
> name Eglot.

I don't think you are -- many people have weighed in saying they like
the name.  It's just that the people that want a change feel the need to
talk more, which is natural.

(Spoiler warning: The name isn't going to change.)

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> On Sun, Oct 2, 2022 at 3:05 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > 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.
>>
>
> Those are all phrases in disguise.  Even "hl" is really two things.

I guess so?                           What is the other thing?

> 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, 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.

> None of this makes any difference to the fact that Eglot is the best
> name for referring to exactly what Eglot is.

Tautologically yes, but this is too abstract.  The question others and I
are raising is whether or not the function of Eglot is best described by
the name "Eglot", for nothing more than the practical issue of feature
discovery and ease of remembering a name.

> João

Also, do you have comments on the other suggestions form my previous
message?

Re: Renaming eglot -- or at least add an alias?

[Jose A. Ortega Ruiz]

On Sun, Oct 02 2022, Manuel Uberti wrote:

> On 02/10/22 16:42, João Távora wrote:
>> None of this makes any difference to the fact that Eglot is the best
>> name for referring to exactly what Eglot is.
>
> FWIW, because I seem to be in the minority here, I really like the name Eglot.

FWIW, let me mention that i absolutely agree with you, for essentially
the same reasons as you, and also:

  - using a search engine to get help about something not working for
    'eglot' is much easier than any of the "discoverable" alternatives;

  - original names are part of the joy of programming, and developers
    working hard for free software do deserve some joy (exaggerating,
    should we rename emacs to "editor" and GNU to
    "free-operating-system-similar-to-unix"? :))

cheers,
jao
-- 
Nobody made a greater mistake than he who did nothing because he could
do only a little. -Edmund Burke, statesman and writer (1729-1797)

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

On Sun, Oct 2, 2022 at 4:52 PM Philip Kaludercic <philipk@posteo.net> wrote:

> > 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.

> > 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 something
that enhances Emacs (also tried to carry the meaning of "joke" in my
destitute sense of humor).

> 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".

> 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. Language
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.

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 structure.

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 bug
reports. I recommend M-x eglot instead.

> > None of this makes any difference to the fact that Eglot is the best
> > name for referring to exactly what Eglot is.
>
> Tautologically yes, but this is too abstract.

Names, signs, are abstract indirections. What's in a name? That which
we call Eglot by any other name would just as many bugs I should
probably be focusing on.

(With apologies to W. Shakespeare)
João

[-- Attachment #2: Type: text/html, Size: 3240 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Philip Kaludercic <philipk@posteo.net> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> On Sun, Oct 2, 2022 at 12:34 PM Philip Kaludercic <philipk@posteo.net>
>> 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. 

>> I have no problem admitting "Emacs polyglot" is mostly a half-assed pretext
>> 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 part
>> 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? 

>
> 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.

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

>
>   - using a search engine to get help about something not working for
>     'eglot' is much easier than any of the "discoverable" alternatives;
>

This is an extremely good point. Imagine searching for ide-mode?

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The deadline is that we want to have Eglot in Emacs 29, and the
  > release branch is expected in late November.

Isn't that up to us?  If we make this branch in January, that wait
would not be a problem.

It is good to make a plan, but there is no need to be rigid about it.
When we have a choice to make, that would be hard to change later,
it's worth delaying so as to make the eight choice.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > While I can agree with the sentiment underlying this, I'm not sure I
  > agree with the practicality. The space of available meaningful names
  > which convey a meaningful description of what a module/library does
  > which are also not ridiculously long and are unique is actually quite
  > small. Naming things is difficult.

I am reputed to be good at that.  nstead of telling me how hopeless it
is, which won't convince me, how about telling me what Eglot does?
Then we'll see if I come up with a more descriptive name.

  > In reality, very few packages/modules actually provide any real meaning
  > based on just their name.

Yes, we could do a lot better.

  > However, trying to change names
  > now will not help and runs the risk of further confusing the user base.

It's amazing how quickly people start saying it's too late to change
something.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > While I can agree with the sentiment underlying this, I'm not sure I
>   > agree with the practicality. The space of available meaningful names
>   > which convey a meaningful description of what a module/library does
>   > which are also not ridiculously long and are unique is actually quite
>   > small. Naming things is difficult.
>
> I am reputed to be good at that.  nstead of telling me how hopeless it
> is, which won't convince me, how about telling me what Eglot does?
> Then we'll see if I come up with a more descriptive name.
>
No, I'm not the one pushing for the change. It is your responsibility to
actually understand what eglot is if your going to argue the name needs
changing. How else are you going to assess if any proposed names are
appropriate?

Besides, I included links which explain what it is which you
could go and read as easily as me writing it up for you.  

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> I am reputed to be good at that.  nstead of telling me how hopeless it
> is, which won't convince me, how about telling me what Eglot does?
> Then we'll see if I come up with a more descriptive name.

It uses an external program speaking the language server protocol to
provide completion-at-point and cross-referencing (think
xref-find-references and xref-find-definitions.)

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> I am reputed to be good at that.  nstead of telling me how hopeless it
>> is, which won't convince me, how about telling me what Eglot does?
>> Then we'll see if I come up with a more descriptive name.
>
> It uses an external program speaking the language server protocol to
> provide completion-at-point and cross-referencing (think
> xref-find-references and xref-find-definitions.)

and a fair bit more like

- code snippets
- code diagnostics and linting
- enhanced documentation and feeds into eldoc
- provide code actions to fix diagnostic/linter errors or suggest code
  refactoring 
- hovering over symbols provides function signatures/documentation
- symbol renaming and other refactoring support
 
Note that what functionality is provided depends largely on what
functionality is supported by the specific language server being
used. All of the above may not be available in all language servers. It
isn't eglot which does any of this - eglot is just the client. The
language server is what does the work - eglot just feeds that data into
other Emacs facilities, like eldoc, flymake etc.

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Tim Cross <theophilusx@gmail.com> writes:

>> 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? 

Because Elgot is being merged into the core?  Also, as I say this
doesn't have to be a direct alias.  I can imagine an xref-like backend
system where Elgot is just one of the implementations.

>> 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. 

This is a cliche, and an inaccurate one on top of that.  Emacs isn't a
blank slate where you pick and choose everything.  Many things are
"forced" upon users: Why does Xref use TAGS-files by default?  Why is
font-locking enabled by default?  Why is anything bound at all?  Why are
any packages even bundled with Emacs in the first place?

What you say is a common impression because a lot of "modern"
functionality is missing OOTB, like the stuff that Elgot provides.  The
reason why packages are bundled is because Emacs ought to be useful.
Elgot does a good job at "super-charging" xref, imenu, capf, etc. so
UI-wise nothing is changed, just improved.

That being said, there are at least two points that should be considered
before 29.1 is released:

- The rebinding of `display-local-help'.  I don't get why this is done.
- The custom mode-line modification instead of eglot being just another
  minor mode item.

>        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).

Ok, but that is already something that Elgot handles with
`eglot-server-programs', right?

> 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.

Even if this might be the case (Lars indicated that it is so), I at
least want to have made a serious effort at trying to find an
alternative.

> 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. 

Not sure about that, the main reason I think was that due to the
approaching release of Emacs 29.1 we don't have the time to properly
rename the package.  Which is why I have just been asking for an alias.
Some name where if someone asks me in person how to enable
auto-completion, the next question isn't "How do I spell that?" or "What
was that name again?".

It seems to me that most people in support of "Eglot" as a name reject
everything else because it isn't perfect or an exact description.  As if
there is only a hypothetical, ideal name and everything else is equally
inadequate, whether "elgot", "eglot", "ide-mode", "foobarbaz" or
"chair".

>      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.

In general yes, when an important feature like this is being merged into
the core, then I think it is absolutely reasonable to question something
like this.

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

João Távora <joaotavora@gmail.com> writes:

> On Sun, Oct 2, 2022 at 4:52 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
>> > 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 something
> 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. Language
> 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 structure.

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 bug
> 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.

Re: Renaming eglot -- or at least add an alias?

[João Távora]

Philip Kaludercic <philipk@posteo.net> writes:

>
> That being said, there are at least two points that should be considered
> before 29.1 is released:
>
> - The rebinding of `display-local-help'.  I don't get why this is
> done.

display-local-help is a generic at-point documentation facility.  It
comes with a default binding in the Emacs global map.  M-x eldoc does
not have a default binding (yet).  d-l-help is also a much poorer
version of what ElDoc is nowadays.  Contrary to ElDoc, there is no easy
way for Eglot to link d-l-help it up to LSP-provided documentation.

It's not fully accurate to say that Eglot rebinds `display-local-help`,
at least not permanently.  Rather, for the duration of Eglot's tenure
over the buffer(s), some settings known to work are applied including
binding the 'C-h .' key to an ElDoc command.

A demanding user can override any of these settings.  Read
https://github.com/joaotavora/eglot/blob/master/MANUAL.md#overriding-eglots-choices

> - The custom mode-line modification instead of eglot being just another
>   minor mode item.

The information that Eglot displays in the mode-line is important to
signal if/how it is managing the buffer.  It could be grouped with the
other minor modes, but I felt that it would take up too much space and
look akward in that position, so I moved it to the side.

> > 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?

Of course, but I said nothing to the contrary.  I merely meant that it
is good for Eglot's user to remember that this enriched capability and
consistency is supported _transiently_ for a well-defined subset of the
buffers being worked on, and that potentially a third-party helper (the
language server program) must be installed to support more buffers.

There is a very broad applicability of Emacs to many types of uses and
very many language servers that may or not be available (probably won't
be by default).

The user should not assume that just by launching the Emacs editor, the
superior capability will be available all the time, because that
requires a piece that is not (and cannot easily be) bundled with Emacs.

You may, if you want, make an Emacs distribution with a narrower focus
on a specific application where the former is true.  See
https://portacle.github.io/, which brands itself as a "Common Lisp IDE".
There Emacs is bundled with SLIME and SLY turned on by default.

> We enthusiasts often overestimate the readiness of more casual users
> when it comes to remembering commands, bindings, packages, etc.

I think you underestimate users' ability (and maybe also your own?) to
remember a single 5 letter name.  Eglot has few commands, few
customization variables, no bindings.  It's as minimalist as I and those
who helped could make it.  For a beginner, M-x eglot is all there is to
it.

João

Re: Renaming eglot -- or at least add an alias?

[Stefan Monnier]

>> - The rebinding of `display-local-help'.  I don't get why this is done.
>
> display-local-help is a generic at-point documentation facility.  It
> comes with a default binding in the Emacs global map.  M-x eldoc does
> not have a default binding (yet).  d-l-help is also a much poorer
> version of what ElDoc is nowadays.  Contrary to ElDoc, there is no easy
> way for Eglot to link d-l-help it up to LSP-provided documentation.

Oh... help-at-pt... yes that one needs love (and maybe integration with
eldoc-mode).

> I think you underestimate users' ability (and maybe also your own?) to
> remember a single 5 letter name.  Eglot has few commands, few
> customization variables, no bindings.  It's as minimalist as I and those
> who helped could make it.  For a beginner, M-x eglot is all there is to
> it.

I could also imagine auto-enabling Eglot when the circumstances are
right (e.g. when the major modes's own support code is not very well
developed, and when we can see that a good LSP server is available)
making even `M-x eglot` unnecessary.


        Stefan

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, emacs-devel@gnu.org
> Date: Sun, 02 Oct 2022 21:06:01 -0400
> 
>   > The deadline is that we want to have Eglot in Emacs 29, and the
>   > release branch is expected in late November.
> 
> Isn't that up to us?  If we make this branch in January, that wait
> would not be a problem.

It's up to us, but I would like to make a good-faith effort to keep
the deadline.  Otherwise, why make a decision if we back up on it at
the first opportunity?

> It is good to make a plan, but there is no need to be rigid about it.
> When we have a choice to make, that would be hard to change later,
> it's worth delaying so as to make the eight choice.

I'd like to reserve delay decisions for serious problems.  My
experience is that if we allow the deadline to slip too easily, we
will keep delaying it, and very quickly find ourself in August rather
than January.  And this problem is nowhere near being serious enough.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 02 Oct 2022 21:07:30 -0400
> 
>   > However, trying to change names
>   > now will not help and runs the risk of further confusing the user base.
> 
> It's amazing how quickly people start saying it's too late to change
> something.

That's on purpose: we are trying to speed up the Emacs release cycle,
something that is a long-standing issue that users complain about.

Re: Renaming eglot -- or at least add an alias?

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> - The rebinding of `display-local-help'.  I don't get why this is done.
>>
> Oh... help-at-pt... yes that one needs love (and maybe integration with
> eldoc-mode).

Yes, precisely, integration.  Maybe its just a question of adding a
default value of eldoc-documentation-functions that has help-at-pt's
simplistic text-property-based logic.  Then rebinding C-h . to some
eldoc entry point that targets the echo area only.  The latter can be
done with eldoc-display-functions, but if full compatibility isn't
absolutely essential, I'd say 'C-h .' is a pretty good candidate to be
bound to M-x eldoc.

>> I think you underestimate users' ability (and maybe also your own?) to
>> remember a single 5 letter name.  Eglot has few commands, few
>> customization variables, no bindings.  It's as minimalist as I and those
>> who helped could make it.  For a beginner, M-x eglot is all there is to
>> it.
>
> I could also imagine auto-enabling Eglot when the circumstances are
> right (e.g. when the major modes's own support code is not very well
> developed, and when we can see that a good LSP server is available)
> making even `M-x eglot` unnecessary.

I'm on the fence about that.  If hypothetically we did that, the problem
would be that launching a future such Emacs to edit source code of a
given mode in two different machine -- one has the server, the other
hasn't -- has too much discrepant behavior.  There are already other
places where behavior is dependent on the availability of an external
program, but I think it would be less pronouced than Eglot vs no-Eglot.

João

Re: Renaming eglot -- or at least add an alias?

[Stefan Monnier]

>>>> - The rebinding of `display-local-help'.  I don't get why this is done.
>>>
>> Oh... help-at-pt... yes that one needs love (and maybe integration with
>> eldoc-mode).
> Yes, precisely, integration.  Maybe its just a question of adding a
> default value of eldoc-documentation-functions that has help-at-pt's
> simplistic text-property-based logic.

I haven't looked at all that help-at-pt offers, but it does sound about right.

> Then rebinding C-h . to some eldoc entry point that targets the echo
> area only.

I can't see any reason why we should stick to the echo area only.

> if full compatibility isn't absolutely essential, I'd say 'C-h .' is
> a pretty good candidate to be bound to M-x eldoc.

Sounds about right as well.

>>> I think you underestimate users' ability (and maybe also your own?) to
>>> remember a single 5 letter name.  Eglot has few commands, few
>>> customization variables, no bindings.  It's as minimalist as I and those
>>> who helped could make it.  For a beginner, M-x eglot is all there is to
>>> it.
>>
>> I could also imagine auto-enabling Eglot when the circumstances are
>> right (e.g. when the major modes's own support code is not very well
>> developed, and when we can see that a good LSP server is available)
>> making even `M-x eglot` unnecessary.
>
> I'm on the fence about that.  If hypothetically we did that, the problem
> would be that launching a future such Emacs to edit source code of a
> given mode in two different machine -- one has the server, the other
> hasn't -- has too much discrepant behavior.  There are already other
> places where behavior is dependent on the availability of an external
> program, but I think it would be less pronouced than Eglot vs no-Eglot.

In any case, I think it's pretty hypothetical at this point.
There's no need yet to decide how we'll cross that bridge.


        Stefan

Re: Renaming eglot -- or at least add an alias?

[Rudolf Adamkovič]

Richard Stallman <rms@gnu.org> writes:

> I am reputed to be good at that.  nstead of telling me how hopeless it
> is, which won't convince me, how about telling me what Eglot does?
> Then we'll see if I come up with a more descriptive name.

Love the spirit!

Eglot assists programmers.  Think tags but better, e.g. not only "jump
to symbol" but also "rename symbol".  It uses LSP behind the scenes.

Rudy
-- 
"Programming reliably -- must be an activity of an undeniably
mathematical nature […] You see, mathematics is about thinking, and
doing mathematics is always trying to think as well as possible."
-- Edsger W. Dijkstra, 1981

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FWIW, let me mention that i absolutely agree with you, for essentially
  > the same reasons as you, and also:

  >   - using a search engine to get help about something not working for
  >     'eglot' is much easier than any of the "discoverable" alternatives;

We should try harder to find clearer alternatives to consider, before
conclusing it can't be done.

    > - original names are part of the joy of programming,

There is plenty of other scope for that.  Certain aspects
of the user interface are important for users, and we need to
give that priority.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> Can anyone suggest a way to describe the job that Eglot does, NOT
  > >> using technical jargon, or implementation details such as "LSP"?

  > Some ideas of the top of my head:

  > - ide-mode
  > - integrated-development-mode
  > - {smart,intelligent,clever}-mode
  > - programming-mode
  > - syntax-mode

You've tried to resent descriptions which are short enough that they
might serve as command names.  Unfortunately, that shortness makes
them less than helpful for explaining the job that Eglot does.

Each of those names can fit other things in Emacs.  There are other
IDEs in Emacd.  Thee are other things in Emacs we could call clever.
There are many modes for programming.  There are other features that
understand program syntax, and there have been since 1976.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I am reputed to be good at that.  nstead of telling me how hopeless it
  > > is, which won't convince me, how about telling me what Eglot does?
  > > Then we'll see if I come up with a more descriptive name.
  > >
  > No, I'm not the one pushing for the change.

I am not "pushing for the change" regardless of all advantages and
disadvantages.  Rather, I am pushing to look for possible better
names, and then make a decision based on whatever we find.

Isn't that clearly the right thing to do?  Won't you help us do it?

If we find no better name than "Eglot", we should use that one.  But
we should make a real try to find the best one.

    It is your responsibility to
  > actually understand what eglot is if your going to argue the name needs
  > changing.

That is a strange claom to make.

I argued that the name Eglot has a specific disadvantage: that it
doesn't mean anything to people like me who don't know what the
package does.  I don't have a "rasponsibility to understand what Eglot
is" to make _that_ point.

But I do need to understand what Eglot does in order to look
for possible better names.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I am reputed to be good at that.  nstead of telling me how hopeless it
  > > is, which won't convince me, how about telling me what Eglot does?
  > > Then we'll see if I come up with a more descriptive name.
  > >
  > No, I'm not the one pushing for the change.

I am not "pushing for the change" regardless of all advantages and
disadvantages.  Rather, I am pushing to look for possible better
names, and then make a decision based on what we will have found.

Isn't that clearly the right thing to do?  Won't you help us do it?

If we find no better name than "Eglot", we will use that one.  But we
should make a real try to find one.

    It is your responsibility to
  > actually understand what eglot is if your going to argue the name needs
  > changing.

That is a strange claim to make.  I argued that the name Eglot has a
specific disadvantage: that it doesn't mean anything to people like me
who don't know what the package does.

For that point, of all points, I don't have a "rasponsibility to
understand what Eglot is."

But I do need to understand roughly what Eglot does in order to look
for possible better names.

I thank Po Lu for posting that:

    It uses an external program speaking the language server protocol to
    provide completion-at-point and cross-referencing (think
    xref-find-references and xref-find-definitions.)

This says that Eglot uses the language server for two very specific jobs.

Does Eglot define its own commands to complete and/or find referencs,
or does it hook into other commands which do those jobs so that they
can make use of the language server data to do them?

Then you posted about some other things it does:

  > - code snippets

(I know what a "snippet" might be, but I have no idea what action this
means.)

  > - code diagnostics and linting

(Likewise, I don't quite understand this as an action.)

  > - enhanced documentation and feeds into eldoc
  > - provide code actions to fix diagnostic/linter errors or suggest code
  >   refactoring 
  > - hovering over symbols provides function signatures/documentation
  > - symbol renaming and other refactoring support

This gives me the idea that Eglot causes various parts of Emacs to take
advantage of parsing the file's language in order to do their jobs
better.  Is that basically right?

Does Eglot aim to make use of parsing in all the Emacs features
where it could be of use?

If these two are correct, then I think I have an idea.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > It's amazing how quickly people start saying it's too late to change
  > > something.

  > That's on purpose: we are trying to speed up the Emacs release cycle,
  > something that is a long-standing issue that users complain about.

To speed it up does not require becoming rigid.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Eglot assists programmers.  Think tags but better, e.g. not only "jump
  > to symbol" but also "rename symbol".  It uses LSP behind the scenes.

I see what you mean.  Alas, an explanation at that very general level
won't help me find a name that distinguishes Eglot from various other
packages that assist programmers.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Yuri Khan]

On Tue, 4 Oct 2022 at 08:09, Richard Stallman <rms@gnu.org> wrote:

>   > Eglot assists programmers.  Think tags but better, e.g. not only "jump
>   > to symbol" but also "rename symbol".  It uses LSP behind the scenes.
>
> I see what you mean.  Alas, an explanation at that very general level
> won't help me find a name that distinguishes Eglot from various other
> packages that assist programmers.

The framing of your question, i.e. “describe what Eglot does without
mentioning its name”, pretty much guarantees that any other client
implementation of the language server protocol (LSP) will fit the
description.

And that is the general problem with functionality-based names.

Re: Renaming eglot -- or at least add an alias?

[Christopher M. Miles]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]


"Christopher M. Miles" <numbchild@gmail.com> writes:

After reading this long thread, I have some name options:

- lsp-client (It's a client of LSP, then name it as it is)
- lsp-frontend (Similar name like lsp-client, In case the -client is used in library filename.)
- language-server-client (meaningful name than lsp-client)
- language-server-frontend
- language-server-ide (IDE is meaningful for elgot functionalities)
- language-server-kit
- other similar names....

-- 

[ stardiviner ]
I try to make every word tell the meaning that I want to express without misunderstanding.

Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> I thank Po Lu for posting that:
>
>     It uses an external program speaking the language server protocol to
>     provide completion-at-point and cross-referencing (think
>     xref-find-references and xref-find-definitions.)
>
> This says that Eglot uses the language server for two very specific jobs.
>
> Does Eglot define its own commands to complete and/or find referencs,
> or does it hook into other commands which do those jobs so that they
> can make use of the language server data to do them?

I think eglot aims to hook into existing commands and subsystems
whenever possible: flymake, completion-at-point, xref, et cetera.

>   > - enhanced documentation and feeds into eldoc
>   > - provide code actions to fix diagnostic/linter errors or suggest code
>   >   refactoring 
>   > - hovering over symbols provides function signatures/documentation
>   > - symbol renaming and other refactoring support
>
> This gives me the idea that Eglot causes various parts of Emacs to take
> advantage of parsing the file's language in order to do their jobs
> better.  Is that basically right?

Yes.

> Does Eglot aim to make use of parsing in all the Emacs features
> where it could be of use?

I think so, yes.

Re: Renaming eglot -- or at least add an alias?

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

"Christopher M. Miles" <numbchild@gmail.com> writes:

> "Christopher M. Miles" <numbchild@gmail.com> writes:
>
> After reading this long thread, I have some name options:
>
> - lsp-client (It's a client of LSP, then name it as it is)
> - lsp-frontend (Similar name like lsp-client, In case the -client is used in library filename.)
> - language-server-client (meaningful name than lsp-client)
> - language-server-frontend
> - language-server-ide (IDE is meaningful for elgot functionalities)
> - language-server-kit
> - other similar names....

I don't think that Eglot needs to be renamed.  The package just needs a
name, and I think Eglot is not a bad one.  If the name doesn't make it
clear what it does, the same is true for Emacs, Company, GNU, GCC, Linux
(the kernel).

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Gerd Möllmann]

 > At the very least, we should consider adding some alias, like
 > `start-lsp', and/or `lsp-start'.[2]

Wouldn't it be nice if Emacs had CL packages?  Then everyone could add 
superior names as a package nickname.  That would make bikeshedding much 
easier :-).

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 03 Oct 2022 21:02:29 -0400
> 
>   > > It's amazing how quickly people start saying it's too late to change
>   > > something.
> 
>   > That's on purpose: we are trying to speed up the Emacs release cycle,
>   > something that is a long-standing issue that users complain about.
> 
> To speed it up does not require becoming rigid.

To some degree, it does.  It requires to deliberately reject
unnecessary and low-importance changes that would have delayed the
release.

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >> Can anyone suggest a way to describe the job that Eglot does, NOT
>   > >> using technical jargon, or implementation details such as "LSP"?
>
>   > Some ideas of the top of my head:
>
>   > - ide-mode
>   > - integrated-development-mode
>   > - {smart,intelligent,clever}-mode
>   > - programming-mode
>   > - syntax-mode
>
> You've tried to resent descriptions which are short enough that they
> might serve as command names.  Unfortunately, that shortness makes
> them less than helpful for explaining the job that Eglot does.

That is kind of the issue, isn't it?  Eglot (or LSP in general) doesn't
add any new features, it just improves the accuracy of what already is
built-in.

> Each of those names can fit other things in Emacs.  There are other
> IDEs in Emacd.  Thee are other things in Emacs we could call clever.
> There are many modes for programming.  There are other features that
> understand program syntax, and there have been since 1976.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 03 Oct 2022 21:01:59 -0400
> 
> I thank Po Lu for posting that:
> 
>     It uses an external program speaking the language server protocol to
>     provide completion-at-point and cross-referencing (think
>     xref-find-references and xref-find-definitions.)
> 
> This says that Eglot uses the language server for two very specific jobs.

Actually, it can be used for many more specific jobs.  Basically, any
job that requires understanding of the program's syntax and structure
can use language servers via Eglot.  Someone else posted a longer list
of such jobs:

  > - enhanced documentation and feeds into eldoc
  > - provide code actions to fix diagnostic/linter errors or suggest code
  >   refactoring 
  > - hovering over symbols provides function signatures/documentation
  > - symbol renaming and other refactoring support

And the full list is really unbounded (although some jobs are not yet
supported by Emacs, perhaps because they are too hard or impossible
without a language server).

> This gives me the idea that Eglot causes various parts of Emacs to take
> advantage of parsing the file's language in order to do their jobs
> better.  Is that basically right?

Yes, AFAIU.

> Does Eglot aim to make use of parsing in all the Emacs features
> where it could be of use?

It provides an opportunity and infrastructure for doing that.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> Date: Tue, 4 Oct 2022 07:25:19 +0200
> Cc: emacs-devel@gnu.org, joaotavora@gmail.com
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
>  > At the very least, we should consider adding some alias, like
>  > `start-lsp', and/or `lsp-start'.[2]
> 
> Wouldn't it be nice if Emacs had CL packages?  Then everyone could add 
> superior names as a package nickname.  That would make bikeshedding much 
> easier :-).

Does shorthands.el fit the bill?

Re: Renaming eglot -- or at least add an alias?

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Wouldn't it be nice if Emacs had CL packages?  Then everyone could add 
>> superior names as a package nickname.  That would make bikeshedding much 
>> easier :-).
>
> Does shorthands.el fit the bill?

It's a step in the right direction, but it's not going far enough for
advanced bikeshedders :-).

For example, if we take this, from the elisp info manual:

     (defun snu-lines (s)
       "Split string S into a list of strings on newline characters."
       (snu-split "\\(\r\n\\|[\n\r]\\)" s))

     ;; Local Variables:
     ;; read-symbol-shorthands: (("snu-" . "some-nice-string-utils-"))
     ;; End:

the "snu-" is gone after reading the file.

With packages, the package "some-nice-string-utils" would just define a
function "lines", and that would be accesible as
"some-nice-string-utils:lines".

Or "snu:lines", if a package nickname "snu" is used, either globally or
locally.  Or they rename the package, or change nicknames globally.  Or
they choose to use no package-prefix at all, if they want.

And/or mix in hierarchical packages.

That I call bikeshedding opportunities! :-).

A bit more seriously, shorthandse.l shows that there is a problem,
right?  And there's an existing, old, solution, and IMHO no reason to
invent a new one, which won't materialize anyway.  While for CL packages
we might find Someone(tm) giving it a spin, theoretically of course.

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

I don't think so. It could, somewhat but would be akward. Gerd's suggestion
is much a much more natural way to solve this bike shed. At the Lisp symbol
level, at least. At the package level (as in Elisp .el  file names) it does
nothing for this particular semiotic bike shed.

João

On Tue, Oct 4, 2022, 08:43 Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 4 Oct 2022 07:25:19 +0200
> > Cc: emacs-devel@gnu.org, joaotavora@gmail.com
> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >
> >  > At the very least, we should consider adding some alias, like
> >  > `start-lsp', and/or `lsp-start'.[2]
> >
> > Wouldn't it be nice if Emacs had CL packages?  Then everyone could add
> > superior names as a package nickname.  That would make bikeshedding much
> > easier :-).
>
> Does shorthands.el fit the bill?
>

[-- Attachment #2: Type: text/html, Size: 1452 bytes --]

Re: Renaming eglot -- or at least add an alias?

[xenodasein--- via Emacs development discussions.]

Demands over changing eglot's name are super annoying.  A name
change is going to accomplish absolutely nothing, maybe except
disrespecting the author.  If you want to do that at least come
up with an actually good name.  Not with ludicrous things like
"{smart,intelligent,clever}-mode" or "IntelliSense."
Descriptions (hardly names) like lsp-mode are passable but
definitely less tasteful so authors should decide whether they
prefer this-package-does-this-and-uses-this-software-protocol-
implementing-other-software-thing-mode or something both tasteful
AND descriptive like Emacs Polyglot.

I for one never got bothered when I saw Emacs packages like Gnus
and not immediately understand "crazy customizable news reader
that is somehow a great mail client."  I suspect it is the same
for most users, considering the names of extremely popular software
worldwide.

Re: Renaming eglot -- or at least add an alias?

[Gerd Möllmann]

On 22-10-04 11:57 , João Távora wrote:
> I don't think so. It could, somewhat but would be akward. Gerd's 
> suggestion is much a much more natural way to solve this bike shed. At 
> the Lisp symbol level, at least. At the package level (as in Elisp .el  
> file names) it does nothing for this particular semiotic bike shed.

Hierarchical packages could help here:

https://cmucl.org/docs/cmu-user/html/Hierarchical-Packages.html
https://franz.com/support/tech_corner/hierpackuser.lhtml

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Philip Kaludercic <philipk@posteo.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > >> Can anyone suggest a way to describe the job that Eglot does, NOT
>>   > >> using technical jargon, or implementation details such as "LSP"?
>>
>>   > Some ideas of the top of my head:
>>
>>   > - ide-mode
>>   > - integrated-development-mode
>>   > - {smart,intelligent,clever}-mode
>>   > - programming-mode
>>   > - syntax-mode
>>
>> You've tried to resent descriptions which are short enough that they
>> might serve as command names.  Unfortunately, that shortness makes
>> them less than helpful for explaining the job that Eglot does.
>
> That is kind of the issue, isn't it?  Eglot (or LSP in general) doesn't
> add any new features, it just improves the accuracy of what already is
> built-in.
>

I think your correct that eglot doesn't bring any new features. What we
are really talking about here is a new architecture where, in an ideal
world, each language would provide its own language server that all
editors would leverage off via a client like elgot. There would be no
need for individual editors to re-invent functionality such as linting,
code snippets or editor specific language parsing etc. As such, it
offers the potential for simpler and more efficient editors that have to
worry less about keeping up with the evolution of a specific language.

However, it may not be accurate to argue that eglot (and LSP generally)
provides improvement or more accurate functionality. There are cases
where the LSP based solution may not be as good as a very sophisticated
mode for a specific language. For example, while I find an LSP based
solution really good when I'm working on Javascript, I still find cider
mode better when working with Clojure. LIkewise, not all LSP servers are
equal. Some are better and/or more sophisticated than others. 

This new architecture is not just beneficial for editor
developers/maintainers. Users benefit because of a simpler configuration
experience. Prior to LSP and an Emacs lsp client, I had to configure a
number of different emacs packages in order to get a useful Javascript
development environment. Now, all I have to do is install one of the JS
LSP servers and eglot and the job is done.

Trying to find a new name which reflects what eglot does is problematic
because what it does is the same as what many other packages do. What is
different is the way (architecture) it sues to achieve this. However,
that doesn't really help either - if we use a name which is somehow
derived from eglot's role as an lsp client, we cause confusion because
there is more than one lsp client and when people try to communicate
around this, things get confused between the package called lsp client
and the different 'things' which are lsp clients. Likewise, when
searching for help or past messages/articles, you get too much 'noise'
because the name your using is too similar to other uses or
functionality.

The whole idea of names which reflect the role or purpose of a package
is flawed. It results in generic names which make searching for
information specific to that package much harder. In many cases, such
generic names tend to provide little real value anyway.

On the other hand, if you have a unique name which doesn't tell you
anything about what a package does, what are you likely to do - look at
it more closely and likely read the package description. Not only can
you provide a unique distinct name which makes communication and
searching easier, you may actually peak interest more than a likely
limited descriptive name which makes something seem irrelevant or more
limiting than it needs to be. 

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think the clearest name for Eglot is  Parse Code.
That's what all these enhancements have in common.
If you enable the Parse Code feature, various functionalities
will parse code (when possible, when supported, etc.).

There's no need to eliminate the name Eglot.  I think making Parse
Code an alias for it would do the really helpful job.  Its source
files can be mostly unchanged -- but they should explain that the
package is also called Parse Code, and why.

The main change is that Emacs should refer to the package and its
functionality primarily as Parse Code in menus and documentation.
That is how we will get the benefit of that name's clarity.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > That's on purpose: we are trying to speed up the Emacs release cycle,
  > >   > something that is a long-standing issue that users complain about.
  > > 
  > > To speed it up does not require becoming rigid.

  > To some degree, it does.  It requires to deliberately reject
  > unnecessary and low-importance changes that would have delayed the
  > release.

In situations like this, where we are about to make a choice
that would be a pain to change later, I think choosing a good
name is important.  Well worth a week of delay in the release.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If the name doesn't make it
  > clear what it does, the same is true for Emacs, Company, GNU, GCC, Linux
  > (the kernel).

GCC is an acronym for GNU Compiler Collection; that states what it
does.

GNU is an acronym for GNU's Not Unix.  By the convention for recursive
acronyms, that implies something similar to Unix; in other words, a
Unix-like operating system.

Emacs is short for Editing Macros, which says it is an editor.

That is not to say that none of those could possibly be improved upon.

Company, by contrast, is one of the unclear names I think we should
change for clarity.

As for Linux, that name is not ours, so the blame or the praise
is not for us.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 04 Oct 2022 13:39:29 -0400
> 
>   > > To speed it up does not require becoming rigid.
> 
>   > To some degree, it does.  It requires to deliberately reject
>   > unnecessary and low-importance changes that would have delayed the
>   > release.
> 
> In situations like this, where we are about to make a choice
> that would be a pain to change later, I think choosing a good
> name is important.  Well worth a week of delay in the release.

I see no pain in adding aliases and descriptive one-liners to an
existing package.  And I don't believe the change of the name will
mean just one week of delay.

Right now, it is most important for me to get Eglot into the Emacs Git
repository.  We can add aliases, descriptive labels, etc. later --
those can be dome on the release branch.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 04 Oct 2022 13:39:27 -0400
> 
> I think the clearest name for Eglot is  Parse Code.

Eglot doesn't parse code.  It is a client of a protocol designed to
allow applications to send requests about source code and receive
results.  The server which responds to the requests does parse the
code, but Eglot doesn't.

> The main change is that Emacs should refer to the package and its
> functionality primarily as Parse Code in menus and documentation.

I think this will not be the best solution, because the features
enabled by Eglot use the results of parsing performed by an external
server, they don't perform any parsing.

But it's too early and premature to discuss what we will say in our
menus, because we have no idea what these menus will be and which
features they will activate.  We should delay this discussion until
after the merge, at which point we will be able to talk about concrete
commands, variables, doc strings, and menu items.

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > If the name doesn't make it
>   > clear what it does, the same is true for Emacs, Company, GNU, GCC, Linux
>   > (the kernel).
>
> GCC is an acronym for GNU Compiler Collection; that states what it
> does.
>
> GNU is an acronym for GNU's Not Unix.  By the convention for recursive
> acronyms, that implies something similar to Unix; in other words, a
> Unix-like operating system.
>
> Emacs is short for Editing Macros, which says it is an editor.
>
> That is not to say that none of those could possibly be improved upon.
>
> Company, by contrast, is one of the unclear names I think we should
> change for clarity.
>
> As for Linux, that name is not ours, so the blame or the praise
> is not for us.

Now things are just getting ridiculous. Your original requirement was
for a name free of jargon and non-technical. GCC, GNU and Emacs hardly
meet those requirements. The name eglot seems as appropriate given it
stands for Emacs polyglot and essentially that is what it does - it
makes Emacs able to 'know' and work with many languages. The definition
of polyglot is "a person who knows and is able to use several
languages". This is as close to any other proposed description for what
it does. By enabling eglot, you can enable Emacs to better work/use
many languages by adding language specific linting, code snippets,
refactoring, documentation, completion and navigation to definitions and
references etc without also having to install additional language
specific packages. 

However, the real benefit of the name is that it is short, unique and
easy to type and great for use in searches. Just try a little
experiment, type eglot into a browser search box and look at what you
have. Now type any of the alternative names proposed and see what you
get. The results make it pretty clear which was the better term to
search for. 

Then you suggest we should change the name of company mode, a mode which
has been extremely successful and over the many years it has existed,
I've never seen a single person say anything like "Oh wow, I just
discovered what company is, if only it had a better name which would
have alerted me sooner!".

If anything, the success of company (and even GNU Linux) demonstrates
the weakness of your argument regarding the importance of clear
names. You are emphasising just one aspect of a name and ignoring the
other important attributes of a name (like uniqueness, memorable,
short). Adding in company now just makes all of this seem like
bureaucratic busy work which, after all the dust has settled, will have
achieved little or made things worse.

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I think the clearest name for Eglot is  Parse Code.
> That's what all these enhancements have in common.
> If you enable the Parse Code feature, various functionalities
> will parse code (when possible, when supported, etc.).
>
> There's no need to eliminate the name Eglot.  I think making Parse
> Code an alias for it would do the really helpful job.  Its source
> files can be mostly unchanged -- but they should explain that the
> package is also called Parse Code, and why.
>
> The main change is that Emacs should refer to the package and its
> functionality primarily as Parse Code in menus and documentation.
> That is how we will get the benefit of that name's clarity.

A terrible name because it is misleading. Eglot does not do any code
parsing. In fact, it knows nothing about the underlying
code/language. As I've said MANY times in this thread, eglot is just a
client which is the glue between Emacs and servers which implement the
language server protocol. It is the servers that have all the language
specific functionality.

GO one step further. Consider a user who is having problems with the
package they know as 'Parse Code". The first thing they will do is enter
something in a search engine to try and find a result. The natural thing
to do would be to include the package name in the search. Imagine all
the 'noise' in the results if you search for 'Parse Code". Your answer
will likely be "Ah, but we have kept the name eglot, so they can use
that in the search!". So now what we have done is potentially create
more confusion as we have a package known by two names and they need to
know the original 'eglot' name in order to easily find relevant
information.

Let it go. You want a better name and none have been forthcoming. This
is a non-issue and time to move on.
. 

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Tim Cross <theophilusx@gmail.com> writes:

> Then you suggest we should change the name of company mode, a mode which
> has been extremely successful and over the many years it has existed,
> I've never seen a single person say anything like "Oh wow, I just
> discovered what company is, if only it had a better name which would
> have alerted me sooner!".

I was like that, when I had first heard of both "auto-complete-mode" and
"company-mode" I preferred the former because the name was more
descriptive, and "company-mode" made the impression of being
"commercial" software.  In the end I switched because it was technically
superior, but I hesitated for a long while no other reason than the
name.

While it might be that many don't care about names, it is unreasonable
to assume that nobody prefers generic, descriptive names.

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Philip Kaludercic <philipk@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Then you suggest we should change the name of company mode, a mode which
>> has been extremely successful and over the many years it has existed,
>> I've never seen a single person say anything like "Oh wow, I just
>> discovered what company is, if only it had a better name which would
>> have alerted me sooner!".
>
> I was like that, when I had first heard of both "auto-complete-mode" and
> "company-mode" I preferred the former because the name was more
> descriptive, and "company-mode" made the impression of being
> "commercial" software.  In the end I switched because it was technically
> superior, but I hesitated for a long while no other reason than the
> name.
>
> While it might be that many don't care about names, it is unreasonable
> to assume that nobody prefers generic, descriptive names.

So, suddenly, because I disagree with the necessity to change the name
of eglot, I suddenly don't care about names or assume nobody prefers
generic, descriptive names? That is just nonsense. It is the fact I care
about the name I've been involved in this discussion. 

I've lost count of how many times I've said this.

I'm not against descriptive names. What I'm against is the requirement
for a descriptive name to take precedence over all other important
attributes of a good name.

I would also suggest, based on your experience with company mode, that
you put too much weight in the meaning of a name. The old saying about
never judging a book by its cover seems somewhat relevant here. Most
people don't select packages (either in Emacs or anywhere else) based
just on the name. They fact you didn't look at the description of
company mode and judged it solely based on the name is really a failure
in your process, not in the package name.

Out of interest, given the name 'auto-complete' was already taken, what
would have been your preferred name for 'company'? 

In this age of internet data and internet searching, I would suggest
that uniqueness of a name is actually far more important than the
descriptive attributes of the name. When your lucky enough to be able to
have both a descriptive and unique name, fantastic. However, the name
being descriptive should not be a requirement.

At the end of the day, the reason this debate is going on and on is
because nobody who is pushing for a name change has come up with a
single suggestion which adds more value than it destroys. RMS has
suggested Parse Code, which I think is one of the worse suggestions so
far - it is inaccurate and misleading, will make searching for help and
problem solutions much harder, will likely cause confusion in
communications, is longer and attempts to 'own' the name of a generic
process which many other packages implement. In fact, if I was searching
for a code parser, I would be frustrated by that package showing up as
it doesn't do what it says on the box. When I search for a code parser,
I want something which will parse my code so that I can then do
something with that parsed/toeknised result, I'm not interested in a
client for LSP servers.   

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> Now things are just getting ridiculous. Your original requirement was
> for a name free of jargon and non-technical. GCC

Is a compiler.  Anyone who has reason to use a compiler should know what
it is.  In addition, the C compiler on Unix-like systems is
traditionally "CC", with various different compilers prepending a letter
or two (i.e. pcc, xlc, et cetera.)  Such precedent has not been set with
language server clients: for example, KDE's Kate calls theirs "LSP
Client".

> GNU

Is an operating system, made as a clone of Unix.  It is also a name that
requires uniqueness there are many different Unix-like operating systems
out there.  Would you also demand that MS Windows be named "Operating
System"?  Or Sun Solaris "Operating System"?

> Emacs

Was named in 1976, and the ship with its name has long since sailed.
That is not the case with eglot.

> Then you suggest we should change the name of company mode, a mode which
> has been extremely successful and over the many years it has existed,
> I've never seen a single person say anything like "Oh wow, I just
> discovered what company is, if only it had a better name which would
> have alerted me sooner!".

I have, in the past I was extremely confused by the relationship between
auto-complete and company due to the name of the latter.

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I think the clearest name for Eglot is  Parse Code.
> That's what all these enhancements have in common.
> If you enable the Parse Code feature, various functionalities
> will parse code (when possible, when supported, etc.).

I think that will not work, because Semantic does the same thing, and we
already give it the menu item "source code parsers".

And before some bright young mind comes up with the idea to remove
Semantic in favor of LSP, keep in mind that it is used on a daily basis
by many people, including yours truly.

Re: Renaming eglot -- or at least add an alias?

[Simon Leinen]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

Thinking about how eglot improves source code editing with Emacs:

Eglot is Glue to use the LSP protocol to Obtain Type (and other)
information...

That's a bit long, so maybe let's find an acronym and use that as a name?
;-)
-- 
Simon.

[-- Attachment #2: Type: text/html, Size: 408 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > If the name doesn't make it
>   > clear what it does, the same is true for Emacs, Company, GNU, GCC, Linux
>   > (the kernel).
>
> GCC is an acronym for GNU Compiler Collection; that states what it
> does.
>
> GNU is an acronym for GNU's Not Unix.  By the convention for recursive
> acronyms, that implies something similar to Unix; in other words, a
> Unix-like operating system.
>
> Emacs is short for Editing Macros, which says it is an editor.
>
> That is not to say that none of those could possibly be improved upon.
>
> Company, by contrast, is one of the unclear names I think we should
> change for clarity.
>
> As for Linux, that name is not ours, so the blame or the praise
> is not for us.

I'm neither blaming nor praising anyone.

I mean the name "Emacs" doesn't make it what it does at the first sight.
Someone who have never heard about Emacs would wonder what it is, or
even can misunderstand it as something related to MacOS.

A Visual Studio may not understand what GCC is at the first sight.

Many proprietary OS users would wonder what Linux is.

Many Linux users have no idea about GNU, and at the first sight, they
might think of an animal, or even an asteroid.

Company stands for "COMPlete ANYthing", but as someone pointed out,
people can misunderstand it as a commercial software.

Even the name "English" don't make any sense to many people.

So instead of renaming Eglot or presenting it to the user with another
name, I think we should focus on other things.  Name is indeed
important, but it is already too late for Eglot.  If we change the name
now, all third-party documentations like many blog posts will become
invalid.  A stitch in time saves nine.  If someone informed the author
about this when they pushed for the first time to the Eglot repository,
then we wouldn't have need this debate now.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Alfred M. Szmidt]

     > > I am reputed to be good at that.  nstead of telling me how hopeless it
     > > is, which won't convince me, how about telling me what Eglot does?
     > > Then we'll see if I come up with a more descriptive name.
     > >
     > No, I'm not the one pushing for the change.

   I am not "pushing for the change" regardless of all advantages and
   disadvantages.  Rather, I am pushing to look for possible better
   names, and then make a decision based on what we will have found.

   Isn't that clearly the right thing to do?  Won't you help us do it?

Seeing that eglot would still keep it's original name, there is little
to no reason to make up a name on the spot, and stop or hinder Eli
from going forward working on the next release.

A new name, or a better name that users would normally call, can be
done at a later time, seeing that it would be just a simple DEFALIAS.

So this discussion can easily be taken later, without casuing extra
arguments.

Re: Renaming eglot -- or at least add an alias?

[Alfred M. Szmidt]

To be fair, eglot does a bit more than just being a LSP client.  It
enables lots of extra fluff.  E.g., it popups up a docstring in the
mini-buffer using eldoc, it highlights broke code using flymake,
enables completion using company-mode if that is used, etc -- that is
quite a bit more than just a simple client interface.

If all it did was act like a client, then the name would have been
obvious (start-lsp-server), but since it does many many more things
... eglot is actually a plenty fine name.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: rms@gnu.org, eliz@gnu.org, emacs-devel@gnu.org
> Date: Wed, 05 Oct 2022 06:57:45 -0400
> 
> To be fair, eglot does a bit more than just being a LSP client.  It
> enables lots of extra fluff.  E.g., it popups up a docstring in the
> mini-buffer using eldoc, it highlights broke code using flymake,
> enables completion using company-mode if that is used, etc -- that is
> quite a bit more than just a simple client interface.

It provides LSP client services to several Emacs features, yes.
Having a client without this glue would be much less useful, because
it would mean we'd need to develop that ourselves.

Re: Renaming eglot -- or at least add an alias?

[Gerd Möllmann]

 > That's a bit long, so maybe let's find an acronym and use that as a > 
 > name?
 > ;-)

Eglot Gathers Lots of Odd Titles :-)

Re: Renaming eglot -- or at least add an alias?

[Alfred M. Szmidt]

   > To be fair, eglot does a bit more than just being a LSP client.  It
   > enables lots of extra fluff.  E.g., it popups up a docstring in the
   > mini-buffer using eldoc, it highlights broke code using flymake,
   > enables completion using company-mode if that is used, etc -- that is
   > quite a bit more than just a simple client interface.

   It provides LSP client services to several Emacs features, yes.
   Having a client without this glue would be much less useful, because
   it would mean we'd need to develop that ourselves.

Right, my point was mearly that eglot isn't _just_ a client -- so
whatever name is derived from that wouldn't be a good fit, since it
does much more as well.

Re: Renaming eglot -- or at least add an alias?

[Alexander Adolf]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

elsp would be very close to elisp. Just saying…

  --alex

-- 
www.condition-alpha.com / @c_alpha
Sent from my iPhone; apologies for brevity and autocorrect weirdness. 

> On 5. Oct 2022, at 17:08, Alfred M. Szmidt <ams@gnu.org> wrote:
> 
> 
>> 
>> To be fair, eglot does a bit more than just being a LSP client.  It
>> enables lots of extra fluff.  E.g., it popups up a docstring in the
>> mini-buffer using eldoc, it highlights broke code using flymake,
>> enables completion using company-mode if that is used, etc -- that is
>> quite a bit more than just a simple client interface.
> 
>   It provides LSP client services to several Emacs features, yes.
>   Having a client without this glue would be much less useful, because
>   it would mean we'd need to develop that ourselves.
> 
> Right, my point was mearly that eglot isn't _just_ a client -- so
> whatever name is derived from that wouldn't be a good fit, since it
> does much more as well.
> 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1944 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I think the clearest name for Eglot is  Parse Code.

  > Eglot doesn't parse code.  It is a client of a protocol designed to
  > allow applications to send requests about source code and receive
  > results.  The server which responds to the requests does parse the
  > code, but Eglot doesn't.

That's true, but it consists of implementation details.  Users don't
need to know about them or think in those terms.  For users, the
simple description of the package's job is to causes various Emacs
features to work by parsing code.

  > But it's too early and premature to discuss what we will say in our
  > menus, because we have no idea what these menus will be and which
  > features they will activate.  We should delay this discussion until
  > after the merge, at which point we will be able to talk about concrete
  > commands, variables, doc strings, and menu items.

If users ask at some point to "use this package", it is important
what we call the package.

If users ask to enable various specific features that work using this
package, maybe users won't need to know the package's name.


How to deal with Eglot and Semantic is not clear to me.

Is there any programming language which is supported both by Eglot and
by Semantic?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 06.10.2022 00:35, Richard Stallman wrote:
> Is there any programming language which is supported both by Eglot and
> by Semantic?

C/C++/any other Semantic-supported langugages.

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 05.10.2022 01:31, Tim Cross wrote:
> Out of interest, given the name 'auto-complete' was already taken, what
> would have been your preferred name for 'company'?

I'd like the answer to that as well.

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> How to deal with Eglot and Semantic is not clear to me.
>
> Is there any programming language which is supported both by Eglot and
> by Semantic?

I think this question still shows a fundamental lack of understanding
regarding what eglot is and does.

Eglot doens't know anything about programming languages. What languages
it is able to work with is determined by the available language
servers. The available language servers change as new ones are created
and old ones die off. They are implemented in different languages and
have nothing to do with Emacs or elisp.

Is there overlap between semantic and eglot? Well, yes in the sense that
languages wupported by semantic have language servers.

When there is overlap, is it the same functionality? No, not
necessarily. It may have common aspects, but it could also be
significantly different. Some people will likely prefer a semantic based
workflow and others may prefer an eglot one (and yet others may prefer
other elisp soluions for some languages, for example cider over eglot
and clojure-lsp.

This again brings us around to a core stumbling block - how do you have
a name which describes what something does when there are multiple
packages which do that thing? 

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> How to deal with Eglot and Semantic is not clear to me.
>
> Is there any programming language which is supported both by Eglot and
> by Semantic?

I think this question still shows a fundamental lack of understanding
regarding what eglot is and does.

Eglot doens't know anything about programming languages. What languages
it is able to work with is determined by the available language
servers. The available language servers change as new ones are created
and old ones die off. They are implemented in different languages and
have nothing to do with Emacs or elisp.

Is there overlap between semantic and eglot? Well, yes in the sense that
languages wupported by semantic have language servers.

When there is overlap, is it the same functionality? No, not
necessarily. It may have common aspects, but it could also be
significantly different. Some people will likely prefer a semantic based
workflow and others may prefer an eglot one (and yet others may prefer
other elisp soluions for some languages, for example cider over eglot
and clojure-lsp.

This again brings us around to a core stumbling block - how do you have
a name which describes what something does when there are multiple
packages which do that thing? 

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Is there any programming language which is supported both by Eglot and
> by Semantic?

Yes -- the only such language I write in is C.

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> Is there overlap between semantic and eglot? Well, yes in the sense that
> languages wupported by semantic have language servers.
>
> When there is overlap, is it the same functionality? No, not
> necessarily.

Before saying this, did you actually read through the Semantic manual?

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Is there overlap between semantic and eglot? Well, yes in the sense that
>> languages wupported by semantic have language servers.
>>
>> When there is overlap, is it the same functionality? No, not
>> necessarily.
>
> Before saying this, did you actually read through the Semantic manual?

It has been some time since I last used semantic, but yes, I have read
the manual. What is your point?

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 05 Oct 2022 17:35:26 -0400
> 
>   > Eglot doesn't parse code.  It is a client of a protocol designed to
>   > allow applications to send requests about source code and receive
>   > results.  The server which responds to the requests does parse the
>   > code, but Eglot doesn't.
> 
> That's true, but it consists of implementation details.  Users don't
> need to know about them or think in those terms.  For users, the
> simple description of the package's job is to causes various Emacs
> features to work by parsing code.

I think from user's POV Eglot will be related to the features it
enables.  They won't care about code parsing that is the basis of
that.

>   > But it's too early and premature to discuss what we will say in our
>   > menus, because we have no idea what these menus will be and which
>   > features they will activate.  We should delay this discussion until
>   > after the merge, at which point we will be able to talk about concrete
>   > commands, variables, doc strings, and menu items.
> 
> If users ask at some point to "use this package", it is important
> what we call the package.

The name must be Eglot, because that's how the package was called
since 2017.  We cannot possibly rewrite history or change people's
memories.

> How to deal with Eglot and Semantic is not clear to me.
> 
> Is there any programming language which is supported both by Eglot and
> by Semantic?

Yes.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Thu, 06 Oct 2022 11:13:43 +1100
> 
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > How to deal with Eglot and Semantic is not clear to me.
> >
> > Is there any programming language which is supported both by Eglot and
> > by Semantic?
> 
> I think this question still shows a fundamental lack of understanding
> regarding what eglot is and does.

I don't think there's a misunderstanding here, no.

> Eglot doens't know anything about programming languages. What languages
> it is able to work with is determined by the available language
> servers. The available language servers change as new ones are created
> and old ones die off. They are implemented in different languages and
> have nothing to do with Emacs or elisp.

That is immaterial.  To Emacs users, Eglot+language server is a single
entity that provides and/or enables some Emacs features.  Semantic
provides and enables some of the same features.

> When there is overlap, is it the same functionality? No, not
> necessarily.

Actually, yes, it's the same functionality.  Xref support is one area
of overlap, refactoring support is another, semantic analysis is yet
another.

Semantic was developed with a similar goals in mind, so it isn't
surprising that there's overlap in functionality.  Those goals were
the reasons why we added parts of CEDET to Emacs years ago -- we hoped
they will be the basis of an Emacs-based modern IDE capabilities.

Experience taught us that these hopes didn't materialize, and
meanwhile the technology moved to other solutions.  So now we want to
adopt those solutions to Emacs, and naturally there will be clashes
with Semantic-based functionalities.  We'll need to resolve that as we
go, probably deprecating Semantic in the long run.

> This again brings us around to a core stumbling block - how do you have
> a name which describes what something does when there are multiple
> packages which do that thing? 

This dispute is from my POV a complete waste of time, energy, and
bandwidth.  I wish people have stopped arguing, because it won't
change anything in the short run.  As I already said at the beginning
of this useless thread.

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> Can anyone suggest a way to describe the job that Eglot does, NOT
>>> using technical jargon, or implementation details such as "LSP"?
>
> Some ideas of the top of my head:
>
> - ide-mode
> - integrated-development-mode
> - {smart,intelligent,clever}-mode
> - programming-mode
> - syntax-mode

I know it is too late now, but another idea might just be
"polygot"/"polygot-mode".  Has some language connotation, close to
"Eglot" and is a real word.

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Right, my point was mearly that eglot isn't _just_ a client -- so
  > whatever name is derived from that wouldn't be a good fit, since it
  > does much more as well.

I agree.  That is why I've proposed a name that has nothing to do with
internal details like that.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > To be fair, eglot does a bit more than just being a LSP client.  It
  > > enables lots of extra fluff.  E.g., it popups up a docstring in the
  > > mini-buffer using eldoc, it highlights broke code using flymake,
  > > enables completion using company-mode if that is used, etc -- that is
  > > quite a bit more than just a simple client interface.

  > It provides LSP client services to several Emacs features, yes.
  > Having a client without this glue would be much less useful, because
  > it would mean we'd need to develop that ourselves.

I agree.  I would not suggest removing any of Eglot's functionality.
I'd expect just the opposite -- that people would continue making 
a range of Emacs features make use of Eglot when that is useful.

The name I proposed, "Parse Code", fits this generality.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 06.10.2022 13:24, Philip Kaludercic wrote:
> Philip Kaludercic<philipk@posteo.net>  writes:
> 
>> Tim Cross<theophilusx@gmail.com>  writes:
>>
>>> Richard Stallman<rms@gnu.org>  writes:
>>>
>>>> Can anyone suggest a way to describe the job that Eglot does, NOT
>>>> using technical jargon, or implementation details such as "LSP"?
>> Some ideas of the top of my head:
>>
>> - ide-mode
>> - integrated-development-mode
>> - {smart,intelligent,clever}-mode
>> - programming-mode
>> - syntax-mode
> I know it is too late now, but another idea might just be
> "polygot"/"polygot-mode".  Has some language connotation, close to
> "Eglot" and is a real word.
> 

Very close to https://github.com/polymode/polymode/.

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Seeing that eglot would still keep it's original name, there is little
  > to no reason to make up a name on the spot, and stop or hinder Eli
  > from going forward working on the next release.

If we include the package in the Emacs 29 release, that will call for
mentioning it in many places in documentation for users -- the places
that document the features it enhances.

Even if its own source code still carries the name "Eglot", those
improvements in documenation should carry the clearer name.
And a few places in the code should use the other name.

So we have a reason to finish this now.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> The name I proposed, "Parse Code", fits this generality.

This is a terrible name.

If I saw a package called 'Parse Coded" I would expect it would provide
functionality you would normally get from a code parser. I"d be looking
for an API I could query to get things from the parse tree.

Eglot does not provide that. If anything, "Parse Code" would be a good
name for semantic as that is essentially what it does. Other modules,
like speedbar, semanticdb, ecb etc then query that semantic api to get
information from the parse tree.

Eglot doesn't provide that API. It feeds the data from the LSP server
into various other packages, like xref, flycheck, eldoc etc.

In short, the name 'Parse Code' would look to me like a developer
library for people writing elisp packages, not a general purpose package which
sets up a development environment for many different languages.

All I can say is I really pity future Emacs users should this rename
occur. When they use the package and run into problems, good luck
finding something relevant when you search for 'parse code'. 

Just for fun, do a Google search for "Emacs parse code". Then do a
search for "Emacs eglot".

Which search results do you think would be most helpful to our users?

Re: Renaming eglot -- or at least add an alias?

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> Now that we're getting closer to merging eglot, I think it is our last
> chance to (re-)consider that "eglot" is not the ideal name.  It has some
> charm, of course, but it is quite non-descriptive and it's hard (read:
> impossible) to understand what it does based on the name alone.[1]

FWIW,

The word "bikeshedding" often gets thrown around when someone tries to
find ways of making Emacs easier to use.  I don't think that is the best
approach.  Ease of use often comes down to minor details, in themselves
not a big deal, but that taken together will start to add up.

I also think the claim that naming doesn't matter is wrong.  Naming of
user facing features *does* matter, especially of important features
such as this one.  We have enough technical debt, quirks and historical
baggage in Emacs as it is.

Several people have argued the renaming case effectively, and I haven't
seen any need to add much beyond that.  But it's clear to me now that we
haven't been able to find a significantly better name.  Given that there
is also a lot of opposition to renaming, I think I agree that, on
balance, it might be better to leave this alone.

Long live Eglot.  I'm happy to see it merged.

Re: Renaming eglot -- or at least add an alias?

[Jose A. Ortega Ruiz]

On Fri, Oct 07 2022, Tim Cross wrote:

[...]

> In short, the name 'Parse Code' would look to me like a developer
> library for people writing elisp packages, not a general purpose
> package which sets up a development environment for many different
> languages.

Just like tree-sitter, which i understand is also nearing its inclusion
in emacs core, and whose primary function is, if i'm not mistaken,
literally parsing code.

(For my own education as a non-native speaker, if i may: isn't "Parse
Code", not being a noun phrase, a bit awkward as a name anyway? Sounds
to me like, say, calling an email client "Write Messages".)

Cheers,
jao
-- 
“If I can do it better in Emacs I use Emacs. Otherwise, I use Emacs.”
 - Mike Zamansky

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 06 Oct 2022 18:09:12 -0400
> 
>   > Seeing that eglot would still keep it's original name, there is little
>   > to no reason to make up a name on the spot, and stop or hinder Eli
>   > from going forward working on the next release.
> 
> If we include the package in the Emacs 29 release, that will call for
> mentioning it in many places in documentation for users -- the places
> that document the features it enhances.

"Many places" is an exaggeration, IMO.  Eglot will come with its own
separate manual, will be briefly mentioned in the Emacs manual, and
will be called out in NEWS.  That's all I see at the moment.

> Even if its own source code still carries the name "Eglot", those
> improvements in documenation should carry the clearer name.
> And a few places in the code should use the other name.

The documentation mentioned above will explain what Eglot is and why
that is its name (I'm working on the Eglot manual as we speak, so I
know that's what the manual will do).  But the name of the package is
Eglot since 2017, when it appeared and Emacs users started using it,
so it would be incorrect and un-clever for us to change its name 6
years after its appearance.  We can (and will) make it easier for
users to understand what its features do, by labeling the menus and
describing in the doc strings and help-echo strings what the commands
and variables really do and what effect they have on Emacs.  If
needed, we can also provide aliases or front-ends for Eglot commands
and variables whose names don't mention Eglot, but are related to the
command's or variable's real effect.  For example, the command to
start the language server and connect to it could have a name to that
effect, or it could have a name related to the fact that it turns on
language-server support.

Please also keep in mind that many (perhaps even most, I didn't count
yet) of Eglot's features are not explicitly invoked via the likes of
"M-x eglot-SOMETHING".  Instead, you enable Eglot in a buffer or for a
project, and then features we already have in Emacs, like M-. or
xref-find-references, or completion-at-point, or eldoc documentation
and function signature hints, or flymake diagnostics -- these and
other features are _enhanced_ by the information coming from the
language server.  Eglot works in the background, feeding these
features with the language-server derived information, and is
otherwise almost completely invisible to the user.  So we are arguing
about the name of something that is barely visible on the user level.

> So we have a reason to finish this now.

Documentation and menu labels are something that can be finalized
after the release branch is cut, as it is routine maintenance job that
is not of critical importance for the code stability.  So I see no
need to rush with that.  We should have this discussion later, after
Eglot is in core, people have read the documentation and tried to use
Eglot in Real Life, and have much better understanding what it is and
what it does (and also what it isn't and doesn't).

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 07.10.2022 09:34, Eli Zaretskii wrote:
> We can (and will) make it easier for
> users to understand what its features do, by labeling the menus and
> describing in the doc strings and help-echo strings what the commands
> and variables really do and what effect they have on Emacs.

Indeed we'll probably get the most bang for the buck by adding a menu 
entry or two which could say something like

   Language Servers -> Connect
   Language Servers -> Shutdown

without renaming the package or its commands.

We could put them alongside EDE's and Semantic's menu entries. Or maybe 
instead, given that EDE is not the recommended choice for "Project 
Support" anymore, and we don't usually recommend Semantic to new users 
either.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> Date: Fri, 7 Oct 2022 13:12:03 +0300
> Cc: ams@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 07.10.2022 09:34, Eli Zaretskii wrote:
> > We can (and will) make it easier for
> > users to understand what its features do, by labeling the menus and
> > describing in the doc strings and help-echo strings what the commands
> > and variables really do and what effect they have on Emacs.
> 
> Indeed we'll probably get the most bang for the buck by adding a menu 
> entry or two which could say something like
> 
>    Language Servers -> Connect
>    Language Servers -> Shutdown
> 
> without renaming the package or its commands.

Yes, something like that.

Bonus points for adding some relatively-thin layer which would allow
Eglot to be just one "backend" for language servers' services, so that
users could use others.  But that may be too much for Emacs 29.1.

> We could put them alongside EDE's and Semantic's menu entries. Or maybe 
> instead, given that EDE is not the recommended choice for "Project 
> Support" anymore, and we don't usually recommend Semantic to new users 
> either.

Or we could make the EDE/Semantic menus have a sub-menu, whereby the
user could select which kind of "support" they want.

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 07.10.2022 14:27, Eli Zaretskii wrote:
>> Date: Fri, 7 Oct 2022 13:12:03 +0300
>> Cc: ams@gnu.org, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>> On 07.10.2022 09:34, Eli Zaretskii wrote:
>>> We can (and will) make it easier for
>>> users to understand what its features do, by labeling the menus and
>>> describing in the doc strings and help-echo strings what the commands
>>> and variables really do and what effect they have on Emacs.
>>
>> Indeed we'll probably get the most bang for the buck by adding a menu
>> entry or two which could say something like
>>
>>     Language Servers -> Connect
>>     Language Servers -> Shutdown
>>
>> without renaming the package or its commands.
> 
> Yes, something like that.
> 
> Bonus points for adding some relatively-thin layer which would allow
> Eglot to be just one "backend" for language servers' services, so that
> users could use others.  But that may be too much for Emacs 29.1.

One or two hooks, shouldn't be hard. But there's no hurry indeed.

>> We could put them alongside EDE's and Semantic's menu entries. Or maybe
>> instead, given that EDE is not the recommended choice for "Project
>> Support" anymore, and we don't usually recommend Semantic to new users
>> either.
> 
> Or we could make the EDE/Semantic menus have a sub-menu, whereby the
> user could select which kind of "support" they want.

That depends on whether we want the menus to present an "intro" to Emacs 
functionality that doesn't require much reading to pick the right choice.

IMHO that can be the best goal for the menu bar. But you might have a 
different understanding of its role.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> Date: Fri, 7 Oct 2022 14:38:34 +0300
> Cc: rms@gnu.org, ams@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> We could put them alongside EDE's and Semantic's menu entries. Or maybe
> >> instead, given that EDE is not the recommended choice for "Project
> >> Support" anymore, and we don't usually recommend Semantic to new users
> >> either.
> > 
> > Or we could make the EDE/Semantic menus have a sub-menu, whereby the
> > user could select which kind of "support" they want.
> 
> That depends on whether we want the menus to present an "intro" to Emacs 
> functionality that doesn't require much reading to pick the right choice.
> 
> IMHO that can be the best goal for the menu bar. But you might have a 
> different understanding of its role.

Something to revisit at a later date, I think.  Too many things are
still in flux: Eglot, tree-sitter...  The functionalities overlap, and
at least I personally don't yet have a clear idea of how to make the
best "mix".

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 07.10.2022 14:48, Eli Zaretskii wrote:
>> Date: Fri, 7 Oct 2022 14:38:34 +0300
>> Cc:rms@gnu.org,ams@gnu.org,emacs-devel@gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>>
>>>> We could put them alongside EDE's and Semantic's menu entries. Or maybe
>>>> instead, given that EDE is not the recommended choice for "Project
>>>> Support" anymore, and we don't usually recommend Semantic to new users
>>>> either.
>>> Or we could make the EDE/Semantic menus have a sub-menu, whereby the
>>> user could select which kind of "support" they want.
>> That depends on whether we want the menus to present an "intro" to Emacs
>> functionality that doesn't require much reading to pick the right choice.
>>
>> IMHO that can be the best goal for the menu bar. But you might have a
>> different understanding of its role.
> Something to revisit at a later date, I think.  Too many things are
> still in flux: Eglot, tree-sitter...  The functionalities overlap, and
> at least I personally don't yet have a clear idea of how to make the
> best "mix".

IIUC tree-sitter will be used by specific major modes that implement the 
integration. Some will just do that from the outset, and some might have 
user options to toggle.

But if those options are featured in the menu bar, they probably will be 
in the major mode's menu, not inside Tools.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> Date: Fri, 7 Oct 2022 15:03:36 +0300
> Cc: rms@gnu.org, ams@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> IMHO that can be the best goal for the menu bar. But you might have a
> >> different understanding of its role.
> > Something to revisit at a later date, I think.  Too many things are
> > still in flux: Eglot, tree-sitter...  The functionalities overlap, and
> > at least I personally don't yet have a clear idea of how to make the
> > best "mix".
> 
> IIUC tree-sitter will be used by specific major modes that implement the 
> integration. Some will just do that from the outset, and some might have 
> user options to toggle.

Yes, so take python-mode as an example.  It has both tree-sitter
support and Eglot support.  How to use both? does it even make sense?

> But if those options are featured in the menu bar, they probably will be 
> in the major mode's menu, not inside Tools.

For Eglot, probably.  For tree-sitter, I don't know yet.  If we have
enough modes with tree-sitter support, it might make sense to allow it
globally.

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 07.10.2022 15:09, Eli Zaretskii wrote:
>> Date: Fri, 7 Oct 2022 15:03:36 +0300
>> Cc: rms@gnu.org, ams@gnu.org, emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>>>> IMHO that can be the best goal for the menu bar. But you might have a
>>>> different understanding of its role.
>>> Something to revisit at a later date, I think.  Too many things are
>>> still in flux: Eglot, tree-sitter...  The functionalities overlap, and
>>> at least I personally don't yet have a clear idea of how to make the
>>> best "mix".
>>
>> IIUC tree-sitter will be used by specific major modes that implement the
>> integration. Some will just do that from the outset, and some might have
>> user options to toggle.
> 
> Yes, so take python-mode as an example.  It has both tree-sitter
> support and Eglot support.  How to use both? does it even make sense?

Sure.

Eglot: code completion, navigation, show method docs, calltips.
TreeSitter: syntax highlighting, maybe indentation and imenu.

So TreeSitter can help improve the "classic" features of major modes, 
but not build code intelligence on top, because it only works with 
individual files, just like existing major modes and their regexp based 
parsers (in font-lock, etc).

>> But if those options are featured in the menu bar, they probably will be
>> in the major mode's menu, not inside Tools.
> 
> For Eglot, probably.  For tree-sitter, I don't know yet.

Above, I was talking solely about tree-sitter.

> If we have
> enough modes with tree-sitter support, it might make sense to allow it
> globally.

I think the issue is going to be how well each mode integrates with 
tree-sitter. Those that do it well, can enable it by default right away. 
Those that don't will have different problems.

So it's not like we'll be able to decide that we're fine with a certain 
class of limitations, so let's enable it wholesale.

And there will always remain major modes that don't have tree-sitter 
integration.

Re: Renaming eglot -- or at least add an alias?

[Emanuel Berg]

Dmitry Gutov wrote:

> Eglot: code completion, navigation, show method docs,
> calltips. TreeSitter: syntax highlighting, maybe indentation
> and imenu.

Can't we have an "assistant" as well, like the one in MS Word?

  It looks like you're writing a letter ...

So here with Elisp it would be

  It looks like you're implementing the Bubblesort algorithm.
  Beware that it performs poorly in real world use! But if you
  really want it, actually some dude on MELPA already has it
  <reference 69b06f306a5fc2b38e707bae3ff1e35db2b39b6b>

Or would that be annoying you think?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Emanuel Berg <incal@dataswamp.org> writes:

> Dmitry Gutov wrote:
>
>> Eglot: code completion, navigation, show method docs,
>> calltips. TreeSitter: syntax highlighting, maybe indentation
>> and imenu.
>
> Can't we have an "assistant" as well, like the one in MS Word?
>
>   It looks like you're writing a letter ...
>
> So here with Elisp it would be
>
>   It looks like you're implementing the Bubblesort algorithm.
>   Beware that it performs poorly in real world use! But if you
>   really want it, actually some dude on MELPA already has it
>   <reference 69b06f306a5fc2b38e707bae3ff1e35db2b39b6b>
>
> Or would that be annoying you think?

Personally, I'd find it annoying. However, it is pretty much what
Github's co pilot does and many seem to love it.

I'm an old dog who probably has trouble with 'new tricks'. However, I
hate seeing the current state of much of the development I see where
programs seem to be nothing more than cobbled together cut n paste from
various web forums like stack overflow, github, reddit etc with very
little sign/clarity regarding design or the algorithms being used. To
often, I see people tracking down bugs by using a debugger and slowly
stepping through the code wathing variables rather than actually reading
and getting to udnerstand it (probably because it is just a jumble of
cut n paste). An assistant who just jumps in and proposes code is likely
to reduce understanding rather than increase it.

On the other hand, anything which makes it easier for non-programmers to
program is probably well aligned with the goals of the FSF
i.e. empowering users rather than making them dependent on members of
the secret programming guild!

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I never even thought about using Company mode, because its name gave
me no idea of what it was for.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think that will not work, because Semantic does the same thing, and we
  > already give it the menu item "source code parsers".

I'd like to understand in more detail the similarities and differences
between Eglot and Sematic -- NOT at the level of how they work, but in
terms of which jobs they do in which cases.  Think of a case as a
combination of source language and job to be done.

Do they tend to do similar jobs, but for different languages?  If so,
we could think of them as two alternate methods to use.  chosen by the
mode or operation.  The user doesn't have to think of this as a
choice.  The user could request, "Please do code parsing for my C
files, and use whichever method works for the action I try to do."

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > The main change is that Emacs should refer to the package and its
  > > functionality primarily as Parse Code in menus and documentation.

  > I think this will not be the best solution, because the features
  > enabled by Eglot use the results of parsing performed by an external
  > server, they don't perform any parsing.

That's an implementation detail, not important for this aspect of things.

The point is that the feature users will enable is a feature of parsing code
(wherever that is implemented).  It is generally better to talk with users
in terms that make sense at the user's level.

People have pointed out that Semantic also parses code.
Perhaps we should think of Eglot and Semantic as two methods
by which Emacs implementrs one feature (parsing code).

We could have a Parse Code feature which uses can enable.  For some
actions and languages, it would use Eglot, and for others it would use
Semantic, but users should not have to know about those two (unless
they are curious).

  > But it's too early and premature to discuss what we will say in our
  > menus, because we have no idea what these menus will be and which
  > features they will activate.

I'm talking about more than "menus".  I'm talking about how we will
describe this feature in all kinds of documentation.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > As I've said MANY times in this thread, eglot is just a
  > client which is the glue between Emacs and servers which implement the
  > language server protocol. It is the servers that have all the language
  > specific functionality.

This is just an implementation detail.

  > GO one step further. Consider a user who is having problems with the
  > package they know as 'Parse Code". The first thing they will do is enter
  > something in a search engine to try and find a result.

The first thing the user should do is look in the Emacs Manual, in the
index.  But the manual is posted on web sites, and will show up in
search engines too.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Is there any programming language which is supported both by Eglot and
  > > by Semantic?

  > C/C++/any other Semantic-supported langugages.

Thanks.  We have gone a step forward.

Eglot does various sorts of actions.  People have posted lists of them.
Which of them does it support for C/C++?

Now let's compare it with Semantic.  Which of those actions does
Semantic support for those languages?  Does Semantic support any other
actions, for those languages?

Now suppose a user enables Eglot and Semantic -- so that for certain
actions they are both available.  How does Emacs decide which one to use,
for jobs they can both do?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I see no pain in adding aliases and descriptive one-liners to an
  > existing package.

We are talking about two different kinds of changes.  You're talking
about simple little changes.  They would not be much work but they
would not do much good.

I'm talking about choosing a simple and clear way to describe thie feature
to the user, which would call for some change in code and more change
in how we write about this in Emacs documention.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > How to deal with Eglot and Semantic is not clear to me.
  > >
  > > Is there any programming language which is supported both by Eglot and
  > > by Semantic?

  > I think this question still shows a fundamental lack of understanding
  > regarding what eglot is and does.

There is a lot I don't know, which is why I am asking question after question.

  > Eglot doens't know anything about programming languages. What languages
  > it is able to work with is determined by the available language
  > servers.

That's the pedantic way of looking on it -- in terms of implementation
details.

In the user's terms, though, in any editing session, Eglot supports
certain language and not others.  The user may not know why, but perse
sees that Eglot works for A and doesn't work for B.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > How to deal with Eglot and Semantic is not clear to me.
  > >
  > > Is there any programming language which is supported both by Eglot and
  > > by Semantic?

  > I think this question still shows a fundamental lack of understanding
  > regarding what eglot is and does.

There is a lot I don't know, which is why I am asking question after question.

  > Eglot doens't know anything about programming languages. What languages
  > it is able to work with is determined by the available language
  > servers.

That's the pedantic way of looking on it -- in terms of implementation
details.

In the user's terms, though, in any editing session, Eglot supports
certain language and not others.  The user may not know why, but perse
sees that Eglot works for A and doesn't work for B.

  >  Some people will likely prefer a semantic based
  > workflow and others may prefer an eglot one (and yet others may prefer

It sounds like the commands for using Semantic on a file may be very
different from the commands for using Eglot on that same file.
Is that right?

It sounds like we have created a lot of complexity that it would
be better to replace with simpler, more uniform interfaces.

Is that possible in principle?

Could we have something comparable to GUD and VC to unify these parsing
facilities?




-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 08.10.2022 01:49, Richard Stallman wrote:
> We could have a Parse Code feature which uses can enable.  For some
> actions and languages, it would use Eglot, and for others it would use
> Semantic, but users should not have to know about those two (unless
> they are curious).

I'm not aware of any languages where Semantic is universally (meaning, 
for most users) a better option.

It can still serve those who have written a custom grammar for some 
domain-specific language, and those who have been using it for a while, 
and not willing to switch.

In most other cases, Eglot (or LSP-Mode) should be preferred. There are 
other third-party language support packages (such as Cider for Clojure 
or Robe for Ruby) which some consider superior, but neither has been 
proposed for inclusion, so I'm just mentioning that for completeness.

Re: Renaming eglot -- or at least add an alias?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

On Sat, Oct 08, 2022 at 09:03:01AM +1100, Tim Cross wrote:
> 
> Emanuel Berg <incal@dataswamp.org> writes:
> 
> > Dmitry Gutov wrote:
> >
> >> Eglot: code completion, navigation, show method docs,
> >> calltips. TreeSitter: syntax highlighting, maybe indentation
> >> and imenu.
> >
> > Can't we have an "assistant" as well, like the one in MS Word?
> >
> >   It looks like you're writing a letter ...
> >
> > So here with Elisp it would be
> >
> >   It looks like you're implementing the Bubblesort algorithm.
> >   Beware that it performs poorly in real world use! But if you
> >   really want it, actually some dude on MELPA already has it
> >   <reference 69b06f306a5fc2b38e707bae3ff1e35db2b39b6b>
> >
> > Or would that be annoying you think?
> 
> Personally, I'd find it annoying. However, it is pretty much what
> Github's co pilot does and many seem to love it.

[more good reasons]

What I miss here is the "big picture".

Programming is an eminently social activity. More so when it tries
to tackle big project.

What Microsoft is doing here (and succeeding at a horrifying speed)
is building a "social network" for programming, to feed on hacker's
behavioral surplus [1].

The acquisition of Github was just an especially successful move
in that direction; before, they acquired LinkedIn, for example.
They were desperately searching for a niche left over by Google,
Facebook and Twitter -- and they seem to have found it.

Copilot is just the next step (Chapter Ten "Make Them Dance")
described in Zuboff's book. Basically it is what Google
tried with Pokémon Go.

Cheers

[1] Shoshana Zuboff: "The Age of Surveillance  Capitalism"

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Oct 2022 18:50:05 -0400
> 
> I'm talking about choosing a simple and clear way to describe thie feature
> to the user, which would call for some change in code and more change
> in how we write about this in Emacs documention.

This has no hope of being discussed efficiently until all of the
participants have a good understanding of what the package does and
how.  Please wait at least until the Eglot manual is ready in its
first draft, and let's take it from there.  The current discussion is
based on many misconceptions, misunderstandings, and inaccurate
statements, and is basically a huge waste of everyone's time.

When the Eglot manual is published, you and others will have a chance
of reading its explanations of what Eglot does and how we intent to
integrate it into the Emacs source-code editing features, optionally
enhance that by looking at the Eglot code (which is just 3300 lines of
Lisp), and have a clear picture of what we are talking about.  Then
this discussion will be practical and efficient (and some parts of it
will be unnecessary), and we could have hope of reaching some useful
conclusions.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> Date: Sat, 8 Oct 2022 07:32:06 +0200
> From: <tomas@tuxteam.de>
> 
> What Microsoft is doing here (and succeeding at a horrifying speed)
> is building a "social network" for programming, to feed on hacker's
> behavioral surplus [1].
> 
> The acquisition of Github was just an especially successful move
> in that direction; before, they acquired LinkedIn, for example.
> They were desperately searching for a niche left over by Google,
> Facebook and Twitter -- and they seem to have found it.
> 
> Copilot is just the next step (Chapter Ten "Make Them Dance")
> described in Zuboff's book. Basically it is what Google
> tried with Pokémon Go.

How is this related to the issue at hand?

Re: Renaming eglot -- or at least add an alias?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Sat, Oct 08, 2022 at 09:52:27AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 8 Oct 2022 07:32:06 +0200
> > From: <tomas@tuxteam.de>
> > 
> > What Microsoft is doing here (and succeeding at a horrifying speed)
> > is building a "social network" for programming, to feed on hacker's
> > behavioral surplus [1].

[...]

> How is this related to the issue at hand?

Just an appeal to think before copying a pattern which may as well
turn out to be an anti-pattern.

Ignore if not interested :)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Renaming eglot -- or at least add an alias?

[xenodasein--- via Emacs development discussions.]

> FWIW,
>
> The word "bikeshedding" often gets thrown around when someone tries to
> find ways of making Emacs easier to use.  I don't think that is the best
> approach.  Ease of use often comes down to minor details, in themselves
> not a big deal, but that taken together will start to add up.
>
> I also think the claim that naming doesn't matter is wrong.  Naming of
> user facing features *does* matter, especially of important features
> such as this one.  We have enough technical debt, quirks and historical
> baggage in Emacs as it is.

I completely agree, what is out of place is that since there seems to be
no desire to a unified naming scheme undertaking, and will probably never
be one as there will always be something more important than "just cleaning
things up" like emulating LibreOffice, only Eglot gets the ire of
inconsistencies, and all the previous packages and likely most future ones
will keep having unique names anyway, and this is not fair or nice.

> Several people have argued the renaming case effectively, and I haven't
> seen any need to add much beyond that.  But it's clear to me now that we
> haven't been able to find a significantly better name.  Given that there
> is also a lot of opposition to renaming, I think I agree that, on
> balance, it might be better to leave this alone.
>
> Long live Eglot.  I'm happy to see it merged.

So IMO if there is a problem it lies deeper and not on naming choice of
Eglot per se.

Re: Renaming eglot -- or at least add an alias?

[chad]

[-- Attachment #1: Type: text/plain, Size: 3504 bytes --]

On Fri, Oct 7, 2022 at 6:56 PM Richard Stallman <rms@gnu.org> wrote:

> It sounds like the commands for using Semantic on a file may be very
> different from the commands for using Eglot on that same file.
> Is that right?
>

"Commands" is probably the wrong way to think about both Semantic/EDE and
eglot (and lsp-mode, etc). The high-level idea in both cases is to enhance
existing emacs facilities (including those that are enabled by default,
those that are shipped with emacs but must be enabled by the user, and
those that are packaged separately from the emacs core) by adding a more
in-depth comprehension of the code the user is examining, modifying,
writing, etc.

Many of these facilities (absent something like Semantic/EDE/eglot/lsp/etc)
using heuristics, conventions, and regexp-based functionality to try to
"understand" the code, and then use that understanding to help the
programmer, for examples, with fontification, completion, pop-up
documentation, additional navigation, and the like.

I believe that a big part of the difficulty of putting a concrete handle on
"what does eglot (or semantic) do?" comes in here: many of the things that
are enabled/enhanced are already present in emacs. For example, M-. runs
xref-find-definitions to find the definition of the thing at point. Emacs
has had this functionality for a long time, and there are several optional
packages that enhance it, using TAGS, rtags, ag, or gnu global to *find*
the reference, or using helm or ivy to access the references. Semantic and
eglot (among others) add functionality that attempts to understand the code
using the same mechanism that, for example, compilers use. (In
Semantic's case, it implements compiler-like tokenizer/lexer/parser
functionality in elisp; the Language Server Protocol (LSP) approach is
instead to use an external tool, often built from the same parts as the
compiler/interpreter, and communicate the "relevant information" over a
channel to an editor).

In this sense, the "eglot commands" are just the ancillary machinery to
make the enhancements happen "in the background" -- telling emacs to start
using the facility, managing the connection and the external process, and,
importantly, configuring that external machinery. That last is important
because there is no "one true LSP server", even for a given language, so
configuration is required. We can hope that this will settle out over time,
but LSP (the protocol that the external tools use to provide
editor-agnostic* information) is still developing, and people are
discovering new ways to integrate a deeper understanding of code into
editing (and reviewing, debugging, etc.) environments.

About Semantic: as has probably become clear by the time you read this, one
of the particular issues of this precise moment in the conversation is that
Semantic *does* parse the code in question, whereas eglot instead serves as
a bridge between the external tools that parse (and more) the code and
emacs' existing (and upcoming) features for editing (reviewing, etc.) code.

In a rough analogy, Semantic can be thought of as "let's replace rcs.el
with something like CVS implemented mostly in elisp", while eglot (and its
cousin lsp-mode) are much more like VC -- the glue between emacs and a
variety of external tools for grokking C, JavaScript, Python, etc.  VC
abstracts over "version control". Gnus abstracts over "message systems".
Eglot attempts to abstract over "understanding (computer) languages".

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 4114 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Alexander Adolf]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]


> On 7. Oct 2022, at 16:32, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> So TreeSitter can help improve the "classic" features of major modes, but not build code intelligence on top, because it only works with individual files, just like existing major modes and their regexp based parsers (in font-lock, etc).

Did we stumble across a name candidate here? “Code intelligence”?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1944 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yes, so take python-mode as an example.  It has both tree-sitter
  > support and Eglot support.  How to use both? does it even make sense?

Do they do the same jobs?  Are they intersubstitutable, in principle?
If so, the question is, are they compatible in user interface?

If they are intersubstitutable, in principle, maybe they ought to have
the same user interface so that most users would not notice or care
which one is doing the job.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

chad <yandros@gmail.com> writes:

> The high-level idea in both cases is to enhance existing emacs
> facilities (including those that are enabled by default, those that
> are shipped with emacs but must be enabled by the user, and those that
> are packaged separately from the emacs core) by adding a more in-depth
> comprehension of the code the user is examining, modifying, writing,
> etc.

That may be true of Eglot, but not of Semantic.  Type "C-c , C-h" and
see for yourself.

Re: Renaming eglot -- or at least add an alias?

[Stefan Monnier]

> Did we stumble across a name candidate here? “Code intelligence”?

It's a bit long, but ... `CIA-mode` anyone?


        Stefan

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 08 Oct 2022 18:34:03 -0400
> 
>   > Yes, so take python-mode as an example.  It has both tree-sitter
>   > support and Eglot support.  How to use both? does it even make sense?
> 
> Do they do the same jobs?  Are they intersubstitutable, in principle?

Not clear yet (to me).  Dmitry says they are basically orthogonal in
the features they support.

One difficulty here is that Eglot exists for some years, so what it
does and how is pretty clear; by contrast, tree-sitter support in
Emacs is very young, and where it could potentially develop needs more
study, at least on my part.

> If so, the question is, are they compatible in user interface?
> 
> If they are intersubstitutable, in principle, maybe they ought to have
> the same user interface so that most users would not notice or care
> which one is doing the job.

You are basically asking the same questions I did.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> Date: Sun, 09 Oct 2022 07:38:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Richard Stallman <rms@gnu.org>
> > Cc: emacs-devel@gnu.org
> > Date: Sat, 08 Oct 2022 18:34:03 -0400
> > 
> >   > Yes, so take python-mode as an example.  It has both tree-sitter
> >   > support and Eglot support.  How to use both? does it even make sense?
> > 
> > Do they do the same jobs?  Are they intersubstitutable, in principle?
> 
> Not clear yet (to me).  Dmitry says they are basically orthogonal in
> the features they support.
> 
> One difficulty here is that Eglot exists for some years, so what it
> does and how is pretty clear; by contrast, tree-sitter support in
> Emacs is very young, and where it could potentially develop needs more
> study, at least on my part.

For example, at least up-front, it sounds like the LSP specification
supports both fontifications and indentation.  Eglot, AFAICT, allows
to request the language server to do the latter (via the eglot-format
command), but doesn't support requesting information about token
types, which could be used for fontification.

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").

Re: Renaming eglot -- or at least add an alias?

[Theodor Thornhill]

>> One difficulty here is that Eglot exists for some years, so what it
>> does and how is pretty clear; by contrast, tree-sitter support in
>> Emacs is very young, and where it could potentially develop needs more
>> study, at least on my part.
>
>For example, at least up-front, it sounds like the LSP specification
>supports both fontifications and indentation.  Eglot, AFAICT, allows
>to request the language server to do the latter (via the eglot-format
>command), but doesn't support requesting information about token
>types, which could be used for fontification.
>
>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'm not sure putting all of this behind json parsing is the best idea. In the case where a server can produce 30k completion per keystroke, adding in font lock for a file of 15k lines is begging for trouble. Not to mention all the other stuff jsonrpc returns in in the meantime. 

This ends very quickiy in unresponsive emacs per keystroke

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 09 Oct 2022 07:38:24 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > From: Richard Stallman <rms@gnu.org>
>> > Cc: emacs-devel@gnu.org
>> > Date: Sat, 08 Oct 2022 18:34:03 -0400
>> > 
>> >   > Yes, so take python-mode as an example.  It has both tree-sitter
>> >   > support and Eglot support.  How to use both? does it even make sense?
>> > 
>> > Do they do the same jobs?  Are they intersubstitutable, in principle?
>> 
>> Not clear yet (to me).  Dmitry says they are basically orthogonal in
>> the features they support.
>> 
>> One difficulty here is that Eglot exists for some years, so what it
>> does and how is pretty clear; by contrast, tree-sitter support in
>> Emacs is very young, and where it could potentially develop needs more
>> study, at least on my part.
>
> For example, at least up-front, it sounds like the LSP specification
> supports both fontifications and indentation.  Eglot, AFAICT, allows
> to request the language server to do the latter (via the eglot-format
> command), but doesn't support requesting information about token
> types, which could be used for fontification.
>
> 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").

To add to the complexity, 'best' will depend heavily on the LSP language
server being used. Some servers are more feature rich than others and
some are better implementations than others. For example, I changed the
language server I use with Javascript as I found a different one from
that being used by most LSP clients which was faster and handled
indentation 'better'. I can imagine there will be situations/languages
where tree-sitter does a better job than the currently existing LSP
servers for that language.

Whatever the default is, the user will need the easy ability to select
which functionality is provided by which package. 

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 09.10.2022 07:57, Eli Zaretskii wrote:
>> Date: Sun, 09 Oct 2022 07:38:24 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>>> From: Richard Stallman <rms@gnu.org>
>>> Cc: emacs-devel@gnu.org
>>> Date: Sat, 08 Oct 2022 18:34:03 -0400
>>>
>>>    > Yes, so take python-mode as an example.  It has both tree-sitter
>>>    > support and Eglot support.  How to use both? does it even make sense?
>>>
>>> Do they do the same jobs?  Are they intersubstitutable, in principle?
>>
>> Not clear yet (to me).  Dmitry says they are basically orthogonal in
>> the features they support.
>>
>> One difficulty here is that Eglot exists for some years, so what it
>> does and how is pretty clear; by contrast, tree-sitter support in
>> Emacs is very young, and where it could potentially develop needs more
>> study, at least on my part.
> 
> For example, at least up-front, it sounds like the LSP specification
> supports both fontifications and indentation.  Eglot, AFAICT, allows
> to request the language server to do the latter (via the eglot-format
> command), but doesn't support requesting information about token
> types, which could be used for fontification.

LSP syntax highlighting is a new-ish thing, and apparently isn't 
supported by Eglot. Further, passing the highlighting information over 
the wire is bound to be slower than the in-process integration offered 
by TreeSitter.

Indentation - maybe, I'd have to check how well it works first. The 
indentation code we have already seems to be good for the majority of 
languages, and having it in Elisp makes it more easily hackable and 
customizable.

TreeSitter indentation logic will not be entirely in Elisp, but almost 
as hackable nevertheless.

> 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'd recommend keeping the divide where I described it, but then keep an 
eye out for whether one of the options makes a noticeably better job 
somewhere at the other's turf. Maybe after Emacs 29.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> Date: Sun, 9 Oct 2022 15:44:19 +0300
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> Not clear yet (to me).  Dmitry says they are basically orthogonal in
> >> the features they support.
> >>
> >> One difficulty here is that Eglot exists for some years, so what it
> >> does and how is pretty clear; by contrast, tree-sitter support in
> >> Emacs is very young, and where it could potentially develop needs more
> >> study, at least on my part.
> > 
> > For example, at least up-front, it sounds like the LSP specification
> > supports both fontifications and indentation.  Eglot, AFAICT, allows
> > to request the language server to do the latter (via the eglot-format
> > command), but doesn't support requesting information about token
> > types, which could be used for fontification.
> 
> LSP syntax highlighting is a new-ish thing, and apparently isn't 
> supported by Eglot. Further, passing the highlighting information over 
> the wire is bound to be slower than the in-process integration offered 
> by TreeSitter.
> 
> Indentation - maybe, I'd have to check how well it works first. The 
> indentation code we have already seems to be good for the majority of 
> languages, and having it in Elisp makes it more easily hackable and 
> customizable.
> 
> TreeSitter indentation logic will not be entirely in Elisp, but almost 
> as hackable nevertheless.
> 
> > 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'd recommend keeping the divide where I described it, but then keep an 
> eye out for whether one of the options makes a noticeably better job 
> somewhere at the other's turf. Maybe after Emacs 29.

I'm not trying to make an argument, just point out that the jury is
still out about these issues, and we need at some point make our
minds.

Re: Renaming eglot -- or at least add an alias?

[Felician Nemeth]

> LSP syntax highlighting is a new-ish thing, and apparently isn't
> supported by Eglot.

True, but there is a pending patch by Akib Azmain Turja that adds this
very feature to Eglot.  Akib hopes to start the copyright process soon.

https://github.com/joaotavora/eglot/pull/839

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 09.10.2022 17:09, Felician Nemeth wrote:
>> LSP syntax highlighting is a new-ish thing, and apparently isn't
>> supported by Eglot.
> True, but there is a pending patch by Akib Azmain Turja that adds this
> very feature to Eglot.  Akib hopes to start the copyright process soon.
> 
> https://github.com/joaotavora/eglot/pull/839

Do you expect it to have advantages compared to using TreeSitter?

Re: Renaming eglot -- or at least add an alias?

[chad]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Sat, Oct 8, 2022 at 8:35 PM Po Lu <luangruo@yahoo.com> wrote:

> chad <yandros@gmail.com> writes:
>
> > The high-level idea in both cases is to enhance existing emacs
> > facilities (including those that are enabled by default, those that
> > are shipped with emacs but must be enabled by the user, and those that
> > are packaged separately from the emacs core) by adding a more in-depth
> > comprehension of the code the user is examining, modifying, writing,
> > etc.
>
> That may be true of Eglot, but not of Semantic.  Type "C-c , C-h" and
> see for yourself.
>

My mistake. I thought that semantic had integrated more fully since being
brought into core, but that's clearly wrong. Apologies.

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Felician Nemeth]

>>> LSP syntax highlighting is a new-ish thing, and apparently isn't
>>> supported by Eglot.
>> True, but there is a pending patch by Akib Azmain Turja that adds this
>> very feature to Eglot.  Akib hopes to start the copyright process soon.
>> https://github.com/joaotavora/eglot/pull/839
>
> Do you expect it to have advantages compared to using TreeSitter?

I'm not very familiar with TreeSitter, but I think TreeSitter would for
all practical cases provide a faster/simpler solution to font-locking.

(TreeSitter uses an already defined grammar, whereas an LSP server could
potentially take into account dynamic information.  I've reimplemented
the hangman game as an LSP server, and there the color of a word depends
on its location within the file.  The color of the hanged man could also
depend on the number of remaining guesses.)

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 09.10.2022 17:45, Felician Nemeth wrote:
>>>> LSP syntax highlighting is a new-ish thing, and apparently isn't
>>>> supported by Eglot.
>>> True, but there is a pending patch by Akib Azmain Turja that adds this
>>> very feature to Eglot.  Akib hopes to start the copyright process soon.
>>> https://github.com/joaotavora/eglot/pull/839
>> Do you expect it to have advantages compared to using TreeSitter?
> I'm not very familiar with TreeSitter, but I think TreeSitter would for
> all practical cases provide a faster/simpler solution to font-locking.
> 
> (TreeSitter uses an already defined grammar, whereas an LSP server could
> potentially take into account dynamic information.  I've reimplemented
> the hangman game as an LSP server, and there the color of a word depends
> on its location within the file.  The color of the hanged man could also
> depend on the number of remaining guesses.)

That's my understanding of it as well.

I suppose Eglot could provide some extra highlighting (e.g. for defined 
classes, or methods, at callsites), but to get that information, the 
language has to scan the full project first (or a significant part, at 
least).

That would mean the fontification would need to be delayed 
significantly, or it would have the "blinking" effect we recently saw 
discussed (and complained about) with CC Mode.

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Whatever the default is, the user will need the easy ability to select
  > which functionality is provided by which package. 

I won't argue against that.  But I suggest that the best conceptual
organization for this would have these two levels:

1. A control to enable or disable the functionality.

2. Various ways to specify preference of back end for various parts of it.

I suggest that #1 be simple, as lots of people will want to enable the
functionality, and that we put the complexity into #2 since it would
be used by more sophisticated users to make more sophisticated
choices.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Not clear yet (to me).  Dmitry says they are basically orthogonal in
  > the features they support.

Is this a coincidence, that different features just happen to be
implemented in the two?  Or is it for some underlying reason that
is unlikely to change?

Let's suppose that they continue to be basically disjoint in terms of
features.  Then we will never (or hardly ever) need to worry about
"Which underlying method to do feature F with?"

So, do we need to offer users the option of enabling Tree-sitter and not
Eglot, and the option of enabling Eglot and not Tree-sitter?

Or will users generally be happy with a single control to enable both
of them (whichever are implemented for the language in use)?

  > > If they are intersubstitutable, in principle, maybe they ought to have
  > > the same user interface so that most users would not notice or care
  > > which one is doing the job.

  > You are basically asking the same questions I did.

Good that we are following the same line of thinking.
Could you show me the answers you got?

If they were already posted on the list, could you send them
just to me?  No need to ask others to read them again.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 10 Oct 2022 18:05:36 -0400
> 
>   > Not clear yet (to me).  Dmitry says they are basically orthogonal in
>   > the features they support.
> 
> Is this a coincidence, that different features just happen to be
> implemented in the two?  Or is it for some underlying reason that
> is unlikely to change?

They both parse and analyze the program source.

> Let's suppose that they continue to be basically disjoint in terms of
> features.  Then we will never (or hardly ever) need to worry about
> "Which underlying method to do feature F with?"
> 
> So, do we need to offer users the option of enabling Tree-sitter and not
> Eglot, and the option of enabling Eglot and not Tree-sitter?

Eglot needs a server to be installed and started, so it will always
require an explicit action.  Moreover, a server supports one language
(or a small number of them), so different ones need to be started if
the project involves several languages.

Tree-sitter activation could be more automatic, based on the
availability of the language support.

>   > > If they are intersubstitutable, in principle, maybe they ought to have
>   > > the same user interface so that most users would not notice or care
>   > > which one is doing the job.
> 
>   > You are basically asking the same questions I did.
> 
> Good that we are following the same line of thinking.
> Could you show me the answers you got?

I don't have any answers yet, which is why I posted the questions.

Re: Renaming eglot -- or at least add an alias?

[Theodor Thornhill]

Eli Zaretskii <eliz@gnu.org> writes:


[...]

>>   > > If they are intersubstitutable, in principle, maybe they ought to have
>>   > > the same user interface so that most users would not notice or care
>>   > > which one is doing the job.
>> 
>>   > You are basically asking the same questions I did.
>> 
>> Good that we are following the same line of thinking.
>> Could you show me the answers you got?
>
> I don't have any answers yet, which is why I posted the questions.

One major difference is that tree sitter does just parsing, and provides
interface to access the returned tree.  It works on _one_ file, and does
not care of project semantics, package managers, dependency fetching etc
etc etc.  That's LSPs job.  Going to references, opening files in
directories outside of the project is also for LSP, thus Eglot.
Returning completions etc etc etc.

Tree-sitter _cannot_ do these things. However, it is fast, which is the
major selling point.  That is why you'd want to use that for
indentation, font locking and the simpler things.  You can also hack on
tree-sitter.  When provided with a proper api it is easy to extend
yourself and add utilities in your own config.  Not so much for LSP.
Whatever is to be done must be supported by said server.

They look similar, but in reality they are not.  Yes, both can
font-lock, but that's almost where the similarities end.

Because all of the interaction between server and client in lsp is json
there's a huge overhead with parsing and shipping things into the emacs
user interface.  So IMO what tree-sitter is good at should be left to
tree-sitter.

(font locking in the server is often just a wrapper of tree-sitter
shipped over json anyways).

Theo

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 11.10.2022 12:44, Theodor Thornhill wrote:
> Eli Zaretskii<eliz@gnu.org>  writes:
> 
> 
> [...]
> 
>>>    > > If they are intersubstitutable, in principle, maybe they ought to have
>>>    > > the same user interface so that most users would not notice or care
>>>    > > which one is doing the job.
>>>
>>>    > You are basically asking the same questions I did.
>>>
>>> Good that we are following the same line of thinking.
>>> Could you show me the answers you got?
>> I don't have any answers yet, which is why I posted the questions.
> One major difference is that tree sitter does just parsing, and provides
> interface to access the returned tree.  It works on_one_  file, and does
> not care of project semantics, package managers, dependency fetching etc
> etc etc.  That's LSPs job.  Going to references, opening files in
> directories outside of the project is also for LSP, thus Eglot.
> Returning completions etc etc etc.
> 
> Tree-sitter_cannot_  do these things. However, it is fast, which is the
> major selling point.  That is why you'd want to use that for
> indentation, font locking and the simpler things.  You can also hack on
> tree-sitter.  When provided with a proper api it is easy to extend
> yourself and add utilities in your own config.  Not so much for LSP.
> Whatever is to be done must be supported by said server.
> 
> They look similar, but in reality they are not.  Yes, both can
> font-lock, but that's almost where the similarities end.
> 
> Because all of the interaction between server and client in lsp is json
> there's a huge overhead with parsing and shipping things into the emacs
> user interface.  So IMO what tree-sitter is good at should be left to
> tree-sitter.
> 
> (font locking in the server is often just a wrapper of tree-sitter
> shipped over json anyways).

Here's also a comment on HN by the author of TreeSitter supporting this 
view: https://news.ycombinator.com/item?id=18349488

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Did we stumble across a name candidate here? “Code intelligence”?

  > It's a bit long, but ... `CIA-mode` anyone?

Perhaps "Code-Parse mode"?
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

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.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Stefan Monnier]

Richard Stallman [2022-10-11 17:15:09] wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>   > > Did we stumble across a name candidate here? “Code intelligence”?
>   > It's a bit long, but ... `CIA-mode` anyone?
> Perhaps "Code-Parse mode"?

Do you mean it for Eglot or for Tree-Sitter?
;-)


        Stefan

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> 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.

Re: Renaming eglot -- or at least add an alias?

[Yuan Fu]

> On Oct 11, 2022, at 11:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Richard Stallman <rms@gnu.org>
>> 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.

IMO in some sense, eglot and major mode sits at the same level, and tree-sitter a level lower. Consider this: take imenu as an example. Major mode sets imenu-create-index-function for imenu to function. A major mode now has two options available, one function uses tree-sitter and one don’t. If the user enables eglot, eglot sets menu-create-index-function to eglot-imenu, overriding major mode’s function. From this perspective, tree-sitter is just a mechanism a major mode could use, not unlike syntax-ppss, while eglot do things its own way, replacing parts of the major mode’s functionality with its own.

So it’s not really “two back-ends”, tree-sitter and eglot are different in fundamental ways.

Yuan

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Tue, 11 Oct 2022 23:37:28 -0700
> Cc: Richard Stallman <rms@gnu.org>,
>  emacs-devel@gnu.org
> 
> > 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.
> 
> IMO in some sense, eglot and major mode sits at the same level, and tree-sitter a level lower. Consider this: take imenu as an example. Major mode sets imenu-create-index-function for imenu to function. A major mode now has two options available, one function uses tree-sitter and one don’t. If the user enables eglot, eglot sets menu-create-index-function to eglot-imenu, overriding major mode’s function. From this perspective, tree-sitter is just a mechanism a major mode could use, not unlike syntax-ppss, while eglot do things its own way, replacing parts of the major mode’s functionality with its own.
> 
> So it’s not really “two back-ends”, tree-sitter and eglot are different in fundamental ways.

My vision of the relation is different from yours.  Major mode sets
imenu-create-index-function to some code that can either use
tree-sitter or some other way of detecting the symbols for the index.
That other way includes Eglot.  The fact that Eglot overrides the
mode's setting is just an implementation detail.

And none of that matters for the user, btw.  Users don't care much
about implementation, they only care about the possible ways of
getting the functionality, and in this case there are 3 such ways.

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 11 Oct 2022 23:37:28 -0700
>> Cc: Richard Stallman <rms@gnu.org>,
>>  emacs-devel@gnu.org
>> 
>> > 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.
>> 
>> IMO in some sense, eglot and major mode sits at the same level, and tree-sitter a level
>> lower. Consider this: take imenu as an example. Major mode sets
>> imenu-create-index-function for imenu to function. A major mode now has two options
>> available, one function uses tree-sitter and one don’t. If the user enables eglot, eglot
>> sets menu-create-index-function to eglot-imenu, overriding major mode’s function. From
>> this perspective, tree-sitter is just a mechanism a major mode could use, not unlike
>> syntax-ppss, while eglot do things its own way, replacing parts of the major mode’s
>> functionality with its own.
>> 
>> So it’s not really “two back-ends”, tree-sitter and eglot are different in fundamental ways.
>
> My vision of the relation is different from yours.  Major mode sets
> imenu-create-index-function to some code that can either use
> tree-sitter or some other way of detecting the symbols for the index.
> That other way includes Eglot.  The fact that Eglot overrides the
> mode's setting is just an implementation detail.
>
> And none of that matters for the user, btw.  Users don't care much
> about implementation, they only care about the possible ways of
> getting the functionality, and in this case there are 3 such ways.

This all seems to get very confusing/complicated quite fast.

In case it helps, as a user, for most of the languages I work in, here
is what I would want (assuming eglot/tree-sitter support available for
each language.

- Tree-sitter for font lock and indentation. I don't think eglot will be
  fast enough given json parsing and process comms etc.
  
- eglot for linting, xref, completion, doc lookup, code actions etc.
  Most of the time, I want this on a project rather than a file
  basis. Also, I want something which is consistent with co-workers who
  use other editors, but the same language server.

So for me, I want to be able to specify for xxx-mode, use tree-sitter
for font locking and indentation and eglot for everything else. Being
able to easily set that in myh init will be what I am looking for. 

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 12.10.2022 09:37, Yuan Fu wrote:
> If the user enables eglot, eglot sets menu-create-index-function to eglot-imenu, overriding major mode’s function.

I suppose it does override that, but are you sure it's always a good idea?

Are Imenu indexes produced by Eglot really better than what we can do 
with TreeSitter?

IME it doesn't usually need project-wide information, since the menu is 
local to the current file. Some language servers could be smarter in the 
way that they recognize some framework-based patterns, which aren't 
inherent in the language. But the major modes can do that too.

Re: Renaming eglot -- or at least add an alias?

[Robert Weiner]

I am with Lars and Eli.  The name is fine, already widely used and keeping the release to schedule is much more important.

-- rsw

> On Oct 2, 2022, at 11:09 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Manuel Uberti <manuel.uberti@inventati.org> writes:
> 
>> FWIW, because I seem to be in the minority here, I really like the
>> name Eglot.
> 
> I don't think you are -- many people have weighed in saying they like
> the name.  It's just that the people that want a change feel the need to
> talk more, which is natural.
> 
> (Spoiler warning: The name isn't going to change.)
> 

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Robert Weiner <rswgnu@gmail.com> writes:

> I am with Lars and Eli.  The name is fine, already widely used and
> keeping the release to schedule is much more important.

FWIW if the maintainers think Eglot is okay as a name, then I'm fine
with leaving the name as-is.

My problem is searching "language server" in custom gives nothing of
value, while it probably should.

Re: Renaming eglot -- or at least add an alias?

[Alexander Adolf]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]


> On 12. Oct 2022, at 00:05, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> Richard Stallman [2022-10-11 17:15:09] wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>> Did we stumble across a name candidate here? “Code intelligence”?
>>> It's a bit long, but ... `CIA-mode` anyone?
>> Perhaps "Code-Parse mode"?
> 
> Do you mean it for Eglot or for Tree-Sitter?
> ;-)

Good point; and it nicely demonstrates what I was going to say, i.e. that “code-parse mode” seems too narrow. 

That said, cia-mode doesn’t sound as bad to me as it may seem at first glance. Spell “CIA” out to “code intelligence agent”, and your half way there. 🕵️‍♀️

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1944 bytes --]

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Manuel Uberti
>  <manuel.uberti@inventati.org>,  João Távora
>  <joaotavora@gmail.com>, Philip Kaludercic <philipk@posteo.net>,  Tim Cross
>  <theophilusx@gmail.com>,  emacs-devel@gnu.org,  Richard Stallman
>  <rms@gnu.org>
> Date: Wed, 12 Oct 2022 19:55:09 +0800
> 
> FWIW if the maintainers think Eglot is okay as a name, then I'm fine
> with leaving the name as-is.
> 
> My problem is searching "language server" in custom gives nothing of
> value, while it probably should.

In what customs did you search, and in which codebase?

Eglot was not yet landed on master, so how exactly this will look in
Emacs cannot be determined as yet.  But if, after it lands, you see
problems with discoverability, by all means report a documentation
bug.

Re: Renaming eglot -- or at least add an alias?

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> 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.

Eglot is available via GNU ELPA, I expect it to continue this parallel
distribution even after merge into Emacs core. This allows shorter
release cycles for bug fixing and new features.

For this very reason it is good to have a separate Eglot manual, in
order to reflect the changes in time.

Best regards, Michael.

Re: Renaming eglot -- or at least add an alias?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> In what customs did you search, and in which codebase?

customize-apropros.  I searched "language server" with Eglot installed
off ELPA:

  customize-apropos: No customizable group, face, or option matching (language server)

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rswgnu@gmail.com,  larsi@gnus.org,  manuel.uberti@inventati.org,
>  joaotavora@gmail.com,  philipk@posteo.net,  theophilusx@gmail.com,
>  emacs-devel@gnu.org,  rms@gnu.org
> Date: Wed, 12 Oct 2022 21:42:57 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In what customs did you search, and in which codebase?
> 
> customize-apropros.  I searched "language server" with Eglot installed
> off ELPA:
> 
>   customize-apropos: No customizable group, face, or option matching (language server)

customize-apropos looks at symbol names, and that's all.  Discovering
features based on their names only is not the best idea.
apropos-documentation is a much better tool for that.

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Because all of the interaction between server and client in lsp is json
  > > there's a huge overhead with parsing and shipping things into the emacs
  > > user interface.  So IMO what tree-sitter is good at should be left to
  > > tree-sitter.

Supposing this conclusion is valid (which seems plausible to me),
what does that imply about enabliing Eglot and Tree-sitter?

Should we have a command to enable both together (using Tree-sitter for
the jobs it can do, and Eglot for the others) or disable both together?

Should we have three levels of enablement?  (Neither one, Tree-sitter
only, or both)?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Perhaps "Code-Parse mode"?

  > Do you mean it for Eglot or for Tree-Sitter?
  > ;-)

For either one, or both -- whichever ones you have specified
to use when you enable Code-Parse mode.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Renaming eglot -- or at least add an alias?

[Yuan Fu]

> On Oct 12, 2022, at 3:50 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 12.10.2022 09:37, Yuan Fu wrote:
>> If the user enables eglot, eglot sets menu-create-index-function to eglot-imenu, overriding major mode’s function.
> 
> I suppose it does override that, but are you sure it's always a good idea?
> 
> Are Imenu indexes produced by Eglot really better than what we can do with TreeSitter?

I have to way to tell, but surely not worse, since a LSP server knows everything tree-sitter knows and more.

> 
> IME it doesn't usually need project-wide information, since the menu is local to the current file. Some language servers could be smarter in the way that they recognize some framework-based patterns, which aren't inherent in the language. But the major modes can do that too.

Yeah, I think either one should be fine. Eglot saves work for major mode developers, and tree-sitter gives major mode developer and users more option and flexibility, since they need to implement the imenu function.

Yuan

Re: Renaming eglot -- or at least add an alias?

[Yuan Fu]

> On Oct 12, 2022, at 12:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 11 Oct 2022 23:37:28 -0700
>> Cc: Richard Stallman <rms@gnu.org>,
>> emacs-devel@gnu.org
>> 
>>> 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.
>> 
>> IMO in some sense, eglot and major mode sits at the same level, and tree-sitter a level lower. Consider this: take imenu as an example. Major mode sets imenu-create-index-function for imenu to function. A major mode now has two options available, one function uses tree-sitter and one don’t. If the user enables eglot, eglot sets menu-create-index-function to eglot-imenu, overriding major mode’s function. From this perspective, tree-sitter is just a mechanism a major mode could use, not unlike syntax-ppss, while eglot do things its own way, replacing parts of the major mode’s functionality with its own.
>> 
>> So it’s not really “two back-ends”, tree-sitter and eglot are different in fundamental ways.
> 
> My vision of the relation is different from yours.  Major mode sets
> imenu-create-index-function to some code that can either use
> tree-sitter or some other way of detecting the symbols for the index.
> That other way includes Eglot.  The fact that Eglot overrides the
> mode's setting is just an implementation detail.
> 
> And none of that matters for the user, btw.  Users don't care much
> about implementation, they only care about the possible ways of
> getting the functionality, and in this case there are 3 such ways.

Ah, that makes sense. Then maybe we want major modes to have more say on what function uses eglot and what not, because eglot simply “takes over” right now. But I don’t have anything insightful to say about that.

Yuan

Re: Renaming eglot -- or at least add an alias?

[Yuan Fu]

> 
> This all seems to get very confusing/complicated quite fast.
> 
> In case it helps, as a user, for most of the languages I work in, here
> is what I would want (assuming eglot/tree-sitter support available for
> each language.
> 
> - Tree-sitter for font lock and indentation. I don't think eglot will be
>  fast enough given json parsing and process comms etc.
> 
> - eglot for linting, xref, completion, doc lookup, code actions etc.
>  Most of the time, I want this on a project rather than a file
>  basis. Also, I want something which is consistent with co-workers who
>  use other editors, but the same language server.
> 
> So for me, I want to be able to specify for xxx-mode, use tree-sitter
> for font locking and indentation and eglot for everything else. Being
> able to easily set that in myh init will be what I am looking for. 

Thanks for you input. I don’t think eglot (and LSP the protocol) handles font-lock and indent, and tree-sitter doesn’t do the things you listed for eglot. So if you just enable tree-sitter and eglot you should get what you want exactly. I don’t know about eglot, but we are working on the toggle for tree-sitter right now, you can see the other thread I started on this topic.

Yuan

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Yuan Fu <casouri@gmail.com> writes:

>> 
>> This all seems to get very confusing/complicated quite fast.
>> 
>> In case it helps, as a user, for most of the languages I work in, here
>> is what I would want (assuming eglot/tree-sitter support available for
>> each language.
>> 
>> - Tree-sitter for font lock and indentation. I don't think eglot will be
>>  fast enough given json parsing and process comms etc.
>> 
>> - eglot for linting, xref, completion, doc lookup, code actions etc.
>>  Most of the time, I want this on a project rather than a file
>>  basis. Also, I want something which is consistent with co-workers who
>>  use other editors, but the same language server.
>> 
>> So for me, I want to be able to specify for xxx-mode, use tree-sitter
>> for font locking and indentation and eglot for everything else. Being
>> able to easily set that in myh init will be what I am looking for. 
>
> Thanks for you input. I don’t think eglot (and LSP the protocol) handles font-lock and
> indent, and tree-sitter doesn’t do the things you listed for eglot. So if you just enable
> tree-sitter and eglot you should get what you want exactly. I don’t know about eglot, but
> we are working on the toggle for tree-sitter right now, you can see the other thread I
> started on this topic.
>

The LSP does handle providing indentation support (clojure-lsp has that)
and I think code highlighting/font-locking is also being added. However,
I agree with most who are concerned the overheads associated with LSP
are potentially problematic, especially with large files.

I find the file/project distinction useful when looking at tree-sitter
and LSP (eglot). Tree-sitter seems extremely useful for providing parsed
information on a single file while LSP seems useful when you need to
look at things from a project perspective.

Of course, the performance issue associated with LSP and parsing json
also need to be considered in the context of the work (development and
maintenance) required to implement a tree sitter parser for a specific
language. The advantage of the LSP server is that it is able to provide
data for many different editors and has the potential of being actively
supported by the community supporting the language and not jsut the
smaller community supporting an editor mode.

Re: Renaming eglot -- or at least add an alias?

[Stephen Leake]

Yuan Fu <casouri@gmail.com> writes:

> Thanks for you input. I don’t think eglot (and LSP the protocol)
> handles font-lock and indent, 

The LSP protocol supports font-lock via SemanticTokens. This is
relatively new, and the released elgot doesn't support it yet.

LSP supports indent via DocumentFormatting. Eglot supports this via
eglot-format.

I don't know how many language servers support DocumentFormatting;
ada_language_server only supports formatting the whole document, not
just a region, so it is not useful for Emacs indent. ada_language_server
also has poor error recovery, and refuses to format even when it can
recover from a syntax error, making it even less useful.

-- 
-- Stephe

Re: Renaming eglot -- or at least add an alias?

[Stephen Leake]

Yuan Fu <casouri@gmail.com> writes:

>> On Oct 11, 2022, at 11:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
> IMO in some sense, eglot and major mode sits at the same level, and
> tree-sitter a level lower. Consider this: take imenu as an example.
> Major mode sets imenu-create-index-function for imenu to function. A
> major mode now has two options available, one function uses
> tree-sitter and one don’t. If the user enables eglot, eglot sets
> menu-create-index-function to eglot-imenu, overriding major mode’s
> function. From this perspective, tree-sitter is just a mechanism a
> major mode could use, not unlike syntax-ppss, while eglot do things
> its own way, replacing parts of the major mode’s functionality with
> its own.
>
> So it’s not really “two back-ends”, tree-sitter and eglot are
> different in fundamental ways.

I've just finished changing ada-mode 8.0 to be compatible with eglot (not
released yet, but soon), and it now very much treats eglot as one of two
possible backends (with the existing wisi parser and gpr_query the
other, and tree-sitter being a possible third in the future).

Almost every place where eglot does something by default can be
disabled, by setting eglot-stay-out-of appropriately.

So major-modes can treat eglot as just an interface to a language
server.

ada-mode 8.0 provides three variables to control this:

(defcustom ada-face-backend :options '(none eglot wisi)

(defcustom ada-indent-backend :options '(none eglot wisi)

(defcustom ada-xref-backend :options '(gpr_query gnat eglot)

If you have the current ada_language_server installed, but not the Ada
wisi parser, then ada-face-backend defaults to none, since that server
doesn't support it. Similarly for the other backends.

I should have initial feedback from beta testers in a month or so.

-- 
-- Stephe

Re: Renaming eglot -- or at least add an alias?

[Stephen Leake]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Because all of the interaction between server and client in lsp is json
>   > > there's a huge overhead with parsing and shipping things into the emacs
>   > > user interface.  So IMO what tree-sitter is good at should be left to
>   > > tree-sitter.

Premature optimization.

In practice, eglot is fast enough. That's why LSP servers are so
popular.

I suppose we could invoke a climate change argument; tree-sitter might
use measurably less electricity for the same task on the same CPU. That
would be interesting to find out. I suspect running a display totally
swamps that.

> Supposing this conclusion is valid (which seems plausible to me),
> what does that imply about enabliing Eglot and Tree-sitter?

Nothing.

> Should we have a command to enable both together (using Tree-sitter for
> the jobs it can do, and Eglot for the others) 

That should certainly be possible; that's what ada-mode 8.0 does for
eglot and the wisi parser (yet another alternative to tree-sitter).

Whether it's one command, or several custom options, is up for
discussion. ada-mode has three custom options, for face, indent, and xref.

> Should we have three levels of enablement?  (Neither one, Tree-sitter
> only, or both)?

It should be on a feature-by-feature basis; as you mention, for a given
language, tree-sitter and eglot may support different features.

-- 
-- Stephe

Re: Renaming eglot -- or at least add an alias?

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Yuan Fu <casouri@gmail.com> writes:
>
>>> On Oct 11, 2022, at 11:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>> IMO in some sense, eglot and major mode sits at the same level, and
>> tree-sitter a level lower. Consider this: take imenu as an example.
>> Major mode sets imenu-create-index-function for imenu to function. A
>> major mode now has two options available, one function uses
>> tree-sitter and one don’t. If the user enables eglot, eglot sets
>> menu-create-index-function to eglot-imenu, overriding major mode’s
>> function. From this perspective, tree-sitter is just a mechanism a
>> major mode could use, not unlike syntax-ppss, while eglot do things
>> its own way, replacing parts of the major mode’s functionality with
>> its own.
>>
>> So it’s not really “two back-ends”, tree-sitter and eglot are
>> different in fundamental ways.
>
> I've just finished changing ada-mode 8.0 to be compatible with eglot (not
> released yet, but soon), and it now very much treats eglot as one of two
> possible backends (with the existing wisi parser and gpr_query the
> other, and tree-sitter being a possible third in the future).
>
> Almost every place where eglot does something by default can be
> disabled, by setting eglot-stay-out-of appropriately.
>
> So major-modes can treat eglot as just an interface to a language
> server.
>
> ada-mode 8.0 provides three variables to control this:
>
> (defcustom ada-face-backend :options '(none eglot wisi)
>
> (defcustom ada-indent-backend :options '(none eglot wisi)
>
> (defcustom ada-xref-backend :options '(gpr_query gnat eglot)
>
> If you have the current ada_language_server installed, but not the Ada
> wisi parser, then ada-face-backend defaults to none, since that server
> doesn't support it. Similarly for the other backends.
>
> I should have initial feedback from beta testers in a month or so.

Thinking about this some more, I realized there are other features that
the user might want to control:

signature help - show the function signature when point is in a function
name. ada-mode does not currently do this, and users might want to turn
it off.

completion - gpr_query does this for ada-mode, but eglot is always
better, so it is used if available. 

diagnostics - error messages from the parser for syntax errors in the
file; eglot displays them via flymake. ada-mode also does this (not
using flymake) - I have not considered how to handle them fighting each
other, but I will probably have to disable one or the other.

-- 
-- Stephe

Re: Renaming eglot -- or at least add an alias?

[Theodor Thornhill]

On 13 October 2022 02:47:51 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > > Because all of the interaction between server and client in lsp is json
>>   > > there's a huge overhead with parsing and shipping things into the emacs
>>   > > user interface.  So IMO what tree-sitter is good at should be left to
>>   > > tree-sitter.
>
>Premature optimization.
>

Why do you say that? 

I've been using lsp for a long time, and typing lag can get unbearable with servers that sends too much stuff. When 20k completions containing _full_ documentation for every result that json gets humongous. Adding syntax highlights on top of that isn't advisable, considering emacs nonmultithreaded nature. 


>In practice, eglot is fast enough. That's why LSP servers are so
>popular.
>

That does not mean piling on features will help. Eglot is fast exactly because we've been mindful on what has been added. 

Re: Renaming eglot -- or at least add an alias?

[Philip Kaludercic]

Theodor Thornhill <theo@thornhill.no> writes:

> On 13 October 2022 02:47:51 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>>Richard Stallman <rms@gnu.org> writes:
>>
>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>>   > > Because all of the interaction between server and client in lsp is json
>>>   > > there's a huge overhead with parsing and shipping things into the emacs
>>>   > > user interface.  So IMO what tree-sitter is good at should be left to
>>>   > > tree-sitter.
>>
>>Premature optimization.
>>
>
> Why do you say that? 
>
> I've been using lsp for a long time, and typing lag can get unbearable
> with servers that sends too much stuff. When 20k completions
> containing _full_ documentation for every result that json gets
> humongous. Adding syntax highlights on top of that isn't advisable,
> considering emacs nonmultithreaded nature.

Is there any way to negotiate what information one is interested in at a
time?  E.g. I usually am not interested in documentation while
completion a symbol name.  If curious I'll request it manually and
having all of Emacs slowed down because of something like that sounds bad.

>
>>In practice, eglot is fast enough. That's why LSP servers are so
>>popular.
>>
>
> That does not mean piling on features will help. Eglot is fast exactly because we've been mindful on what has been added. 

Re: Renaming eglot -- or at least add an alias?

[Stephen Leake]

Theodor Thornhill <theo@thornhill.no> writes:

> On 13 October 2022 02:47:51 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>>Richard Stallman <rms@gnu.org> writes:
>>
>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>>   > > Because all of the interaction between server and client in lsp is json
>>>   > > there's a huge overhead with parsing and shipping things into the emacs
>>>   > > user interface.  So IMO what tree-sitter is good at should be left to
>>>   > > tree-sitter.
>>
>>Premature optimization.
>>
>
> Why do you say that? 

Because it gives a supposed cause without evidence of an actual problem.

> I've been using lsp for a long time, and typing lag can get unbearable
> with servers that sends too much stuff. When 20k completions
> containing _full_ documentation for every result that json gets
> humongous. 

Ok, that's actual data. On the other hand, did you measure different
parts of the process, so you are sure that the json is the bottleneck,
and not something else? It's not clear just from this description that a
tree-sitter implementation would be faster.

In addition, LSP supports sending the documentation later, after the user
has actually looked at a completion item, using a completionItem/resolve
request. So this sounds like a specific client or server implementation
problem more than an inherent LSP problem.

> Adding syntax highlights on top of that isn't advisable, considering
> emacs nonmultithreaded nature.

Syntax highlighting, mediated by font-lock, should only ever send small
amounts of data; one screen full at a time. That is if the server
supports the textDocument/semanticTokens/range request, and not just the
textDocument/semanticTokens/full request.

-- 
-- Stephe

Re: Renaming eglot -- or at least add an alias?

[Dmitry Gutov]

On 13.10.2022 13:20, Stephen Leake wrote:
>> I've been using lsp for a long time, and typing lag can get unbearable
>> with servers that sends too much stuff. When 20k completions
>> containing_full_  documentation for every result that json gets
>> humongous.
> Ok, that's actual data. On the other hand, did you measure different
> parts of the process, so you are sure that the json is the bottleneck,
> and not something else? It's not clear just from this description that a
> tree-sitter implementation would be faster.

I'm pretty sure that we should support syntax highlighting when the 
corresponding language server is not installed. Or fails to launch for 
some reason.

We can control which grammars we bundle with Emacs, but we're not going 
to bundle language servers.

Re: Renaming eglot -- or at least add an alias?

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Stephen Leake <stephen_leake@stephe-leake.org>,  Richard Stallman
>  <rms@gnu.org>,  Dmitry Gutov <dgutov@yandex.ru>,  eliz@gnu.org,
>   emacs-devel@gnu.org
> Date: Thu, 13 Oct 2022 08:59:33 +0000
> 
> > I've been using lsp for a long time, and typing lag can get unbearable
> > with servers that sends too much stuff. When 20k completions
> > containing _full_ documentation for every result that json gets
> > humongous. Adding syntax highlights on top of that isn't advisable,
> > considering emacs nonmultithreaded nature.
> 
> Is there any way to negotiate what information one is interested in at a
> time?  E.g. I usually am not interested in documentation while
> completion a symbol name.  If curious I'll request it manually and
> having all of Emacs slowed down because of something like that sounds bad.

Eglot allows that, yes.

Re: Renaming eglot -- or at least add an alias?

[Theodor Thornhill]

On 13 October 2022 12:20:13 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> On 13 October 2022 02:47:51 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>>>Richard Stallman <rms@gnu.org> writes:
>>>
>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>
>>>>   > > Because all of the interaction between server and client in lsp is json
>>>>   > > there's a huge overhead with parsing and shipping things into the emacs
>>>>   > > user interface.  So IMO what tree-sitter is good at should be left to
>>>>   > > tree-sitter.
>>>
>>>Premature optimization.
>>>
>>
>> Why do you say that? 
>
>Because it gives a supposed cause without evidence of an actual problem.
>
>> I've been using lsp for a long time, and typing lag can get unbearable
>> with servers that sends too much stuff. When 20k completions
>> containing _full_ documentation for every result that json gets
>> humongous. 
>
>Ok, that's actual data. On the other hand, did you measure different
>parts of the process, so you are sure that the json is the bottleneck,
>and not something else? It's not clear just from this description that a
>tree-sitter implementation would be faster.
>

Yes I did,at the time. Though I cannot find the issue at hand, but it was related to Elm-language-server if memory serves me right. 


>In addition, LSP supports sending the documentation later, after the user
>has actually looked at a completion item, using a completionItem/resolve
>request. So this sounds like a specific client or server implementation
>problem more than an inherent LSP problem.
>

Sure, but that's life. Nonconforming servers are everywhere, and these issues are bound to happen. If something as important and simple as colors and indentation would be unusable because of a bug in a transitive dependency we have a much bigger problem, imo. Tree-sitter will not cause us these headaches as easily. 


>> Adding syntax highlights on top of that isn't advisable, considering
>> emacs nonmultithreaded nature.
>
>Syntax highlighting, mediated by font-lock, should only ever send small
>amounts of data; one screen full at a time. That is if the server
>supports the textDocument/semanticTokens/range request, and not just the
>textDocument/semanticTokens/full request.
>

Yes, and yet again we are at the mercy of the specific server. Using tree-sitter we can much more reliably resolve the situation on our own. Of course, in both cases the tech is new and will mature, but to me tree-sitter seems like the obvious winner. 

Re: Renaming eglot -- or at least add an alias?

[Tim Cross]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>> On 13 October 2022 02:47:51 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>>>Richard Stallman <rms@gnu.org> writes:
>>>
>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>
>>>>   > > Because all of the interaction between server and client in lsp is json
>>>>   > > there's a huge overhead with parsing and shipping things into the emacs
>>>>   > > user interface.  So IMO what tree-sitter is good at should be left to
>>>>   > > tree-sitter.
>>>
>>>Premature optimization.
>>>
>>
>> Why do you say that? 
>
> Because it gives a supposed cause without evidence of an actual problem.
>
>> I've been using lsp for a long time, and typing lag can get unbearable
>> with servers that sends too much stuff. When 20k completions
>> containing _full_ documentation for every result that json gets
>> humongous. 
>
> Ok, that's actual data. On the other hand, did you measure different
> parts of the process, so you are sure that the json is the bottleneck,
> and not something else? It's not clear just from this description that a
> tree-sitter implementation would be faster.
>
> In addition, LSP supports sending the documentation later, after the user
> has actually looked at a completion item, using a completionItem/resolve
> request. So this sounds like a specific client or server implementation
> problem more than an inherent LSP problem.
>
>> Adding syntax highlights on top of that isn't advisable, considering
>> emacs nonmultithreaded nature.
>
> Syntax highlighting, mediated by font-lock, should only ever send small
> amounts of data; one screen full at a time. That is if the server
> supports the textDocument/semanticTokens/range request, and not just the
> textDocument/semanticTokens/full request.

I think I agree. I've often seen the criticism that LSP based solutions
are no good because of poor performance arising from the use of JSON as
the communication format. 

As someone who has done his share of web development and is very
familiar with the pros and cons of JSON and alternative formats which (I
think) are far superior, I can udnerstand where this concern can come
from. 

However, having used LSP based setups (lsp-mode and eglot) fro quite
some time on some large projects with many files and some large source
files and in a couple of different languages, I have to say I've not
noticed performance issues at all. I have run into other issues, most of
which have been resolved. I did find with eglot that it was important
to ensure the packages it users were up-to-date (i.e. xref, flymake,
eldoc etc). 

What I have observed is that unsurprisingly, results are very dependent
on the language server you are using. For example, I switched the LSP
server I was using for Javascript and immediately experienced a much
better result. Actually, this was one of the nice aspects of using an
LSP based work flow. Changeing LSP server was a simple as downloading
the server executable and changing one variable in my client config. 

I have not used LSP for font locking, but have used it for indentation
and it worked fine with no observable performance issues like typing lag
etc.

The other aspect of using LSP which I've found interesting, but really
only as something to hack/playh with, has been setting up your own LSP
server for a specific language. I experimented using Clojure and Raku
and was surprised how quickly/easily you could add functionality to my
editor, primarily as I was able to leverage of built-in functionality
of the languages I was working with. I think this ability to leverage of
the target languages built-in features combined with a smaller code base
and reduced maintenance within the editor core is what gives the LSP
architecture an edge over solutions like tree-sitter. The fact it can be
used with multiple different editors is the sugar on top.

However, if the effort has been done to add tree-sitter support for a
language and it is maintained, then it will likely to perform better in
many cases and could well be the preferred choice for many users.

Re: Renaming eglot -- or at least add an alias?

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]

Theodor Thornhill <theo@thornhill.no> writes:

> On 13 October 2022 12:20:13 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>>Theodor Thornhill <theo@thornhill.no> writes:
>>
>>> On 13 October 2022 02:47:51 CEST, Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>>>>Richard Stallman <rms@gnu.org> writes:
>>>>
>>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>>
>>>>>   > > Because all of the interaction between server and client in lsp is json
>>>>>   > > there's a huge overhead with parsing and shipping things into the emacs
>>>>>   > > user interface.  So IMO what tree-sitter is good at should be left to
>>>>>   > > tree-sitter.
>>>>
>>>>Premature optimization.
>>>>
>>>
>>> Why do you say that? 
>>
>>Because it gives a supposed cause without evidence of an actual problem.
>>
>>> I've been using lsp for a long time, and typing lag can get unbearable
>>> with servers that sends too much stuff. When 20k completions
>>> containing _full_ documentation for every result that json gets
>>> humongous. 
>>
>>Ok, that's actual data. On the other hand, did you measure different
>>parts of the process, so you are sure that the json is the bottleneck,
>>and not something else? It's not clear just from this description that a
>>tree-sitter implementation would be faster.
>>
>
> Yes I did,at the time. Though I cannot find the issue at hand, but it was related to Elm-language-server if memory serves me right. 
>
>
>>In addition, LSP supports sending the documentation later, after the user
>>has actually looked at a completion item, using a completionItem/resolve
>>request. So this sounds like a specific client or server implementation
>>problem more than an inherent LSP problem.
>>
>
> Sure, but that's life. Nonconforming servers are everywhere, and these
> issues are bound to happen. If something as important and simple as
> colors and indentation would be unusable because of a bug in a
> transitive dependency we have a much bigger problem, imo. Tree-sitter
> will not cause us these headaches as easily.
>
>
>>> Adding syntax highlights on top of that isn't advisable, considering
>>> emacs nonmultithreaded nature.
>>
>>Syntax highlighting, mediated by font-lock, should only ever send small
>>amounts of data; one screen full at a time. That is if the server
>>supports the textDocument/semanticTokens/range request, and not just the
>>textDocument/semanticTokens/full request.
>>
>
> Yes, and yet again we are at the mercy of the specific server. Using
> tree-sitter we can much more reliably resolve the situation on our
> own. Of course, in both cases the tech is new and will mature, but to
> me tree-sitter seems like the obvious winner.
>

LSP is too flexible to block the editor.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

I have to agree, it seems there are some here with partial or minimal
understanding of the job that Eglot does and has done for a significant
user base for some years now.  We should allow these people some time to
become acquainted with Eglot, ideally via its actual use, before moving
on to architectural discussions.

At this point, I'd like to point out again that a manual for Eglot **exists
already**.  Written by Eglot's author (i.e. me), it is being rewritten
freely by Eli in Texinfo format, and this will become the "official
manual" to be published as frequently as possible.

The Texinfo manual, which I have already reviewed, is written in a
structured and sober style typical of quality Emacs manuals.  However,
the existing MANUAL.md which I have already linked to (and do it again
at the end), contains more contextual and historical information which I
shall migrate to commentary in the eglot.el source file.

For example, this section, which is not fully reproduced in the future
TexInfo manual, could shed some light on some of the issues being
discussed:

"Eglot uses LSP to activate modern IDE features in Emacs. These features
are
 provided via a number of auxiliary packages:

 * at-point documentation, via the ElDoc package;
 * on-the-fly diagnostic annotations with server-suggested fixes, via the
Flymake package;
 * definition chasing/cross-referencing, via the Xref package;
 * in-file symbolic navigation, via the Imenu package;
 * completion (via Emacs built-in front-ends, Company, or other front-ends)

[...]

Experienced users will notice that these auxiliary facilities aren't
exactly new in Emacs.  For lack of adequate configuration, they are
sometimes inactive by default.  Traditionally, each major-mode tries to
configure a subset of them, at least partially.  Users commonly fill in
the gaps in their personal configurations.  In general, it is
time-consuming to achieve some kind of unifying consistency across
different packages in the same major mode or across different major
modes in the same package.

This is the main problem solved by LSP and Eglot: Eglot links up Emacs
packages to LSP features (also known as LSP capabilities) by temporarily
configuring the auxiliary packages while it is active in some buffer
(see Eglot-managed buffers).

Not all servers support the full set of LSP capability, but most of them
support enough to enable the basic set of features enumerated
above. Conversely, some servers offer capability for which an Emacs
equivalent package doesn't yet exist, and so Eglot can't link up the
two.

There are some cases where Eglot itself offers a user-facing facility
for a given capability. Examples are the refactoring commands
eglot-rename and eglot-code-action-organize-imports (see Commands)."

The full MANUAL.md:
https://github.com/joaotavora/eglot/blob/master/MANUAL.md

[-- Attachment #2: Type: text/html, Size: 3213 bytes --]

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

I'm also inclined, for now, to having Tree-sitter be the fast and
configurable
way provider of information for font-locking, indentation, and syntactic
classification.
But I confirm that LSP solves at least the first 2 of these 3 things.  As
to its
practicality, I'm reasonably sure that many on-line editors such as
godbolt.org,
hackerrank, etc. use LSP extensively.  The font-locking is very acceptable,
even in larger files, and I'd be surprised that this font-locking is
supported
by anything other than LSP.

João

[-- Attachment #2: Type: text/html, Size: 794 bytes --]

Re: Renaming eglot -- or at least add an alias?

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Wed, Oct 12, 2022 at 11:51 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 12.10.2022 09:37, Yuan Fu wrote:
> > If the user enables eglot, eglot sets menu-create-index-function to
eglot-imenu, overriding major mode’s function.
> I suppose it does override that, but are you sure it's always a good idea?

I'm not sure that's a productive question, as nothing is ever "always" a
good
idea 100%.  But in those cases where one can decide that it's not, Eglot
allows
the user or the major mode to override it.  Same as most any other package
configuration linked up by Eglot. See Eglot's manual for details.

João

[-- Attachment #2: Type: text/html, Size: 816 bytes --]