From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill 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:13:03 +0200 Message-ID: <87h6pur79c.fsf@thornhill.no> References: <87bkg4bkfu.fsf@fastmail.fm> <83a5voa328.fsf@gnu.org> <87h6pw9tpa.fsf@gmail.com> <875y6bm5ut.fsf@fastmail.fm> <87r0oz6i9p.fsf_-_@gmail.com> 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="3942"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 23 17:14:22 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 1qNams-0000sv-Bo for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Jul 2023 17:14:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNalv-0008Mr-Aj; Sun, 23 Jul 2023 11:13:23 -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 1qNalt-0008Mi-HV for emacs-devel@gnu.org; Sun, 23 Jul 2023 11:13:21 -0400 Original-Received: from out-63.mta1.migadu.com ([95.215.58.63]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNalr-0005kF-GU; Sun, 23 Jul 2023 11:13:21 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1690125193; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nQWGUhKoWVC2tUon/ebEbkAvMZ5E8kvsyvZqaQ9/QUw=; b=hAWEgJqWRIAKwierugSUWKjPXKPs76Ud0mjdnmRqCYQOWZ6PJKqAidZMENV4yZbRYuUqiQ 7YOiGA3v4nqi/DM5XTLhCvZjOnyQIzAlqx55+u3tEQU1seBhGXZreIZsar5peFbMXiHEad lsspyWthLGmJvIZJHGTbCgcbWCgupAd1kP+nTKoLfJ2xtRRliR/hk8IzVdMd1ypoyGd4rd QjDfe6FV7Zag+MSlI+NXHxsQ+m4/YkfkT6NQDu8gHkPivhEZ3vL4vMJoIch8oNFSfqpWu9 +N/F/E0lGi9NZWkB72nFL3ejTTfyfY/aPYqFMWFztKocB8y2ZnUQh+2VlX/wYQ== In-Reply-To: <87r0oz6i9p.fsf_-_@gmail.com> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=95.215.58.63; envelope-from=theo@thornhill.no; helo=out-63.mta1.migadu.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:308041 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > Tassilo Horn writes: > >>> Tassilo, can you test? >> I can say at least that the error is gone. Thank you! > > In that case, I'm closing, but we should keep chatting because this > matter interests me as well. In fact, let's move this to Emacs-devel. > >> So is there a way to stop the indentation wars [between LSP and Emacs's]? > > There's quite a bit of overlap in indentation functionality, yes. For > example, in non-ts c++-mode, there are a lot of indentation knobs, and > they can probably do all this. But configuring them is difficult (for > me), and I'm not sure I haven't seen at a bug or two. In practice, I've > accepted I'll never get them to match my team's .clang-format > completely. > > A way to "stop" the war is to get one of the sides to surrender. To > make the LSP side lose, just add symbols to > 'eglot-ignored-server-capabilities', like > ':documentOnTypeFormattingProvider'. > >> Maybe if I could make it so that return and tab would also be >> considered as trigger characters for eglot-format? > > If your aim is to make the LSP side "win", I don't think you should use > the "trigger character" technique specifically. But in Emacs you can of > course bind keys to commands that invoke 'eglot-format' synchronously. > > Even better, I think the most correct way is to buffer-locally set > 'indent-line-function' and 'indent-region-function', so you can keep the > familiar feeling of TAB. > > I've tested this: > > * Setting 'indent-region-function' simply to 'eglot-format' apparently > works. (Not in cc-mode, which has a tendency for wheel-reinvention. > Or who knows original invention... but in any case it's probably time > for me to move on to c++-ts-mode) > > * As to 'indent-line-function', there's no Eglot command that's exactly > compatible with the protocol, but it's pretty easy to make one: > > (defun eglot-indent-line () > (eglot-format (line-beginning-position) (line-end-position))) > > After setting 'indent-line-function' and 'indent-region-function' like > this, things seem to work well at first. But simple things like RET > ('newline') fail. I haven't investigated. Maybe it's becasue of > electric-indent-mode? Or maybe just because of the fact that > `eglot-format` asks the language server to do more than just indenting, > namely it also inserts newlines. Or maybe I'm just not passing in the > correct range. > > And then there are the annoying messages in the echo area about edits > successfully applied, but that's easily solved. > > I hope you (and/or others) can give this approach (or variations > thereof) some testing. Maybe with other LSP servers and/or style files. > > The reason I find this interesting it that it would IMO not only solve > the indentation wars, it solves fundamental problems of limited-context > indenters such as c++-ts-mode. Consider the C/C++ textual preprocessor > macros: probably no tree-sitter mode can know exactly what they mean and > how to indent the surrounding code, but a sufficiently smart > project-knowing LSP can. > > Are there drawbacks to this "LSP-wins" approach to indentation? > Probably. Chief among them LSP is very slow when compared things in the > same address space, like an Elisp function or a dynamically linked C > library. > > My early impression is that this fact almost certainly matters for > LSP-driven fontification, but not for indentation. > > In summary, if we can get a successful approach that feels right for > Emacs users (mostly regarding TAB, newline and region-indenting), maybe > we can enshrine LSP-powered indentation in Eglot-managed buffers just > like we do for Xref, Flymake, Imenu, etc... > > Jo=C3=A3o (I haven't read that bugreport yet, sorry if this has already been discusse= d) 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. VSCode offers a settings-ui for much of this, which writes to its own settings.json (or something like that). I'm not sure how such a configuration would look for emacs, but I'm sure it's possible. Theo