bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47657: python-shell font-lock with multi-line input: runaway fontifi


From: JD Smith
Subject: bug#47657: python-shell font-lock with multi-line input: runaway fontification buffer length
Date: Sun, 25 Apr 2021 13:53:35 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]