GNU bug report logs - #24870
26.0.50; parse-partial-sexp ignores comment-end

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24870 in the body.
You can then email your comments to 24870 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 3 Nov 2016 20:38:09 +0100

[Message part 1 (text/plain, inline)]

haskell-mode, at EOB:

---

{- To explore this file: -}

asdf =

---

parse-partial-sexp thinks being inside a paren - see attachment.

GNU Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-10-11

[after-haskell-comment.png (image/png, attachment)]

Message #10 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Matt Armstrong <marmstrong <at> google.com>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 24870 <at> debbugs.gnu.org
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Wed, 30 Nov 2016 01:10:58 -0800

Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:

> haskell-mode, at EOB:
>
> ---
>
> {- To explore this file: -}
>
> asdf =
>
> ---
>
> parse-partial-sexp thinks being inside a paren - see attachment.
>
> GNU Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-10-11

Hi Andreas,

Emacs does not have a haskell-mode, so this bug is difficult to reproduce.

It may be more appropriate to report this to the haskell-mode
maintainers for triage.  They can figure out if it is a problem that
should be fixed in haskell-mode itself, or a problem with Emacs.

Alternatively, can you provide a series of clear instructions to
reproduce the problem in a fresh Emacs started without your
customizations?  For example, begin by running "emacs -Q" and go from
there.  Your attached .png presents a buffer called
*parse-partial-sexp-output*, but it is not clear how this was generated.

Thanks

Message #13 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: Matt Armstrong <marmstrong <at> google.com>
Cc: 24870 <at> debbugs.gnu.org
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Wed, 30 Nov 2016 13:37:06 +0100

[Message part 1 (text/plain, inline)]

On 30.11.2016 10:10, Matt Armstrong wrote:
> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>> haskell-mode, at EOB: --- {- To explore this file: -} asdf = --- 
>> parse-partial-sexp thinks being inside a paren - see attachment. GNU 
>> Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-10-11 
> Hi Andreas, Emacs does not have a haskell-mode, so this bug is 
> difficult to reproduce. It may be more appropriate to report this to 
> the haskell-mode maintainers for triage. They can figure out if it is 
> a problem that should be fixed in haskell-mode itself, or a problem 
> with Emacs. Alternatively, can you provide a series of clear 
> instructions to reproduce the problem in a fresh Emacs started without 
> your customizations? For example, begin by running "emacs -Q" and go 
> from there. Your attached .png presents a buffer called 
> *parse-partial-sexp-output*, but it is not clear how this was 
> generated. Thanks
Hi Matt,

checked that with help of the haskell-mode folks already.
https://github.com/haskell/haskell-mode/issues/1459

As it's nice at current pretest Emacs, concluded a bug in trunk.
Here a shortened recipe. Put code below in a buffer:
||
|{- Just a comment: -}|

M-x haskell-mode RET

As after a comment, there should be no nesting.
Than evaluate one of the forms below

|(insert (format "%S" (syntax-ppss)))|
|(insert (format "%S" (parse-partial-sexp (point-min) (point))))|

Result both: (1 1 22 nil nil nil 0 nil nil (1) nil)

GNU Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-11-15

[Message part 2 (text/html, inline)]

Message #16 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Matt Armstrong <marmstrong <at> google.com>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 24870 <at> debbugs.gnu.org
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Wed, 30 Nov 2016 15:02:39 -0800

Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:

> On 30.11.2016 10:10, Matt Armstrong wrote:
>> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>>> haskell-mode, at EOB: --- {- To explore this file: -} asdf = --- 
>>> parse-partial-sexp thinks being inside a paren - see attachment. GNU 
>>> Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-10-11 
>> Hi Andreas, Emacs does not have a haskell-mode, so this bug is 
>> difficult to reproduce. It may be more appropriate to report this to 
>> the haskell-mode maintainers for triage. They can figure out if it is 
>> a problem that should be fixed in haskell-mode itself, or a problem 
>> with Emacs. Alternatively, can you provide a series of clear 
>> instructions to reproduce the problem in a fresh Emacs started without 
>> your customizations? For example, begin by running "emacs -Q" and go 
>> from there. Your attached .png presents a buffer called 
>> *parse-partial-sexp-output*, but it is not clear how this was 
>> generated. Thanks
> Hi Matt,
>
> checked that with help of the haskell-mode folks already.
> https://github.com/haskell/haskell-mode/issues/1459

Thanks.  For reference, this is what you have said on the github bug:

