Develop with Pleasure: The Next Big Thing

I'd suggest two things:
1. JavaScript frameworks support (prototype-style classes, mootools-style classes, dojo, maybe yui, maybe ext)
2. Add common refactorings to openAPI, so that custom languages could provide not only rename and introduce variable, but more complex ones. And add them it to Ruby, Groovy, Javascript..

Hello Jay,

I'd suggest two things:

1. JavaScript frameworks support (prototype-style classes,
mootools-style classes, dojo, maybe yui, maybe ext)

2. Add common refactorings to openAPI, so that custom languages could
provide not only rename and introduce variable, but more complex ones.
And add them it to Ruby, Groovy, Javascript..

These aren't really big things. :)

JavaScript frameworks are basically supported at the rate of someone filing
JIRA issues requesting specific features to support. (As far as I know, prototype-style
classes are already supported.)

Refactoring OpenAPI is currently mostly driven by the requirements of the
language plugins we are developing. (For example, Groovy developers wanted
to have Inline, so Inline is pluggable in 7.0.) We find that this works better
than adding speculative APIs which are not initially used by anything, because
such APIs can turn out to be unsuitable for any actual use.

So, yes, we will definitely have more of each of these items in the next
release.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Hello Dmitry,

Refactoring OpenAPI is currently mostly driven by the requirements of
the language plugins we are developing. (For example, Groovy developers
wanted to have Inline, so Inline is pluggable in 7.0.) We find that this
works better than adding speculative APIs which are not initially used
by anything, because such APIs can turn out to be unsuitable for any
actual use.

The worst API is an API that doesn't exist. To be honest, I don't understand what's the
point in preventing people to plug into actions that do already work for java code, just
because there's no JB-plugin that needs it.

All the popular refactorings could have been easily made available like
RefactoringSupportProvider#getIntroduceVariableHandler - maybe not at such high level as
the new InlineHandler - but with virtually no risk of creating an API that's "unsuitable".

http://www.jetbrains.net/jira/browse/IDEADEV-10476

Sascha

Hi,

My modest wish list includes:
Support for C++ (eclipse has it).
Support for Velocity templates

Thanks,
Erez.

Hello enahir,

My modest wish list includes:
Support for C++ (eclipse has it).

This is out of scope for the IntelliJ IDEA project, and we don't have any
plans to develop such a project at JetBrains. There's a third-party C++ support
plugin available on plugins.intellij.net.

Support for Velocity templates

This is very likely to be implemented in 8.0.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

The problem with opening handlers is that it is too high-level, thus it is inappropriate for refactoring cross-language projects, i,e, when the target is in one language and the reference is in the other. If you look at API for inline, it does account for this.

Eugene.

Dave Griffith wrote:

I'll start: Integrated task management, including adapters for all of
the major issue tracking systems, Mylyn-like context management,
clean integration with IDEA change lists, and probably some TeamCity

Time to start giving some love to my JIRA browser plugin - I think
theres also a few other task tracking/todo list plugins already that
could probably pull together for somethng fancy... maybe.

Dave Griffith wrote:

1) Suggestions must be something large enough to appear as a line
item on the IDEA 8.0 roadmap.

1. Open Code Coverage data to inspections - I'd love to run some tests,
navigate to some uncovered code and have IDEA subtly give me a lightbulb
to "Add test for method #xxxxx". Or have inspection reports highlight
code thats not covered by tests.

I'm sure there could be alot of things we could come up with if the
coverage data was accessible...

Mark Derricutt wrote:

Dave Griffith wrote:

>> I'll start: Integrated task management, including adapters for all of
>> the major issue tracking systems, Mylyn-like context management,
>> clean integration with IDEA change lists, and probably some TeamCity

Another one - distributed version control systems.

Theres the Mercurial plugin being developed already, taking that onboard
and making it a first class VCS module would kick arse.

Hello Eugene,

