Let each individual interpreter configure completionKey

[Leemoonsoo]

This patch makes each interpreter choose completion key.
Tab completion key is applied to %python, %spark, %spark.sql, %spark.pyspark, %spark.dep interpreters.

One limitation is, interpreter setting pre-exists this patch does not apply tab completion.
New interpreter setting after this patch will work with tab completion.
Reason is, Zeppelin write editor configuration under conf/interpreter.json on interpreterSetting creation and read it. So even if an interpreter is upgraded and includes new editor configuration, zeppelin still reads old information from conf/interpreter.json unless user recreates it.

This is I think wrong behavior need to be addressed in a separate issue.

Please @malayhm take a look this patch and merge if you're okay.

[malayhm]

@Leemoonsoo
Thanks for taking this up, change lgtm.

I have a couple of questions:

1. Is there a way to overcome the limitation of existing interpreters?
2. How to expose this configuration to the user so that they get to know which interpreter has tab as code completion. This can partially address point 1.

[Leemoonsoo]

Is there a way to overcome the limitation of existing interpreters?

I think editor configuration in resources/interpreter-setting.json under each interpreter doesn't have to be copied to conf/interpreter.json on interpreterSetting creation. Instead of reading copied information from conf/interpreter.json, reading information directly from resources/interpreter-setting.json would solve this problem.

How to expose this configuration to the user so that they get to know which interpreter has tab as code completion. This can partially address point 1.

I have no good idea on this. Candidates i can think are

1. Keyboard shotcut dialog
   

2. Interpreter menu
   

Do you have any other idea?

[malayhm]

I think editor configuration in resources/interpreter-setting.json under each interpreter doesn't have to be copied to conf/interpreter.json on interpreterSetting creation. Instead of reading copied information from conf/interpreter.json, reading information directly from resources/interpreter-setting.json would solve this problem.

I think we should add a case to handle non-existent property so that, it can take care of this change even if the interpreter is old.

What do you think?

Auto-completion key discovery

I like the idea to add it as part of keyboard shortcuts rather than showing it in the interpreter settings so that user can see all the shortcuts from a single page instead of going through each interpreter.
I think keyboard shortcuts are one way to expose this with the list of interpreters with tab and list of interpreters with Ctrl + ..
Along with this, we can also add the list of shortcuts as part of documentation the same way other IDEs show.

[Leemoonsoo]

I think we should add a case to handle non-existent property so that, it can take care of this change even if the interpreter is old.

AFAIK, there's no good reason this property should be copied to conf/interpreter.json from Interpreter. We can just read the property from interpreter always.

I filed an issue https://issues.apache.org/jira/browse/ZEPPELIN-2907

[zjffdu]

@Leemoonsoo I hit the interpreter.json upgrade issue when doing interpreter component refactoring, and I think I already fixed it. https://github.com/apache/zeppelin/blob/master/zeppelin-zengine/src/main/java/org/apache/zeppelin/interpreter/InterpreterSettingManager.java#L199

BTW, for the api stability/compatibility of zeppelin, there're 2 perspective IMO.

• One is the api (include the rest api and interpreter api).
• Another is the configuration file we expose to users implicitly. (interpreter.json, credentials.json, notebook-authorization.json and etc).

In the 0.8.0 (or at least before 1.0), I plan to make them stable