Re: Emacs as an Org LSP server

[Tim Cross <theophilusx@gmail.com>]

I am no fan of Microsoft. I have run Linux as my primary desktop since
1994. I have been working as a developer since 1988 and have first hand
experience regarding many of the poor business practices of Microsoft.
However, I think the LSP is actually a positive imitative and a
potential benefit to all developers and all editors and development
tools, both closed and open source. I have outlined some points I think
are relevant below.

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> On Tue, Dec 15, 2020 at 01:08:47AM +0800, TEC wrote:
>>
>> Jean Louis <bugs@gnu.support> writes:
>>
>> > [LSP is a evil plot from microsoft]
>>
>> I can see that you're overly concerned about Microsoft being able to
>> somehow exert control over this. It may assuage your concerns to see an
>> example "technology stack" that Org-LSP could fit into.
>
> REST API calls to a remote server as a core part of editing text in
> your editor isn't concerning? How remote? How would you know? If they
> use HTTPS could you even see what is sent?
>

LSP is not restricted to REST. It uses JSON as the message format, but
can use any form of remote procedure call. It could be REST, it could be
basic Unix socket interface, it could be some other TCP interface. Any
interface both sides understand will work.

>> Microsoft has provided a /standard/ that a huge number of editors/IDEs
>> have adopted with /independent implementations/. At this point there is
>> /nothing/ M$ could do to interfere with how the above works.
>
> Microsoft doesn't make standards that it can't corrupt or take
> advantage of. See LDAP/AD, HTML extensions, programming language
> extensions that makes their solutions incompatible with standards.
>

Yes, Microsoft does have a poor reputation when it comes to standards.
However, if you consider why they have proposed the LSP and what their
business model is, it becomes fairly obvious there is no benefit for
them in changing this specification without good technical reasons.

Microsoft has proposed the LSP because it has the potential to make
their editors more popular and able to support more languages. They want
others to implement the LSP server so that they can support the language
in their editor or development tools with minimal development effort,
increasing market share and reducing maintenance costs. Nothing unusual
with that - basic business principal. They won't want to modify or
change the protocol unnecessarily as that will break their own
integration with these servers. Their business model relies on
maintaining the standard they have proposed.

The key point here is that other technologies, including free software
tools like Emacs, can also benefit from this technology. I'm sure
Microsoft would prefer to prevent this, but they can't if they want
others to develop the language server modules.

One of the biggest challenges for editors like Emacs is how to provide
support for new languages which include all the features people expect
in a modern editor. Often, it is extremely difficult to provide these
features without incorporating some form of language parser or compiler.
this is difficult to do with just Elisp. To try and work around these
limitations, Emacs has used things like ECLIM to interface with the
Eclipse editor and leverage off the internal facilities it provides.
What the LSP does is provide a generic interface definition which works
in a similar fashion, but is not dependent on an external server like
Eclipse.

Consider the potential of a future where in addition to defining a new
language, tools to compile/parse and execute the language the projects
which develop/maintain that language also provide an LSP server for that
language. this would mean that in order to use that language in your
editor, all you need to do is configure your LSP client to communicate
with that server.

I currently use 4 different LSP servers in my Emacs setup. None of them
require a web server. They are all just scripts/executables which sit in
my bin directory. When I open a file in a language which has a LSP
server, Emacs starts the server and communicates with it to handle
completion, linting, format hints etc. There is no external network
connection required, no remote services, no reporting to MS. Even if
Microsoft changes the specification, it has no impact on my current use.

>> You seem to be focusing on the term "server" in the name. This seems to
>> be a red herring in this case. In LSP the server is analogous to "emacs
>> --daemon" and the client to "emacsclient".
>
> REST = web server. Using to make JSON requests over what you are
> editing and your editor requiring the ability to send/receive to a
> potential remote web server is a valid concern.
>

Except that isn't how it works. There is no requirement for a web
server and there is no requirement for it to be based on REST. The
message format is JSON, but how these messages are passed between the
editor and the server is not restricted to a HTTP protocol.


> Emacs daemon is a local socket interface (by default) for
> communication between processes on the same box.
>

As are some of the LSP interfaces.

>> I appreciate your concerns Jean, and am aware of Microsoft's history,
>> however I do not believe there is any factual basis for your conclusions
>> in this instance.
>
> Tainted, definitions quoted from https://www.thefreedictionary.com/tainted
>
>  - To affect or associate with something undesirable or reprehensible:
>     a reputation that was tainted by allegations of illegal activity.
>
>  - An undesirable or corrupting influence or association: wanted to
>     avoid the taint of an accounting scandal.
>
> This is the point. Given Microsoft's shameful history, any project
> they are supporting is *tainted* by their corrupting influence and
> association. That LSP is pushed by MS makes it undesirable due to
> their reputation. That Github is now owned by MS makes it tainted by
> their reputation.
>

And yet Microsoft has submitted and had patches accepted into the Linux
kernel. Does this mean the Linux kernel is now tainted?

> Companies, just like individuals should be judged by their actions.
> Microsoft's well earned poor reputation is sufficient reason to
> exclude them from any open source effort.
>
> I must conclude that MS is supporting LSP because they believe it will
> increase market share for their proprietary editors. This is due to
> their reputation and historic behavior. Thus I have no desire to
> support LSP and thus not support MS indirectly.
>

Just because something is a benefit for Microsofts market share is no
reason it can not also be a benefit to others. I have no illusions that
Microsoft has proposed the LSP because they can see a benefit for their
editors and tools. However, there is such a thing as mutual benefit. The
LSP is a good idea regardless of its origin. Similar ideas have been
proposed before, but have failed to gain traction because they lacked
sufficient support. In fact, LSP could be a benefit to open source
because it now means editors like Emacs could incorporate feature rich
support for closed languages, such as Microsoft's .net and visual basic
and make it more feasible to use Emacs in environments where this was
not possible or as productive as using a native Microsoft editor.

As to the question of indirect support for Microsoft, I have some bad
news. It is more than likely, if you are using Emacs, you are already
providing indirect support. I recently had a look at the packages in the
GNU ELPA repository. I found 98 of these packages, all of them with
copyright assigned to the FSF, are maintained and developed on github.
If you are using GNU ELPA packages, it is highly likely you are using a
package which relies on github for maintenance of the code base,
supporting github which is owned by Microsoft.

We are right to be sceptical about anything proposed by Microsoft.
However, we also need to look more deeply than just a "everything
microsoft does is bad". Even bad people can have good ideas. We need to
evaluate the idea on its own merit and use it to meet our own
requirements. In this case, an LSP server for org mode has the potential
to bring org mode to others who don't use Emacs. I have reservations
about how successful this can be because much of what I think makes org
mode such a powerful tool is too highly tied to Emacs, but I think it is
a great experiment which might prove to be beneficial to both org mode
and free software more generally.

--
Tim Cross