From: Noam Postavsky <npostavs@gmail.com>
To: Carlos Pita <carlosjosepita@gmail.com>
Cc: 33959@debbugs.gnu.org
Subject: bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled
Date: Tue, 22 Oct 2019 20:18:17 -0400 [thread overview]
Message-ID: <87y2xcco1i.fsf@gmail.com> (raw)
In-Reply-To: <CAELgYhfFTr70Mj_CYmFSDFDZKDOiM1a6g+1toQUxFU4jRsOFCw@mail.gmail.com> (Carlos Pita's message of "Wed, 16 Oct 2019 17:35:42 -0300")
tags 33959 fixed
close 33959 27.1
quit
Carlos Pita <carlosjosepita@gmail.com> writes:
> Hi Noam, I don't want to be insistent (and I'm probably being)
No worries, sorry for taking so long on this.
> As it is now, it's certainly buggy. I know it would be desirable to
> provide an unit test for [1] but this new commit I'm providing can't
> harm (remember it's just an "around advice": `(unless (string= output
> "") ... )`) and I believe my argument against the way the empty output
> condition was checked before is sound and simple enough. Thanks and
> sorry for the insistence.
Looking at this now afresh, I agree that this change looks safe
enough. I think I was confused before by the other patch removing that
same guard in the first branch of the `if'.
I do suspect that the filter function receiving an empty string is a bug
in itself though. Meanwhile I've pushed your fix (since we'll want it
in the GNU ELPA python.el for Emacs 26 and earlier regardless of whether
the underlying process filter bug is fixed).
[2: ab67287872]: 2019-10-22 20:11:49 -0400
Avoid extra lines in python-shell font lock buffer (Bug#33959)
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ab6728787245e0d46bd8a8919e30c882f6011182
prev parent reply other threads:[~2019-10-23 0:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 2:08 bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when eldoc is enabled Carlos Pita
2019-01-03 2:34 ` bug#33959: Carlos Pita
2019-01-03 4:40 ` bug#33959: Carlos Pita
2019-01-03 5:38 ` bug#33959: Carlos Pita
2019-04-05 2:36 ` bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled Noam Postavsky
2019-04-16 21:47 ` Carlos Pita
2019-04-16 22:04 ` Noam Postavsky
2019-04-16 22:08 ` Carlos Pita
2019-04-16 22:14 ` Carlos Pita
2019-04-16 23:01 ` Noam Postavsky
2019-04-16 23:51 ` Noam Postavsky
2019-05-11 3:51 ` Noam Postavsky
2019-04-05 2:55 ` bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when eldoc " Noam Postavsky
2019-04-16 20:42 ` Carlos Pita
2019-10-13 19:39 ` bug#33959: Carlos Pita
2019-10-13 19:44 ` bug#33959: Lars Ingebrigtsen
2019-10-13 19:51 ` bug#33959: Carlos Pita
2019-10-15 0:34 ` bug#33959: 26.1.90; python.el font-lock buffer wreaks havoc when company is enabled Noam Postavsky
2019-10-15 0:52 ` Carlos Pita
2019-10-15 0:58 ` Carlos Pita
2019-10-16 20:35 ` Carlos Pita
2019-10-21 20:56 ` Carlos Pita
2019-10-23 0:18 ` Noam Postavsky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2xcco1i.fsf@gmail.com \
--to=npostavs@gmail.com \
--cc=33959@debbugs.gnu.org \
--cc=carlosjosepita@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).