This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Some jVi users have reported that brace matching doesn't work correctly for php files. In particular, with jVi, if the caret is on a line with a brace (but not on the brace, just the line) then "go to matching brace" works. It first looks forward on the line for a brace char, then backwards. I don't use php, so I haven't tried this on php files. You can see the expected behavior with jVi when editing a java file. The brace matching spec, http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor-bracesmatching/overview-summary.html , has a section "Controlling the parameters" that describes what jVi does to get this behavior.
Not sure what you are talking about... So you wanna improve our NetBeans behavior to enable "go to matching brace" even though you are not on the brace? If it doesn't work now, it shoudl be an enhancement...maybe not for just PHP, but for a whole editor.
(In reply to comment #1) > If it doesn't work now, it should be an enhancement...maybe not for just PHP, > but for a whole editor. It does work now for most file types (including tags in xml/html files); PHP is the only one I know of that is broken. I'm setting this issue back to defect; I am assuming that is setting when something doesn't meet spec. The braces matching spec referenced in comment #0 says > the parameters can be controlled on per-component basis by setting > appropriate client properties. This is to allow interested modules > such as the jVi plugin to overwrite global settings and implement > their own searching policies. The following properties are supported. The spec goes on to define the ClientProperty key/values that it works with.
I still don't have your point. I really don't know, what you mean by "doesn't work correctly". Imho it works exactly as it should. It that spec part, there is nothing written what the behavior should be. Now, opening and closing brace is highlighted if you have a caret on the brace. Where is written, that it's wrong? If you think, that this behavior is wrong, provide me a snippet of code, where the problem will be described better (with step-by-step description of what to do, what is expected and what happens). If you just want to enable highlighting (matching) of braces if you are "not" on them, then it's an enhancement.
(In reply to comment #3) > ... It that spec part, there > is nothing written what the behavior should be. Near the beginning of the spec, under "The infrastructure overview" there are subsections "Search direction", "Maximum lookahead" and "Controlling the parameters". These sections describe the programability that "the infrastructure supports". For example it says the parameters can be controlled on per-component basis by setting appropriate client properties and then lists 4 properties (for example nbeditor-bracesMatching-maxBackwardLookahead). > Now, opening and closing brace > is highlighted if you have a caret on the brace. Where is written, that it's > wrong? The spec says, under "Search direction" when looking for the original area we not only want to look right next to a caret, but we also want to search a little bit further The current behavior is incomplete, that is what is wrong. It doesn't handle the client properties as defined in the spec. It only looks right next to the caret. It does not look "a little bit further". There is editor.bracesmatching/test/unit/src/org/netbeans/modules/editor/bracesmatching/MasterMatcherTest.java which does a little testing with some of the client properties. They are referenced as final strings such as MasterMatcher.PROP_SEARCH_DIRECTION. > If you just want to enable highlighting (matching) of braces if you are "not" > on them, then it's an enhancement. I've attached a screen shot showing braces highlighted when the caret is not on one of the braces. This is in a java file. Does this demonstrate that the issue is a defect and not enhancement?
Created attachment 118350 [details] braces highlighted when caret not at brace This is an example of how the brace matching infrastructure searches forward from the caret looking for a brace match. This is a java file
Assuming there is agreement on the spec...
No agreement, I have to discuss it.
(In reply to comment #7) > No agreement, I have to discuss it. That's progress. Is the issue whether the spec applies to PHP?
I get lookahead of 1 from MatcherContext, so I can search only on a caret. I tried to open and test some Java file and it highlights braces exactly as PHP modules do. You have to be at a brace to highlight it and its matching brace. And as you write, that the behavior is not complete, it's exactly what it wanted to be. The same as for Java and others. Yes, probably there is a possibility to improve that behavior and allow to increase searching area...not just a 1 token, but it has to be rewritten and now it works exactly as we wanted. Without any problems. It's not a defect at all. Nothing is broken. Probably I can implement it, but not now, because we are in fixing phase for 7.2 and no features can't be implemented. I'll let it as a P3 Enhancement and I'll invetigate it more for next release. Please, understand me. Problems which are now fixed are that exceptions are thrown, code completion doesn't work, indexing is slow, IDE freezes, etc. This feature improvement has no priority for this release. Sorry for any inconvenience. Thanks.
(In reply to comment #9) > I get lookahead of 1 from MatcherContext, so I can search only on a caret. I > tried to open and test some Java file and it highlights braces exactly as PHP > modules do. You have to be at a brace to highlight it and its matching brace. > > And as you write, that the behavior is not complete, it's exactly what it > wanted to be. The same as for Java and others. I have a plugin that sets different values for lookahead/lookbehind. And for java/text/html/... things work as demonstrated in the screenshot and as described in the NetBeans brace matching spec. (that is a real screenshot of netbeans, I didn't make that up which is what you seem to be implying) It may work as you want it to; but IT DOES NOT WORK ACCORDING TO SPEC. IIUC. I simply reported the issue. I would be satisfied if it was closed as wontfix; lowered in priority; deferred to later releases or whatever. Do you think it meets spec? (I understand it meets "your spec", but I don't believe it meets "the spec"). Do you think that the brace matching docs are not the spec? > Yes, probably there is a possibility to improve that behavior and allow to > increase searching area...not just a 1 token, but it has to be rewritten and > now it works exactly as we wanted. Without any problems. It's not a defect at > all. Nothing is broken. How do explain that it does not match the behavior described in the spec? It surprises me that meeting spec is considered an enhancement. Let me say again. I am not asking for this to be fixed right away (or at all). I am reporting a problem against NetBeans that has been incorrectly reported against a plugin. > Probably I can implement it, but not now, because we are in fixing phase for > 7.2 and no features can't be implemented. I'll let it as a P3 Enhancement and > I'll invetigate it more for next release. > > Please, understand me. Problems which are now fixed are that exceptions are > thrown, code completion doesn't work, indexing is slow, IDE freezes, etc. This > feature improvement has no priority for this release. I certainly agree on your priorities and understand that this is not appropriate for working on now (if ever). It's too bad that the PHP brace matching code didn't start with the code in the core NetBeans text editor. > Sorry for any inconvenience. The only inconvenience is dealing with my confusion about the desire to call this an enhancement request and/or what is the spec. > Thanks.
Sometimes I get too wrapped up in things... I don't mean to rant. I'm just looking to understand the process.
Same as me :) But now I don't have a power to discuss (unfortunately I don't have a time either :( ). So setting it as defect...but not sure if I'll be able to fix it for 7.2, really don't know. It has really low priority. But we'll see...