emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Emacs as an Org LSP server
Date: Tue, 15 Dec 2020 00:51:02 +0300	[thread overview]
Message-ID: <X9feRggSqEQ/Zj0f@protected.rcdrun.com> (raw)
In-Reply-To: <87y2i0kup8.fsf@gmail.com>

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	other threads:[~2020-12-14 21:52 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 15:05 Emacs as an Org LSP server TEC
2020-12-13 10:41 ` TEC
2020-12-13 11:05   ` Bill Burdick
2020-12-13 14:36   ` Jean Louis
2020-12-13 17:33     ` TEC
2020-12-13 20:23       ` Jean Louis
2020-12-14  0:54         ` Gerry Agbobada
2020-12-14  1:04           ` Tim Cross
2020-12-14  1:10         ` George Mauer
2020-12-14 11:41   ` Neil Jerram
2020-12-14 15:25     ` TEC
2020-12-14 15:46       ` Neil Jerram
2020-12-14 15:55         ` TEC
2020-12-14 17:02           ` Jean Louis
2020-12-14 17:08             ` TEC
2020-12-14 18:05               ` Russell Adams
2020-12-14 18:12                 ` TEC
2020-12-14 19:16                   ` Russell Adams
2020-12-14 20:18                     ` Jean Louis
2020-12-14 21:34                     ` Tim Cross
2020-12-14 20:20                 ` Tim Cross
2020-12-14 21:45                   ` Tom Gillespie
2020-12-14 18:39               ` LSP is Microsoft's patented protocol - " Jean Louis
2020-12-14 18:44                 ` TEC
2020-12-14 18:52                   ` Jean Louis
2020-12-15  5:47                     ` Richard Stallman
2020-12-15  5:50                       ` Jean Louis
2020-12-15  6:09                         ` Christopher Dimech
2020-12-15  6:25                           ` Jean Louis
2020-12-15  6:51                             ` Christopher Dimech
2020-12-16  5:38                           ` Richard Stallman
2020-12-14 17:27             ` Gerry Agbobada
2020-12-14 18:16               ` Jean Louis
2020-12-14 18:26                 ` TEC
2020-12-14 18:50                   ` Jean Louis
2020-12-14 19:41                   ` Russell Adams
2020-12-14 18:51                 ` Bastien
2020-12-15  8:51               ` Bill Burdick
2020-12-14 19:50             ` Tim Cross
2020-12-14 21:51               ` Jean Louis [this message]
2020-12-14 22:35                 ` Dominik Schrempf
2020-12-14 23:36                   ` Jean Louis
2020-12-14 17:22           ` Neil Jerram
2020-12-14 17:24             ` TEC
2020-12-14 17:57               ` Neil Jerram
2020-12-14 18:04                 ` TEC
2020-12-14 17:39             ` Russell Adams
2020-12-14 17:45               ` TEC
2020-12-16 11:49   ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X9feRggSqEQ/Zj0f@protected.rcdrun.com \
    --to=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).