From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cHXvG5ne11+udwAA0tVLHw (envelope-from ) for ; Mon, 14 Dec 2020 21:52:25 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id KB7ZF5ne11+7TwAA1q6Kng (envelope-from ) for ; Mon, 14 Dec 2020 21:52:25 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AEEC5940396 for ; Mon, 14 Dec 2020 21:52:24 +0000 (UTC) Received: from localhost ([::1]:47444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kovlX-0000N9-8v for larch@yhetil.org; Mon, 14 Dec 2020 16:52:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kovkv-0000Ke-Fc for emacs-orgmode@gnu.org; Mon, 14 Dec 2020 16:51:45 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]:36905) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kovkr-0001WT-SQ for emacs-orgmode@gnu.org; Mon, 14 Dec 2020 16:51:44 -0500 Received: from localhost ([::ffff:197.157.34.185]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E007.000000005FD7DE69.000078C6; Mon, 14 Dec 2020 14:51:37 -0700 Date: Tue, 15 Dec 2020 00:51:02 +0300 From: Jean Louis To: Tim Cross Subject: Re: Emacs as an Org LSP server Message-ID: References: <87o8kf69tm.fsf@ucc.asn.au> <87v9d66l75.fsf@gmail.com> <87a6ugpftr.fsf@gmail.com> <877dpkpefs.fsf@gmail.com> <87y2i0kup8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87y2i0kup8.fsf@gmail.com> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -0.31 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: AEEC5940396 X-Spam-Score: -0.31 X-Migadu-Scanner: scn0.migadu.com X-TUID: KWar8s0+EUsq 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 [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