Community
Participate
Working Groups
It would be nice if JDT's code folding supported named custom regions, vs.net editors already offer similar functionality. The syntax of region definition could be like following: // region Blahblah .... // endregion
My code folding plug-in strives to have custom regions, although currently the regions aren't name-able - please check it out: http://www.coffee-bytes.com/servlet/PlatformSupport ... and submit enhancement requests at the sourceforge page! Thanks, R.J.
*** Bug 96422 has been marked as a duplicate of this bug. ***
Note that you can now name the coffee-bytes code folding. I like it; it works pretty well.
I tried it, seems pretty buggy to me. Might be that I'm using 3.1M7. Still would be nice if Eclipse supported this out of the box.
*** Bug 99284 has been marked as a duplicate of this bug. ***
*** Bug 102814 has been marked as a duplicate of this bug. ***
*** Bug 191926 has been marked as a duplicate of this bug. ***
Fyi, just noticed that this is how the NetBeans 6 beta supports this: // <editor-fold defaultstate="collapsed" desc=" UML Marker "> // #[regen=yes,id=DCE.4C30BCAA-9D8D-2473-35A2-FD0A9A5724E2] // </editor-fold>
I'll try to find a simple solution.
I think it could make sense to go along the lines of the VS approach than NetBeans because that approach is pretty simple. It has been a while, but if I recall correctly they support something like this: #region <text of label to be shown over region> ... code ... #endregion I actually like the use of the "#" because it's reminiscent of a C/C++ preprocessor directive. I think of this as a sort of "tool directive" that tells the editor what to do, instead of telling a preprocessor what to do. Mid 2003 I tried to push the JSR175 folks a bit on this in case annotation syntax was a good approach to this, but that's probably not feasible anymore because annotations can't be put in arbitrary locations (message inserted below for reference). Regarding NetBeans use of specifying some kind of image descriptor or whatever "UML Marker" means, which I also allude to in the message below, I'm not sure if there's a strong enough use case there and that could overload the editor gutter with images. So maybe something as simple as the following could work? // #fold-start <my first folded region> ... code ... // #fold-end Which would be rendered with the usual "+" and a box that says [my first folded region]. The "#" could also be turned into an "@" so that this looked more familiar in Java code and could have Javadoc tag style completions ------------------------------ -----Original Message----- Sent: Thursday, November 06, 2003 11:58 PM Subject: jsr175 and the #region hack I like VisualStudio's #region hack and want to see a similar capability in Eclipse for Java and AspectJ code. The JDT folks are quite interested in matching this feature of C#/VS.NET. They're working on implementing folding (should be working for blocks by February). But there's not obvious way to force a folded region in Java. At OOPSLA I brainstormed this with Kai, the editor guy, but the only reasonable thing we came up with do is stick the folding directive into a comment (blah). Could it be a jsr175 style annotation instead? E.g. public static void main(String[] args) { JFrame figureFrame = new JFrame("Figure Editor"); panel = new FigurePanel(); @FoldRegion("setup the frame") // equivalent to #region <comment> figureFrame.setContentPane(panel); figureFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); figureFrame.pack(); figureFrame.setVisible(true); @EndRegion() // equivalent to #region } I actually like the annotation more than the preprocessor directive style, and it would let us play with other rendering directives (now you see why I'm interested). But would this mean that you guys have to loosen where annotations are allowed to be declared? I don't know what alternatives others have considered, but if this makes sense I'm tempted to suggest to the JDT guys that they ask the JSR175 expert group for it. Mik
>Could it be a jsr175 style annotation instead? E.g. We also need to support projects that write code below 1.5. We shouldn't restrict the solution to 1.5 and higher and adding two solutions seems overkill.
(In reply to comment #11) > >Could it be a jsr175 style annotation instead? E.g. > We also need to support projects that write code below 1.5. We shouldn't > restrict the solution to 1.5 and higher and adding two solutions seems > overkill. I agree to Daniel, this solution should be 1) Totally version independent. I think most professional projects are still 1.4, so there is no chance for Annotations. I also prefer 1.5, but the reality looks different. 2) Annotations are also bad because they're tight to the Java syntax. Regions should be independent from Java declarations. 3) No preprocessor directive, we aren't living in our own fairy tale were we can easily establish our own syntax. I suggest (and implemented) this: This: class { + // <region title="Hello World"> //int oldStuff; /* * Bla bla bla */ int x; // </region> } Collapses to this: class { - [Hello World] } I will add this feature as a patch later this day. To push the discussion further and that we have something to discuss and develop into a final solution.
Using XML-like syntax like "<region title="Hello World">" could cause trouble when Java7 allows to write XML code inside .java files. I suggest to use similar syntax as we already use for non-nls'ed code, e.g.: //$REGION Custom Title goes here$ and //$REGION-END$ And optionally a + to indicate being folded per default: //$REGION+ Custom title goes here$ //$REGION-END$ The question remains how to deal with nesting, especially how fault tolerant the folding structure provider is when the code has unbalanced tags. Also, the current projection framework doesn't offer good support to fold away a complete region and then replace it with your own text. I suggest to simply collapse it into the existing first line: //$REGION+ Custom title goes here$
Created attachment 89634 [details] Proposal implementation - Part 1 fo 3: jdt.core
Created attachment 89635 [details] Proposal implementation - Part 2 fo 3: jdt.ui
Created attachment 89636 [details] Proposal implementation - Part 3 fo 3: jface.text This is my proposal implementation. It's not cleaned up, some variable names could be refactored, javadoc must be added, etc. A known bug is the extreme jumpy behavior if you add/remove regions, all regions get expanded or may collapse if you add/remove a region tag. But that's due to the raw state of the work and no real problem. Please Ignore that and make instead comments to general pattern of the code. The places where and how it's implemented, since there are many different possibilities which make all more or less sense.
(In reply to comment #13) > Using XML-like syntax like "<region title="Hello World">" could cause trouble > when Java7 allows to write XML code inside .java files. I don't see a problem there, since this Java 7 draft it's not about xml in the comments, but directly in the source code. > I suggest to use similar syntax as we already use for non-nls'ed code, e.g.: > //$REGION Custom Title goes here$ and //$REGION-END$ I have a problem with that, it's that it's so similar to the $NLS code. These tags are intentionally unremarkable, they are just little hints, but regions are much mightier; while they might not affect the code itself they allow to fold away thousands of lines. They have a very heavy effect on the visible appearance of the code, and so they should also appear very prominent and remarkable. And not as some visually unimportant annotations. > And optionally a + to indicate being folded per default: > //$REGION+ Custom title goes here$ //$REGION-END$ That's another point where xml wise writing has advantages, you can later easily enhance the tags with other attributes. Which may end up in this: <region title="Addition" folded="true" color="blue" category="math"...> I think this xml wise writing is much cleaner and easier to read than these $NLS tag annotations which always appear a little bit more "hackier". > The question remains how to deal with nesting, especially how fault tolerant > the folding structure provider is when the code has unbalanced tags. The Visual Studios guys made a very convenient solution: every old region tag holds it old folding state, and new ones are ignored until they are failure free (OK, thats not all, further questions are: how to deal with illegal java code which regions intersect with the self defined regions, etc.). > Also, the current projection framework doesn't offer good support to fold away > a complete region and then replace it with your own text. I suggest to simply > collapse it into the existing first line: > //$REGION+ Custom title goes here$ I really don't want to stay away from this "full-collapse" solution because of the incapabilities of the API, it looks much clearer and easier to read, which is BTW the absolute final target of all of this (!), if you have regions which just consistent out of the framed regions titles. It may not make such a big difference when you just think about it, but if you see it for real, you will likely change your mind. I will post a screenshot of my actual and working solution. No Photoshop trick, no special prepared rare "it works" moment; I mean, although I "cheated" and just overpainted the old text, it works very very well.
Created attachment 89641 [details] Folding screenshot of the proposal implementation
We don't want those folded regions to look different than the other folded code. Especially not that it looks like a linked region. What about performance? >> Using XML-like syntax like "<region title="Hello World">" could cause trouble >> when Java7 allows to write XML code inside .java files. >I don't see a problem there, since this Java 7 draft it's not about xml in the >comments, but directly in the source code. Fair enough.
Created attachment 89669 [details] Screenshot with another color style > We don't want those folded regions to look different than the other folded > code. Why not, it's very special, especially when you think about the possible (likely) future development of this regions. For me this is an absolute must-have feature. It makes the code _much_ more readable. > Especially not that it looks like a linked region. That's really a problem. While I have no problems with that, I think I belong to a minority of users who share this opinion. I investigated in the problem and found a few solutions which might work or not: - A background pattern. Any pattern that differs really visible from a plain colored background makes it really harder to read the text. Out of question. - A colored background. Makes always the impression of a selection, bad idea. - A thicker, very different colored frame. Doesn't make the text harder to read and can be quickly drawn. So I tried it, with light green colors. You can view the result in the attachment. I know the colors need a bit more fine tuning, they are still to bright and intensive, but there is no linked region action which produces a frame which is comparable to that! > What about performance? That's a good question. But I think it could be a fulfilling solution till jface has been updated. It are maybe up to around 5 white uniform colored blocks on screen at the same time, that isn't totally cheap but shouldn't be too expensive.
(In reply to comment #19) > We don't want those folded regions to look different than the other folded code. +1 for this, and a visually quiet gray box.
Created attachment 89715 [details] Example of folding Visual Studio (In reply to comment #21) > (In reply to comment #19) > > We don't want those folded regions to look different than the other folded code. > > +1 for this, and a visually quiet gray box. Please open your mind a little bit, it has really advantages. I give you an example screenshot of Visual Studio with collapsed regions, and simple folded code. It looks as in my first draft. While it may mean nothing to you what VS does, here are some arguments you should think about: - I never heard any VS user that he complained about this feature, and wished it were in any way different. All seem to be very happy with the way it is. - This feature request was mostly created from users who wished they had the region feature of VS in their Eclipse. And I think many users are just like me, and the first thing they miss, when they switch between these two IDEs, are VS regions. Look also at the many duplicate bug requests for this feature. And remember that not everyone who wishes this feature mentions VS, because he fears childish religious "not-invented-here", "it's from M$" fights, which are totally anti-productive. - These regions are special, and different, regions are used to collapse thousands of code-lines with maybe 50 methods at once. And they have titles! A feature no other collapsed region have. They just should not, they _must_ look different. You also write constant variables every time this way: "int COLOR_GREEN", although it would be more convenient to write just "int colorGreen" like you usually write variables.
I forgot to mention a thing about the patches: new features in public interfaces (I think it's just one), will be extracted and moved to an child interface. That's just temporary while it's in development state, API consistency will be kept, of course!
IMHO it should look consistent with the way we fold now. That is a folded custom region would look like this: (+) //<region "FooBarRegion">[..] Maybe: (+) //FooBarRegion[..] Just my 2 cents...
Sorry, but if you want this patch to have a chance being accepted you'll have to make it look like the other folding regions and not like linked mode. Also, first step would be to move this to JDT Core and ask whether they would consider adding this.
(In reply to comment #25) > Sorry, but if you want this patch to have a chance being accepted you'll have > to make it look like the other folding regions and not like linked mode. > > Also, first step would be to move this to JDT Core and ask whether they would > consider adding this. Well, moving: yes! But can't this only a committer do? To whom should I email about this?
>Well, moving: yes! But can't this only a committer do? >To whom should I email about this? You mean re: moving the bug?
(In reply to comment #27) > >Well, moving: yes! But can't this only a committer do? > >To whom should I email about this? > You mean re: moving the bug? Moving the component category, like you said: (In reply to comment #25) > Also, first step would be to move this to JDT Core... If this questions & answers goes further, shouldn't we meet in chat (irc.freenode.net #eclipse-dev)? I fear we're clogging the bug-entry with this formalities. I'm new to this and don't know all steps in all details about bringing in new enhancements.
Moving to JDT Core to decide whether they want to add those region semantics. Discussing here is fine as others that aren't online can follow.
I have a question about the JavaOutlinePage, the JavaOutlinePage uses as ITreeContentProvider the nested class ChildrenProvider, this class uses as content type the interface IJavaElement, and with that a dozen classes which implement this interface. If we introduce regions they should be shown also in the Outline View (of course optionally), but that would mean I have to introduce my own class which implements IJavaElement (and ISourceReference) and wraps the original, actual IJavaElement (and ISourceReference). And additionally I must go into the code of all the helper classes (which aren't just a few lines), and change the typecasting calls for the IJavaElement, where the IJavaElement is typecasted to IMethod or similar (if IJavaElement#getJavaElementType() returned the corresponding type). So that they typecast the element they get when they call #getIJavaElement() (or better handle the result of #getIJavaIElement() from the beginning) or show the right labels and icons if they find out that the IJavaElement is actually a region. This is a big change, and there are many different ways to implement it in all its details, what I would like to get is an answer of someone from the JDT-Core team, who has a vision how something like this should be implemented.
I would like to add my few cents here. I'm a frequent VS user and custom regions are essential when working on code longer than 50 lines. But if you decide to add then to Eclipse than you have to do it right. What I mean by 'right': - regions have to have a label\caption (folding screenshot is perfect IMHO), - regions should have tree-like structure (I should be able to put nested regions inside other regions) - I should be able to surround any piece of code with a region (it can be 50 methods or it can be 50 lines inside 200-line method) I also think, that regions should not be included in an outline structure or (preferably) should have dedicated region structure.
(In reply to comment #31) > - regions have to have a label\caption (folding screenshot is perfect IMHO), I would never deny that ;-) > - regions should have tree-like structure (I should be able to put nested > regions inside other regions) > - I should be able to surround any piece of code with a region (it can be 50 > methods or it can be 50 lines inside 200-line method) Already done in the patches. :-) > I also think, that regions should not be included in an outline structure or > (preferably) should have dedicated region structure. No opinion on that, I will do what the majority wants. Both positions have pros & contras.
To everybody: if you are interested in this patch, could you vote for it? Thanks :-)
Any updates on this issue? I mean, everywhere I look I see developers, missing good code folding in Eclipse. What can we do besides voting for this bug/fix? Jan-Hendrik's patch looks great, it must make it into an Eclipse release.
>3) No preprocessor directive, we aren't living in our own fairy tale were we >can easily establish our own syntax. although i agree with you that it is reasonable NOT to create a new preprocessor directive out of logical reasons i still think it would make sense to ALSO support the preprocessor code folding the same way like at least one other major IDE does! imagine now, all major IDEs (except eclipse) are supporting custom code folding, but everybody has its own approach: in visual studio you have "#region / #endregion" in C#, "#pragma region / #pragma endregion" in C++, in netbeans you have the already quoted syntax, and in Code::Blocks you have "///{ / ///}". in a project where multipe IDE's are used (by the different developers involved all working on the same project) like we have it in our company, i can immediately see who is using which IDE by looking at the custom code folding code! you CAN do a workaround in some IDEs by example by defining region blocks in c++ projects like this #pragma region regionName ///{ //some code to be folded #pragma endregion ///} this will then work in Code::Blocks as well as in Visual Studio..... what i am saying is that eclipses code folding should be: * either so generic that you can set your own syntax for code folding * or be able to integrate well into other code folding styles like code::blocks custom code blocks do with the one of other IDEs * or at least use the same approach that another major IDE does, most probably netbeans then. however it is implemented, even if eclipse will do its own implementation of custom code folding, it will be improving eclipse big time. i am gladly voting for this bug, this is really something that i miss since i began working on eclipse coming from visual studio! so any news on this? whats the status?
(In reply to comment #35) > so any news on this? whats the status? I think the responsible Eclipse team still isn't thinking that it's worth the effort. Think about maintenance, that adds to a sensible implementation. Although it should be a small and easy maintainable patch. But with each vote we're moving further towards an actual implementation. With 17 votes we moved really a big step! There are only 41 Bugs which have the same or equal votes - and 1956 Bugs if you search for >= 1 vote! If this bug reaches 20 votes it's finally something they can't ignore anymore. I think they will accept then that it's really something that is wanted by a majority of people, a "Should have" feature. I fear most of them still think it's a "Nice to have" feature. If you use this scale in project-management (a very common scale): 1. Must have 2. Should have 3. Nice to have 4. Nice to have if we have much time / people left (always a rare resource in Eclipse) We started at (4), and now we are very close to (2). Please, keep on voting.
Note that there's an extension point to contribute your own folding provider (if it doesn't change the existing code) i.e. you could distribute your custom folding(s) in a separate plug-in. Having said that, we don't plan to add this in the near future.
(In reply to comment #37) > Note that there's an extension point to contribute your own folding provider > (if it doesn't change the existing code) i.e. you could distribute your custom > folding(s) in a separate plug-in. Having said that, we don't plan to add this > in the near future. But what we want is a solution which is right inside Eclipse. The external solutions have often bugs and always lag behind Eclipse releases. There are also too overfilled with features. There is also no big company behind a solution. If the responsible developer just decides to stop his plugin because his kids get born, or whatever, development stops, and the plugin becomes unusable with the latest Eclipse releases and it's new Java 6,7,8... language features. We just want a small builtin code-folding, right out-of-the-box, which is maintained, kept into Eclipse, and developed together with it's features. !!!!!!!!!!!!!!!!!!!!!!Very important!!!!!!!!!!!!!!!!!!!!!! The biggest problem is the syntax. Every developer has his own best solution how to write it. If you don't provide a straight, tight, clear line, every plugin will be unusable with all the others. So, at least, you should provide us all a clear straight syntax, that you will support in the feature, if you finally implement it. Think of it as if you invent a new XML structure: compact, good readable and extensible.
Sure, but as you just mentioned correctly, the feature doesn't come for free and will need maintenance in the future and at this point this is not something we will invest. If people really really want this then it should be easy to find a big company or an university that hosts this and if/once the plug-in gets stable and used/loved by many developers we can discuss adopting it inside Eclipse.
(In reply to comment #38) Then come back to the syntax I talked about in Comment #36. What about that? If you give an official line at least the plugins Syntax will be compatible between each other. Then every coder want to make his plugin engaging like a charm in the future implementation of Eclipse. And it will, if they follow the official Syntax.
(In reply to comment #40) > (In reply to comment #38) > Then come back to the syntax I talked about in Comment #36. Sorry: Meant Comment #38.
>Syntax will be compatible between each other. Developing that syntax through various iterations is exactly what that plug-in would have to do. Eventually, the start/end tags even need to be configurable.
(In reply to comment #42) > Developing that syntax through various iterations is exactly what that plug-in > would have to do. Eventually, the start/end tags even need to be configurable. Well, I must answer to this: __no__! You would have no common definition, and everyone who reads the file without the knowledge of the fitting code-folding syntax, and the fitting code-folding plugin, don't understands the documentation, (which a good declared code-folding automatically does by itself). Because there are thousands of different definitions. If finally one emerges, many file content renamer tools will have to be written. It's like the browser wars between IE and Netscape, but worse. It would be, if there is an IE Syntax like this: <begin><caption>bla</caption></begin><main>...</main> and the corresponding Netscape would be: <head><title>bla</title></head><body>...</body>. And then there were another 3 different Web-Browsers, each with it's own definition. It would be really great if there would be a clear line, direct from the beginning. Like XML, DTD, XSD, ..., which had great success, BTW.
(In reply to comment #43) then maybe some presets of possible code-folding-styles would be appropriate, thus avoiding the described uncontrolled growth but providing certain flexibility at the same time?
(In reply to comment #44) > then maybe some presets of possible code-folding-styles would be appropriate, > thus avoiding the described uncontrolled growth but providing certain > flexibility at the same time? Of course, a XSD would be warmly welcome, and happily embraced. Maybe something like this: <xs:element name="region"> <xs:complexType> <xs:attribute name="title" use="required" type="xs:string"/> <xs:attribute name="color" use="optional" type="xs:hexBinary"/> <xs:attribute name="category" use="optional" type="xs:IDREF"/> </xs:complexType> </xs:element>
(In reply to comment #45) Since, this doesn't seem to get any further I suggest to everybody to implement the far superior implementation of Codefolding in Netbeans - or start using Netbeans if the feature is important for you. In Netbeans: // <editor-fold defaultstate="collapsed" desc="${DESCRIPTION}"> ${selection line}${cursor} // </editor-fold> Corresponding XSD could be: <xs:element name="editor-fold"> <xs:complexType> <xs:attribute name="desc" use="required" type="xs:string"/> <xs:attribute name="defaultstate" use="optional" type="xs:string"/> </xs:complexType> </xs:element>
(In reply to comment #46) Sorry if the last comment came to aggressive to some people. Don't wanted to rant against someone.
(In reply to comment #46) > (In reply to comment #45) > Since, this doesn't seem to get any further I suggest to everybody to implement > the far superior implementation of Codefolding in Netbeans - or start using > Netbeans if the feature is important for you. I saw a very good implementation by you, Jan-Hendrik. Do you think it may be possible that you make a plug-in out of that? You surely invested some time, getting the patch done for eclipse, maybe that one can make it as a plugin, that would be great.
(In reply to comment #48) > I saw a very good implementation by you, Jan-Hendrik. Do you think it may be > possible that you make a plug-in out of that? You surely invested some time, > getting the patch done for eclipse, maybe that one can make it as a plugin, > that would be great. Well, actually the current implementation is more a draft, as discussion base. It has bugs I'm aware of, I made a better implementation but realized that it would be the best if the whole default code folding would be rewritten (mine still has flaws). I have currently no time for that, and if I have the time later, I can't support it continuously. It must be a company or university which cares for such a plugin, or, as best solution, the Eclipse foundation. There is actually already a code folding plugin at http://code.google.com/p/coffee-bytes/. But from my view it's too cramped with unnecessary stuff. It cares about the code folding of every single for/do/while-loop. Custom titled regions is actually a feature which was added later, and seems to be a "nice have feature" at this project, but nothing essential. While I could accept that (although I don't appreciate it), the problem is, that currently nobody cares about the project. Last actions seem to have happend in 2007, and there are heavy bugs which haven't been touched for now 2 years! That's exactly what I'm talking about! If this isn't inside Eclipse, and the Eclipse coders _must_ care, nobody will in the end. Even if it's a company thing, it may drop it after 6 months, ignoring all the unsolved issues. But at least a company has the highest potential to establish a plugin that gets inside Eclipse, so keep on voting, maybe a company can be attracted to it, and if it's get included, we even might reach the higher level of Netbeans/Visual Studio code-folding.
Talking with Dani, it feels like JDT/Core could surface some region information in its models (JavaModel, DOM AST) for that purpose. The overhead should be small given it scans comments already anyway. Now, once we know the regions there is quite some work to leverage this feature across the JDT stack, including (but not limited to): - editor code folding (as already figured in this bug) - silencing warnings in some code regions (think generated code) - hide some search matches in some regions - codeassist may also treat these region contents as less relevant - etc... For 3.5, we (JDT/Core) could agree on the low level support: compiler and models, providing we get some sign-up from external contributions on the leveraging. Given I see patches attached already, is this a fair expectation ?
tentatively for 3.5M5
(In reply to comment #50) > Talking with Dani, it feels like JDT/Core could surface some region information > in its models (JavaModel, DOM AST) for that purpose. The overhead should be > small given it scans comments already anyway. > > Now, once we know the regions there is quite some work to leverage this feature > across the JDT stack, including (but not limited to): > - editor code folding (as already figured in this bug) > - silencing warnings in some code regions (think generated code) > - hide some search matches in some regions > - codeassist may also treat these region contents as less relevant > - etc... > > For 3.5, we (JDT/Core) could agree on the low level support: compiler and > models, providing we get some sign-up from external contributions on the > leveraging. > Given I see patches attached already, is this a fair expectation ? I am willing to help, sir. But what do you expect exactly? It's clear that the DefaultJavaFoldingStructureProvider class should be widely rewritten, also the Scanner class and PublicScanner class should be extended with a region tag scan. I did already the scanner part, in that way that I added extra separated methods to the scanner classes, which can be used by a call to a single public method (#readRegions()). But I think you want them more integrated, even if it's a feature which can be switched off, don't you? About the JavaModel DOM AST: You mean, you would really like to change the document editor code itself? Like, changing the binary tree which represents the document content? I don't really think so, but on the next level above that, right? Sorry, but it has been months where I last looked at it, can you tell me which file(s) you mean? I'm willing to help, but more exact information would be helpful.
Now that we have sort of a 'go', I think the first thing to do is to define the syntax that fits our needs. Here are my requirements and others might have additional ones: - human readable (as non-Eclipse users might read that code) - have a caption - allow nesting - allow to define different folding types (aka kinds or categories) - define whether folded per default or not - allow to add custom attributes Of course for the scanner it should be - unambiguous - easy/fast to scan Maybe we should arrange a meeting to discuss this? > It's clear that the >DefaultJavaFoldingStructureProvider class should be widely rewritten Do you mean to support this or do you have concrete improvements for the existing code?
(In reply to comment #53) Megert's Requirements: > - human readable (as non-Eclipse users might read that code) Either my suggestion or Netbeans. My suggestion is more C# wise, Netbeans is likely much better known in the Java world. Also I think the Netbeans people are cooperative enough to agree if we later come with new enhancement suggestions. > - have a caption Fits to both suggestions. > - allow nesting I think this is a must have feature. > - allow to define different folding types (aka kinds or categories) Agreed. I already suggested that in comment #45. > - define whether folded per default or not Netbeans has that already, I suggest we copy that. > - allow to add custom attributes The C# and the Netbeans suggestions both use XML syntax, no problem there. > Of course for the scanner it should be > - unambiguous > - easy/fast to scan > Maybe we should arrange a meeting to discuss this? An IRC meeting on irc.freenode.net? Gladly. Chat to me on #eclipse-dev, to "NotAvailable". > > It's clear that the > >DefaultJavaFoldingStructureProvider class should be widely rewritten > Do you mean to support this or do you have concrete improvements for the > existing code? Let me clear my inexact statement a little bit. As I worked on an updated Version I had problems with the way how the annotations (folding points) were handled. In the end the whole class is centered around instances of IJavaElement's. But these custom defined regions are definetely no Java elements. They were, will, and never should be Java elements. They can be outside of all Java elements. You have to write ugly wrapper dummy classes for them, and must treat them as real IJavaElement instances. Not very nice. More hacking than good coding, because IJavaElement is spread all over the whole file.
re: DefaultJavaFoldingStructureProvider I see. Originally there was no AST (nodes) from the reconcile/java model delta and most folding points were Java elements. The new custom regions will hopefully be in the AST and hence the whole code be rewritten to be AST-based. >> Maybe we should arrange a meeting to discuss this? >An IRC meeting on irc.freenode.net? Gladly. Chat to me on #eclipse-dev, to >"NotAvailable". Or we setup a call.
To be assessed for M3. We then decide if this stay on the plan for 3.5.
Created attachment 113021 [details] Latest version of modifications at: jdt.core Here is the latest version of my modifications for jdt.core. I tested the option to disallow same titled regions which are at the same nesting level. I think we should discuss that, that region titles must be unique if they are in the same nesting level. That modification can be easily removed, it's at line 775 in Scanner.java, at the "NONE_UNIQUE_TITLE" variable, and at the line 758 in PublicScanner.java also at the "NONE_UNIQUE_TITLE" variable.
Sure, first the jdt.core part must be done. But I think we can discuss the UI part features now, and discuss the specific implementation parts later, after we know how to base it on top of jdt.core - the concepts itself will stay the same. The following suggestions are all "should have features", all "must have features" were already discussed in the earlier comments: 1) There should be the possibility to move selected text to a specific region, via context menu. So, that you mark java code, open the context menu, go to "Regions | Region target list | Move to $ListEntry", and the text is moved to the end of that region, so that you can refactorize your sourcecode fast and easy. 2) This builds on top of suggestion (1). It should be possible to mark a specific region as your favorite region, which appears then as target region in the context menu _root_ for selected text, so that you can move all your sourcecode quick and easily with 2 mouse-clicks to that region. Just imagine you have sourcecode parts of one big theme scattered all over your file, you want to move them to a specific region. So you mark that region as your favorite, so now you can rush through your source file, and with one "mark, click, click" you clear up the whole file at one big swoop. The context menu should look like this: "Move to region $Favorite". 3) The Outline View should have an option to show a list of regions, and what methods and other regions they are encapsulating, in a tree view like the usual Outline View. (This last feature is more a "nice to have feature") 4) There should be the option (opt-in) to mark the regions starts and ends even when the are expanded. Only when you click exactly on that line, the title disappears and the original XML comment comes out. That has the advantage, that you still see easily in which region you are when you scroll through the sourcecode with many expanded regions. That could look like this: ============= { Region x, calculate z } ================ ... code ... -------------------------------------------------------- I think we can agree that these regions markers should only be possible if they are: - In a single line comment (//) - Stand alone So there should be no problem that these drawings are hiding something. I suggest to have this option as an opt-in option, because new users may be irritated by it, while experienced users will really welcome it. Other things may be helpful, but I think these are the most important. They will complete the package, and make it really useful. As already said, most people who use custom titled regions, almost never seem to use simple codefolding, that shows how important it is to make a feature really sophisticated before it comes actually useful.
I'm interested: how is the current state of this enhancement at the IBM Eclipse developers? Is it already worked on, or still in decision state.
Sorry, we ran out of time for M3. Deferring to M4.
re: comment 57 1. Glancing through the patch, I have the impression region detection requires an entire scan of the source. Am I mistaken ? I would rather see a solution integrated with comment scanning; and maybe take advantage of this move to unify task detection with fallthrough and regions. 2. Are we sure that there will be a unique way to define a region ? The region tags seem in stone. Experience with TODO tasks is that users wanted to refine the tags used. 3. Is region detection robust to syntax errors ? Does it play well with syntax/statement recovery ?
(In reply to comment #61) > re: comment 57 > 1. Glancing through the patch, I have the impression region detection requires > an entire scan of the source. Am I mistaken ? I would rather see a solution > integrated with comment scanning; and maybe take advantage of this move to > unify task detection with fallthrough and regions. I had the solution integrated at first (which can be done again easily), but I run into a problem. IIRC the problem was that the scanning of the source code was aborted when there was a big flaw in it. But the regions should be independent from the source code. So that regions don't vanish after illegal sourcecode like: "int a = <html><body>>>..." (Copy-Paste-Error, whatever...). They must stay, and wrap e.g. different stuff after the end of the class declaration. > 2. Are we sure that there will be a unique way to define a region ? The region > tags seem in stone. Experience with TODO tasks is that users wanted to refine > the tags used. It totally should be in stone, the regions would be more like the @Override annotation, were also never happened to be a movement to change the name of the @Override annotation, which works also not only as a syntax check, but also as a documentation. And we talked already about that: The region definitions must also work as a documentation, when everybody comes up with its own javadoc, there will be no universal understanding. TODO's are more for private todo lists, regions are also for public released 100% polished code that you present to the world, so that everybody can see and benefit from it. So it's also a javadoc, not only code management. > 3. Is region detection robust to syntax errors ? Does it play well with > syntax/statement recovery ? That's an interesting problem, and must be developed together with the new folding provider. So that wrong typed regions or new introduced regions don't intersect with existing regions, and therefore already existing regions don't start to automatically collapse/expand them selfs. For example, everybody knows the failures which happen when you work on deep nested "if" expressions, and you aren't still finished with the work on different nested "if" expressions, or accidentally made a bracket to much or few. It shouldn't be hard to solve, but it must be done together with the new folding provider.
>> 3. Is region detection robust to syntax errors ? Does it play well with >> syntax/statement recovery ? >That's an interesting problem, and must be developed together with the new >folding provider. This must not be tied together. JDT Core will have to generate the regions so that any clients can consume them without harm.
(In reply to comment #63) > >> 3. Is region detection robust to syntax errors ? Does it play well with > >> syntax/statement recovery ? > >That's an interesting problem, and must be developed together with the new > >folding provider. > This must not be tied together. JDT Core will have to generate the regions so > that any clients can consume them without harm. I explained it wrong: not tied together. But developed together, so you can see how the implementation in the scanner must be, so that an arbitrary client can work with it.
No progress was made for M4
(In reply to comment #65) > No progress was made for M4 To make it clear: no new patch was provided after Philippe's feedback (comment 61). As said in comment 56, this item was not assessed in time so it has to be removed from 3.5.
I'm new to that thread, but why don't use the old Origami style with that 3 brackets? This not so space consuming and there must exist a lot of code already, e.g. // {{{ some code // }}}
*** Bug 315742 has been marked as a duplicate of this bug. ***
What is the status of this at Helios ? I am much for the Netbeans solution - actually is sorely missed now that I try Eclipse - the Vim solution needs manually changing number of lines which does not seem convenient and the #regions one lacks the automatic folding which is really needed : // <editor-fold defaultstate="collapsed" desc="${DESCRIPTION}"> ${selection line}${cursor} // </editor-fold> +1 Notice default state and the position of the cursor This becomes : +Description Also this should be implemented as a "surround with editor fold" option as in netbeans. It is *really* convenient. Please change this Platform : All. Also a couple other bugs are possible duplicates - I have marked them as such in their comments - no "Mark as a possible duplicate" option in Bugzilla ?
(In reply to comment #69) > What is the status of this at Helios ? No work was done or is currently planned for the next release (3.8/Juno).
(In reply to comment #70) > No work was done or is currently planned for the next release (3.8/Juno). Hmm - please reconsider. see also : https://bugs.eclipse.org/bugs/show_bug.cgi?id=169098 https://bugs.eclipse.org/bugs/show_bug.cgi?id=173796
> see also : > https://bugs.eclipse.org/bugs/show_bug.cgi?id=169098 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=173796 Code folding depends on the language and there's currently no framework support for that besides documents and viewers that allow projections.
(In reply to comment #72) > Code folding depends on the language You mean the initial comment character ? Like // in C++ and Java ? Then probably implement it in those languages It is really missed from netbeans
(In reply to comment #73) > (In reply to comment #72) > > Code folding depends on the language > You mean the initial comment character ? > Like // in C++ and Java ? > Then probably implement it in those languages > It is really missed from netbeans It's a different setup altogether over in our XML/HTML/JSP editors, but I suppose JavaScript would be similar enough that it could borrow most of a JDT solution.
Please add this for Java at least. Other languages can be supported in time. It's the one thing that really annoys me about Eclipse and keeps me from using it more.
Java and C/C++ please (//) Just noticed this is around since 2004 :whistling:
Hello from 2017. 13 years and this issue is STILL around. As far as I know, all plugins which attempted to do this (basically very simple feature) are deprecated, unsupported and stopped working a long while ago. I would highly appreciate this feature, at least for Java/JDT. In other languages, such regions are even part of the language itself (see #region in C#).
