From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs,gmane.emacs.devel Subject: bug#64784: 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 11:20:50 +0100 Message-ID: <87r0oz6i9p.fsf_-_@gmail.com> References: <87bkg4bkfu.fsf@fastmail.fm> <83a5voa328.fsf@gnu.org> <87h6pw9tpa.fsf@gmail.com> <875y6bm5ut.fsf@fastmail.fm> 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="1893"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 23 12:19:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qNWBN-0000Gf-Gz for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Jul 2023 12:19:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNWB5-0006zu-8k; Sun, 23 Jul 2023 06:19:03 -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 1qNWB4-0006xX-6p for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 06:19:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qNWB3-0007gC-Ut for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 06:19:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNWB3-0000qx-Q8 for bug-gnu-emacs@gnu.org; Sun, 23 Jul 2023 06:19:01 -0400 Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sun, 23 Jul 2023 10:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 64784 X-GNU-PR-Package: emacs Mail-Followup-To: 64784@debbugs.gnu.org, joaotavora@gmail.com, thorn@fastmail.fm Original-Received: via spool by 64784-done@debbugs.gnu.org id=D64784.16901075053231 (code D ref 64784); Sun, 23 Jul 2023 10:19:01 +0000 Original-Received: (at 64784-done) by debbugs.gnu.org; 23 Jul 2023 10:18:25 +0000 Original-Received: from localhost ([127.0.0.1]:38486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNWAS-0000q2-Hd for submit@debbugs.gnu.org; Sun, 23 Jul 2023 06:18:24 -0400 Original-Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:60900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNWAP-0000pm-Sb for 64784-done@debbugs.gnu.org; Sun, 23 Jul 2023 06:18:22 -0400 Original-Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-3fbc656873eso32075705e9.1 for <64784-done@debbugs.gnu.org>; Sun, 23 Jul 2023 03:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690107496; x=1690712296; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=dItGQZ1vdYjpMFy0H/XUmQm60fO5sD5ZWsulJDKy1/o=; b=VLWE10AuIbqaBWxEikajCGz0eYW8eT4/yrNPB6g6XLIaWYS4JOwiJFJIWi/FVtb2x/ Km+mnSRdfYYb44kr8D4hqSec9ZuH41SZ+r1cXuDvHrxt77Zf3hu7+RfRcxbRxTu3OpOG jxlKkI8BzBN7rvfxz9HSYNrk3K/2iHVjp6+pD5DkDvZLyTx1jHzcoP0EhDeDRYK3U9yE rPlkY2HXJltUNwWutKyXVQn0EYHcEtKiLo1ki6OnNE0wrELuh9e8Kb08slt5q+mUvTxw /vk/EcU79/a+uFMOaJckabdO0lrQz4oqI4MgGjwVa3BNfQmtbXoicZWS+880RxSFn3NF zSIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690107496; x=1690712296; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=dItGQZ1vdYjpMFy0H/XUmQm60fO5sD5ZWsulJDKy1/o=; b=dvu7ekz6EBCfL1LMrH8W810pnycz0KOqWJtUqINqjaJfOkWV6FyBIRsA92BuxlMVLC Ku8QSUFkwiFRVtW775O9C4j8ZhM0q0CTWyyHeaPrJGLNEOPFqrCaCy39qvROY5pEyxMr jEUqfnUAw0Y4b3ek+zp6f0OAOspF0567jk+VT/A46IG+6eD/wJAltAtId92DC54ZIf0X QPLtkqqbZrZ/8YCtzSyOqkkp1qDGac7yjXYH7NldFwQbgMhb/jnGrbGRD76dOVAEc3xr +BDyn1ct4JTP6amrKBsP1R6t4LFk6X0dPua3Ud5Kg0sP42UeVOKnfqrN2Jh5WXUMv3Oc FPRg== X-Gm-Message-State: ABy/qLZutELosmr4B1m1ScEvRkdo2RK4auGPaTqpgDIstF3h4AVQKjME b++15GNeMSavMVwVAyuCQR3mszlOPqg= X-Google-Smtp-Source: APBJJlHx/ZDdyec1mMk5DwZOYiKg8OG7GsOfRdBlcY02Z1a9Bl0l76x+wYySDXaQo3iagqG8wm+v4A== X-Received: by 2002:a05:600c:21c1:b0:3fb:e254:b81e with SMTP id x1-20020a05600c21c100b003fbe254b81emr5294955wmj.12.1690107495545; Sun, 23 Jul 2023 03:18:15 -0700 (PDT) Original-Received: from krug ([87.196.73.34]) by smtp.gmail.com with ESMTPSA id w3-20020a05600c014300b003fc05b89e5bsm7171993wmm.34.2023.07.23.03.18.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Jul 2023 03:18:14 -0700 (PDT) In-Reply-To: <875y6bm5ut.fsf@fastmail.fm> (Tassilo Horn's message of "Sun, 23 Jul 2023 09:21:54 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265885 gmane.emacs.devel:308029 Archived-At: 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