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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74894 in the body.
You can then email your comments to 74894 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Keglo Stephane <stephanekeglo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.4; Emacs not responding when calling python-fix-imports
Date: Sun, 15 Dec 2024 02:52:53 +0000

[Message part 1 (text/plain, inline)]

when writting a python code with a missing import, using
`python-fix-imports' make emacs not responding.


In GNU Emacs 29.4 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.0) of 2024-10-10 built on
4825182c94fc4195b65c80c30f523a16
System Description: Fedora Linux 41 (Workstation Edition)

Configured using:
'configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
--sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-cairo --with-dbus --with-gif
--with-gpm=no --with-harfbuzz --with-jpeg --with-json --with-modules
--with-native-compilation=aot --with-pgtk --with-png --with-rsvg
--with-sqlite3 --with-tiff --with-tree-sitter --with-webp --with-xpm
build_alias=x86_64-redhat-linux-gnu host_alias=x86_64-redhat-linux-gnu
CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2 -flto=auto -ffat-lto-objects
-fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer ' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed
-Wl,-z,pack-relative-relocs -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-specs=/usr/lib/rpm/redhat/redhat-package-notes '
PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig CXX=g++
'CXXFLAGS=-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer ''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
 value of $LANG: en_US.UTF-8
 value of $XMODIFIERS: @im=ibus
 locale-coding-system: utf-8-unix

Major mode: Python

Minor modes in effect:
 eglot--managed-mode: t
 flymake-mode: t
 global-treesit-auto-mode: t
 corfu-popupinfo-mode: t
 global-corfu-mode: t
 corfu-mode: t
 marginalia-mode: t
 vertico-mode: t
 electric-pair-mode: t
 recentf-mode: t
 global-auto-revert-mode: t
 global-hl-line-mode: t
 save-place-mode: t
 global-display-line-numbers-mode: t
 display-line-numbers-mode: t
 savehist-mode: t
 override-global-mode: t
 tooltip-mode: t
 global-eldoc-mode: t
 eldoc-mode: t
 show-paren-mode: t
 electric-indent-mode: t
 mouse-wheel-mode: t
 menu-bar-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 blink-cursor-mode: t
 column-number-mode: t
 line-number-mode: t
 transient-mark-mode: t
 auto-composition-mode: t
 auto-encryption-mode: t
 auto-compression-mode: t
 auto-save-visited-mode: t

Load-path shadows:
/home/kstephane/.emacs.d/elpa/jsonrpc-1.0.25/jsonrpc hides 
/usr/share/emacs/29.4/lisp/jsonrpc
/home/kstephane/.emacs.d/elpa/eglot-1.17/eglot hides 
/usr/share/emacs/29.4/lisp/progmodes/eglot
/home/kstephane/.emacs.d/elpa/eldoc-1.15.0/eldoc hides 
/usr/share/emacs/29.4/lisp/emacs-lisp/eldoc

Features:
(shadow sort mail-extr emacsbug jka-compr shortdoc dabbrev cape-keyword
cape pyimport s pyimport-autoloads dash bug-reference dash-autoloads
s-autoloads loaddefs-gen lisp-mnt tar-mode arc-mode archive-mode
mm-archive message sendmail yank-media dired dired-loaddefs rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util mailabbrev
gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils gnutls
network-stream url-cache url-http url-auth mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny help-fns
radix-tree cl-print pulse eglot external-completion jsonrpc xref
flymake-proc flymake thingatpt diff diff-mode ert ewoc debug backtrace
find-func compile imenu pyvenv-auto pyvenv eshell esh-cmd generator
esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util
files-x python pcase comint ansi-osc ring ansi-color time-date mule-util
project consult bookmark text-property-search pp comp comp-cstr warnings
icons rx treesit-auto treesit corfu-popupinfo corfu edmacro kmacro
orderless marginalia vertico compat compat-30 try dracula-theme
solarized-light-theme solarized-theme solarized solarized-faces color
flatui-theme monokai-theme cl-extra help-mode elec-pair recentf
tree-widget wid-edit autorevert filenotify hl-line saveplace
display-line-numbers savehist use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core finder-inf cape-autoloads consult-autoloads
corfu-autoloads dracula-theme-autoloads eglot-autoloads eldoc-autoloads
flatui-theme-autoloads ivy-autoloads jsonrpc-autoloads
marginalia-autoloads monokai-theme-autoloads orderless-autoloads
pyvenv-auto-autoloads pyvenv-autoloads solarized-theme-autoloads
treesit-auto-autoloads try-autoloads vertico-autoloads info
compat-autoloads package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util mailcap url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp
byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 683304 127932)
(symbols 48 26561 1)
(strings 32 181120 4632)
(string-bytes 1 5152913)
(vectors 16 50296)
(vector-slots 8 913218 108362)
(floats 8 406 386)
(intervals 56 1752 816)
(buffers 984 33))

[Message part 2 (text/html, inline)]

Message #8 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Keglo Stephane <stephanekeglo <at> gmail.com>, kobarity <kobarity <at> gmail.com>
Cc: 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sat, 21 Dec 2024 12:39:55 +0200

> Date: Sun, 15 Dec 2024 02:52:53 +0000
> From: Keglo Stephane <stephanekeglo <at> gmail.com>
> 
> when writting a python code with a missing import, using
> `python-fix-imports' make emacs not responding.

