3 comments

Hi Robert!

Yes it did, but is this going to be fixed so users in general don't have
to do that?

The problem is that your files were not processed as JSP files, and
personally I think it is correct since we need to know the filetype
before parsing file and extension is the best (cheapest) way to get this
info.

>>4- Color coding is off, commented out java scriptlets still show like
>>live highlighted code.


I can't find this issue in Tracker nor reproduce it. Please file one or
send me reference on it.


huh... I don't have it in my watches either. lame. somehow it got
lost. I need to reproduce and refile. I owe you a report there.

Ok. looking forward to get it from you.

>>7- Debugging is in the dumpster.


In progress. We had some serious changes in debugger recently and it is
not stable jet.


Yup, critical since on the JSP end debugging simply does not work to any
usable level.

Agreed. I hope it will be fixed soon.

Thanks,
IK

--
Igor Kuralenok
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

Igor Kuralenok wrote:
>>Yes it did, but is this going to be fixed so users in general don't have
>>to do that?


The problem is that your files were not processed as JSP files, and
personally I think it is correct since we need to know the filetype
before parsing file and extension is the best (cheapest) way to get this
info.


Can an intention be added for unrecognized file extensions embedded in
JSPs? The intention would register the file type as a JSP type.

Jon

0

Jon Steelman wrote:

Igor Kuralenok wrote:

>>> Yes it did, but is this going to be fixed so users in general don't
>>> have to do that?
>>
>>
>> The problem is that your files were not processed as JSP files, and
>> personally I think it is correct since we need to know the filetype
>> before parsing file and extension is the best (cheapest) way to get
>> this info.


Can an intention be added for unrecognized file extensions embedded in
JSPs? The intention would register the file type as a JSP type.


Well there is a further problem with all this. Sometimes I get other
folk's work where they put the JSP code in a .txt file. Now last I
tried, when you try to add an extention that already exists, it gives
you an error and doesn't let you. So while the workaround in my first
case is OK because .inc wasn't part of anything, .txt is, and therefore
a text file may or may not containt JSP code.

I would PREFER the following behavior if at all possible, and I don't
think it's unreasonable since they have to parse the include anyway.

If you see something like this in a JSP page:

<%@include file="foo.inc" %>

first thing you do is parse the top of the file to see if you can find
either:
a- a page directive indicating the language of the file
b- anything starting with <%@

If you do assume it's a jsp page. If not, then let the user worry about
it. For the case where users don't want that behavior, give us a check
box to not parse include files for the possiblity that they're JSP
pages. Most if not all JSP programmers will never put a page directive
in the middle of the page, usuall within the first 5-6 lines you know
that you're in a JSP page. I think my reasoning here would hold true
even if all we had was scriptlets in the code, you still need to do page
imports.

See I often work on code from JSP-based portals. I don't write the
original code but have to modify it for our own purposes. This means
that I need to spend a good amount of time getting all the pieces
together so that I can compile, debug and add more code to their code.
it's often a pretty darn ugly process to go through, and in my own ways
I have to admit, I am trying to take advantage of both JetBrains'
generosity and great ability to listen to solve my problems, or see if I
can't get them to twist something to help me do my work better.

While this piece is not HUGE, it's still a problem.

R

0

Please sign in to leave a comment.