bug#47657: python-shell font-lock with multi-line input: runaway fontification buffer length

[JD Smith <jdtsmith@gmail.com>]

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

Very odd, I get :

1
1
7

in *Python-font-lock* after precisely these same steps.  What if you use C-j in step #5 instead of C-c SPC?


> On Apr 25, 2021, at 1:34 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> JD Smith <jdtsmith@gmail.com> writes:
> 
>> 1 emacs -Q
>> 2 M-x run-python
>> 3 C-x 5 b “ *Python-font-lock*”
>> 4 In inferior python shell: type any line.
>> 5 C-c SPC (`comint-accumulate’) to continue.
>> 6 Type another line.  Notice the first line is repeated. 
>> 7 Repeat steps 5 & 6 several times. 
>> 
>> You didn't say what Emacs version you're using -- I tested this in Emacs
>> 28, and was unable to reproduce this.  The " *Python-font-lock*" buffer
>> never contains more than a single non-blank line using this recipe.
>> (The "any line" I used to test was "5”.)
>> 
>> Mac port, v27.2, python-mode v0.26.1.  I have a hard time
>> understanding how this would not reproduce, as
>> (buffer-substring-no-properties prompt-end (point-max)) clearly takes
>> all of the text (multi-lines included) from the prompt onward.  I took
>> a look here (python-mode v0.27.1) and the input is gathered in the
>> same manner in the post-command-hook.  The “repeated” lines in #6 are
>> in the *Python-font-lock* buffer, btw.
> 
> After typing "1" in 4) and "7" in 6), the buffer looks like:
> 
> <Mail Attachment.png>
> So just the "7", and not the first line, which was "1".
> 
> Perhaps there's some missing element in your recipe?
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no


[-- Attachment #2: Type: text/html, Size: 2873 bytes --]