From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#61017: 29.0.60; ruby-ts-mode indents class between two lines incorrectly Date: Wed, 25 Jan 2023 09:22:55 -0500 Message-ID: References: <1a2436ef-ff4d-827c-f22f-33b0737d9b1f@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19409"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61017@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 25 15:24:19 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 1pKghG-0004pz-8E for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 25 Jan 2023 15:24:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pKgh2-0001aY-Ch; Wed, 25 Jan 2023 09:24:04 -0500 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 1pKgh1-0001aL-1y for bug-gnu-emacs@gnu.org; Wed, 25 Jan 2023 09:24:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pKgh0-00063T-LS for bug-gnu-emacs@gnu.org; Wed, 25 Jan 2023 09:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pKgh0-00019D-4n for bug-gnu-emacs@gnu.org; Wed, 25 Jan 2023 09:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jan 2023 14:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61017 X-GNU-PR-Package: emacs Original-Received: via spool by 61017-submit@debbugs.gnu.org id=B61017.16746565954356 (code B ref 61017); Wed, 25 Jan 2023 14:24:02 +0000 Original-Received: (at 61017) by debbugs.gnu.org; 25 Jan 2023 14:23:15 +0000 Original-Received: from localhost ([127.0.0.1]:58696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKggF-00018C-CJ for submit@debbugs.gnu.org; Wed, 25 Jan 2023 09:23:15 -0500 Original-Received: from mail-pj1-f48.google.com ([209.85.216.48]:51998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKggC-00017w-Vq for 61017@debbugs.gnu.org; Wed, 25 Jan 2023 09:23:13 -0500 Original-Received: by mail-pj1-f48.google.com with SMTP id b10so18705091pjo.1 for <61017@debbugs.gnu.org>; Wed, 25 Jan 2023 06:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+v7xGM9v46doeFpCjqqe1vZMyMJNodSMEjfS1MyzO7A=; b=PtWe6bxiboy3JF61F4vPbU4K+/I7sCGx4+FtJqI5KUwPKlyMuIm/7w65LArjlSau8P QjR/tzaROUH/+Y2uJSfnoTEsEvDhTP/z/jqbBqAWvZ4WuhOSKXYxO6pE7FIKScftXnVv LEKQiXUzxglqpA13TjuQpIVcngtwhzEwHbCQ5/v4yy9WesvEG+vpE0gMEp1pG1KpPPCz g1ZLmQF4jUi3rELz+g5ejY/2j6wlcmCWkvB2BDaFuG0mDEwASRw6swoj3eTS7CieTOf6 Y/bVHOmiPv8i+KZyzwcO7K9xkcMGN24ZrzZzEd4hWZcPhnE4qzbYJDjvewtkdTwUrlTG tvbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=+v7xGM9v46doeFpCjqqe1vZMyMJNodSMEjfS1MyzO7A=; b=mX2gqSy+Q/Wf80d+Xk9tA1SCnSWbHvJInuKUhy9UE76CWci17ScejArQiCXk+GjltH 9Agq5HFUUoUjfLP9gu5L0Zfe95DDILoBJdkJgKjaip6HAJhpTAxL01DBeIPfmW76Bjl7 NssP1Eup/FF4pLm6eP492MZWU/aZpb8D93Sd5e66Clic759hYT/w/IW0rmknOJ9B/1nk 9IV3TGD8yOK2MxdhnmDIZg8SRVCO4NhSBrazlRDclcBtNAPANqqi8Z4eViPRf67TOVdE ifsvUGqgKBBkVnll/0CKtw3AjVx40Fi7H4cMtUyP2ubasaCq+J1kXEt53YNhyz5HCpqX E+kA== X-Gm-Message-State: AO0yUKX/DoP/TMgwz/PveNsRXWY09/MxnUyflpiD5PJlfTBMV4NQp1Ra qpmhrHyRiF7Fl/i9KO1op1KYQvQ5JkAcIQ3uN28= X-Google-Smtp-Source: AK7set9LDn06L8rYrLndIJ+iZq2MugKEb9zuGpBDEBBCf2gqySTC7s2+sjuSu0Rph9Z6SU2LFxwgBbHt6K/yq8h9pp8= X-Received: by 2002:a17:902:db10:b0:196:2155:d49a with SMTP id m16-20020a170902db1000b001962155d49amr516927plx.33.1674656586797; Wed, 25 Jan 2023 06:23:06 -0800 (PST) In-Reply-To: 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:254137 Archived-At: On Tue, Jan 24, 2023 at 11:00 PM Dmitry Gutov wrote: > > On 25/01/2023 02:45, Aaron Jensen wrote: > > >>>> Is it enough of an improvement? > >>> > >>> That seems to make indentation after an open def not happen: > >>> > >>> def foo > >>> bar > >>> end > >> > >> Not sure what you mean. Is that an example with an "open def"? "end" > >> seems to be closing it. In the final state, it indents correctly here. > > > > Sorry, that's what I meant. If I do type exactly that and do not > > reindent, I end up with that though (closing with the end does not > > cause the previous line to reindent) > > All right. > > But if the proposed patch doesn't make things worse for this example, we > might as well install it. Because this "unclosed def" case is distinct > from the one you filed this bug report regarding. Sounds good to me. > >>> I applied the patch manually though, so maybe you can confirm that you > >>> see the same thing? > >> > >> If I have a buffer with just the first line: > >> > >> def foo > >> > >> then it indeed doesn't indent. But I think that happens with or without > >> this patch? > >> > >> It's a slightly different problem: the grammar parses this code example > >> without ERROR nodes, like a full method, for some reason: > >> > >> (program > >> (method def body: (identifier) end)) > >> > >> And the end position of the "virtual" end node stays at the previous > >> line, so our code doesn't know it's inside the method. > >> > >> I suppose we could add some tricky predicate like (is the previous node > >> a method with an "end" child that is 0 characters long), but the grammar > >> might change (we should look for any previous reported issues about this > >> behavior, or maybe ones that resulted in it), and it only happen this > >> way when there is nothing after "def xyz" in the buffer. > > > > I wonder if this is mistaken handling of endless methods? > > Those parse to nodes that look a little different (no "end"): > > (program > (method def body: (identifier) = (integer))) > > So I'm not sure. > > > I can't > > think of a reason that it would parse like that. Should that be > > reported upstream? > > I filed https://github.com/tree-sitter/tree-sitter-ruby/issues/234, > let's see if there is any response. Thank you. Aaron