Thanks.  Could you please show a simple recipe for reproducing this?

kobarity, any comments or suggestions?

Message #11 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74894 <at> debbugs.gnu.org, Keglo Stephane <stephanekeglo <at> gmail.com>
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sun, 22 Dec 2024 00:16:53 +0900

Eli Zaretskii wrote:
> 
> > Date: Sun, 15 Dec 2024 02:52:53 +0000
> > From: Keglo Stephane <stephanekeglo <at> gmail.com>
> > 
> > when writting a python code with a missing import, using
> > `python-fix-imports' make emacs not responding.
> 
> Thanks.  Could you please show a simple recipe for reproducing this?
> 
> kobarity, any comments or suggestions?

I have not been able to reproduce this so far, but I have found that
if the file is large, say 10000 lines, it takes a few seconds.

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.

Message #14 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>, Keglo Stephane <stephanekeglo <at> gmail.com>
Cc: 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sat, 21 Dec 2024 18:12:15 +0200

> Date: Sun, 22 Dec 2024 00:16:53 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: Keglo Stephane <stephanekeglo <at> gmail.com>,
> 	74894 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > 
> > > Date: Sun, 15 Dec 2024 02:52:53 +0000
> > > From: Keglo Stephane <stephanekeglo <at> gmail.com>
> > > 
> > > when writting a python code with a missing import, using
> > > `python-fix-imports' make emacs not responding.
> > 
> > Thanks.  Could you please show a simple recipe for reproducing this?
> > 
> > kobarity, any comments or suggestions?
> 
> I have not been able to reproduce this so far, but I have found that
> if the file is large, say 10000 lines, it takes a few seconds.
> 
> 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.

Thanks.  So my request for a reproduction recipe still stands.  Keglo
Stephane, could you please provide such a recipe?

Message #17 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: Keglo Stephane <stephanekeglo <at> gmail.com>,
	Eli Zaretskii <eliz <at> gnu.org>
Cc: 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sun, 22 Dec 2024 10:21:09 +0900

