python mode bugs

[James K. Lowden]

I have two problems with python.el. Maybe three.

1. GNU bug report logs - #29717[1]: imenu does not recognize function
definitions with annotations.

2. imenu is purportedly bound to C-c C-j, but no "index" I supply
returns anything but errors. What does it want?

3. At 111 days old, it doesn't seem like the known bug is getting any
attention. What is the polite way to indicate it matters?

In case you *really* want to help, the offending function appears to be

python-imenu--build-tree

and the regex

python-nav-beginning-of-defun-regexp

The difference in the pattern to be matched is:

def f(a, b): #works
vs
def f(a: int, b: str) -> bool: # fails

FWIW, I don't think the regex need include anything after the leading
parenthesis. The following awk script is too simple because it doesn't
recognize nested functions and class methods, but otherwise does the
trick:

awk -F'[\t ()]' '/^def +/ {print $2}'

Any help much appreciated.

--jkl
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29717

[Stefan Monnier]

> 3. At 111 days old, it doesn't seem like the known bug is getting any
> attention. What is the polite way to indicate it matters?

You can send a new message to that bug-report with a shirt content like
"ping?" or "Is anybody here? it's been 111 days and I still haven't
heard anything".

Even better, you can add info such as the one you provide below:

> In case you *really* want to help, the offending function appears to be
>
> python-imenu--build-tree
>
> and the regex
>
> python-nav-beginning-of-defun-regexp
>
> The difference in the pattern to be matched is:
>
> def f(a, b): #works
> vs
> def f(a: int, b: str) -> bool: # fails
>
> FWIW, I don't think the regex need include anything after the leading
> parenthesis. The following awk script is too simple because it doesn't
> recognize nested functions and class methods, but otherwise does the
> trick:
>
> awk -F'[\t ()]' '/^def +/ {print $2}'

which might allow even Emacs contributors not familiar with Python to
come up with a fix.


Stefan

[Ben Bacarisse]

"James K. Lowden" <jklo...@speakeasy.net> writes:

> I have two problems with python.el. Maybe three.
>
> 1. GNU bug report logs - #29717[1]: imenu does not recognize function
> definitions with annotations.
>
> 2. imenu is purportedly bound to C-c C-j, but no "index" I supply
> returns anything but errors. What does it want?

It wants the name of a class or a function and will auto-complete but if
imenu is not finding and to start with there will be nothing you enter
here!

> 3. At 111 days old, it doesn't seem like the known bug is getting any
> attention. What is the polite way to indicate it matters?

Some people say "Ping?".

> In case you *really* want to help, the offending function appears to be
>
> python-imenu--build-tree
>
> and the regex
>
> python-nav-beginning-of-defun-regexp
>
> The difference in the pattern to be matched is:
>
> def f(a, b): #works
> vs
> def f(a: int, b: str) -> bool: # fails

The pattern in python-nav-beginning-of-defun-regexp does not seem to be
the culprit. It matches both of these.

> FWIW, I don't think the regex need include anything after the leading
> parenthesis.

Yes, that's what python-nav-beginning-of-defun-regexp does. Nothing
after the name is examined. In fact, it matches a def with no '(' at all.

The problem appears to be somewhere else, most likely in
python-imenu--build-tree as you say.

> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29717
--
Ben.

[Robert Pluim]

Ben Bacarisse <ben....@bsb.me.uk> writes:

> "James K. Lowden" <jklo...@speakeasy.net> writes:
>
>> I have two problems with python.el. Maybe three.
>>
>> 1. GNU bug report logs - #29717[1]: imenu does not recognize function
>> definitions with annotations.
>>
>> 2. imenu is purportedly bound to C-c C-j, but no "index" I supply
>> returns anything but errors. What does it want?

Which version of emacs are you using? This seems to work fine for me
in Emacs 26 and 27.

Robert

[Ben Bacarisse]

You don't quote anything I said but you might be asking me too. So,
just in case, I'm using 25.1.1.

--
Ben.

[Robert Pluim]

Hmm, C-c C-j doesnʼt have an issue for me in 25.1. This happens from
emacs -Q as well?

Robert

[Ben Bacarisse]

M-X imenu works both with emacs -Q and with my normal startup. It
failed to find functions with type annotations when I originally tried
because that was an emacsclient and something must have happened since I
stared the server.

