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: newline-and-indent vs. electric-indent-mode Date: Sun, 24 Jan 2021 04:54:10 +0200 Message-ID: <02e60113-66f4-0217-d8c4-abe8cb3bdb6d@yandex.ru> References: <87wnw5yt58.fsf@hajtower> <01d07f6d-cc4c-2f54-4bae-a611bba7be93@yandex.ru> <66b7932d-4cee-9628-fae0-168ee6ebc041@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="5825"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: =?UTF-8?Q?Harald_J=c3=b6rg?= , Emacs Developer List To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 24 03:58:41 2021 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 1l3Vbs-0001Qx-UU for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jan 2021 03:58:40 +0100 Original-Received: from localhost ([::1]:56510 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l3Vbr-0004t4-QU for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jan 2021 21:58:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55306) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l3VXc-0007Xc-NA for emacs-devel@gnu.org; Sat, 23 Jan 2021 21:54:16 -0500 Original-Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:46080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l3VXa-0003R7-KW for emacs-devel@gnu.org; Sat, 23 Jan 2021 21:54:15 -0500 Original-Received: by mail-ej1-x632.google.com with SMTP id rv9so13095599ejb.13 for ; Sat, 23 Jan 2021 18:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wQvQhfbggfEgRPHNusXqW0psiAI5Hdl2ZcwsEBOZi18=; b=uFkn945YKLDrypdsklwWm+g8lZvvV+yA27y09UcT9UjRNcIaQt8KdkRwempa3oa2k1 LhhdTr2aD246OaoXXFCf5fVJFWWwtgNZ7CskPXLAee+5RNwIpaAFyqNkogV/4ILB2v4H iEI+vGMUOqBeib044RgZx79uIRWYvWWydeno3Rq7QtZVtX08mc34f0AhCmTMnqQUJ893 Ga4mrsv34t1CXIZH4SGcnTbY+H74ONM6fW1ESY0GULK6AdExa96Jze1se6bRz4hp9DdZ ire0h9HVYUbHAJaIDW8a37awOqcTgo9ydX6+dzZuQxjTF+lCyHmvvGnCIsdw+aXO294a U/XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wQvQhfbggfEgRPHNusXqW0psiAI5Hdl2ZcwsEBOZi18=; b=bNgQYD+Zey8JKXal4zHzDeE4Wpk7vsMeXA4+V6HB4Jr208cJ3kj9P7kQsWDfxbfCsg 98voO+ynNoRzmn0ZMbt59HuqzpSRLyKSJromVQqiBMxMaKYNdaG6imRHwHpzytqDRcAE 5QtIk1jwmsbZHiShy6gwkYg2ovcMsKEpPaEjnoJrzY1cMh0kUroHl6VGUHiLQkCS1168 xV7X7jeOKnpNAnHC4Cu3fJR3feZbA5+WvFP19cftkc+4XFFR3XjsUfDn93dAxjxSQrWo lyx+Ycvf9I3/dDpUjyf283SpyCwqqsu5oXe2Hp9EJNrQjZTCuP5tiEfFKa/92sB0ItCe Jlng== X-Gm-Message-State: AOAM5326TgS6X5T3bMt9TPEn6zy6D0imDx2bv9n7SKimcnNmfDDqD3I+ DFFtkCX7USq8oYAxd4HJ9W6SnbffbgI= X-Google-Smtp-Source: ABdhPJzEgrCT9QrRGi+Mc9tjEz8amIyJnnL4lHfIikZpqUcW+E9QNuleNhAw6X+FmrSVs0Z4FiHm/A== X-Received: by 2002:a17:906:4893:: with SMTP id v19mr1486571ejq.454.1611456852954; Sat, 23 Jan 2021 18:54:12 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p15sm5090603ejx.109.2021.01.23.18.54.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Jan 2021 18:54:12 -0800 (PST) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=raaahh@gmail.com; helo=mail-ej1-x632.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 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.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:263328 Archived-At: On 23.01.2021 05:16, Stefan Monnier wrote: >> I'm not sure how it is a bug. It's "reindentation" in both cases, right? >> And electric-indent-inhibit's docstring refers to reindentation. > > But with the current behavior, a char other than \n into > `electric-indent-chars` can never have any effect when > `electric-indent-inhibit` is non-nil. So I'd argue that a char other > than \n should take precedence over `electric-indent-inhibit`, > especially because such a char can only be there if it's been > explicitly added. All right, filed as bug#46064. I suppose of a user wants to have those over vars not have effect, they can set those to nil in the major mode hook. >>>> It's just that in my mental model \n doesn't belong to the current line, >>>> only to the next one. So it shouldn't reindent the original line. >>> It's often useful for me, as in typing >>> foo RET else RET blabla >>> where the else benefits from being reindented upon the second RET. >> I see. Well, ruby--electric-indent-p covers this scenario already. > > Indeed, this approach can work as well. > [ BTW, here's another one where ruby-mode is saved by the reindentation > done by `newline`: foo RET endl DEL RET ;-) ] This one can be also solved by 'undo' instead of DEL, but yes. >> Perhaps your approach is simpler, but always reindenting the original line >> gets annoying if the indentation function sometimes produces suboptimal >> results. > > I think `electric-indent-mode` is annoying in any case if the > indentation code disagrees with your style. True, but my present complaint is about it being annoying *twice* for the same line. And if it's being annoying while point is still on that line, it's marginally easier to fix. > There are lots of knobs to > play with deciding when and were indentation happens, and it's hard to > know what the statistically optimal heuristic. So I won't try to argue > that the current choice is best, but I think it's equally hard to argue > that some other choice is best. Agreed. > If we could automatically detect when a reindentation is immediately > undone by the user, maybe we could collect statistics. That might help with indentation defaults (if the statistics is sent back to us somehow), but not with specific cases, I think. And the indentation code has to be capable of producing the needed indentation patterns, at least with some values of indentation-related options. >> again, or undo the change and go with C-o C-n TAB. > > I think `C-j TAB` is quicker (but I must admit that my muscle memory > often makes me do `C-q C-j TAB`) Oh, right. In the meantime, I'll try running with RET bound to newline-and-indent, like in good old days.