GNU bug report logs - #30393
cperl-mode: open-paren-in-column-0 of string literal affects later statement indentation

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: minor; Reported by: paulusm <paulusm@HIDDEN>; dated Thu, 8 Feb 2018 16:20:03 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 16 Apr 2018 19:24:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 16 15:24:17 2018
Received: from localhost ([127.0.0.1]:56246 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f89jd-0000pf-4P
	for submit <at> debbugs.gnu.org; Mon, 16 Apr 2018 15:24:17 -0400
Received: from colin.muc.de ([193.149.48.1]:63558 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1f89jb-0000pX-9j
 for 30393 <at> debbugs.gnu.org; Mon, 16 Apr 2018 15:24:16 -0400
Received: (qmail 20553 invoked by uid 3782); 16 Apr 2018 19:24:13 -0000
Received: from acm.muc.de (p5B147020.dip0.t-ipconnect.de [91.20.112.32]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 16 Apr 2018 21:24:11 +0200
Received: (qmail 5689 invoked by uid 1000); 16 Apr 2018 19:21:37 -0000
Date: Mon, 16 Apr 2018 19:21:37 +0000
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure - Documentation
 enhancements
Message-ID: <20180416192137.GA5637@ACM>
References: <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
 <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
 <20180305084255.GA4786@ACM> <83zi3msdms.fsf@HIDDEN>
 <20180408105257.GA5350@ACM> <83vad0xlwu.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <83vad0xlwu.fsf@HIDDEN>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, dgutov@HIDDEN, monnier@HIDDEN,
 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Eli.

On Mon, Apr 09, 2018 at 21:41:21 +0300, Eli Zaretskii wrote:
> > Date: Sun, 8 Apr 2018 10:52:57 +0000
> > Cc: monnier@HIDDEN, 30393 <at> debbugs.gnu.org, dgutov@HIDDEN,
> >   npostavs@HIDDEN
> > From: Alan Mackenzie <acm@HIDDEN>

> > Can we start moving forward with this change, please?

> What prevents you from moving forward with it?  You already know what
> needs to be done to move forward: documentation of the new primitives
> and some tests.

After mulling it over for several weeks, I now think it would be better
just to leave these new primitives out.  Although they might be useful,
their main use was for me whilst hacking the syntax routines.

However, I propose the following documentation changes to go with my
patch to the code, these changes clarifying some of the limitations
inherent to syntax-ppss, and indicating how my enhancements will work.



diff --git a/doc/lispref/syntax.texi b/doc/lispref/syntax.texi
index 3327d7855c..b58e2a9a98 100644
--- a/doc/lispref/syntax.texi
+++ b/doc/lispref/syntax.texi
@@ -430,6 +430,11 @@ Syntax Table Functions
 This function always returns @code{nil}.  The old syntax information in
 the table for this character is discarded.
 
+Note that if the modification of @var{table} changes the way it parses
+comments or strings, the cache used by @code{syntax-ppss} will be
+emptied in each buffer whose current syntax table (or its parent,
+etc.) is @var{table}.  @xref{Position Parse}.
+
 @example
 @group
 @exdent @r{Examples:}
@@ -502,6 +507,12 @@ Syntax Table Functions
 @defun set-syntax-table table
 This function makes @var{table} the syntax table for the current buffer.
 It returns @var{table}.
+
+Note that if @var{table} parses comments or strings differently from
+the buffer's previous syntax table, the cache used by
+@code{syntax-ppss} in this buffer will be emptied.  @xref{Position
+Parse}.
+
 @end defun
 
 @defun syntax-table
@@ -523,6 +534,9 @@ Syntax Table Functions
 more precise: @code{with-syntax-table} temporarily alters the current
 syntax table of whichever buffer is current at the time the macro
 execution starts.  Other buffers are not affected.
+
+This macro might empty the cache used by @code{syntax-ppss}, as noted
+above under @code{set-syntax-table}.
 @end defmac
 
 @node Syntax Properties
@@ -534,6 +548,15 @@ Syntax Properties
 occurrences in the buffer, by applying a @code{syntax-table} text
 property.  @xref{Text Properties}, for how to apply text properties.
 
+As an alternative to setting @code{syntax-table} text properties
+directly, you can use @code{syntax-propertize-function} (see below).
+Most major modes supplied with Emacs which use these text properties
+use this method for applying them.  We strongly recommended you to use
+just one of these methods in any Emacs Lisp program, and not to mix
+them in the same buffer.@footnote{@code{syntax-propertize-function}
+can operate at unpredictable times, and may erase explicitly applied
+@code{syntax-table} properties.}
+
   The valid values of @code{syntax-table} text property are:
 
 @table @asis
@@ -556,6 +579,10 @@ Syntax Properties
 If this is non-@code{nil}, the syntax scanning functions, like
 @code{forward-sexp}, pay attention to syntax text properties.
 Otherwise they use only the current syntax table.
+
+If you change this variable after buffer initialization time, even if
+your Emacs Lisp program doesn't use @code{syntax-ppss}, you should
+call @code{syntax-ppss-flush-cache}.  @xref{Position Parse}.
 @end defvar
 
 @defvar syntax-propertize-function
@@ -695,8 +722,9 @@ Motion via Parsing
 negative @var{depth} has the effect of moving deeper by @var{-depth}
 levels of parenthesis.
 
-Scanning ignores comments if @code{parse-sexp-ignore-comments} is
-non-@code{nil}.
+Scanning skips over comments if @code{parse-sexp-ignore-comments} is
+non-@code{nil} (which it usually is for programming language major
+modes).
 
 If the scan reaches the beginning or end of the accessible part of the
 buffer before it has scanned over @var{count} parenthetical groupings,
@@ -709,7 +737,7 @@ Motion via Parsing
 It returns the position where the scan stops.  If @var{count} is
 negative, the scan moves backwards.
 
-Scanning ignores comments if @code{parse-sexp-ignore-comments} is
+Scanning skips over comments if @code{parse-sexp-ignore-comments} is
 non-@code{nil}.
 
 If the scan reaches the beginning or end of (the accessible part of) the
@@ -747,7 +775,7 @@ Position Parse
 
   For syntactic analysis, such as in indentation, often the useful
 thing is to compute the syntactic state corresponding to a given buffer
-position.  This function does that conveniently.
+position.  @code{syntax-ppss} does that conveniently.
 
 @defun syntax-ppss &optional pos
 This function returns the parser state that the parser would reach at
@@ -769,6 +797,33 @@ Position Parse
 complete subexpression) and sixth value (minimum parenthesis depth) in
 the returned parser state are not meaningful.
 
+Note that these caches become invalid when you set a new syntax table
+for the buffer, or change an entry for a character in the current
+syntax table.  If you set or clear a @code{syntax-table} text property
+at some buffer position, the caches become invalid for the buffer
+portion at and after that position.  It is your responsibility to deal
+with these situations, either by calling
+@code{syntax-ppss-flush-cache} (see below), or by refraining from
+using @code{syntax-ppss} while the caches are invalid.  An exception
+to this is when such a change alters the way comments or strings are
+parsed; then, Emacs calls @code{syntax-ppss-flush-cache}
+automatically.@footnote{The reason for this is that from Emacs 27,
+Emacs uses @code{syntax-ppss} internally in low level primitives such
+as @code{forward-comment} and @code{scan-lists}.  This automatic
+flushing of the cache helps these primitives continue to work
+reliably.}
+
+Changing any of the variables @code{multibyte-syntax-as-symbol},
+@code{parse-sexp-ignore-comments}, @code{comment-end-can-be-escaped}
+(@pxref{Control Parsing}), or @code{parse-sexp-lookup-properties}
+(@pxref{Syntax Properties}) after buffer initialization will always
+leave @code{syntax-ppss}'s caches invalid in the affected buffers.  So
+will changing a symbol's @code{syntax-table} property when that symbol
+is the value of a @code{category} text property somewhere in the
+buffer (@pxref{Special Properties}), a practice we don't recommend.
+In such cases you must always take one of the actions detailed in the
+previous paragraph.
+
 This function has a side effect: it adds a buffer-local entry to
 @code{before-change-functions} (@pxref{Change Hooks}) for
 @code{syntax-ppss-flush-cache} (see below).  This entry keeps the
@@ -952,6 +1007,11 @@ Control Parsing
 You can use @code{forward-comment} to move forward or backward over
 one comment or several comments.
 
+If you change any of the above three variables after buffer
+initialization time, even if your Emacs Lisp program doesn't use
+@code{syntax-ppss}, you should call @code{syntax-ppss-flush-cache}.
+@xref{Position Parse}.
+
 @node Syntax Table Internals
 @section Syntax Table Internals
 @cindex syntax table internals
diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi
index ebfa8b9b0f..d8df9fe352 100644
--- a/doc/lispref/text.texi
+++ b/doc/lispref/text.texi
@@ -3203,6 +3203,14 @@ Special Properties
 properties of this symbol serve as defaults for the properties of the
 character.
 
+You might be tempted to put a @code{syntax-table} property onto the
+symbol, and change this property's value repeatedly in your Lisp
+program, thus changing the syntax of many characters in a buffer at
+the same time.  We advise against doing this, since it renders the
+caches used by @code{syntax-ppss} invalid in a way that Emacs cannot
+detect and correct for.  If you are going to be doing this, please
+consult @ref{Position Parse} and follow the advice there.
+
 @item face
 @cindex face codes of text
 @kindex face @r{(text property)}


-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 10 Apr 2018 17:32:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 10 13:32:42 2018
Received: from localhost ([127.0.0.1]:45378 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f5x8L-0006Q8-Sg
	for submit <at> debbugs.gnu.org; Tue, 10 Apr 2018 13:32:42 -0400
Received: from colin.muc.de ([193.149.48.1]:60361 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1f5x8J-0006Px-4u
 for 30393 <at> debbugs.gnu.org; Tue, 10 Apr 2018 13:32:40 -0400
Received: (qmail 45299 invoked by uid 3782); 10 Apr 2018 17:32:37 -0000
Received: from acm.muc.de (p5B1472B7.dip0.t-ipconnect.de [91.20.114.183]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Tue, 10 Apr 2018 19:32:36 +0200
Received: (qmail 5332 invoked by uid 1000); 10 Apr 2018 17:31:06 -0000
Date: Tue, 10 Apr 2018 17:31:06 +0000
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180410173106.GA5290@ACM>
References: <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
 <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
 <20180305084255.GA4786@ACM> <83zi3msdms.fsf@HIDDEN>
 <20180408105257.GA5350@ACM> <83vad0xlwu.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <83vad0xlwu.fsf@HIDDEN>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, dgutov@HIDDEN, monnier@HIDDEN,
 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Eli.

On Mon, Apr 09, 2018 at 21:41:21 +0300, Eli Zaretskii wrote:
> > Date: Sun, 8 Apr 2018 10:52:57 +0000
> > Cc: monnier@HIDDEN, 30393 <at> debbugs.gnu.org, dgutov@HIDDEN,
> >   npostavs@HIDDEN
> > From: Alan Mackenzie <acm@HIDDEN>

> > Can we start moving forward with this change, please?

> What prevents you from moving forward with it?

The lack of an expressed intention, in principle, to accept the patch.
I'll take your post as this.

> You already know what needs to be done to move forward: documentation
> of the new primitives and some tests.

Yes.  I will move forward with this now.  Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 9 Apr 2018 18:41:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 09 14:41:44 2018
Received: from localhost ([127.0.0.1]:44245 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f5bjZ-0003pW-FC
	for submit <at> debbugs.gnu.org; Mon, 09 Apr 2018 14:41:44 -0400
Received: from eggs.gnu.org ([208.118.235.92]:41781)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f5bjY-0003pK-IL
 for 30393 <at> debbugs.gnu.org; Mon, 09 Apr 2018 14:41:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f5bjS-0008Kw-MO
 for 30393 <at> debbugs.gnu.org; Mon, 09 Apr 2018 14:41:35 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60185)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f5bjA-0008De-Un; Mon, 09 Apr 2018 14:41:17 -0400
Received: from [176.228.60.248] (port=4206 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f5bjA-0006HW-Ha; Mon, 09 Apr 2018 14:41:16 -0400
Date: Mon, 09 Apr 2018 21:41:21 +0300
Message-Id: <83vad0xlwu.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
In-reply-to: <20180408105257.GA5350@ACM> (message from Alan Mackenzie on Sun, 
 8 Apr 2018 10:52:57 +0000)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
References: <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
 <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
 <20180305084255.GA4786@ACM> <83zi3msdms.fsf@HIDDEN>
 <20180408105257.GA5350@ACM>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, dgutov@HIDDEN, monnier@HIDDEN,
 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> Date: Sun, 8 Apr 2018 10:52:57 +0000
> Cc: monnier@HIDDEN, 30393 <at> debbugs.gnu.org, dgutov@HIDDEN,
>   npostavs@HIDDEN
> From: Alan Mackenzie <acm@HIDDEN>
> 
> Can we start moving forward with this change, please?

What prevents you from moving forward with it?  You already know what
needs to be done to move forward: documentation of the new primitives
and some tests.  Am I missing something?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 8 Apr 2018 10:54:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 08 06:54:13 2018
Received: from localhost ([127.0.0.1]:41937 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f57xd-0004mg-4U
	for submit <at> debbugs.gnu.org; Sun, 08 Apr 2018 06:54:13 -0400
Received: from colin.muc.de ([193.149.48.1]:59060 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1f57xa-0004mW-HT
 for 30393 <at> debbugs.gnu.org; Sun, 08 Apr 2018 06:54:11 -0400
Received: (qmail 8798 invoked by uid 3782); 8 Apr 2018 10:54:08 -0000
Received: from acm.muc.de (p5B146FB5.dip0.t-ipconnect.de [91.20.111.181]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 08 Apr 2018 12:54:07 +0200
Received: (qmail 6688 invoked by uid 1000); 8 Apr 2018 10:52:57 -0000
Date: Sun, 8 Apr 2018 10:52:57 +0000
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180408105257.GA5350@ACM>
References: <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
 <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
 <20180305084255.GA4786@ACM> <83zi3msdms.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <83zi3msdms.fsf@HIDDEN>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, dgutov@HIDDEN, monnier@HIDDEN,
 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hello, Eli.

On Mon, Mar 05, 2018 at 18:14:51 +0200, Eli Zaretskii wrote:
> > Date: Mon, 5 Mar 2018 08:42:55 +0000
> > From: Alan Mackenzie <acm@HIDDEN>
> > Cc: 30393 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>,
> > 	Noam Postavsky <npostavs@HIDDEN>

> > Existing C functions have been modified as follows:
> >   o - signal_after_change.
> >     * - Regardless of the settings of the change hooks,
> >       syntax-ppss-flush-cache will be called for an actual textual
> >       change.
> >   o - Fset_syntax_table.
> >     * - If the new table is literally different from the old,
> >       syntax-ppss-flush-cache will be called with an argument of -1.
> >   o - Fmodify_syntax_entry.
> >     * - If the new entry is literally different from the old one,
> >       syntax-ppss-flush-cache will be called with an argument of -1.
> >   o - init_syntax_once and syms_of_syntax.
> >     * - Administrative amendments.
> >   o - set_properties, add_properties, remove_properties.  If a
> >     syntax-table property set or removed, whether directly or via a
> >     category property, potentially alters the parsing of literals,
> >     syntax-ppss-flush-cache will be called.

> Any reason why you introduce 2 new primitives that no Lisp code uses?

[ Already answered ].

> In any case, this needs documentation changes if and when it's agreed
> upon.

Can we start moving forward with this change, please?

Just a quick summary of what it's about:  syntax-ppss is now being used
in back_comment.  syntax-ppss's cache, at the moment, isn't being
invalidated when the syntax table is swapped, or an entry in it is
changed, or when a syntax-table text property is applied to a buffer
element.  The patch fixes this, as far as back_comment is concerned.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 6 Mar 2018 18:24:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 06 13:24:34 2018
Received: from localhost ([127.0.0.1]:47996 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1etHGM-00014g-IX
	for submit <at> debbugs.gnu.org; Tue, 06 Mar 2018 13:24:34 -0500
Received: from colin.muc.de ([193.149.48.1]:60158 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1etHGK-00014X-Vq
 for 30393 <at> debbugs.gnu.org; Tue, 06 Mar 2018 13:24:33 -0500
Received: (qmail 98428 invoked by uid 3782); 6 Mar 2018 18:24:31 -0000
Received: from acm.muc.de (p548C78E6.dip0.t-ipconnect.de [84.140.120.230]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Tue, 06 Mar 2018 19:24:30 +0100
Received: (qmail 7882 invoked by uid 1000); 6 Mar 2018 18:09:17 -0000
Date: Tue, 6 Mar 2018 18:09:17 +0000
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180306180917.GA7774@ACM>
References: <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
 <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
 <20180305084255.GA4786@ACM> <83zi3msdms.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <83zi3msdms.fsf@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, dgutov@HIDDEN, monnier@HIDDEN,
 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Eli.

On Mon, Mar 05, 2018 at 18:14:51 +0200, Eli Zaretskii wrote:
> > Date: Mon, 5 Mar 2018 08:42:55 +0000
> > From: Alan Mackenzie <acm@HIDDEN>
> > Cc: 30393 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>,
> > 	Noam Postavsky <npostavs@HIDDEN>

> > Existing C functions have been modified as follows:
> >   o - signal_after_change.
> >     * - Regardless of the settings of the change hooks,
> >       syntax-ppss-flush-cache will be called for an actual textual
> >       change.
> >   o - Fset_syntax_table.
> >     * - If the new table is literally different from the old,
> >       syntax-ppss-flush-cache will be called with an argument of -1.
> >   o - Fmodify_syntax_entry.
> >     * - If the new entry is literally different from the old one,
> >       syntax-ppss-flush-cache will be called with an argument of -1.
> >   o - init_syntax_once and syms_of_syntax.
> >     * - Administrative amendments.
> >   o - set_properties, add_properties, remove_properties.  If a
> >     syntax-table property set or removed, whether directly or via a
> >     category property, potentially alters the parsing of literals,
> >     syntax-ppss-flush-cache will be called.

> Any reason why you introduce 2 new primitives that no Lisp code uses?

least-literal-difference-between-syntax-tables and
syntax-tables-literally-different-p?  They're for helping with
debugging.  Syntax tables, like char tables in general, are awkward
unwieldy beasts.  Sooner or later, somebody debugging is going to want
to compare two syntax tables which aren't behaving as she expects they
should.  Those primitives (which, yes, will need documenting) were cheap
and easy to write, but would be awkward and unwieldy to write as
one-offs in Lisp.

> In any case, this needs documentation changes if and when it's agreed
> upon.

Yes, but less documentation that would be needed without it.
Introducing the syntax-ppss mechanism into syntax primitives broke them,
since its cache invalidation is imperfect.  With my patch, aside from
any bugs in it, those primitives are less broken, hence less
documentation of the breakage is needed.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 5 Mar 2018 16:15:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 05 11:15:34 2018
Received: from localhost ([127.0.0.1]:46123 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1esslx-00037F-WF
	for submit <at> debbugs.gnu.org; Mon, 05 Mar 2018 11:15:34 -0500
Received: from eggs.gnu.org ([208.118.235.92]:33323)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1esslw-000373-3y
 for 30393 <at> debbugs.gnu.org; Mon, 05 Mar 2018 11:15:32 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1esslq-0008Tm-3M
 for 30393 <at> debbugs.gnu.org; Mon, 05 Mar 2018 11:15:26 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55849)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1esslX-0008Ct-G3; Mon, 05 Mar 2018 11:15:07 -0500
Received: from [176.228.60.248] (port=4591 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1esslT-0005tc-1f; Mon, 05 Mar 2018 11:15:04 -0500
Date: Mon, 05 Mar 2018 18:14:51 +0200
Message-Id: <83zi3msdms.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
In-reply-to: <20180305084255.GA4786@ACM> (message from Alan Mackenzie on Mon, 
 5 Mar 2018 08:42:55 +0000)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
 <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN> <20180305084255.GA4786@ACM>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, dgutov@HIDDEN, monnier@HIDDEN,
 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Mon, 5 Mar 2018 08:42:55 +0000
> From: Alan Mackenzie <acm@HIDDEN>
> Cc: 30393 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>,
> 	Noam Postavsky <npostavs@HIDDEN>
> 
> Existing C functions have been modified as follows:
>   o - signal_after_change.
>     * - Regardless of the settings of the change hooks,
>       syntax-ppss-flush-cache will be called for an actual textual
>       change.
>   o - Fset_syntax_table.
>     * - If the new table is literally different from the old,
>       syntax-ppss-flush-cache will be called with an argument of -1.
>   o - Fmodify_syntax_entry.
>     * - If the new entry is literally different from the old one,
>       syntax-ppss-flush-cache will be called with an argument of -1.
>   o - init_syntax_once and syms_of_syntax.
>     * - Administrative amendments.
>   o - set_properties, add_properties, remove_properties.  If a
>     syntax-table property set or removed, whether directly or via a
>     category property, potentially alters the parsing of literals,
>     syntax-ppss-flush-cache will be called.

Any reason why you introduce 2 new primitives that no Lisp code uses?

In any case, this needs documentation changes if and when it's agreed
upon.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 5 Mar 2018 08:58:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 05 03:58:03 2018
Received: from localhost ([127.0.0.1]:45080 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eslwX-0007Y2-AF
	for submit <at> debbugs.gnu.org; Mon, 05 Mar 2018 03:58:02 -0500
Received: from colin.muc.de ([193.149.48.1]:14723 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1eslwT-0007Xr-L4
 for 30393 <at> debbugs.gnu.org; Mon, 05 Mar 2018 03:57:58 -0500
Received: (qmail 80724 invoked by uid 3782); 5 Mar 2018 08:57:56 -0000
Received: from acm.muc.de (p548C79D6.dip0.t-ipconnect.de [84.140.121.214]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 05 Mar 2018 09:57:55 +0100
Received: (qmail 5896 invoked by uid 1000); 5 Mar 2018 08:42:55 -0000
Date: Mon, 5 Mar 2018 08:42:55 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180305084255.GA4786@ACM>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
 <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: Noam Postavsky <npostavs@HIDDEN>, 30393 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Stefan.

Sorry this has taken so long.  I've been preoccupied with things outside
of Emacs.

On Mon, Feb 12, 2018 at 15:45:40 -0500, Stefan Monnier wrote:
> > It has occurred to me over the last day or two that I have already
> > solved these problems (basically, with your first approach, hooking into
> > set-syntax-table and friends) in the comment-cache branch, and that the
> > approach taken could be used more or less unchanged in the current
> > master.

> If you can reuse existing code, even better.

The following patch ensures that (almost) any time the syntax table or a
syntax-table text property is changed in a way which affects literals,
the function syntax-ppss-flush-cache is called.

The known exceptions to the above are that setting any of the variables
parse-sexp-lookup-properties, syntax-propertize-function,
syntax-propertize-extend-region-functions, multibyte-syntax-as-symbol,
parse-sexp-ignore-comments, comment-end-can-be-escaped after mode
initialisation is not detected.  The major mode code would need to flush
the caches explicitly on such a change.  Also, changing the syntax-table
property of a symbol which is the value of a category text-property is
not detected.

In the following descriptions "literally the same" and "literally
different", when applied to syntax things, are shorthand for "will parse
literals (comments and strings) the same/differently".

Existing C functions have been modified as follows:
  o - signal_after_change.
    * - Regardless of the settings of the change hooks,
      syntax-ppss-flush-cache will be called for an actual textual
      change.
  o - Fset_syntax_table.
    * - If the new table is literally different from the old,
      syntax-ppss-flush-cache will be called with an argument of -1.
  o - Fmodify_syntax_entry.
    * - If the new entry is literally different from the old one,
      syntax-ppss-flush-cache will be called with an argument of -1.
  o - init_syntax_once and syms_of_syntax.
    * - Administrative amendments.
  o - set_properties, add_properties, remove_properties.  If a
    syntax-table property set or removed, whether directly or via a
    category property, potentially alters the parsing of literals,
    syntax-ppss-flush-cache will be called.



diff --git a/src/chartab.c b/src/chartab.c
index 065ae4f9f2..e2b9e682cc 100644
--- a/src/chartab.c
+++ b/src/chartab.c
@@ -314,7 +314,6 @@ sub_char_table_ref_and_range (Lisp_Object table, int c, int *from, int *to,
   return val;
 }
 
-
 /* Return the value for C in char-table TABLE.  Shrink the range *FROM
    and *TO to cover characters (containing C) that have the same value
    as C.  It is not assured that the values of (*FROM - 1) and (*TO +
@@ -386,6 +385,60 @@ char_table_ref_and_range (Lisp_Object table, int c, int *from, int *to)
   return val;
 }
 
+/* Return the value for C in char-table TABLE.  Shrink the range
+   *FROM and *TO to cover characters (containing C) that have the same
+   value as C.  Should the value for C in TABLE be nil, consult the
+   parent table of TABLE, recursively if necessary.  It is not
+   guaranteed that the values of (*FROM - 1) and (*TO + 1) are
+   different from that of C.  */
+Lisp_Object
+char_table_ref_and_range_with_parents (Lisp_Object table, int c,
+                                       int *from, int *to)
+{
+  Lisp_Object val;
+  Lisp_Object parent, defalt;
+  struct Lisp_Char_Table *tbl;
+
+  if (*to < 0)
+    *to = MAX_CHAR;
+  if (ASCII_CHAR_P (c)
+      && *from <= c
+      && *to >= c)
+    {
+      tbl = XCHAR_TABLE (table);
+      parent = tbl->parent;     /* Added in to try to fix segfault.  2018-02-18. */
+      defalt = tbl->defalt;
+      val = NILP (tbl->ascii)
+        ? defalt /*Qnil*/
+        : sub_char_table_ref_and_range (tbl->ascii, c, from, to, defalt, false);
+      while (NILP (val) && !NILP (parent))
+        {
+          tbl = XCHAR_TABLE (parent);
+          parent = tbl->parent;
+          defalt = tbl->defalt;
+          val = NILP (tbl->ascii)
+            ? defalt /*Qnil*/
+            : sub_char_table_ref_and_range (tbl->ascii, c, from, to, defalt, false);
+        }
+      return val;
+    }
+  else if (!ASCII_CHAR_P (c))
+    {
+      val = char_table_ref_and_range (table, c, from, to);
+      tbl = XCHAR_TABLE (table);
+      while (NILP (val))
+        {
+          parent = tbl->parent;
+          if (NILP (parent))
+            break;
+          val = char_table_ref_and_range (parent, c, from, to);
+          tbl = XCHAR_TABLE (parent);
+        }
+      return val;
+    }
+  else
+    return Qnil;
+}
 
 static void
 sub_char_table_set (Lisp_Object table, int c, Lisp_Object val, bool is_uniprop)
diff --git a/src/insdel.c b/src/insdel.c
index 02e3f41bc9..4016ceb845 100644
--- a/src/insdel.c
+++ b/src/insdel.c
@@ -2170,6 +2170,12 @@ signal_after_change (ptrdiff_t charpos, ptrdiff_t lendel, ptrdiff_t lenins)
   ptrdiff_t count = SPECPDL_INDEX ();
   struct rvoe_arg rvoe_arg;
 
+  /* Ensure we invalidate the syntax cache on an actual text change
+     regardless of the settings of inhibit-modification-hooks and
+     after-change-functions. */
+  if ((lenins != lendel)
+      && Ffboundp (Qsyntax_ppss_flush_cache)) /* For bootstrapping. */
+    call1 (Qsyntax_ppss_flush_cache, make_number (charpos));
   if (inhibit_modification_hooks)
     return;
 
diff --git a/src/lisp.h b/src/lisp.h
index a7f0a1d78f..e4f76f4561 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -3851,6 +3851,8 @@ extern void r_alloc_inhibit_buffer_relocation (int);
 extern Lisp_Object copy_char_table (Lisp_Object);
 extern Lisp_Object char_table_ref_and_range (Lisp_Object, int,
                                              int *, int *);
+extern Lisp_Object char_table_ref_and_range_with_parents (Lisp_Object, int,
+                                                          int*, int*);
 extern void char_table_set_range (Lisp_Object, int, int, Lisp_Object);
 extern void map_char_table (void (*) (Lisp_Object, Lisp_Object,
                             Lisp_Object),
diff --git a/src/syntax.c b/src/syntax.c
index 52cec23cd7..d81a57cd22 100644
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -178,8 +178,12 @@ static ptrdiff_t find_start_begv;
 static EMACS_INT find_start_modiff;
 
 
+static void check_syntax_table (Lisp_Object);
 static Lisp_Object skip_chars (bool, Lisp_Object, Lisp_Object, bool);
 static Lisp_Object skip_syntaxes (bool, Lisp_Object, Lisp_Object);
+static bool syntax_table_value_range_is_interesting_for_literals (Lisp_Object,
+                                                                  int, int);
+static void break_off_syntax_tables_literal_relations (Lisp_Object);
 static Lisp_Object scan_lists (EMACS_INT, EMACS_INT, EMACS_INT, bool);
 static void scan_sexps_forward (struct lisp_parse_state *,
                                 ptrdiff_t, ptrdiff_t, ptrdiff_t, EMACS_INT,
@@ -687,6 +691,112 @@ prev_char_comend_first (ptrdiff_t pos, ptrdiff_t pos_byte)
   return val;
 }
 
+/* Empty the syntax-ppss cache of every buffer whose syntax table is
+   currently set to TABLE. */
+static void
+empty_syntax_tables_buffers_syntax_caches (Lisp_Object table)
+{
+  Lisp_Object buf, buf_list;
+  struct buffer *current = current_buffer;
+  struct buffer *b;
+
+  buf_list = Fbuffer_list (Qnil);
+  while (!NILP (buf_list))
+    {
+      buf = XCAR (buf_list);
+      b = XBUFFER (buf);
+      if (EQ (BVAR (b, syntax_table), table))
+        {
+          set_buffer_internal_1 (b);
+          call1 (Qsyntax_ppss_flush_cache, make_number (-1));
+        }
+      buf_list = XCDR (buf_list);
+    }
+  set_buffer_internal_1 (current);
+}
+
+#define LITERAL_MASK ((1 << Sstring)            \
+                      | (1 << Sescape)          \
+                      | (1 << Scharquote)       \
+                      | (1 << Scomment)         \
+                      | (1 << Sendcomment)      \
+                      | (1 << Scomment_fence)   \
+                      | (1 << Sstring_fence))
+
+/* The following returns true if ELT (which will be a raw syntax
+   descriptor (see page "Syntax Table Internals" in the Elisp manual)
+   or nil) represents a syntax which is (potentially) relevant to
+   strings or comments.  */
+static bool
+SYNTAB_LITERAL (Lisp_Object elt)
+{
+  int ielt;
+  if (!CONSP (elt))
+    return false;
+  ielt = XINT (XCAR (elt));
+  return (ielt & 0xF0000)       /* a comment flag is set */
+    || ((1 << (ielt & 0xFF)) & LITERAL_MASK); /* One of Sstring, .... */
+}
+
+static
+bool syntax_table_value_is_interesting_for_literals (Lisp_Object val)
+{
+  if (!CONSP (val)
+      || !INTEGERP (XCAR (val)))
+    return false;
+  return SYNTAB_LITERAL (XCAR (val));
+}
+
+/* The text property PROP is having its value VAL at position POS in buffer BUF
+either set or cleared.  If this value is relevant to the syntax of literals,
+reduce the BUF's "syntax cache position" to POS.  */
+void
+check_syntax_cache_for_prop (ptrdiff_t pos, Lisp_Object prop,
+                             Lisp_Object val, Lisp_Object buffer)
+{
+  struct buffer *b;
+  struct buffer *current = current_buffer;
+  Lisp_Object plist;
+
+  if (!BUFFERP (buffer))
+    return;
+  b = XBUFFER (buffer);
+  set_buffer_internal_1 (b);
+  if (pos >= syntax_propertize__done)
+    {
+      set_buffer_internal_1 (current);
+      return;
+    }
+
+  if (EQ (prop, Qcategory)
+      && SYMBOLP (val))
+    {
+      plist = Fsymbol_plist (val);
+      while (CONSP (plist))
+        {
+          prop = XCAR (plist);
+          plist = XCDR (plist);
+          if (!CONSP (plist))
+            {
+              set_buffer_internal_1 (current);
+              return;
+            }
+          val = XCAR (plist);
+          if (EQ (prop, Qsyntax_table))
+            break;
+          plist = XCDR (plist);
+        }
+    }
+  if (EQ (prop, Qsyntax_table)
+      && syntax_table_value_is_interesting_for_literals (val))
+    call1 (Qsyntax_ppss_flush_cache, make_number (pos));
+  set_buffer_internal_1 (current);
+}
+
+/*****************************************************************************
+ *****************************************************************************/
+
+
 /* Check whether charpos FROM is at the end of a comment.
    FROM_BYTE is the bytepos corresponding to FROM.
    Do not move back before STOP.
@@ -989,6 +1099,222 @@ back_comment (ptrdiff_t from, ptrdiff_t from_byte, ptrdiff_t stop,
   return from != comment_end;
 }
 
+/* If the two syntax entries OLD_SYN and NEW_SYN would parse strings
+   or comments differently return true, otherwise return nil. */
+static bool
+literally_different (Lisp_Object old_syn, Lisp_Object new_syn)
+{
+  bool old_literality = SYNTAB_LITERAL (old_syn),
+    new_literality = SYNTAB_LITERAL (new_syn);
+  return (old_literality != new_literality)
+    || (old_literality
+        && (!EQ (Fcar (old_syn), Fcar (new_syn))));
+}
+
+/* If there is a character position in the range [START, END] for
+   whose syntaxes in syntax tables OLD and NEW strings or comments
+   might be parsed differently, return the lowest character for which
+   this holds.  Otherwise, return -1.  */
+static int
+syntax_table_ranges_differ_literally_p (Lisp_Object old, Lisp_Object new,
+                                              int start, int end)
+{
+  int old_from, new_from, old_to, new_to;
+  Lisp_Object old_syn = Qnil, new_syn = Qnil; /* Initialise to avoid compiler warnings. */
+
+  new_from = old_from = start;
+  new_to = old_to = -1;
+
+  while ((old_from < end) && (new_from < end))
+    {
+      if (old_from == new_from)
+        {
+          old_syn = char_table_ref_and_range_with_parents (old, old_from,
+                                                           &old_from, &old_to);
+          new_syn = char_table_ref_and_range_with_parents (new, new_from,
+                                                           &new_from, &new_to);
+          if (literally_different (old_syn, new_syn))
+            return old_from;
+          old_from = old_to + 1;
+          new_from = new_to + 1;
+          old_to = -1;
+          new_to = -1;
+        }
+      else if (old_from < new_from)
+        {
+          old_syn = char_table_ref_and_range_with_parents (old, old_from,
+                                                           &old_from, &old_to);
+          if (literally_different (old_syn, new_syn))
+            return old_from;
+          old_from = old_to + 1;
+          old_to = -1;
+        }
+      else
+        {
+          new_syn = char_table_ref_and_range_with_parents (new, new_from,
+                                                           &new_from, &new_to);
+          if (literally_different (old_syn, new_syn))
+            return new_from;
+          new_from = new_to + 1;
+          new_to = -1;
+        }
+    }
+  return -1;
+}
+
+DEFUN ("least-literal-difference-between-syntax-tables",
+       Fleast_literal_difference_between_syntax_tables,
+       Sleast_literal_difference_between_syntax_tables,
+       2, 2, 0,
+       doc: /* Lowest char whose different syntaxes in OLD and NEW parse literals differently.
+               OLD and NEW are syntax tables.  */)
+       (Lisp_Object old, Lisp_Object new)
+{
+  int c;
+
+  check_syntax_table (old);
+  check_syntax_table (new);
+  c = syntax_table_ranges_differ_literally_p (old, new, 0, MAX_CHAR + 1);
+  if (c >= 0)
+    return make_number (c);
+  return Qnil;
+}
+
+/* The next two variables are alists, the key being a syntax table,
+   and the value being a non-empty list of syntax_tables.  When a
+   syntax table B is known to parse strings and comments the same as
+   syntax table A, it will be a member of the value whose key is A in
+   `literally_the_same_sts' (and vice versa).  Similarly, when two
+   syntax tables are known to parse strings and comments differently,
+   there will be entries in `literally_different_sts'. */
+static Lisp_Object literally_the_same_sts, literally_different_sts;
+
+DEFUN ("syntax-tables-literally-different-p",
+       Fsyntax_tables_literally_different_p,
+       Ssyntax_tables_literally_different_p,
+       2, 2, 0,
+       doc: /* Will syntax tables OLD and NEW parse literals differently?
+Return t when OLD and NEW might parse comments and strings differently,
+otherwise nil.  (Use `least-literal-difference-between-syntax-tables'
+to locate a character position where the tables differ.)  */)
+     (Lisp_Object old, Lisp_Object new)
+{
+  Lisp_Object elt;
+
+  check_syntax_table (old);
+  check_syntax_table (new);
+  /* Check to see if there is a cached relationship between the tables. */
+  if (!NILP (Fmemq (new, /*XCHAR_TABLE (old)->extras[0])*/
+                    Fassq (old, literally_the_same_sts))))
+    return Qnil;
+  if (!NILP (Fmemq (new, /*XCHAR_TABLE (old)->extras[1])*/
+                    Fassq (old, literally_different_sts))))
+    return Qt;
+  /* The two tables have no known relationship, so we'll have
+     laboriously to compare them. */
+  if (syntax_table_ranges_differ_literally_p (old, new, 0, MAX_CHAR + 1) >= 0)
+    {
+      /* Mark the "literally different" relationship between the OLD and
+         NEW syntax tables. */
+      elt = Fassq (new, literally_different_sts);
+      if (NILP (elt))
+        literally_different_sts = Fcons (Fcons (new, Fcons (old, Qnil)),
+                                         literally_different_sts);
+      else
+        Fsetcdr (elt, Fcons (old, XCDR (elt)));
+      elt = Fassq (old, literally_different_sts);
+      if (NILP (elt))
+        literally_different_sts = Fcons (Fcons (old, Fcons (new, Qnil)),
+                                         literally_different_sts);
+      else
+        Fsetcdr (elt, Fcons (new, XCDR (elt)));
+      return Qt;
+    }
+  else
+    {
+      /* Mark the "not literally different" relationship between the OLD
+         and NEW syntax tables. */
+      elt = Fassq (new, literally_the_same_sts);
+      if (NILP (elt))
+        literally_the_same_sts = Fcons (Fcons (new, Fcons (old, Qnil)),
+                                        literally_the_same_sts);
+      else
+        Fsetcdr (elt, Fcons (old, XCDR (elt)));
+      elt = Fassq (old, literally_the_same_sts);
+      if (NILP (elt))
+        literally_the_same_sts = Fcons (Fcons (old, Fcons (new, Qnil)),
+                                        literally_the_same_sts);
+      else
+        Fsetcdr (elt, Fcons (new, XCDR (elt)));
+      return Qnil;
+    }
+}
+
+/* If any character in the range [START, END) has an entry in syntax
+   table TABLE which is relevant to literal parsing, return true,
+   else return false. */
+static bool
+syntax_table_value_range_is_interesting_for_literals (Lisp_Object table,
+                                                      int start, int end)
+{
+  int from, to;
+  Lisp_Object syn;
+
+  from = start;
+  to = end;
+  while (from < to)
+    {
+      syn = char_table_ref_and_range_with_parents (table, from, &from, &to);
+      if (SYNTAB_LITERAL (syn))
+        return true;
+      from = to + 1;
+      to = end;
+    }
+  return false;
+}
+
+static void
+break_off_syntax_tables_literal_relations (Lisp_Object table)
+{
+  Lisp_Object remotes_elt;
+  Lisp_Object remotes, keep_remotes;
+  Lisp_Object rem, elt;
+
+  remotes_elt = Fassq (table, literally_the_same_sts);
+  remotes = Fcdr (remotes_elt);
+  keep_remotes = remotes;
+  while (!NILP (remotes))
+    {
+      rem = Fcar (remotes);
+      elt = Fassq (rem, literally_the_same_sts);
+      Fsetcdr (elt, Fdelq (table, Fcdr (elt)));
+      if (NILP (Fcdr (elt)))
+        literally_the_same_sts = Fdelq (elt, literally_the_same_sts);
+      remotes = Fcdr (remotes);
+    }
+  if (!NILP (keep_remotes))
+    literally_the_same_sts = Fdelq (remotes_elt, literally_the_same_sts);
+
+  remotes_elt = Fassq (table, literally_different_sts);
+  remotes = Fcdr (remotes_elt);
+  keep_remotes = remotes;
+  while (!NILP (remotes))
+    {
+      rem = Fcar (remotes);
+      elt = Fassq (rem, literally_different_sts);
+      Fsetcdr (elt, Fdelq (table, Fcdr (elt)));
+      if (NILP (Fcdr (elt)))
+        literally_different_sts = Fdelq (elt, literally_different_sts);
+      remotes = Fcdr (remotes);
+    }
+  if (!NILP (keep_remotes))
+    literally_different_sts = Fdelq (remotes_elt, literally_different_sts);
+}
+
+
+/*****************************************************************************
+ ****************************************************************************/
+
 DEFUN ("syntax-table-p", Fsyntax_table_p, Ssyntax_table_p, 1, 1, 0,
        doc: /* Return t if OBJECT is a syntax table.
 Currently, any char-table counts as a syntax table.  */)
@@ -1057,6 +1383,14 @@ One argument, a syntax table.  */)
 {
   int idx;
   check_syntax_table (table);
+  /* Optimise away the case when we're not changing the table. */
+  if (EQ (BVAR (current_buffer, syntax_table), table))
+    return table;
+  if (!NILP (Fsyntax_table_p (BVAR (current_buffer, syntax_table)))
+      && !NILP (Fsyntax_tables_literally_different_p
+                (BVAR (current_buffer, syntax_table), table))
+      && Ffboundp (Qsyntax_ppss_flush_cache)) /* for bootstrapping. */
+    call1 (Qsyntax_ppss_flush_cache, make_number (-1));
   bset_syntax_table (current_buffer, table);
   /* Indicate that this buffer now has a specified syntax table.  */
   idx = PER_BUFFER_VAR_IDX (syntax_table);
@@ -1274,6 +1608,16 @@ usage: (modify-syntax-entry CHAR NEWENTRY &optional SYNTAX-TABLE)  */)
     check_syntax_table (syntax_table);
 
   newentry = Fstring_to_syntax (newentry);
+  if (SYNTAB_LITERAL (newentry)
+      || (CONSP (c)
+          ? syntax_table_value_range_is_interesting_for_literals
+          (syntax_table, XINT (XCAR(c)), XINT (XCDR (c)))
+          : (SYNTAB_LITERAL (Faref (syntax_table, c)))))
+    {
+      empty_syntax_tables_buffers_syntax_caches (syntax_table);
+      break_off_syntax_tables_literal_relations (syntax_table);
+    }
+
   if (CONSP (c))
     SET_RAW_SYNTAX_ENTRY_RANGE (syntax_table, c, newentry);
   else
@@ -3637,6 +3981,10 @@ init_syntax_once (void)
   /* This has to be done here, before we call Fmake_char_table.  */
   DEFSYM (Qsyntax_table, "syntax-table");
 
+  /* We do not yet have any knowledge of how syntax tables parse literals. */
+  literally_the_same_sts = Qnil;
+  literally_different_sts = Qnil;
+
   /* Create objects which can be shared among syntax tables.  */
   Vsyntax_code_object = make_uninit_vector (Smax);
   for (i = 0; i < Smax; i++)
@@ -3728,6 +4076,9 @@ syms_of_syntax (void)
   staticpro (&gl_state.current_syntax_table);
   staticpro (&gl_state.old_prop);
 
+  staticpro (&literally_the_same_sts);
+  staticpro (&literally_different_sts);
+
   /* Defined in regex.c.  */
   staticpro (&re_match_object);
 
@@ -3752,6 +4103,8 @@ See the info node `(elisp)Syntax Properties' for a description of the
   DEFSYM (Qinternal__syntax_propertize, "internal--syntax-propertize");
   Fmake_variable_buffer_local (intern ("syntax-propertize--done"));
 
+  DEFSYM (Qsyntax_ppss_flush_cache, "syntax-ppss-flush-cache");
+
   words_include_escapes = 0;
   DEFVAR_BOOL ("words-include-escapes", words_include_escapes,
 	       doc: /* Non-nil means `forward-word', etc., should treat escape chars part of words.  */);
@@ -3790,6 +4143,8 @@ In both cases, LIMIT bounds the search. */);
   DEFSYM (Qcomment_end_can_be_escaped, "comment-end-can-be-escaped");
   Fmake_variable_buffer_local (Qcomment_end_can_be_escaped);
 
+  defsubr (&Sleast_literal_difference_between_syntax_tables);
+  defsubr (&Ssyntax_tables_literally_different_p);
   defsubr (&Ssyntax_table_p);
   defsubr (&Ssyntax_table);
   defsubr (&Sstandard_syntax_table);
diff --git a/src/syntax.h b/src/syntax.h
index 2171cbbba4..1771ae4728 100644
--- a/src/syntax.h
+++ b/src/syntax.h
@@ -28,6 +28,10 @@ INLINE_HEADER_BEGIN
 
 extern void update_syntax_table (ptrdiff_t, EMACS_INT, bool, Lisp_Object);
 extern void update_syntax_table_forward (ptrdiff_t, bool, Lisp_Object);
+extern void check_syntax_cache_for_prop (ptrdiff_t, Lisp_Object,
+                                         Lisp_Object, Lisp_Object);
+
+
 
 /* The standard syntax table is stored where it will automatically
    be used in all new buffers.  */
diff --git a/src/textprop.c b/src/textprop.c
index 984f2e6640..cd56d8b12c 100644
--- a/src/textprop.c
+++ b/src/textprop.c
@@ -21,6 +21,7 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
 #include "lisp.h"
 #include "intervals.h"
+#include "syntax.h"
 #include "buffer.h"
 #include "window.h"
 
@@ -340,6 +341,12 @@ set_properties (Lisp_Object properties, INTERVAL interval, Lisp_Object object)
 	    record_property_change (interval->position, LENGTH (interval),
 				    XCAR (sym), XCAR (value),
 				    object);
+            check_syntax_cache_for_prop
+              (interval->position, XCAR (sym), XCAR (value), object);
+            if (!EQ (property_value (properties, XCAR (sym)), Qunbound))
+              check_syntax_cache_for_prop
+                (interval->position, XCAR (sym),
+                 property_value (properties, XCAR (sym)), object);
 	  }
 
       /* For each new property that has no value at all in the old plist,
@@ -352,6 +359,8 @@ set_properties (Lisp_Object properties, INTERVAL interval, Lisp_Object object)
 	    record_property_change (interval->position, LENGTH (interval),
 				    XCAR (sym), Qnil,
 				    object);
+            check_syntax_cache_for_prop
+                (interval->position, XCAR (sym), XCAR (value), object);
 	  }
     }
 
@@ -406,6 +415,10 @@ add_properties (Lisp_Object plist, INTERVAL i, Lisp_Object object,
 	      {
 		record_property_change (i->position, LENGTH (i),
 					sym1, Fcar (this_cdr), object);
+                check_syntax_cache_for_prop
+                    (i->position, sym1, Fcar (this_cdr), object);
+                check_syntax_cache_for_prop
+                    (i->position, sym1, val1, object);
 	      }
 
 	    /* I's property has a different value -- change it */
@@ -442,6 +455,8 @@ add_properties (Lisp_Object plist, INTERVAL i, Lisp_Object object,
 	    {
 	      record_property_change (i->position, LENGTH (i),
 				      sym1, Qnil, object);
+              check_syntax_cache_for_prop
+                (i->position, sym1, val1, object);
 	    }
 	  set_interval_plist (i, Fcons (sym1, Fcons (val1, i->plist)));
 	  changed = true;
@@ -475,11 +490,14 @@ remove_properties (Lisp_Object plist, Lisp_Object list, INTERVAL i, Lisp_Object
       /* First, remove the symbol if it's at the head of the list */
       while (CONSP (current_plist) && EQ (sym, XCAR (current_plist)))
 	{
-	  if (BUFFERP (object))
-	    record_property_change (i->position, LENGTH (i),
-				    sym, XCAR (XCDR (current_plist)),
-				    object);
-
+          if (BUFFERP (object))
+            {
+              record_property_change (i->position, LENGTH (i),
+                                      sym, XCAR (XCDR (current_plist)),
+                                      object);
+              check_syntax_cache_for_prop
+                (i->position, sym, XCAR (XCDR (current_plist)), object);
+            }
 	  current_plist = XCDR (XCDR (current_plist));
 	  changed = true;
 	}
@@ -492,8 +510,12 @@ remove_properties (Lisp_Object plist, Lisp_Object list, INTERVAL i, Lisp_Object
 	  if (CONSP (this) && EQ (sym, XCAR (this)))
 	    {
 	      if (BUFFERP (object))
-		record_property_change (i->position, LENGTH (i),
-					sym, XCAR (XCDR (this)), object);
+                {
+                  record_property_change (i->position, LENGTH (i),
+                                          sym, XCAR (XCDR (this)), object);
+                  check_syntax_cache_for_prop
+                    (i->position, sym, XCAR (XCDR (this)), object);
+                }
 
 	      Fsetcdr (XCDR (tail2), XCDR (XCDR (this)));
 	      changed = true;


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 17 Feb 2018 11:06:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 17 06:06:30 2018
Received: from localhost ([127.0.0.1]:47494 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1en0K6-0007AC-Ox
	for submit <at> debbugs.gnu.org; Sat, 17 Feb 2018 06:06:30 -0500
Received: from colin.muc.de ([193.149.48.1]:41603 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1en0K5-0007A4-43
 for 30393 <at> debbugs.gnu.org; Sat, 17 Feb 2018 06:06:29 -0500
Received: (qmail 17926 invoked by uid 3782); 17 Feb 2018 11:06:27 -0000
Received: from acm.muc.de (p548C6567.dip0.t-ipconnect.de [84.140.101.103]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Sat, 17 Feb 2018 12:06:26 +0100
Received: (qmail 5687 invoked by uid 1000); 17 Feb 2018 10:54:31 -0000
Date: Sat, 17 Feb 2018 10:54:31 +0000
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180217105431.GA4595@ACM>
References: <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM> <8360752gj8.fsf@HIDDEN>
 <20180211124930.GB4515@ACM> <83d11b1ozj.fsf@HIDDEN>
 <20180214210022.GA10559@ACM>
 <887b550a-66bb-a976-ae8e-e4ffac9bd811@HIDDEN>
 <20180216174331.GA9007@ACM>
 <756b8ae5-7596-ca52-32cd-a2acb2ce1d38@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <756b8ae5-7596-ca52-32cd-a2acb2ce1d38@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: Eli Zaretskii <eliz@HIDDEN>, npostavs@HIDDEN,
 monnier@HIDDEN, 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Dmitry.

On Sat, Feb 17, 2018 at 04:16:31 +0200, Dmitry Gutov wrote:
> On 2/16/18 7:43 PM, Alan Mackenzie wrote:

> > Yes, you're right.  How about .....

> >      ...., commands seeking the start of a defun will stop at opening
> >      parentheses or braces at column zero which aren't in a comment or
> >      string.

> > ?  It's more accurate, if less elegant, than what has been committed.

> I think it's better, thank you. Though more verbose, it addresses the 
> issue that has been a problem for years.

Not years.  Decades.  :-)

I've committed that fix.  Thanks for pointing it out.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 17 Feb 2018 02:16:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 16 21:16:43 2018
Received: from localhost ([127.0.0.1]:47375 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ems3O-00078A-KN
	for submit <at> debbugs.gnu.org; Fri, 16 Feb 2018 21:16:43 -0500
Received: from mail-wm0-f45.google.com ([74.125.82.45]:55717)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1ems3M-00077x-SN
 for 30393 <at> debbugs.gnu.org; Fri, 16 Feb 2018 21:16:41 -0500
Received: by mail-wm0-f45.google.com with SMTP id h74so6140830wme.5
 for <30393 <at> debbugs.gnu.org>; Fri, 16 Feb 2018 18:16:40 -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=PqMznykZiRkpFq39ZK8kkWBcKDUDthI308KxiXsNAZ0=;
 b=tJeqkwXut4WJ8MvM1wP99iGZi73BLE/FkosI8RVuudvp1E8+21CmIinTmQrVNDnupZ
 FrOvIJ+mBa+xmRF9xF0VVc+C8rzXGW4Y1n5HCBj00aQYE5PbjjMcs1Gcu5Tr98x8N2LV
 1KErjKiDNcF7p8iyRkUWjGmLufMuPafau3rz7NcSJYN4Mt7+ZTARKosmnbk3Xu1weKFt
 Kd7Y+X3gRBEZFS06YIDrIpWCWpBVorjC5PuXSPIn/CMlqjN6RArU6qlt0VPk8yn+SAuQ
 jtVxkYpyK6EFoP2wafbLAqu1W953BbHj7G8Y1dqjv0MUOvP/XZNEUewxZE7K7WGB/kY4
 2RVw==
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=PqMznykZiRkpFq39ZK8kkWBcKDUDthI308KxiXsNAZ0=;
 b=aBzp9nIZgnBC08EHioqpQW0AQcrO8D2fQK7UCXijf8kx4hr7RoJZbTEhWNtMEUtZBR
 xBlugO/+jqH+IhY0yWNU3gqiCT4JGCRRr2wpx+wwemrwZvQENs1jwspG9XleN1D9h2yd
 ZGeudbKri5FIWEt8b+ie8jJ867xM9mCEz5D5QX2GkgVc48Ylw0UAxzoPrrlwZJcj4Jgp
 nW1aZqrM67P6CUGbW8vIL36z8t3Fi8tOEr4R1HCpJqZLbjkwwbtHKuLUOzJwsfw9CJCt
 0nMBIW/2e1KxbD4sW7/nkXSIm0uKS0FXgENbnniSbxIdIhFxvP+opNdgo/rgzdwcOINe
 eJhw==
X-Gm-Message-State: APf1xPA2k9jrtepwTrNtWifNSKvTnGj0dxlW+lbRpWoDiqVPHDHZaio4
 WkULFhBuo89z34RdZ/0Q9SQ=
X-Google-Smtp-Source: AH8x224d/o6KhP22XOysDb0wE1bB00+BWXXMHiP1cvlQASPlLP/4pod+qDVMXa3Vq9cFeBkn1kiFrA==
X-Received: by 10.28.146.197 with SMTP id u188mr6305999wmd.124.1518833795030; 
 Fri, 16 Feb 2018 18:16:35 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id s14sm2481106wmb.45.2018.02.16.18.16.33
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 16 Feb 2018 18:16:33 -0800 (PST)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
To: Alan Mackenzie <acm@HIDDEN>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN> <20180210112654.GA4537@ACM>
 <8360752gj8.fsf@HIDDEN> <20180211124930.GB4515@ACM> <83d11b1ozj.fsf@HIDDEN>
 <20180214210022.GA10559@ACM> <887b550a-66bb-a976-ae8e-e4ffac9bd811@HIDDEN>
 <20180216174331.GA9007@ACM>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <756b8ae5-7596-ca52-32cd-a2acb2ce1d38@HIDDEN>
Date: Sat, 17 Feb 2018 04:16:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101
 Thunderbird/59.0
MIME-Version: 1.0
In-Reply-To: <20180216174331.GA9007@ACM>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 30393
Cc: Eli Zaretskii <eliz@HIDDEN>, npostavs@HIDDEN,
 monnier@HIDDEN, 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

On 2/16/18 7:43 PM, Alan Mackenzie wrote:

> Yes, you're right.  How about .....
> 
>      ...., commands seeking the start of a defun will stop at opening
>      parentheses or braces at column zero which aren't in a comment or
>      string.
> 
> ?  It's more accurate, if less elegant, than what has been committed.

I think it's better, thank you. Though more verbose, it addresses the 
issue that has been a problem for years.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 16 Feb 2018 17:55:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 16 12:55:23 2018
Received: from localhost ([127.0.0.1]:47160 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1emkEF-0001MM-Ng
	for submit <at> debbugs.gnu.org; Fri, 16 Feb 2018 12:55:23 -0500
Received: from colin.muc.de ([193.149.48.1]:62910 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1emkEE-0001MD-4y
 for 30393 <at> debbugs.gnu.org; Fri, 16 Feb 2018 12:55:22 -0500
Received: (qmail 99806 invoked by uid 3782); 16 Feb 2018 17:55:20 -0000
Received: from acm.muc.de (p548C7789.dip0.t-ipconnect.de [84.140.119.137]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Fri, 16 Feb 2018 18:55:18 +0100
Received: (qmail 9047 invoked by uid 1000); 16 Feb 2018 17:43:31 -0000
Date: Fri, 16 Feb 2018 17:43:31 +0000
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180216174331.GA9007@ACM>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM> <8360752gj8.fsf@HIDDEN>
 <20180211124930.GB4515@ACM> <83d11b1ozj.fsf@HIDDEN>
 <20180214210022.GA10559@ACM>
 <887b550a-66bb-a976-ae8e-e4ffac9bd811@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <887b550a-66bb-a976-ae8e-e4ffac9bd811@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: Eli Zaretskii <eliz@HIDDEN>, npostavs@HIDDEN,
 monnier@HIDDEN, 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Dmitry.

On Fri, Feb 16, 2018 at 13:52:03 +0200, Dmitry Gutov wrote:
> On 2/14/18 11:00 PM, Alan Mackenzie wrote:

> >      ...If this
> >      option is set to `t' (the default), commands seeking the start of a
> >      defun will stop at opening parentheses or braces at column zero.

> Is this still true actually? On master, in emacs-lisp-mode, with point after

> (defun asdasd ()
>    "
> (")


> C-M-a moves to before the defun, and not inside the docstring.

Yes, you're right.  How about .....

    ...., commands seeking the start of a defun will stop at opening
    parentheses or braces at column zero which aren't in a comment or
    string.

?  It's more accurate, if less elegant, than what has been committed.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 16 Feb 2018 11:52:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 16 06:52:15 2018
Received: from localhost ([127.0.0.1]:45749 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1emeYp-0003H9-I3
	for submit <at> debbugs.gnu.org; Fri, 16 Feb 2018 06:52:15 -0500
Received: from mail-wm0-f48.google.com ([74.125.82.48]:54516)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1emeYm-0003Gt-Li
 for 30393 <at> debbugs.gnu.org; Fri, 16 Feb 2018 06:52:12 -0500
Received: by mail-wm0-f48.google.com with SMTP id z81so2681127wmb.4
 for <30393 <at> debbugs.gnu.org>; Fri, 16 Feb 2018 03:52:12 -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=Ot6WtvEdc3Zchy2+j/Ux+td/+tBl6U0PH2X04/Xqszw=;
 b=oy2uFQkw6tAU/l8hXv0uT0CobdkwP+de3BLYGF1b6gBFU7Ki22z3brtmZ9g7Z8JTx1
 iEnOD7Utg1VVPle7BZ48/9Ne9pUgTF5dDoEtZOX/fKpE8JvBoFH+M6COZrE6PpY4xwT+
 Lkw6sP52GishKeIb9gdEVmVPux4mNRbtWOarNhikgJv1fm2uKfup/AaB8b0IBwWYyBFT
 GCfvF3pdnlJfHHZMyolDADAlMN5mLnhZWnsWQKP1W5co7eMX07AEl6Fqvh5WeIW9OcaU
 sSJFTPPyreP5fb550wVtfVFowJz/y2QjNZAiofSITI6A//CeLSHPgyzrzO+5IJ/VcNo9
 1rfA==
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=Ot6WtvEdc3Zchy2+j/Ux+td/+tBl6U0PH2X04/Xqszw=;
 b=dOvzmSN40idysaSp6CWtFJcDnTqwSw3MgwkMnBENA9s8Z1YL+aUXR4liT7WwVxGihh
 8EcPy+jsm7dByBNhPnwyOVdINGTKcFimUiIYLn3hDUj7DnfxH369DE9vjEP2c9mUBlF0
 t63+Y+WKdfp5elgE9KoOMsvfBA2EJPeX/nuLZ1iIZ1m447a2g7zvzPdqwUXvj6kc7ykB
 vcN86tMD92PE39+60+74UdBEVywGTBoBZTyuvmi9VP5RMVyJjxO4n7+d+qcOtZmMc6xe
 z0XulKx3S1SKG/mKWt+eZEixujMaH7t5jxqPo+xMSH2dDF6tO69LlbbMqssGK2ngNAGB
 RCWw==
X-Gm-Message-State: APf1xPBp16Llc3tPbacNCIj32ZvTyyNFEE7CaA/JXw36eC5NPqpKCODg
 Ljn+LO11zQj2cXU1MCfNHk8=
X-Google-Smtp-Source: AH8x2275JJoSerdQ8UBNqZ2NlMMIvVwYkGEst3rRhz3PIZkNi/R1IRC93kqzY6cKPNdS6XkWdGL7eg==
X-Received: by 10.28.17.141 with SMTP id 135mr4321296wmr.80.1518781926774;
 Fri, 16 Feb 2018 03:52:06 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.193])
 by smtp.googlemail.com with ESMTPSA id r1sm16103635wmg.22.2018.02.16.03.52.04
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 16 Feb 2018 03:52:05 -0800 (PST)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
To: Alan Mackenzie <acm@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN> <20180210112654.GA4537@ACM>
 <8360752gj8.fsf@HIDDEN> <20180211124930.GB4515@ACM> <83d11b1ozj.fsf@HIDDEN>
 <20180214210022.GA10559@ACM>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <887b550a-66bb-a976-ae8e-e4ffac9bd811@HIDDEN>
Date: Fri, 16 Feb 2018 13:52:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101
 Thunderbird/59.0
MIME-Version: 1.0
In-Reply-To: <20180214210022.GA10559@ACM>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, monnier@HIDDEN,
 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

On 2/14/18 11:00 PM, Alan Mackenzie wrote:

>      ...If this
>      option is set to `t' (the default), commands seeking the start of a
>      defun will stop at opening parentheses or braces at column zero.

Is this still true actually? On master, in emacs-lisp-mode, with point after

(defun asdasd ()
   "
(")


C-M-a moves to before the defun, and not inside the docstring.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 15 Feb 2018 17:39:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 15 12:39:21 2018
Received: from localhost ([127.0.0.1]:45055 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1emNVB-0002gY-L6
	for submit <at> debbugs.gnu.org; Thu, 15 Feb 2018 12:39:21 -0500
Received: from eggs.gnu.org ([208.118.235.92]:60319)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1emNV9-0002gL-89
 for 30393 <at> debbugs.gnu.org; Thu, 15 Feb 2018 12:39:19 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1emNUz-0002YP-Jl
 for 30393 <at> debbugs.gnu.org; Thu, 15 Feb 2018 12:39:14 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35472)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1emNUz-0002YI-G2; Thu, 15 Feb 2018 12:39:09 -0500
Received: from [176.228.60.248] (port=2459 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1emNUy-0003hv-Rw; Thu, 15 Feb 2018 12:39:09 -0500
Date: Thu, 15 Feb 2018 19:39:06 +0200
Message-Id: <834lmiw3t1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
In-reply-to: <20180214210022.GA10559@ACM> (message from Alan Mackenzie on Wed, 
 14 Feb 2018 21:00:22 +0000)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM> <8360752gj8.fsf@HIDDEN>
 <20180211124930.GB4515@ACM> <83d11b1ozj.fsf@HIDDEN>
 <20180214210022.GA10559@ACM>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, 30393 <at> debbugs.gnu.org,
 monnier@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Wed, 14 Feb 2018 21:00:22 +0000
> Cc: dgutov@HIDDEN, npostavs@HIDDEN,
>   monnier@HIDDEN, 30393 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm@HIDDEN>
> 
>     26.2.1 Left Margin Convention
>     -----------------------------
> 
>     Many programming-language modes have traditionally assumed that any
>     opening delimiter found at the left margin is the start of a top-level
>     definition, or defun.  So, by default, commands which seek the beginning
>     of a defun accept such a delimiter as signifying that position.
> 
>        If you want to override this convention, you can do so by setting the
>     user option `open-paren-in-column-0-is-defun-start' to `nil'.  If this
>     option is set to `t' (the default), commands seeking the start of a
>     defun will stop at opening parentheses or braces at column zero.  When
>     it is `nil', defuns are found by searching for parens or braces at the
>     outermost level.  Since low-level Emacs routines no longer depend on
>     this convention, you usually won't need to change
>     `open-paren-in-column-0-is-defun-start' from its default.

This is fine by me, but please replace "delimiters" in the beginning
of the text with "opening parenthesis or brace", for clarity.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 14 Feb 2018 21:11:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 14 16:11:51 2018
Received: from localhost ([127.0.0.1]:43316 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1em4LG-0001LN-SJ
	for submit <at> debbugs.gnu.org; Wed, 14 Feb 2018 16:11:51 -0500
Received: from colin.muc.de ([193.149.48.1]:55625 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1em4LF-0001LF-2z
 for 30393 <at> debbugs.gnu.org; Wed, 14 Feb 2018 16:11:49 -0500
Received: (qmail 27506 invoked by uid 3782); 14 Feb 2018 21:11:47 -0000
Received: from acm.muc.de (p548C7683.dip0.t-ipconnect.de [84.140.118.131]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Wed, 14 Feb 2018 22:11:45 +0100
Received: (qmail 10599 invoked by uid 1000); 14 Feb 2018 21:00:22 -0000
Date: Wed, 14 Feb 2018 21:00:22 +0000
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180214210022.GA10559@ACM>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM> <8360752gj8.fsf@HIDDEN>
 <20180211124930.GB4515@ACM> <83d11b1ozj.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <83d11b1ozj.fsf@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, 30393 <at> debbugs.gnu.org,
 monnier@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Eli.

On Sun, Feb 11, 2018 at 18:16:00 +0200, Eli Zaretskii wrote:
> > Date: Sun, 11 Feb 2018 12:49:30 +0000
> > Cc: dgutov@HIDDEN, npostavs@HIDDEN,
> >   monnier@HIDDEN, 30393 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm@HIDDEN>

> > > This text is not needed.  The original text, which you deleted,
> > > described how to avoid a real problem; if that problem no longer
> > > exists, we should just delete that text.  If that problem does exist
> > > in some modes, we should leave that text as it was, with a better
> > > description of what modes are still subject to these problems.

> > > But describing something that is no longer done by Emacs is just waste
> > > of paper.

> > Perhaps the proposed fix was somewhat prolix ("long winded").  But, in a
> > sense, we're providing a new feature, the ability to write syntactically
> > correct parens.  If we don't mention this, people won't notice.
> > Occasionally somebody will remember the previous restriction, try to
> > look it up in the manual, and end up puzzled.

> > How about a compromise, and replacing those two long paragraphs with a
> > simple sentence such as:

> >     From Emacs 27.1, you can write opening parens at column zero without
> >     problems.

> > > Overall, I must say I'm confused regarding the purpose of this patch.
> > > What does it try to accomplish?

> > To note that the documented previous restrictions on parens in column 0
> > no longer hold.

> The right place for such stuff is in NEWS.

> > I suppose we really want to mark this part of the manual as obsolete,
> > but we've got no mechanism for doing this.  Besides,
> > open-paren-in-column-0-is-defun-start still has _some_ functionality.

> The variable should have some minimal description with a note that
> using it nowadays is seldom needed.  That should be enough to drive
> your point home, I think.

In accordance with that, then, I propose the following as the complete
emacs manual page "Left Margin Convention":

    26.2.1 Left Margin Convention
    -----------------------------

    Many programming-language modes have traditionally assumed that any
    opening delimiter found at the left margin is the start of a top-level
    definition, or defun.  So, by default, commands which seek the beginning
    of a defun accept such a delimiter as signifying that position.

       If you want to override this convention, you can do so by setting the
    user option `open-paren-in-column-0-is-defun-start' to `nil'.  If this
    option is set to `t' (the default), commands seeking the start of a
    defun will stop at opening parentheses or braces at column zero.  When
    it is `nil', defuns are found by searching for parens or braces at the
    outermost level.  Since low-level Emacs routines no longer depend on
    this convention, you usually won't need to change
    `open-paren-in-column-0-is-defun-start' from its default.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 12 Feb 2018 20:45:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 12 15:45:45 2018
Received: from localhost ([127.0.0.1]:40087 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1elKyv-0000Er-75
	for submit <at> debbugs.gnu.org; Mon, 12 Feb 2018 15:45:45 -0500
Received: from chene.dit.umontreal.ca ([132.204.246.20]:44076)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1elKys-0000Ei-8t
 for 30393 <at> debbugs.gnu.org; Mon, 12 Feb 2018 15:45:43 -0500
Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242])
 by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1CKjeec022261;
 Mon, 12 Feb 2018 15:45:40 -0500
Received: by lechazo.home (Postfix, from userid 20848)
 id 8062964B86; Mon, 12 Feb 2018 15:45:40 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <jwvsha6c4z1.fsf-monnier+emacsbugs@HIDDEN>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
 <20180212183800.GA5601@ACM>
Date: Mon, 12 Feb 2018 15:45:40 -0500
In-Reply-To: <20180212183800.GA5601@ACM> (Alan Mackenzie's message of "Mon, 12
 Feb 2018 18:38:00 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 2 Rules triggered
	EDT_SA_DN_PASS=0, RV6220=0
X-NAI-Spam-Version: 2.3.0.9418 : core <6220> : inlines <6390> : streams
 <1778796> : uri <2591661>
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 30393
Cc: Noam Postavsky <npostavs@HIDDEN>, 30393 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

> It has occurred to me over the last day or two that I have already
> solved these problems (basically, with your first approach, hooking into
> set-syntax-table and friends) in the comment-cache branch, and that the
> approach taken could be used more or less unchanged in the current
> master.

If you can reuse existing code, even better.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 12 Feb 2018 18:49:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 12 13:49:04 2018
Received: from localhost ([127.0.0.1]:40010 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1elJ9y-0005zY-OX
	for submit <at> debbugs.gnu.org; Mon, 12 Feb 2018 13:49:04 -0500
Received: from colin.muc.de ([193.149.48.1]:16381 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1elJ9w-0005z8-4I
 for 30393 <at> debbugs.gnu.org; Mon, 12 Feb 2018 13:49:00 -0500
Received: (qmail 78966 invoked by uid 3782); 12 Feb 2018 18:48:58 -0000
Received: from acm.muc.de (p548C77BB.dip0.t-ipconnect.de [84.140.119.187]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Mon, 12 Feb 2018 19:48:57 +0100
Received: (qmail 5898 invoked by uid 1000); 12 Feb 2018 18:38:00 -0000
Date: Mon, 12 Feb 2018 18:38:00 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180212183800.GA5601@ACM>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
 <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: Noam Postavsky <npostavs@HIDDEN>, 30393 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Stefan

On Sun, Feb 11, 2018 at 17:53:38 -0500, Stefan Monnier wrote:
> > OK, but I suspect in practice, this would be impossible to debug for
> > lack of reproducibility.

> Those problems can be hard to debug, indeed.  But an inf-loop should at
> least be diagnosed as such fairly easily (even if its origin can be
> difficult to track down), so I don't think "in practice I haven't bumped
> into this problem yet" just because those problems stay undetected.

> > Another definite bug is that the syntax-ppss cache is not flushed when
> > the syntax-table is changed, whether with set-syntax-table or
> > modify-syntax-entry.

> That's right.  I haven't bumped into such issues yet, but here (contrary
> to the above problem) it might very well be because the error
> stays undetected.

.... and of course, the need to flush the cache when a syntax-table text
property is applied or removed.

> > This is critical, now that primitives depend on this cache.

> I can see two approaches to solve this problem:
> - hook into set-syntax-table and modify-syntax-entry or something
>   like that.  This will make it work right everywhere automatically, but
>   I'm afraid it could turn out to be difficult to make it efficient
>   (because of the cost of the tests needed to detect changes and more
>   importantly because of excessive flushing of the syntax-ppss cache).
> - provide new functions to let packages tell syntax-ppss about
>   such things.  E.g. a macro `with-new-syntax-context` (which would
>   be treated a bit like narrowing, maybe).  This would require changes
>   to packages that suffer from this problem but should give
>   better performance.

> I'd prefer the second option, but at the same time, I'm not completely sure
> what are the "typical" problem cases (which makes it hard to come up
> with good new functions/macros) other than the case where we use
> with-syntax-table (which is sometimes combined with a local narrowing)
> but some of those only tweak the "word-vs-symbol-vs-punctuation"
> settings so should ideally not flush the syntax-ppss cache.

> Also I don't actually know whether the "fully automatic" approach would
> actually turn out to be too expensive, it's just a gut feeling.

> > Would you please fix this, Stefan.

> It's fairly high up on my todo list, but I'm kinda swamped right now.

It has occurred to me over the last day or two that I have already
solved these problems (basically, with your first approach, hooking into
set-syntax-table and friends) in the comment-cache branch, and that the
approach taken could be used more or less unchanged in the current
master.

For set-syntax-table, it compares the old and the new syntax tables to
see if they are "literally the same" (i.e. process strings and comments
identically) or "literally different", and only in the latter case does
it flush the cache.  These comparisons, which are expensive, are cached
inside the syntax-tables (in "extra slots").  Similarly, on
modify-syntax-entry, the cache is flushed iff the change affects
literals.

Similarly, on setting or deleting a syntax-table text property, the
cache is flushed from that point if the change affects literals.  This
happens regardless of the setting of inhibit-modification-hooks, etc.

It is a fact that the vast bulk of libraries which use syntax-ppss use
only elements 3, 4, and 8, i.e. the ones relevant to literals, and
ignore everything else.  For these the scheme outlined above is
rigorous.  I have timed it in the comment-cache branch, scanning through
.../src/xdisp.c displaying each screen, and found no difference to the
approach without comment-cache.

For those few libraries which do use the full capabilities of the
parsing state, we would need to flush the cache on all
set-syntax-table's and so on.  Maybe.  Maybe this would be too expensive
in run time.

So the interface I propose would be two abnormal hooks, one for
"literally important" changes to the syntax, and the other for other
changes to the syntax.  The hook functions would take an optional
argument which would be nil for changes to the syntax table, or a buffer
position where a syntax-table property is being changed.

Mostly, only the first of these hooks need be used, the standard
function on them being syntax-ppss's flush function.  Major modes could
add syntax-ppss's flush function to the second hook (possibly through
some nice interface), should they use the non-literal parts of the parse
state.

One or two incidental changes would be needed, for example to fix the
infinite recursion in printing syntax-tables, caused by the mutual
presence of "literally the same/different" syntax tables in the extra
slots.  This would not be difficult.

Then, finally, if we can be bothered, we could put in a mechanism to
deal with changes in parse-sexp-lookup-properties and
parse-sexp-ignore-comments.

What do you think?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 11 Feb 2018 22:53:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 17:53:44 2018
Received: from localhost ([127.0.0.1]:38696 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1el0VE-0003Ko-DQ
	for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 17:53:44 -0500
Received: from chene.dit.umontreal.ca ([132.204.246.20]:33904)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1el0VC-0003Kg-CM
 for 30393 <at> debbugs.gnu.org; Sun, 11 Feb 2018 17:53:43 -0500
Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242])
 by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1BMrd8c026305;
 Sun, 11 Feb 2018 17:53:39 -0500
Received: by ceviche.home (Postfix, from userid 20848)
 id 8788B6630B; Sun, 11 Feb 2018 17:53:38 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <jwvo9kvf92g.fsf-monnier+emacsbugs@HIDDEN>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
 <20180211103610.GA4515@ACM>
Date: Sun, 11 Feb 2018 17:53:38 -0500
In-Reply-To: <20180211103610.GA4515@ACM> (Alan Mackenzie's message of "Sun, 11
 Feb 2018 10:36:10 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 2 Rules triggered
	EDT_SA_DN_PASS=0, RV6219=0
X-NAI-Spam-Version: 2.3.0.9418 : core <6219> : inlines <6389> : streams
 <1778709> : uri <2591122>
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 30393
Cc: Noam Postavsky <npostavs@HIDDEN>, 30393 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

> OK, but I suspect in practice, this would be impossible to debug for
> lack of reproducibility.

Those problems can be hard to debug, indeed.  But an inf-loop should at
least be diagnosed as such fairly easily (even if its origin can be
difficult to track down), so I don't think "in practice I haven't bumped
into this problem yet" just because those problems stay undetected.

> Another definite bug is that the syntax-ppss cache is not flushed when
> the syntax-table is changed, whether with set-syntax-table or
> modify-syntax-entry.

That's right.  I haven't bumped into such issues yet, but here (contrary
to the above problem) it might very well be because the error
stays undetected.

> This is critical, now that primitives depend on this cache.

I can see two approaches to solve this problem:
- hook into set-syntax-table and modify-syntax-entry or something
  like that.  This will make it work right everywhere automatically, but
  I'm afraid it could turn out to be difficult to make it efficient
  (because of the cost of the tests needed to detect changes and more
  importantly because of excessive flushing of the syntax-ppss cache).
- provide new functions to let packages tell syntax-ppss about
  such things.  E.g. a macro `with-new-syntax-context` (which would
  be treated a bit like narrowing, maybe).  This would require changes
  to packages that suffer from this problem but should give
  better performance.

I'd prefer the second option, but at the same time, I'm not completely sure
what are the "typical" problem cases (which makes it hard to come up
with good new functions/macros) other than the case where we use
with-syntax-table (which is sometimes combined with a local narrowing)
but some of those only tweak the "word-vs-symbol-vs-punctuation"
settings so should ideally not flush the syntax-ppss cache.

Also I don't actually know whether the "fully automatic" approach would
actually turn out to be too expensive, it's just a gut feeling.

> Would you please fix this, Stefan.

It's fairly high up on my todo list, but I'm kinda swamped right now.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 11 Feb 2018 16:16:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 11:16:30 2018
Received: from localhost ([127.0.0.1]:38516 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekuIk-0002mP-OY
	for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 11:16:30 -0500
Received: from eggs.gnu.org ([208.118.235.92]:35355)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1ekuIi-0002mC-8N
 for 30393 <at> debbugs.gnu.org; Sun, 11 Feb 2018 11:16:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1ekuIZ-0005aM-Py
 for 30393 <at> debbugs.gnu.org; Sun, 11 Feb 2018 11:16:19 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53508)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1ekuIZ-0005aC-LX; Sun, 11 Feb 2018 11:16:15 -0500
Received: from [176.228.60.248] (port=1032 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1ekuIY-0006gH-TV; Sun, 11 Feb 2018 11:16:15 -0500
Date: Sun, 11 Feb 2018 18:16:00 +0200
Message-Id: <83d11b1ozj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
In-reply-to: <20180211124930.GB4515@ACM> (message from Alan Mackenzie on Sun, 
 11 Feb 2018 12:49:30 +0000)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM> <8360752gj8.fsf@HIDDEN>
 <20180211124930.GB4515@ACM>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, 30393 <at> debbugs.gnu.org,
 monnier@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Sun, 11 Feb 2018 12:49:30 +0000
> Cc: dgutov@HIDDEN, npostavs@HIDDEN,
>   monnier@HIDDEN, 30393 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm@HIDDEN>
> 
> > This text is not needed.  The original text, which you deleted,
> > described how to avoid a real problem; if that problem no longer
> > exists, we should just delete that text.  If that problem does exist
> > in some modes, we should leave that text as it was, with a better
> > description of what modes are still subject to these problems.
> 
> > But describing something that is no longer done by Emacs is just waste
> > of paper.
> 
> Perhaps the proposed fix was somewhat prolix ("long winded").  But, in a
> sense, we're providing a new feature, the ability to write syntactically
> correct parens.  If we don't mention this, people won't notice.
> Occasionally somebody will remember the previous restriction, try to
> look it up in the manual, and end up puzzled.
> 
> How about a compromise, and replacing those two long paragraphs with a
> simple sentence such as:
> 
>     From Emacs 27.1, you can write opening parens at column zero without
>     problems.
> 
> > Overall, I must say I'm confused regarding the purpose of this patch.
> > What does it try to accomplish?
> 
> To note that the documented previous restrictions on parens in column 0
> no longer hold.

The right place for such stuff is in NEWS.

> I suppose we really want to mark this part of the manual as obsolete,
> but we've got no mechanism for doing this.  Besides,
> open-paren-in-column-0-is-defun-start still has _some_ functionality.

The variable should have some minimal description with a note that
using it nowadays is seldom needed.  That should be enough to drive
your point home, I think.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 11 Feb 2018 13:00:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 08:00:27 2018
Received: from localhost ([127.0.0.1]:37670 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekrF5-0004gR-2y
	for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 08:00:27 -0500
Received: from colin.muc.de ([193.149.48.1]:35751 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1ekrF3-0004gJ-RJ
 for 30393 <at> debbugs.gnu.org; Sun, 11 Feb 2018 08:00:26 -0500
Received: (qmail 95998 invoked by uid 3782); 11 Feb 2018 13:00:24 -0000
Received: from acm.muc.de (p548C70D3.dip0.t-ipconnect.de [84.140.112.211]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 11 Feb 2018 14:00:23 +0100
Received: (qmail 5755 invoked by uid 1000); 11 Feb 2018 12:49:30 -0000
Date: Sun, 11 Feb 2018 12:49:30 +0000
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180211124930.GB4515@ACM>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM> <8360752gj8.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8360752gj8.fsf@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, 30393 <at> debbugs.gnu.org,
 monnier@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Eli.

On Sat, Feb 10, 2018 at 14:08:43 +0200, Eli Zaretskii wrote:
> > Date: Sat, 10 Feb 2018 11:26:54 +0000
> > From: Alan Mackenzie <acm@HIDDEN>
> > Cc: Noam Postavsky <npostavs@HIDDEN>,
> > 	Stefan Monnier <monnier@HIDDEN>, 30393 <at> debbugs.gnu.org

> > +definition, or defun.  Therefore, in these modes, don't put an opening

> Which "these modes" does this refer to?  How will the reader know when
> to use this convention and when not?

Good point.  I suppose the answer is that there now aren't any such
modes.  Maybe this part of the section should be removed.

> > +  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.

> This text is not needed.  The original text, which you deleted,
> described how to avoid a real problem; if that problem no longer
> exists, we should just delete that text.  If that problem does exist
> in some modes, we should leave that text as it was, with a better
> description of what modes are still subject to these problems.

> But describing something that is no longer done by Emacs is just waste
> of paper.

Perhaps the proposed fix was somewhat prolix ("long winded").  But, in a
sense, we're providing a new feature, the ability to write syntactically
correct parens.  If we don't mention this, people won't notice.
Occasionally somebody will remember the previous restriction, try to
look it up in the manual, and end up puzzled.

How about a compromise, and replacing those two long paragraphs with a
simple sentence such as:

    From Emacs 27.1, you can write opening parens at column zero without
    problems.

> Overall, I must say I'm confused regarding the purpose of this patch.
> What does it try to accomplish?

To note that the documented previous restrictions on parens in column 0
no longer hold.

I suppose we really want to mark this part of the manual as obsolete,
but we've got no mechanism for doing this.  Besides,
open-paren-in-column-0-is-defun-start still has _some_ functionality.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 11 Feb 2018 10:47:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 11 05:47:06 2018
Received: from localhost ([127.0.0.1]:37639 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekpA2-00089a-9C
	for submit <at> debbugs.gnu.org; Sun, 11 Feb 2018 05:47:06 -0500
Received: from colin.muc.de ([193.149.48.1]:20562 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1ekpA1-00089S-GH
 for 30393 <at> debbugs.gnu.org; Sun, 11 Feb 2018 05:47:05 -0500
Received: (qmail 52324 invoked by uid 3782); 11 Feb 2018 10:47:04 -0000
Received: from acm.muc.de (p548C70D3.dip0.t-ipconnect.de [84.140.112.211]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 11 Feb 2018 11:47:02 +0100
Received: (qmail 5025 invoked by uid 1000); 11 Feb 2018 10:36:10 -0000
Date: Sun, 11 Feb 2018 10:36:10 +0000
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180211103610.GA4515@ACM>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
 <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: Noam Postavsky <npostavs@HIDDEN>, 30393 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hello, Stefan.

On Sat, Feb 10, 2018 at 09:58:55 -0500, Stefan Monnier wrote:
> > I'm not sure, but I think there's a danger of a recursive loop,

> Definitely.

> > should a major mode use a hook in syntax-ppss to calculate syntax-table
> > properties,

> You mean when a major mode sets syntax-propertize-function, right?

> > and that hook call forward-comment.

> The principle I tried to follow to avoid inf-loop is that each
> recursive-invocation of syntax-ppss should be on a strictly smaller
> buffer position.

> Another principle is that syntax-propertize moves
> syntax-propertize--done before calling syntax-propertize-function, so
> similarly each recursive invocation of syntax-propertize would have to
> be a strictly greater buffer position.

> So in a large buffer, this can recurse faily deep, but it shouldn't be
> able to recurse infinitely.

> This said, in practice I haven't bumped into this problem yet, so
> if/when it shows up, we'll see how it should be fixed.

OK, but I suspect in practice, this would be impossible to debug for
lack of reproducibility.

Another definite bug is that the syntax-ppss cache is not flushed when
the syntax-table is changed, whether with set-syntax-table or
modify-syntax-entry.

This is critical, now that primitives depend on this cache.

Would you please fix this, Stefan.

Thanks!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 10 Feb 2018 14:59:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 10 09:59:03 2018
Received: from localhost ([127.0.0.1]:37155 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekWcJ-00007Q-9M
	for submit <at> debbugs.gnu.org; Sat, 10 Feb 2018 09:59:03 -0500
Received: from chene.dit.umontreal.ca ([132.204.246.20]:34235)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1ekWcG-000070-If
 for 30393 <at> debbugs.gnu.org; Sat, 10 Feb 2018 09:59:01 -0500
Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242])
 by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1AEwuR2020352;
 Sat, 10 Feb 2018 09:58:57 -0500
Received: by ceviche.home (Postfix, from userid 20848)
 id 02F6F66352; Sat, 10 Feb 2018 09:58:55 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <jwvzi4ggaxh.fsf-monnier+emacsbugs@HIDDEN>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
 <20180210112654.GA4537@ACM>
Date: Sat, 10 Feb 2018 09:58:55 -0500
In-Reply-To: <20180210112654.GA4537@ACM> (Alan Mackenzie's message of "Sat, 10
 Feb 2018 11:26:54 +0000")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 2 Rules triggered
	EDT_SA_DN_PASS=0, RV6219=0
X-NAI-Spam-Version: 2.3.0.9418 : core <6219> : inlines <6389> : streams
 <1778582> : uri <2590354>
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 30393
Cc: Noam Postavsky <npostavs@HIDDEN>, 30393 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

> I'm not sure, but I think there's a danger of a recursive loop,

Definitely.

> should a major mode use a hook in syntax-ppss to calculate syntax-table
> properties,

You mean when a major mode sets syntax-propertize-function, right?

> and that hook call forward-comment.

The principle I tried to follow to avoid inf-loop is that each
recursive-invocation of syntax-ppss should be on a strictly smaller
buffer position.

Another principle is that syntax-propertize moves
syntax-propertize--done before calling syntax-propertize-function, so
similarly each recursive invocation of syntax-propertize would have to
be a strictly greater buffer position.

So in a large buffer, this can recurse faily deep, but it shouldn't be
able to recurse infinitely.

This said, in practice I haven't bumped into this problem yet, so
if/when it shows up, we'll see how it should be fixed.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 10 Feb 2018 12:09:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 10 07:09:11 2018
Received: from localhost ([127.0.0.1]:36166 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekTxv-00078k-Ce
	for submit <at> debbugs.gnu.org; Sat, 10 Feb 2018 07:09:11 -0500
Received: from eggs.gnu.org ([208.118.235.92]:50196)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1ekTxt-00078W-St
 for 30393 <at> debbugs.gnu.org; Sat, 10 Feb 2018 07:09:10 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1ekTxl-0006H3-No
 for 30393 <at> debbugs.gnu.org; Sat, 10 Feb 2018 07:09:04 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40566)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1ekTxl-0006Gl-Ju; Sat, 10 Feb 2018 07:09:01 -0500
Received: from [176.228.60.248] (port=3545 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1ekTxk-00043T-MW; Sat, 10 Feb 2018 07:09:01 -0500
Date: Sat, 10 Feb 2018 14:08:43 +0200
Message-Id: <8360752gj8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
In-reply-to: <20180210112654.GA4537@ACM> (message from Alan Mackenzie on Sat, 
 10 Feb 2018 11:26:54 +0000)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN> <20180210112654.GA4537@ACM>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 30393
Cc: npostavs@HIDDEN, 30393 <at> debbugs.gnu.org,
 monnier@HIDDEN, dgutov@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Sat, 10 Feb 2018 11:26:54 +0000
> From: Alan Mackenzie <acm@HIDDEN>
> Cc: Noam Postavsky <npostavs@HIDDEN>,
> 	Stefan Monnier <monnier@HIDDEN>, 30393 <at> debbugs.gnu.org
> 
> +definition, or defun.  Therefore, in these modes, don't put an opening

Which "these modes" does this refer to?  How will the reader know when
to use this convention and when not?

> +  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.

This text is not needed.  The original text, which you deleted,
described how to avoid a real problem; if that problem no longer
exists, we should just delete that text.  If that problem does exist
in some modes, we should leave that text as it was, with a better
description of what modes are still subject to these problems.

But describing something that is no longer done by Emacs is just waste
of paper.

Overall, I must say I'm confused regarding the purpose of this patch.
What does it try to accomplish?

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 10 Feb 2018 11:37:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 10 06:37:42 2018
Received: from localhost ([127.0.0.1]:36145 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekTTS-0006Ns-8b
	for submit <at> debbugs.gnu.org; Sat, 10 Feb 2018 06:37:42 -0500
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 <acm@HIDDEN>) id 1ekTTQ-0006Nj-9L
 for 30393 <at> debbugs.gnu.org; Sat, 10 Feb 2018 06:37:40 -0500
Received: (qmail 11634 invoked by uid 3782); 10 Feb 2018 11:37:39 -0000
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
Received: (qmail 21549 invoked by uid 1000); 10 Feb 2018 11:26:54 -0000
Date: Sat, 10 Feb 2018 11:26:54 +0000
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Message-ID: <20180210112654.GA4537@ACM>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
 <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
User-Agent: Mutt/1.7.2 (2016-11-26)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@HIDDEN>
X-Primary-Address: acm@HIDDEN
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: 30393 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
 Noam Postavsky <npostavs@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

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).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 10 Feb 2018 08:54:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 10 03:54:05 2018
Received: from localhost ([127.0.0.1]:36021 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekQv6-0000Pq-PE
	for submit <at> debbugs.gnu.org; Sat, 10 Feb 2018 03:54:04 -0500
Received: from mail-lf0-f42.google.com ([209.85.215.42]:35287)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1ekQv5-0000PL-GQ
 for 30393 <at> debbugs.gnu.org; Sat, 10 Feb 2018 03:54:03 -0500
Received: by mail-lf0-f42.google.com with SMTP id a204so14321254lfa.2
 for <30393 <at> debbugs.gnu.org>; Sat, 10 Feb 2018 00:54:03 -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=LhgGGwXF6lg/9MrqADswLh8QAFwIYG0fdRbzHGXoit0=;
 b=ULBpdR6er34Os1tQ70bPYW2jfOrPrlj0obd8qAv2DZvnJqXmarvKKu+WQF7oAXQ3IB
 KmQ0719yQWnq+84OE8d+vjfYJ0bZpO0H9NtIH9+MD6WcSouU+AYAlC5lD7oYEaOIAMRQ
 Aj5+0T65Ukn+hXnar11Ne7k51EdHNv+TTUUahnyLEM5k/w7Ql5lquV1TiVh+dvzsLoEZ
 JwPsROJbchL+0bMd7aw8ScF9U68Cz/KKZdWpycadRcXRuY0xEE39ZEh6fuDvorQVn4Rm
 9SZEUSAjWzeKc2hyxlrlnes5FqujP5iTX3ub9lga8cHO0GBoHAxHNGco6APOOo4FRcRw
 fciQ==
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=LhgGGwXF6lg/9MrqADswLh8QAFwIYG0fdRbzHGXoit0=;
 b=GBMnBJ8qym0EC46aHDQ2RHbRyATDBt8/DJVVlYG1+JdDWaZW2OFgSYKZPz31BNQkWN
 dfYHWxXg9KMYiPe5lf4rTypCgYyfG9JplLsNbAIMkJyUdxe67SXcuzvsxI+pahap216p
 roTIHfBWDWA02Ibm7vlhHAzrP5daPv8NtLWnUGmVrtJsPd6rqc2Am0LJSTblHkIgA5M0
 kV7FJiNUAiWtH6EZiKPnN6DCxnygHJS+JS/0y/ZP0VwcMpY6G7Fiz6g8WZ1fAcZJi4VX
 p2vp3qZmv1xsPfwMXvs/XoDZvMOpZ6U3O+nZh1hCkyuBIfDXhqgGTb0KKCMbi/M8YvE8
 WqAA==
X-Gm-Message-State: APf1xPAWaz57v56lDHcRGDu8ktWCNkboKxq4QbbxKDKBReOzRyBiN86l
 O1EBoLNXiTRHVWsZbAMmC5ML/Q8W
X-Google-Smtp-Source: AH8x2264XZ9NkkESMNUqCkpnlcrB7qqqXGEU8aW1V8zFlMZY2N9pUzaxNGW1l2lPxxDkXaNOemtO4w==
X-Received: by 10.25.56.13 with SMTP id f13mr3605548lfa.16.1518252837250;
 Sat, 10 Feb 2018 00:53:57 -0800 (PST)
Received: from [192.168.1.174] ([178.252.127.239])
 by smtp.googlemail.com with ESMTPSA id s25sm241668lfc.81.2018.02.10.00.53.56
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Sat, 10 Feb 2018 00:53:56 -0800 (PST)
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
To: Alan Mackenzie <acm@HIDDEN>,
 Noam Postavsky <npostavs@HIDDEN>
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <3331f80a-c5aa-5cb9-8088-0a88888bdaca@HIDDEN>
Date: Sat, 10 Feb 2018 11:53:55 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101
 Thunderbird/58.0
MIME-Version: 1.0
In-Reply-To: <20180209175040.63536.qmail@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  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). > > Just
 to remind people, I fixed all this nonsense about parens in column > 0 and
 `open-paren-in-column-0-is-defun-start' over a year ago. Key > search term:
 "comment-cache". [...] 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [178.252.127.239 listed in dnsbl.sorbs.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (raaahh[at]gmail.com)
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
 trust [209.85.215.42 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [209.85.215.42 listed in wl.mailspike.net]
 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
 domains are different
 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom
 freemail headers are different
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
X-Debbugs-Envelope-To: 30393
Cc: 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  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). > > Just
    to remind people, I fixed all this nonsense about parens in column > 0 and
    `open-paren-in-column-0-is-defun-start' over a year ago. Key > search term:
    "comment-cache". [...] 
 
 Content analysis details:   (2.0 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [209.85.215.42 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [209.85.215.42 listed in list.dnswl.org]
  1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                             [178.252.127.239 listed in dnsbl.sorbs.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (raaahh[at]gmail.com)
  0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                             domains are different
  0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom
                              freemail headers are different
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

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).
> 
> Just to remind people, I fixed all this nonsense about parens in column
> 0 and `open-paren-in-column-0-is-defun-start' over a year ago.  Key
> search term: "comment-cache".

Note that this particular bug has been filed against Emacs 24.4, and I 
can't reproduce it on master.

> 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?

AFAICT, open-paren-in-column-0-is-defun-start doesn't have much effect now.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 10 Feb 2018 03:55:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 09 22:55:40 2018
Received: from localhost ([127.0.0.1]:35969 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekMGJ-0001NY-SE
	for submit <at> debbugs.gnu.org; Fri, 09 Feb 2018 22:55:40 -0500
Received: from mail-it0-f50.google.com ([209.85.214.50]:33217)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1ekMGI-0001NJ-OL
 for 30393 <at> debbugs.gnu.org; Fri, 09 Feb 2018 22:55:39 -0500
Received: by mail-it0-f50.google.com with SMTP id u12so962012ite.0
 for <30393 <at> debbugs.gnu.org>; Fri, 09 Feb 2018 19:55:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=MXP5jYDTNBGtFTiWmOwuc81jypZJVVjQJgr1keeXEGE=;
 b=N04tKS+++HmKwr4d6mGhTs3pIn4eUHLiBtUvw6G/N6uaccPv36R6AzgVm5dlUcCp1i
 CjRyk8BglR2Cgg8+bIAhO4ccjJMj/gMlZYeA23c7WWRzENv94fary3RD5a4nM0Iywsny
 gL0VXYeCl7P6zIDp/SL6RM0MlX7ZGbTUNLvnEq2q4YK6n0ntY5j9Wl7jZLbSC6VV+xmz
 dK/b56EVtyp2jv+p4JUcOP3AHBBTNdRdwmcoIjI8xDim5wIc4n3TCkttdS208uH9J9n0
 YPSdjx4iRib0IxzJRizCIgDNZu5AA7PPWRBBI4zEDvrBnGvE2QMDfUfoMLPs+JRjFACX
 nnYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:references:date
 :in-reply-to:message-id:user-agent:mime-version;
 bh=MXP5jYDTNBGtFTiWmOwuc81jypZJVVjQJgr1keeXEGE=;
 b=WgDNnwgWiRF66dX/yt12mXKIjlJPsgTMYwEwr7qWo4jVIe2diCNk1665njh+PO+cu8
 tS0r32n4UhhvsXd8vmRbj+Bf68YTBfUYfTwWlPPyxUngjLfTkYvnw3lcoLweCWxJVpaY
 bSGTKDQf+J/KaZE0iE5nk5F+OiV/Oacjpz3yrsxxzL4c0QS2IzcJBvyp/ATDd2jL5O6p
 Z4rM11qjOYMPzHtEtq9HmsvUc0GGCj0sez33NAjUq0UXS+mHBenebMeQ6JYqBj2fI9kg
 9RqWT5OWqH/Dfs3WlYrGk/cr9z6DkhvcJ+/K7mpv9XCTKV8tWbePzBFfy5izMMrACslL
 Q1ng==
X-Gm-Message-State: APf1xPAie24lVycv22AC9Vo5BJs/aaMgJnd7KAzgCJWBIZLxItSGZpga
 ZnWKSnKrQH3N2chlY82qgNxJJw==
X-Google-Smtp-Source: AH8x226J4j0OjpL4DhsZ+I7LHuB+meX5Upa6SGlj4wCY+2mkTTsi70eMBxzcqXDQ6a5Qfo/R19uAUg==
X-Received: by 10.36.26.71 with SMTP id 68mr3322358iti.148.1518234933001;
 Fri, 09 Feb 2018 19:55:33 -0800 (PST)
Received: from zebian (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34])
 by smtp.googlemail.com with ESMTPSA id
 c15sm882848itd.4.2018.02.09.19.55.31
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Fri, 09 Feb 2018 19:55:32 -0800 (PST)
From: Noam Postavsky <npostavs@HIDDEN>
To: Alan Mackenzie <acm@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
References: <20180208152552.GL13340@hodi>
 <20180209175040.63536.qmail@HIDDEN>
Date: Fri, 09 Feb 2018 22:55:31 -0500
In-Reply-To: <20180209175040.63536.qmail@HIDDEN> (Alan Mackenzie's
 message of "9 Feb 2018 17:50:40 -0000")
Message-ID: <874lmpcxcc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.2 (/)
X-Debbugs-Envelope-To: 30393
Cc: 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)

Alan Mackenzie <acm@HIDDEN> writes:

>> 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).
>
> Just to remind people, I fixed all this nonsense about parens in column
> 0 and `open-paren-in-column-0-is-defun-start' over a year ago.  Key
> search term: "comment-cache".

I fixed it for emacs-lisp-mode using syntax-ppss (Bug#27920, Bug#25122),
but based on previous discussions, you wouldn't be especially happy with
such a solution...




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 9 Feb 2018 17:50:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 09 12:50:44 2018
Received: from localhost ([127.0.0.1]:35666 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ekCou-0001l4-0a
	for submit <at> debbugs.gnu.org; Fri, 09 Feb 2018 12:50:44 -0500
Received: from colin.muc.de ([193.149.48.1]:23154 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@HIDDEN>) id 1ekCor-0001ku-JD
 for 30393 <at> debbugs.gnu.org; Fri, 09 Feb 2018 12:50:42 -0500
Received: (qmail 63537 invoked by uid 3782); 9 Feb 2018 17:50:40 -0000
Date: 9 Feb 2018 17:50:40 -0000
Message-ID: <20180209175040.63536.qmail@HIDDEN>
From: Alan Mackenzie <acm@HIDDEN>
To: Noam Postavsky <npostavs@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
Organization: muc.de e.V.
In-Reply-To: <mailman.8766.1518140709.27995.bug-gnu-emacs@HIDDEN>
X-Newsgroups: gnu.emacs.bug
User-Agent: tin/2.4.1-20161224 ("Daill") (UNIX) (FreeBSD/11.1-RELEASE-p4
 (amd64))
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30393
Cc: 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

In article <mailman.8766.1518140709.27995.bug-gnu-emacs@HIDDEN> you wrote:
> retitle 30393 cperl-mode: open-paren-in-column-0 of string literal affects later statement indentation
> quit

> paulusm <paulusm@HIDDEN> writes:

>> # It's worth noting at this point that the /contents/ of the string
>> # seem to trigger the issue.

> 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).

Just to remind people, I fixed all this nonsense about parens in column
0 and `open-paren-in-column-0-is-defun-start' over a year ago.  Key
search term: "comment-cache".

My fix was rejected without any deep, soul-searching consideration, for
reasons which appeared obscure then and haven't become any clearer
since.

This bug, the failure to deal reasonably with open parens in column
zero, is a malignancy on the face of Emacs, breeding bug after bug after
bug, as we see here, as we have seen many times over the years.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.
Changed bug title to 'cperl-mode: open-paren-in-column-0 of string literal affects later statement indentation' from '24.4; cperl-mode: indentation failure' Request was from Noam Postavsky <npostavs@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 30393 <at> debbugs.gnu.org:


Received: (at 30393) by debbugs.gnu.org; 9 Feb 2018 01:44:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 08 20:44:17 2018
Received: from localhost ([127.0.0.1]:34522 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ejxjc-00081L-QD
	for submit <at> debbugs.gnu.org; Thu, 08 Feb 2018 20:44:16 -0500
Received: from mail-it0-f65.google.com ([209.85.214.65]:39703)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>)
 id 1ejxja-000813-M2; Thu, 08 Feb 2018 20:44:15 -0500
Received: by mail-it0-f65.google.com with SMTP id c80so8845126itb.4;
 Thu, 08 Feb 2018 17:44:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=qtSOvJBONEDfcMBIfcKIF4YP437o6nKog5FR1FTx+Q8=;
 b=swa5nsOtJq2B/EacV/3ZUu4llGGGQVT9594LE1slOHhpauIm/FRCJSEWR4umFPUE71
 STKcGxd1YIYz/+KOaLPGSYfjGA9HtqphMGprqVYWCE61ox+mwDR136yzYignGzF3xesX
 XwHyoY+bs+qpIW3MlnuuxLVncYEwsiBKT0nZOxLJAHEu6fXZfm4LrLD6rM7qpnyjDYAv
 WspCSyor7Fb4uR+6WpvBAkAax/f1Jbfbd6qjYQIpZJ4N+AL5L7VqYS6xXnCwfU8wf9NP
 dvvZIvwM6foFAAWy9qG99vSCQJ/Yqi/VrO1lFEo9nXSr3VpjxgIz/TlY6n0aImG0uuN5
 CVDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:cc:subject:references:date
 :in-reply-to:message-id:user-agent:mime-version;
 bh=qtSOvJBONEDfcMBIfcKIF4YP437o6nKog5FR1FTx+Q8=;
 b=g3fh7ur5FI2mNUR1T0QBMsmfvt5ORC7GVJXLhhRkLVPHLDxAk454LWtb7uvdOPzPih
 F0RnwDulP42dJJPO/Vnj0o+kKbQ51upaRyTjASFNFNlFUp6320kdZGrw3Hhsl560qBIj
 OVM1H9sfyHwVb98TFFsxFhNWKiutDktb4EjlLqcAvL0vPFXIUuPcUEhFT0oH9VXWqOlN
 0NwGlDGWXVLrcwclOAyAAa9e9aX2/leJ6TXLf6npac+o70cl0Bwv+BARGhjylLsHmO80
 yZCKS5sYSzN8bnVKXes81wCQ37eJkGYem8KfM2ttSRBM/HdBTE/h240L6G9itipVgtBO
 n9/Q==
X-Gm-Message-State: APf1xPB0T9iOZ9MIljVSvsrOY7K8ztTgt28Tck9UkMxm4m8fpPy9K9gk
 sJVJgd0YxT/hc78de+1joK1rZg==
X-Google-Smtp-Source: AH8x226BMWHSMKu3w9q0qN/us1YytW0K5E3lttyFNEkPohiA9GWf33DJwPUX9EsXYhs5Pyij2fPTvg==
X-Received: by 10.36.111.66 with SMTP id x63mr1485442itb.12.1518140649020;
 Thu, 08 Feb 2018 17:44:09 -0800 (PST)
Received: from zebian (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34])
 by smtp.googlemail.com with ESMTPSA id
 o201sm1152098itb.7.2018.02.08.17.44.07
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Thu, 08 Feb 2018 17:44:08 -0800 (PST)
From: Noam Postavsky <npostavs@HIDDEN>
To: paulusm <paulusm@HIDDEN>
Subject: Re: bug#30393: 24.4; cperl-mode: indentation failure
References: <20180208152552.GL13340@hodi>
Date: Thu, 08 Feb 2018 20:44:07 -0500
In-Reply-To: <20180208152552.GL13340@hodi> (paulusm's message of "Fri, 9 Feb
 2018 02:25:52 +1100")
Message-ID: <87tvurc4yg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 30393
Cc: 30393 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

retitle 30393 cperl-mode: open-paren-in-column-0 of string literal affects later statement indentation
quit

paulusm <paulusm@HIDDEN> writes:

> # It's worth noting at this point that the /contents/ of the string
> # seem to trigger the issue.

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).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 8 Feb 2018 16:19:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 08 11:19:21 2018
Received: from localhost ([127.0.0.1]:34225 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ejouv-00068g-4h
	for submit <at> debbugs.gnu.org; Thu, 08 Feb 2018 11:19:21 -0500
Received: from eggs.gnu.org ([208.118.235.92]:59525)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <paulusm@HIDDEN>) id 1ejo5X-0004v3-Fg
 for submit <at> debbugs.gnu.org; Thu, 08 Feb 2018 10:26:16 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <paulusm@HIDDEN>) id 1ejo5R-0000Il-H0
 for submit <at> debbugs.gnu.org; Thu, 08 Feb 2018 10:26:10 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,FREEMAIL_FROM
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:55357)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <paulusm@HIDDEN>) id 1ejo5R-0000Ic-DF
 for submit <at> debbugs.gnu.org; Thu, 08 Feb 2018 10:26:09 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50487)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <paulusm@HIDDEN>) id 1ejo5Q-0005b1-8k
 for bug-gnu-emacs@HIDDEN; Thu, 08 Feb 2018 10:26:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <paulusm@HIDDEN>) id 1ejo5K-0000Fv-5Z
 for bug-gnu-emacs@HIDDEN; Thu, 08 Feb 2018 10:26:08 -0500
Received: from homie.mail.dreamhost.com ([208.97.132.208]:49097
 helo=homiemail-a60.g.dreamhost.com)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <paulusm@HIDDEN>) id 1ejo5J-0000F0-SO
 for bug-gnu-emacs@HIDDEN; Thu, 08 Feb 2018 10:26:02 -0500
Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1])
 by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 788742820A2;
 Thu,  8 Feb 2018 07:25:57 -0800 (PST)
Received: from hodi (124-170-193-247.dyn.iinet.net.au [124.170.193.247])
 (using TLSv1 with cipher AES128-SHA (128/128 bits))
 (No client certificate requested)
 (Authenticated sender: paul@HIDDEN)
 by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 72C42282096;
 Thu,  8 Feb 2018 07:25:56 -0800 (PST)
Date: Fri, 9 Feb 2018 02:25:52 +1100
From: paulusm <paulusm@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 24.4; cperl-mode: indentation failure
Message-ID: <20180208152552.GL13340@hodi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no
 timestamps) [generic] [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.4 (----)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Thu, 08 Feb 2018 11:19:19 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.4 (----)

### How to foul up indentation in cperl-mode (cperl-indent-command)

# Here is some badly-indented Perl:

          my $sql = "insert into jobs (id, priority) values (1, 2);";
               my $sth = $dbh->prepare($sql) or die "bother";

# try indenting each line above (individually) by pressing TAB
# (cperl-indent-command).
#
# No problem - everything behaving normally.


# Now try this:

          my $sql = "insert into jobs
(id, priority)
values (1, 2);";
               my $sth = $dbh->prepare($sql) or die "bother";

# Note how "my $sth..." doesn't indent properly?  On my system, it
# stays where it is, where I expect it to re-indent to column 0.


# Now anything following refuses to indent:

          print "Help!";


# Comment out the second code block, and the "Help!" line indents
# properly again.

# It's worth noting at this point that the /contents/ of the string
# seem to trigger the issue.  If the "$sql = ..." lines were changed
# to:
#
# first case:
#   $sql = "select * from jobs;";
#
# second case:
#   $sql = "select *
#   from jobs;";
#
# The issue does not appear.



In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-09-12 on hullmann, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.10 (jessie)

--
Paul.




Acknowledgement sent to paulusm <paulusm@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#30393; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 16 Apr 2018 19:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.