From: Tom Gillespie <firstname.lastname@example.org> To: Tim Cross <email@example.com> Cc: emacs-orgmode <firstname.lastname@example.org> Subject: Re: Emacs as an Org LSP server Date: Mon, 14 Dec 2020 16:45:04 -0500 [thread overview] Message-ID: <CA+G3_POpGbbgCz0nqk0juTrXxgw4goGOd4zGoeQsSUE76AQOyg@mail.gmail.com> (raw) In-Reply-To: <email@example.com> 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 <firstname.lastname@example.org> 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 <RLAdams@AdamsInfoServ.Com> writes: > > > On Tue, Dec 15, 2020 at 01:08:47AM +0800, TEC wrote: > >> > >> Jean Louis <email@example.com> 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 >
next prev parent reply other threads:[~2020-12-14 21:46 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 [this message] 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 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=CA+G3_POpGbbgCz0nqk0juTrXxgw4goGOd4zGoeQsSUE76AQOyg@mail.gmail.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).