GNU bug report logs - #74894
29.4; Emacs not responding when calling python-fix-imports

Previous Next

Package: emacs;

Reported by: Keglo Stephane <stephanekeglo <at> gmail.com>

Date: Sun, 15 Dec 2024 18:44:02 UTC

Severity: normal

Found in version 29.4

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: kobarity <kobarity <at> gmail.com>
To: Keglo  Stephane <stephanekeglo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74894 <at> debbugs.gnu.org
Subject: bug#74894: 29.4; Emacs not responding when calling python-fix-imports
Date: Sun, 02 Mar 2025 16:04:17 +0900
Keglo Stephane wrote:
> 
> Hello Sir,
> 
> This is the output of the backtrace
> 
> Debugger entered--Lisp error: (quit)
>   call-process("python" nil (#<buffer  *temp*> nil) nil "-c" "from isort import find_imports_in_stream, find_imp..." ""
> "/home/stephanek/")
>   apply(call-process "python" nil (#<buffer  *temp*> nil) nil "-c" "from isort import find_imports_in_stream,
> find_imp..." "" "/home/stephanek/")

Thanks, I understand the situation.  You are editing a file directly
under your home directory (/home/stephanek/).  In that case, Emacs
tries to extract the import statement from all Python files under the
home directory.  If there are many files, this will take a long time
and it will appear to hang.  It is the same as running the following
command:

isort-identify-imports /home/stephanek

The workaround is to create a directory and move the Python files
there for editing.  If for some reason the file needs to be directly
under your home directory, I would suggest creating a symbolic link to
it.

Editing Python files directly under the home directory is one of the
standard use cases, but I think it is outside the use case envisioned
by the python.el's import management.

kobarity wrote:
> The other problem I found is that if I run `python-fix-imports'
> without saving the buffer, I get the following error:
> 
> python exited with status 1
> 
> This occurs because isort cannot read the lock file (symbolic link)
> such as ".#foo.py", which is created before the modified buffer is
> saved.  Although I don't think this has anything to do with the
> non-response issue.

I thought the problem here was an isort problem, so I reported it in
the following issue and suggested a PR, which was incorporated into
isort 6.0.1.

https://github.com/PyCQA/isort/issues/2330




This bug report was last modified 79 days ago.

Previous Next


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