New Eglot release

New Eglot release

[João Távora]

Hello,

After some significant work done to Eglot in emacs-29 the last few
weeks, I'd like to make the 1.12 release so people can use it from GNU
ELPA in older Emacs versions.

However, one question remains from the merge: where to put
Eglot-specific NEWS describing the latest user-visible changes??

I'm not opposed to putting them in Emacs's own NEWS file, except that
for this Emacs 29 version it'd be a bit akward, since Eglot just made it
in, so the existing NEWS is about Eglot's appearance, not about what
changed recently.

I think, someone suggested /etc/EGLOT-NEWS at the time.  That could
work, I guess.  But would anyone read it?

Also, it'd be nice that it'd go somewhere where the description of the
package in https://elpa.gnu.org/ can pick it up.

João

Re: New Eglot release

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 04 Mar 2023 20:02:07 +0000
> 
> After some significant work done to Eglot in emacs-29 the last few
> weeks, I'd like to make the 1.12 release so people can use it from GNU
> ELPA in older Emacs versions.
> 
> However, one question remains from the merge: where to put
> Eglot-specific NEWS describing the latest user-visible changes??
> 
> I'm not opposed to putting them in Emacs's own NEWS file, except that
> for this Emacs 29 version it'd be a bit akward, since Eglot just made it
> in, so the existing NEWS is about Eglot's appearance, not about what
> changed recently.

Sorry, I don't follow what you say here, and thus don't understand the
difficulty.  Perhaps if you show the text you'd like to have there,
the misunderstanding will be resolved.

> I think, someone suggested /etc/EGLOT-NEWS at the time.  That could
> work, I guess.  But would anyone read it?

Does anyone read NEWS?

Re: New Eglot release

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Does anyone read NEWS?

Yes. Mickey Petersen.

https://www.masteringemacs.org/article/whats-new-in-emacs-28-1

https://www.masteringemacs.org/article/whats-new-in-emacs-27-1

etc pp

Best regards, Michael.

Re: New Eglot release

[João Távora]

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

On Sun, Mar 5, 2023, 05:50 Eli Zaretskii <eliz@gnu.org> wrote:

>
> Sorry, I don't follow what you say here, and thus don't understand the
> difficulty.  Perhaps if you show the text you'd like to have there,
> the misunderstanding will be resolved.
>

A mention to Eglot's new support for LSP inlay hints, for example.

> I think, someone suggested /etc/EGLOT-NEWS at the time.  That could
> > work, I guess.  But would anyone read it?
>
> Does anyone read NEWS?
>

I think more people read NEWS than FOO-NEWS. As Michael pointed out, NEWS
is even given special visibility and analyzed point-by-point by Mickey
Petersen in his popular blog.

João

>

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

Re: New Eglot release

[Dmitry Gutov]

On 05/03/2023 17:30, João Távora wrote:
> I think more people read NEWS than FOO-NEWS. As Michael pointed out, 
> NEWS is even given special visibility and analyzed point-by-point by 
> Mickey Petersen in his popular blog.

The appearance of a new FOO-NEWS might give it some extra attention.

Coupled with some existing enthusiasm for Eglot's addition.

Re: New Eglot release

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 5 Mar 2023 15:30:19 +0000
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> On Sun, Mar 5, 2023, 05:50 Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  Sorry, I don't follow what you say here, and thus don't understand the
>  difficulty.  Perhaps if you show the text you'd like to have there,
>  the misunderstanding will be resolved.
> 
> A mention to Eglot's new support for LSP inlay hints, for example.

That should be in NEWS, I think.

In general, if the new Eglot release doesn't have dozens of new
features, I'd suggest to describe them all in NEWS.

Re: New Eglot release

[Philip Kaludercic]

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

> Hello,
>
> After some significant work done to Eglot in emacs-29 the last few
> weeks, I'd like to make the 1.12 release so people can use it from GNU
> ELPA in older Emacs versions.
>
> However, one question remains from the merge: where to put
> Eglot-specific NEWS describing the latest user-visible changes??
>
> I'm not opposed to putting them in Emacs's own NEWS file, except that
> for this Emacs 29 version it'd be a bit akward, since Eglot just made it
> in, so the existing NEWS is about Eglot's appearance, not about what
> changed recently.
>
> I think, someone suggested /etc/EGLOT-NEWS at the time.  That could
> work, I guess.  But would anyone read it?

Would using a "News" section in eglot.el (along the same lines of the
"Commentary" section) make sense here?  elpa-admin.el should pick this
up when generating news for elpa.gnu.org.

> Also, it'd be nice that it'd go somewhere where the description of the
> package in https://elpa.gnu.org/ can pick it up.
>
> João

-- 
Philip Kaludercic

Re: New Eglot release

[João Távora]

Philip Kaludercic <philipk@posteo.net> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> Hello,
>>
>> After some significant work done to Eglot in emacs-29 the last few
>> weeks, I'd like to make the 1.12 release so people can use it from GNU
>> ELPA in older Emacs versions.
>>
>> However, one question remains from the merge: where to put
>> Eglot-specific NEWS describing the latest user-visible changes??
>>
>> I'm not opposed to putting them in Emacs's own NEWS file, except that
>> for this Emacs 29 version it'd be a bit akward, since Eglot just made it
>> in, so the existing NEWS is about Eglot's appearance, not about what
>> changed recently.
>>
>> I think, someone suggested /etc/EGLOT-NEWS at the time.  That could
>> work, I guess.  But would anyone read it?
>
> Would using a "News" section in eglot.el (along the same lines of the
> "Commentary" section) make sense here?  elpa-admin.el should pick this
> up when generating news for elpa.gnu.org.

