From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id ll/2NzXd119bAQAA0tVLHw (envelope-from ) for ; Mon, 14 Dec 2020 21:46:29 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id cP31MjXd119wfwAAbx9fmQ (envelope-from ) for ; Mon, 14 Dec 2020 21:46:29 +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 308C69403AA for ; Mon, 14 Dec 2020 21:46:29 +0000 (UTC) Received: from localhost ([::1]:40622 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kovfo-0005KQ-3q for larch@yhetil.org; Mon, 14 Dec 2020 16:46:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kovej-0005Iq-BT for emacs-orgmode@gnu.org; Mon, 14 Dec 2020 16:45:21 -0500 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:51924) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koveh-0000Cx-1t for emacs-orgmode@gnu.org; Mon, 14 Dec 2020 16:45:21 -0500 Received: by mail-wm1-x32b.google.com with SMTP id v14so15104009wml.1 for ; Mon, 14 Dec 2020 13:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ds1lsabyEK09dFUbnXyOorNOgYDjN7Mn1ehv9B2A1xU=; b=X2l2frRTPOKoqoYeIddCmyGr/cEHRqX5isgfrIaFzjiKDKQrFA0SDwDbK8oSrBcirI ILuC1Lu7w2bcb4CISl673yjLjIXR1q0hfb8I5tXzKiEdD4jNx/rtlOmSQVRQ9OWjFEvX dOSJGMdyxjGbtt8rpZgUAfz1njdGOoa3yalUdploX3XaelfyMnFt9L3hTzhgv6qTEhST JtdpZKu8bQM9KmUeIiNq9ogt57HA0Tg279KUNsixRuZnY44GfehLHT578JAd7an2uv9b XXNK4TBhYKDGwiqnK6g7LI0CW7P9yRNEi7BOB0yfhCmO0iSlp6qbOlK90nRzcIEwM695 BSCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ds1lsabyEK09dFUbnXyOorNOgYDjN7Mn1ehv9B2A1xU=; b=lJ+rOblFGATW4TiTtKyClOobfyykvSvhzzUOedCfYA60EXGl0DSVoakjgLOPm8ofZX oRSKfrV/0t8PkU3yZOMXYZr8NAtCjrvLXIxHw2SlsZZ/2XQJenjo+vTTR9iRLyXP2s2o 1Aq+CCxrpr7r9Ojj8ZKh5Fu0q5lLDw8mgJVfyMfta+SbVszUFVDrs9gPUBkfJCzPwrpf OD4ezUZWjPHSEXc1iYWviVit1fTRzMrGmU7lPOY01tQQCYJM82ZGp52KdAquqKStlELk HCKlzR8zG/JpGoaNKbZ44JgR+xbMj7izALf1jP2W4kW24Z3H8odGEPj3S/BKJuMviio4 PZ0A== X-Gm-Message-State: AOAM5336CJ3ys/XUSF842qMOET3dJ1Pv7y7EJI5LWrD60FuConGxThFg SnP1MUgyUaw5rZQXbGQdKDyxltA8AVlbG19aysc= X-Google-Smtp-Source: ABdhPJyHABnB3YBw47P5TeYnLDcOAzU/HjNNPjEROpx4MgW4/uvKVBd5pJVQQGgWb74I7s5z2J1DZ0FH3ojuc+EGc28= X-Received: by 2002:a7b:c088:: with SMTP id r8mr30145921wmh.45.1607982316040; Mon, 14 Dec 2020 13:45:16 -0800 (PST) MIME-Version: 1.0 References: <87o8kf69tm.fsf@ucc.asn.au> <87v9d66l75.fsf@gmail.com> <87a6ugpftr.fsf@gmail.com> <877dpkpefs.fsf@gmail.com> <873608pai7.fsf@gmail.com> <20201214180549.GE6352@maokai> <87v9d4krc7.fsf@gmail.com> In-Reply-To: <87v9d4krc7.fsf@gmail.com> From: Tom Gillespie Date: Mon, 14 Dec 2020 16:45:04 -0500 Message-ID: Subject: Re: Emacs as an Org LSP server To: Tim Cross Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=tgbugs@gmail.com; helo=mail-wm1-x32b.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: , Cc: emacs-orgmode 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=X2l2frRT; 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: 308C69403AA X-Spam-Score: -1.51 X-Migadu-Scanner: scn0.migadu.com X-TUID: gkQiBPDTPqIU See also. https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00798.html and https://www.reddit.com/r/emacs/comments/696pv1/rms_supports_language_server_protocol_integration/ for some discussion. Best, Tom On Mon, Dec 14, 2020 at 4:31 PM Tim Cross wrote: > > > > I am no fan of Microsoft. I have run Linux as my primary desktop since > 1994. I have been working as a developer since 1988 and have first hand > experience regarding many of the poor business practices of Microsoft. > However, I think the LSP is actually a positive imitative and a > potential benefit to all developers and all editors and development > tools, both closed and open source. I have outlined some points I think > are relevant below. > > Russell Adams writes: > > > On Tue, Dec 15, 2020 at 01:08:47AM +0800, TEC wrote: > >> > >> Jean Louis writes: > >> > >> > [LSP is a evil plot from microsoft] > >> > >> I can see that you're overly concerned about Microsoft being able to > >> somehow exert control over this. It may assuage your concerns to see an > >> example "technology stack" that Org-LSP could fit into. > > > > REST API calls to a remote server as a core part of editing text in > > your editor isn't concerning? How remote? How would you know? If they > > use HTTPS could you even see what is sent? > > > > LSP is not restricted to REST. It uses JSON as the message format, but > can use any form of remote procedure call. It could be REST, it could be > basic Unix socket interface, it could be some other TCP interface. Any > interface both sides understand will work. > > >> Microsoft has provided a /standard/ that a huge number of editors/IDEs > >> have adopted with /independent implementations/. At this point there is > >> /nothing/ M$ could do to interfere with how the above works. > > > > Microsoft doesn't make standards that it can't corrupt or take > > advantage of. See LDAP/AD, HTML extensions, programming language > > extensions that makes their solutions incompatible with standards. > > > > Yes, Microsoft does have a poor reputation when it comes to standards. > However, if you consider why they have proposed the LSP and what their > business model is, it becomes fairly obvious there is no benefit for > them in changing this specification without good technical reasons. > > Microsoft has proposed the LSP because it has the potential to make > their editors more popular and able to support more languages. They want > others to implement the LSP server so that they can support the language > in their editor or development tools with minimal development effort, > increasing market share and reducing maintenance costs. Nothing unusual > with that - basic business principal. They won't want to modify or > change the protocol unnecessarily as that will break their own > integration with these servers. Their business model relies on > maintaining the standard they have proposed. > > The key point here is that other technologies, including free software > tools like Emacs, can also benefit from this technology. I'm sure > Microsoft would prefer to prevent this, but they can't if they want > others to develop the language server modules. > > One of the biggest challenges for editors like Emacs is how to provide > support for new languages which include all the features people expect > in a modern editor. Often, it is extremely difficult to provide these > features without incorporating some form of language parser or compiler. > this is difficult to do with just Elisp. To try and work around these > limitations, Emacs has used things like ECLIM to interface with the > Eclipse editor and leverage off the internal facilities it provides. > What the LSP does is provide a generic interface definition which works > in a similar fashion, but is not dependent on an external server like > Eclipse. > > Consider the potential of a future where in addition to defining a new > language, tools to compile/parse and execute the language the projects > which develop/maintain that language also provide an LSP server for that > language. this would mean that in order to use that language in your > editor, all you need to do is configure your LSP client to communicate > with that server. > > I currently use 4 different LSP servers in my Emacs setup. None of them > require a web server. They are all just scripts/executables which sit in > my bin directory. When I open a file in a language which has a LSP > server, Emacs starts the server and communicates with it to handle > completion, linting, format hints etc. There is no external network > connection required, no remote services, no reporting to MS. Even if > Microsoft changes the specification, it has no impact on my current use. > > >> You seem to be focusing on the term "server" in the name. This seems to > >> be a red herring in this case. In LSP the server is analogous to "emacs > >> --daemon" and the client to "emacsclient". > > > > REST = web server. Using to make JSON requests over what you are > > editing and your editor requiring the ability to send/receive to a > > potential remote web server is a valid concern. > > > > Except that isn't how it works. There is no requirement for a web > server and there is no requirement for it to be based on REST. The > message format is JSON, but how these messages are passed between the > editor and the server is not restricted to a HTTP protocol. > > > > Emacs daemon is a local socket interface (by default) for > > communication between processes on the same box. > > > > As are some of the LSP interfaces. > > >> I appreciate your concerns Jean, and am aware of Microsoft's history, > >> however I do not believe there is any factual basis for your conclusions > >> in this instance. > > > > Tainted, definitions quoted from https://www.thefreedictionary.com/tainted > > > > - To affect or associate with something undesirable or reprehensible: > > a reputation that was tainted by allegations of illegal activity. > > > > - An undesirable or corrupting influence or association: wanted to > > avoid the taint of an accounting scandal. > > > > This is the point. Given Microsoft's shameful history, any project > > they are supporting is *tainted* by their corrupting influence and > > association. That LSP is pushed by MS makes it undesirable due to > > their reputation. That Github is now owned by MS makes it tainted by > > their reputation. > > > > And yet Microsoft has submitted and had patches accepted into the Linux > kernel. Does this mean the Linux kernel is now tainted? > > > Companies, just like individuals should be judged by their actions. > > Microsoft's well earned poor reputation is sufficient reason to > > exclude them from any open source effort. > > > > I must conclude that MS is supporting LSP because they believe it will > > increase market share for their proprietary editors. This is due to > > their reputation and historic behavior. Thus I have no desire to > > support LSP and thus not support MS indirectly. > > > > Just because something is a benefit for Microsofts market share is no > reason it can not also be a benefit to others. I have no illusions that > Microsoft has proposed the LSP because they can see a benefit for their > editors and tools. However, there is such a thing as mutual benefit. The > LSP is a good idea regardless of its origin. Similar ideas have been > proposed before, but have failed to gain traction because they lacked > sufficient support. In fact, LSP could be a benefit to open source > because it now means editors like Emacs could incorporate feature rich > support for closed languages, such as Microsoft's .net and visual basic > and make it more feasible to use Emacs in environments where this was > not possible or as productive as using a native Microsoft editor. > > As to the question of indirect support for Microsoft, I have some bad > news. It is more than likely, if you are using Emacs, you are already > providing indirect support. I recently had a look at the packages in the > GNU ELPA repository. I found 98 of these packages, all of them with > copyright assigned to the FSF, are maintained and developed on github. > If you are using GNU ELPA packages, it is highly likely you are using a > package which relies on github for maintenance of the code base, > supporting github which is owned by Microsoft. > > We are right to be sceptical about anything proposed by Microsoft. > However, we also need to look more deeply than just a "everything > microsoft does is bad". Even bad people can have good ideas. We need to > evaluate the idea on its own merit and use it to meet our own > requirements. In this case, an LSP server for org mode has the potential > to bring org mode to others who don't use Emacs. I have reservations > about how successful this can be because much of what I think makes org > mode such a powerful tool is too highly tied to Emacs, but I think it is > a great experiment which might prove to be beneficial to both org mode > and free software more generally. > > -- > Tim Cross >