Eli Zaretskii wrote:
> 
> > Date: Sun, 22 Dec 2024 00:16:53 +0900
> > From: kobarity <kobarity <at> gmail.com>
> > Cc: Keglo Stephane <stephanekeglo <at> gmail.com>,
> > 	74894 <at> debbugs.gnu.org
> > 
> > Eli Zaretskii wrote:
> > > 
> > > > Date: Sun, 15 Dec 2024 02:52:53 +0000
> > > > From: Keglo Stephane <stephanekeglo <at> gmail.com>
> > > > 
> > > > when writting a python code with a missing import, using
> > > > `python-fix-imports' make emacs not responding.
> > > 
> > > Thanks.  Could you please show a simple recipe for reproducing this?
> > > 
> > > kobarity, any comments or suggestions?
> > 
> > I have not been able to reproduce this so far, but I have found that
> > if the file is large, say 10000 lines, it takes a few seconds.
> > 
> > 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.
> 
> Thanks.  So my request for a reproduction recipe still stands.  Keglo
> Stephane, could you please provide such a recipe?

If it is difficult to establish a reproduction recipe, please do a
little research in your environment.

While Emacs is not responding, run "top" to see if there is a process
with high CPU utilization.  It is likely Python or Emacs is using CPU.
If the CPU utilization of Python is high, please tell us the arguments
of the Python process.  If the CPU utilization of Emacs is high,
please check if you can abort with Ctrl-G or sending SIGUSR2 signal.
If you can abort, please send the backtrace:

1. emacs -Q
2. M-x load-fie
   Specify the location of python.el (or python.el.gz, not
   python.elc).  You can use M-x locate-library and enter "python" to
   locate the file.
3. M-x toggle-debug-on-quit
4. Reproduce the issue.
5. Abort with Ctrl-G or SIGUSR2.

Thanks in advance.

Message #20 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Keglo Stephane <stephanekeglo <at> gmail.com>
Cc: kobarity <kobarity <at> gmail.com>, 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4; Emacs not responding when calling
 python-fix-imports
Date: Sat, 04 Jan 2025 13:46:48 +0200

[Please use Reply All, to have everyone CC'ed.]

> Date: Sun, 22 Dec 2024 14:35:51 +0000
> From: Keglo Stephane <stephanekeglo <at> gmail.com>
> 
> This is a simple recipe to reproduce the bug:
> 1- open an empty python buffer
> 2- start an inferior python shell C-c C-p
> 3- Enter the following code:  print(string.digits) 
> 4- Evaluation of this code should throw an exception since the string module is not imported
> 5- Trying to use python-add-import ( C-c TAB a) or python-fix-imports ( C-c TAB fix) to add the missing
> import, Emacs freeze a moment.
> you have to press Ctrl-G to make Emacs respond again.

kobarity, any suggestions?

Message #23 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Keglo Stephane <stephanekeglo <at> gmail.com>
Cc: 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sat, 04 Jan 2025 23:17:29 +0900

Eli Zaretskii wrote:
> 
> [Please use Reply All, to have everyone CC'ed.]
> 
> > Date: Sun, 22 Dec 2024 14:35:51 +0000
> > From: Keglo Stephane <stephanekeglo <at> gmail.com>
> > 
> > This is a simple recipe to reproduce the bug:
> > 1- open an empty python buffer
> > 2- start an inferior python shell C-c C-p
> > 3- Enter the following code:  print(string.digits) 
> > 4- Evaluation of this code should throw an exception since the string module is not imported
> > 5- Trying to use python-add-import ( C-c TAB a) or python-fix-imports ( C-c TAB fix) to add the missing
> > import, Emacs freeze a moment.
> > you have to press Ctrl-G to make Emacs respond again.
> 
> kobarity, any suggestions?

Sorry, I did not realize that email was a DM.  Here is my reply:

> Thank you, but I cannot reproduce the problem.
> 
> Import management depends on the contents of the directory (or more
> precisely, the project).  If you try the above procedure with an empty
> directory (outside of a project, such as a Git repository), you may
> not have problems.  Therefore, it may be a little difficult to
> establish a reproducible recipe.
> 
> Just to add, import management works without inferior python.

So, my expectation is that Keglo will do the research I previously
mailed:

> While Emacs is not responding, run "top" to see if there is a process
> with high CPU utilization.  It is likely Python or Emacs is using CPU.
> If the CPU utilization of Python is high, please tell us the arguments
> of the Python process.  If the CPU utilization of Emacs is high,
> please check if you can abort with Ctrl-G or sending SIGUSR2 signal.
> If you can abort, please send the backtrace:
> 
> 1. emacs -Q
> 2. M-x load-fie
>    Specify the location of python.el (or python.el.gz, not
>    python.elc).  You can use M-x locate-library and enter "python" to
>    locate the file.
> 3. M-x toggle-debug-on-quit
> 4. Reproduce the issue.
> 5. Abort with Ctrl-G or SIGUSR2.

Other useful information includes:

- Whether you are working on "project"
- Whether or not the "freeze" last for a few minutes or so

Message #26 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephanekeglo <at> gmail.com, kobarity <kobarity <at> gmail.com>
Cc: 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sat, 18 Jan 2025 11:23:16 +0200

Ping!  Keglo, could you please respond?

> Date: Sat, 04 Jan 2025 23:17:29 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: 74894 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > 
> > [Please use Reply All, to have everyone CC'ed.]
> > 
> > > Date: Sun, 22 Dec 2024 14:35:51 +0000
> > > From: Keglo Stephane <stephanekeglo <at> gmail.com>
> > > 
> > > This is a simple recipe to reproduce the bug:
> > > 1- open an empty python buffer
> > > 2- start an inferior python shell C-c C-p
> > > 3- Enter the following code:  print(string.digits) 
> > > 4- Evaluation of this code should throw an exception since the string module is not imported
> > > 5- Trying to use python-add-import ( C-c TAB a) or python-fix-imports ( C-c TAB fix) to add the missing
> > > import, Emacs freeze a moment.
> > > you have to press Ctrl-G to make Emacs respond again.
> > 
> > kobarity, any suggestions?
> 
> Sorry, I did not realize that email was a DM.  Here is my reply:
> 
> > Thank you, but I cannot reproduce the problem.
> > 
> > Import management depends on the contents of the directory (or more
> > precisely, the project).  If you try the above procedure with an empty
> > directory (outside of a project, such as a Git repository), you may
> > not have problems.  Therefore, it may be a little difficult to
> > establish a reproducible recipe.
> > 
> > Just to add, import management works without inferior python.
> 
> So, my expectation is that Keglo will do the research I previously
> mailed:
> 
> > While Emacs is not responding, run "top" to see if there is a process
> > with high CPU utilization.  It is likely Python or Emacs is using CPU.
> > If the CPU utilization of Python is high, please tell us the arguments
> > of the Python process.  If the CPU utilization of Emacs is high,
> > please check if you can abort with Ctrl-G or sending SIGUSR2 signal.
> > If you can abort, please send the backtrace:
> > 
> > 1. emacs -Q
> > 2. M-x load-fie
> >    Specify the location of python.el (or python.el.gz, not
> >    python.elc).  You can use M-x locate-library and enter "python" to
> >    locate the file.
> > 3. M-x toggle-debug-on-quit
> > 4. Reproduce the issue.
> > 5. Abort with Ctrl-G or SIGUSR2.
> 
> Other useful information includes:
> 
> - Whether you are working on "project"
> - Whether or not the "freeze" last for a few minutes or so
> 

Message #29 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephanekeglo <at> gmail.com
Cc: kobarity <at> gmail.com, 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sat, 01 Feb 2025 13:54:25 +0200

Ping! Ping!  Keglo, are you there?

> Cc: 74894 <at> debbugs.gnu.org
> Date: Sat, 18 Jan 2025 11:23:16 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Ping!  Keglo, could you please respond?
> 
> > Date: Sat, 04 Jan 2025 23:17:29 +0900
> > From: kobarity <kobarity <at> gmail.com>
> > Cc: 74894 <at> debbugs.gnu.org
> > 
> > Eli Zaretskii wrote:
> > > 
> > > [Please use Reply All, to have everyone CC'ed.]
> > > 
> > > > Date: Sun, 22 Dec 2024 14:35:51 +0000
> > > > From: Keglo Stephane <stephanekeglo <at> gmail.com>
> > > > 
> > > > This is a simple recipe to reproduce the bug:
> > > > 1- open an empty python buffer
> > > > 2- start an inferior python shell C-c C-p
> > > > 3- Enter the following code:  print(string.digits) 
> > > > 4- Evaluation of this code should throw an exception since the string module is not imported
> > > > 5- Trying to use python-add-import ( C-c TAB a) or python-fix-imports ( C-c TAB fix) to add the missing
> > > > import, Emacs freeze a moment.
> > > > you have to press Ctrl-G to make Emacs respond again.
> > > 
> > > kobarity, any suggestions?
> > 
> > Sorry, I did not realize that email was a DM.  Here is my reply:
> > 
> > > Thank you, but I cannot reproduce the problem.
> > > 
> > > Import management depends on the contents of the directory (or more
> > > precisely, the project).  If you try the above procedure with an empty
> > > directory (outside of a project, such as a Git repository), you may
> > > not have problems.  Therefore, it may be a little difficult to
> > > establish a reproducible recipe.
> > > 
> > > Just to add, import management works without inferior python.
> > 
> > So, my expectation is that Keglo will do the research I previously
> > mailed:
> > 
> > > While Emacs is not responding, run "top" to see if there is a process
> > > with high CPU utilization.  It is likely Python or Emacs is using CPU.
> > > If the CPU utilization of Python is high, please tell us the arguments
> > > of the Python process.  If the CPU utilization of Emacs is high,
> > > please check if you can abort with Ctrl-G or sending SIGUSR2 signal.
> > > If you can abort, please send the backtrace:
> > > 
> > > 1. emacs -Q
> > > 2. M-x load-fie
> > >    Specify the location of python.el (or python.el.gz, not
> > >    python.elc).  You can use M-x locate-library and enter "python" to
> > >    locate the file.
> > > 3. M-x toggle-debug-on-quit
> > > 4. Reproduce the issue.
> > > 5. Abort with Ctrl-G or SIGUSR2.
> > 
> > Other useful information includes:
> > 
> > - Whether you are working on "project"
> > - Whether or not the "freeze" last for a few minutes or so
> > 
> 
> 
> 
> 

Message #32 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Keglo  Stephane <stephanekeglo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: kobarity <at> gmail.com, 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4; Emacs not responding when calling
 python-fix-imports
Date: Thu, 13 Feb 2025 20:08:37 +0000

[Message part 1 (text/plain, inline)]

Sorry Sir for not responding. I'm not working on a file inside a 
project. I'm just editing a file. I try to reproduce,  it still the 
same. when calling python-add-imports or python-fix-imports, i am 
seeing a circle loading for a long time. i have to press control-g to 
stop it.

On Sat, Feb 1 2025 at 01:54:25 PM +02:00:00, Eli Zaretskii 
<eliz <at> gnu.org> wrote:
> Ping! Ping!  Keglo, are you there?
> 
>>  Cc: 74894 <at> debbugs.gnu.org <mailto:74894 <at> debbugs.gnu.org>
>>  Date: Sat, 18 Jan 2025 11:23:16 +0200
>>  From: Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>>
>> 
>>  Ping!  Keglo, could you please respond?
>> 
>>  > Date: Sat, 04 Jan 2025 23:17:29 +0900
>>  > From: kobarity <kobarity <at> gmail.com <mailto:kobarity <at> gmail.com>>
>>  > Cc: 74894 <at> debbugs.gnu.org <mailto:74894 <at> debbugs.gnu.org>
>>  >
>>  > Eli Zaretskii wrote:
>>  > >
>>  > > [Please use Reply All, to have everyone CC'ed.]
>>  > >
>>  > > > Date: Sun, 22 Dec 2024 14:35:51 +0000
>>  > > > From: Keglo Stephane <stephanekeglo <at> gmail.com 
>> <mailto:stephanekeglo <at> gmail.com>>
>>  > > >
>>  > > > This is a simple recipe to reproduce the bug:
>>  > > > 1- open an empty python buffer
>>  > > > 2- start an inferior python shell C-c C-p
>>  > > > 3- Enter the following code:  print(string.digits)
>>  > > > 4- Evaluation of this code should throw an exception since 
>> the string module is not imported
>>  > > > 5- Trying to use python-add-import ( C-c TAB a) or 
>> python-fix-imports ( C-c TAB fix) to add the missing
>>  > > > import, Emacs freeze a moment.
>>  > > > you have to press Ctrl-G to make Emacs respond again.
>>  > >
>>  > > kobarity, any suggestions?
>>  >
>>  > Sorry, I did not realize that email was a DM.  Here is my reply:
>>  >
>>  > > Thank you, but I cannot reproduce the problem.
>>  > >
>>  > > Import management depends on the contents of the directory (or 
>> more
>>  > > precisely, the project).  If you try the above procedure with 
>> an empty
>>  > > directory (outside of a project, such as a Git repository), you 
>> may
>>  > > not have problems.  Therefore, it may be a little difficult to
>>  > > establish a reproducible recipe.
>>  > >
>>  > > Just to add, import management works without inferior python.
>>  >
>>  > So, my expectation is that Keglo will do the research I previously
>>  > mailed:
>>  >
>>  > > While Emacs is not responding, run "top" to see if there is a 
>> process
>>  > > with high CPU utilization.  It is likely Python or Emacs is 
>> using CPU.
>>  > > If the CPU utilization of Python is high, please tell us the 
>> arguments
>>  > > of the Python process.  If the CPU utilization of Emacs is high,
>>  > > please check if you can abort with Ctrl-G or sending SIGUSR2 
>> signal.
>>  > > If you can abort, please send the backtrace:
>>  > >
>>  > > 1. emacs -Q
>>  > > 2. M-x load-fie
>>  > >    Specify the location of python.el (or python.el.gz, not
>>  > >    python.elc).  You can use M-x locate-library and enter 
>> "python" to
>>  > >    locate the file.
>>  > > 3. M-x toggle-debug-on-quit
>>  > > 4. Reproduce the issue.
>>  > > 5. Abort with Ctrl-G or SIGUSR2.
>>  >
>>  > Other useful information includes:
>>  >
>>  > - Whether you are working on "project"
>>  > - Whether or not the "freeze" last for a few minutes or so
>>  >
>> 
>> 
>> 
>> 

[Message part 2 (text/html, inline)]

Message #35 received at 74894 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sat, 15 Feb 2025 22:47:06 +0900

Keglo Stephane wrote:
> Sorry Sir for not responding. I'm not working on a file inside a project. I'm just editing a file. I try to reproduce, 
> it still the same. when calling python-add-imports or python-fix-imports, i am seeing a circle loading for a long time. i
> have to press control-g to stop it.

Could you try the following steps I mentioned in my previous email?

> 1. emacs -Q
> 2. M-x load-fie
>    Specify the location of python.el (or python.el.gz, not
>    python.elc).  You can use M-x locate-library and enter "python" to
>    locate the file.
> 3. M-x toggle-debug-on-quit
> 4. Reproduce the issue.
> 5. Abort with Ctrl-G or SIGUSR2.

Message #38 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: stephanekeglo <at> gmail.com, kobarity <kobarity <at> gmail.com>
Cc: 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sat, 01 Mar 2025 14:10:09 +0200

Ping!  Keglo, could you please answer the question below?

> Date: Sat, 15 Feb 2025 22:47:06 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> 	74894 <at> debbugs.gnu.org
> 
> Keglo Stephane wrote:
> > Sorry Sir for not responding. I'm not working on a file inside a project. I'm just editing a file. I try to reproduce, 
> > it still the same. when calling python-add-imports or python-fix-imports, i am seeing a circle loading for a long time. i
> > have to press control-g to stop it.
> 
> Could you try the following steps I mentioned in my previous email?
> 
> > 1. emacs -Q
> > 2. M-x load-fie
> >    Specify the location of python.el (or python.el.gz, not
> >    python.elc).  You can use M-x locate-library and enter "python" to
> >    locate the file.
> > 3. M-x toggle-debug-on-quit
> > 4. Reproduce the issue.
> > 5. Abort with Ctrl-G or SIGUSR2.
> 

Message #41 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Keglo  Stephane <stephanekeglo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: kobarity <kobarity <at> gmail.com>, 74894 <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4; Emacs not responding when calling
 python-fix-imports
Date: Sat, 01 Mar 2025 17:40:29 +0000

[Message part 1 (text/plain, inline)]

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/")
 (save-current-buffer (set-buffer buffer) (apply #'call-process 
python-interpreter nil (list temp nil) nil "-c" python--list-imports 
(or name "") (mapcar #'file-local-name source)))
 (if (bufferp source) (save-current-buffer (set-buffer source) 
(call-process-region (point-min) (point-max) python-interpreter nil 
(list temp nil) nil "-c" python--list-imports (or name ""))) 
(save-current-buffer (set-buffer buffer) (apply #'call-process 
python-interpreter nil (list temp nil) nil "-c" python--list-imports 
(or name "") (mapcar #'file-local-name source))))
 (let* ((temp (current-buffer)) (status (if (bufferp source) 
(save-current-buffer (set-buffer source) (call-process-region 
(point-min) (point-max) python-interpreter nil (list temp nil) nil "-c" 
python--list-imports (or name ""))) (save-current-buffer (set-buffer 
buffer) (apply #'call-process python-interpreter nil (list temp nil) 
nil "-c" python--list-imports (or name "") (mapcar #'file-local-name 
source))))) lines) (if (eq 0 status) nil (error "%s exited with status 
%s (maybe isort is missing?)" python-interpreter status)) (goto-char 
(point-min)) (while (not (eobp)) (setq lines (cons 
(buffer-substring-no-properties (point) (pos-eol)) lines)) 
(forward-line 1)) (nreverse lines))
 (progn (let* ((temp (current-buffer)) (status (if (bufferp source) 
(save-current-buffer (set-buffer source) (call-process-region 
(point-min) (point-max) python-interpreter nil (list temp nil) nil "-c" 
python--list-imports (or name ""))) (save-current-buffer (set-buffer 
buffer) (apply #'call-process python-interpreter nil (list temp nil) 
nil "-c" python--list-imports (or name "") (mapcar ... source))))) 
lines) (if (eq 0 status) nil (error "%s exited with status %s (maybe 
isort is missing?)" python-interpreter status)) (goto-char (point-min)) 
(while (not (eobp)) (setq lines (cons (buffer-substring-no-properties 
(point) (pos-eol)) lines)) (forward-line 1)) (nreverse lines)))
 (unwind-protect (progn (let* ((temp (current-buffer)) (status (if 
(bufferp source) (save-current-buffer (set-buffer source) 
(call-process-region ... ... python-interpreter nil ... nil "-c" 
python--list-imports ...)) (save-current-buffer (set-buffer buffer) 
(apply ... python-interpreter nil ... nil "-c" python--list-imports ... 
...)))) lines) (if (eq 0 status) nil (error "%s exited with status %s 
(maybe isort is missing?)" python-interpreter status)) (goto-char 
(point-min)) (while (not (eobp)) (setq lines (cons 
(buffer-substring-no-properties (point) (pos-eol)) lines)) 
(forward-line 1)) (nreverse lines))) (and (buffer-name temp-buffer) 
(kill-buffer temp-buffer)))
 (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn 
(let* ((temp (current-buffer)) (status (if (bufferp source) 
(save-current-buffer ... ...) (save-current-buffer ... ...))) lines) 
(if (eq 0 status) nil (error "%s exited with status %s (maybe isort is 
missing?)" python-interpreter status)) (goto-char (point-min)) (while 
(not (eobp)) (setq lines (cons (buffer-substring-no-properties ... ...) 
lines)) (forward-line 1)) (nreverse lines))) (and (buffer-name 
temp-buffer) (kill-buffer temp-buffer))))
 (let ((temp-buffer (generate-new-buffer " *temp*" t))) 
(save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn 
(let* ((temp (current-buffer)) (status (if ... ... ...)) lines) (if (eq 
0 status) nil (error "%s exited with status %s (maybe isort is 
missing?)" python-interpreter status)) (goto-char (point-min)) (while 
(not (eobp)) (setq lines (cons ... lines)) (forward-line 1)) (nreverse 
lines))) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))))
 (let ((buffer (current-buffer))) (let ((temp-buffer 
(generate-new-buffer " *temp*" t))) (save-current-buffer (set-buffer 
temp-buffer) (unwind-protect (progn (let* ((temp ...) (status ...) 
lines) (if (eq 0 status) nil (error "%s exited with status %s (maybe 
isort is missing?)" python-interpreter status)) (goto-char (point-min)) 
(while (not ...) (setq lines ...) (forward-line 1)) (nreverse lines))) 
(and (buffer-name temp-buffer) (kill-buffer temp-buffer))))))
 python--list-imports(nil ("/home/stephanek/"))
 (let* ((cands (python--list-imports name source)) 
(minibuffer-default-add-function #'(lambda nil (setq minibuffer-default 
(let (...) (if window ...))))) (statement (cond ((and name (length= 
cands 1)) (car cands)) (prompt (completing-read prompt (or cands 
python-import-history) nil nil nil 'python-import-history))))) (if 
(string-empty-p statement) nil statement))
 python--query-import(nil ("/home/stephanek/") "Add import: ")
 (and t (python--query-import name (python--import-sources) "Add 
import: "))
 (let* ((statement (and t (python--query-import name 
(python--import-sources) "Add import: ")))) (if statement (if 
(python--do-isort "--add" statement) (message "Added `%s'" statement) 
(message "(No changes in Python imports needed)")) nil))
 python-add-import(nil)
 funcall-interactively(python-add-import nil)
 command-execute(python-add-import)



