Community
Participate
Working Groups
1. Collapse function should be able to collapse block of code between "{" and "}" into a single line looking something like "{ ... }", displayed in different color or style. 2. As an addition to bracket matching, there should a way to display an vertical line starting just under opening "{" going all the way down to matching closing "}", if one exists. This should be configurable in terms of color and turning on/off. 3. For the comments, there should be a button which would either display the comments or hide them. When hidden, special marker would be displayed one character space left from where the comments were and this marker should take only one character space, or none if possible. It should be like the comments in MS Excel. 4. When 3. combined with 1., there should be another configuration item, that would turn on/off displaying comments in collapsed block of code. This would make handling large/complex pieces of code much easier. If code can be also printed as it is displayed, it would be great.
this feature is on our feature list but unfortunately not for 2.0 - deferring for now
Reopening for 2.1 consideration
*** Bug 21514 has been marked as a duplicate of this bug. ***
5. How about the ability to fold expanded CVS keywords? That way, if other developers like to expand CVS keywords, and I don't want to see them (particularly the Log keyword), our line numbers will still correspond.
*** Bug 36161 has been marked as a duplicate of this bug. ***
Don't forget folding of the import statements
There's some overlap with bug 37671 (especially regarding collapsing of sections).
If folding were to be added, I think it would be great to expose an API that allows for even more fine-tuned folding (at the line level). This would be very useful for a research project I'm working on. Pasting in my newsgroup comments to this effect below: For example, we'd ideally like to be able to take code that looks like this: int foo(int a) { int someVar; int someOtherVar; someVar = a; someOtherVar = globalV; if (someVar == 10) { someOtherVar++; for (int i = 0; i < 5; i++) { cout << i << endl; } someVar -= 5; } return someVar; } And then if we wanted to focus only on lines that affected "someVar," for instance, we could use folding to display this in the editor: int foo(int a) { int someVar; + ... if (someVar == 10) { + ... someVar -= 5; } return someVar; } But when this is displayed in the editor, the line numbers reflect the real line numbers in the full source code, etc. The plus signs might be clickable to allow the user to reveal the elided code.
A basic 'hide/show' lines capability would be wonderful, since it would allow the old XEDIT/KEDIT commands of "ALL" and "SPREAD" to be built. "ALL" takes a search target, and only shows lines that contain that string. "SPREAD" shows you context around 'shown' lines, either based on a # (# of lines), or another search target. I use this kind of capability as a search mechanism. Rather than searching for something, I do an "ALL" on it, so I can see all the lines at once. Those of you lucky enough to have access to a VM/CMS box (eh hem!) can try running the command HELP XEDIT ALL to get more info on this ... the ALL command is just really a macro that modifies the 'SELECT' level of lines, and the 'DISPLAY' setting which indicates which 'SELECT' level to display.
*** Bug 41104 has been marked as a duplicate of this bug. ***
I suggest to take a look at Visual Studio .NET expand/collapse funcionality. I don't find useful the idea of hidding single lines instead of code blocks (or 'import blocks' or 'comment blocks'...) as Will and Patrick suggest.
*** Bug 41573 has been marked as a duplicate of this bug. ***
*** Bug 13855 has been marked as a duplicate of this bug. ***
Another (complimentary) approach to code folding... Code folding in programmers' editors is normally implemented in terms of folding away the contents of a method, class, etc. Another way to implement the same feature would be to allow the programmer to define keywords in her comments similar to the task tag feature. Each different task tag specifies an outline level similar to "<h1>", "<h2>", etc., in HTML. Then you can have an outline view of your source code where the outline header comments become expandable/collapsable outline nodes and the source code becomes the supporting body text. Dragging the outline headers would then move the accompanying source code similar to the way the same feature operates inside a word processor. There should probably be a standard way (probably in a comment at the top) for each compilation unit to specify the commenting conventions it uses so that different programmers aren't forced to use the same identical set of outline tag conventions. The result of this would be that it would be much easier and faster to come to a quick understanding of well-written/commented code.
*** Bug 41648 has been marked as a duplicate of this bug. ***
Responding to Guido, I just want to point out that the two approaches really are compatible, and it's just a matter of which interfaces you'd like to expose. Folding comment blocks, import statements, etc. is a (very useful) special case of folding individual lines. I completely agree that end-users writing code with Eclipse will mostly be interested in the block-level folding that Guido mentions, and I think those are the options that should be readily available to them. But at some point you'll have to implement the functionality to hide individual lines (to support the block-level folding), and I think this line-level folding functionality should be exposed in an API that plugin authors can use. The code would already be there, and it wouldn't add that many additional functions to the API.
*** Bug 41911 has been marked as a duplicate of this bug. ***
It would also be nice if the new Eclipse code collapse feature could support user defined regions like in Visual Studio .NET I.e. in C# #region Description ...code... #endregion results in a user defined portion of the code that can be individually collapsed. I find this feature especially useful in conjunction with autogenerated code. A similar feature could also be implemented for Java. Obviously the #region and #endregion directives won't cut it in Java, but I think something like: // region Description ...code... // endregion could do the trick.
Here's another use-case for this enhancement. I'd like to use this support in an editor for the SAS language. There is an editor written in C that works as follows that we'd like to mimic in the Java version: Expanded: 1 - data x; 2 do i=1 to 1000; 3 output; 4 end; 5 run; ____________________________________________ 6 /* comment for contents */ 7 - proc contents 8 data=x; 9 run; Collapsed: 1 + data x; ____________________________________________ 7 + proc contents The underscores are my ASCII representation of a thin line the C control draws between foldable sections in the editor. Also note the "-" isn't necessarily on the first line of the foldable section. Line numbers are an option just like in the current text editor. Any attempt to modify text on a collapsed line makes it expand. If you select part of the text on a collapsed line and copy it, you only get the text you selected. However if you select the whole line and do a copy you will get the whole expanded section in the copy buffer.
This really needs to be boosted up in terms of priority. As both a Dot Net and java developer, I am glad to see Eclipse making leaps in bounds, but the folding feature is one of the major hurdles I still see before I use Eclipse as my full time developing environment. A simple folding feature needs to be put into an upcoming Milestone, and later as Lars mentioned, a Region based system like in Visual Studio would be amazing.
As a basic feature for any editor that has an adapter for the outline view, perhaps that could provide a default set of collapse points (naturally, this isn't enough for the java editor, but would probably be helpful for third party editors, like my JScheme plugin).
Raising priority to P2 because this feature request has been in assigned state for over a year with no visible development activity.
We use priorities to manage the PRs. Please use voting or severity to express your opinion.
Tomas Znamenacek had a point, a lot of people have commented on this bug, but nothing has progressed for more than a year.
According to Kai-Uwe, voting or severity should be used to express interest in this feature request. The voting that has been going on for OVER A YEAR did not help at all, so I'm setting the severity to "major", becuase when I compare the usability of Eclipse to usability of the .Net Studio, this is one of the major feature differences... (Major, and one of the first differences people will see, IMO) To all CCs, please provide your input.
Tomas Znamenacek, this is a very critical missing feature and one of the surprises I had when I first ran eclipse, after being asked to port a project over to Java from .NET. Get and Set functions are great for keeping object properties clear and concise, but really stink when you have a very large object class. In dot net, regions save me a TON on editor real-estate.
I would have to agree with the other posters. This is one feature that is truly needed in Eclipse. I would easily rate this in the top 3 features that Eclipse NEEDS.
+1 I think this would be a very useful feature.
+1 It will increase developer productivity dramatically in a single way. Responding to Lars, I think "// region Description" comments or code defined regions (#region/#endregion) are not good ideas. It is a little tricky, isn't it?. That comments have no sense for a NetBeans developer (only an example). I think the code should remain as it is and the funcionality should be as simple as possible.
+1 However, I find the possibility to have user defined regions very interesting. If you're working in a team with NetBean users, fine, just don't use it. If you're an Eclipse only team, it's just great.
If you don't add comments to the source then where is the editor supposed to store its ranges of collapsed lines? Storing them in the metadata files seems like an invitation to sync problems.
Responding to Guido, I think it is perfectly legitimate for the editor to store region info as comments in the source. I also agree with Ed about possible sync. problems if you store it anywhere else. In fact I think that: // REGION description ... // ENDREGION is just as legitimate as // TODO description I used lowercase letters (region and endregion) in my previous posting but I now believe they should be in uppercase (REGION and ENDREGION) just like the TODO feature.
Java already supports named regions. They are called "methods". If you want Eclipse to help you focus on one at a time, click the "show source of selected element only" button in the button row at the top of the Java editing window. I use it and like it. IMO, having foldable {}-surrounded blocks and comments would be nice in case the "methods" get too long (which they tend to do, unforturnately). Having my foldings persisted between editing sessions doesn't seem necessary to me; so as far as I am concerned the persistance problem can be ignored.
But being able to collapse a PORTION of a method is very handy. Being able to collapse, for instance, the catch and finally blocks so you can see the flow of the method is VERY handy. Being able to focus on just the method is fine but what this enhancement is for is to collapse portions of the code that are not necessarily just a method.
To respond to Johan Walles comment, this is a request is for Eclipse enhancement and I expect that the Eclipse team will implement it (as they have done with other functions) in a way that can applied to any text displayed in the Eclipse editor. This means it would be applicable to text like XML, which has no methods.
*** Bug 42360 has been marked as a duplicate of this bug. ***
I'd like to suggest some alternative approach, which can be easier to implement with the existing editors. So, idea is to have another outline that will replicate the code and represented as a tree view. Check the implementation of similar thing for Together - http://w8.platonoff.com/together/folding.gif That new outline should be synchronized with editor and probably have an option to show only currently selected scope (Similary to "Show Source for the selected element only" action).
The implementation should allow for code folding/collapsing within the same editor. Also, the + and - signs (if used by the Eclipse team) should only be visible when lines are already collapsed(showing +) or have been previously collapsed and are now expanded(showing -). There might be a need for two implementation of this feature. One storing the region info dirrectly in the source code in form of comments, and another one, using some metadata files outside of the source code. The reason for the second approach is that it would be very "cool" to be able to make use of this feature for a code that is read only.
Instead of marking regions with comments, you could mark regions similar to how you mark breakpoints and bookmarks. It is less permanant this way, and won't port easily to your co-workers workspace - but then again maybe to them regions are defined differently...
As to the marking the regions the same way as break points, I think the lack of the persistance would be a big disadvantage. It would be nice to see the regions the author of the code has defined in the comments, that way, you might understand the code faster. Anyway, this is only my personal preference, the final design is up to the Eclipse team...(wondering when it will be)
Tomas, I agree. I would add that as with all features, I think it would be nice to allow it both ways. For example, many times I'm trying to make sense of some code, but I'm not going to commit any changes, so there's no real advantage to me marking regions in the actual code. Perhaps it will always be marked as a region in my own workspace, but I'm not going to put my own defined regions like // region 1: "tricky part I want to hide for now" // end region 1 // region 2: Part I understand so far // end region 2
I'm glad to see a boost in the activity for this bug. BTW, did anybody notice this is the second most voted bug for eclipse ? A lot of good things are coming out and I really like the idea to have the ability to collapse the catch/finally blocks together. Maybe an option in Source -> Folding -> Collapse all catch/finally blocks? Just my two cents.
Interesting discussion of this so far. Perhaps I could add a few ideas... I believe that the concept of regions and folding should be implemented at the top edotor level so that it becomes available in all Eclipse text-based editors. It would be up to each type of editor to define what a "region" is. For java, it could be comment blocks, methods, etc. For HTML, it could be TABLE tags. Additionally, each region should have some kind of indentifier that would be unique within a source file. Nested regions could use their parent's identifier as a prefix. (The identifier would be strictly internal and not visible to the user.) For example the code block containing the definition for a class MyClass could be internally named "classMyClass", while a method definition doBusinessLogic for this class could be code named "classMyClass:method-doBusinessLogic". If user-defined regions are implemented, the identifier could be based on the comment following the "//REGION:" keyword (or perhaps a substring of it). It would of course be up to the editor implementation to find and name all the regions in a source file. This allows for the saving of region fold states in a project metadata file, rather than the source file, while still retaining some measure of percistency as code is added and removed, since the regions are not based on line numbers alone. By default, all regions would be expanded, so if a method is renamed in an updated file, or the region comment has changed, the related region will become expanded. Each time the source file is saved or refreshed, information about regions that are no longer relevant would be purged from the metadata file. I believe this to be a solution that will not needlessly polute the source files while still allowing for a lot of functionality to be programmed in on a per-editor basis.
Eclipse team, could you please provide us, the people requesting the feature, with some information on when this feature will be implemented ? (do not let this feature miss another release...)
Eclipse team, would you please inform us about the progress on this feature request ? I have raised the priority and severity because this request is the second most voted for and is over year and a half old.
This item is on our 3.0 plan since I have published the plan in summer. Resetting priority and milestone as priority and milestone are managed by the committers.
The original question by Thomas never got answered. Is this planned for a near Milestone release? What is its progress? Why isn't it a higher priority? If this has been on the plan since Summer, than more information should be available.
it not in Build id: 200310101454 (Version 3) Is it ? Will it ever make it in version 3 ? When? Also I would like to add, that it would be cool to have a "collapse all" and "expand all" option.
+1 like the above postet ( http://w8.platonoff.com/together/folding.gif ) . That would probally be the most convenient elegant way ...
Robert (& CO), I think two different windows (code view and folding code view) with the same code is too complex for such simple thing. Please, take a look at Visual Studio .NET folding capabilities (screenshots at http://www.actiprosoftware.com/Products/DotNet/SyntaxEditor/Outlining.aspx) if you can...
+1 for the dotNet approace
Guido, I agree. No extra FoldingView. By posting that pic again I just wanted to vote for the postion of the [+] and [-] within the texteditor. So that it pays respect to nested structures. I like the idea of having the [+] and [-] right beneath the method/command name. Of course this feature must be disabable (disabable ?) completely. So that no [+] and [-] are displayed at all.
Hi all, according to the plan posted for v3, this feature should be implemented in this version, so please keep adding ideas and refining the existing ones. Here is one comment on position of the + and - signs in the editor. In the Java editor, the column on the left edge is used to indicate the span/length of a method. It seems that it would the best candidate for placing the collapse and expand signs. Also, when nothing is collapsed, no signs are shown there. This approach also dictates that the folding/collapsing is indicated and done within the same editor. Tomas
Created attachment 7126 [details] scite editor screenshot Adding vertical bars to better vizualize the expanded blocks is not a bad idea. See an example captured from Scite.
ahhh.. Not another thing in that line.! What happens if i have a compile error and a breakpoint and code folding enabled? That line is getting to crowded.. I think line should have a column size (now only 1 but i would like to set it to 2) and then the distribute those things equaly.. (of fixed for code folding as far to the right)
Tomas, the left edge of the editor is already used for displaying a lot of other information. For example it would be necessary to find a way to avoid overlapping of [+][-] with the LightBulb-Icon. Maybe the width of that column must be increased. Also it should be thougth over if it is not to much information in one small place for good ergonomic design. The advantage of placing the [+][-] right beneath the method/command-name is that it is easier to handle and better to use, especially when there is a lot of nesting of codeblocks(wich mostly is the case in javacode). It supports reading and understanding the code and wich block is a sub-block of another one. The possible disatvantage (I am not sure about that) could be that the code gets a little bit harder to read with all these [+][-] directly in the code. But (no matter how this feature will be implemented) it MUST be possible to disable it anyway.
Johan, Robert, you are right, putting the expand/collapse signs on the left edge line would only caouse overlapping problems. I wonder what approach does the Eclipse team have in plan... Tomas
Johan mentions "Not another thing in that line.! ... That line is getting to crowded.." I would suggest that it's *already* too crowded. Why not just go the whole 9 yards and make the gutter totally configurable. Configure how many columns the gutter should have. Configure what types of markers go in what column. Configure what color each column is. Configure left/right orientation around the editor for *each* of the gutter columns (this is already kind of done where there's the "summary" gutter for errors on the right - if this was totally configurable that gutter could go along with the other columns, etc) Then, the current behavior is one column, everything goes there. Once code folding is added, it would add a new gutter column, but if people prefer one crowded column, they can configure that themselves. --- Also, code folding should be configurable as to what gets folded (sorry if this was already mentioned). In other words, I personally don't want to see 1000 +/- signs - just for methods or blocks longer than 20 lines. Here's what could be configured - Types of code folding (methods, control loops, blocks) - Min length to allow/disable folding for each of the enabled code types
I agree with configurable code folding, however, I expect that there will be no + on the spot where you can fold something. The plus should only be shown on the spots where code has previously been folded. There could also be commands in the context menu for expand all, collapse all and/or collapse all posible.
There are two gutters already, call them left and right. Left gutter is used for breakpoints and bookmarks and problems and quickfixes and selected element color. Right gutter is used for line numbers (if enabled) and quickdiff colors. So I think the + and - icons should go in the right gutter. Putting them inside the text (indented) would likely interfere with cut/paste, and also makes it harder to target the icons with the mouse (combo horiz+vertical movement instead of just vertical when going from icon to icon). Adding more gutters would always use more real estate, which I would consider to be a bad thing. Adding a super-customizable gutter management system would take time away from other more important things for little benefit.
If you put the +/- in the existing gutter some people will complain that the gutter is too crowded. If you put the +/- in its own gutter some people will complain that you're losing too much real estate. If you avoid those two problems by putting it somewhere else many will wish it was in a gutter. So, allowing a gutter customizing will satisfy close to 100% of the people on this particular part of the folding question. Instead of spending X hours getting the gutter customizing barely working for this code folding, spend X + ln(X) to get the gutter customizing right the first time. That's all I'm saying. Now, if gutter customizing for the code folding is a totally worthless idea, then that's something else entirely.
What if we forget about the +/- signs for a second? The collapse/expand functionality could become available while the mouse hovers a block and for instance Ctrl-Shift keys are pressed. A dim rectangle or an outline would show the target block and with a click we could expand/collapse it. Another "key modifier - mouse over" combination could activate a "quick view mode" by expanding a block automatically at mouse-over and collapse it at mouse- out.
VS.NET foding options are good . +1 for this approach. can we get like that
I agree with ovi (comment 62). We're all good programmers ;-) so we indent our code in a sensible way. Therefore, foldable regions are already visible by the indentation of the code itself. Therefore, IMHO, it is not necessary to show foldable regions with a '-'. Also, putting all these '-' marks in a gutter is confusing for me. It clearly shows where collapsable blocks start, but it's unclear where the collapsable block ends (which end-line corresponds with which '-' marker). To find that out, you would have to look at the indentation of the code itself anyway, which involves some more eye-gymnastics. See the .NET screenshot (http://www.actiprosoftware.com/Products/DotNet/SyntaxEditor/Outlining.aspx) for a case in point. Showing an unfoldable region with a '+' mark is a good thing however. Otherwise you could go: 'Hey, where did the code go to?'. So, folded regions should be clearly indicated. This would be my preferred implementation: - leave everything in one window (+1 for the .NET approach) - do not show foldable regions unless the editor is explicitly configured to do so (I leave others to fight over how this should be done) - give following options to fold a region: - when standing with the cursor on the begin or end of a foldable code block, provide a quick assist to do so - after selecting some lines of code, provide a quick assist to fold it (if it sensible to do so of course) - give an option (source -> fold -> ... ???) to quickly fold all catch blocks or all if statements or all methods or ... so you can quickly grasp the outline of some code. - after some code is folded, clearly indicate that it is folded and can thus be unfolded (a '+' somewhere (in the gutter like .NET or in front of the folded block like Together) and change the decoration of the text (ellipses, color, fade out <g>)). - of course, an 'unfold all' would be mighty handy - IMVHO, code folding is something personal for a programmer. Therefore, folding should not mess with the source code (special comments, ...). The folding status should be remembered in a file seperate from the source file (one file per source file or all in the .project?) My .02 euro's
Created attachment 7138 [details] Code folding in IDEA This is a screenshot of code folding in the IntelliJ IDEA IDE, which I think is very good.
Created attachment 7139 [details] Code folding in IDEA 4 The prevoius screenshot showed IDEA 3, this Screenshot shows code folding in IDEA 4. Enhancements: No extra column and you can also folde a comment or a method at the end of the code folding block!
IDEA 4 version is my favourit! It needs not very much of the screen!
+1 for the IntelliJ IDEA 3 screenshot (comment #65). That one looks much more "Eclipse-ish" than the IDEA 4 one, and I find the pointy icons confusing on the latter (looks more "Swing-ish").
Hi all, I wonder if anyone finds the point 2 of my original feature request useful. Here is the copy of it: 2. As an addition to bracket matching, there should a way to display an vertical line starting just under opening "{" going all the way down to matching closing "}", if one exists. This should be configurable in terms of color and turning on/off. Example: A piece of code like this: if(enabled==true){ for(i=0;i<elements.length;++i){ doSomething(elements[i]); doSomethingElse(elements[i]); . . . } . . doAnotherThing(elements); } could look like this, with the line drawn using ligther color: if(enabled==true){ | for(i=0;i<elements.length;++i){ | | doSomething(elements[i]); | | doSomethingElse(elements[i]); | | . | | . | | . | } | . | . | doAnotherThing(elements); }
Yes Tomas, absolutely. I've attached a scite editor screenshot, I'm not sure if you've seen it.
I also use the Scite editor. I like the vertical lines but something about it still bugs me. It would seem to me that having 5 or more vertical lines next to each other would kind of defeat it's purpose.
I really like the suggeston in comment 62. This would remove the necessity of adding anything to the gutters -- just ctrl-shift + hover and the collapsable block becomes highlighted somehow. ctrl-shift + click, and the block collapses/expands... No extra distracting information (which will be ignored anyway when you don't want to collapse blocks...)
Just a quick note about <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=9355#c62">Comment #62</a>. I like the idea, except for the part I have to use the mouse. One of the biggest complains I get about eclipse from other developers is that you always have to use the mouse for one reason or another, and this would be another case. Consideration must be made of using only the keyboard (perhaps some combination of ctl-shift-left cursor to collapse, and ctl-shift-right cursor to expand).
Once the functionality is there, assigning keyboard shortcuts is not an issue. I like IDEA's Ctrl+ and Ctrl-.
I also vote against making this feature a mouse only feature. Using a mouse is like having only two fingers, but I have ten of them and a 100+ keys to work with, so this feature should also have a keyboard shortcut... As to the vertical lines, one can show up when cursor(text one or mouse) is at the { or } or when some keyboard shortcut is used.
I think this feature should not be connected too much with the Java-Development-Environment (folding Methods, Try-Catches etc.). It should be a basic feature in all editors, to "exclude" lines from the display. In the good old ISPF/PDF Editor on MVS, they have the feature to exclude lines, which also is cleverly connected to the find/replace commands (propably similar to CMS/VMS, see #9). There the excluded lines are shown as "------ <nn> LINES EXLUDED ---" as extra line in the source-code (which of course is protected). The exclude and re-show command could then be attached to a context-menu (e.g. Java-Specific) or a key-code. (see <a href="http://publibz.boulder.ibm.com/epubs/pdf/ispedt02.pdf">OS/390 V2R5.0 ISPF Edit and Edit Macros</a> for more info.) The user could then define his/hers own criteria (or use builtins) for exluding regions using special 'tokens' in the source-code. Although it is probably beyond the scope of this request/bug, I would think that it would be a great thing for code-generation (based on templates, etc.) if "regions" in a source-editor could be protected from direct editing, and could be linked to a master document (or generation/build-mechanism) instead.
Why is this bug not assigned to any Target Milestone. Does "Version: 3.0" mean, that it will be in 3.0 final definitively? Is it in M6 already somewhere hidden?
It's a committed item for 3.0 but not yet committed for a specific milestone.
There have been some reguests for support of regions. There is a plugin, Protocols, that does something similar. See: http://www.bergner.se/protocols
Happy two year anniversary Folding bug!
Hey, it's still 6 days more before the anniversary! Sincerely I hope there won't be a third anniversary though ;)
I have been using eclipse for about 3 days now, and the lack of folding behavior is just about my only gripe. But I am very pleased to see all the excellent discussion going on for this enhancement. If any one is interested in my two cents... Folding should be: 1. User definable and commentable. I love .NET's folding. Assume I have three event handlers for a control X, I can put #region EVENT HANDLERS FOR X around the whole set and then when it collapses there is a nice little box there instead with my comments telling me what I put inside. 2. Persistent between sessions. Preferably all collapsed when a file is opened. 3. Needs to have a keyboard shortcut to collapse and expand. .NET doesn't as far as I know and I hate it.
Also it would be nice if eclipse allows us to print the folded code in both forms (folded and unfolded). VS.NET, AFAIK, always prints the unfolded form, which is annoying when you want to print the code for handouts in presentations. It would be SUPER nice if we can copy and paste code in both forms as well... very useful for articles, write up, documentation, etc.
I nearly went with IDEA because of code folding, but decided to get behind the Open Source solution (I'm currently learning how to do Eclipse plugins, so I can contribute someday). I really appreciate all the hard work people have put into Eclipse! I prefer the IDEA (3.0) approach, but am concerned with all the debate over details and what seems to me to be some "attitude of entitlement". "The perfect is the enemy of the good." I'm sure the Eclipse committers "get" the idea of code folding; I hope they'll do a minimal/basic version with some well-chosen extension points, and then people can do fancier solutions as plugins...
*** Bug 54422 has been marked as a duplicate of this bug. ***
+1 really would like code folding. fyi jedit's options for code folding are fairly nice as well. Whats the status of this issue. Any preview in M8?
Personally, my experience with these kinds of features is that they're more trouble than they're worth. Visually distracting, confusing to new users, and cluttering when you're trying to quickly skim-read your code and you're missing a whole block that you just can't find. I'm absolutely *not* in favor of implementing this feature, but if you do implement it, I have a request: please make it optional. The feature has to have an off button, or I'm switching IDEs. Seriously! I love Eclipse. It's a great product, and the price is superb. ;-) However, I can't stand the collapsing block feature in other editors, and I certainly don't want to see my beloved Eclipse perminently tarnished by this clutter.
The Visual Studio has this option. I think they have got this entire code folding thing right .It is slick and good compared to others .
From the JDT 3.0M9 Milestone Plan ( at http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/jdt-ui-home/r3_0/main.html#Milestone_Planning ): "Typing, Presentation, and Source Manipulation * Override indicators in vertical ruler (2 days) * Prepare semantic syntax highlighting (10 days) * Prepare Java conformant folding (2 days)" Looks like we'll get the code folding in M9 ?
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-text- home/plan.html#Milestone_Planning This is the plan for M9 Text component . folding allow user controlled folding structures vertical ruler column as folding control They are marked green now
This is now available for the Compilation Unit Editor (I20040504 and newer) and the Class File Editor (released in HEAD). - new Java > Editor > Folding preference page which allows to enable and configure folding for the Compilation Unit editor (support for the class file editor will follow) - new commands that allow to control the folding: - Toggle Folding, default: Ctrl + Numpad_Divide - Collapse, default: Ctrl + Numpad_Subtract - Expand, default: Ctrl + Numpad_Add - new extension-point "org.eclipse.jdt.ui.foldingStructureProviders" which allows clients to contribute folding structure providers. See extension-point documentation for more details. - support for other editor providers to implement their own projections, see the text plug-in packages named "*.projection.*" Please do not reopen this bug report if the solution does not fit your needs but reopen a new report instead.
*** Bug 27034 has been marked as a duplicate of this bug. ***
FYI - for those of you who feel there are some shortcomings with the current implementation of code folding, please check out the latest release of my Eclipse code folding plug-in: http://www.coffee-bytes.com/servlet/PlatformSupport Also, feel free to use the sourceforge site to request enhancements or report bugs.
