emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs as an Org LSP server


From: Dominik Schrempf
Subject: Re: Emacs as an Org LSP server
Date: Mon, 14 Dec 2020 23:35:40 +0100
User-agent: mu4e 1.4.13; emacs 27.1

Hello!

I am infrequent active participant on this list but follow some discussions.
This one I found particularly interesting. I do see both of your points Tim
Cross, and Jean Louis, thank you for your detailed explanations including the
references.

As a user of Emacs and Org mode (and not so much as a developer), I am mostly
interested in an editor that works well with the features and languages I use.
For example, I am writing a lot of Haskell, and the Haskell Language Server
provides excellent development support. The Haskell Language Server is not
developed exclusively by Emacs users. To the contrary, it's probably developed
mostly by non-Emacs users. Would I use Emacs to write Haskell code if I could
not use the Haskell Language Server? I don't know although I love Emacs. (I am
sure I would, but I would be a little disappointed).

More generally, on https://langserver.org/ I found a very good argument for why
we need a specification such as the LSP.

I quote:

The problem: "The Matrix"
       Go       Java    TypeScript      ...
Emacs  X  X     X
Vim    X  X     X
VSCode X  X     X
...

The solution: Lang[uage] servers and clients
Go         X
Java       X
TypeScript X
...

Emacs  X
Vim    X
VSCode X

I think this is an excellent idea. However, I am not familiar with the legal
aspects mentioned by Jean. So far I had good experiences with language servers.
On the other side, Org mode is Emacs specific, so this argument does not really
apply. Do we want Org mode to stay Emacs specific? I don't know.

Dominik

Jean Louis <bugs@gnu.support> writes:

> There is definitely nothing wrong in providing Org language server
> that runs for different editors who could support the LSP protocol, it
> will boost collaboration.
>
> That is pretty much separate subject of the centralization and
> strategies we spoke about.
>
> * Tim Cross <theophilusx@gmail.com> [2020-12-14 23:19]:
>> This is just ill informed nonsense. The LSP is nothing more than a
>> specification. The fact it was initially defined/proposed by Microsoft
>> is completely irrelevant.
>
> I truly wish it would be that simple.
>
> There are many tools and inventions by Microsoft. Some of them appear
> to be free, but all of them are there to contribute to profit
> making. I am not against profit making. But we have to look into the
> tool as having the purpose to contribute to THEIR profit
> making. History of Microsoft is clear. Sorry, I do not share the
> narrowed viewpoint that they will invest so much money "to help other
> free software developers". That it is defined by Microsoft in
> collaboration with others is very relevant there.
>
> First question to clarify is if it is really patented or not. While
> you as user you can download some Rust server software or Java
> software and run server that will work with various editors, somebody
> else may not be able to do so if there is patent on it. That imposes
> freedom obstacles in future.
>
> Does this patent description correspond to the subject:
> https://uspto.report/patent/app/20190149346
>
>> It is NOT server based in the sense you mean. In fact, it is
>> actually precisely what you argue it should be. LSP is simply a
>> "generic definitions how editor could act, and editor could load
>> those generic definitions locally."
>
> I am well aware that you as user may download the piece of software
> and run it as server on your computer and that you wish to distinguish
> how user may not need a remote server. We clarified this
> already.
>
> Corporation will not have use of your personal use, they will promote
> their servers and push people to get hooked and trapped into it. It
> will become questionable if other entities become able to do the same
> if such process is patented.
>
> That it is server based should be undisputable. The whole protocol
> speaks of sparing client's CPU time, so CPU time will be spared when
> process does not run on the same CPU. You can run it now for
> yourself. Sure. But the strategy is visible from their very open
> descriptions. Large company is not interested in those single
> users. Single users had "git" under their control but nobody had
> enough money and power to centralize 50 million developers.
>
> Innocent example is: https://melpa.org/#/lsp-pascal package that
> requires: https://github.com/arjanadriaanse/pascal-language-server
>
> But it is made and designed as a server for third parties to take
> advantage of it one time in future.
>
> https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
>
> If one would like to improve all editors to use centralized
> specifications than that could be done also by providing server-less
> specification that every editor could load and thus function in the
> same way. Then editor developers could make their underlying language
> module that would understand the extension
> specificiation. Then users would just need to import or load the
> general specification something like XML file or similar type of a
> document that says how specific programming language would be linted,
> completed, highlighted and so on. And all free software editors would
> likely comply and adopt that, would that option be popularized.
>
> That option was not popularized and server based model have been
> chosen as only so one can take away computing control from people and
> gain larger market share.
>
> Microsoft engineers are not stupid to provide a useful tool and in
> addition to put money to promote such tool for other editors as there
> would be no gain for them in that strategy.
>
> Maybe not everytime user need to use third software to provide
> specification for some language, but most of time. I do understand
> that language server provides same service to various editors provided
> they use LSP protocol. I do understand it can minimize code writing
> which is definitely sound and reasonable. It is just our narrow view
> on it. Read the patent and wrong me if that patent does not
> apply. Read their plans of server based designed and third party
> registry and wrong me if it is not so.
>
> Instead of some larger Emacs Lisp package for specific language mode,
> we will load somewhat or considerably shorter Emacs Lisp PLUS the
> external software to provide us server to Emacs supporting that
> specific software.
>
> Even the server has to be developed, but apparently minimizes efforts
> in larger group of editor developers.
>
> - servers can be downloaded currently by users and used on single
>   computer. Yet intention of the protocol is not to be used on single
>   computer but to take away the CPU time/effort from clients onto the
>   server side. The logic for long term strategy is "third party"
>   providing a service. They may or may not implement it. It sounds
>   like CPU is not enough for Emacs to handle multiple languages, but
>   alright, let us follow their logic.
>
> From:
> https://www.infoworld.com/article/3088698/microsoft-backed-langauge-server-protocol-strives-for-language-tools-interoperability.html
>
> "Either a third-party registry or a bundling of the language server
> inside of an IDE is necessary to enable Language Server Protocol. An
> open governance model for the protocol still must be developed,
> according to Jewell."
>
> Now we are using bundling method. But the "third party registry" is
> an option for future. That clearly speaks of long term strategy.
>
> You speak of bundling method. I speak of the overall long term
> strategy. Once we all start using it, then there will be new
> innovation: there will be no need to download all those various
> language servers, there will be united centralized place which on can
> use.
>
> In general, I find the strategy smart, but not humanitarian as it
> appears to be. It is competition for control of the market share, run
> for profit, and possible spying and tracking of users (once third
> party registry come into place) and a way to take away computing from
> people.
>
> When there is enough general acceptance, people will be centralized,
> trapped and tracked.
>
> It is one way for Emacs to die. The more control there is the more
> funnel effect will be there for only few software pieces to remain on
> the market, probably those belonging to Microsoft. Developers are
> moved into direction how corporations want it. Not how they want it.
>
> Who controls the specification controls all editors and their related
> users.
>
> Jean



reply via email to

[Prev in Thread] Current Thread [Next in Thread]