From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sat, 23 May 2020 22:27:39 +0100 Message-ID: <87k112uyt0.fsf@gmail.com> References: <93a7bb1c-390f-440f-02cc-6cce39ea9431@yandex.ru> <87k1175sl3.fsf@gmail.com> <2a43cea0-8e00-3c22-3ddc-eff29fc9b2db@yandex.ru> <87d06y4kze.fsf@gmail.com> <712d7134-b8ef-b843-bb20-152717092497@yandex.ru> <87367s1bxu.fsf@gmail.com> <90325e25-7a44-0068-9294-91afda7ed953@yandex.ru> <87pnawyr9t.fsf@gmail.com> <87mu5zyctg.fsf@gmail.com> <58e1a8c7-59a7-b9dd-7260-726d3e137927@yandex.ru> <871rnby0kz.fsf@gmail.com> <89cc0eec-ebaa-1605-9f10-52fdf7140322@yandex.ru> <87eerbwk6n.fsf@gmail.com> <9e1a8e49-269e-6b45-ed86-98ea188528a5@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="912"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: Richard Stallman , joostkremers@fastmail.fm, emacs-devel , "Alfred M. Szmidt" , Stefan Monnier , =?utf-8?B?7KGw7ISx67mI?= , Eli Zaretskii , Phillip Lord To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 23 23:28:25 2020 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 1jcbgv-00006l-0o for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 23:28:25 +0200 Original-Received: from localhost ([::1]:55588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcbgu-0000eE-36 for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 17:28:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcbgJ-0000D1-8C for Emacs-devel@gnu.org; Sat, 23 May 2020 17:27:47 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:47016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcbgH-0005Pf-OR; Sat, 23 May 2020 17:27:46 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id x6so101487wrm.13; Sat, 23 May 2020 14:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=vUdsYWjetQ23GQdmAXKmvs/8VIhA6GKJp3GM15tsIoI=; b=JPQX+KFkzwqWq1vKJXYR0imjSQ8haD1yndR7mN7FA5pQPB5TVb3d8hB4aNFGss4RLF uab2d0Ldg50BNZkz6dv3mB9Rol3CN5AJVBIPtXAdzMInUWTFBCVtM2F7+ncb4hX4HvYC K+25mQSXtsJxS4CZf/ht9PkCXlnEZob8Ng+kIPUwnmxWRHc4QEXYhiUYd2OlydbyJ/tL d7mMG4H/bEalRDRysKniQ+0m2shr6xe8fae94iGCTZkbJdoJMzvGLH9LVTgjNMyzTQvC 0Mu75IJAe7FfMAHdr2q/vsH+iQrKEMFq0RjP2pcfOxsqx3Z+y0pwcC55JJSEhaAdf9R4 xBNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=vUdsYWjetQ23GQdmAXKmvs/8VIhA6GKJp3GM15tsIoI=; b=fcluXhrIIxhDMSit6Jz4zcTO6FlsIkgt9PB2oqwFTl+MU6klCHRkIA/3+p1LEe775t 9+S707lv+/mHhMB/I62Ne+xffHYxzWJk9ELhgPscK1M/bMugMu5jcelbUxiuCbzYeF0N zVcpdEzrIkrwlDeGhbRZO04qsI93R/hzXYRENBL66RKWgqFYma1E8IRW436s4xhVri6O NDIjZfESBRRJjVoPwvuogGPmUtVL97HW2mNiTuvv3xj81+yAuz5QL5NR2oOAZI326RpW j/DvCKNOXuRFox6AOiUYr7tn3RnYCP+gj2RLfygK+elDGEXwOKOXYMEs2KZl0hqIjzSK mdmw== X-Gm-Message-State: AOAM532sEBUMd9+IxqoUu9rAzG0pNlP1Wp2k2N09SO8LwZvtUbIRXET0 +/w5z/Ypu9zFCfE4pEeDcrdZFuPqizXjcg== X-Google-Smtp-Source: ABdhPJxq2SV+jLQhMqZaUInx0EAzcyLsqNFivNx5MzU5kIvt756Tcl9ycxfXFvwUwdSgdeAox4FsLw== X-Received: by 2002:adf:fe45:: with SMTP id m5mr8344142wrs.257.1590269262161; Sat, 23 May 2020 14:27:42 -0700 (PDT) Original-Received: from krug (89-180-159-150.net.novis.pt. [89.180.159.150]) by smtp.gmail.com with ESMTPSA id a15sm1114888wra.86.2020.05.23.14.27.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 May 2020 14:27:40 -0700 (PDT) In-Reply-To: <9e1a8e49-269e-6b45-ed86-98ea188528a5@yandex.ru> (Dmitry Gutov's message of "Sat, 23 May 2020 21:47:40 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::42a; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42a.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:251289 Archived-At: Dmitry Gutov writes: > On 23.05.2020 03:48, Jo=C3=A3o T=C3=A1vora wrote: > >>>> Some major modes might even automate the second step, if it's cheap. I >>>> know people really like `eglot-ensure`, which that starts up a server >>>> automatically. >>> >>> It's less "integrated" than what that other mode is doing. >> I don't see how. We must be talking about different things. I'm >> talking Emacs -Q, C-x C-f foo.xxx RET and xxx-mode kicks in, sets up and >> maybe even starts Eglot. For that to work, xxx-mdoe has to be in core, >> otherwise you need M-x package-install xxx-mode > > *And* you need the author of xxx-mode to participate in the scheme. That has nothing to do with "integrated" as in IDE. One presents a patch to the author: if he doesn't want to participate in the scheme, then he doesn't want to, period. But it's very unlikely, since there's no downside. It's like not wanting to participate in, say, keybindings or font-lock. Even Alan agreed some lines of flymake stuff to go into cc-mode.el after understanding they weren't going to explode. >>> So worst case scenario, people will point out that Emacs core has >>> released something not entirely complete while there is a package with >>> all batteries included. >> You're saying this becasue rust-mode isn't in the core and/or GNU >> ELPA? >> Than it's not a problem of Eglot/LSP at all. > I'm talking about user perception, you respond with "not a problem". Let's stop this silliness. I wrote: _not a problem of Eglot/LSP_. How could it be? If Emacs doesn't have rust-mode out of the box, you can't use rust-mode out of the box, with copious apologies to users and their perceptions and everyone other reader having to endure my statement of the very obvious. >>> Again, examples of much simpler programs. And historically stable. And >>> Rubocop has its own, well-documented configuration interface (text >>> file) that's expected to be edited by users. >> Don't see any reson why an LSP server would be some kind of >> second-grade >> delinquent program. > > I integrated Rubocop because I'm familiar with it, just like almost > every Rubyist. I don't imagine we could say the same about all major=20 > mode authors and the LSP ecosystem. They don't have to be familiar with the "LSP ecosystem" just a particular program and its invocation. The newbiest of users can help there, it's trivial to setup. You're totally off in this: Eglot supports more than 20 servers (yes, it supports more than are listed) and the majority most of them work very nicely without any customization. >>> And of every major mode author making the effort to familiarize >>> themselves with this stuff, apparently. >> Same with font-lock and imenu and eldoc and forward-sexp-function. >> Mode >> authors needn't familizarize themselves with the protocol, only in some >> cases with the server program they're setting up. Like rubocop. > > The font-lock, imenu, eldoc and f-s-f provide extension points where > the extensions can basically indulge in unbounded levels of > creativity, support various languages, frameworks, libraries, and so > on. > > There's literally no possibility to contain that all in a file shipped > with Emacs. *And* a significant portion of these extensions out there=20 > requires knowledge and experience that the authors of these extension > points do not possess. They only needed to create flexibility. > > The situation with LSP is different: the total creativity is limited > by the LSP protocol, and the extensions will be pertaining to LSP > server settings, if I understand your examples so far. Yes, so you're making my point. The things that go into the major mode are usually minimal, usually little more than setting the value of `eglot-server-program`. But those minimal bits do belong there. >>> You might be forgetting that Eglot doesn't exactly support _all_ the >>> features that languages servers offer. At least, that's my impression >>> of your answer to the question about refactoring actions. >> Eglot supports refactoring actions. Commands and renames and stuff >> . I >> don't know what where you want to go with this. Give an example. If >> Eglot doesn't support something we can add it. LSP works by >> "capability", what capability are you exactly referring to? And not all >> servers support the same capabilities. > > What about Java development? Does Eglot provide all capabilities > included in the "LSP Java commands" section here, in some shape or > form? Eglot supports LSP, the Language Server Protocol, a mechanism whereby editors don't have to care about the specifics details of a language. We don't support language specific extensions, but we do support an API for major-modes or users to enter into that business if they can't select a better server or work to improve the protocol. If you have a specific thing would like to be able to do, I'm more than open to hear about it, but shoving some lsp-mode files here to make me hunt its bloat for dubious language-specific features of servers that I don't use is not my idea of fun. Eglot was designed specifically with certain ideal of Emacs in mind, one you're totally free not to agree with. Goes like this: major modes customize little bits of minor modes and other infrastrcuture to assist them in their work. I see Eglot as LSP infrastructure much as font-lock, imenu, syntax, flymake, you name it. I will only do the -.el dance as a last resort, (cf. flymake-cc.el), when it's hard to communicate with the major mode author. But my starting position assumes it won't be difficult to do so, because that's how my ideal of Emacs is: open, collaborative and proven good stuff goes where it needs to go. The fact that Eglot started of as a separate package was purely intrumental: I needed to test some ideas beforehand and convince myself and the world that such an approach was possible. I'm sorry if you're not convinced (or only half-convinced). I think it would help if you actually tried it a bit and collected some actual problems or ideas. > I'm not saying it can't possibly work, just that it looks suboptimal, > given existing development trends and areas of responsibility. =20=20 Sorry, but that sounds a bit like generic managerial talk, very little juice there. Bring real problems to the table. Bring something of the form: "I was trying to this and that with eglot.el, but then this dragon appeared, how do I slay him?". Bring that to the issue tracker. I don't think your worries about major-mode authors being burdened, or too many emacs-diffs emails, or confused users, hold much water, frankly. The idea is for Emacs 28 to have good LSP support in the core, and I'm encouraged to see some support for that idea. Incidentally, there are much larger challenges with LSP such as arguing for a more inclusive spec -- which is the whole point of LSP. Perhaps you could cast your energy and theoretical concerns in that direction. I'm signing off this sub-thread, there's nothing more to add here, you can have the last words/make your final arguments. Jo=C3=A3o