bug#21671: [PATCH] fix python.el hanging up during fontification #21657

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[immerrr again]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

Two patches are included.

One fixes the fact that for some reason syntax-propertize--done has
ceased to be buffer-local after commit [1] and for some reason commit
[2] did not help. I did it the way other buffer-local variables are
initialized and it worked. The change fixes #21657 that was failing
because syntax-propertize--done was inherited from scratch buffer and
docstring boundaries were not propertized as a result.

The other infinite loop I found accidentally when adding a whitespace
before module docstring. I have fixed one corner-case of it, but in
other circumstances I'd argue that whatever smart extensions
python-mode adds to forward-sexp, those extensions should never move
point less than the normal forward-sexp should.

Cheers,
immerrr

1. https://github.com/emacs-mirror/emacs/commit/3928ef2dd5b8febf3b1d9c1bfb22af3698d16bea

2. https://github.com/emacs-mirror/emacs/commit/0360b7f2c4f0358106e229de4dfe91a67445a50c

[-- Attachment #2: 0002-Prevent-infinite-loop-in-python-info-docstring-p.patch --]
[-- Type: text/x-patch, Size: 1522 bytes --]

From 149066dbfc7f11c40f6dbed70a3279153bf3ab7a Mon Sep 17 00:00:00 2001
From: immerrr <immerrr@gmail.com>
Date: Mon, 12 Oct 2015 14:17:16 +0300
Subject: [PATCH 2/2] Prevent infinite loop in python-info-docstring-p

python-info-docstring-p did not expect that
python-nav-beginning-of-statement could leave point intact not at the
beginning of buffer which happened if the first statement in the file
was indented (it is a Python syntax error).

* python.el (python-nav--forward-sexp): if backward-sexp brought point
to the beginning of the buffer, leave it there
---
 lisp/progmodes/python.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 6ff12b5..7ccd204 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -1712,7 +1712,11 @@ expressions when looking at them in either direction."
                    (python-nav-beginning-of-block))
                   ((memq context '(statement-start block-start))
                    (goto-char next-sexp-pos)
-                   (python-nav-beginning-of-statement))
+                   (unless (bobp)
+                     ;; If backward-sexp brought the point to
+                     ;; beginning-of-buffer, beginning-of-statement
+                     ;; will only bring it back.
+                     (python-nav-beginning-of-statement)))
                   (t (goto-char next-sexp-pos))))))))))
 
 (defun python-nav-forward-sexp (&optional arg safe skip-parens-p)
-- 
2.6.1


[-- Attachment #3: 0001-Fix-syntax-propertize-done-to-be-buffer-local.patch --]
[-- Type: text/x-patch, Size: 1209 bytes --]

From a0878abd691e9cc36ee7298b249593a79cdd6029 Mon Sep 17 00:00:00 2001
From: immerrr <immerrr@gmail.com>
Date: Mon, 12 Oct 2015 14:16:48 +0300
Subject: [PATCH 1/2] Fix syntax-propertize--done to be buffer-local

* src/syntax.c (syms_of_syntax): fix syntax-propertize--done to be
buffer-local
---
 src/syntax.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/syntax.c b/src/syntax.c
index 6bfb3b7..4f7dcd7 100644
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -3668,11 +3668,12 @@ Otherwise, that text property is simply ignored.
 See the info node `(elisp)Syntax Properties' for a description of the
 `syntax-table' property.  */);
 
+  DEFSYM (Qsyntax_propertize__done, "syntax-propertize--done");
   DEFVAR_INT ("syntax-propertize--done", syntax_propertize__done,
 	      doc: /* Position up to which syntax-table properties have been set.  */);
   syntax_propertize__done = -1;
   DEFSYM (Qinternal__syntax_propertize, "internal--syntax-propertize");
-  Fmake_variable_buffer_local (intern ("syntax-propertize--done"));
+  Fmake_variable_buffer_local (Qsyntax_propertize__done);
 
   words_include_escapes = 0;
   DEFVAR_BOOL ("words-include-escapes", words_include_escapes,
-- 
2.6.1

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[immerrr again]

FTR, 0001-Fix-syntax-propertize-done.. patch seems unnecessary as commit [1]
does its job.

1. https://github.com/emacs-mirror/emacs/commit/0360b7f2c4f0358106e229de4dfe91a67445a50c

On Mon, Oct 12, 2015 at 2:48 PM, immerrr again <immerrr@gmail.com> wrote:
> Two patches are included.
>
> One fixes the fact that for some reason syntax-propertize--done has
> ceased to be buffer-local after commit [1] and for some reason commit
> [2] did not help. I did it the way other buffer-local variables are
> initialized and it worked. The change fixes #21657 that was failing
> because syntax-propertize--done was inherited from scratch buffer and
> docstring boundaries were not propertized as a result.
>
> The other infinite loop I found accidentally when adding a whitespace
> before module docstring. I have fixed one corner-case of it, but in
> other circumstances I'd argue that whatever smart extensions
> python-mode adds to forward-sexp, those extensions should never move
> point less than the normal forward-sexp should.
>
> Cheers,
> immerrr
>
> 1. https://github.com/emacs-mirror/emacs/commit/3928ef2dd5b8febf3b1d9c1bfb22af3698d16bea
>
> 2. https://github.com/emacs-mirror/emacs/commit/0360b7f2c4f0358106e229de4dfe91a67445a50c

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[Torsten Bronger]

Hallöchen!

immerrr again writes:

> FTR, 0001-Fix-syntax-propertize-done.. patch seems unnecessary as commit [1]
> does its job.

Does this mean that the infinite loop thingy is gone for Python
docstrings?

Tschö,
Torsten.

-- 
Torsten Bronger    Jabber ID: torsten.bronger@jabber.rwth-aachen.de

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[immerrr again]

Works for me. I'd still change a thing or two in python.el code, but
triplequoted strings are propertized, so it does not inf-loop anymore.

On Tue, Oct 13, 2015 at 11:43 AM, Torsten Bronger
<bronger@physik.rwth-aachen.de> wrote:
> Hallöchen!
>
> immerrr again writes:
>
>> FTR, 0001-Fix-syntax-propertize-done.. patch seems unnecessary as commit [1]
>> does its job.
>
> Does this mean that the infinite loop thingy is gone for Python
> docstrings?
>
> Tschö,
> Torsten.
>
> --
> Torsten Bronger    Jabber ID: torsten.bronger@jabber.rwth-aachen.de
>
>
>
>

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[Lars Ingebrigtsen]

immerrr again <immerrr@gmail.com> writes:

> Works for me. I'd still change a thing or two in python.el code, but
> triplequoted strings are propertized, so it does not inf-loop anymore.

Ok; closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[immerrr again]

On Tue, Feb 23, 2016 at 11:06 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Ok; closing this bug report.
>

There were two patches in the original message, one contained a fix
for an issue fixed otherwise, the other can still infloop (as of
25.0.50.1), albeit in a rather unusual situation: when a python-mode
buffer starts with a whitespace followed by a quote.

What about the second patch?

Cheers,
immerrr

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[Lars Ingebrigtsen]

immerrr again <immerrr@gmail.com> writes:

> There were two patches in the original message, one contained a fix
> for an issue fixed otherwise, the other can still infloop (as of
> 25.0.50.1), albeit in a rather unusual situation: when a python-mode
> buffer starts with a whitespace followed by a quote.
>
> What about the second patch?

Could you repost the second patch?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[immerrr again]

[-- Attachment #1: Type: text/plain, Size: 199 bytes --]

On Tue, Feb 23, 2016 at 11:49 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> immerrr again <immerrr@gmail.com> writes:
>
> Could you repost the second patch?
>

Sure, attaching it.

Cheers,
immerrr

[-- Attachment #2: 0002-Prevent-infinite-loop-in-python-info-docstring-p.patch --]
[-- Type: text/x-patch, Size: 1522 bytes --]

From 149066dbfc7f11c40f6dbed70a3279153bf3ab7a Mon Sep 17 00:00:00 2001
From: immerrr <immerrr@gmail.com>
Date: Mon, 12 Oct 2015 14:17:16 +0300
Subject: [PATCH 2/2] Prevent infinite loop in python-info-docstring-p

python-info-docstring-p did not expect that
python-nav-beginning-of-statement could leave point intact not at the
beginning of buffer which happened if the first statement in the file
was indented (it is a Python syntax error).

* python.el (python-nav--forward-sexp): if backward-sexp brought point
to the beginning of the buffer, leave it there
---
 lisp/progmodes/python.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 6ff12b5..7ccd204 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -1712,7 +1712,11 @@ expressions when looking at them in either direction."
                    (python-nav-beginning-of-block))
                   ((memq context '(statement-start block-start))
                    (goto-char next-sexp-pos)
-                   (python-nav-beginning-of-statement))
+                   (unless (bobp)
+                     ;; If backward-sexp brought the point to
+                     ;; beginning-of-buffer, beginning-of-statement
+                     ;; will only bring it back.
+                     (python-nav-beginning-of-statement)))
                   (t (goto-char next-sexp-pos))))))))))
 
 (defun python-nav-forward-sexp (&optional arg safe skip-parens-p)
-- 
2.6.1

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[Lars Ingebrigtsen]

immerrr again <immerrr@gmail.com> writes:

> @@ -1712,7 +1712,11 @@ expressions when looking at them in either direction."
>                     (python-nav-beginning-of-block))
>                    ((memq context '(statement-start block-start))
>                     (goto-char next-sexp-pos)
> -                   (python-nav-beginning-of-statement))
> +                   (unless (bobp)
> +                     ;; If backward-sexp brought the point to
> +                     ;; beginning-of-buffer, beginning-of-statement
> +                     ;; will only bring it back.
> +                     (python-nav-beginning-of-statement)))
>                    (t (goto-char next-sexp-pos))))))))))

