* bug#21657: 25.0.50; Python mode goes into an infinite loop
@ 2015-10-09 22:22 Dima Kogan
2015-10-09 23:16 ` Luke Powers
0 siblings, 1 reply; 6+ messages in thread
From: Dima Kogan @ 2015-10-09 22:22 UTC (permalink / raw)
To: 21657
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
Hi. I'm running a very recent emacs:
https://github.com/emacs-mirror/emacs/commit/7e83f50
Opening a trivial python source file (attached) with a trivial and
seemingly-unrelated .emacs.d/init.el (also attached) makes emacs spin
its wheels. Hitting C-g doesn't work to get control back. You actually
have to kill the process.
Thanks!
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacsbreak.py --]
[-- Type: text/x-python, Size: 24 bytes --]
"""
blah blah blah
"""
[-- Attachment #3: init.el --]
[-- Type: application/emacs-lisp, Size: 39 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#21657: 25.0.50; Python mode goes into an infinite loop
2015-10-09 22:22 bug#21657: 25.0.50; Python mode goes into an infinite loop Dima Kogan
@ 2015-10-09 23:16 ` Luke Powers
2015-10-13 3:21 ` Daniel Colascione
0 siblings, 1 reply; 6+ messages in thread
From: Luke Powers @ 2015-10-09 23:16 UTC (permalink / raw)
To: Dima Kogan; +Cc: 21657
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
There are a couple issues out there with similar reports (21646 21629
21628).
Revert to 818f06eaa72d8e4f9ba314c1c2855613bf89f396 if you want to work
around the issue.
On Fri, Oct 9, 2015 at 3:22 PM, Dima Kogan <dima@secretsauce.net> wrote:
> Hi. I'm running a very recent emacs:
>
> https://github.com/emacs-mirror/emacs/commit/7e83f50
>
> Opening a trivial python source file (attached) with a trivial and
> seemingly-unrelated .emacs.d/init.el (also attached) makes emacs spin
> its wheels. Hitting C-g doesn't work to get control back. You actually
> have to kill the process.
>
> Thanks!
>
>
[-- Attachment #2: Type: text/html, Size: 1056 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#21657: 25.0.50; Python mode goes into an infinite loop
2015-10-09 23:16 ` Luke Powers
@ 2015-10-13 3:21 ` Daniel Colascione
2015-10-13 4:58 ` immerrr again
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Colascione @ 2015-10-13 3:21 UTC (permalink / raw)
To: Luke Powers, Dima Kogan; +Cc: 21657
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]
On 10/09/2015 04:16 PM, Luke Powers wrote:
> There are a couple issues out there with similar reports (21646 21629
> 21628).
>
> Revert to 818f06eaa72d8e4f9ba314c1c2855613bf89f396 if you want to work
> around the issue.
I think I know what's going on. Stefan's change moved some of the
syntax-propertize stuff from Lisp into C. Now Emacs core has a variable
called syntax-propertize--done, known in C as syntax_propertize__done.
We make it buffer-local using Fmake_variable_buffer_local, but that
makes the variable buffer-local when it's _set_. Until it's set, the
variable retains its global value, which lives in the C variable
syntax_propertize__done. So if we syntax-propertize 1000 characters of
buffer A, then find-file in buffer B, we think we've syntax-propertized
up to position 1000 (the value of syntax_propertize__done) until we set
it to something else. In the case of Python, if we have a triple quote
in the first 1000 characters, we infloop.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#21657: 25.0.50; Python mode goes into an infinite loop
2015-10-13 3:21 ` Daniel Colascione
@ 2015-10-13 4:58 ` immerrr again
2015-10-13 5:05 ` Daniel Colascione
0 siblings, 1 reply; 6+ messages in thread
From: immerrr again @ 2015-10-13 4:58 UTC (permalink / raw)
To: Daniel Colascione; +Cc: 21657, Dima Kogan, Luke Powers
There's a patch to fix this in #21671.
On Tue, Oct 13, 2015 at 6:21 AM, Daniel Colascione <dancol@dancol.org> wrote:
> I think I know what's going on. Stefan's change moved some of the
> syntax-propertize stuff from Lisp into C. Now Emacs core has a variable
> called syntax-propertize--done, known in C as syntax_propertize__done.
> We make it buffer-local using Fmake_variable_buffer_local, but that
> makes the variable buffer-local when it's _set_. Until it's set, the
> variable retains its global value, which lives in the C variable
> syntax_propertize__done. So if we syntax-propertize 1000 characters of
> buffer A, then find-file in buffer B, we think we've syntax-propertized
> up to position 1000 (the value of syntax_propertize__done) until we set
> it to something else. In the case of Python, if we have a triple quote
> in the first 1000 characters, we infloop.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#21657: 25.0.50; Python mode goes into an infinite loop
2015-10-13 4:58 ` immerrr again
@ 2015-10-13 5:05 ` Daniel Colascione
2015-10-13 5:42 ` immerrr again
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Colascione @ 2015-10-13 5:05 UTC (permalink / raw)
To: immerrr again; +Cc: 21657, Dima Kogan, Luke Powers
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
Please don't top post.
On 10/12/2015 09:58 PM, immerrr again wrote:
> There's a patch to fix this in #21671.
I saw your message after I sent mine. How exactly is it supposed to
work? I can't reliably repro the condition that leads to the variable
being inherited across buffers (even with Torsten Bronger's testcase),
so I can't test it. It doesn't seem like adding a DEFSYM should make a
difference here though. Can you explain why your patch works?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#21657: 25.0.50; Python mode goes into an infinite loop
2015-10-13 5:05 ` Daniel Colascione
@ 2015-10-13 5:42 ` immerrr again
0 siblings, 0 replies; 6+ messages in thread
From: immerrr again @ 2015-10-13 5:42 UTC (permalink / raw)
To: Daniel Colascione; +Cc: 21657, Dima Kogan, Luke Powers
On Tue, Oct 13, 2015 at 8:05 AM, Daniel Colascione <dancol@dancol.org> wrote:
> I saw your message after I sent mine. How exactly is it supposed to
> work? I can't reliably repro the condition that leads to the variable
> being inherited across buffers (even with Torsten Bronger's testcase),
> so I can't test it. It doesn't seem like adding a DEFSYM should make a
> difference here though. Can you explain why your patch works?
>
Apparently, I was testing a version that was older than [1] since it
was reproduced reliably. With it, the variable indeed seems properly
buffer-local. I think I misread commit metadata in git blame thinking
that the commit was from the last year, so I presumed that my Emacs
version already had it. I couldn't find any docs about obarray
initialization procedure (DEFSYM code-generation and alike), that was
the only place where Fmake_variable_buffer_local was invoked on
intern("foo") instead of a DEFSYM-initialized variable and I didn't
have much time to deduce from sources how these two approaches differ,
so I simply changed it to look like the others and ensured that it
worked after the change. Feel free to ignore that patch if it is
unnecessary.
1. https://github.com/emacs-mirror/emacs/commit/0360b7f2c4f0358106e229de4dfe91a67445a50c
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-10-13 5:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-09 22:22 bug#21657: 25.0.50; Python mode goes into an infinite loop Dima Kogan
2015-10-09 23:16 ` Luke Powers
2015-10-13 3:21 ` Daniel Colascione
2015-10-13 4:58 ` immerrr again
2015-10-13 5:05 ` Daniel Colascione
2015-10-13 5:42 ` immerrr again
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).