From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Elisp LSP Server Date: Tue, 02 Nov 2021 04:47:07 +1100 Message-ID: <87ilxbyb20.fsf@gmail.com> References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <8100571.MQnaI0vtd3@galex-713.eu> <2131617.6ipFHDhFrr@galex-713.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26686"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.4; emacs 28.0.60 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 01 20:56:03 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mhdPX-0006iV-6R for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Nov 2021 20:56:03 +0100 Original-Received: from localhost ([::1]:60398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhdPV-0004ty-Fg for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Nov 2021 15:56:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55694) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhcEL-0003MQ-Vi for emacs-devel@gnu.org; Mon, 01 Nov 2021 14:40:27 -0400 Original-Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]:35714) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhcEI-0007so-Ix for emacs-devel@gnu.org; Mon, 01 Nov 2021 14:40:25 -0400 Original-Received: by mail-pf1-x42d.google.com with SMTP id s5so5638300pfg.2 for ; Mon, 01 Nov 2021 11:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=L0tDCP9G6dpGRVOZ6lQ7yFtq4eP3gPifFVedwFbmbQg=; b=DqRmFsDeGf8ElWEGs/Zo031vSzHTnr9VC4/mz6FdiFWtqwc1x+hQ+I69OwRMfaByub XUHCWYNc4DUafqHDjiGot/2v7hGiAcGHpGplVlVZSA5To1uejmlVtu75ne3Th6We2mPU rRtO3X0JybjQ4Zhiuupj/VTuOhaI2LchXB2vuG06Nf2ZZDMkavFv5zQVi7HVvzM6JqYO CvqmginwgYPYkVMH5CgHfzU8E3X8Y48M+iieyS20EI/1BE8S0xHf5BiT07TAn5JTJxvm KlR5FuWKg8ZcJ/cQThAxwCRkPOEk2ivuMljSV5V9LTbvjB54SIjdZ2gh5fqQ/lYFKhwg XOEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=L0tDCP9G6dpGRVOZ6lQ7yFtq4eP3gPifFVedwFbmbQg=; b=AeZNKrUllb0gmbIbGXOCy65IcIthdK38H/5qWaXqS+BDuyH63gn6NRcYOwy8BE5OUc dvpQPeKIVCseUI1D/2criW81J4Bs0oFMaKfbFi6svh2bJZVW47mfbqspCRz6xLwYDXqO noDclVfSEcsr9k/SPUTwMx4FpM/xXtnnTRy4sgYargJybs4C0tXYZGGJCFXBzERTOtlL GyOQCtEIKeaEEjDxVZ8BSe+w6lToKvyp3KafmLTjFXGcQvK+NGx0kJVEmXSm51v+F4tw Vyz0WVaEGNwEUGn08w+0QbwyayEVwYq3GClIU0+qTQWRelLBTAhvM8LId57N42a1fZ7N OBXA== X-Gm-Message-State: AOAM533XFWSjOeWSeVeSlf9YGrzZFFbieVtM2qq6otjOB0lpdPidhyIJ zwF8J2IZqFzCNwkPOBfHjukawGP0ASc= X-Google-Smtp-Source: ABdhPJxeEoBCb0cGMu43AYnd3rHevOO8efx8mHydVDr27f5lyQdOW2Z+ZVWc0S2mfr0xJt/30hzccw== X-Received: by 2002:a63:954d:: with SMTP id t13mr23283472pgn.179.1635792020791; Mon, 01 Nov 2021 11:40:20 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-27b4-e52b-0762-d22e.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:27b4:e52b:762:d22e]) by smtp.gmail.com with ESMTPSA id l3sm15675571pff.4.2021.11.01.11.40.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Nov 2021 11:40:19 -0700 (PDT) In-reply-to: <2131617.6ipFHDhFrr@galex-713.eu> Received-SPF: pass client-ip=2607:f8b0:4864:20::42d; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42d.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-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278423 Archived-At: Alexandre Garreau writes: > Le samedi 30 octobre 2021, 08:51:37 CET Richard Stallman a =C3=A9crit : >> [[[ To any NSA and FBI agents reading my email: please consider ]]] >> [[[ whether defending the US Constitution against all enemies, ]]] >> [[[ foreign or domestic, requires you to follow Snowden's example. ]]] >>=20 >> > > You can already start Emacs locally. What's the actual point or >> > > goal >> > > here? >> >=20 >> > you cannot from webpages, >>=20 >> I can't imagine what it would mean to "start Emacs from a web page". >> Can you please explain concretely? Please keep in mind that some of >> us have never seen it. > > To me it would mean to have something written in the page=E2=80=99s sourc= e that=20 > would trigger emacs to be launched, and possibly its window to be=20 > displayed as part of the page (that is: without decoration or ability to= =20 > be moved, and it would scroll with the page=E2=80=99s content and wouldn= =E2=80=99t be=20 > displayed if the browser=E2=80=99s window=E2=80=99s not). > > What I would imagine would be for instance or=20 > possibly with attributes specifying that we want to open it with emacs or= =20 > at line n (I=E2=80=99m sure standards exist for those, there is certainly= some=20 > anchor syntax for within github to point at a line, something like=20 > file.c#l123). > >> With a concrete picture of the practice in question, we could start to >> think about the practical and _moral_ implications of supporting that >> in Emacs. How would it affect the development and use of the GNU >> system? How would it affect our fight against unjust computing? >>=20 >> We could also think about how we would want to implement it, if we >> decide to try. >>=20 >> The more closely and seamlessly Emacs becomes integrated with some >> other program's user interface, the more it undermines our goal of >> making users aware of GNU Emacs, and of the ethical goals that we >> develop GNU Emacs (and GNU as a whole) to promote. > > Oh that=E2=80=99s a valid concern I didn=E2=80=99t thought about=E2=80=A6 > >> That suggests that perhaps the best way to do this job is via >> emacsclient. > > Indeed. > >> > The issue is you can follow an hyperlink from emacs (or any >> >=20 >> > software, for the matter) to the webbrowser, but more hardly from >> > the >> > webbrowser to some specific function of emacs >>=20 >> I'm not sure how to understand the idea of invoking a "specific >> function of Emacs" from a browser. Would you please give a couple of >> concrete examples? Which functions of Emacs would you suggest we >> support imvoking in this way, and how would they be used in the >> scenario? > > open at line, open with a certain mode enabled, open several files at onc= e,=20 > open an svg file either as an image or as source, etc. > > the main one being =E2=80=9Copen at line=E2=80=9D > >> > yet these represent most of the usage of their >> >=20 >> > computer from modern users. >>=20 >> That is not necessarily a recommendation of it. Quite the contrary: >> there are a lot of bad developments in modern computing. >> Most of the computing people do nowadays is for suckers. >> Surveillance companies have a lot of influence over what people >> do on the internet, and how they do it. > > Yes of course. > >> The question of when to go along, and how far, is sometimes >> obvious, and sometimes subtle. > > As I said: I think the way I propose would be strictly in benefit of emac= s=20 > (it would drag people from the browser to emacs, which is going to be mor= e=20 > full-featured and faster anyway). It would also for users because it woul= d=20 > remove the need for javascript in certain cases that are going to=20 > proliferate (people programming inside their browser), so they could avoi= d=20 > it. I'm sorry, but this argument makes no sense to me. This whole argument assumes the user has emacs installed. If they don't use emacs, it is unlikely they have it installed and if they do use it, then it isn't going to attract any new users. I also don't understand the argument of avoiding javascript - the only way to interact with an API or a LSP server or emacsclient from within a web page is via some form of script execution and the only scripting language universally supported inside a browser is javascript (possible exception is with a browser extensions, but that would need a browser specific extensions for each browser type). I also don't see how this relates at all to an elisp language LSP server. So far in this thread, the only person who seems to have come up with a valid justification for an LSP server is Eli, with his suggestion that an elisp LSP server running in a separate Emacs instance could provide an efficient mechanism for offloading processing to a separate process, thereby improving emacs performance (a poor mans multi-tasking if you like). If you had access to an elisp LSP server from within a web browser, that would still require lots of javascript to handle the embedded 'window' - having an elisp LSP server is not going to suddenly enable Emacs to embed an Emacs frame/window inside a web page. The best you could do is use the elisp LSP server for parsing, adding face properties, completion etc. You would still need javascript to manage the display and navigation within the embedded 'window'. . Note also that there already exists a browser extension (chrome and firefox, though I don't know about the firefox extension post the firefox API changes a few years ago), which allows you to use Emacs to edit any editable field in a web page. The 'with-editor' extension adds an 'emacs' button to editable fields in a web page - clicking on that pulls up a new emacs frame (via emacsclient) which allows you to use Emacs to edit the data. Once you close the frame, the data is updated in the browser page field. I disagree with RMS and others fears regarding the implications of an elisp LSP server. I feel this is 'tilting at windmills'. Emacs and elisp are great technologies, but they are of little to no interest to non-emacs users. Just because it would be technically possible to call an elisp LSP server from a non-free program does not mean that provision of such an LSP server would result in either Emacs/elisp being used by non-free software or in some way encouraging free software users to use non-free software. The real benefit of elisp is in the whole environment that Emacs provides. The limited functionality provided via the LSP protocol cannot reproduce that environment and at best, would only provide access to functionality which is already available via other LSP servers which are likely to be more familiar to non-Emacs users than elisp. ... and of course, all of this is primarily vapourware based on a fleeting thought with no real substance. I would encourage anyone who feels it is worth fleshing out further to do so and the rest of us wait until something of substance exists before debating pros and cons. For all we know, implementation of an elisp LSP server may result in other benefits not yet thought of which could be extremely valuable to the Emacs community. We should encourage such developments rather than discourage them based on vague and unsubstantiated fears.=20