Seems a bug of
GNU Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-11-15
Does not exist at
GNU Emacs 25.1.90.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-11-29


> As it's nice at current pretest Emacs, concluded a bug in trunk.
> Here a shortened recipe. Put code below in a buffer:
> ||
> |{- Just a comment: -}|
>
> M-x haskell-mode RET

Note that haskell-mode is not part of Emacs.  Ideally, your steps to
reproduce that begin with running "emacs -Q".  Emacs maintainers that
might not also be Haskell hackers will appreciate it.  :)

Also, can you describe the visible symptom that caused you to begin
looking at syntax-ppss and parse-partial-sexp?  That description may
help me or others spot similarities with other reported bugs.

(I must say that I am not an Emacs expert, and I do not usually reply to
Emacs bugs.  I looked at a few bugs last night as a way to help
maintainers triage the "easy" bugs.  It does not look like this bug is
easy!)

Message #19 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Matt Armstrong <marmstrong <at> google.com>
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Wed, 30 Nov 2016 20:17:17 -0500

Matt Armstrong <marmstrong <at> google.com> writes:

> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>
>> On 30.11.2016 10:10, Matt Armstrong wrote:
>>> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>>>> haskell-mode, at EOB: --- {- To explore this file: -} asdf = --- 
>>>> parse-partial-sexp thinks being inside a paren - see attachment. GNU 
>>>> Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-10-11 
>>> Hi Andreas, Emacs does not have a haskell-mode, so this bug is 
>>> difficult to reproduce. It may be more appropriate to report this to 
>>> the haskell-mode maintainers for triage. They can figure out if it is 
>>> a problem that should be fixed in haskell-mode itself, or a problem 
>>> with Emacs. Alternatively, can you provide a series of clear 
>>> instructions to reproduce the problem in a fresh Emacs started without 
>>> your customizations? For example, begin by running "emacs -Q" and go 
>>> from there. Your attached .png presents a buffer called 
>>> *parse-partial-sexp-output*, but it is not clear how this was 
>>> generated. Thanks
>> Hi Matt,
>>
>> checked that with help of the haskell-mode folks already.
>> https://github.com/haskell/haskell-mode/issues/1459
>
> Thanks.  For reference, this is what you have said on the github bug:
>
> Seems a bug of
> GNU Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-11-15
> Does not exist at
> GNU Emacs 25.1.90.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-11-29
>
>
>> As it's nice at current pretest Emacs, concluded a bug in trunk.
>> Here a shortened recipe. Put code below in a buffer:
>> ||
>> |{- Just a comment: -}|
>>
>> M-x haskell-mode RET
>
> Note that haskell-mode is not part of Emacs.  Ideally, your steps to
> reproduce that begin with running "emacs -Q".  Emacs maintainers that
> might not also be Haskell hackers will appreciate it.  :)
>
> Also, can you describe the visible symptom that caused you to begin
> looking at syntax-ppss and parse-partial-sexp?  That description may
> help me or others spot similarities with other reported bugs.
>
> (I must say that I am not an Emacs expert, and I do not usually reply to
> Emacs bugs.  I looked at a few bugs last night as a way to help
> maintainers triage the "easy" bugs.  It does not look like this bug is
> easy!)

This seems similar to #24767.

Message #22 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: npostavs <at> users.sourceforge.net, Matt Armstrong <marmstrong <at> google.com>
Cc: 24870 <at> debbugs.gnu.org
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 1 Dec 2016 09:24:53 +0100

[Message part 1 (text/plain, inline)]

On 01.12.2016 02:17, npostavs <at> users.sourceforge.net wrote:
> Matt Armstrong <marmstrong <at> google.com> writes:
>
>> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>>
>>> On 30.11.2016 10:10, Matt Armstrong wrote:
>>>> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>>>>> haskell-mode, at EOB: --- {- To explore this file: -} asdf = ---
>>>>> parse-partial-sexp thinks being inside a paren - see attachment. GNU
>>>>> Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-10-11
>>>> Hi Andreas, Emacs does not have a haskell-mode, so this bug is
>>>> difficult to reproduce. It may be more appropriate to report this to
>>>> the haskell-mode maintainers for triage. They can figure out if it is
>>>> a problem that should be fixed in haskell-mode itself, or a problem
>>>> with Emacs. Alternatively, can you provide a series of clear
>>>> instructions to reproduce the problem in a fresh Emacs started without
>>>> your customizations? For example, begin by running "emacs -Q" and go
>>>> from there. Your attached .png presents a buffer called
>>>> *parse-partial-sexp-output*, but it is not clear how this was
>>>> generated. Thanks
>>> Hi Matt,
>>>
>>> checked that with help of the haskell-mode folks already.
>>> https://github.com/haskell/haskell-mode/issues/1459
>> Thanks.  For reference, this is what you have said on the github bug:
>>
>> Seems a bug of
>> GNU Emacs 26.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-11-15
>> Does not exist at
>> GNU Emacs 25.1.90.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2016-11-29
>>
>>
>>> As it's nice at current pretest Emacs, concluded a bug in trunk.
>>> Here a shortened recipe. Put code below in a buffer:
>>> ||
>>> |{- Just a comment: -}|
>>>
>>> M-x haskell-mode RET
>> Note that haskell-mode is not part of Emacs.  Ideally, your steps to
>> reproduce that begin with running "emacs -Q".  Emacs maintainers that
>> might not also be Haskell hackers will appreciate it.  :)
>>
>> Also, can you describe the visible symptom that caused you to begin
>> looking at syntax-ppss and parse-partial-sexp?  That description may
>> help me or others spot similarities with other reported bugs.
>>
>> (I must say that I am not an Emacs expert, and I do not usually reply to
>> Emacs bugs.  I looked at a few bugs last night as a way to help
>> maintainers triage the "easy" bugs.  It does not look like this bug is
>> easy!)
> This seems similar to #24767.

There is said:

> The string "(* hello *)" should be highlighted as a comment, and is
> indeed correctly highlighted this way in Emacs-25 (and Emacs-24), but
> not in "master".

Here in "master" the syntax-highlighting is correct. So the cases might be related, but not the same.

BTW here is the recipe with a new setup.

{- asdfasd -}
-- (parse-partial-sexp (point-min) (point))
-- ==> (1 1 nil nil t nil 0 nil 15 (1) nil)

absolut n | n >= 0 = n
          | otherwise = -n

[Message part 2 (text/html, inline)]

Message #25 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: Matt Armstrong <marmstrong <at> google.com>
Cc: 24870 <at> debbugs.gnu.org
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 1 Dec 2016 09:33:42 +0100

On 01.12.2016 00:02, Matt Armstrong wrote:
> Also, can you describe the visible symptom that caused you to begin
> looking at syntax-ppss and parse-partial-sexp?  That description may
> help me or others spot similarities with other reported bugs.
>
> (I must say that I am not an Emacs expert, and I do not usually reply to
> Emacs bugs.  I looked at a few bugs last night as a way to help
> maintainers triage the "easy" bugs.  It does not look like this bug is
> easy!)

It broke some code relying on results of parse-partial-sexp
This , resp. syntax-ppss, is an internally widely used function.

Message #28 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 24870 <at> debbugs.gnu.org, Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Tue, 13 Dec 2016 22:00:16 -0500

[Message part 1 (text/plain, inline)]

tags 24870 = confirmed
merge 24870 25063
quit

This is the same as your report in 25063, as you noted there, the
comment starter is being counted as a list opener (although the comment
closer is not being recognized as a list closer).

Here's a recipe that doesn't require haskell-mode:

[bug-24870-comment-nesting-pps.el (text/plain, inline)]

(defconst 24870-syntax-table
  (let ((table (make-syntax-table)))
    (modify-syntax-entry ?\{  "(}1nb" table)
    (modify-syntax-entry ?\}  "){4nb" table)
    (modify-syntax-entry ?-  ". 123" table)
    table))

(defun 24870-test ()
  (interactive)
  (with-current-buffer (get-buffer-create "*24870 test*")
    (set-syntax-table 24870-syntax-table)
    (insert "{-C-}\nX")
    (message "pps nesting: %d" (nth 0 (parse-partial-sexp (point-min) (point-max))))
    (display-buffer (current-buffer))))

[Message part 3 (text/plain, inline)]

I have tracked the issue down to scan_sexps_forward in syntax.c

Message #35 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 24870 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Tue, 13 Dec 2016 23:04:45 -0500

[Message part 1 (text/plain, inline)]

npostavs <at> users.sourceforge.net writes:
>
>
> I have tracked the issue down to scan_sexps_forward in syntax.c

Applying this change which reverts part of [1] seems to fix the issue:

[bug-24870-quick-fix.diff (text/x-diff, inline)]

