On Sat, 13 Aug 2022 at 11:26, Stefan Kangas wrote: >> Subject: [PATCH 2/4] python.el: Adjustments to Flymake back-end > > How about: > > python.el: Support pyflakes 2.4+ in flymake > This commit includes a second change advertising the possibility to use the pylint program. Moreover, I'm not claiming that pyflakes changed in version 2.4; the change probably happened further in the past. So I made this statement less specific. (BTW, instead of writing things like "To use `flake8' you would set this to ..." in a docstring, wouldn't it make sense for describe-variable to list the suggested customization values from the :type specification?) > Maybe include an example of the old/new pattern in comments? Or even > better actually: add a test for it. I've added some tests. >> From 95675a3f63bc420813992d7b599e99b303e4fd63 Mon Sep 17 00:00:00 2001 >> From: Augusto Stoffel >> Date: Sat, 13 Aug 2022 18:10:14 +0200 >> Subject: [PATCH 3/4] python.el: Add completion-predicate symbol property to >> commands >> >> * lisp/progmodes/python.el: Add a completion-predicate property to >> most commands defined in this file; some are only useful in >> python-mode, others in inferior-python mode as well. >> (python-skeleton-define, python-define-auxiliary-skeleton): Add >> appropriate completion-predicate properties. > > This makes sense, but how about just creating a new mode > python-common-mode that both python-mode and inferior-python-mode could > inherit from? Would that simplify things here? In any case there are two cases to consider anyway: commands that only make sense in Python source code, and commands that make sense in code or in the REPL (we might eventually have code that makes sense just in the REPL, that's not the case now). So for the current purposes this suggestion wouldn't really simplify anything. > I'm fine with this as `outline-heading-end-regexp' doesn't seem to see > much use in any case (and folding to one line somehow seems nicer > anyways). > > However, it seems like we might be able to do find a fix here with just > a small number of assumptions, if we really wanted to. I guess the fix would be not to look for the next colon, but instead to the next colon skipping over pairs of delimiters. But then we couldn't use regexps, and moreover things wouldn't work on incomplete code during editing. And I also think folding on one line makes just as much sense, if it isn't better. So it looks like removing this is the best option.