Skip to content

Conversation

@malayhm
Copy link
Contributor

@malayhm malayhm commented Aug 16, 2017

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?

  • Build: mvn clean package -Denforcer.skip -DskipTests -Drat.skip
  • Open a paragraph
  • Press tab with following options: first character, after space

Questions:

  • Does the licenses files need an update? no
  • Is there breaking changes for older versions? no
  • Does this needs documentation? no


// 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') {
Copy link
Member

@1ambda 1ambda Aug 16, 2017

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.

Copy link
Member

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?

Copy link
Contributor Author

@malayhm malayhm Aug 16, 2017

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?

Copy link
Member

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.

Copy link
Contributor Author

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.:

Copy link
Contributor Author

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.

Copy link
Member

@Leemoonsoo Leemoonsoo Aug 23, 2017

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

  1. 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
    fi
    

    you'll realize it's not easy to write echo "TAB".
    I can find many similar other cases with SQL, and other languages.

  2. 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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Leemoonsoo Sure.

@malayhm
Copy link
Contributor Author

malayhm commented Sep 5, 2017

@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.

@Leemoonsoo
Copy link
Member

@malayhm just created a PR to this branch malayhm#1. Please take a look.

@zjffdu
Copy link
Contributor

zjffdu commented Sep 19, 2017

ping @malayhm @Leemoonsoo Any update ?

@malayhm
Copy link
Contributor Author

malayhm commented Sep 19, 2017

@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

@Leemoonsoo
Copy link
Member

@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.
b. Merge this PR + malayhm#1 -> Remove hardcoded part from front-end and let each interpreter choose completion key. But it does not applied to existing interpreter setting ZEPPELIN-2907.
c. Merge this PR + malayhm#1 + ZEPPELIN-2907 -> Everything is happy

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).
And b) brings something on using zeppelin (i.e. we should document the behavior that existing interpreter setting does not have tab completion key support).

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

@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

issue ZEPPELIN-2907 is already solved?

@zjffdu
Copy link
Contributor

zjffdu commented Sep 20, 2017

This makes interpreter impossible to add / update "editor" configuration without user recreate interpreterSetting

@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

@zjffdu
Copy link
Contributor

zjffdu commented Sep 28, 2017

ping @malayhm @Leemoonsoo

@Leemoonsoo
Copy link
Member

I'm testing this branch + malayhm#1 + master. Let me comment after the test.

@Leemoonsoo
Copy link
Member

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.

@zjffdu
Copy link
Contributor

zjffdu commented Oct 8, 2017

ping @malayhm

Let each individual interpreter configure completionKey
@malayhm
Copy link
Contributor Author

malayhm commented Oct 10, 2017

@Leemoonsoo @zjffdu I have merged the sub level pull request to this PR.
I have found an issue, will fix it in few minutes, we can merge to master post that.

@malayhm
Copy link
Contributor Author

malayhm commented Oct 10, 2017

@Leemoonsoo : I have changed

let isAllTabs = currentLine.split('').every(function(char) { return (char === '\t' || char === ' ') })
to
let isAllTabs = currentLine.substring(0, iCursor.column - 1).split('').every(function(char) { return (char === '\t' || char === ' ') })

@Leemoonsoo
Copy link
Member

Looks great!
There're 3 CI build job failure. https://travis-ci.org/malayhm/zeppelin/builds/286024284
Failures does not look like related to this PR change, but just in case, could you try merge current master (which fixes some CI issue) and see if it gives different result?

@zjffdu
Copy link
Contributor

zjffdu commented Oct 14, 2017

ping @malayhm

@malayhm
Copy link
Contributor Author

malayhm commented Oct 16, 2017

@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?

@zjffdu
Copy link
Contributor

zjffdu commented Oct 16, 2017

@malayhm Could you try to rerun these failed CI build ? https://travis-ci.org/malayhm/zeppelin/builds/288324042

@malayhm
Copy link
Contributor Author

malayhm commented Oct 16, 2017

@zjffdu I have restarted https://travis-ci.org/malayhm/zeppelin/builds/288324042, but it seems it didn't help.

@Leemoonsoo
Copy link
Member

Could you try

cd zeppelin-web
npm run lint:once

and resolve error?

@malayhm
Copy link
Contributor Author

malayhm commented Oct 16, 2017

@Leemoonsoo Fixed the lint error.

@Leemoonsoo
Copy link
Member

Thanks @malayhm !

LGTM and merge to master if no further comment!

@malayhm
Copy link
Contributor Author

malayhm commented Oct 17, 2017

@Leemoonsoo one question, why did we not add R to have auto complete on tab?

@Leemoonsoo
Copy link
Member

Probably i missed. Do you mind add a commit in this branch to enable tab completion on R?

@malayhm
Copy link
Contributor Author

malayhm commented Oct 18, 2017

@Leemoonsoo I have added the setting for r and python sql as well.

@Leemoonsoo
Copy link
Member

Thanks @malayhm. Looks good and i'm merging into master.

@malayhm
Copy link
Contributor Author

malayhm commented Oct 18, 2017

Sure @Leemoonsoo

@asfgit asfgit closed this in 84cb4b5 Oct 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants