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

Previous Next

Full log

Message #65 received at 33959 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33959 <at> debbugs.gnu.org
Subject: Re: bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when
 company is enabled
Date: Mon, 14 Oct 2019 21:52:03 -0300

> And also the overlap with the Bug#32390 fix made things more
> confusing; now that I've pushed it, at least that problem is gone.

I'm in the process of creating a patch for this that applies on top of
your recent commit and it's just wrapping everything into:

   (unless (string= output "") ... )

So I believe that if you already bought to other one this is way
easier to buy :)

Even without further digging into the specifics of the issue, I'd
advanced an argument for adding that guard:

> No matter the reason why empty output is being passed to the filter,
> it's wrong for the filter to add a new line to the font lock buffer if
> this happens.

And the check for empty output was always there, but in conjunction
with a check for "just a prompt":

(if (and (not (string= "" output)) (not just-a-prompt))
       do-something
   add-a-newline)

I think it's clear this logic is faulty. Both an empty output and a
just-a-prompt output are reasons not to do-something. But only
just-a-prompt is a reason to add-a-newline.

Have I been persuasive enough now :) ?

Previous Next

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