From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: LSP vs Emacs indentation [Was: bug#64784: 30.0.50; Eglot: Lisp error: (wrong-type-argument number-or-marker-p return) in eglot--post-self-insert-hook] Date: Sun, 23 Jul 2023 17:42:16 +0100 Message-ID: References: <87bkg4bkfu.fsf@fastmail.fm> <83a5voa328.fsf@gnu.org> <87h6pw9tpa.fsf@gmail.com> <875y6bm5ut.fsf@fastmail.fm> <87r0oz6i9p.fsf_-_@gmail.com> <87h6pur79c.fsf@thornhill.no> 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="28872"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tassilo Horn , Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Theodor Thornhill Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 23 18:40:52 2023 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 1qNc8a-0007Bz-3p for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Jul 2023 18:40:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNc7i-0007Ot-W6; Sun, 23 Jul 2023 12:39:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNc7d-0007OE-BD for emacs-devel@gnu.org; Sun, 23 Jul 2023 12:39:53 -0400 Original-Received: from mail-oo1-xc34.google.com ([2607:f8b0:4864:20::c34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qNc7b-0004a1-Pp; Sun, 23 Jul 2023 12:39:53 -0400 Original-Received: by mail-oo1-xc34.google.com with SMTP id 006d021491bc7-56584266c41so2194934eaf.2; Sun, 23 Jul 2023 09:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690130389; x=1690735189; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zsdqNEuJvtw/iwgVaBRCL5JCC/mybIQd+AseL7//WAQ=; b=eff5+PZCgDzmXaIpDI94GuQ6XyiPYPmc+W2fzCH8x8LQF+2tzTH0ByFV8p8sYIV3b3 jTF2sKfVLcxE5aBe8xfdUvonO45+NBbWeKxI1RSoNnt2ISsdHXly5jWYtjp1r3x8C3bZ 0R6kEHANMsI4FGvDGXtB4prhojlTZg8iM7oVNte2k8yGm4VX1EcBU5i8hPoLFyG7wkfw m94HCt8/qb0VInNfabJzOyA+e5mIjr8miWOp5l79xog8d110a99MDxMIBQXAB4vak1eg 3onXEloHO3mXupZMUe2I30YXjC++ZTdXwlcex0jMkcr27VKGV9Bp+4wCsurXdo8dbqfI mBcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690130389; x=1690735189; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zsdqNEuJvtw/iwgVaBRCL5JCC/mybIQd+AseL7//WAQ=; b=DlLsCA6XWbtFMKOtbvrM47stp1SnGhmSAN7QjR3L5bA7ZzK4E1FOnJX6OUvI3/0O+o Rm9T4xsP7zoemB0ubTpZO2mj1CS9AtSVHiAGKUDRGu+kl5jL84UpMZ2RGz4gEaxNU8xo wOLmsNldOZSmOR4ffJfxlf3kPAK9Uy+8FYi2t1pN1DUazXrrrltlGvG+1LcJ/+IjuN4D NTDN6qg0um84eyB+QCcRzZm5ta7TD26S+xATviyogydgsYaPp0WMDrb/UMRQmoeDV3kx jNXvIVCnC68lrWMpJbL/Qe/NOg1jCnio8cT5uxM3qQIax+Is1xZZ8RCFQhYW2Nd7KmYD 0Sfw== X-Gm-Message-State: ABy/qLaoeKI0tiZvr84UcRmncXMldJUahSXK0ETQaeLJ2cXupBSZXYCk fiydaClCzL9XgyPmUnksDmySF75bIBjT/e0lhW/SkwbI X-Google-Smtp-Source: APBJJlGuYccO8EAjQqteyMQL70Msuex33y4mfBB7g0mWhaioeo3bWxLkmGf6TKUZkULx5FOXnRj7nUFll/t/94TV9lw= X-Received: by 2002:a4a:2401:0:b0:566:f94f:cd28 with SMTP id m1-20020a4a2401000000b00566f94fcd28mr6610947oof.3.1690130389528; Sun, 23 Jul 2023 09:39:49 -0700 (PDT) In-Reply-To: <87h6pur79c.fsf@thornhill.no> Received-SPF: pass client-ip=2607:f8b0:4864:20::c34; envelope-from=joaotavora@gmail.com; helo=mail-oo1-xc34.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, T_SCC_BODY_TEXT_LINE=-0.01 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308042 Archived-At: On Sun, Jul 23, 2023 at 4:13=E2=80=AFPM Theodor Thornhill wrote: > This is interesting! But for the time being many lsp-servers vary a lot > in their ability to do this properly. Gopls, for example, seems to > handle this very well, in that already has a very heavily enforced > indentation style. Same goes for rust. Java, however, is a different > beast. Intellij has its own indentation implementation that isn't > lsp-available. Eclipse is lsp-available, but was for me almost > impossible to configure in the initializationOptions, as it required > sourcing a file with xml-settings etc. Getting jdtls to format things > like Intellij, which coworkers use, is hard. Similarly, for javascript, > where other tools, like prettier, is used to do this. Sometimes they > allow for a plugin to the lsp-server, sometimes it has to be executed > separately. My point is that getting indentation correct often relies on > factors outside of lsp, or emacs even, making it hard to > configure. So do many other aspects of LSP already. Uniform configuration isn't LSP's strong suit. And as you mention each team/language server usually has its own underlying rule format and, as you mention, sometimes it's not even possible to plug it into LSP. Eglot users of those subpar language servers can always opt for good ol Emacs rules using eglot-ignored-server-capabilities or something else (IMO if a server can't do something well, it simply shouldn't announce it can, and Eglot can just detect that). So right now, I'm not really worried about this: I'm more interested in how well LSP's "format" abstraction meshes with Emacs's "indent" abstractions. I want to find out if we can get a good match in terms of performance and functionality, and I'm primarily interested in "good" servers (gopls, rust-analyzer, clangd,...). IOW, I'm calling on Eglot tinkerers to propose and test something to set indent-* variables to around lines 1870-1950 of lisp/progmodes/eglot.el :-) Jo=C3=A3o