[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company
From: |
Noam Postavsky |
Subject: |
bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled |
Date: |
Thu, 04 Apr 2019 22:36:20 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1.91 (gnu/linux) |
Carlos Pita <carlosjosepita@gmail.com> writes:
> Nevertheless I found the origin of the problem. Somehow when company
> is enabled in the shell buffer
> python-shell-font-lock-comint-output-filter-function is getting empty
> strings as output and then the ";; Otherwise just add a newline."
> clause is activated.
> 1. The first one (Avoid-spurious...) strictly fixes this issue by
> moving the not-empty condition to the top and doing everything else
> unless not-empty. Period. That works.
Hmm, I'm not sure if it's working here. My *Python* buffer looks like
this:
Python 3.7.0 (default, Sep 15 2018, 19:13:07)
Type 'copyright', 'credits' or 'license' for more information
IPython 6.5.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: 1 + len('123') + 99 + len('aa')
In [13]: 1 + len('123') + 99 + len('aa')
Out[13]: 105
In [14]: 1 + len('123') + 99 + len('aa')
In [14]: 1 + len('123') + 99 + len('aa')
Out[14]: 105
In [15]: 1 + len('123') + 99 + len('aa')
In [21]: 1 + len('123') + 99 + len('aa')
Out[21]: 105
In [22]:
And my " *Python-font-lock*" looks like this:
1 + len('123') + 99 + len('aa')
1 + len(
1 + len('123'
1 + len('123') + 99 + len('aa')
The behaviour seems rather inconsistent. I think to solve this properly
we need some deterministic tests which reproduce the problem.
- bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled,
Noam Postavsky <=