-
Notifications
You must be signed in to change notification settings - Fork 2.8k
ZEPPELIN-277 Add Tab as Autocomplete for Notebook non-md paragraphs #2542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| // If user has pressed tab on first line char or if editor mode is %md, keep existing behavior | ||
| // If user has pressed tab anywhere in between and editor mode is not %md, show autocomplete | ||
| if (iColumnPosition && $scope.paragraph.config.editorMode !== 'ace/mode/markdown') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think python interpreter should use the existing auto completion key as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @malayhm for the improvement.
Like @1ambda mentioned, each different interpreter (language) may use auto-completion key (tab) differently.
Could you take a look comment https://issues.apache.org/jira/browse/ZEPPELIN-2736?focusedCommentId=16077868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16077868?
Editor configurations, such as 'language', 'editOnDblClick' are already defined in each interpreter-setting.json file and transfered to front-end.
I think we can add 'completionKey' in 'editor' under interpreter-setting.json and make conditionally apply autocompletion key based on this property.
@malayhm what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Leemoonsoo Yes, it would be better to give the user an option to select what should be the shortcut for code completion. But I fear that user may not go to each interpreter and change the shortcut. We can go with Tab as default shortcut and the user can choose if they want any different shortcut.
What do you think about having separate default shortcuts for a different interpreter or same for all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Interpreter setting" in zeppelin is a bit confusing because we use this words in two different places. One place is in 'Interpreter' menu, we can create interpreter settings and configure them. Another place is "Interpreter-setting.json" in each interpreter's source tree, which has default values for property and some immutable configurations.
What I meant was the immutable configuration in the second one.
For example markdown interpreter has immutable 'editor' configuration, like
"editor": {
"language": "markdown",
"editOnDblClick": true
And editor property can be accessed from the front end, like here or here.
So, we can make Tab or any other key as a default key for completion, but developers of each interpreter should able to override best completion key for each interpreter in the source code of interpreter.
I haven't thought deeply about each user override shortcut of completion key. But once Zeppelin allow user customizing shortcut, I think it will be not only completion key, but all other shortcut keys.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Leemoonsoo IMHO, we should not make autocomplete configurable through immutable editor configuration for following reasons:
-
A notebook can have mixed paragraph types and hence mixed interpreter which will have different autocomplete and will make a user think everytime they want to use autocomplete. This will result into bad UX.
-
In case where interpreters are shared, change to interpreter autocomplete setting will make it spread across the notebook and impact the behavior of other users
-
Talking from the code perspective, it will become tricky to change the shortcut at the runtime for existing paragraphs of opened notebooks if settings are changed elsewhere
For simplicity, the following should be the behavior:
- One shortcut for autocomplete for all the paragraphs within a notebook irrespective of interpreter type
- We can disable autocomplete for %md paragraph as it doesn't make sense to show autocomplete
In this way, the user will have clarity on what is the shortcut without putting any thoughts to it and it will be easy to communicate and document as well. This is the behavior in all the IDEs as well, e.g.:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zjffdu I think we will make tab as default autocomplete but at the same time we have to disable autocomplete for a few interpreters, e.g. md.
@Leemoonsoo has asked if we have to add more interpreters to the exclusion list in this PR apart from md.
@Leemoonsoo I can't think of any other exclusion as of now. It doesn't mean we should not add more inclusion in future. Today we don't have any exclusion for Ctrl+. autocomplete, hence it should be fine moving with the current work done in the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make tab as a default completion key, I wish we address following two
-
Improve tab completion behavior
This code brings completion list anytime user press tab if cursor is not the 0 column in the line. But i think we need little bit of improvement here. For example Jupyter does not brings completion unless there's any char before cursor on tab key press.
%sh if [ 1 == 1 ]; then echo "HEY" if [ 2 == 2]; then echo "TAB" fi fiyou'll realize it's not easy to write
echo "TAB".
I can find many similar other cases with SQL, and other languages. -
Move completion key selection from front-end to interpreter implementation
We can't really assume that every interpreter is okay with tab key completion.
And Zeppelin Interpreter is pluggable module. There're community managed interpreters as well as 3rd party interpreters. And asking front-end code change to configure pluggable module is not really a good idea I think.
We really need make interpreter contain completion key configuration, not hardcode completion key in the front-end side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Leemoonsoo I agree with point 1, I will make the changes in this PR.
Regarding point 2, can we take it up as a separate item with some feedback from the users so that we can make customer centric decision?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay,
Then, do you mind If I create a pullrequest to your branch for point 2? I really think it's benefit to developers who develop new interpreter choose completion key without touching front-end code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Leemoonsoo Sure.
|
@Leemoonsoo Added the improvement as per point 1 mentioned above. It will keep adding tab if all the previous characters are a tab in the same line. |
|
ping @malayhm @Leemoonsoo Any update ? |
|
@Leemoonsoo I think the PR branch to this PR has an open discussion and it may break few things. Can we merge this branch to master and take it separately whenever time permits? cc: @zjffdu |
|
@malayhm Let me try summarize in this way a. Merge this PR -> Tab completion works but target interpreter to apply tab completion is hardcoded in the front-end. a) brings something on development of interpreter (i.e. we should document where interpreter developer can find and change completion key from the front-end code). If we agree that c) is something we want to deliver to our users, which part do you want to cover in this PR @malayhm ? And according to comment from @zjffdu
issue ZEPPELIN-2907 is already solved? |
@Leemoonsoo ZEPPELIN-2907 is not resolved, but the issue you concerned above is fixed. As in the interpreter component refactoring, I would always overwrite editor by using the editor info from InterpreterSettingTemplate (interpreter-setting.json) (https://github.com/apache/zeppelin/blob/master/zeppelin-zengine/src/main/java/org/apache/zeppelin/interpreter/InterpreterSettingManager.java#L199). And I believe the editor info is immutable, so it should be safe to overwrite it. That means we could always add new field in editor of interpreter-setting.json |
|
ping @malayhm @Leemoonsoo |
|
I'm testing this branch + malayhm#1 + master. Let me comment after the test. |
|
I tested this branch + malayhm#1 + master. Like @zjffdu mentioned master branch doesn't have interpreter setting problem, so it works well without ZEPPELIN-2907. @malayhm if you review and merge malayhm#1, i think we can merge this pull request. |
|
ping @malayhm |
Let each individual interpreter configure completionKey
|
@Leemoonsoo @zjffdu I have merged the sub level pull request to this PR. |
…LIN-277 # Conflicts: # zeppelin-web/src/app/notebook/paragraph/paragraph.controller.js
|
@Leemoonsoo : I have changed
|
|
Looks great! |
|
ping @malayhm |
|
@Leemoonsoo @zjffdu I tried merging the latest master with a rerun of the CI job. Unfortunately, it didn't help. Could you suggest the next step? |
|
@malayhm Could you try to rerun these failed CI build ? https://travis-ci.org/malayhm/zeppelin/builds/288324042 |
|
@zjffdu I have restarted |
|
Could you try and resolve error? |
|
@Leemoonsoo Fixed the lint error. |
|
Thanks @malayhm ! LGTM and merge to master if no further comment! |
|
@Leemoonsoo one question, why did we not add R to have auto complete on tab? |
|
Probably i missed. Do you mind add a commit in this branch to enable tab completion on R? |
|
@Leemoonsoo I have added the setting for r and python sql as well. |
|
Thanks @malayhm. Looks good and i'm merging into master. |
|
Sure @Leemoonsoo |
What is this PR for?
This PR will add tab as auto complete invoker if paragraph is non-md and user has not pressed the tab as a first character in the line
What type of PR is it?
[Improvement]
What is the Jira issue?
How should this be tested?
Questions: