Community
Participate
Working Groups
The idea is to end an age old discussion to all parties satisfaction once and for all. Which is better: if () { } or if () { } The answer, IMHO, is to seperate formatting/encoding of source files from presentation. How Eclipse renders { is an issue much the same as what colors, bold, etc. that it chooses to render the source code. Here is the scheme: - Add an option to choose how Eclipse renders/shows the "{" on the screen. This configuration option would be much the same as the Java->Code formatter preferences today, except it would be called "Java->Code presentation". - When files are saved to disk/commmitted to CVS, Eclipse automatically examines the existing source file and respects the encoding/formatting of "{". This is an important feature when using Eclipse against a project which has established rules about source code encoding. - Source code could even be presented without {, but only indentation, lines, or colorings. The same idea applies to: - Comments. They should be collapsable(I can fit more code onto the screen if I temporarily hide comments). - Various formatting options, "Compact assignment". Øyvind
There are currently no plans to do this. This item would also need work/commitment from other components (e.g. Compare, Team, ...).
*** Bug 53044 has been marked as a duplicate of this bug. ***
*** Bug 102290 has been marked as a duplicate of this bug. ***
*** Bug 103711 has been marked as a duplicate of this bug. ***
*** Bug 107990 has been marked as a duplicate of this bug. ***
Still no plans to do this? The number of duplicates alone could serve as an indication. A lot has happened since 2003. The current Java code formatter is far more potent now, making the argument for this kind of functionality stronger.
Still no plans to do this? Correct. Feel free to work on this item and provide a high-quality patch.
Sure, I could do that. But I would rather work on a feature request that was opened and alive. I entered bug 10799 since I had ideas that stretched beyond what is described here (and the former duplicates) and I wanted to start a renewed discussion. I'm afraid your immediate "resolve as duplicate" felt like you closed the door in my face.
>I'm afraid your immediate "resolve as duplicate" felt like >you closed the door in my face. That was not the intention. The benefit of marking is duplicate is that it connects all interested parties. The other resolution would have been "RESOLVED LATER". This only reflects our planning. You can always propose to work on an item which is marked as later.
Good. Misunderstanding on my part then. I think there's a subtle difference between leaving a feature request as OPEN and close as RESOLVED (even if the resolution is LATER). To me, the former encourages an ongoing discussion whereas the latter is an indefinite postponement. I didn't even search for RESOLVED items before I entered my feature request since I knew that the feature didn't exist. If it's a feature request, why not simply lower the prio instead of marking it as RESOLVED?
If you look at the Eclipse process dev guidlines for bugzilla: http://www.eclipse.org/org/processes/Guidelines_for_Eclipse_Development_Process/bugzilla-use.html you'll see that we should even set more PRs to LATER ;-)
*** Bug 108868 has been marked as a duplicate of this bug. ***
*** Bug 27207 has been marked as a duplicate of this bug. ***
*** Bug 112033 has been marked as a duplicate of this bug. ***
*** Bug 22434 has been marked as a duplicate of this bug. ***
One common concern that comes up in the "braces discussion" is that a) takes up more screen real-estate. There has been some other efforts in Eclipse to recover screen estate lost to syntax noise(e.g. collapsed import statements). If Eclipse had the capability(it does have some of this capability today, coloring, collapsed imports, etc.) of seperating presentation from formatting & storage of the Java code, then perhaps this could be used to recover even more screen real-estate. The goal of reducing screen real-estate usage is that large programs become more readable with less page-up/down + splitscreen... a) if () { } b) if () { }
Just some ideas on more a more "terse" representation of Java code to better illustrate what I'm pondering. Consider: public boolean getCanCreateDetail() { return getForskrifter()!=null && getOmrader()!=null && getSelectedStatus()!=null && getSted()!=null; } Using two rules: - OGNL syntax. This is inspired by http://www.ognl.org. Used extensively in e.g. Tapestry. http://jakarta.apache.org/tapestry/. Since JSF(Java Server Faces) is becoming a standard and AFAIK, it is very similar to Tapestry in philosophy, I imagine that they have something OGNL like. - indentation instead of braces(idea stolen from Python) public boolean getCanCreateDetail() return forskrifter&&omrader&&selectedStatus&&sted; There would be a button in the margin(much like the '+/-' for collapsing imports) to switch between the representations.
*** Bug 114995 has been marked as a duplicate of this bug. ***
What I would like to see is something like this: +public boolean getCanCreateDetail () | return forskrifter != null | | && omrader != null | | && selectedStatus != null | | && sted != null Notes: - There are no braces or parens. The editor indents the code and adds lines to indicate which parts belong together. - Long conditionals are split over several lines. The formatting should allow to delete parts of the expresion by deleting a line (instead of having to aim with the mouse or endless shift-ctrl-cursor journeys). - There are no ";" because they are mostly unecessary for the developer. - Things like &&, ||, !=, etc. should be replaced by the proper symbols The hard problems come with debugging (see my comments for bug #53044)
For me, the key is the ability to define separate settings for display and for saved files. Currently, you can "auto-format" the file and have it use the code style settings applied to a file. Here is the usage pattern that I'd like to see: * User can define one code-style for storage and one code-style for display. * If you user has display formatting turned on, the following is done: - when the file is opened, the user's display-style is applied to the file. - while the user works on the file, no auto formatting is applied. As long as the file is open, whatever the user types into the file is preserved. - when a file is saved, it gets formatted using the storage-style. That way, whenever I open a file, it is shown to me in the format that I prefer, but when I go to check the file into source code control, it will be in the format that the team has agreed upon. This helps prevent spurrious formatting based checkins/conflicts. make sense? I entered this concept as a separate bug, which was subsequently resolved as a dupe of this one. To me, it seems that my idea is an extension of the main thrust of this bug, but it seems to fit here.
I wholeheartedly agree with Comment #20. There is definitely a distinction between formatting standards agreed upon by a team vs. those that are convenient or match the desired style of each individual. I want the ability to make the distinction first; how to reclaim real estate while viewing the code or eliminate "unnecessary" syntax are subsequent concerns.
*** Bug 121552 has been marked as a duplicate of this bug. ***
I'm interested in implementing the following functionality (similar to what I described in my comment #20): * The user defines a view-format and a saved-format. * When a file is opened, the view-format is applied to the file. * When a file is saved, the saved-format is applied to the written file, but what is shown to the user remains as they typed it. * When a file is refreshed, the view-format is applied to the file. * If you user applies formatting (through today's mechanism) it applies the view-format. To implement this, I want to do the following: * Add a preferences pane to capture the format preferences for the saved-format. The regular format preferences would be used as the view format. * Extend the java editor to perform the functions above. This seems like a simple task, for someone who knows the Eclipse object hierarchy well. I am not this person. What I'd like from someone here would be the contact info for someone who could and wouldn't mind answering my questions. thanks!
I suggest to ask the questions on the eclipse.tools.jdt newsgroup. Tricky part will be the class/binary files with attached source: you cannot reformat those to the view settings because class file information (e.g. line info) will no longer match and the debugger will highlight the wrong source lines - unless of course you also provide a mapping here. You also have to make sure that compare viewer inputs are converted.
(In reply to comment #23) > I'm interested in implementing the following functionality (similar to what I > described in my comment #20): > > * The user defines a view-format and a saved-format. > * When a file is opened, the view-format is applied to the file. I believe that doing a conversion upon load is the wrong way to go. Some reasons I can think of that stops me from getting that "warm fuzzy feeling": - conversion is lossy in the general case. This can cause a load + save to change the formatting of the original file even if there were no other changes. - when the user modifies his preferences, all loaded files must be reformatted again. - More severe presentation changes, such as presenting brackets "{" with with indentation(trick stolen from Python) can't be handled via conversion. I would feel better if presentation with preferred formatting was handled at rendering time, just as font&text color is handled today. Also, if the underlying storage of the text never changes, then there would be no need to do conversion upon commit. As text is typed in, it should, internally, be stored in the repository formatting.
Perhaps this idea could start its life with a "Code presentation View" without any editing capabilities...
re comment 26: bug 66598 would provide this.
In that case, we should probably concentrate on bug 66598 first; this will give us the necessary time to learn what we really want to (and can) achieve. Especially how the online formatting is going to work out is probably a bit foggy right now. When the view exists, we can go back to this bug by refactoring the code until one can edit the "view" in realtime.
The view already exists but it's directly showing the source as is. The idea is to have an option that allows to format it as defined by the containing project prefs.
*** Bug 139708 has been marked as a duplicate of this bug. ***
http://nickgravgaard.com/elastictabstops/ describes a "new" way to handle Tabs which is related to this bug. Bascially, it's proposed to handle Tabs like WinWord or Desktop Publishing software: By aligning the character after the tab (kind of an instant table). That would make text formatting more simple (you just separate the different "columns" and the editor aligns them). In a next step, this could be extended to handle comments and javadoc. First, the "text" part (ie. the characters inside "/*" and after each "*") should be independent of the "outline". So when the line just contains "_*_|" (| is the cursor) and I press backspace, the whole line should be deleted as if the "_*_" wasn't there. In the second step, the Javadoc text could be replaced with a HTML-like editor which is wrapped in a component that draws a"*"-border around it (see the JDocEditor plugin at http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-330.html for an example). When that works well, we could take the gathered experience from these changes to attack this bug.
Wait wait ;-) Elastic tab stop isn't the cure here since it has nothing to do with formatting, e.g. where you wrap your code or have newlines. In fact it introduces yet another format/style which one might like or dislike, especially those who prefer to work with external editors (which won't have support for this new feature). This doesn't mean that I don't like the idea of elastic tab stop though. Please use bug 149603 for further comments about the elastic tab stop feature.
> Elastic tab stop isn't the cure here Correct but it would be one small step into the right direction, ie. it would allow to separate content from display. And it allows to break this big bug down into smaller chunks which might help to implement it faster.
*** Bug 165868 has been marked as a duplicate of this bug. ***
Another thing I would like to be able to do with separate presentation and formatting/storage is to e.g. edit Java in the context of a presented HTML page. Consider Tapestry/Java Server Faces and something like OGNL. Basically if I could form within a HTML page refer to Java code in a .java file and edit OGNL like expressions I wouldn't need OGNL. While not actually editing Java from within the context of HTML, I would like OGNL like rendering of that Java code in HTML source. This would: - get rid of the need for OGNL - improve *performance* of the web app - provide a terse & legible HTML templates. I see this PR is RESOLVED LATER :-)
> Another thing I would like to be able to do with separate presentation > and formatting/storage is to e.g. edit Java in the context of a presented > HTML page. I think that's outside the scope of this bug. Here, we talk about separating the presentation of the editor and the Java file. What you want is either to be able to extend Java with HTML (so you can say: HTML xxx = <HTML>...;) or to extend the editors to "see" information from elsewhere. Have a look at the WebToolsProject WTP or MyEclipse. They already can do quite a lot of magic in that regard.
*** Bug 192688 has been marked as a duplicate of this bug. ***
I don't think that the problem arises from displayed/saved files... Because the files are in my computer... and in my computer I see the files the way I want to see them. But rather when working with a server ( at least that is my case ). My suggestion is that eclipse keeps working the same way it has been, but when I go and commit a file, that file ( that is using my formatter ), is formatted with the "common" formatter which was selected by the team. When I open the compare editor the file, local file is formatted with my formatter, and the remote file is reformatted with my formatter.... that way I always see files with my formatter.
(In reply to comment #38) > that way I always see > files with my formatter. There are several issues here: - How to synchronize line numbers when someone else sends you a stacktrace (he will not using your formatter, so the line numbers will be wrong). - Some people are happy with ASCII, others want to be able to use a more graphical editor with lines and HTML support in javadoc. Eclipse has shown that VI/emacs is not the only way to edit source. And I, personally, believe that Eclipse is just the tip of the iceberg. After 30 years of software development, we still limit ourselves to ASCII; even Unicode (supported by Java) is frail. No wonder Adobe Flash has driven Java from the browser into a corner to rot&die. Flash comes with an *editor*, not VI Version 10.0 (9.0 brought support for the cursor keys and 10.0 added Ctrl-Space! *cheer* :-( ).
(In reply to comment #35) > Consider Tapestry/Java Server Faces and something like OGNL. If you want to see how you can integrate HTML and a programming language, look at Google and MarkupBuilder. Example: builder.html { head { title 'foo' } body { for (item in pageItems) { item.render(builder) } } } Basically, the language transforms this into a series of method calls to the builder which can be interleaved with code. This is very easy to read after sitting down for a few minutes and thinking it through, it gets rid of the ... uhm ... challenged HTML/XML syntax and it offers a simple way to push the contents of your variables out into the stream at the right place without guessing, insane tree navigation. Did I mention that this is a stream based API? No building of the document in memory in advance, Sir! That's the stuff!
(In reply to comment #39) > - How to synchronize line numbers when someone else sends you a stacktrace (he > will not using your formatter, so the line numbers will be wrong). > How about maintaining two sets of line-numbers? One 'main' set that reflects how the source is stored in the actual file, and one 'formatted' set that is volatile and only applies to the current view in the editor. Viewable by preference of course even if the 'formatted' line-numbers probably are of very limited use. > - Some people are happy with ASCII, others want to be able to use a more > graphical editor with lines and HTML support in javadoc. > I don't understand why that should be relevant in this case. Can you please elaborate?
(In reply to comment #41) > > - How to synchronize line numbers when someone else sends you a stacktrace > >(he will not using your formatter, so the line numbers will be wrong). > > > How about maintaining two sets of line-numbers? Many, actually. Some examples: You get a stacktrace for the final product. This one is simple: Resolve the line number against the server version and then map this to the version in your local workspace. Next, a co-worker reports an error. In this case, he will have to map his line number to the server line number and from there, you can work it out. The main problem is that you can't automatically differentiate between the two. All of a sudden, you have to know if the other person is using a different formatter than you do. Another solution might be to change the Eclipse compiler to generate virtual line numbers, say, per term in your AST. That would allow to locate NPE's like o.getA().getB().getC() (where getB() returns null) much more easily but we'll get into trouble if someone compiles your project with Sun's javac. > > - Some people are happy with ASCII, others want to be able to use a more > > graphical editor with lines and HTML support in javadoc. > > > I don't understand why that should be relevant in this case. Can you please > elaborate? Take my comment #19. I'm arguing to drop ASCII-only source code editing. I'd like to be able to edit HTML directly. I'd like to be able to use tables to arrange data (maybe even with cells that can do calculations for me). In this scenario, line numbers start to become irrelevant because I'm navigating a big picture which contains small chunks of Java code at certain places. This leads to the question: Is this bug about automatically calling the Java Formatter or is it a radical new way to look at Java source (just like the transition from VI/emacs/Notepad to Eclipse). In comment #31, I refer to a demo of an editor that will indent in a table-like manner (i.e. not in multiples of 8). This leads to the question whether we want to add formatting instructions to our source code (like HTML where you mix formatting with your content) to make it more readable and add additional information which simply can't be expressed in Java. Imagine having an Excel sheet as part of a .java file where you can configure the current class (for example, for listing constant values or complex data arrays). In the file itself, this would be a set of comments and when the editor opens the file, it would read those comments and embed Excel/OOCalc for this data. class Foo { /*<TABLE>*/ /*<TR>*/ /*<TD hidden>*/ public final static /*</TD>*/ /*<TD>*/ FOO1 /*</TD>*/ /*<TD hidden>*/ = new Foo( /*</TD>*/ /*<TD>*/ "Foo 1" /*</TD>*/ /*<TD hidden>*/ ); /*</TD>*/ /*</TR>*/ } etc.
(In reply to comment #42) > > Many, actually. Some examples: You get a stacktrace for the final product. This > one is simple: Resolve the line number against the server version and then map > this to the version in your local workspace.... I think we are talking passed each other. There would never be several versions with different formatting the way I envision it. The viewer/editor does the formatting on the fly and in memory only. The persistent storage underneath would never be subject to that formatting. It would use some canonical format adopted by everyone. No matter who uses the file, the line numbers would be consistent throughout. How things are organized in your editor is irrelevant. It's for your eyes only. No stacktrace or debug session would ever be based or affected by your formatting. In some sense I think we say the same thing. The line numbers used when viewing the code are utterly irrelevant, if even present. The only thing that matters is that since debugger info and stacktraces are based on line numbers, those line numbers must be matched with the persisted (and compiled) source files. The mapping from those files to/from your formatted view must be done on the fly by the editor/viewer.
Comment #42 I don't think that's a good idea... maybe adapt that idea... but implement the formatting elsewhere... because if someone checks out the source and uses another editor... that code will be unusable. Comment #43 Very true... I thought of modifying files because it would be easier... but what you say would be the solution.
As a quick fix, I'm gonna try to make a plugin, that patches the problem... Forgetting about the line number issues, just trying to synchronize the file when doing commit, update or compare operations. I'm kind of busy... but i'll try to give it a shot. Just to keep everyone informed. When I have it running i'll post the project.
Get rid of deprecated state.
*** Bug 294444 has been marked as a duplicate of this bug. ***
*** Bug 320125 has been marked as a duplicate of this bug. ***
(In reply to comment #48) > *** Bug 320125 has been marked as a duplicate of this bug. *** Just adding a couple of thoughts here, since this is the place to be for this in my mind ground changing enhancement request for the IDE coding experience. In general I agree with having a physical file format and a display format as the best solution. The only addition I had was to allow word wrapping in code editors, fit to visible horizontal space as an option (people using 60 char editors v.s 180 char editors, avoid horizontal scrollbars). The text can still be treated as the same line from compiler standpoint, but it would require some changes in the editor newline recognition, maybe introduce an editor specific invisible soft newline character combination that is not persisted... 11 // 12 // a very long method call in a small editor that wraps around on a good spot/token [\s,.<operator>] close to the editor border 13 //funnily that is just how it is displayed in notepad++ where I type this right now A solution could be to have two tabbed views in the code editor(physical, display) of the editor similar to the XML editor(source, design). I could live with having the debug perspective/stacktrace linkage using the physical tab rather than the display tab as a work around for the compiler line numbers, but of course it is probably easy to synch those views if you have both available... Maybe an intermediate solution (as was suggested above) would be to create a different editor "FormatedCodeEditor" that might not be used for stack trace linkage and debugging.
I recently entered a post in the JDT forum: http://www.eclipse.org/forums/index.php?t=rview&goto=660159#msg_660159 Fortunatelly Dani found it there and pointed me to this feature request. To summarize my feature whish: It would be really nice to display (read-only) sources of e.g. used libaries (e.g. rt.jar) in the format settings that a I prefer. I assume that the additional "display settings" would solve this. Those "display settings" should also have a check box "Use save settings".
(In reply to comment #50) > It would be really nice to display (read-only) sources of e.g. used libaries > (e.g. rt.jar) in the format settings that a I prefer. As already discussed above, formatting the whole file would lead to changed line numbers, so e.g. debugging and the Java stack trace console would be broken. I guess the best we could do for attached sources would be to correct the indentation.
(In reply to comment #51) > As already discussed above, formatting the whole file would lead to changed > line numbers, so e.g. debugging and the Java stack trace console would be > broken. I guess the best we could do for attached sources would be to correct > the indentation. Wouldn't it be possible to maintain a map between original line numbers and the line numbers in the formatted source and use that during debugging?
Yeah, I should have said "I guess the best we could *realistically* do ...". If someone offers to write a high-quality patch that performs this mapping *everywhere*, then we could consider this again. "Everywhere" includes the whole debugger UI, stack traces, Java model, search, etc.
(In reply to comment #53) > Yeah, I should have said "I guess the best we could *realistically* do ...". How about this: As a first simple step, you add a second tab to the Java editors which reads "Formatted" (like the XML editor where you have the design and the source view). That way, the debugger could jump to the "RAW" tab and I could switch to the formatted tab for browsing the source.
(in reply to comment #51) Having a correct indentation would be very helpfull!! (in reply to comment #54) Nice idea! And either the "RAW" mode does indentation or a third tab does "indented RAW".
I like the idea of fixing the indentation but I don't like to add an additional tab to each class file editor.
(In reply to comment #56) > [...]I don't like to add an additional > tab to each class file editor. Agreed but which other metaphor does the UI offer to achieve this?
(In reply to comment #57) > (In reply to comment #56) > > > [...]I don't like to add an additional > > tab to each class file editor. > > Agreed but which other metaphor does the UI offer to achieve this? Long time ago we discussed to add an extension point that would allow to contribute presentations for class files (e.g. source vs. byte code vs. disassembled format etc.). Back then the idea was that the presentation could be chosen e.g. via drop down at the top.
*** Bug 354432 has been marked as a duplicate of this bug. ***
*** Bug 367226 has been marked as a duplicate of this bug. ***
As for the line number mismatch problem, why not compile the source as formatted using my formatting rules? This fixes all of the problems with the entire stack being mismatched. No mapping of line numbers between storage and my formatting would be required. Most of the time, I am not dealing with line numbers from production or from other engineers. Let's solve this problem for the common case and then deal with the issues of the rare case. If I get a call stack from production, then I simply switch to the storage formatting with a click of a button or menu item. I think I can handle looking at foreign formatted code for a little bit while I figure out the call stack. If I get a call stack or line number from another user in their own formatting, then I tell them that won't work. The user can then send me a call stack with generated locations per term in the AST or they could have Eclipse do the conversions down to the storage format. This shouldn't be too hard. For each, call stack frame format the file down to the storage format and watch where the beginning of the line goes.
(In reply to comment #61) > As for the line number mismatch problem, why not compile the source as > formatted using my formatting rules? This fixes all of the problems with the > entire stack being mismatched. No mapping of line numbers between storage and > my formatting would be required. Because that solves the problem only for one-member teams. For any non-simple project, more than one person will work on the same code and they will have different formatting rules. For you, the solution is already there: Run the code formatter on save (see http://stackoverflow.com/a/234625/34088)
*** Bug 537939 has been marked as a duplicate of this bug. ***
