Skip to content

Latest commit

 

History

History
116 lines (96 loc) · 5.19 KB

features.org

File metadata and controls

116 lines (96 loc) · 5.19 KB

importmagic.el

This is an elisp package intended to use importmagic to autoimport missing symbols in Python without having to bother to go to the beginning of the file to manually add the imports. I’ve tried it with Elpy and it works ok.

This file is intended to help the developing process.

[5/7] Work process

  1. [X] Write the Python EPC Server:
    • [X] Write a function that returns unimported symbols
    • [X] Write a function that returns candidates for a single symbol
    • [X] Write a function that returns where to put the new import. Actually we may or may not need this function, it really depends on how Python imports should be put in a buffer
  2. [X] Write the actual importmagic.el file using EPC.
    • [X] Write a function that starts the RPC server on buffer initialization.
    • [X] Write a function that queries the server for the unresolved symbols to import and shows the candidates using completing-read or something along those lines.
    • [X] Write a function that actually inserts the suggested import in the buffer without saving it
    • [X] Write a function that queries for every unimported symbol (that has candidates, obviously).
  3. [X] Write a good README file.
  4. [X] Test it and bind it to a key.
  5. [ ] Use it for profit.
  6. [X] Use Cask. Make tests for the package and actually create a package
  7. [ ] Maybe submit it to MELPA.

Work for the Nov 28 - Dic 05 week

The hard work for this package is mostly written and it should be ready to submit to MELPA. However, I do not want to submit a package without bf real testing. By that I mean I should test my own package myself outside ERT and the Emacs Lisp environment. If everything goes well I should submit this package to MELPA and get it out.

There are a few issues concerning this project that need some attention:

  1. Get the copyright stuff into importmagic.el and possibly importmagicserver.py. That should set the package ready to submit it.
  2. Record a screencast with camcorder that should what this package can do. I feel like it’s very important to do that, because most packages don’t include a screenshot, and it really bothers me that you don’t know what they look like. It’s like they’re forcing you to install their packages.
  3. Get better key bindings, or even better, reuse some already bound key bindings to fix imports.

Those are quite easy to do, not much work there, but there are two issues that need further investigation:

  1. Use M-RET to fix errors: this issue has an entire subsection below. This requires Flycheck to be running.
  2. Test that locally defined symbols can actually be imported using importmagic. I do not know the scope of importmagic, but it looks like it follows some weird convention. It can however import classes from locally defined modules. This test can be done on a real world, but I haven’t really figured out how to do it from within ERT. I’ll have to look further into it.

Finding a good key to bind importmagic-fix-symbol-at-point

Until now we have the function stated above (importmagic-fix-symbol-at-point) which successfully modifies the buffer and inserts the selected import candidate into it. So, need a key to bind to this action.

I always liked IntelliJ’s M-RET to do this. However, it might be the case that the user -pretty much like me- has M-RET bound to something else, and it would be kind of a bummer to have to get rid of whatever that key binding does in order to just import symbols.

So I got an idea: we can make (and I actually did make it) importmagic-fix-symbol-at-point fail if there’s no candidates. I’ll explain why that is a desirable behavior after giving the general idea.

What we ultimately want to do is using M-RET non obstrusively, or, to put it in Emacs terms, we want to kind of make a dwim command: If there’s an error at point, then query for imports of symbol at point, if there’s no candidates or there’s no error at point regarding unknown symbols, then just do a normal M-RET. I don’t know how, but I’m pretty sure that that’s possible with Emacs. Anyway, here’s a little code snippet to detect where there are errors at point with Flycheck:

(eq (point) (flycheck-next-error-pos 1))

Specifically for Python, we should also check the kind of error. So we’ll need to read some documentation for that, and it, of course, depends on the linter.

After that, we could do something like this:

(condition-case nil
    (importmagic-fix-symbol-at-point)
  (error "Do normal M-RET key behavior"))

And then, of course, we could bind it to M-RET safely. Of course, the code snippet above doesn’t check for flycheck errors, but you get the idea. I’ll actually have to modify importmagic-fix-symbol-at-point. Cool challenge, huh?