After restarting the server, emacsclient behaves (unsurprisingly) just
like a fresh emacs run: imenu shows all functions in a test Python file,
even those with type annotations.

However, emacs -Q shows me more information! It indicates if the index
item is a def or a class etc. It seems I have python-mode installed and
emacs -Q is using python.el.gz and emacs is using python-mode.elc.

So my data point was not useful.

However, the OP should check if they are using python-mode (shown as
"Py") or python.el (shown as "Python").

--
Ben.

[James K. Lowden]

On Fri, 06 Apr 2018 14:43:44 +0200
Robert Pluim <rpl...@gmail.com> wrote:

> >>>> 2. imenu is purportedly bound to C-c C-j, but no "index" I
> >>>> supply returns anything but errors. What does it want?
> >>
> >> Which version of emacs are you using? This seems to work fine for
> >> me in Emacs 26 and 27.
>

> Hmm, C-c C-j doesn?t have an issue for me in 25.1. This happens from
> emacs -Q as well?

Gah, of course! I'm using 25.1, too and -- I'm sorry and happy to say
-- it turns out I have a local problem, because it works as advertized
with -Q.

Sorry for the distraction. I'll spend see if I can find the proximate
cause, and if there's any useful information.

Thanks for pointing out the obvious, and to everyone else who offered
suggestions. Hopefully I'll be able to show why the bug should be
closed.

--jkl

[Andreas Röhler]

On 06.04.2018 15:29, Ben Bacarisse wrote:

> However, emacs -Q shows me more information! It indicates if the index
> item is a def or a class etc.

Hi,

python-mode.el developer here. Indeed left out some advertisement,
because if at "def" or "class" should be indicated by the given keyword
already. Case there is some other occasion and info not redundant, it
might be helpful to learn about.

Best,

Andreas

[Ben Bacarisse]

Andreas Röhler <andreas...@easy-emacs.de> writes:

> On 06.04.2018 15:29, Ben Bacarisse wrote:
>
>> However, emacs -Q shows me more information! It indicates if the index
>> item is a def or a class etc.
>

> python-mode.el developer here. Indeed left out some advertisement,
> because if at "def" or "class" should be indicated by the given
> keyword already. Case there is some other occasion and info not
> redundant, it might be helpful to learn about.

I am only a very occasional Python programmer so I am not a good source
of information. The ! in my remark was not intended to express any
great pleasure from the extra information, just surprise at the
different behaviour. As the time I did not know that python-mode.el and
python.el were both present and working slightly differently.

--
Ben.

[Andreas Röhler]

Thanks. Might have missed something.

Andreas,
considering which info to display an interesting question

[James K. Lowden]

On Thu, 5 Apr 2018 15:50:15 -0400
"James K. Lowden" <jklo...@speakeasy.net> wrote:

> 1. GNU bug report logs - #29717[1]: imenu does not recognize function
> definitions with annotations.

Just to remind the casual reader, this is a non-issue. imenu works
just fine by iteself: with "emacs -Q", it annotations do not interefere
with recognizing Python function defintions.

The source of conflict in my .emacs file is apparently one important
line:

(semantic-mode 1)

If semantic is never enabled, imenu works as advertised. After semantic
is enabled, imenu stops working (c-C c-J fails to jump to most
functions). Turning semantic-mode off after it's been enabled makes no
difference: it's broken, and you get to keep both pieces.

Now that I know about it, it's not a giant problem. I can have two
emacs sessions, one for Python without semantic, and the other with
semantic and not for Python.

However, if someone wants to look into it further, I'm happy to provide
such information as I can to help narrow down the conflict, if that's
what it is.

--jkl

[Colin Baxter]

Hello James,

>>>>> James K Lowden <jklo...@speakeasy.net> writes:

> On Thu, 5 Apr 2018 15:50:15 -0400
> "James K. Lowden" <jklo...@speakeasy.net> wrote:

>> 1. GNU bug report logs - #29717[1]: imenu does not recognize
>> function definitions with annotations.

> Just to remind the casual reader, this is a non-issue. imenu
> works just fine by iteself: with "emacs -Q", it annotations do not
> interefere with recognizing Python function defintions.

> The source of conflict in my .emacs file is apparently one
> important line:

> (semantic-mode 1)

Imenu works for me (in python, at least) if I enable semantic via M-x
semantic-mode and not from my ~/.emacs file.

Best wishes,