GNU bug report logs - #33959
26.1.90; python.el font-lock buffer wreaks havoc when company is enabled

Previous Next

Full log

View this message in rfc822 format

From: Noam Postavsky <npostavs <at> gmail.com>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 33959 <at> debbugs.gnu.org
Subject: bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled
Date: Tue, 16 Apr 2019 18:04:01 -0400

Carlos Pita <carlosjosepita <at> gmail.com> writes:

> Hi Noam,
>
>> 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.
>
>
> The state of your " *Python-font-lock*" buffer is exactly what I mean.
> The duplications you see are caused by spurious newlines added when
> empty output is passed to the filter. There are two bad things there:
> i) empty strings are transformed into new lines and 2) empty strings
> are an undesirable side effect of company being triggered in a hidden
> buffer (this is analogous to the problem with org mode hidden buffer
> and yasnippet that I recently reported). Try disabling company mode in
> python font lock buffer; even though, this is not necessary if (i)
> above is fixed, which IMO should be done independently of the nasty
> company interaction.
>
> Besides, remember that patch 2 is fixing two different issues. This is
> somewhat undesirable but there are a lot of overlapping between them.
> Nevertheless, I provided patch 1 in case you are unwilling to apply
> one of them.

The above state happens after I've applied your patch #2.  So I can't
tell if it fixes anything.  That's why I think we need some
deterministic tests to show what is fixed and what is broken.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.