Inline may be a special case, but for the vast majority of cases, the issue of
cross-language references just doesn't matter. My point is that the API should have been
made consistent in the moment Introduce Variable has been added, which could have done
with virtually no effort, but would have allowed to plug into the standard-refactorings in
a proper way.

And there's also nothing that prevents refining the APIs when needed. IDEA-APIs break
between every release, knowingly or unknowingly, so until a refined high-level API is
needed, there would at least be some API.

I even doubt I could now use the InlineHandler API for XSLT because I don't have control
over the hosting XML-Language's refactoring support. Which makes the new high-level API in
fact less powerful, and that's what I'd call an unsuitable API (even if I have to admit
that this is a rare case too).

I'll wait and see what IDEA 8.0 will bring... ;)

Sascha

Hello Eugene.

I don't clearly understand why some refactoring handlers could be inappropriate for cross-language projects.
The thing that i am mostly conserned about is simply some place for refactorings. I remember i was trying to add introduce variable in IDEA 5.1 - and i was a bit confused by the fact that it seemed like i needed a new action with the same CtrlAltV shortcut which i would place somewhere in menu with title "my custom language refactorings". To me refactoring is not dependent on the language.

ps. Sascha, thanks for support

>> Support for Velocity templates

>This is very likely to be implemented in 8.0.

Tapestry? Freemarker? Pure curiousity. I've got no particular dog in this fight.

--Dave Griffith

see subject

Theres the Mercurial plugin being developed already, taking that onboard
and making it a first class VCS module would kick arse.

If you find a 100%-Java implementation, that would be cooool.

Hello Mark,

Another one - distributed version control systems.

Theres the Mercurial plugin being developed already, taking that
onboard and making it a first class VCS module would kick arse.

I wonder if there's any data available regarding the usage of distributed
VCS systems in the enterprise. So far it looks like the DVCS adoption is
coming quite slowly (for example, people kept on talking about the Mercurial
repository for OpenJDK, and it's still nowhere to be seen).

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Hello Dave,

>>> Support for Velocity templates
>>>
>> This is very likely to be implemented in 8.0.
>>

Tapestry? Freemarker? Pure curiousity. I've got no particular dog in
this fight.

Freemarker, yes; Tapestry, don't know. With the usual amount of disclaimers
that apply. :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Hello Mark,

1. Open Code Coverage data to inspections - I'd love to run some
tests, navigate to some uncovered code and have IDEA subtly give me a
lightbulb to "Add test for method #xxxxx". Or have inspection reports
highlight code thats not covered by tests.

I'm sure there could be alot of things we could come up with if the
coverage data was accessible...

Well, it is accessible. It's even in the OpenAPI. It even has some javadocs.
See the CoverageDataManager class.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Hello Dmitry,

>>>> Support for Velocity templates
>>>>
>>> This is very likely to be implemented in 8.0.
>>>
>> Tapestry? Freemarker? Pure curiousity. I've got no particular dog
>> in this fight.
>>

Freemarker, yes; Tapestry, don't know. With the usual amount of
disclaimers that apply. :)

IIRC, during start of Selena EAP there was a plan to use the RHTML work from
the Ruby plugin to build a (sample) Velocity plugin.
Did something come out of this?

-tt

Hello Taras,

>> Freemarker, yes; Tapestry, don't know. With the usual amount of
>> disclaimers that apply. :)
>>

IIRC, during start of Selena EAP there was a plan to use the RHTML
work from the Ruby plugin to build a (sample) Velocity plugin.
Did something come out of this?

No, as far as I know.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Things I would love to see:

1) Ant debugging like netbeans has (see http://ant.netbeans.org/debugger.html)

2) Similarly: XSLT debugging

