emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs as an Org LSP server


From: Tom Gillespie
Subject: Re: Emacs as an Org LSP server
Date: Mon, 14 Dec 2020 16:45:04 -0500

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 <theophilusx@gmail.com> 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 <bugs@gnu.support> 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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]