bug#57184: [PATCH] Assorted improvements to python.el

[Augusto Stoffel]

Hi Stefan,

I've attached new patches, see below for comments on your comments.  (As
to the smaller style changes, feel free to copyedit my patches before
merging in case I still let something slip.)

0001-python-check-command-Don-t-use-absolute-file-names.patch
Description: Text Data

0002-python.el-Adjustments-to-Flymake-backend.patch
Description: Text Data

0003-python.el-Add-completion-predicate-symbol-property-t.patch
Description: Text Data

0004-python-mode-Remove-special-outline-heading-end-regex.patch
Description: Text Data

On Sat, 13 Aug 2022 at 11:26, Stefan Kangas <stefankangas@gmail.com> 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 <arstoffel@gmail.com>
>> 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.