3) Editor groups (see http://www.jetbrains.net/jira/browse/IDEA-12130); ability to group the currently open editors into separate tabs, either by filetype, by VCS status, by module, ...

Dmitry Jemerov wrote:

I wonder if there's any data available regarding the usage of
distributed VCS systems in the enterprise. So far it looks like the DVCS
adoption is coming quite slowly (for example, people kept on talking
about the Mercurial repository for OpenJDK, and it's still nowhere to be
seen).

Kelly O'Hair's been publically blogging lately about the transition to
mercurial:

http://weblogs.java.net/blog/kellyohair/

I have been seeing more and more places adopting mercurial (although I
dont have references off hand).

Dmitry Jemerov wrote:

Well, it is accessible. It's even in the OpenAPI. It even has some
javadocs.
See the CoverageDataManager class.

Mmm when did that come in? I wonder if just didn't get me access to the
data I wanted (easily) when I last looked at that.

Hmmm - time to go reading ;)

Hello Jens,

2) Similarly: XSLT debugging

That's not too far away actually ;)

Sascha

Really nobody interested? Or do your Website designers already have their
own tools? We don't need Velocity or FreeMarker templating any more after
switching to Wicket.

Jay wrote:

To me refactoring is not dependent on the language.

There's much more in refactorings than it seems too... They care about
control flow, constant evaluation, data flow calculations, variable
aliasing, exception handling, etc. And all these are fundamentally
different in different languages. It really seems that creating
abstractions of this level might be impractical. That's why we're still
looking for problem solution and try to generify existing refactorings.

The worst API is an API that doesn't exist. To be honest, I don't
understand what's the point in preventing people to plug into actions
that do already work for java code, just because there's no JB-plugin
that needs it.

This sounds like a "Worst feature is a feature that doesn't exist. Give
us FEATURES!"...

We do try to add API whenever possible. We simply can't add api to all
refactorings at once due to their number and complexity.

IIRC, during start of Selena EAP there was a plan to use the RHTML work
from the Ruby plugin to build a (sample) Velocity plugin.
Did something come out of this?

You slightly missed the point. We reimplemented JSP and used RHTML as a
testbed for new API, which will (might/can) be used for Freemarker
implementation.

Hello Mike,

>> The worst API is an API that doesn't exist. To be honest, I don't
>> understand what's the point in preventing people to plug into actions
>> that do already work for java code, just because there's no
>> JB-plugin that needs it.

This sounds like a "Worst feature is a feature that doesn't exist. Give
us FEATURES!"...

Sorry, that's absolutely not what I said. It's about the difference of having no simple API at all
vs. an API that fits any possible future requirement but doesn't exist.

Please see the issue link I posted. I still haven't seen a good reason yet why the
RefactoringSupport interface doesn't contain methods that return a simple RefactoringActionHandler
for the most common refactorings. That's not blindly calling for vague features, but a very clearly
formulated request.

We do try to add API whenever possible. We simply can't add api to all
refactorings at once due to their number and complexity.

Well, adding "@Nullable RefactoringActionHandler getExtractMethodHandler()" and some of its
relatives is hardly a high number nor an extreme complexity.

I don't like to argue about this and I really appreciate that you strive to provide the best
possible API, but I honestly don't understand this policy that has now prevented custom languages to
properly implement e.g. an Extract Method feature since the Language API was introduced over two
years ago.

Sascha

If you really want to know: no, not really.

I can imagine that creating a WYSIWYG-HTML will take a really long time, and the added value (for me) will be minimum. I see IntelliJ primarily as Java IDE, not an all-in-one tool Support for Ruby and Groovy are some nice extra's, but I don't like to see IntelliJ becoming the next Frontpage.

Frontpage is a nice tool, Dreamweaver is also pretty nice: you are probably better of using them instead.

I'd much rather see integrated profiling, better code coverage support, and Java framework support (Terracotta/Gigaspaces/Guice/Wicket) than things like this.

Hello Erik,

I'd much rather see integrated profiling, better code coverage
support,

What exactly would you like to see improved?

and Java framework support
(Terracotta/Gigaspaces/Guice/Wicket) than things like this.

Have you tried the existing plugins for Guice and Wicket? If yes, do they
suit your needs?

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"