From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: treesit indentation "blinking" Date: Mon, 3 Apr 2023 23:58:17 +0300 Message-ID: <17c4d854-91b2-f221-e6e5-79056d427376@yandex.ru> References: <83jzyy4776.fsf@gnu.org> <9F152CAA-6326-459F-84FF-87988B3A92B6@gmail.com> <6bf0322b-1151-129a-e26f-61cf4f232d17@yandex.ru> <6efb9f84-211d-560e-3196-95d7f0b8be19@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28975"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Yuan Fu , Eli Zaretskii , theodor thornhill , geza.herman@gmail.com, Daniel Colascione , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 03 22:59:10 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 1pjRGg-0007PN-HK for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Apr 2023 22:59:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pjRFw-0007Kq-ND; Mon, 03 Apr 2023 16:58:24 -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 1pjRFv-0007Ke-Fj for emacs-devel@gnu.org; Mon, 03 Apr 2023 16:58:23 -0400 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pjRFt-0001tU-8e; Mon, 03 Apr 2023 16:58:23 -0400 Original-Received: by mail-wr1-x42e.google.com with SMTP id v1so30709166wrv.1; Mon, 03 Apr 2023 13:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680555499; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=usnxr0HCm9Gx2yR2GXePPASfEU46eRB9O6RtR8aRpAs=; b=NsRGUHy6UYvpgKgIkGxUJ+HUy2ue9c8N2bo5meLPz+uvjMGVXzLd02auyHSR5wo7AO VWUerOHFPvES3dM4ngvHx0bGXigoXvR7s/DXOFGkLTnhV0XI6DhQgRLviO00sa0CgzWF 5Lna6AkvPUTon2I10laLhXHKhZZyDdb4jcfQvvqZyLEpS5nlOcN0FZBnHiRyNifxmgyp YA7c51kHLOVmCp37mxYBdT2FK+gp6NgbHAfie4Tu1yqUSs0rO/+7wiFig6KjjsMdAw4e j1+UtkiyNw7bhnjKaQnsHQ4Q+P/C9qIbP106NWHz2FTxiM/QlWUmhNrbaQBFIWwWoErm dROg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680555499; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=usnxr0HCm9Gx2yR2GXePPASfEU46eRB9O6RtR8aRpAs=; b=1tT/IxzHtdD/CyX1P+zhbrsIyx+D1vvdjb1ekqEHAlh6pt/bLJMUYhKtHPXrnbTFyc RI2Pvdz/O7MLZeS1WzpjbykUHdF6L/GbzcbEbsb8sn6sgirIKovBjSKk+a24WmyCGrHI rh3oKZIQjLDCoQptOSqbxxE/W79wdf4RP3FzOCPHqfbRRcjBpEXSACmG2PlOYDUP/0Kh 0zedOk0PmzldS7vUPxZ2iL1pXGKvAvCVUAPpuxwOb1wFiHDmz+rOMIe1vCURD4iHKLBK Q14CfmL3YBZ6fi6vK1QBjaOsggawaFkmTL1fdxiOmD4JTSr5cYDKWFBFapYJmemkWwJs FI5w== X-Gm-Message-State: AAQBX9fMji6dPOgGPriyo7NBT66NGdymCxaf4KY1+SrqLfXSXmGXLtgR BvJg7Brex977ny+bgD5pFeo= X-Google-Smtp-Source: AKy350asmaz/YVOz8/pSMnAvGH9RWNukrWUymp1V8EWNaHI/DEoZ8ueNz7/cTi8vEgpmkDLs8ItLFA== X-Received: by 2002:adf:eec5:0:b0:2d0:3584:27d with SMTP id a5-20020adfeec5000000b002d03584027dmr27580306wrp.29.1680555499107; Mon, 03 Apr 2023 13:58:19 -0700 (PDT) Original-Received: from [192.168.1.2] ([31.216.80.60]) by smtp.googlemail.com with ESMTPSA id u13-20020adfeb4d000000b002daeb108304sm10569786wrn.33.2023.04.03.13.58.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Apr 2023 13:58:18 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42e.google.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-1.349, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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:305085 Archived-At: Hi Alan, On 03/04/2023 15:56, Alan Mackenzie wrote: >>> That is NOT electric indentation. The whole point about electric >>> indentation is for it to take effect whilst point is still on the line >>> being edited. Thus, for example, you can see whether or not the line >>> needs breaking, or whether there's room for a short comment at the end >>> of the line. > >> Wouldn't you know whether the line needs breaking, as long as the line >> was indented correctly when you opened it with RET? > > Maybe sometimes, but often not. I think it's the exceptions that are relatively rare, mostly labels (goto and switch/case). I'm no C++ expert, though. >> This is not a substitute for enabling electric-pair-mode, alas. > > As you've no doubt gathered, I particularly dislike electric-pair-mode. > I'm likely far from rare in that respect. I think we'll be doing our > users a disservice if indentation only works when e-p-m is enabled. Be that as it may, improving the state of affairs looks difficult. It will likely involve taking part in C and C++'s grammars development, and even then full success is not guaranteed. I've tried to make indentation's behavior better in ruby-ts-mode is similar circumstances, but the sole difference between it and c++ indent rules is that is has a "catch all" rule which, for code like def foo if asd , does indent 'if' one level. And Ruby code is usually more nested anyway. Also note that the C++ example starts working much better as soon as there is at least one closing brace, e.g. int foo() { for (;;) { | } because in this situation both the declaration's bounds and the for node's bounds are more or less easily determined. In practice, it should mean that as long as the top-level definition is "closed" (perhaps manually, without electric-pair-mode), you can type inside an enjoy much better auto-indentation. Although maybe some exceptions will remain still (some further research could be useful). >> I would also prefer c++-ts-mode supported indentation with closing >> braces missing, but we're really limited by what the parser provides. >> E.g. for this code > >> int foo() { >> for (;;) { > >> we get this parse tree: > >> (ERROR (primitive_type) >> (function_declarator declarator: (identifier) >> parameters: (parameter_list ( ))) >> { for ( ; ; ) {) > >> where the "for" statement isn't even present (the separate tokens are >> parsed as leaf nodes, and that's it). It's difficult to write meaningful >> indentation rules that would match this. > > Why do we get a parse tree with ERROR in it when the source isn't > erroneous? It is merely incomplete. It is incomplete and hard to make sense of, apparently. But perhaps someone could contribute improvements to the parser that would make things better. > Tree sitter was surely designed for > editors, where source code being entered is typically incomplete, not > just for things like code formatters. Why do we not get a full valid > parse tree indicating the current (incomplete) state? The parser's tolerance has limits, aparently. But see my latest example: that code is still incomplete, and yet it parses much better. Most code editing is additive, rather writing functions from scratch. So I'm guessing it might work out, most of the time.