On Sat, Mar 1 2025 at 02:10:09 PM +02:00:00, Eli Zaretskii 
<eliz <at> gnu.org> wrote:
> Ping!  Keglo, could you please answer the question below?
> 
>>  Date: Sat, 15 Feb 2025 22:47:06 +0900
>>  From: kobarity <kobarity <at> gmail.com <mailto:kobarity <at> gmail.com>>
>>  Cc: Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>>,
>>  	74894 <at> debbugs.gnu.org <mailto:74894 <at> debbugs.gnu.org>
>> 
>>  Keglo Stephane wrote:
>>  > Sorry Sir for not responding. I'm not working on a file inside a 
>> project. I'm just editing a file. I try to reproduce,
>>  > it still the same. when calling python-add-imports or 
>> python-fix-imports, i am seeing a circle loading for a long time. i
>>  > have to press control-g to stop it.
>> 
>>  Could you try the following steps I mentioned in my previous email?
>> 
>>  > 1. emacs -Q
>>  > 2. M-x load-fie
>>  >    Specify the location of python.el (or python.el.gz, not
>>  >    python.elc).  You can use M-x locate-library and enter 
>> "python" to
>>  >    locate the file.
>>  > 3. M-x toggle-debug-on-quit
>>  > 4. Reproduce the issue.
>>  > 5. Abort with Ctrl-G or SIGUSR2.
>> 

