From: Jean Louis <email@example.com> To: Tim Cross <firstname.lastname@example.org> Cc: email@example.com 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: <firstname.lastname@example.org> 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 <email@example.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
next prev parent 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 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Emacs as an Org LSP server' \ /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
Code repositories for project(s) associated with this 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).