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

[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.





reply via email to

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