Partial fix for CLJ-198 - Auto-import in the REPL inserts broken code

[cjkent]

I'm not sure if this is the right approach but it fixes the problem in the REPL and doesn't seem to break auto-imports in regular files. There are some problems or things I'm unsure about:

• The import is on the same line as the typed text which is annoying. I tried to add a newline after the import but kept breaking the document. The existing code inserts a namespace declaration without a newline and I assume the newlines are inserted by the code formatter. Which doesn't do anything to a call to the import macro which my code generates.
• Is is reasonable and reliable to use PsiFile.getViewProvider().isPhysical() to decide whether we're in the REPL?
• Is there an easy way to find out the current namespace in the REPL? If there is then it might be better to use the existing code that generates a namespace declaration. The only way I can think of is to execute (.name ns) in the REPL and get the result without outputting anything to the console but that doesn't look like it would be simple.

[donnerpeter]

isPhysical is certainly not the right method to determine if it's REPL. There might be quite many non-physical files created for different purposes. I'd suggest to create a special user data Key and put it either to the Document created for REPL, and then check if it's present. Maybe wrap with some more beautifully-looking static isReplFile() method.

What do you mean by "kept breaking the document"?

And what do you mean by the current namespace in REPL? Do you mean the one defined in previous evaluations? Then maybe it's easier to just track it on the side of the REPL, analysing the PSI as soon as it's being sent to the evaluation and remembering it somewhere.

[Alefas]

I left the link in CLJ-198 issue to this pull request, so when we will start to fix this issue, we will take a look here. Or you have fix it earlier by another pull request (we can't merge this pull request, because it's not complete yet).