I'm not a Python mode user, so I can't really review this patch.  I've
reopened the bug -- could somebody else have a peek at this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[npostavs]

unarchive 24905
forcemerge 24905 21671
quit

Lars Ingebrigtsen <larsi@gnus.org> writes:

> immerrr again <immerrr@gmail.com> writes:
>
>> @@ -1712,7 +1712,11 @@ expressions when looking at them in either direction."
>>                     (python-nav-beginning-of-block))
>>                    ((memq context '(statement-start block-start))
>>                     (goto-char next-sexp-pos)
>> -                   (python-nav-beginning-of-statement))
>> +                   (unless (bobp)
>> +                     ;; If backward-sexp brought the point to
>> +                     ;; beginning-of-buffer, beginning-of-statement
>> +                     ;; will only bring it back.
>> +                     (python-nav-beginning-of-statement)))
>>                    (t (goto-char next-sexp-pos))))))))))
>
> I'm not a Python mode user, so I can't really review this patch.  I've
> reopened the bug -- could somebody else have a peek at this?

AFAICT, the problem is solved in #24905, so there is no need for this
patch.

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[immerrr again]

On Mon, Oct 12, 2015 at 2:48 PM, immerrr again <immerrr@gmail.com> wrote:
> Two patches are included.
>

Is there anything that prevents merging the second patch
(0002-Prevent-infinite-...) that fixes the situation described below?

>
> The other infinite loop I found accidentally when adding a whitespace
> before module docstring. I have fixed one corner-case of it, but in
> other circumstances I'd argue that whatever smart extensions
> python-mode adds to forward-sexp, those extensions should never move
> point less than the normal forward-sexp should.

Cheers,
immerrr

bug#21671: [PATCH] fix python.el hanging up during fontification #21657

[immerrr again]

On Sat, Oct 24, 2015 at 7:04 PM, immerrr again <immerrr@gmail.com> wrote:
> On Mon, Oct 12, 2015 at 2:48 PM, immerrr again <immerrr@gmail.com> wrote:
>> Two patches are included.
>>
>> snip
>>
>> The other infinite loop I found accidentally when adding a whitespace
>> before module docstring. I have fixed one corner-case of it, but in
>> other circumstances I'd argue that whatever smart extensions
>> python-mode adds to forward-sexp, those extensions should never move
>> point less than the normal forward-sexp should.

Any comments about the five-line patch that fixes the situation described above?

Cheers,
immerrr