Code completion in JavaScript files
So far the code completion in JavaScript files is very limited - I only happen to complete the variable names which isn't that much, honestly ...
How about:
1) Completing user's method name + showing it's arguments (with Ctrl+P)
2) Completing W3C DOM method names + showing their arguments
There are still a hell lot of differences between Java-editor and JavaScript-editor expriences and I hoped IDEA 5 will solve most of them. It appears to be just starting ..
请先登录再写评论。
Not the best time to discuss, since we are in pre-release state, but
nevertheless I would be delighted to know your ideas on how this could be
implemented.
I mean how could we filter DOM elements to offer in typeless JavaScript?
Eugene.
"Evgeny Goldin" <no_mail@jetbrains.com> wrote in message
news:7612243.1122477437479.JavaMail.javamailuser@localhost...
>
>
Javascript is not typeless, it does not have static typing, but every
object has a type at runtime. I think in a typical JS application, most
types can be inferred from static analysis.
Evgeny, a request exists for inferring types in JS code, which would
help to solve your two issues. The issue is
http://jetbrains.net/jira/browse/IDEABKL-3405 - you can vote efor it.
Eugene Vigdorchik (JetBrains) wrote:
>>So far the code completion in JavaScript files is very limited - I only
>>happen to complete the variable names which isn't that much, honestly ...
>>
>>How about:
>>1) Completing user's method name + showing it's arguments (with Ctrl+P)
>>2) Completing W3C DOM method names + showing their arguments
>>
>>There are still a hell lot of differences between Java-editor and
>>JavaScript-editor expriences and I hoped IDEA 5 will solve most of them.
>>It appears to be just starting ..
I would be delighted to know your ideas on how this could be implemented
God, I loved it. And my answer is "Why should I care?" since I'm not an IDEA developer. The same way I may not care about how all IDEA features are implemented but still using them and being damn happy having them ..
As about possible ways to still do it - let's see ..
User-defined functions - just scan .js files - all functions() are there.
DOM functions - just provide the default list of DOM properties/methods, people will choose what they need. Current JavaScript code completion doesn't make sense in lot's of places anyway (see the screenshot attached for s typical example). So, there could be various kinds of JS code completion, say:
- "Core JS Complete" (completes core JS statements, functions, classes)
- "W3C DOM Complete" (completes W3C DOM properties methods)
- "Element/Document Complete" (completes all Element/Document properties,methods, like getElementsByTagName, createTextNode, etc)
You can use Danny Goodman's references (http://www.dannyg.com/ref/jsquickref.html) to group the various kinds of JS code completion.
Parameters list - you have them all, both for user-defined functions and the built-in ones.
P.S.
As about pre-release stage - if EAP wasn't crashing all the time, I was joining it months before the pre-release stage. I once has a veeery long discussion in this forum about EAP instability and lot's of people screamed at me saying how stupid am I to demand stable EAPs. Well, ok, Irida EAPs were soo unstable that almost all geeks around I knew have stopped using them. Me - I let myself installing it only after saw RC releases and already reported bugs, features, etc .. Something I really wish could do much much much earlier.
Attachment(s):
1.gif
To summarise - my idea is following: right, you can't know the variables real types (unless some kind of flow analysis is used) so give up on being precise and exact about code completion. Allow user the lists of standard properties/methods grouped by various categories and let him choose. If user chooses something that doesn't make sense in his context - well, too bad for him :) But we both know people usually have a pretty good idea about what are they intending to write in the editor so it's just a matter of picking a right property/method from the right group, that's all. I mean - just provide me with all properties/methods available in all objects, grouped by DOM classes, <input types, etc .. Become my "JavaScript: The Definitive Guide" - I have it's "References" chapters open all the time, especially "Part V: W3C DOM Reference".
And then - the situation will already get much better.
Eugene,
I would expect your replies to be a little more mature and/or professional! We do pay for using IDEA (you know...), and we do help you debugging it (by wiling to use you're EAPs).
1. "Not the best time to discuss..."
Your schedule is of no relevance here! Telling us that an obvious feature wont be included because you spend most of your time fixing bugs written by yourself is pathetic.
2. "I would be delighted to know..."
Of course you would... If you already had that knowledge you wouldn't be wasting our time with your moronic sarcasm, trying to change topic / buying yourself some time / trying to be funny etc...
3. "I mean how could we filter DOM..."
There ARE some useful books you can buy that will help you with this...
Give us a break... If you don't have anything smart to write, but still feal like you have to do something with your fingers, go color a Disney notebook.
Nancy Boy
I don't want such "dumb completion." I don't think IDEA should be
brought back down to the level of Visual Studio for completion. I think
if JS completion is to be implemented, it must be implemented using data
flow analysis, or else it should not be implemented at all. That's what
I want.
Evgeny Goldin wrote:
Nancy Boy wrote:
Says he, hiding behind a pseudonym.
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001
Can't agree with you. If you'll wait for flow analysis two things will happen:
1) you won't get in until year 2007 if all they can do right now is to complete the local variable names and allow me a "break" completion to "tbody."
2) it won't work correctly 100% of the time and will make mistakes. I mean, really, if JS method is called as "onclick" handler with some 'id' argument and getElementById() it - how any kind of flow analysis will know what kind of object is it ? It's only the person who wrote the code that knows this object happens to be, say, 'tbody' or 'tr' or 'input' with type "checkbox"
I suggest something simpler which isn't a rocket science - completions which are simple JS refrences, like those you find in "JS Bible" tables. This way two things will happen:
1) person will know he's using standard property/method (if his browser is reasonably updated)
2) no mistake will be made in method/property spelling
Besides, how about user-defined methods completion ? How hard it is to scan all .js files to get a list of all methods and their arguments ? (well, OO JavaScript may be an issue). It will also help to prevent naming a function with a name which is already used.
Gordon Tyler wrote:
>> I would expect your replies to be a little more mature and/or
>> professional!
You been reading my mind? ;)
Sascha
Nancy, JB responses may seem curt or rude sometimes but I have learned
that I think it's a misleading product of language barrier. Eugene can
say for himself but I think in general JB developers don't mean to
insult anyone on these forums. I may be wrong, maybe they do mean to,
but it's not the impression I get.
Nancy Boy wrote:
> but
Here is a copy&paste from one of my previous posts:
-
Regarding the DOM and custom object support, I think the same approach
like in the case of java could be made, plus:
- use the concept of "library", but in this case, to libraries will
belong all the javascript files in the current project/module
- javadocs like support for the parsed javascript files.
- javadoc like tags/annotations to extend information the IDE has over a
function (e.g. desired parameter type - even if one can change this
dynamically, desired return type, if the method is just a dummy for the
DOM/js objects,etc.)
- with the above functionality write a dummy/(wrapper) implementation of
the browser supported DOM Objects and the standard javascript objects,
as belonging to "Standard library" "Mozilla Library", "IE5.5 library",
etc., i.e. the same role that in java the JDK or the custom libraries
plays. In writing these "libraries, the community could help allot.
If one includes one of these "libraries"(dummy methods with javadoc
comments and annotations/tags), the editor has much more information to
provide a java similar intelligence to the user.
Unfortunately, I have no idea how to implement the above with the IDEA
OpenAPI :( - I suppose it's not even possible at the moment.
-
Ahmed.
Uhm, ouch... boy?
1. We do pay for using IDEA (you know...)
You're not pre-paying, right? If you don't like it => don't use =>
don't pay.
2. and we do help you debugging it (by wiling to use you're EAPs)
That's the whole point you miss the purpose of the EAP. It isn't for debugging.
Well, not only. It's all about continuous brainstorming where we share our
ideas with EAPers and learn from their ideas.
3. Your schedule is of no relevance here!
Quite right. But it's also true that our schedule, the process we have and
the features that we've done is simply non of your business.
4. obvious feature
Go ahead and do it yourself. Oh yeah, of course you have better things to
do with your fingers like writing these pointless rants!
Sure I'd better keep silence on this but... sorry, just couldn't resist.
WBR,
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
I always thought EAP is a developer-to-developer forum where professionalism
is not about saying sweet things but about discussing real stuff. I'm sorry
if I've offended someone with my reply, but again I don't see any use in
saying "I want this" if you don't detail what you mean. Back to the topic,
we've studied the
possibility of having DOM completion for quite some time, but haven't come
to any acceptable solution. On one side there is of course the possibility
to offer word completion from DOM dictionary as Evgeny has mentioned, on the
other we could use HTML document where this JS is embedded (if any) as a
reference structure for DOM. But again, if your document is dynamically
modified you won't get any suggestions. So to summarize it is dynamic typing
that makes JS editor less powerful than Java. Some posiibilities remain,
that we could dynamically analyze your script to get the desired
information, but this still sounds like fiction to me.
Eugene.
P.S. All that is written by me is my personal opinion.
"Nancy Boy" <no_mail@jetbrains.com> wrote in message
news:27997191.1122487230336.JavaMail.javamailuser@localhost...
>
professional! We do pay for using IDEA (you know...), and we do help you
debugging it (by wiling to use you're EAPs).
>
feature wont be included because you spend most of your time fixing bugs
written by yourself is pathetic.
be wasting our time with your moronic sarcasm, trying to change topic /
buying yourself some time / trying to be funny etc...
>
feal like you have to do something with your fingers, go color a Disney
notebook.
>
Eugene Vigdorchik (JetBrains) wrote:
I hope it doesn't annoy you for me to bring it up so much but I feel
you've never explained much why you feel this way about determining
runtime types statically.
Why do you think it's such fiction? Don't you think type could be
computed during annotator run, and cached in PsiElement for performance
in future annotator runs? I've learned a lot about dataflow from
implementing my @NonNull plugin, and it's not so hard. It's sure that
some types will never be known, and IDEA cannot help the developer
unless he or she designs code in a certain way. But, I think most JS
code is simple enough that even only intra-procedural analysis would
help a great deal.
To me it seems the only difference is that in Java,
PsiExpression.getType() returns immediately, while
JSExpression.getType() would require some more time and caches.
DFA-ing to know calc the type is only half of the problem Keiht.
Imagine the simplest use case possible: document.getElementById("some_table_id").
Generally, we only can complete Element methods here, not those specific
for ]]> tag, which might appear useless again. At least comparing to
simple 'all possible' methods completion.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
Keith,
You are right: there is a possibility to compute types (as a set of
properties certain object could have at some point).
Still I was talikng about DOM elements completion, and this is an external
environment to the JS code.
Consider the task of supporting this kind of completion:
first you have several DOM roots, like "document", "window" etc. Then you
call general purpose methods on these, like e.g. document.getElementById()
(not sure if this is true method), and obtain some general object of which
you don't know if it is really HTML tag, or a form or something else. - thus
when completing you either propose all properties of all DOM "classes", or
have some heuristics to filter them, like analyzing HTML document itself.
The latter sounds really tasty, but it has considerable limitations, and I
don't know any other ways to restrict this otherwise word-like completion.
Any ideas?
Eugene.
P.S. just now another idea has come to my mind, that we could use the same
technique as in java data-flow, and assume the object has a certain property
once you've dereferenced this property before. Moreover, since properties
from DOM are connected into graph, referring to one property would make
several others visible to completion.
"Keith Lea" <keith@cs.oswego.edu> wrote in message
news:dc8qo5$m3h$1@is.intellij.net...
>
>
>
I only expect Element methods in that case, nothing more. Eventually it
could be extended to be smarter about things like getElementById.
Maxim Shafirov (JetBrains) wrote:
Eugene Vigdorchik (JetBrains) wrote:
In that case you know it's at least an Element. Completing from there
with only Element methods would be a huge step forward, I think.
I think first implementing something basic (as basic as JS dataflow
engine can be) which knows simple built-in and DOM types like Array,
Element, would be a great start....
This sounds like it would be very powerful. I've been thinking of ways
for developers to give IDEA information about types. I was thinking
about javadoc-style annotations for functions, like /* @returns Array
*/, but I think that would be too cumbersome, by hand at least. It would
also clutter the code. With your assumption proposition, maybe when an
unknown property is accessed on an object, an "import popup" appears,
saying "Is this object: HtmlTable, HtmlForm, Array" (whichever types own
that property)", and inserts annotation into code somehow, like "//
@type(var) = Array".
This is my first idea about how to infer based on used properties, and I
hope it will promote further discussion, because my idea isn't so great
. I think having an editor spit comments all over the code is not so cool :)
I think you should consider, many people will be willing to change how
they code to get more benefits out of the editor. I know, I change my
Java code to suit IDEA analysis & other features sometimes. Maybe there
is some way to structure or annotate the code to make things like this
easier.
Anyway, as I said above, I think a great first step would be basic
intraprocedural analysis based on return types of DOM functions and JS
built-in functions.
I would be excited to start working on this, to add to the JS plugin,
but I don't think I have time anytime soon. I hope you guys do :) I
think having the first editor of this kind would be as revolutionary as
IDEA was in the first place. I imagine python and Ruby editors, in
addition to JS, which are as smart as Java editor, some day.
>>Eugene Vigdorchik (JetBrains) wrote:
>>
>>>that makes JS editor less powerful than Java. Some posiibilities remain,
>>>that we could dynamically analyze your script to get the desired
>>>information, but this still sounds like fiction to me.
>>
>>I hope it doesn't annoy you for me to bring it up so much but I feel
>>you've never explained much why you feel this way about determining
>>runtime types statically.
>>
>>Why do you think it's such fiction? Don't you think type could be
>>computed during annotator run, and cached in PsiElement for performance
>>in future annotator runs? I've learned a lot about dataflow from
>>implementing my @NonNull plugin, and it's not so hard. It's sure that
>>some types will never be known, and IDEA cannot help the developer
>>unless he or she designs code in a certain way. But, I think most JS
>>code is simple enough that even only intra-procedural analysis would
>>help a great deal.
>>
>>To me it seems the only difference is that in Java,
>>PsiExpression.getType() returns immediately, while
>>JSExpression.getType() would require some more time and caches.
"If you don't like it => don't use => don't pay"...
I'm sure your sales department fully "support" this approach...
I do hide behind "Nancy Boy" for many reasons...
I'll tell you about one:
Let's say (hypothetically), that when it comes to buying IntelliJ licenses, I play the role of an influencer / decision maker. In that case I wouldn't want my co-workers to know that although I recommend IDEA, I'm really disappointed with it... right?
I really like IDEA. I think it's the best (really).
But, not by far... Eclipse is really getting there, you know...
Since we have business relations with JetBrains I know you don't really represent them (Eugene, Maxim). You did, however, helped me solve the "moving to eclipse" dilemma...
Thanks guys...
Since it's obvious that IJ JavaScript analysis capabilities is not as
advanced as the Java ones at the moment, I would just add all the DOM
objects and functions as a hard coded thing (even common denominator
between IE and FF would be 90% of needs) and just blindly complete any
symbol in the file - functions, variables, etc. Add to that some OO JS
awareness and you got to the 80% point IMO, and JetBrains can worry
about making it as smart as Java (i.e. very extremely) later.
Amnon
Exactly. Instead of thinking too high about flow analysis, XDoclet-like comments and the like geek adventures .. adding some dumb DOM completions will already help tremendously to the JS developers. Plus AltUp/Down, CtrlP, Alt+F7 shortcuts - the usual things. And then it'll be time to discuss the next step - flow analysis, XDoclet-like comments, etc, etc, etc
On Wed, 27 Jul 2005 13:46:41 -0700, Eugene Vigdorchik (JetBrains)
<ven@jetbrains.com> wrote:
FYI -- IDEABKL-3061
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"charles eubanks" <charles.eubanks@sbcglobal.net> wrote in message
news:op.sul1priqwqdfgv@ceubanksxp.svl.ibm.com...
>
Thank you, this looks really interesting.
Does Eclipse do better for javascript?
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
How about you stop looking at what Eclipse does or does not and start thinking what is comfortable for JavaScript developers ? What makes them "develop with pleasure" ? Something you've excelled all those years, as well all know and respect IDEA for.
Because the current JS support is way too trivial to even call it a "JS suport"
Are you joking me?!
MyEclipse, Full features list:
http://www.myeclipseide.com/ContentExpress-display-ceid-15.html
MyEclipse, Javascript Editor:
http://www.myeclipseide.com/ContentExpress-display-ceid-58.html
Don't even bother replying...
Spend the time learning...
As I already said... You're pathetic!
In article <12943306.1122550704238.JavaMail.javamailuser@localhost>,
Nancy Boy <no_mail@jetbrains.com> wrote:
Wow real nice. Chicken shit and rude.
These are feature lists, did you ACTUALLY use it?
R
Oh Yeah !!!!!!
In article <19204407.1122551376353.JavaMail.javamailuser@localhost>,
Nancy Boy <no_mail@jetbrains.com> wrote:
Could someone toss this idiot off the forum please?
R
Ah,
I like IntelliJent people like yourself...
You're out of words, so start being voilent...
I guess you're pathetic too...