Thanks for the suggestion. It would make sense, but has the drawback
that it makes a file grow a bit too much for my personal taste.  Do you
know if elpa-admin.el can pick up etc/EGLOT-NEWS?  If not, I think I'll
go with Emacs's etc/NEWS, which is the most visible anyway.  Maybe one
day there will be way for elpa-admin.el to pick up the Eglot-relevant
section there.

João

Re: New Eglot release

[Philip Kaludercic]

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> João Távora <joaotavora@gmail.com> writes:
>>
>>> Hello,
>>>
>>> After some significant work done to Eglot in emacs-29 the last few
>>> weeks, I'd like to make the 1.12 release so people can use it from GNU
>>> ELPA in older Emacs versions.
>>>
>>> However, one question remains from the merge: where to put
>>> Eglot-specific NEWS describing the latest user-visible changes??
>>>
>>> I'm not opposed to putting them in Emacs's own NEWS file, except that
>>> for this Emacs 29 version it'd be a bit akward, since Eglot just made it
>>> in, so the existing NEWS is about Eglot's appearance, not about what
>>> changed recently.
>>>
>>> I think, someone suggested /etc/EGLOT-NEWS at the time.  That could
>>> work, I guess.  But would anyone read it?
>>
>> Would using a "News" section in eglot.el (along the same lines of the
>> "Commentary" section) make sense here?  elpa-admin.el should pick this
>> up when generating news for elpa.gnu.org.
>
> Thanks for the suggestion. It would make sense, but has the drawback
> that it makes a file grow a bit too much for my personal taste.  

  Depending on what your standards are, I think that if the news section
  only contained information about the latest revision (or the development
  revision), that the file size would be fine.

>                                                                  Do you
> know if elpa-admin.el can pick up etc/EGLOT-NEWS?  If not, I think I'll
> go with Emacs's etc/NEWS, which is the most visible anyway.  Maybe one
> day there will be way for elpa-admin.el to pick up the Eglot-relevant
> section there.

  No, to my knowledge none of the core packages don't use etc/NEWS or any
  other NEWS file.  Not that this shouldn't be possible -- I don't imagine
  it should be too difficult to hack up something like that if there is
  a need for something like that, especially since Emacs 29 has brought
  along at least two larger packages (use-package and Eglot) into the
  core, that might have their own separate audiences.

> João

Re: New Eglot release

[Philip Kaludercic]

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> João Távora <joaotavora@gmail.com> writes:
>>
>>> Hello,
>>>
>>> After some significant work done to Eglot in emacs-29 the last few
>>> weeks, I'd like to make the 1.12 release so people can use it from GNU
>>> ELPA in older Emacs versions.
>>>
>>> However, one question remains from the merge: where to put
>>> Eglot-specific NEWS describing the latest user-visible changes??
>>>
>>> I'm not opposed to putting them in Emacs's own NEWS file, except that
>>> for this Emacs 29 version it'd be a bit akward, since Eglot just made it
>>> in, so the existing NEWS is about Eglot's appearance, not about what
>>> changed recently.
>>>
>>> I think, someone suggested /etc/EGLOT-NEWS at the time.  That could
>>> work, I guess.  But would anyone read it?
>>
>> Would using a "News" section in eglot.el (along the same lines of the
>> "Commentary" section) make sense here?  elpa-admin.el should pick this
>> up when generating news for elpa.gnu.org.
>
> Thanks for the suggestion. It would make sense, but has the drawback
> that it makes a file grow a bit too much for my personal taste.  

  Depending on what your standards are, I think that if the news section
  only contained information about the latest revision (or the development
  revision), that the file size would be fine.

>                                                                  Do you
> know if elpa-admin.el can pick up etc/EGLOT-NEWS?  If not, I think I'll
> go with Emacs's etc/NEWS, which is the most visible anyway.  Maybe one
> day there will be way for elpa-admin.el to pick up the Eglot-relevant
> section there.

  No, to my knowledge none of the core packages don't use etc/NEWS or any
  other NEWS file.  Not that this shouldn't be possible -- I don't imagine
  it should be too difficult to hack up something like that if there is
  a need for something like that, especially since Emacs 29 has brought
  along at least two larger packages (use-package and Eglot) into the
  core, that might have their own separate audiences.

> João

Re: New Eglot release

[F. Jason Park]

Philip Kaludercic <philipk@posteo.net> writes:

>>                                                                  Do you
>> know if elpa-admin.el can pick up etc/EGLOT-NEWS?  If not, I think I'll
>> go with Emacs's etc/NEWS, which is the most visible anyway.  Maybe one
>> day there will be way for elpa-admin.el to pick up the Eglot-relevant
>> section there.
>
>   No, to my knowledge none of the core packages don't use etc/NEWS or any
>   other NEWS file.  Not that this shouldn't be possible -- I don't imagine
>   it should be too difficult to hack up something like that if there is
>   a need for something like that, especially since Emacs 29 has brought
>   along at least two larger packages (use-package and Eglot) into the
>   core, that might have their own separate audiences.

FWIW, ERC is one :core package that keeps its own etc/FOO-NEWS. The
latest headlines are excerpted in a <pre> block toward the end of the
project's ELPA page (a bit over-truncated in our case, not that it
bothers me).

Re: New Eglot release

[João Távora]

F. Jason Park <jp@neverwas.me> writes:

>>   a need for something like that, especially since Emacs 29 has brought
>>   along at least two larger packages (use-package and Eglot) into the
>>   core, that might have their own separate audiences.
>
> FWIW, ERC is one :core package that keeps its own etc/FOO-NEWS. The
> latest headlines are excerpted in a <pre> block toward the end of the
> project's ELPA page (a bit over-truncated in our case, not that it
> bothers me).