[Message part 2 (text/html, inline)]

Message #44 received at 74894 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #47 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>
Cc: 74894 <at> debbugs.gnu.org, stephanekeglo <at> gmail.com
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sun, 02 Mar 2025 09:15:49 +0200

> Date: Sun, 02 Mar 2025 16:04:17 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> 	74894 <at> debbugs.gnu.org
> 
> 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.

Maybe we should document this limitation somewhere?

Message #50 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74894 <at> debbugs.gnu.org, stephanekeglo <at> gmail.com
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Sun, 02 Mar 2025 17:44:44 +0900

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> 
> > Date: Sun, 02 Mar 2025 16:04:17 +0900
> > From: kobarity <kobarity <at> gmail.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > 	74894 <at> debbugs.gnu.org
> > 
> > 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.
> 
> Maybe we should document this limitation somewhere?

I agree.  How about the attached patch?

[0001-Improve-docstrings-of-python.el-import-management.patch (application/octet-stream, attachment)]

Message #53 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>
Cc: 74894 <at> debbugs.gnu.org, stephanekeglo <at> gmail.com
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Thu, 06 Mar 2025 15:54:04 +0200

> Date: Sun, 02 Mar 2025 17:44:44 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: stephanekeglo <at> gmail.com,
> 	74894 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > 
> > > Date: Sun, 02 Mar 2025 16:04:17 +0900
> > > From: kobarity <kobarity <at> gmail.com>
> > > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > > 	74894 <at> debbugs.gnu.org
> > > 
> > > 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.
> > 
> > Maybe we should document this limitation somewhere?
> 
> I agree.  How about the attached patch?

