Hi Libing,
the interface looks great and I just tried to use it to remove all the hacks I have done to the code edit widget. However, some things don’t seem to work yet, or I am still missing something:
1. I can set the ecma version to 5 in the .tern-project file (good) 2. I can load my custom tern plugin by means of the .tern-project file instead of adding it to the dependencies of ternDefaults.js (good) 3. I still need to include the name of my plugin in the required plugins section in ternDefaults.js (bad) 4. I cannot use the .eslintrc file to set the proper environment (bad)
Some details: 3. Assume you have the following tern plugin and referenced it in the .tern-project file.
define([ 'tern/lib/tern', ], function (tern) {
tern.registerPlugin('myPlugin', function (server, options) { server.addDefs(defs); });
var defs = { "!name": "myPlugin", "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." } } } }; });
To get the proposals I still need to add the following to the required plugins section in ternDefaults.js (aside from an /*eslint-env myPlugin*/ in the editor). "myPlugin": { "name": "MyPlugin", "description": "MyPlugin", "version": "1.0" }
4. In order to get rid of the eslint-env directive in the editor, I added the following to the .eslintrc file but I don’t get any proposals "env": { "myPlugin": true }
You can test this on your demo page by adding "env": { "browser": true } to the .eslintrc file. I would expect to get proposals when I type document. and open the content assist but there are none. What’s interesting is, that the error on document goes away as soon as you add those lines. Also the hover on document then shows the correct documentation.
Regards, Sebastian
P.S.: Orion 12 looks awesome! Great work!
Hi Sebastian:We just announced Orion 12.0[1] today
and the codeEdit widget[2] is there with your feature request for the tern
project and eslint rule. Please download the latest widget from http://www.eclipse.org/downloads/download.php?file=/orion/drops/R-12.0-201606220105/built-codeEdit.zip.For a quick reference, here is the demo
page: http://libingw.github.io/OrionCodeEditTern/.Regards,Libing[1] http://planetorion.org/news/2016/06/announcing-orion-12/[2] http://planetorion.org/news/2016/06/new-and-noteworthy-for-codeedit-widget-12/From:
Sebastian Pahnke <pahnke.sebastian@xxxxxxxxx>To:
Orion developer discussions
<orion-dev@xxxxxxxxxxx>Date:
05/12/2016 10:55 AMSubject:
Re: [orion-dev]
Custom Types/Globals in CodeEditWidgetSent by:
orion-dev-bounces@xxxxxxxxxxx Sounds great! Thanks!Am 11.05.2016 um 22:27 schrieb Libing Wang <Libing_Wang@xxxxxxxxxx>:RE: codeEdit.setFileContents('.eslintrc',
<content>) or codeEdit.setFileContents('.tern-project', <content>)
codeEdit already has the fileClient service so that you can use similar
APIs from it. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=493461and
working on it. Please see details in the bug for the idea. I will update
our wiki page for the instructions once the bug is fixed.
Libing
From: Curtis
Windatt/Ottawa/IBM@IBMCA To: Orion
developer discussions <orion-dev@xxxxxxxxxxx> Date: 05/10/2016
02:31 PM Subject: Re:
[orion-dev] Custom Types/Globals in CodeEditWidget Sent by: orion-dev-bounces@xxxxxxxxxxx
https://bugs.eclipse.org/bugs/show_bug.cgi?id=493379
From: Sebastian
Pahnke <pahnke.sebastian@xxxxxxxxx> To: Orion
developer discussions <orion-dev@xxxxxxxxxxx> Date: 05/10/2016
11:15 AM Subject: Re:
[orion-dev] Custom Types/Globals in CodeEditWidget Sent by: orion-dev-bounces@xxxxxxxxxxx
Hi,
what if I could tell the „in-memory“ file system the contents of such
a file instead of the location. For instance, when I create the code edit
widget on my page I would write:
codeEdit.setFileContents('.eslintrc', <content>) or codeEdit.setFileContents('.tern-project', <content>)
Then, whenever the file system is queried for such a file, it just returns
these contents, instead of resolving a physical file. Would that be a possible
solution? I don’t know the Orion architecture very well, so please tell
me if this is nonsense :) I at least think it would be a practical workaround
for the code edit widget, since you have to create an instance anyway before
you can use it.
Regards, Sebastian
Am 06.05.2016 um 16:49 schrieb Libing Wang <Libing_Wang@xxxxxxxxxx>:
Curtis: codeEdit consumes an "in-memory" file system that is barely a
place holder to workaround the Orion inputManager. This file system is
registered as the default file system, taking care of file read, write,
etc. I think the real challenge here is that, for example, the "in-memory"
file system has no idea on where the imported files are. So unless end
user implements a real file system and pass it as a user plugin, it is
hard to support this.
Libing
From: Curtis
Windatt/Ottawa/IBM To: Orion
developer discussions <orion-dev@xxxxxxxxxxx> Cc: Libing
Wang/Ottawa/IBM@IBMCA Date: 05/05/2016
03:10 PM Subject: Re:
[orion-dev] Custom Types/Globals in CodeEditWidget
Yes a .eslintrc file could be used to set the environment. We were
just demo'ing this feature this afternoon. The problem is the same
as the .definitions folder. codeEditWidget has no project, so the
tooling can't search for those files.
Libing, do you have any ideas on how we could workaround this?
Curtis
From: Sebastian
Pahnke <pahnke.sebastian@xxxxxxxxx> To: Orion
developer discussions <orion-dev@xxxxxxxxxxx> Date: 05/05/2016
01:00 PM Subject: Re:
[orion-dev] Custom Types/Globals in CodeEditWidget Sent by: orion-dev-bounces@xxxxxxxxxxx
Hi Curtis,
as I have seen you have integrated .eslintrc support for the Orion IDE.
I don’t know how hard it is, but if the codeEditWidget API could provide
a function to feed in an .eslintrc file, then I could just set the required
eslint-env directive once and accomplish 2) without hacking the built _javascript_Plugin
file. Just an idea :)
But as for now, the solution works fine and I thank you for your help.
Regards, Sebastian
Am 05.05.2016 um 15:26 schrieb Curtis Windatt <Curtis_Windatt@xxxxxxxxxx>:
That's great that you were able to inject a new tern plugin into the build
ternWorkerCore.
No there is no way to modify the default eslint environments. To
help users with this we have additional eslint rules that will mark the
code warning about no environment directive set. That rule has a
quick fix to set the missing eslint-env entry in your file. I'm not
sure how difficult hooking into these quick fixes would be (and whether
having to have an eslint-nev directive is reasonable to you). Maybe
in the future our ESLint implementation would look at everything Tern is
aware of and ignore the eslint-env, but that isn't our current focus.
Curtis
From: Sebastian
Pahnke <pahnke.sebastian@xxxxxxxxx> To: Orion
developer discussions <orion-dev@xxxxxxxxxxx> Date: 05/04/2016
02:28 PM Subject: Re:
[orion-dev] Custom Types/Globals in CodeEditWidget Sent by: orion-dev-bounces@xxxxxxxxxxx
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 _______________________________________________ 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
_______________________________________________ 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@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/orion-dev
|