From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id d7wENd/o11/dbgAA0tVLHw (envelope-from ) for ; Mon, 14 Dec 2020 22:36:15 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id GPdCMN/o1188fQAAB5/wlQ (envelope-from ) for ; Mon, 14 Dec 2020 22:36:15 +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 EB3C49401BC for ; Mon, 14 Dec 2020 22:36:14 +0000 (UTC) Received: from localhost ([::1]:48006 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kowRx-0000ax-Te for larch@yhetil.org; Mon, 14 Dec 2020 17:36:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kowRW-0000ae-Fa for emacs-orgmode@gnu.org; Mon, 14 Dec 2020 17:35:46 -0500 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]:45399) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kowRU-0007Xj-6b for emacs-orgmode@gnu.org; Mon, 14 Dec 2020 17:35:46 -0500 Received: by mail-ej1-x62e.google.com with SMTP id qw4so24822772ejb.12 for ; Mon, 14 Dec 2020 14:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:in-reply-to:message-id:date :mime-version; bh=7KvLBaQBlJId6D3ZvXFOIjTr/gEa0pDBTZiQz3VNDLI=; b=ZHh/HV/fhv4LogQ9eJB/nJPKliw/r5Ay3v5PxlK5RgHItE+/noTRmgO+BfYkYSyUr5 +GIow3QN1COwW06Zs2kl9me0eP0FqbZb39DPSJuWTrMqiGvt0PAFNh0OSf+Zg1NBlY5g ohkzo4Nn8i3RPRCmkko4xNmGYwN9lrn4b917+KgFx2ZvEoXkz+e3HM6EFyQ5do93ZJFO spv26XZhvFcv6ET3cdbP/8mtfVAeNz8QMddKvrYOlOvvqwn8HSKdkfF75po9KDa2f2dI x+aZC50Yf1+WOUwelFMHs5dflGPqBB+NX6M6+t5TOquK26XhKUgqQpXfmoLy3RBEppQR xJiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject :in-reply-to:message-id:date:mime-version; bh=7KvLBaQBlJId6D3ZvXFOIjTr/gEa0pDBTZiQz3VNDLI=; b=TzDMrx0ugGEooH51YdcfBlyMwZAdnQHgUMmLeokz3GPva4Uj8hxuo1W6iebgdIuFv/ BUNS4ilg2FYD4U2HJ6SVqvybuYjsE5rK9KGTjGZIRwvV4iGhceNuIbeiwPmTkcAOVWmY wF7E1LXd1gEAVCot8uGQPXHJ2vgHwXhsNyq+RvwlWGcrlnUiwXC3NBTABlZLnfZGxAmw 0u8bCiUdpFhpdn8Vftfk09i5e6nthOD+dTxcVNrkHI/13GFUK7vAQ5oJQ+fxi++b7HnQ YVpxKFVYBvhJEFqn55CXII5AZnvAh0tSva+h0TEaQmBkFJHN1Oyi2Cbi5UAcJ3vG9wrr ttvw== X-Gm-Message-State: AOAM531wtE0B9nERT6oP5BMBEqmn0/4vM0GVl5K6tkC5GfQYNylME89P BAgNufbdo1SHOJibcgtzxlxYiQSoqw== X-Google-Smtp-Source: ABdhPJxCUjfmKcTZ/JOSTVMEOSm5oNYePjPYEGoMkCdg7yysQ1WaEqoa8Pa5BeD32JLY6fNL5fD/CA== X-Received: by 2002:a17:906:7cc6:: with SMTP id h6mr24029338ejp.161.1607985341659; Mon, 14 Dec 2020 14:35:41 -0800 (PST) Received: from localhost (070-207.dynamic.dsl.fonira.net. [178.251.70.207]) by smtp.gmail.com with ESMTPSA id op5sm14409823ejb.43.2020.12.14.14.35.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Dec 2020 14:35:41 -0800 (PST) References: <87o8kf69tm.fsf@ucc.asn.au> <87v9d66l75.fsf@gmail.com> <87a6ugpftr.fsf@gmail.com> <877dpkpefs.fsf@gmail.com> <87y2i0kup8.fsf@gmail.com> User-agent: mu4e 1.4.13; emacs 27.1 From: Dominik Schrempf To: emacs-orgmode@gnu.org Subject: Re: Emacs as an Org LSP server In-reply-to: Message-ID: <87ft48f22r.fsf@gmail.com> Date: Mon, 14 Dec 2020 23:35:40 +0100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=dominik.schrempf@gmail.com; helo=mail-ej1-x62e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.51 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=ZHh/HV/f; dmarc=pass (policy=none) header.from=gmail.com; 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: EB3C49401BC X-Spam-Score: -1.51 X-Migadu-Scanner: scn0.migadu.com X-TUID: nqQ9srecLpjI 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 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 [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