pythonic-python-readable-file-name throws error

[j-christ]

I'm getting an error from pythonic which prevents me from opening new files in emacs:

  pythonic-python-readable-file-name: Wrong type argument: stringp, nil

This happens after I've installed flx-ido, and am using M-x f to attempt to open a file. With flx-ido, there's an "extra" key sequence you can use (Ctrl-f) to exit IDO and use basic file opening which does work with pythonic.

I believe the problem is that pythonic-python-readable-file-name is assuming that the filename argument passed to it is non-nil. This is not always going to be the case:

https://stackoverflow.com/a/5414033

I don't really understand elisp, but I have replaced pythonic-python-readable file name with

(defun pythonic-python-readable-file-name (filename)
  "Emacs to Python FILENAME conversion.
Take FILENAME from the perspective of the localhost and translate
it to the FILENAME Python process can read.  Python can be
running locally or remotely.  FILENAME can have local or tramp
format.  Result will have local format."
(if filename
  (let ((alias (pythonic-aliased-path (expand-file-name filename))))
   (if (tramp-tramp-file-p alias)
        (tramp-file-name-localname (tramp-dissect-file-name alias))
     alias))
  filename
  ))

And the problem goes away. In keeping with the "be liberal in what you accept" dictum, can you modify pythonic-python-readable-file-name to return filename if it is nil?

[dakra]

Hmm, pythonic-python-readable-file-name is actually never actively called when opening a buffer.
I checked anaconda in case you use it, but there is a guard installed for no filename buffers.

Can you send the complete backtrace from the debug error buffer?
Do you use any other package that uses pythonic? E.g. djangonaut?

[j-christ]

Here's the stack trace.

  expand-file-name(nil)
  pythonic-python-readable-file-name(nil)
  pythonic-activate(nil)
  pyenv-mode-set("system")
  #f(compiled-function (path) #<bytecode -0x1a8e1070f1388913>)("/Users/christop")
  f-traverse-upwards(#f(compiled-function (path) #<bytecode -0x1a8e1070f1388913>) "/Users/christop")
  f-traverse-upwards(#f(compiled-function (path) #<bytecode -0x1a8e1070f1388913>) "/Users/christop/.emacs.d")
  f-traverse-upwards(#f(compiled-function (path) #<bytecode -0x1a8e1070f1388913>) "/Users/christop/.emacs.d/elpa")
  f-traverse-upwards(#f(compiled-function (path) #<bytecode -0x1a8e1070f1388913>))
  pyenv-mode-auto-hook()
  run-hooks(find-file-hook)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer pythonic.el> #("~/.emacs.d/elpa/pythonic-20210122.1247/pythonic.el" 11 15 (face flx-highlight-face) 16 20 (face flx-highlight-face)) nil nil "~/.emacs.d/elpa/pythonic-20210122.1247/pythonic.el" (3768092 16777232))
  find-file-noselect(#("/Users/christop/.emacs.d/elpa/pythonic-20210122.12..." 25 29 (face flx-highlight-face) 30 34 (face flx-highlight-face)) nil nil)
  ido-file-internal(raise-frame)
  ido-find-file()
  funcall-interactively(ido-find-file)
  call-interactively(ido-find-file nil nil)
  command-execute(ido-find-file)

On further inspection, it seems the problem might be related to trying to deactivate a pyenv environment. I'm transitioning into a directory which has no python env set; thus the pythonic-activate(nil).

This might seem like a weird thing to do, but on my system there's no "default" python. It's a new system and I'm still setting it up, but I'm kind of liking the idea that invoking "python" in a directory without an explicit virtual environment set up results in "command not found". This will force me to use a virtual environment to run python!

However, when I navigate from a directory with a pyenv to one without (e.g. .emacs.d/elpa/pythonic), pyenv-mode-auto calls pyenv-mode-set("system") which calls pythonic-activate(nil), which is the source of the error. Perhaps pythonic-activate(nil) should just call pythonic-deactivate when passed a nil argument?

[dakra]

Is this the pyenv-mode-auto that causes the error. imho the check should happen there.

Calling pythonic-activate with nil and then deactivates is imho confusing, the caller should instead just call pythonic-deactivate.

[j-christ]

But no call to pythonic-activate should throw an error, and what are you supposed to do when passed a nil filename?

I agree this should also be fixed upstream, but in keeping with "be liberal in what you accept", I think it should be fixed here as well.