Community
Participate
Working Groups
I'm a prior user of the IntelliJ Idea Java IDE and one feature I particularly liked was the ability to turn on/off horizontal lines between methods and member variables when editing a class. The setting was an application-wide property and it made it very easy to see the method boundaries when editing code. I'd like to request this as a new feature in Eclipse and make it something that is configurable through Preferences.
+1 here
The painting architecture to support this is in-place in the Java Editor. We have considered this feature and came to the conclusion that 1) it is noise and 2) it costs cycles (and painting is on the critical performance path). However, we have never developed ourselves with such separators. This feedback sounds that such add real value. We should investigate how much effort it is to add this feature.
unfortunately not for 2.0
+1 for this feature!
+1 from my side. It's been 2 years this since this feature request was forwarded! Still no action.
Any chance of this getting some attention for 3.1?
*** Bug 80100 has been marked as a duplicate of this bug. ***
*** Bug 92965 has been marked as a duplicate of this bug. ***
4 years, 2 duplicates, 6 CCs, and 4 votes later and this still has no attention? C'mon - EG says the architectureis already in place - how much effort can it be to implement from there?
Get rid of deprecated state.
*** Bug 199630 has been marked as a duplicate of this bug. ***
*** Bug 214282 has been marked as a duplicate of this bug. ***
Not for 3.5.
Created attachment 182840 [details] Fix Here is what the feature does - - Draws boundary lines to demarcate methods. - This can be turned ON/OFF using 'Method Boundary Lines' in the Java > Editor preference page. - The color of the line can be changed from the same preference page. - By default it draws boundaries for collapsed methods as well - this can be turned off by setting 'drawBoundaryForCollapsedMethods' to 'false' in JavaEditor.java. I haven't yet looked for the performance tests - will do so next. Following is a sample set of scenarios for testing - - Rapidly move the horizontal or vertical scroll bars and watch for refresh issues. - Do the above with as many small methods in the visible area as possible. - Switch editor tabs, applications and/or move another window over the editor area. - Expand collapse methods, javadocs and other elements. - Type/Delete/Paste within a method. - etc.
Thanks, Rajesh, for spending some time on this! I have one UI suggestion that I think is critical for usability: provide a toolbar button to toggle the preference, similar to the "Show source of selected element only" preference. I'd like to say I can add that part as a contribution, but I don't see myself realistically having the time between now and 3.7M4 (or M5).
(In reply to comment #15) > Thanks, Rajesh, for spending some time on this! > I have one UI suggestion that I think is critical for usability: provide a > toolbar button to toggle the preference, similar to the "Show source of > selected element only" preference. I'd like to say I can add that part as a > contribution, but I don't see myself realistically having the time between now > and 3.7M4 (or M5). Yes, we should do that, but it has to be hidden by default just like the other button is. Another/additional possibility would be to offer a command that allows to toggle it.
(In reply to comment #0) > ability to turn on/off horizontal lines between methods and > member variables when editing a class. The request is for methods *and member variables*. The patch adds horizontal lines only before *and* after a method. I think it will be more consistent to add lines before *or* after a java element - method, inner type, member variable. It might be overkill but the separators for different elements could be slightly different - color, dotted/dashed/solid/thicker line ?
(In reply to comment #17) > (In reply to comment #0) > > ability to turn on/off horizontal lines between methods and > > member variables when editing a class. > The request is for methods *and member variables*. > It says 'between methods and member variables' and not necessarily between member variables. Anyway, besides interpreting that statement, I am not convinced about the utility of separators between member variables if that's what you are implying. > The patch adds horizontal lines only before *and* after a method. I think it > will be more consistent to add lines before *or* after a java element - method, > inner type, member variable. Adding 'before *or* after' instead of 'before *and* after' - that would work only if, 1. we added separators between all types of elements, 2. For methods, we could search if the previous and next elements are methods and accordingly draw the lines. The first approach could lead to severe clutter and probably an overkill. The second would make the processing slower, but we could try and see if the performance is acceptable.
Created attachment 183100 [details] Patch Added the following - 1. Toolbar button to toggle the feature ON/OFF 2. Icons for toolbar and help docs (please copy the attached icons.zip into your workspace folder and unzip) 3. Updated the various Help Docs
Created attachment 183101 [details] Icons Place the zip in your workspace folder and extract there.
LAF: - opening e.g. ArrayList I see two lines between each method - line draws too far on the right (should be aligned with line highlighter) - should also draw line between types (thicker or two lines to see the diff) - I would rename the preference (e.g. "[Draw] horizontal line between types and method) - once we've decided on what it does and how we name it in the UI we have to change all the constants and Javadoc - The tool bar button must not be visible by default CODE: - the code should be triggered by changes in the Java model and not compute the state on each redraw - getElementAtOffset(int) must not be used as it forces a reconcile in the UI thread which is not good - the new class should be placed outside the Java editor ==> I think it would be much easier to follow a similar approach like the folding structure provider: simply add an annotation for each line and let the annotation painter infrastructure do all the work. You would register a new AnnotationPainter.IDrawingStrategy which would draw the horizontal line for your new annotation type.
(In reply to comment #21) > LAF: > - opening e.g. ArrayList I see two lines between each method > - should also draw line between types (thicker or two lines to see the diff) What happens if you have the following snippets? What all lines and of what type do we draw? 1) class A { private void foo() { } int a =100; int b =200; private void bar() { } } 2) class A{ class InnerClass { } int a =100; int b =100; private void foo() { } private void bar() { } }
> What happens if you have the following snippets? What all lines and of what > type do we draw? We will have to see how it looks but something like this: > > 1) > class A { ----------------------------- > private void foo() { > } > > int a =100; > int b =200; ----------------------------- > private void bar() { > } > } > > 2) > class A{ ----------------------------- ----------------------------- > class InnerClass { > } ----------------------------- ----------------------------- > int a =100; > int b =100; ----------------------------- > private void foo() { > } ----------------------------- > private void bar() { > } ----------------------------- > } I would leave the lines around the top-level class away unless there are more than one.
----------------------------- private void foo() { } ----------------------------- ----------------------------- private void bar() { } ----------------------------- Probably also needs to be change (only 1 line between methods): ----------------------------- private void foo() { } ----------------------------- private void bar() { } ----------------------------- Otherwise I sometimes get 1 and sometimes 2 lines.
The annotation based approach I mentioned in comment 21 has another benefit: we could provide different drawing strategies in the future, e.g. box around the method instead of horizontal lines.
Created attachment 183542 [details] Patch The new patch has following - - Rewrote the feature using the annotations framework. - Separator drawn for Types and Methods. - Separator not drawn for Primary type (see ITypeRoot#getPrimaryType()). - Type separator is a thicker line. - Separators drawn at the top of types and methods. - Various scenarios such as paste/delete of entire Types/Methods, multiple top-level types and inner types are all handled. Issues- - The annotation painter seems to be behaving differently for collapsed javadoc versus collapsed method by ignoring annotations at the first line of javadoc, but works fine for collapsed methods. - When there are field declarations between 2 types/methods, then a separator would make sense at the bottom of the type/method above. Still looking into this.
(In reply to comment #26) > - When there are field declarations between 2 types/methods, then a separator > would make sense at the bottom of the type/method above. Still looking into > this. We could show a separator before a field declaration 'block' (instead of a separator for every field declaration) e.g. class A{ ***************************** class InnerClass { } ............................ int a= 100; int b= 100; ----------------------------- private void foo() { } ............................ int c= 100; ----------------------------- private void bar() { } }
(In reply to comment #27) > (In reply to comment #26) > > - When there are field declarations between 2 types/methods, then a separator > > would make sense at the bottom of the type/method above. Still looking into > > this. > > We could show a separator before a field declaration 'block' (instead of a > separator for every field declaration) Yes, what you have shown is kind of the idea, but the challenges are - 1. Firstly, the model doesn't have a notion of a 'field block' so one needs to parse line by line and reliably process a block. All additions/deletions/edits to the block will have to processed for each field. 2. Another way could be to associate the annotation with the last line of the type/method that has a field declaration following it. Here, if the field declaration is deleted or a new one inserted, the model currently won't flag type/method above as 'element changed'. Need to keep it simple, so will dig deeper and get back.
Created attachment 183719 [details] Patch Added the following - 1. If between 2 Methods/Types, there are other types such as field declarations, there would be a separator to show the end of the Method/Type. This is shown in e.g. below. 2. Modified label on Preference page - need to finalize name, I was thinking of a name like JavaSourceSeparatorLine. 3. Paste/Delete/Typing tested to work. class A{ ***************************** class InnerClass { } ----------------------------- int a= 100; int b= 100; ----------------------------- private void foo() { } ----------------------------- int c= 100; ----------------------------- private void bar() { } }
Created attachment 183730 [details] Patch Optimized the code and fixed few issues.
Created attachment 183737 [details] patch Fixed a small issue with the toggle on/off.
I tried this feature with real code, and it does not look too bad. The one improvement I can think of is in handling of anonymous classes e.g. private IInformationControlCreator getInformationControlCreator() { return new IInformationControlCreator() { public IInformationControl createInformationControl(Shell parent) { return new DefaultInformationControl(parent, JavaPlugin.getAdditionalInfoAffordanceString()); } }; }
from my last review (comment 21): >- line draws too far on the right (should be aligned with line highlighter) Not fixed: 1. paste the following into Package Explorer: public class A { void foo() { class B { } } class C { void bar() { } } } 2. enable horizontal lines ==> draws further than current line painting NOTE: you might want to look at the WhitespaceCharacterPainter on how the clipping is done there (especially the changes Markus made recently). >- The tool bar button must not be visible by default Not fixed. Feature work/changes: - The icon needs green dots - The icon should be to the right of 'Toggle Mark Occurrences' - The class should also get a thick line at the end, e.g. void foo() { class A { } toString(); } - In some situations, also methods probably need a terminating HL, e.g. when having anonymous inner classes (not 100% sure yet though). Bugs: - There's small cheese on the right when hitting 'Enter': ==> this is probably caused because you paint to far to the right (see above) - Horizontal lines (HLs) are gone after File > Revert. - Disabling the HLs does not remove it: 1. open a CU 2. enable HLs 3. change a method name 4. disable HLs ==> HLs still there - Changing the color when HL painting isn't enabled gives an NPE. - Something with the update code looks wrong i.e. I don't get the HLs but I see the new methods in the outline and the folding icons. This happens when methods with the same name are there, e.g. select a method with its body and then Ctrl+Alt+Up. - If an inner class is folded then the folding marker on the right is sometimes drawn in bold. This is probably because you don't reset the line style in your painter. - Your painter/layer should be below the annotation layer used do draw the linked mode stuff: try rename on a method ==> you don't see the upper line of the box. - There shouldn't be a HL at the top when in segmented mode (method only view). - Platform Doc needs no changes (the action is only in JDT). When all is done (committed in HEAD) we also need to investigate whether it looks better if the lines start closer to the parents indentation than right at the left side.
- IJavaEditorActionDefinitionIds - don't add an empty line before the @since - don't touch code outside your changes (gives me more to review) -plugin.xml - methodBoundaryLinesColor definition is missing - JavaEditor - the provider should not be created when not needed - the provider should not be created inside createPartControl - MethodBoundaryLinesProvider - the copyright is missing - use install/uninstall instead of (de-)activate NOTE: more detailed review once issues from comment 33 are fixed
This feature is becoming the Duke Nukem Forever of the Eclipse platform!
Probably gonna regret asking this since this thread been dead for over 2 years but whatever happened to this work? I like some of the others in the post are an ex Intelli-J user attempting to convert to Eclipse and also struggle without the method seperators. Is this available now as standard in Eclipse but hidden somewhere?
As far as I can tell, it is not available in Eclipse Juno SR 2 release (20130225-0426). :( I, too, am still hoping to see this feature implemented.
who doesn't :)))
I authored this crazy request 11 years ago. I don't even use Eclipse anymore. I was originally told that it was too expensive since it was part of the paint routine. Maybe someone in the next 11 years can take the time to do this. It seems it would be trivial. I get notified when someone comments and I'm surprised it's still living.
Well, I have developers adding comments lines in the code to achieve that. It drives me crazy... Is there any ETA on that because well, it doesn't sounds to be that difficult to achieve nowadays :) When I ask them, to remove the lines it's OK, but buy me an IntelliJ license then... I see the issue is not assigned so I have little hope. Oh well...
Note that this bug already contains an initial patch with review comments. I'd be happy to review the next version of it, if someone steps up and provides it.
Ceremonial every-second-year ping on this old feature request. It has a reviewed patch, can anyone try to revive that patch and address the review comments?
New Gerrit change created: https://git.eclipse.org/r/98567
Hi Dani, I did some update and brought along Rajesh's most recent patches so that they are now part of Gerrit. As of the latest integration builds of Eclipse, I don't see the horizontal line drawing further than current line painting in Comment 33. Could you confirm this is still happening? I've attached how it looks like on my current build.
Created attachment 268731 [details] horizontal line doesn't go past whole line highlighting
(In reply to Ian Pun from comment #45) > Created attachment 268731 [details] > horizontal line doesn't go past whole line highlighting I don't see any horizontal line in that screenshot.
(In reply to Ian Pun from comment #44) > Hi Dani, > > I did some update and brought along Rajesh's most recent patches... See my comment in Gerrit.
Like Nicolas Bihan mentioned, I'm one of those people who is adding demarcation comment lines before methods, but I would prefer not having to do this. Side note: Using the javadoc style instead of // keeps the line with the method when rearranging them via the outline view: /** ------------------------------------ */
