Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Custom Types/Globals in CodeEditWidget

Hi,

I just wrote a simple test Tern plugin replicating my use case (see below). 

1) If I hack this into the dependency list of ternDefaults in the built ternWorkerCore file and add the plugin name to the required plugins, my types are loaded and if I specify /* eslint-env mytypes */ in the editor I can see the code completion for them. 

2) If I hack  „mytypes: true“ into the list of standard environments in TernAssist.computeContentAssist in the built _javascript_Plugin file, I can omit the eslint-env directive and use code completion for my types right away.

Using this approach I can completely get rid of the extension of the builtin object in eslint/conf/environments, which is nice. Can I somehow achieve 2) from outside the built files?

@Libing: I know the user plugins and already make use of them for other use cases. But they don’t help me in injecting a custom Tern definition file and enable code completion. For that I just want to use the existing framework.

Example Tern plugin:
define([
"tern/lib/tern",
], function(tern) {

    tern.registerPlugin("mytypes", function(server, options) {
server.addDefs(defs);
});

    var defs = {
        "!name": "mytypes",
        "Foo": {
            "!type": "fn()",
            "create": {
              "!type": "fn(name: string) -> +Foo",
              "!doc": "Returns a new Foo object."
            },
            "prototype": {
                "name": {
                  "!type": "string",
                  "!doc": "The name of the Foo."
                }
            }
        }
    };
});

Regards,
Sebastian


Am 04.05.2016 um 19:50 schrieb Libing Wang <Libing_Wang@xxxxxxxxxx>:

Just a reminder that you can pass any user plugins if you are not aware of that...
https://wiki.eclipse.org/Orion/How_Tos/Code_Edit#Passing_user_plugins

-Libing



From:        Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        05/04/2016 12:46 PM
Subject:        Re: [orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        orion-dev-bounces@xxxxxxxxxxx




It’s OK :)
I will look into writing a Tern plugin and see if that at least helps in reducing the hacking and the update overhead.

Thanks and regards,
Sebastian


Am 04.05.2016 um 18:29 schrieb Curtis Windatt <Curtis_Windatt@xxxxxxxxxx>:

Right, this being in the code edit widget is going to be a problem.  Loading .definition folders, using .tern-project file, etc. are all based around having a project.  And CodeEditWidget doesn't have a project...

So assuming you are stuck hacking in definitions, I would still recommend adding them as a Tern plugin, then modifying TernDefaults to load that plugin.  However, I doubt you could do that in the built/minified code.  We don't have a workflow to load all of the plugins in a folder, we load each one in TernDefaults.


This is not very helpful for you :(


Curtis




From:        
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        
05/04/2016 11:04 AM
Subject:        
Re: [orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        
orion-dev-bounces@xxxxxxxxxxx




Hi,

currently it is rather a „hack in“ than a „hook in“ or plugin, since I have to patch the built ternWorkerCore and _javascript_Plugin files, because I know of no other way :)

1) Can I use that with the CodeEditWidget and if yes, where do I have to put the .definition folder?

2) I don’t really setup „custom completions“, I just add my (dynamic) Tern definition file into the built ternWorkerCore file (in the ternDefaults definition, like ecma5, ecma6, chai). So nothing too complicated.
Let’s say I succeed in adding my type definitions via 1) (see my example file from the last email), then I could activate the code completion for my types simply by adding /* eslint-env mydefinition */, right? So the only feature missing for my needs would be „Turning of filtering based on eslint-env“, as you said. Do I understand that correctly?

3) Again, I don’t setup a custom ESLint validation, I just patch the ESLint globals (see eslint/conf/environments) in the built ternWorkerCore file so that my custom types appear as builtin types, just as String or Date are. Otherwise a new MyType1() would give me red squiggles.

I hope that makes it clearer.

Regards
Sebastian


Am 04.05.2016 um 16:03 schrieb Curtis Windatt <
Curtis_Windatt@xxxxxxxxxx>:

Your plugin adds 1) Type definitions for Tern  2) Custom completions and 3) ESLint validation?  

1) We have limited support already for adding type definitions.  See Bug 484833
https://bugs.eclipse.org/bugs/show_bug.cgi?id=484833

2) Custom completions would require a new Tern plugin that contributes on the 'completions' request.  We would like to support third party Tern plugins, though at the moment we are focused on fetching type definitions for your code (creating or finding an index for some node module you are using).  I was pretty sure we had a bug for this, but I don't see one, so feel free to create one.  Turning off the filtering based on eslint-env will be one step towards this.  The only thing holding us back from that change is that projects without a .tern-project entry would get all of our templates showing up in content assist all the time.

3) We haven't set up a way to contribute to our ESLint setup so I would be interested in how you are hooking in.  Adding new rules shouldn't be difficult but when setting up the configuration for ESLint we are doing lookups in Orion's preference service as well as looking at eslintrc files.

Curtis




From:        
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>
To:        
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:        
05/04/2016 02:55 AM
Subject:        
[orion-dev] Custom Types/Globals in CodeEditWidget
Sent by:        
orion-dev-bounces@xxxxxxxxxxx




Hi,

to use the CodeEditWidget and its completion/validation features with my own custom types, I currently have to do the following steps (which currently work fine for me):

1. In ternWorkerCore.js search for the ternDefaults definition and add a link to my
ASP.NETHTTP request handler (e.g. TypeHandler.ashx?return=types) to the dependencies list => this loads the code completion definitions for Tern

2. In ternWorkerCore.js search for eslint/conf/environments and add a link to my request handler (e.g. TypeHandler.ashx?return=globals) which extends the builtin globals by my types => ESLint knows my types WITHOUT having to specify a eslint-env directive

3. In _javascript_Plugin.js search for ecma5 in the computeContentAssist function and add the name of my type definition file (e.g. mydefinition: true)

The mentioned request handler dynamically creates the Tern definitions / ESLint globals for the custom types (see below for example outputs), because they can possibly change due to a plugin concept. Therefore a static definition file is not sufficient.

But this procedure is tedious and error prone especially when I update the widget, since the mentioned files are minified by default(!). To figure out the steps above I actually created a custom build definition which omits the minification step.

With all the new possibilities due to .tern-project files, is there an easier way to accomplish this? Ideally I would like to write some kind of plugin file where I setup all I need and then just feed it to the CodeEditWidget by a function/during the create step. The important points for me are:
1. A dynamic HTTP request handler has to work, a static definition file is not sufficient
2. The types should behave like builtins without the need to specify a eslint-env directive in every script

TypeHandler.ashx?return=types returns a Tern definition file like this:
define([], function () {
              return {
                               "!name": "mydefinition",
                               
                               MyType1: {
                                                ...
                               }
              };
});

TypeHandler.ashx?return=globals returns ESLint globals like this (extending the predefined builtins!):
define(["eslint/conf/globals"], function (globals) {
              globals.builtin.MyType1 = false;
              ...
              return { builtin: globals.builtin };
});

Thanks and regards,
Sebastian

_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev




_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/orion-dev


_______________________________________________
orion-dev mailing list

orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev

_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev


Back to the top