Whats Next - Summary

Tim Twe wrote:

Bugs
+ Working/Fixed UNDO
+ Memory leaks: working with multiple projects and opening/closing them.

To this I would add:
+ Editor performance on not-so-large files:
http://www.intellij.net/tracker/idea/viewSCR?publicId=33061

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

and: fix all the annoying little bugs !!
Introduce new features into IDEA that assist in fixing bugs that are hard to reproduce (because of course you use IDEA to develop / improve IDEA)

Every developer could take advantage in the knowhow / assistance of really tuning a complex software to the maximum and make it 100% bugfree.

Come on, I need at least 99% bugfree IDEA - the bugs in my own software are causing my enough pain ;)

just tried to run a JUnit test method (one method alone) that was not prefixed with "test" - IDEA allows it but then locks deadly...

What about the advanced JavaScript/HTML editing ?

lllopo wrote:

What about the advanced JavaScript/HTML editing ?

It seems there will be only primitive JavaScript support :(, that what
all other editors at the moment know.

Ahemd.

I find very few bugs. Okay, i dont do any web or J2ee stuff, so i'm hardly using IDEA to its fullest.

Actually... I've probably had 2 issue/bugs. but it was far from blocking. 1 was something that I had to terminate IDEA... and the other was structural search/replace in an XML file (didnt work).


Its obvious that using a beta there may be issues... so i hope you're not refering to those issues.

-Tim

Well, I think this is essential for an IDE that supports J2EE/WEB programming ... and it's really essantial.

Hi,

Any details / tracker request on this?

Tim Twe wrote:
and the other was structural search/replace in an XML file (didnt work).


--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

lllopo wrote:

Well, I think this is essential for an IDE that supports J2EE/WEB programming ... and it's really essantial.

There's no JavaScript editor at the moment that knows "intelligent" code
completion, code navigation, find usages, etc.
Jetbrains would have a real advantage over Eclipse and the others with
such a feature, but it seems to me that "Subversion Integration" has
much more lobby :(.

Ahmed.

I think that .js support would be a large feather in their cap, but ....

It would be better to support the java web side well before venturing to
the client side. When you look at missing JSP 2.0 support (don't
underestimate this - it is a HUGE change) and no JSF support, IJ is
starting to look dated compared to Eclipse, JBuilder, Sun Java Studio
Creator and WebSphere Studio.

Also, I RARELY use java script. It's too much of a pain to keep it
working on all browsers. Any uses from me will be using established
Jakarta Commons libraries and there are JSP components to make the
libraries easy to use.

Ahmed Mohombe wrote:

lllopo wrote:

>
>> Well, I think this is essential for an IDE that supports J2EE/WEB
>> programming ... and it's really essantial.
>

There's no JavaScript editor at the moment that knows "intelligent"
code completion, code navigation, find usages, etc.
Jetbrains would have a real advantage over Eclipse and the others with
such a feature, but it seems to me that "Subversion Integration" has
much more lobby :(.

>

Ahmed.

Norris Shelton wrote:

I think that .js support would be a large feather in their cap, but ....

It would be better to support the java web side well before venturing to
the client side. When you look at missing JSP 2.0 support (don't
underestimate this - it is a HUGE change) and no JSF support, IJ is
starting to look dated compared to Eclipse, JBuilder, Sun Java Studio
Creator and WebSphere Studio.

Also, I RARELY use java script. It's too much of a pain to keep it
working on all browsers.

Well you are lucky because you can choose not to use it. In the most of
the projects however JavaScript IS required (or how yould you like to
make all that client side work?). JavaScript is indeed a pain, but hey,
it should be the job of IDEs to make it easier.
I can remember that java was "dumb" too before that CodeSearch plugin
from IntelliJ (for JBuilder at that time :) ). Only after IntelliJ made
the "intelligent" code completion, all the others started to do the same
:), o,r am I wrong?

Ahmed.

One thing I would like to see added to the list is the inclusion of the PropertiesEditor plugin to the general installation, much like IG and IPP were added. This is a very useful plugin and would definately add to the overall product.

Sean

I would like to see a properties editor, for sure (I need it every 1-2 hours of my work), but something BETTER THAN THIS ONE. The author keeps putting some non-sense features, while some essential things are missing, like the ultra important i18n support.

er, I didnt log a tracker request.

I was working through an XML structure and wanted to perform a subtle structural change (playing with ideas before its set in stone). Put various attributes into a particular namespace; move XML elements outside their parent, etc.

Never having used structural search I tried on a really simple document (example below, query included the angle brackets) to learn how to use structural search and get to progressively more complex examples before doing a search and replace.... Tried fiddling with regex and other parameters... no luck. with <$tag$>]]>

should come up with resultset = { abc , def } the is questionable....

For XML files, under no circumstances could i get even one result. I assumed it would only work on java files.

A couple of different tries and there were a couple of exceptions. After looking through the structural search templates I noticed that there were no XML examples.

Maybe i was using it incorrectly.

very few bugs / beta:

of course I'm only talking about bugs that occured
with the released IDEA 4.5

I had problems with IDEA totally locking when running
JUnit tests (seems to be related to printf statements
in native code), or it outputs "Cannot proceed" in the
JUnit output window and you cannot view the rest of the
output.

Then everything I posted here in the recent days -
mostly do not get a response, except from the struct
search guy. I know that I should file in tracker, but my time is very limited (would have to first check if bug report already exists) - and I am lazy, that's why I use IDEA ;)

Again, in former times (sigh ;) almost virtually every bug that was reported was fixed nearly instantly...
Today you find unfixed bugs that were reported in the
year 2002 ...

IDEA is slowley but cruelly losing reputation.
Time will tell if it is a good marketing decision...

Nice weekend, nevertheless ;)