--- i/src/syntax.c
+++ w/src/syntax.c
@@ -3192,7 +3192,11 @@ scan_sexps_forward (struct lisp_parse_state *state,
 
   while (from < end)
     {
-      if (SYNTAX_FLAGS_COMSTART_FIRST (prev_from_syntax)
+      INC_FROM;
+      code = prev_from_syntax & 0xff;
+
+      if (from < end
+          && SYNTAX_FLAGS_COMSTART_FIRST (prev_from_syntax)
 	  && (c1 = FETCH_CHAR (from_byte),
 	      syntax = SYNTAX_WITH_FLAGS (c1),
 	      SYNTAX_FLAGS_COMSTART_SECOND (syntax)))
@@ -3213,8 +3217,6 @@ scan_sexps_forward (struct lisp_parse_state *state,
 	}
       else
         {
-          INC_FROM;
-          code = prev_from_syntax & 0xff;
           if (code == Scomment_fence)
             {
               /* Record the comment style we have entered so that only

[Message part 3 (text/plain, inline)]

Alan, can you explain what the idea behind that change was?

I think it might correspond to this part of the commit message:

    Reformulate code at the top of the main loop correctly to
    recognize comment openers when starting in the middle of one.

[1]: 9dcf5998935c Sun Mar 20 13:19:48 2016 +0000
"Amend parse-partial-sexp correctly to handle two character comment delimiters"

Message #38 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: npostavs <at> users.sourceforge.net
Cc: 24870 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Wed, 14 Dec 2016 07:45:45 +0100

[Message part 1 (text/plain, inline)]

On 14.12.2016 05:04, npostavs <at> users.sourceforge.net wrote:
> npostavs <at> users.sourceforge.net writes:
>>
>> I have tracked the issue down to scan_sexps_forward in syntax.c
> Applying this change which reverts part of [1] seems to fix the issue:
>
>
>
> Alan, can you explain what the idea behind that change was?
>
> I think it might correspond to this part of the commit message:
>
>      Reformulate code at the top of the main loop correctly to
>      recognize comment openers when starting in the middle of one.
>
> [1]: 9dcf5998935c Sun Mar 20 13:19:48 2016 +0000
> "Amend parse-partial-sexp correctly to handle two character comment delimiters"

Thanks a lot! BTW that message puzzles me too, AFAIK comments in C,C++ 
can't be nested.

[Message part 2 (text/html, inline)]

Message #41 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: npostavs <at> users.sourceforge.net
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Wed, 14 Dec 2016 19:56:23 +0000

Hello, Noam.

On Tue, Dec 13, 2016 at 11:04:45PM -0500, npostavs <at> users.sourceforge.net wrote:
> npostavs <at> users.sourceforge.net writes:


> > I have tracked the issue down to scan_sexps_forward in syntax.c

> Applying this change which reverts part of [1] seems to fix the issue:


> --- i/src/syntax.c
> +++ w/src/syntax.c
> @@ -3192,7 +3192,11 @@ scan_sexps_forward (struct lisp_parse_state *state,

>    while (from < end)
>      {
> -      if (SYNTAX_FLAGS_COMSTART_FIRST (prev_from_syntax)
> +      INC_FROM;
> +      code = prev_from_syntax & 0xff;
> +
> +      if (from < end
> +          && SYNTAX_FLAGS_COMSTART_FIRST (prev_from_syntax)
>  	  && (c1 = FETCH_CHAR (from_byte),
>  	      syntax = SYNTAX_WITH_FLAGS (c1),
>  	      SYNTAX_FLAGS_COMSTART_SECOND (syntax)))
> @@ -3213,8 +3217,6 @@ scan_sexps_forward (struct lisp_parse_state *state,
>  	}
>        else
>          {
> -          INC_FROM;
> -          code = prev_from_syntax & 0xff;
>            if (code == Scomment_fence)
>              {
>                /* Record the comment style we have entered so that only



> Alan, can you explain what the idea behind that change was?

We're talking about 9dcf5998935c8aaa846d7585b81f0dcfe1935b3d from Sun
Mar 20 13:19:48 2016 +0000, still?

The idea is that in a (parse-partial-sexp from to), the end position
might be in the middle of a two character comment marker, such as "/*".
Before this change, it was impossible successfully to use the result of
that operation as the old state for continuing parse-partial-sexp from
that position, since it did not contain enough info to see it was in a
comment after passing the "*"

The change 9dcf599 added an extra element onto the parse state which was
non-nil when we end up after a "/", etc.

> I think it might correspond to this part of the commit message:

>     Reformulate code at the top of the main loop correctly to
>     recognize comment openers when starting in the middle of one.

> [1]: 9dcf5998935c Sun Mar 20 13:19:48 2016 +0000
> "Amend parse-partial-sexp correctly to handle two character comment delimiters"

With the above in mind, I think we should both check your proposed patch
to make sure it doesn't break the working of 9dcf599.

Thanks for Cc'ing me in on this.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #44 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: npostavs <at> users.sourceforge.net
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Wed, 14 Dec 2016 21:58:34 +0000

Hello again, Noam.

On Tue, Dec 13, 2016 at 11:04:45PM -0500, npostavs <at> users.sourceforge.net wrote:
> npostavs <at> users.sourceforge.net writes:


> > I have tracked the issue down to scan_sexps_forward in syntax.c

> Applying this change which reverts part of [1] seems to fix the issue:


> --- i/src/syntax.c
> +++ w/src/syntax.c
> @@ -3192,7 +3192,11 @@ scan_sexps_forward (struct lisp_parse_state *state,

>    while (from < end)
>      {
> -      if (SYNTAX_FLAGS_COMSTART_FIRST (prev_from_syntax)
> +      INC_FROM;
> +      code = prev_from_syntax & 0xff;
> +
> +      if (from < end
> +          && SYNTAX_FLAGS_COMSTART_FIRST (prev_from_syntax)
>  	  && (c1 = FETCH_CHAR (from_byte),
>  	      syntax = SYNTAX_WITH_FLAGS (c1),
>  	      SYNTAX_FLAGS_COMSTART_SECOND (syntax)))
> @@ -3213,8 +3217,6 @@ scan_sexps_forward (struct lisp_parse_state *state,
>  	}
>        else
>          {
> -          INC_FROM;
> -          code = prev_from_syntax & 0xff;
>            if (code == Scomment_fence)
>              {
>                /* Record the comment style we have entered so that only

Alas, that patch won't do.  The very first thing that must be done in the
loop is to check for a two-character comment delimiter, of which the
first character might have been recorded in OLDSTATE element 9 rather
than having been scanned by scan_sexps_forward on the previous loop
iteration.

My analysis of what's happening in the bug recipe you posted one or two
posts previously, here in scan_sexps_forward is as follows.  (In that
recipe, "{-C-}\nX" was parse-partial-sexp'd over, and the syntax table
had been set to recognise "{-" and "-}" as matching comment delimiters.)
(i) On the first iteration of the main loop, the "{" is read.  It is
  recognised as an opening paren, and causes the "current paren depth" to
  be incremented.
(ii) On the second iteration of the loop, the "-" is read.  The function
  now recognises the two-character comment opener, and proceeds to read
  the innards of the comment together with its closing delimiter (the
  "-}").
(iii) On the third and fourth iterations, the function reads "\n" and
  "X".  It then terminates, having reached point-max.
(iv) The paren depth counter remains at 1.

What is new here is characters with paren syntax also being components of
2-char comment delimiters.  I recently fixed a similar problem when
characters with word syntax were also flagged as 2-char comment delimiter
parts.  I think a similar patch at case label Sopen: (Line ~3322), which
would peek ahead at the next character to check for "{-" before
recognising the "{" as an open paren would be the best fix.

Do you want to make this fix, or should I do it?  If you want to do it,
I'm willing (indeed, eager) to review it for you.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #47 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: Alan Mackenzie <acm <at> muc.de>, npostavs <at> users.sourceforge.net
Cc: 24870 <at> debbugs.gnu.org, Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 15 Dec 2016 09:18:01 +0100

On 14.12.2016 20:56, Alan Mackenzie wrote:
>
> We're talking about 9dcf5998935c8aaa846d7585b81f0dcfe1935b3d from Sun
> Mar 20 13:19:48 2016 +0000, still?
>
> The idea is that in a (parse-partial-sexp from to), the end position
> might be in the middle of a two character comment marker, such as "/*".
> Before this change, it was impossible successfully to use the result of
> that operation as the old state for continuing parse-partial-sexp from
> that position, since it did not contain enough info to see it was in a
> comment after passing the "*"
>
> The change 9dcf599 added an extra element onto the parse state which was
> non-nil when we end up after a "/", etc.
>
>

Hi Alan,

sounds like a classical mistake for me.

You commented lately on the effect of narrowing and how simply to 
respect its results. Nothing further to say here.

OTOH: do you have a use-case, a bug, which propelled the amendment?

Thanks,

Andreas

Message #50 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 24870 <at> debbugs.gnu.org, acm <at> muc.de, marmstrong <at> google.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 15 Dec 2016 18:01:40 +0200

> From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
> Date: Thu, 15 Dec 2016 09:18:01 +0100
> Cc: 24870 <at> debbugs.gnu.org, Matt Armstrong <marmstrong <at> google.com>
> 
> Hi Alan,
> 
> sounds like a classical mistake for me.

Most people here don't make "classical mistakes", so it's best to
assume none of them do, and never say such things aloud.

Just a $0.02-worth advice.

Message #53 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 15 Dec 2016 11:33:36 -0500

On Wed, Dec 14, 2016 at 4:58 PM, Alan Mackenzie <acm <at> muc.de> wrote:
>
> Alas, that patch won't do.

I thought that might be the case.

>
> What is new here is characters with paren syntax also being components of
> 2-char comment delimiters.  I recently fixed a similar problem when
> characters with word syntax were also flagged as 2-char comment delimiter
> parts.  I think a similar patch at case label Sopen: (Line ~3322), which
> would peek ahead at the next character to check for "{-" before
> recognising the "{" as an open paren would be the best fix.

I don't think special casing Sopen makes sense, shouldn't the check
apply to all syntax classes?

(the special case for word syntax does make sense, because it has its
own inner loop already)

>
> Do you want to make this fix, or should I do it?  If you want to do it,
> I'm willing (indeed, eager) to review it for you.

I'll have a patch ready in a day or two.

Message #56 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 15 Dec 2016 16:44:58 +0000

Hello, Noam.

On Thu, Dec 15, 2016 at 11:33:36AM -0500, Noam Postavsky wrote:
> On Wed, Dec 14, 2016 at 4:58 PM, Alan Mackenzie <acm <at> muc.de> wrote:

> > Alas, that patch won't do.

> I thought that might be the case.


> > What is new here is characters with paren syntax also being components of
> > 2-char comment delimiters.  I recently fixed a similar problem when
> > characters with word syntax were also flagged as 2-char comment delimiter
> > parts.  I think a similar patch at case label Sopen: (Line ~3322), which
> > would peek ahead at the next character to check for "{-" before
> > recognising the "{" as an open paren would be the best fix.

> I don't think special casing Sopen makes sense, shouldn't the check
> apply to all syntax classes?

Maybe.  I'm too tired to work this out at the moment (it was the office
Glühwein day).

> (the special case for word syntax does make sense, because it has its
> own inner loop already)

As does comment syntax, of course.

> > Do you want to make this fix, or should I do it?  If you want to do it,
> > I'm willing (indeed, eager) to review it for you.

> I'll have a patch ready in a day or two.

Excellent!  Or even in three or four days.  Take your time, do it well
(at least, better than I managed last time round) and enjoy doing it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #59 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 24870 <at> debbugs.gnu.org, Matt Armstrong <marmstrong <at> google.com>,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 15 Dec 2016 16:50:11 +0000

Hello, Andreas.

On Thu, Dec 15, 2016 at 09:18:01AM +0100, Andreas Röhler wrote:


> On 14.12.2016 20:56, Alan Mackenzie wrote:

> > We're talking about 9dcf5998935c8aaa846d7585b81f0dcfe1935b3d from Sun
> > Mar 20 13:19:48 2016 +0000, still?

> > The idea is that in a (parse-partial-sexp from to), the end position
> > might be in the middle of a two character comment marker, such as "/*".
> > Before this change, it was impossible successfully to use the result of
> > that operation as the old state for continuing parse-partial-sexp from
> > that position, since it did not contain enough info to see it was in a
> > comment after passing the "*"

> > The change 9dcf599 added an extra element onto the parse state which was
> > non-nil when we end up after a "/", etc.



> Hi Alan,

> sounds like a classical mistake for me.

Quite possibly.

> You commented lately on the effect of narrowing and how simply to 
> respect its results. Nothing further to say here.

I don't see what your meaning is here, but never mind.

> OTOH: do you have a use-case, a bug, which propelled the amendment?

Yes.  It was quite a few years ago, but a bug in CC Mode was caused by
parse-partial-sexp terminating at a critical place, and the next
invocation of parse-partial-sexp thus going wrong.  I programmed round it
awkwardly at the time.

Also syntax-ppss would be falling into the trap quite a lot, I think.  I
don't think it checked specially for the critical case.  Now it doesn't
have to bother - at least, it won't as soon as Noam has corrected the
current bug.  ;-)

> Thanks,

> Andreas

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #62 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 24870 <at> debbugs.gnu.org, Matt Armstrong <marmstrong <at> google.com>,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 15 Dec 2016 18:59:39 +0100

On 15.12.2016 17:50, Alan Mackenzie wrote:
> You commented lately on the effect of narrowing and how simply to
>> respect its results. Nothing further to say here.
> I don't see what your meaning is here, but never mind.

Referred to your post at emacs-devel 11.12.2016 11:17:

At the moment, narrowing is a strong, direct, simple facility - it does 
what it says it does and no more.

Message #65 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Alan Mackenzie <acm <at> muc.de>
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Sun, 18 Dec 2016 00:39:11 -0500

[Message part 1 (text/plain, inline)]

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Noam.
>
> On Thu, Dec 15, 2016 at 11:33:36AM -0500, Noam Postavsky wrote:
>> On Wed, Dec 14, 2016 at 4:58 PM, Alan Mackenzie <acm <at> muc.de> wrote:
>
>> > What is new here is characters with paren syntax also being components of
>> > 2-char comment delimiters.  I recently fixed a similar problem when
>> > characters with word syntax were also flagged as 2-char comment delimiter
>> > parts.  I think a similar patch at case label Sopen: (Line ~3322), which
>> > would peek ahead at the next character to check for "{-" before
>> > recognising the "{" as an open paren would be the best fix.
>
>> I don't think special casing Sopen makes sense, shouldn't the check
>> apply to all syntax classes?
>
> Maybe.  I'm too tired to work this out at the moment (it was the office
> Glühwein day).
>
>> (the special case for word syntax does make sense, because it has its
>> own inner loop already)
>
> As does comment syntax, of course.
>
>> > Do you want to make this fix, or should I do it?  If you want to do it,
>> > I'm willing (indeed, eager) to review it for you.
>
>> I'll have a patch ready in a day or two.
>
> Excellent!  Or even in three or four days.  Take your time, do it well
> (at least, better than I managed last time round) and enjoy doing it.

Okay, here it is.  I think I've made this function a bit less twisty,
and hopefully haven't broken anything new (make check is still passing).

[v1-0001-Fix-comment-detection-on-open-parens.patch (text/plain, attachment)]

Message #68 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: npostavs <at> users.sourceforge.net
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 29 Dec 2016 11:14:28 +0000

Hello, Noam.

Sorry this has taken me more time than I anticipated; it's a busy time
of the year.  :-(

On Sun, Dec 18, 2016 at 12:39:11AM -0500, npostavs <at> users.sourceforge.net wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > Hello, Noam.

> > On Thu, Dec 15, 2016 at 11:33:36AM -0500, Noam Postavsky wrote:

[ .... ]

> >> > Do you want to make this fix, or should I do it?  If you want to
> >> > do it, I'm willing (indeed, eager) to review it for you.

> >> I'll have a patch ready in a day or two.

[ .... ]

> Okay, here it is.  I think I've made this function a bit less twisty,
> and hopefully haven't broken anything new (make check is still passing).

syntax.c looks good.  It looks very good.  I've just got one trivial
comment:

(i) The new function `check_comment_start' doesn't have a comment saying
what its return value means.  Possibly you could instead rename it so
that the name implies what it returns.  Maybe something like
`in_double_comment_opener'.

I'll admit I haven't actually tried out the code, mainly because you've
written a test file.  One comment about the test file:

(ii) In `parse-partial-sexp-continue-over-comment-marker', variable aftC
is the position in the middle of the comment closer "*/".  I don't think
you are testing in any way that element 10 (nil, or the syntax of the
position just before the end point when that position might be the first
character of a two-character construct, i.e. an escape or first char of a
double-char comment delimiter) is correct.  This element 10 was newly
introduced this year.  Would you please consider adding such a test to
this new test file.  Thanks!

Otherwise, excellent!

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #71 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Alan Mackenzie <acm <at> muc.de>
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 29 Dec 2016 20:55:09 -0500

[Message part 1 (text/plain, inline)]

Alan Mackenzie <acm <at> muc.de> writes:
>
> (i) The new function `check_comment_start' doesn't have a comment saying
> what its return value means.  Possibly you could instead rename it so
> that the name implies what it returns.  Maybe something like
> `in_double_comment_opener'.

Good point, I've updated the patch.

>
> I'll admit I haven't actually tried out the code, mainly because you've
> written a test file.

Oh dear, maybe I should have withheld the test file ;)

>
> (ii) In `parse-partial-sexp-continue-over-comment-marker', variable aftC
> is the position in the middle of the comment closer "*/".  I don't think
> you are testing in any way that element 10 (nil, or the syntax of the
> position just before the end point when that position might be the first
> character of a two-character construct, i.e. an escape or first char of a
> double-char comment delimiter) is correct.

My idea was that its effect would be tested by using pps-preC as
OLDSTATE, which avoids having to encode the specifics in the test.  I
added another clause which uses pps-aftC to cover parsing from the
middle of a comment closer as well as opener.

[v2-0001-Fix-comment-detection-on-open-parens.patch (text/plain, attachment)]

Message #74 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Alan Mackenzie <acm <at> muc.de>
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Thu, 12 Jan 2017 21:07:49 -0500

npostavs <at> users.sourceforge.net writes:

> Alan Mackenzie <acm <at> muc.de> writes:
>>
>> (ii) In `parse-partial-sexp-continue-over-comment-marker', variable aftC
>> is the position in the middle of the comment closer "*/".  I don't think
>> you are testing in any way that element 10 (nil, or the syntax of the
>> position just before the end point when that position might be the first
>> character of a two-character construct, i.e. an escape or first char of a
>> double-char comment delimiter) is correct.
>
> My idea was that its effect would be tested by using pps-preC as
> OLDSTATE, which avoids having to encode the specifics in the test.  I
> added another clause which uses pps-aftC to cover parsing from the
> middle of a comment closer as well as opener.

Ping?  Agree/Disagree?

Message #77 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: npostavs <at> users.sourceforge.net
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Mon, 23 Jan 2017 20:12:32 +0000

Hello, Noam.

Sorry this is very late, but better that than not at all.

On Thu, Jan 12, 2017 at 21:07:49 -0500, npostavs <at> users.sourceforge.net wrote:
> npostavs <at> users.sourceforge.net writes:

> > Alan Mackenzie <acm <at> muc.de> writes:

> >> (ii) In `parse-partial-sexp-continue-over-comment-marker', variable aftC
> >> is the position in the middle of the comment closer "*/".  I don't think
> >> you are testing in any way that element 10 (nil, or the syntax of the
> >> position just before the end point when that position might be the first
> >> character of a two-character construct, i.e. an escape or first char of a
> >> double-char comment delimiter) is correct.

> > My idea was that its effect would be tested by using pps-preC as
> > OLDSTATE, which avoids having to encode the specifics in the test.  I
> > added another clause which uses pps-aftC to cover parsing from the
> > middle of a comment closer as well as opener.

> Ping?  Agree/Disagree?

I've just had another fairly intensive look at the patches, and I agree.

I think it's time to commit these.  What do you say?

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #80 received at 24870 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Alan Mackenzie <acm <at> muc.de>
Cc: 24870 <at> debbugs.gnu.org,
 Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 Matt Armstrong <marmstrong <at> google.com>
Subject: Re: bug#24870: 26.0.50; parse-partial-sexp ignores comment-end
Date: Mon, 23 Jan 2017 19:30:23 -0500

tags 24870 fixed
close 24870 
quit

Alan Mackenzie <acm <at> muc.de> writes:
>
> On Thu, Jan 12, 2017 at 21:07:49 -0500, npostavs <at> users.sourceforge.net wrote:
>> npostavs <at> users.sourceforge.net writes:
>
>> > Alan Mackenzie <acm <at> muc.de> writes:
>
>> >> (ii) In `parse-partial-sexp-continue-over-comment-marker', variable aftC
>> >> is the position in the middle of the comment closer "*/".  I don't think
>> >> you are testing in any way that element 10 (nil, or the syntax of the
>> >> position just before the end point when that position might be the first
>> >> character of a two-character construct, i.e. an escape or first char of a
>> >> double-char comment delimiter) is correct.
>
>> > My idea was that its effect would be tested by using pps-preC as
>> > OLDSTATE, which avoids having to encode the specifics in the test.  I
>> > added another clause which uses pps-aftC to cover parsing from the
>> > middle of a comment closer as well as opener.
>
>
> I've just had another fairly intensive look at the patches, and I
> agree.

Thanks for the review.

>
> I think it's time to commit these.  What do you say?

Yep, pushed to master [1: 201dfe3].

1: 2017-01-23 19:28:30 -0500 201dfe311868932d10da146808fcdd681948ba53
  Fix comment detection on open parens

Previous Next

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