LGTM, thanks.  Should I install it?

Message #56 received at 74894 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74894 <at> debbugs.gnu.org, stephanekeglo <at> gmail.com
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Fri, 07 Mar 2025 23:37:39 +0900

Eli Zaretskii wrote:
> 
> > Date: Sun, 02 Mar 2025 17:44:44 +0900
> > From: kobarity <kobarity <at> gmail.com>
> > Cc: stephanekeglo <at> gmail.com,
> > 	74894 <at> debbugs.gnu.org
> > 
> > Eli Zaretskii wrote:
> > > 
> > > > Date: Sun, 02 Mar 2025 16:04:17 +0900
> > > > From: kobarity <kobarity <at> gmail.com>
> > > > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > > > 	74894 <at> debbugs.gnu.org
> > > > 
> > > > 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.
> > > 
> > > Maybe we should document this limitation somewhere?
> > 
> > I agree.  How about the attached patch?
> 
> LGTM, thanks.  Should I install it?

Yes, please, if it looks good.

Message #61 received at 74894-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>
Cc: stephanekeglo <at> gmail.com, 74894-done <at> debbugs.gnu.org
Subject: Re: bug#74894: 29.4;
 Emacs not responding when calling python-fix-imports
Date: Fri, 07 Mar 2025 16:53:33 +0200

> Date: Fri, 07 Mar 2025 23:37:39 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: stephanekeglo <at> gmail.com,
> 	74894 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > 
> > > Date: Sun, 02 Mar 2025 17:44:44 +0900
> > > From: kobarity <kobarity <at> gmail.com>
> > > Cc: stephanekeglo <at> gmail.com,
> > > 	74894 <at> debbugs.gnu.org
> > > 
> > > Eli Zaretskii wrote:
> > > > 
> > > > > Date: Sun, 02 Mar 2025 16:04:17 +0900
> > > > > From: kobarity <kobarity <at> gmail.com>
> > > > > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > > > > 	74894 <at> debbugs.gnu.org
> > > > > 
> > > > > 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.
> > > > 
> > > > Maybe we should document this limitation somewhere?
> > > 
> > > I agree.  How about the attached patch?
> > 
> > LGTM, thanks.  Should I install it?
> 
> Yes, please, if it looks good.

Thanks, installed on the emacs-30 branch, and closing the bug.

Previous Next

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