[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32390: [ipython 6.x] unmatched quotes break fontification in run-pyt
From: |
Noam Postavsky |
Subject: |
bug#32390: [ipython 6.x] unmatched quotes break fontification in run-python |
Date: |
Wed, 05 Sep 2018 22:32:04 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Carlos Pita <carlosjosepita@gmail.com> writes:
> Why not simply:
>
> (python-shell-comint-end-of-output-p
> (ansi-color-filter-apply output)))
>
> ?
>
> What is the problem when just an input prompt is retrieved (that is,
> the 0 case in (nil 0))?
I guess that's the "not just a prompt" in the comment:
;; Is end of output and is not just a prompt.
But it seems that python.el is assuming a certain chunking of output
from the subprocess, which is really not a safe assumptiong. And
ipython 6 breaks it.
> The current condition is also failing for multiline input. Consider:
>
>
> In [154]: def f():
> ...: 'ewewe
> ...:
>
> output is " ...:" so it's not considered just an input prompt
> (because of the preceding whitespace) and so the font lock buffer is
> wrongly cleaned up (indeed, this is the only case I'm able to figure
> out for which you don't want to cleanup the buffer).
>
> I think the condition should be reformulated to match any expression
> that ends with an input prompt excluding a continuation prompt. This
> would fix both problems:
>
> 1. An expression that is just an input prompt (for example, ansi
> filtered errors) will trigger a cleanup.
> 2. A continuation input prompt will not be considered the start of
> a new input.
This sounds quite sensible to me.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#32390: [ipython 6.x] unmatched quotes break fontification in run-python,
Noam Postavsky <=