GNU bug report logs -
#23443
25.0.93; Temporary change to syntax-table is in effect during syntax-propertize
Previous Next
Reported by: Noam Postavsky <npostavs <at> users.sourceforge.net>
Date: Wed, 4 May 2016 10:43:02 UTC
Severity: normal
Tags: notabug
Found in version 25.0.93
Done: Noam Postavsky <npostavs <at> users.sourceforge.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23443 in the body.
You can then email your comments to 23443 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Wed, 04 May 2016 10:43:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Noam Postavsky <npostavs <at> users.sourceforge.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 04 May 2016 10:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On the emacs-25 and master branches, changing the syntax-table
temporarily affects the table used during syntax-propertize. This does
not happen in 24.5 (unless the difference is just a timing thing?).
This triggers an infinite loop when expanding certain snippets with
yasnippet in haskell-mode (see [1] and [2]).
Attached is a simplified reproducer, run as
emacs -Q -l synprop-bug.el
In Emacs 25+, this results in the message
Error during redisplay: (internal--syntax-propertize 2) signaled
(error "syntax table is changed to standard-syntax-table during syntax
propertize")
In Emacs 24.5, it runs without a problem. It's not entirely clear to
me who should be reponsible for ensuring the right syntax-table during
syntax-propertize.
[1]: https://github.com/capitaomorte/yasnippet/issues/687
[2]: https://github.com/haskell/haskell-mode/issues/1315
[synprop-bug.el (text/x-emacs-lisp, attachment)]
Added indication that bug 23443 blocks19759
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Wed, 04 May 2016 15:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Sun, 08 May 2016 00:59:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 23443 <at> debbugs.gnu.org (full text, mbox):
Hi Noam,
On 05/04/2016 01:41 PM, Noam Postavsky wrote:
> In Emacs 24.5, it runs without a problem. It's not entirely clear to
> me who should be reponsible for ensuring the right syntax-table during
> syntax-propertize.
IIUC, the difference is that in Emacs 25 scan-sexps and other low-level
primitives started calling syntax-propertize when appropriate. And in
24.5 test-check-syntax-table is only called after (probably by font-lock).
In that's the reason, the new behavior is the correct one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Sun, 08 May 2016 18:52:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On Sat, May 7, 2016 at 8:58 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> Hi Noam,
>
> On 05/04/2016 01:41 PM, Noam Postavsky wrote:
>>
>> In Emacs 24.5, it runs without a problem. It's not entirely clear to
>> me who should be reponsible for ensuring the right syntax-table during
>> syntax-propertize.
>
>
> IIUC, the difference is that in Emacs 25 scan-sexps and other low-level
> primitives started calling syntax-propertize when appropriate. And in 24.5
> test-check-syntax-table is only called after (probably by font-lock).
>
> In that's the reason, the new behavior is the correct one.
So yasnippet mustn't use scan-sexps whilst the syntax-table has been changed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Sun, 08 May 2016 18:54:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 05/08/2016 09:51 PM, Noam Postavsky wrote:
> So yasnippet mustn't use scan-sexps whilst the syntax-table has been changed?
I don't know the whole issue, but it should be possible to reorganize
the code that when scan-sexps is called, the current syntax table is the
appropriate one.
But I don't know why you're changing it in the first place.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Sun, 08 May 2016 18:59:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On Sun, May 8, 2016 at 2:53 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> On 05/08/2016 09:51 PM, Noam Postavsky wrote:
>
>> So yasnippet mustn't use scan-sexps whilst the syntax-table has been
>> changed?
>
>
> I don't know the whole issue, but it should be possible to reorganize the
> code that when scan-sexps is called, the current syntax table is the
> appropriate one.
>
> But I don't know why you're changing it in the first place.
That scan-sexps is being to parse the snippet syntax, which is why
it's not using the major-mode's syntax table. I suppose the proper way
to fix this is to parse the whole snippet before inserting it into the
buffer, but I was hoping to put off the code reorganization that would
entail for a while longer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Sun, 08 May 2016 19:13:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 05/08/2016 09:58 PM, Noam Postavsky wrote:
> That scan-sexps is being to parse the snippet syntax, which is why
> it's not using the major-mode's syntax table. I suppose the proper way
> to fix this is to parse the whole snippet before inserting it into the
> buffer,
It seems so.
> but I was hoping to put off the code reorganization that would
> entail for a while longer.
Here's a possible stopgap:
- Narrow the buffer to the snippet (just to be safe).
- Bind syntax-propertize-function to nil.
- Call scan-sexps.
- Call (syntax-ppss-flush-cache snippet-beginning-position).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Tue, 10 May 2016 17:32:02 GMT)
Full text and
rfc822 format available.
Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):
On 08.05.2016 02:58, Dmitry Gutov wrote:
> Hi Noam,
>
> On 05/04/2016 01:41 PM, Noam Postavsky wrote:
>> In Emacs 24.5, it runs without a problem. It's not entirely clear to
>> me who should be reponsible for ensuring the right syntax-table during
>> syntax-propertize.
>
> IIUC, the difference is that in Emacs 25 scan-sexps and other
> low-level primitives started calling syntax-propertize when appropriate.
AFAIS scan-sexps, which calls scan-lists internally, updates the
syntax-table during scan.
Is this reasonable?
May you point me to the spot resp. discussion, when this change was made?
Thanks,
Andreas
> And in 24.5 test-check-syntax-table is only called after (probably by
> font-lock).
>
> In that's the reason, the new behavior is the correct one.
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Tue, 10 May 2016 20:43:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 05/10/2016 08:34 PM, Andreas Röhler wrote:
> AFAIS scan-sexps, which calls scan-lists internally, updates the
> syntax-table during scan.
> Is this reasonable?
>
> May you point me to the spot resp. discussion, when this change was made?
I don't recall there being a discussion. It was a longstanding problem
which Stefan fixed (or at least improved on) during this development cycle.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Wed, 11 May 2016 05:18:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 10.05.2016 22:42, Dmitry Gutov wrote:
> On 05/10/2016 08:34 PM, Andreas Röhler wrote:
>
>> AFAIS scan-sexps, which calls scan-lists internally, updates the
>> syntax-table during scan.
>> Is this reasonable?
>>
>> May you point me to the spot resp. discussion, when this change was
>> made?
>
> I don't recall there being a discussion. It was a longstanding problem
> which Stefan fixed (or at least improved on) during this development
> cycle.
For me it looks like a bug-source rather than a fix. Do you recall what
the mentioned longstanding problem was?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Wed, 11 May 2016 09:21:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 05/11/2016 08:20 AM, Andreas Röhler wrote:
> Do you recall what
> the mentioned longstanding problem was?
The problem was scan-lists not always honoring the syntax defined by
syntax-propertize-function. Because it could behave differently
depending on whether the nearby parts of the buffer had been already
syntax-propertized.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Wed, 11 May 2016 12:11:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 11.05.2016 11:20, Dmitry Gutov wrote:
> On 05/11/2016 08:20 AM, Andreas Röhler wrote:
>> Do you recall what
>> the mentioned longstanding problem was?
>
> The problem was scan-lists not always honoring the syntax defined by
> syntax-propertize-function. Because it could behave differently
> depending on whether the nearby parts of the buffer had been already
> syntax-propertized.
Thanks for the info. Is there a test-case resp. bug-report describing
the original problem?
IMO it needs a different solution than now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Wed, 11 May 2016 12:32:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 05/11/2016 03:13 PM, Andreas Röhler wrote:
> Thanks for the info. Is there a test-case resp. bug-report describing
> the original problem?
There may be some, but I'm not aware of particular ones.
> IMO it needs a different solution than now.
I couldn't imagine a radically different solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Thu, 12 May 2016 10:06:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 23443 <at> debbugs.gnu.org (full text, mbox):
close 23443
tags 23443 + notabug
quit
On Sun, May 8, 2016 at 3:12 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> Here's a possible stopgap:
>
> - Narrow the buffer to the snippet (just to be safe).
> - Bind syntax-propertize-function to nil.
> - Call scan-sexps.
> - Call (syntax-ppss-flush-cache snippet-beginning-position).
Thanks, this seems to be working well (implemented in [1]).
[1]: https://github.com/capitaomorte/yasnippet/pull/695
bug closed, send any further explanations to
23443 <at> debbugs.gnu.org and Noam Postavsky <npostavs <at> users.sourceforge.net>
Request was from
Noam Postavsky <npostavs <at> users.sourceforge.net>
to
control <at> debbugs.gnu.org.
(Thu, 12 May 2016 10:06:02 GMT)
Full text and
rfc822 format available.
Added tag(s) notabug.
Request was from
Noam Postavsky <npostavs <at> users.sourceforge.net>
to
control <at> debbugs.gnu.org.
(Thu, 12 May 2016 10:06:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Mon, 16 May 2016 17:36:02 GMT)
Full text and
rfc822 format available.
Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
|reopen| bugnumber
The proposed solution, which has to bind syntax-propertize-function to
nil before calling scan-sexp, reads like a work around. These things
shouldn't be necessary.
Assume a fix must affect usage of syntax-propertize-function and probably is not a trivial one.
Its design seems worth further discussion.
For example reading:
"The specified function may call ‘syntax-ppss’ on any position
before END, but it should not call ‘syntax-ppss-flush-cache’,
which means that it should not call ‘syntax-ppss’ on some
position and later modify the buffer on some earlier position."
Emacs can do better.
On 12.05.2016 12:05, Noam Postavsky wrote:
> close 23443
> tags 23443 + notabug
> quit
>
> On Sun, May 8, 2016 at 3:12 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>> Here's a possible stopgap:
>>
>> - Narrow the buffer to the snippet (just to be safe).
>> - Bind syntax-propertize-function to nil.
>> - Call scan-sexps.
>> - Call (syntax-ppss-flush-cache snippet-beginning-position).
> Thanks, this seems to be working well (implemented in [1]).
>
> [1]: https://github.com/capitaomorte/yasnippet/pull/695
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Mon, 16 May 2016 18:29:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 23443 <at> debbugs.gnu.org (full text, mbox):
On 05/13/2016 08:49 AM, Andreas Röhler wrote:
> |reopen| bugnumber
Please don't.
> The proposed solution, which has to bind syntax-propertize-function to
> nil before calling scan-sexp, reads like a work around. These things
> shouldn't be necessary.
It's not a solution (because there is no bug here), it's something that
a poorly-behaving function can do to behave better.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23443; Package
emacs.
(Mon, 16 May 2016 20:16:02 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
reopen 23443
The proposed solution, which has to bind syntax-propertize-function to
nil before calling scan-sexp, reads like a work around. These things
shouldn't be necessary.
Assume a fix must affect usage of syntax-propertize-function and probably is not a trivial one.
Its design seems worth further discussion.
For example reading:
"The specified function may call ‘syntax-ppss’ on any position
before END, but it should not call ‘syntax-ppss-flush-cache’,
which means that it should not call ‘syntax-ppss’ on some
position and later modify the buffer on some earlier position."
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 14 Jun 2016 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.