So I've changed my mind.  I was leaning to using etc/NEWS, but now I
think it's better for Eglot to have its own file.  Thanks to both of
you.

I modelled the new etc/EGLOT-NEWS file exactly after etc/ERC-NEWS, with
some Eglot-specific niceties like bug-reference-mode links to both the
Github and the Emacs bug tracker.

This allows me to import the long NEWS.md file that Eglot already had
dating back to almost 5 years ago, and continue from there.  And
hopefully GNU ELPA scripts will also pick the entries and put them in
the project page.

Eli, is this patch good to push?  It adds a new etc/EGLOT-NEWS and makes
a tiny mention to it in etc/NEWS.

João

diff --git a/etc/EGLOT-NEWS b/etc/EGLOT-NEWS
new file mode 100644
index 00000000000..38d0fcaa9ed
--- /dev/null
+++ b/etc/EGLOT-NEWS
@@ -0,0 +1,517 @@
+Eglot NEWS
+
+Copyright (C) 2018-2023 Free Software Foundation, Inc.
+See the end of the file for license conditions.
+
+Please send Eglot bug reports to 'bug-gnu-emacs@gnu.org', and Cc (or
+X-Debbugs-CC) the maintainer 'joaotavora@gmail.com' as well.  Please
+read the chapter titled "Troubleshooting" in the Eglot manual,
+available https://joaotavora.github.io/eglot/#Troubleshooting-Eglot
+
+This file is about changes in Eglot, the Emacs client for the Language
+Server Protocl distributed with GNU Emacs since Emacs version 29.1 and
+with GNU ELPA since 2018.
+
+\f
+* Changes in Eglot 1.12 (upcoming)
+
+** LSP inlay hints are now supported.
+Inlay hints are small text annotations not unlike diagnostics, but
+designed to help readability instead of indicating problems.  For
+example, a C++ LSP server can serve hints about positional parameter
+names in function calls and a variable's automatically deduced type.
+Emacs can display these hints using overlays, helping the user
+remember those types and parameter names.
+
+** Tramp instability issues are worked around effectively.
+Emacs bug#61350 has more details.  For the current Tramp version,
+Eglot's workaround is effective.  Future Tramp versions will have this
+problem solved at the origin.
+
+(github#859, github#1020, github#883) 
+
+** LSP's 'positionEncoding' capability is now supported.
+The position-encoding scheme (UTF-8, UTF-16 or UTF-32) can now
+be negotiated with server.
+
+** More of the user's Eldoc configuration is respected.
+This change addresses the problems reported in many Elglot reports
+dating back to early 2021 at least.
+
+(github#646, github#894, github#920, github#1031, github#1171).
+
+This is unfinished work, as 'eldoc-documentation-strategy' is still
+set by Eglot during its tenure over a buffer.  The default value for
+it cannot work reasonably with Eglot's additions to
+'eldoc-documentation-functions'.
+
+** Completion labels correctly displayed in servers like clangd.
+
+(github#1141)
+
+** Assorted bugfixes.
+
+(bug#61312, bug#61478, bug#61532, bug#61726, bug#61866, bug#61748)
+
+\f
+* Changes in Eglot 1.11 (27/1/2023)
+
+** New server vscode-json-languageserver added to 'eglot-server-programs'.
+
+(bug#60198)
+
+** Assorted bugfixes.
+
+(bug#60379, bug#60557, (bug#61048)
+
+\f
+* Changes in Eglot 1.10 (16/12/2022)
+
+** Emacs progress reporters are used for LSP progress notifications.
+(bug#59149)
+
+** LSP reported URIs other than file:// are passed on to Emacs.
+This change allows other URI handlers, such as a 'jar:' handling
+package, to cooperate with Eglot and find files inside compressed file
+systems (bug#58790).
+
+** Eglot now shows in the menu bar.
+
+** Tree-sitter modes added to 'eglot-server-programs'.
+These modes are usually handled by the same server that handles the
+"classical mode".
+
+** New servers chsharp-ls and texlab added to 'eglot-server-programs'.
+
+** Assorted bugfixes.
+(bug#59824, bug#59338)
+
+\f
+* Changes in Eglot 1.9 (8/10/2022)
+
+This is the last release before integration into Emacs code..
+
+** New 'M-x eglot-list-connections' command.
+Probably not very useful for now.  More keybindings and clickable
+shortcuts to connection-specific commands to be added later.
+
+** Manual temporarily living in separate MANUAL.md file.
+The manual has been rewritten mostly from scratch.  It is structured
+hierarchically and more complete.  After the merge into Emacs, this 
+upcoming TexInfo manual uses this manual as a starting point.
+
+** Support for "single server, multiple modes".
+Previously, if an entry such as '((c++-mode c-mode) . ("clangd)")' was
+found in 'eglot-server-programs', it meant that '.cpp' files '.c'
+files would lead to two 'clangd' instances for managing them, even if
+these files were in the same project.  Now only one is created.  It is
+assumed that most, if not all, servers configured in
+'eglot-server-programs' handle this correctly.
+
+(github#681)
+
+** 'eglot-imenu' no longer uses problematic "special elements".
+Though Eglot's 'eglot-imenu' returned a fully compliant 'imenu'
+structure, that object was not understood by many other frontends
+other than 'M-x imenu' itself.  Since the special functionality it
+enabled wasn't being used anyway, decided to remove it to fix these
+longstanding problems.
+
+(github#758, github#536, github#535)
+
+** 'eglot-workspace-configuration' has been overhauled.
+This variable and its uses are now more thoroughly documented.  It can
+be a set to a function for dynamic calculation of the configuration.
+The preferred format is a plist, though the earlier alist format is
+still supported.
+
+(github#967, github#590, github#790)
+
+** C-u M-. lists and completes arbitrary workspace symbols.
+A very old request, now made possible by a relatively recent change to
+the 'workspace/symbol' RPC method.
+
+(github#131)
+
+** Rework mode-line menus.
+New menus help discover Eglot's features and show which of them are
+supported by the current server.  Menus can be customized away via
+'eglot-menu-string', making space in mode-line.
+
+(github#792)
+
+** Easier to use LSP initialize.initializationOptions.
+In 'eglot-server-programs' a plist may be appended to the usual list
+of strings passed as command line arguments.  The value of its
+':initializationOptions' key constructs the corresponding LSP JSON
+object.  This may be easier than creating a 'defclass' for a specific
+server and specializing 'eglot-initialization-options' to that class.
+
+(github#901, github#845, github#940)
+
+** LSP on-type formatting is now supported.
+
+(github#899)
+
+** Basic LSP "workspace folders" support added.
+Eglot now advertises 'project-root' and 'project-external-roots' as
+workspace-folders.  (Configuring 'project-vc-external-roots-function'
+via Elisp or 'tags-table-list' via Custtomize are two ways to set the
+external roots of a simple git project.)
+
+(github#893)
+
+** Eglot can now show project wide diagnosics via Flymake.
+Some LSP servers report diagnostics for all files in the current
+workspace.  Flymake has (as of version 1.2.1) the option to show
+diagnostics from buffers other than the currently visited one.  The
+command 'M-x flymake-show-project-diagnostics' will now show all
+diagnostics relevant to a workspace.
+
+(github#810)
+
+** Support LSP completion tags.
+An LSP completion tag can be used to tell the editor how
+to render a completion.  Presently, one kind of tag exists, denoting
+its corresponding completion as obsolete.
+
+(github#797)
+
+** Support LSP optional diagnostic tags.
+A diagnostic tag can indicate either "unused or unnecessary code" or
+"deprecated or obsolete code".  Following the rendering suggestions in
+the protocol, we fade out unnecessary code and strike-through
+deprecated code.
+
+(github#794)
+
+** The Rust language server is now rust-analyzer by default.
+Eglot will now prefer starting "rust-analyzer" to "rls" when it is
+available.  The special support code for RLS has been removed.
+
+(github#803)
+
+** New servers have been added to 'eglot-server-programs'.
+- clojure-lsp (github#813)
+- racket-langserver (github#694)
+- futhark lsp (github#922)
+- purescript-language-server (github#905)
+- Perl::LanguageServer (github#952)
+- marksman (github#1013)
+- jedi-language-server ([#994](github#994))
+
+\f
+* Changes in Eglot 1.8 (12/1/2022)
+
+** Alternate servers supported out-of-box for the same major mode.
+In practice, this removes the need for Eglot to "officially" bless one
+server over another.  Thanks to Felicián Németh for the original idea.
+
+Do not confuse this feature with another missing feature which
+consists of supporting multiple servers simultaneously managing a
+major mode within a project.
+
+(github#688)
+
+** TRAMP support has been added.
+Thanks to Brian Cully for the minimalist implementation and thanks to
+Felipe Lema who conducted many early experiments.
+
+(github#637, github#463, github#84)
+
+** 'eglot-ignored-server-capabilities' now correctly spelled.
+This user-visible variable used to be spelled
+'eglot-ignored-server-capabilites', which is still a valid but
+obsolete name.
+
+(github#724)
+
+** Eglot can manage cross-referenced files outside project.
+This is activated by a new customization option
+'eglot-extend-to-xref', which defaults to nil.
+
+Thanks to Michael Livshin for the investigation and elegant solution.
+
+(github#76, github#686, github#695)
+
+** Code action shortcuts can be added by the user.
+'M-x eglot-code-actions' accepts an optional 'action-kind' argument,
+specified interactively with 'C-u'.  Other shortcuts call specific
+actions directly ('eglot-code-action-inline',
+'eglot-code-action-extract', 'eglot-code-action-rewrite',
+'eglot-code-action-organize-imports' and
+'eglot-code-action-quickfix').  One can create own shortcuts for code
+actions with specific a kind by calling 'eglot-code-actions' from
+elisp.
+
+(github#411)
+
+** New command 'eglot-shutdown-server' added.
+
+(github#643)
+
+** New variable 'eglot-withhold-process-id' added.
+If non-nil, Eglot will not send the Emacs process id to the language server.
+This can be useful when using docker to run a language server.
+
+(github#722)
+
+** Several new servers have been added to 'eglot-server-programs'.
+- cmake-language-server (github#787)
+- css-languageserver (github#204, github#769)
+- fortls (github#603)
+- html-languageserver (github#204, github#769)
+- json-languageserver (github#204, github#769)
+- lua-lsp (github#721)
+- mint ls (github#750)
+- pyright (github#742)
+- vim-language-server (github#787)
+- yaml-language-server (github#751)
+- zls (github#646)
+
+\f
+* Changes in Eglot 1.7 (16/12/2020)
+
+** Hierarchical symbols are supported in Imenu.
+Thanks to Ingo Lohmar for the original implementation (github#303).
+
+** Multiple "documentation at point" sources are supported.
+Such sources include as LSP's signature, hover and also the Flymake
+diagnostic messages.  They can all be presented in the echo area
+(space permitting), or via 'C-h .'.  For now, composition of different
+sources can be customized using 'eldoc-documentation-strategy',
+'eldoc-echo-area-use-multiline-p' and 'eldoc-prefer-doc-buffer'.
+
+The variables 'eglot-put-doc-in-help-buffer' and
+'eglot-auto-display-help-buffer' have been removed.
+
+(github#439, github#494, github#481, github#454)
+
+\f
+* Changes in Eglot 1.6 (16/04/2020)
+
+** Column offset calculation is now LSP-conformant.
+It seems the majority of servers now comply with the language server
+specification when it comes to handling non-ASCII texts.  Therefore
+the default values of 'eglot-move-to-column-function' and
+'eglot-current-column-function' have been changed.  The documentations
+of these variables help to restore the old behavior.
+
+(github#361)
+
+** LSP workspace/configuration requests are supported.
+Also a new section "Per-project server configuration" in the README.md
+should answer some FAQ's in this regard.
+
+(github#326)
+
+\f
+* Changes in Eglot 1.5 (20/10/2019)
+
+Thanks a lot to Felicián Németh, Ingo Lohmar, and everyone else who
+helped out!
+
+** Eglot takes over Company configuration.
+Similar to what was already the case with Flymake, Eldoc and Xref, use
+just the backend that can do something useful in Eglot,
+'company-capf'.  See 'eglot-stay-out-of' to opt out of this.
+
+(github#324)
+
+** New option 'eglot-autoshutdown' added.
+This disconnects the server after last managed buffer is killed.
+
+(github#217, github#270)
+
+** Completion support support has been fixed.
+Among other things, consider LSP's "filterText" cookies, which enables
+a kind of poor-man's flex-matching for some backends.
+
+(github#235, github#313, github#311, github#279)
+
+** Supports LSP's "goto declaration/implementation/typeDefinition".
+
+(github#302)
+
+** New option 'eglot-send-changes-idle-time' added.
+
+(github#258)
+
+** Eldoc no longer flickers when moving around.
+
+(github#198)
+
+** Large docs shown in help buffer instead of echo area by default.
+Also add two new customization variables
+'eglot-put-doc-in-help-buffer' and 'eglot-auto-display-help-buffer'.
+
+(github#198)
+
+** Built-in support for Go, Elixir and Ada added.
+
+(github#304, github#264, github#316)
+
+\f
+* Changes in Eglot 1.4 (5/1/2019)
+
+** Parameter highlighting in the first line of signature corrected.
+
+** Documentation strings displayed with 'gfm-view-mode'.
+
+** Hard dependencies on 'flymake-mode' removed.
+
+You can turn it off now in buffers managed by Eglot.
+
+** Connection hooks are run with proper directory local variables.
+This fixes issues with suspiciously empty 'didChangeConfiguration'
+messages that are supposed to communicate parameters from a
+directory-set 'eglot-workspace-configuration'.
+
+(github#196)
+
+** Completion sorting fixed.
+
+(github#190)
+
+** Flymake and Eldoc taken over completely while managing buffers.
+No longer try to add Eglot's facilities to existing facilities in
+these two domains.
+
+\f
+* Changes in Eglot 1.3 (10/12/2018)
+
+** Provide strict checking of incoming LSP messages.
+
+(github#144, github#156)
+
+** Add brief context after 'xref-find-references' when available.
+
+(github#52)
+
+** Support 'completionContext' to help servers like 'ccls'.
+
+** Use Flymake from GNU ELPA
+
+(github#178)
+
+\f
+* Changes in Eglot 1.2 (23/11/2018)
+
+** Support snippet completions.
+Eglot uses 'yasnippet.el' for this, if it is installed.
+
+(github#50)
+
+** 'workspace/didChangeConfiguration' implemented.
+
+(github#29)
+
+** Handle experimental/unknown server methods gracefully.
+
+(github#39)
+
+** Accept functions as entries in 'eglot-server-programs'.
+
+'CONTACT' in the '(MAJOR-MODE . CONTACT)' association in
+'eglot-server-programs' can now be a function of no arguments
+producing any value previously valid for contact.  Functions can be
+interactive on non-interactive.
+
+(github#63)
+
+** Improve completion to be snappier and don't hinder typing.
+
+(github#61)
+
+** Consider ':triggerCharacters' in company completion.
+
+(github#80)
+
+** Add support for 'TextEdit's in completion.
+
+** Prefer ccls over cquery for C/C++
+
+(github#94)
+
+** 'eglot-ignored-server-capabilites' is more user-friendly.
+
+(github#126)
+
+** Implement asynchronous server connection
+A new defcustom 'eglot-sync-connect' controls this feature.
+
+(github#68)
+
+** Add a generic 'eglot-execute-command' API.
+
+Work by Michał K.
+
+** Prompt for server in 'eglot-shutdown'.
+
+(github#73)
+
+** Add support for code action literals.
+
+** Add support for the Eclipse JDT language server.
+
+(github#63)
+
+** Add out-of-the-box support for Haskell, Kotlin, Go, Ocaml, R.
+
+** Add the ability to move to LSP-precise columns.
+
+Some servers like 'clangd' follow the spec very closely here.
+
+(github#124)
+
+** Fix a potential security issue fontifying LSP doc.
+
+(github#154)
+
+** Fix many, many bugs
+
+(github#44, github#48, github#54, github#58, github#64, github#74,
+ github#81, github#82, github#86, github#87, github#83, github#93,
+ github#100, github#115, github#120, github#121, github#126,
+ github#138, github#144, github#158, github#160, github#167)
+
+\f
+* Changes in Eglot 1.1 (9/7/2018) 
+
+** Implement TCP autostart/autoconnect (and support Ruby's Solargraph)
+
+The ':autoport' symbol in the server incovation is replaced
+dynamically by a local port believed to be vacant, so that the ensuing
+TCP connection finds a listening server.
+
+** Eglot now depends on Emacs library 'jsonrpc.el'.
+
+** Assorted bugfixes.
+
+
+\f
+----------------------------------------------------------------------
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+\f
+Local Variables:
+bug-reference-bug-regexp: "\\(\\(github\\|bug\\)#\\([0-9]+\\)\\)"
+bug-reference-url-format: eglot--debbugs-or-github-bug-uri
+mode: outline
+mode: bug-reference-mode
+paragraph-separate: "[	 \f]"
+End:
+
diff --git a/etc/NEWS b/etc/NEWS
index 01ab4b8a1db..2699bc80632 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3214,7 +3214,8 @@ Imenu now lists the members directly nested in R6RS Scheme libraries
 Emacs now comes with the Eglot package, which enhances various Emacs
 features, such as completion, documentation, error detection, etc.,
 based on data provided by language servers using the Language Server
-Protocol (LSP).  See the new Info manual "(eglot) Top" for more.
+Protocol (LSP).  See the new Info manual "(eglot) Top" for more.  Also
+see etc/EGLOT-NEWS.
 
 +++
 ** use-package: Declarative package configuration.

Re: New Eglot release

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: Philip Kaludercic <philipk@posteo.net>,  emacs-devel@gnu.org, eliz@gnu.org
> Date: Fri, 10 Mar 2023 11:38:37 +0000
> 
> Eli, is this patch good to push?  It adds a new etc/EGLOT-NEWS and makes
> a tiny mention to it in etc/NEWS.

EGLOT-NEWS mentions many bugfixes, something that we don't do in
NEWS.  The style is also very different:

> +(github#29)
> +
> +** Handle experimental/unknown server methods gracefully.

This doesn't say enough about the change, so why mention it?  And why
the GitHub reference there?

> +** Hierarchical symbols are supported in Imenu.
> +Thanks to Ingo Lohmar for the original implementation (github#303).

We don't mention individual contributors in NEWS.  They are mentioned
in AUTHORS instead (and if you want, also in doc/emacs/ack.texi).

> +(github#196)
> +
> +** Completion sorting fixed.

This (and other similar entries) are not very useful, IMNSHO.

Moreover, I don't think I see why mentioning past versions of Eglot
that were never parts of Emacs would be useful to someone.  It might
be okay to have that on ELPA, but I don't see why we'd want this in
Emacs core.

> +mode: outline
> +mode: bug-reference-mode

Why not emacs-news-mode?

> +Please send Eglot bug reports to 'bug-gnu-emacs@gnu.org', and Cc (or
> +X-Debbugs-CC) the maintainer 'joaotavora@gmail.com' as well.  Please
> +read the chapter titled "Troubleshooting" in the Eglot manual,
> +available https://joaotavora.github.io/eglot/#Troubleshooting-Eglot

The Eglot manual is now part of Emacs, not on GitHub.

Re: New Eglot release

[João Távora]

On Fri, Mar 10, 2023 at 12:23 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Cc: Philip Kaludercic <philipk@posteo.net>,  emacs-devel@gnu.org, eliz@gnu.org
> > Date: Fri, 10 Mar 2023 11:38:37 +0000
> >
> > Eli, is this patch good to push?  It adds a new etc/EGLOT-NEWS and makes
> > a tiny mention to it in etc/NEWS.
>
> EGLOT-NEWS mentions many bugfixes, something that we don't do in
> NEWS.  The style is also very different:

Yes, it's quite different and this is in big part why I opted for
a separate file, so hopefully these idiosyncrasies could be
at least tolerated.

> > +(github#29)
> > +
> > +** Handle experimental/unknown server methods gracefully.
>
> This doesn't say enough about the change, so why mention it?  And why
> the GitHub reference there?

For readers to get access to the original context.  This was all
pre-merge, and at the time I decided as maintainer that that would
be the kind of NEWS file that I would like to read.

> > +** Hierarchical symbols are supported in Imenu.
> > +Thanks to Ingo Lohmar for the original implementation (github#303).
>
> We don't mention individual contributors in NEWS.  They are mentioned
> in AUTHORS instead (and if you want, also in doc/emacs/ack.texi).

Yeah, again pre-merge.  At the time I didn't have an AUTHORS file and
I wanted to thank certain contributors specially for certain
contributions.  Shall I remove these mentions? (Sorry Ingo :-) )

> > +(github#196)
> > +
> > +** Completion sorting fixed.
>
> This (and other similar entries) are not very useful, IMNSHO.
>
> Moreover, I don't think I see why mentioning past versions of Eglot
> that were never parts of Emacs would be useful to someone.
> It might be okay to have that on ELPA,

Eglot is a :core GNU ELPA package, meaning its source files and its
documentation lives in the Emacs.git repo.

> but I don't see why we'd want this in Emacs core.

I think it's quite nice to have a historical record of Eglot's
evolution, to see how far it has come, how certain decisions were
taken and adjusted over the years.

> > +mode: outline
> > +mode: bug-reference-mode
>
> Why not emacs-news-mode?

Because, for some reason I didn't investigate, it erases my
bug-reference-bug-regexp and the links stop working.

> > +Please send Eglot bug reports to 'bug-gnu-emacs@gnu.org', and Cc (or
> > +X-Debbugs-CC) the maintainer 'joaotavora@gmail.com' as well.  Please
> > +read the chapter titled "Troubleshooting" in the Eglot manual,
> > +available https://joaotavora.github.io/eglot/#Troubleshooting-Eglot
>
> The Eglot manual is now part of Emacs, not on GitHub.

When Emacs 29 is releasd, probably the Eglot manual will be in GNU
sites _for that release, but not for all the other intermediate releases
of the :core ELPA package.

AFAIK, the only place where an up-to-date version is published
for users to read is that link (I'm happy to be shown otherwise, so
I don't have to do this periodic chore anymore).

João

Re: New Eglot release

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 10 Mar 2023 12:50:27 +0000
> Cc: jp@neverwas.me, philipk@posteo.net, emacs-devel@gnu.org
> 
> > > Eli, is this patch good to push?  It adds a new etc/EGLOT-NEWS and makes
> > > a tiny mention to it in etc/NEWS.
> >
> > EGLOT-NEWS mentions many bugfixes, something that we don't do in
> > NEWS.  The style is also very different:
> 
> Yes, it's quite different and this is in big part why I opted for
> a separate file, so hopefully these idiosyncrasies could be
> at least tolerated.

You wanted my opinion; I don't like the style.

> > > +(github#29)
> > > +
> > > +** Handle experimental/unknown server methods gracefully.
> >
> > This doesn't say enough about the change, so why mention it?  And why
> > the GitHub reference there?
> 
> For readers to get access to the original context.

That's IMNSHO is a disservice for the readers.  We should not force
them to go places and read there about the changes, we should provide
enough information for them to understand what has been changed
without going anywhere.  In the few cases where a change is too
complex to describe, we direct to the manual (which is party of the
distribution, and thus at the reader's fingertips).

> > > +** Hierarchical symbols are supported in Imenu.
> > > +Thanks to Ingo Lohmar for the original implementation (github#303).
> >
> > We don't mention individual contributors in NEWS.  They are mentioned
> > in AUTHORS instead (and if you want, also in doc/emacs/ack.texi).
> 
> Yeah, again pre-merge.  At the time I didn't have an AUTHORS file and
> I wanted to thank certain contributors specially for certain
> contributions.  Shall I remove these mentions? (Sorry Ingo :-) )

AUTHORS are generated from ChangeLog files, so they will catch all the
contributions in Git.  Since AFAIU the Eglot history was preserved in
Emacs, those contributions will be caught as well, I think?

> > > +(github#196)
> > > +
> > > +** Completion sorting fixed.
> >
> > This (and other similar entries) are not very useful, IMNSHO.
> >
> > Moreover, I don't think I see why mentioning past versions of Eglot
> > that were never parts of Emacs would be useful to someone.
> > It might be okay to have that on ELPA,
> 
> Eglot is a :core GNU ELPA package, meaning its source files and its
> documentation lives in the Emacs.git repo.

Does that mean the ELPA tarball cannot include files that are not in
the Emacs Git repository?

> > but I don't see why we'd want this in Emacs core.
> 
> I think it's quite nice to have a historical record of Eglot's
> evolution, to see how far it has come, how certain decisions were
> taken and adjusted over the years.

NEWS is not about evolution, it's about changes in specific versions.
Since Emacs will not come with past versions of Eglot, mentioning
those doesn't seem useful.

> > > +mode: outline
> > > +mode: bug-reference-mode
> >
> > Why not emacs-news-mode?
> 
> Because, for some reason I didn't investigate, it erases my
> bug-reference-bug-regexp and the links stop working.

You mean emacs-news-mode and bug-reference-mode are incompatible?
Then perhaps we should fix emacs-news-mode?

> > > +Please send Eglot bug reports to 'bug-gnu-emacs@gnu.org', and Cc (or
> > > +X-Debbugs-CC) the maintainer 'joaotavora@gmail.com' as well.  Please
> > > +read the chapter titled "Troubleshooting" in the Eglot manual,
> > > +available https://joaotavora.github.io/eglot/#Troubleshooting-Eglot
> >
> > The Eglot manual is now part of Emacs, not on GitHub.
> 
> When Emacs 29 is releasd, probably the Eglot manual will be in GNU
> sites _for that release, but not for all the other intermediate releases
> of the :core ELPA package.
> 
> AFAIK, the only place where an up-to-date version is published
> for users to read is that link (I'm happy to be shown otherwise, so
> I don't have to do this periodic chore anymore).

It makes no sense to me to point to the outdated manual on GitHub.
I'm not aware of any other bundled package which does something like
that.

Re: New Eglot release

[João Távora]

On Fri, Mar 10, 2023 at 1:06 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Yes, it's quite different and this is in big part why I opted for
> > a separate file, so hopefully these idiosyncrasies could be
> > at least tolerated.
>
> You wanted my opinion; I don't like the style.

I asked if this is "good to push" ;-)

But I'm interested in your opinion, not necessarily in changing it.

> > > > +(github#29)
> > > > +
> > > > +** Handle experimental/unknown server methods gracefully.
> > >
> > > This doesn't say enough about the change, so why mention it?  And why
> > > the GitHub reference there?
> >
> > For readers to get access to the original context.
>
> That's IMNSHO is a disservice for the readers.  We should not force
> them to go places and read there about the changes, we should provide
> enough information for them to understand what has been changed
> without going anywhere.  In the few cases where a change is too
> complex to describe, we direct to the manual (which is party of the
> distribution, and thus at the reader's fingertips).

I've maintained this project for 5 years and interacted with many
of its users.  My understanding  of what this particular project's
audience is different (but it is not set in stone).

Also users can read the Eglot's (and other ELPA :core packages')
NEWS from other outlets, such as https://elpa.gnu.org/ or even
from links to the Git repo directly.

I think you have a very different understanding of how NEWS
is consumed partly because of how Emacs releases work.  They
follow a release schedule that is one order of magnitude slower
than Eglot's (I'm not criticizing, just stating).

> > > > +** Hierarchical symbols are supported in Imenu.
> > > > +Thanks to Ingo Lohmar for the original implementation (github#303).
> > >
> > > We don't mention individual contributors in NEWS.  They are mentioned
> > > in AUTHORS instead (and if you want, also in doc/emacs/ack.texi).
> >
> > Yeah, again pre-merge.  At the time I didn't have an AUTHORS file and
> > I wanted to thank certain contributors specially for certain
> > contributions.  Shall I remove these mentions? (Sorry Ingo :-) )
>
> AUTHORS are generated from ChangeLog files, so they will catch all the
> contributions in Git.  Since AFAIU the Eglot history was preserved in
> Emacs, those contributions will be caught as well, I think?

Yes, they are there.  I'll remove the mentions to individuals then,
it's no problem.

> > > > +(github#196)
> > > > +
> > > > +** Completion sorting fixed.
> > >
> > > This (and other similar entries) are not very useful, IMNSHO.
> > >
> > > Moreover, I don't think I see why mentioning past versions of Eglot
> > > that were never parts of Emacs would be useful to someone.
> > > It might be okay to have that on ELPA,
> >
> > Eglot is a :core GNU ELPA package, meaning its source files and its
> > documentation lives in the Emacs.git repo.
>
> Does that mean the ELPA tarball cannot include files that are not in
> the Emacs Git repository?

No idea.  But I would like to keep all Eglot's files in one Git
repository, if possible.

> > > but I don't see why we'd want this in Emacs core.
> >
> > I think it's quite nice to have a historical record of Eglot's
> > evolution, to see how far it has come, how certain decisions were
> > taken and adjusted over the years.
>
> NEWS is not about evolution, it's about changes in specific versions.

If you take those together, it maps the evolution of program
in terms of user visible behaviour.

> Since Emacs will not come with past versions of Eglot, mentioning
> those doesn't seem useful.

But gnu.elpa.org allows access to old version, and this
etc/EGLOT-NEWS file is supposed to be imported into there (that's
what F. Jason Park mentioned some email ago).  So I think it
makes sense.

etc/ERC-NEWS also uses a freer style

> > > > +mode: outline
> > > > +mode: bug-reference-mode
> > >
> > > Why not emacs-news-mode?
> >
> > Because, for some reason I didn't investigate, it erases my
> > bug-reference-bug-regexp and the links stop working.
>
> You mean emacs-news-mode and bug-reference-mode are incompatible?
> Then perhaps we should fix emacs-news-mode?

Maybe, and then etc/EGLOT-NEWS can use it.  It's nicer indeed.

> > AFAIK, the only place where an up-to-date version is published
> > for users to read is that link (I'm happy to be shown otherwise, so
> > I don't have to do this periodic chore anymore).
>
> It makes no sense to me to point to the outdated manual on GitHub.
> I'm not aware of any other bundled package which does something like
> that.

It's not outdated, it's the opposite!  As I wrote, it's the most
up-to-date version available,  AFAICT.  I render the doc/misc/eglot.texi file
manually to HTML and update it. Updated it yesterday, for example.

João

Re: New Eglot release

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> +mode: outline
>> +mode: bug-reference-mode
>
> Why not emacs-news-mode?

I guess emacs-news-view-mode is better suited. It let you follow the
references. Good for the majority of readers.

There is the samll disadvantage that it shows the file readonly. But
that's an annoyance only for somebody who wants to edit the file, and it
can be fixed then by "M-x emacs-news-mode".

Two commands I use often when inspecting etc/NEWS.

Best regards, Michael.

Re: New Eglot release

[João Távora]

Michael Albinus <michael.albinus@gmx.de> writes:

>> Why not emacs-news-mode?
>
> I guess emacs-news-view-mode is better suited. It let you follow the
> references. Good for the majority of readers.
>
> There is the samll disadvantage that it shows the file readonly. But
> that's an annoyance only for somebody who wants to edit the file, and it
> can be fixed then by "M-x emacs-news-mode".

I'm tempted to do that, but the annoyance might be too much, methings.
I'd say the best thing would be to allow bug-reference-mode in
emacs-new-mode.  Until then, keeping it in outline is not so bad (and
follows etc/ERC-NEWS).

João

Re: New Eglot release

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  jp@neverwas.me,  philipk@posteo.net,
>   emacs-devel@gnu.org
> Date: Sat, 11 Mar 2023 20:16:07 +0000
> 
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
> > There is the samll disadvantage that it shows the file readonly. But
> > that's an annoyance only for somebody who wants to edit the file, and it
> > can be fixed then by "M-x emacs-news-mode".
> 
> I'm tempted to do that, but the annoyance might be too much, methings.

Doesn't "C-x C-q" solve that with a single command?

Re: New Eglot release

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  jp@neverwas.me,  philipk@posteo.net,
>>   emacs-devel@gnu.org
>> Date: Sat, 11 Mar 2023 20:16:07 +0000
>> 
>> Michael Albinus <michael.albinus@gmx.de> writes:
>> 
>> > There is the samll disadvantage that it shows the file readonly. But
>> > that's an annoyance only for somebody who wants to edit the file, and it
>> > can be fixed then by "M-x emacs-news-mode".
>> 
>> I'm tempted to do that, but the annoyance might be too much, methings.
>
> Doesn't "C-x C-q" solve that with a single command?

That's why I was tempted, but thinking that this file is to be edited by
other users, like the ones proposing new features over at bug#62116 and
github#839, and knowing that these users are not always familiar with
Emacs' development, this could be a source of confusion.  As in "should
I be editing this read-only file?".  A small hindrance, of course, but
the somewhat frivolous cosmetics we gain in exchange aren't worth it,
IMO.  Better to fix emacs-news-mode.

João