From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#30393: 24.4; cperl-mode: indentation failure Date: Sat, 10 Feb 2018 11:26:54 +0000 Message-ID: <20180210112654.GA4537@ACM> References: <20180208152552.GL13340@hodi> <20180209175040.63536.qmail@mail.muc.de> <3331f80a-c5aa-5cb9-8088-0a88888bdaca@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1518262602 22875 195.159.176.226 (10 Feb 2018 11:36:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Feb 2018 11:36:42 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Noam Postavsky , Stefan Monnier , 30393@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 10 12:36:37 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekTRz-00049k-OC for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Feb 2018 12:36:11 +0100 Original-Received: from localhost ([::1]:58002 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekTU1-0004mX-7p for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Feb 2018 06:38:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekTTq-0004jc-SE for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2018 06:38:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ekTTm-0005xD-O7 for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2018 06:38:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56481) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ekTTm-0005x5-JG for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2018 06:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ekTTm-0006OQ-Cc for bug-gnu-emacs@gnu.org; Sat, 10 Feb 2018 06:38:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Feb 2018 11:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30393 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30393-submit@debbugs.gnu.org id=B30393.151826266224548 (code B ref 30393); Sat, 10 Feb 2018 11:38:02 +0000 Original-Received: (at 30393) by debbugs.gnu.org; 10 Feb 2018 11:37:42 +0000 Original-Received: from localhost ([127.0.0.1]:36145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekTTS-0006Ns-8b for submit@debbugs.gnu.org; Sat, 10 Feb 2018 06:37:42 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:10250 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ekTTQ-0006Nj-9L for 30393@debbugs.gnu.org; Sat, 10 Feb 2018 06:37:40 -0500 Original-Received: (qmail 11634 invoked by uid 3782); 10 Feb 2018 11:37:39 -0000 Original-Received: from acm.muc.de (p548C6FC0.dip0.t-ipconnect.de [84.140.111.192]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 Feb 2018 12:37:38 +0100 Original-Received: (qmail 21549 invoked by uid 1000); 10 Feb 2018 11:26:54 -0000 Content-Disposition: inline In-Reply-To: <3331f80a-c5aa-5cb9-8088-0a88888bdaca@yandex.ru> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:143089 Archived-At: Hello, Dmitry. On Sat, Feb 10, 2018 at 11:53:55 +0300, Dmitry Gutov wrote: > On 2/9/18 8:50 PM, Alan Mackenzie wrote: > >> Specifically, it's the open paren in the column 0 that triggers it. You > >> can set `open-paren-in-column-0-is-defun-start' to nil to fix it. Same > >> idea as Bug#25480 (that one is cc-mode). [ .... ] > > If my fix isn't going to be accepted, I think it's high time that > > somebody else stepped up to the plate and fixed this monstrosity once > > and for all. > Have you seen 14b95587520959c5b54356547a0a69932a9bb480? No, I hadn't. Thanks, Stefan! I'm not sure, but I think there's a danger of a recursive loop, should a major mode use a hook in syntax-ppss to calculate syntax-table properties, and that hook call forward-comment. > AFAICT, open-paren-in-column-0-is-defun-start doesn't have much effect now. That patch is incomplete, though. I propose the following, to make it more complete: diff --git a/doc/emacs/programs.texi b/doc/emacs/programs.texi index 4289124545..0fa37530ef 100644 --- a/doc/emacs/programs.texi +++ b/doc/emacs/programs.texi @@ -153,54 +153,35 @@ Left Margin Paren @cindex ( in leftmost column Many programming-language modes assume by default that any opening delimiter found at the left margin is the start of a top-level -definition, or defun. Therefore, @strong{don't put an opening -delimiter at the left margin unless it should have that significance}. -For instance, never put an open-parenthesis at the left margin in a -Lisp file unless it is the start of a top-level list. - - The convention speeds up many Emacs operations, which would -otherwise have to scan back to the beginning of the buffer to analyze -the syntax of the code. - - If you don't follow this convention, not only will you have trouble -when you explicitly use the commands for motion by defuns; other -features that use them will also give you trouble. This includes the -indentation commands (@pxref{Program Indent}) and Font Lock mode -(@pxref{Font Lock}). - - The most likely problem case is when you want an opening delimiter -at the start of a line inside a string. To avoid trouble, put an -escape character (@samp{\}, in C and Emacs Lisp, @samp{/} in some -other Lisp dialects) before the opening delimiter. This will not -affect the contents of the string, but will prevent that opening -delimiter from starting a defun. Here's an example: - -@example - (insert "Foo: -\(bar) -") -@end example - - To help you catch violations of this convention, Font Lock mode -highlights confusing opening delimiters (those that ought to be -quoted) in bold red. +definition, or defun. Therefore, in these modes, don't put an opening +delimiter at the left margin, except in a comment or string, unless it +should have that significance. For instance, never put an +open-parenthesis at the left margin in a Lisp file unless it is the +start of a top-level list. + + In earlier versions of Emacs (through version 26.n), Emacs exploited +this convention to speed up many low-level operations, which would +otherwise have to scan back to the beginning of the buffer. +Unfortunately, this caused confusion when an opening delimiter +occurred at column zero inside a comment. The resulting faulty +analysis often caused wrong indentation or fontification. The +convention could be overridden by setting the user option +@code{open-paren-in-column-0-is-defun-start} to @code{nil}, but this +slowed Emacs down, particularaly when editing large buffers. + + To eliminate these problems, the low level functionality which used +to test for opening delimiters at column 0 no longer does so. Open +delimiters may now be freely written at the left margin inside +comments and strings without triggering these problems. @vindex open-paren-in-column-0-is-defun-start - If you need to override this convention, you can do so by setting -the variable @code{open-paren-in-column-0-is-defun-start}. -If this user option is set to @code{t} (the default), opening -parentheses or braces at column zero always start defuns. When it is -@code{nil}, defuns are found by searching for parens or braces at the -outermost level. - - Usually, you should leave this option at its default value of -@code{t}. If your buffer contains parentheses or braces in column -zero which don't start defuns, and it is somehow impractical to remove -these parentheses or braces, it might be helpful to set the option to -@code{nil}. Be aware that this might make scrolling and display in -large buffers quite sluggish. Furthermore, the parentheses and braces -must be correctly matched throughout the buffer for it to work -properly. + If you want to override the convention, which is still used by some +higher level commands, you can do so by setting the variable +@code{open-paren-in-column-0-is-defun-start} to @code{nil}. If this +user option is set to @code{t} (the default), these commands will stop +at opening parentheses or braces at column zero when seeking the start +of defuns. When it is @code{nil}, defuns are found by searching for +parens or braces at the outermost level. @node Moving by Defuns @subsection Moving by Defuns -- Alan Mackenzie (Nuremberg, Germany).