From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sat, 23 May 2020 21:47:40 +0300 Message-ID: <9e1a8e49-269e-6b45-ed86-98ea188528a5@yandex.ru> References: <96bf0b6e-3559-ed02-5596-6a6642188309@yandex.ru> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="1535"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: Richard Stallman , joostkremers@fastmail.fm, emacs-devel , "Alfred M. Szmidt" , Stefan Monnier , =?UTF-8?B?7KGw7ISx67mI?= , Eli Zaretskii , Phillip Lord To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 23 20:48:31 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 1jcZCA-0000Hq-Q5 for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 20:48:30 +0200 Original-Received: from localhost ([::1]:59282 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcZC9-00085T-Rl for ged-emacs-devel@m.gmane-mx.org; Sat, 23 May 2020 14:48:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcZBT-0007dx-4r for Emacs-devel@gnu.org; Sat, 23 May 2020 14:47:47 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:37641) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcZBS-0004jy-2N; Sat, 23 May 2020 14:47:46 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id l17so13517682wrr.4; Sat, 23 May 2020 11:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kLeVFoHrTeiv+W8wmnUKkp6VRX0hor8FeCc923jl6FA=; b=Cg7ydaAKCBLaVot+VsBagqafSWPBpSRO1sE4WKjycRN7wfBBZypNMnlRPBGvkQW0kx FnXWoUyQbxyEgRN1BEIwThR0jQXZc4pEVqdkyYH+rCBtl4ERKWlms1X9qH/ZCxGDZONg 5IU6iA2X3giOeSoa4vNzJtRC1iBfoJ+cA6UF60h6aAMW7dnty3ywWfz3ojL8RMFCryLs x5fRyE9Nkt0DuCTxQtK08am+c1yJg3Y/4qZc/ghCQ1j41uPvBZuQ6me47+gPqtV06X0U 1puABauKuR/EBl6eLv7wudVfZKKEGDW3cPNRKz1Mo0DqlSIE55pmnrv4kAW9PE18I64z 84VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kLeVFoHrTeiv+W8wmnUKkp6VRX0hor8FeCc923jl6FA=; b=F4qMl+ueQP/hSHySshwqFgCfkNCwNeBw3t/Hw/KDaOoHR8dWFxGC3jhxgORR3gB3co a2gy8La6WpGOmdcVPsY9WQNszCV9lJiZFFXMsS7ADz0OOazfh1xrzBaxEqPcF+ov2Xr7 mRmKypibzatCjhLRQQWfpUIR75ueokRFzTToL+/mCPGJTbhYZ3OOpCpwhhtuxSPEvxdz LmmV08XtGkco6nXFt9hLaG8NB1OEaJxCBC8lm6ocr3RuVJTMtCJJl4/zXws+vBrdvBzR KTHRk6oS/PvUlQqKYTPWPPI30nRh98rsjAnSK2VNzumx1Dj11aGsMneeVeFUsZgD6ZdY YSVg== X-Gm-Message-State: AOAM5338CCLWl2b2tKmBCE1hDqd3HALliiJGUVlMPKMTGVerLNG4Ur4N Wj6uwH9D/r133h6AiRaxzXjq79P9 X-Google-Smtp-Source: ABdhPJzg3Owikc/4x7+az3ouL3O9XAP9HGkrc2gZaXCW5leQcoZf6RFGumSm089xU99xUwhJ0Ews6w== X-Received: by 2002:adf:9264:: with SMTP id 91mr8065006wrj.362.1590259662877; Sat, 23 May 2020 11:47:42 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id c143sm13477756wmd.43.2020.05.23.11.47.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 May 2020 11:47:42 -0700 (PDT) In-Reply-To: <87eerbwk6n.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=raaahh@gmail.com; helo=mail-wr1-x434.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: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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:251285 Archived-At: On 23.05.2020 03:48, João Távora 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. >> 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". All right then. >> 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 mode authors and the LSP ecosystem. >> 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 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. >> 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? https://github.com/emacs-lsp/lsp-java/#supported-commands Here's some other stuff that seems unlikely to be in the spec. FSharp-specific settings and notifications: https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-fsharp.el Metals specific notifications and commands: https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-metals.el > Else we're just speaking in the abstract, you trying to convince me that something somewhere someday is not going to work. I'm not saying it can't possibly work, just that it looks suboptimal, given existing development trends and areas of responsibility. And I'm not crazy about the increased coupling to major modes.