I have the opposite problem. We have contracts with some government
agencies that require absolutely no java script. They even test with it
disabled.

Ahmed Mohombe wrote:

Norris Shelton wrote:

>
>> I think that .js support would be a large feather in their cap, but ....
>>
>> It would be better to support the java web side well before venturing
>> to the client side. When you look at missing JSP 2.0 support (don't
>> underestimate this - it is a HUGE change) and no JSF support, IJ is
>> starting to look dated compared to Eclipse, JBuilder, Sun Java Studio
>> Creator and WebSphere Studio.
>>
>> Also, I RARELY use java script. It's too much of a pain to keep it
>> working on all browsers.
>

Well you are lucky because you can choose not to use it. In the most
of the projects however JavaScript IS required (or how yould you like
to make all that client side work?). JavaScript is indeed a pain, but
hey, it should be the job of IDEs to make it easier.
I can remember that java was "dumb" too before that CodeSearch plugin
from IntelliJ (for JBuilder at that time :) ). Only after IntelliJ
made the "intelligent" code completion, all the others started to do
the same :), o,r am I wrong?

>

Ahmed.

Norris Shelton wrote:

I have the opposite problem. We have contracts with some government
agencies that require absolutely no java script. They even test with it
disabled.

Yes, I know that "government agencies" have such restrictions, but where
productivity and user friedleness is required, no one can afford so many
roudtrips to the server.

Ahemd.

What things missing? What is i18n suuport?

I would beg to differ. On http://www.techrepublic.com , we did
everything client side (before CNet screwed it all up). We were serving
a few million registered users with a completely dynamic site. The only
thing that was static were the icon images.

We always beat the industry average for response time.

Ahmed Mohombe wrote:

Norris Shelton wrote:

>
>> I have the opposite problem. We have contracts with some government
>> agencies that require absolutely no java script. They even test with
>> it disabled.
>

Yes, I know that "government agencies" have such restrictions, but
where productivity and user friedleness is required, no one can afford
so many roudtrips to the server.

>

Ahemd.

More wishes for the next version:

- Back-in-time debugger
Coolness.

- Fix package names
Go through files and fix packages to match directory structure.
For example, after copying a bunch of files from a different project
all the package statements are incorrect. IDEA should be able to go
through and fix them.

- Move method refactoring
No further comment necessary.

- Branch package
Copy package and change references to new package. Useful for branching
a package from a different project.

- Show exception source
Visualize where in the call tree certain exceptions are generated.
(Eclipse has this in M7, which I didn't know when I first thought of this.)

- More structural awareness in editor
Make it possible to move elements around in the parse tree.

Internationalization support(it's called i18n , 'cause it's an-18-symbols-word :)).
Just write an unicode properties file , then compile it with the provided java tool (native2ascii.exe) as it should be, and then open it in the (so called) properties editor plug-in.

lllopo wrote:

Just write an unicode properties file , then compile it with the provided java tool (native2ascii.exe) as it should be, and then open it in the (so called) properties editor plug-in.

So what stops you from doing this? Personally I'm doing it all the time,
except that the native2ascii is part of my build script (it makes sense
if you sometimes want to edit your file at the client site.)

-- dimiter

If you know way how do it with existing Open API and saving all exisiting features I'll mail you sources of plugin and you can add this feature. And you'll become (so called) author of i18n part of (so called) properties editor plug-in.

Internationalization support(it's called i18n , 'cause it's an-18-symbols-word :)).

"internationalization" has 20 characters, but in "i18n" 18 characters
are ommitted :)

Tom

Obviously

What do U mean ? It seems like U don't find this to be important. It's simple - this plug-in can be used for editing only non-unicode property files. If U can't call this a huge restriction, than I don't know ... for me it's a big miss.

Man, just replace the /uXXXX with the appropriate unicode symbol when opening, and put back all non-ASCII chars to /uXXXX form on save. I think this will be enough.

I don't mind to make this, but I don't have the time for now. Anyway , U can send me the source and I'll try to find the time for this, cause it's really important for many developers. Use this mail : lllopo@abv.bg

I have discussed this many times in other forums (if U remember), anyway, once again - I really appreciate your work, but sometimes it seems like U try to avoid the problems and not to solve them. May be U miss a bit the users feedback, I don't know.

Greetings

lllopo wrote:

What do U mean ? It seems like U don't find this to be important. It's simple - this plug-in can be used for editing only non-unicode property files. If U can't call this a huge restriction, than I don't know ... for me it's a big miss.

It's perfectly ok to edit unicode encoded with UTF-8 or whatever else
encoding for that matter. The escaped values are NOT unicode. They are
just that - escaped values. And yes, I don't need editing of escaped
values in property files any more than I need HTML editing plugin for
javadocs.

It's perfectly ok to edit unicode encoded with UTF-8
or whatever else
encoding for that matter. The escaped values are NOT
unicode. They are
just that - escaped values. And yes, I don't need
editing of escaped
values in property files any more than I need HTML
editing plugin for
javadocs.

Then you've never done serious localization, particularly not for asian languages. Try writing a japanese property file using escaped values. It's nowhere near "html for javadocs".

Marcus Brito wrote:

Then you've never done serious localization, particularly not for asian languages. Try writing a japanese property file using escaped values. It's nowhere near "html for javadocs".

It's kind of funny, but this is exactly the situation with me :)

I'm using shift_jis encoded property files and during the build I
translate them with native2ascii. Yet, I never edit the already
translated properties - I treat them like any other compiled file. I.e.
if you need a minor change in class functionality you dont patch the
bytecode (or do you?)

-- dimiter

It's possible to do it on loading but not possible on saving cause there are only beforeDocumentSaving and no afterDocumentSaving. Is one way conversion enough?

TIA,
Dmitry