- This topic has 29 replies, 4 voices, and was last updated 20 years, 2 months ago by
.
-
Posts
-
Scott,
I guess there are some subtleties here that I don’t understand. To my straightforward (perhaps thick) way of thinking, if you’re flagging an error in the margins and the problems view, I don’t see why the source can’t be marked up. If you’ve thoroughly explained it and I’m not getting it, well, I guess I’ll have to live with it. It just seems inconsistent and improper to me. (BTW, your reference to “synthetic accessor method” lost me, and maybe that’s where the crux of the explanation lies. Sorry.)
TR
TR,
I understand your request and will go ahead and file it… you just want a red squiggly under the error, so if for some reason God came down from heaven and erased your left and right margins, you’d still be able to see which lines had errors by way of a MS Word-style-red-squiggly-underline under the tag with errors, am I correct?I don’t think marking the entire tag with a squiggly is too hard, but marking JUST the attribute might be a pain, I’ll see what I can do though.
If I’m not mistaken, you want something like this right:
TR,
The main point was that there are two completely different frameworks at work in all Eclipse editors. Once is the error reconciler that handles the “real time” error marking (squiggles) and the overview annotations that show up in the right margin (annotations ruler). These markers are transient in nature and do not place a permanent warning/error icon in the left margin or an entry in the Problems View. There are limits to what you can validate in real time, because the overhead can’t be so hight that it affects user response time. So, some percentage of errors, but less than 100%, will be found by the reconcilers of the various content editors. Some editors are better at it than others.The second level of checking is a rigorous validation that is often done via compilation. Validation is only performed when specifically requested by the user through a workbench action, such as saving a file with “auto build” turned on, cleaning a project, or selecting “Validate ..” off of a context menu. Validation errors of this nature are permanent and are marked with an error or warning in the left margin in the editor and in the Problems View.
So, for errors that are caught by *both* mechanisms, all forms off error annotation will be shown. For those that are missed by the reconciler but caught by full validation, only the second set will be shown. This is the case in the example you’ve seen with an invalid attribute. The reconciler misses it, so there’s no squiggle under it, but a full description is available in the Problems View and the hover in the left margin lets you know what the problem is.
So, different checking mechanisms yield different types of markers in different places. My only point with that esoteric java editor example is that it is a spot where the Java editor’s reconciler will not report the warning (no squiggle) but the compiler will, so it is marked exactly as your example.
Scott,
It sounds like once the compiler has found the error then it is possible to put the markers in the code. Is this not the case? This is exactly what I’m talking about. The file has been saved, there is a marker in the left margin, but there is no markup in the code. This is the way it seems to work everywhere else.
Granted, I can look to those other areas for more information about the error. But if the attribute is marked with a squiggly line, or in some other manner, I don’t have to go looking. I then know without further investigation where the problem lies. This is what I’m looking for if it can be done.
Thanks for your persistence. 🙂
TR
TR,
Yes, of course it’s a possible enhancement. I was simply explaining that this is “works as designed” at the moment. The problem with doing it is that the compiler doesn’t give us column information and all error messages are human-readable so it would be very tough to figure out what it meant programmatically to know where to put the squiggle.
Scott,
Sorry to beat this to death, but…
Prior to 3.8 GA, the JSP editor showed invalid attributes in bold red. I only remember the functionality, and not whether it was inefficient or made the editor sluggish, which may be why it was removed.
My $.02 is to leave “options” like this in, and make their use configurable/optional, if you can. I didn’t realize this functionality had “gone away” permanently. I thought it might have been a bug that killed it, or that it didn’t work because I was using Struts 1.2.x. I kept waiting for it to be fixed in one of the point releases after GA. At least I know what’s going on now (sort of).
Thanks for your patience and all your help.
TR
I only remember the functionality, and not whether it was inefficient or made the editor sluggish, which may be why it was removed.
Actually its because the editor code base completely 100% changed… actually for ALL of our editors. Previously they were custom editors, but in 3.8.1 beta we integrated the WTP editors, and we continue to extend/enhance them. That’s why the sudden change in behaviors.
My $.02 is to leave “options” like this in, and make their use configurable/optional, if you can. I didn’t realize this functionality had “gone away” permanently.
It was one of the things that changed when we completely replaced the editors, there were a few things lost, but a myriad of things gained. We hope overall you like the editors more now.
Thanks for your patience and all your help.
That is what we are here for. I am sorry that this didn’t work out in the end, normally we do what we can to accomodate most everyone’s reasonable requests, I think the issue here is that by design all the editors are consistent with the Java editor so everything *feels* right across the board to new users… to introduce this inconsistent (but some might find helpful) feature, we are a bit hesitent… of course, as with everything else, if enough users would want this, we’ll do whatever you guys ask for.
I thikn at the end of the day it boils down to priorities… we have some seriously big things in the works, and something like this (unless lots of people wnated it) fall behind the polls that we have run for months where 80, 90 or 100 people all want support for something else… if we had more people, we’d do everything you guys asked for 😉
Riyad,
Thanks for your detailed and considered response. I understand resource contrainsts, believe me. I’m basically a one man shop working on a large-ish project.
My one remaining contention is that I don’t think this is consistent behavior. At least, I have not observed anywhere that there is an error flagged in the left margin where it is not also indicated in the source code. I can live with the current functionality, but I haven’t been convinced that this is the way it “should” work.
Regardless, I appreciate your effort and all the features you guys keep cramming into the product. 🙂
TR
but I haven’t been convinced that this is the way it “should” work.
Actually if you see from my post above with the screenshot, I wasn’t convinced either until Scott explained what was happening… basically it looks like it works this way in the Java editor because the reconciler catches *so much* of the errors (like in my screenshot). Scott gave a case in his post where the reconciler won’t catch the error in the Java editor, and you won’t get a squiggly (assuming I understood him correctly).
However in the case with JSP, parsing JSP is incredibly expensive/complex so the reconciler isn’t as *smart* and misses a lot more that only validation (compilation) can catch… hence the seemingly always missing red squigglies in the JSP editor.
That is not to say that this won’t be an enhancement in the future as we make the reconciler more intelligent.
Scott please correct me if I misunderstood your post, and TR my followup is not meant to persuade at all, I still understand your original request and still see value in it, it is a good request.
Riyad,
I didn’t really understand Scott’s explanation because it may be a case that is more obscure than I normally run into. That’s OK. One can’t know everything. It seems extremely logical to me that if the compiler can flag something as an error after compilation/saving, that it should be possible to indicate such in the source. The popup message gives the name of the attribute, so I don’t see why it wouldn’t be possible to annotate the code. Though Scott did mentions something about column data not being returned by the compiler. That’s probably the sticking point, which is unfortunate.
Oh well. I’m just happy you guys have put together this product as it’s been very helpful to me.
TR
I don’t get the red X in the left margin, but I get the red square in the right margin when editing JSP-files. And I don’t se the errors in the “Problems” window. Both work in Java-files. Could you tell me where I can enable in “preference”?
Sure, if you tell us all your system info first 😀
Can you please post all the information we request in the [URL=http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-393.html]Posting Guidelines[/URL] thread at the top of this forum? That will give us some context so that we can determine if this is an installation issue, a configuration problem, or a bug. Thanks.
Sorry. Here it is: Windows 2000, Eclipse 3.0.1, MyEclipse 3.8.2. Clean install (I tried updatemanager fist but I was missing the “red X” and thought that a clean install would do, but it didn’t help). Tried also a fresh workspace, with no success.
Can you give me the snippet of code that is causing the “error” and what the text is that is shown when you mouse over the red marker on the right side of the editor?
Also try and puposeful create an error in the page and save it (to validate it), add something like:
<% lakdjlakjsdald %>Do you get a left margin marker then and something shown in the problems view? Do you have all the problem view filters turned on? (click the down arrow in the top right corner of problem view, go to Filters… and hit “Select All” then OK”).
