Community
Participate
Working Groups
Lines numbers aren't printed along with the code. Line numbers are necessary when doing code reviews.
not for 2.0
Reopening for 2.1 consideration
*** Bug 6877 has been marked as a duplicate of this bug. ***
*** Bug 29737 has been marked as a duplicate of this bug. ***
this pr has been deferred for 3.0
*** Bug 31029 has been marked as a duplicate of this bug. ***
Is this functionality still committed for the 3.0 release?
There are currently no plans to implement this for 3.0
*** Bug 51605 has been marked as a duplicate of this bug. ***
Seems like nobody at eclipse project ever do code reviews? Line numbers are essential for that.
This would be great if this functionality was added. It would make code reviews a dream come true
This would be very useful, and would seem to be fairly simple to add since the capability to view the line numbers already exists. Why has it been left out until now (for the past several years)??
Is this a possible fix that can make it into 3.1?? There obviously a ground-swelling of people who want this implemented. It would be a HUGE help for code reviews. Please give us an update on when this is planned to be implemented.
There are no plans to include this in 3.1 unless we receive a high quality patch.
It is a shame that eclipse does not manage to do this.
(In reply to comment #14) > There are no plans to include this in 3.1 unless we receive a high quality patch.Why is print formatting (header, footers, line numbers, etc.) not seen as an important feature? I creates a significant NEGATIVE opinion of the product in enterprise settings that have any kind of formal development framework, because it requires you to print the code in another tool for code reviews etc. I urge you to strongly reconsider the priority the whole issue receives. I can see this one issue preventing the adoption of Eclipse in some shops despite all its wonderful features and its great community.
I couldn't believe eclipse REALLY can't do this. Can't be too difficult -- OK i know :-) I don't know how you guys do code reviews, but it really is a necessity. Besides this is really embarassing for such a highly praised tool. This is the ultimate argument for a project manager to nuke eclipse. Really. Tzzz
This is a must-have for a large development shop like ours. We need to have line numbers and customizable headers and footers.
Code inspections are an integral part of our software development process. The inability to print with line numbers is very discouraging. I'm surprised this is not a high priority fix.
*** Bug 106476 has been marked as a duplicate of this bug. ***
Is there any news on the status of this bug? Will it be fixed? If so, when? If you are looking for someone to submit a patch, in what part of the architecture should we begin looking? I am not a commiter so I am not familiar with where everything is, but at least someone can begin working on it if no one has already.
>Will it be fixed? If so, when? As you can see in the keywords field help is wanted to fix this i.e. we currently don't plan to work on this unless there's a high-quality patch attached to this bug report. The interesting code points to loo at are TextViewer.print() which currently delegates to the StyledText widget to print the text.
Created attachment 26998 [details] Quick and dirty fix This quick fix provides the absolute minimal functionality that I required. Please improve upon it as your needs dictate. Apply in the root directory of the source archive contained in eclipse-sourceBuild-srcIncluded-3.1.zip: patch -p1 < eclipse-SDK-3.1-print-line-numbers.patch
The patch is for Platform SWT. It will fail if code folding is enabled. Feel free to submit the patch to Platform SWT.
I have been working on a patch for this and I think I got it all in pretty good shape over the weekend. I will attach three patches (swt, jface.text and ui.editors). The patches will be against what I found in HEAD this morning. There are some new api added in the swt and jface.text but they should not break anyone and the existing default behavior (if the line number ruler is not showing) is not changed. The solution is not specific to printing line numbers. It is generic to printing any kind of annotation in the leading or trailing margin (left and right when in a LTR orientation). It also supports various options for aligning the notations within the margin. I have implemented line numbers as a leading margin print annotation when the line number ruler is showing (right aligned so that the column of numbers look correct). It handles folding correctly (even prints a '+' at the fold point without losing alignment of the column of line numbers. I also fixed a bug where the spliting of a line across a page boundary was not handled correctly. I have added a couple TODO tags to SWT where I think a couple more changes could be justified (for example, where the header and footer are printed if they are specified in the options). We should discuss those separately however. Comments very welcomed.
Created attachment 34574 [details] SWT portion of the patch
Created attachment 34575 [details] JFace portion of the patch
Created attachment 34576 [details] SWT portion of the patch -- again Oops... now why did I check the obsoletes the SWT patch check box as I posted the JFace patch? ;-(
Created attachment 34577 [details] UI Editors portion of the patch Keeping my dirty hands of the obsoletes checkboxes this time ;-)
Adding Steve N to assess the SWT portion of the patch. Steve N, if someone else on SWT should look at this, please add them. Thanks.
Moving to Platform SWT for their portion. Once this is in I can go ahead with the Platform Text part.
It is great to see this issue getting fixed! I have followed the bug for a while and I would like to thank you for your effort! Thank you Steven!
Thank-you, thank-you, thank-you for working on this. (Just had a small accident while carrying the printout for 25 classes down a staircase. Had my hand jostled and the printouts went flying. Since there are no headers, and trying to re-construct which source code page belonged to which class, never mind which order, is next to impossible, I ended up re-printing everything. Class by class, since you cannot select a bunch of classes for a mass print).
Has anyone on the SWT team had a chance to look at the patch? Would it be possible to get this in 3.2 M6? This would require PMC approval since there are additions to the api, however, there is quite a bit of community interest in this bug so it may be worth it. Of course, it would only be worth it if the jface api additions were approved too.
If I may make a suggestion for the implementation? Headers need not be identical: The header for the first printed page could be quite large and contain a lot of information such as actual file name, package/class, last modified date, size in bytes, Date printed, etc The header for page 2+ would have only the package/class, date printed, and page X of Y Page X of Y: This requires two passes through the code. The first to establish the number of pages required, the second to actually print the code. All printing rules would be followed during the first pass, just no output Line Numbers: The line numbers would follow the line numbers showing in the editor. So if the editor had: 1 line 1 2 line 2 3 Line three is a very long line 4 line 4 5 line 5 The printout would show: 1| line 1 2| line 2 3| Line three is a | very long line 4| line 4 5| line 5 Odd/Even printing: This is for printers which do not have a duplexor. You would first print the odd pages, then place the printed o/p back into the printer (flipped) to print the even pages. Gutters: Alternating gutter margins for odd/even pages. This is useful for duplex printouts which are bound. I have written a list utility (in C, a lot of years ago) which does all this. If needed I could try to locate the source. Thanks!
I've been tracking this bug for several years and can't believe it is not fixed yet. Event when the patch is available nobody wants to move it. This feature should have been implemented in the initial version and the fact that is it still not available shows that priority of the Eclipse development team is misaligned with real needs of development community. I guess it will not be fixed in 3.2?
>that is it still not available shows that priority of the Eclipse development >team is misaligned with real needs of development community. Wow. That's a pretty strong statement for this bug given all the other things that Eclipse does for you. Go ahead and apply the patch and it can be fixed for you.
There is no way we can get to this for 3.2. We are at RC3 and way past API freeze. Ping early in the 3.3 development cycle. Thanks and sorry for missing this one.
Sorry Dimitry, when this bug was assigned to me we were only a few days away from the API freeze. I'll work on this after the release.
I guess the strong language did accomplish the goal. I did not mean to offend anyone but I strongly believe that this should be a part of core functionality for any decent code editor. I understand that is is too late for 3.2 and will patiently wait for 3.3. I do believe that Eclipse is by far the best IDE and RCP platform available.
>I guess the strong language did accomplish the goal. I wouldn't say that. The bug is legit and has lots of votes. Strong language tends to put people off rather than help.
Felipe, when you are ready to get back to this please let me know. I have not had any time to further work on the patch and I have a few ideas on how it could be better. As for comment 35, the correct numbering when line splitting is already handled by the patch as you mention. As for the rest, those are interesting ideas but may be beyond the scope of what we would want to do for what is basically a simple text editor and not a work processor. A nicely decorated text editor in several extended usages like the Java editor, but still a text editor. For example, wrt to gutters, how many people would ever really need or want to bind Java code listings? The most interesting idea to me in comment 35 is the page x of y thought. Comments?
Let me suggest two enhancments that would make printing with line numbers more useful: 1. Capability to adjust font, or at least the font size. - This would allow printing in a small font to minimize the number of folded lines and pages, or a larger font size for offline markup and editing. 2. Either a header or footer, preferably with page numbering capability. - This would allow those of us who are clericly challanged to keep better track of things by adding information like date, project and file name.
Hi Felipe, now that 3.2 is out the door would you be able to make a firm statement about this fix being in the next release, i.e. 3.3?
Sure, I'll work in this item soon (one or two weeks time).
Regarding <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=19602#c42">comment 42</a> and having differing headers (and my reason for it). We have all had that last page print out with its lonely closing curly brace. Having headers which are as tight as possible (yet providing sufficient identifying information) saves paper. Yet you still want to know about the file. Which is why I had my printing app print a lot of info in the header on the first page, yet minimal info on subsequent pages. Just a thought :-)
Fixed in HEAD > 20060720 I added a very simple support, a flag in StyledTextPrintOptions named printLineNumbers.
Felipe, thanks for the update but as noted in comment 24 this simple fix will not work when code folding is enabled. What you have done is probably a good solution for anyone using StyleTextPrintOptions. The more I have thought about this I think the patches I proposed need to be moved out of the current api that involves SytledTextPrintOptions and I need to instead create a new more advanced api that involves an entirely new options class (StyledTextPrintOptions2 ???). At that point I think I would add providers for all four margins and not just the left and right. What you think? Should a new feature request be opened to track this? Hopefully I will have some time to dig back into this later this month.
The option to use a smaller font for printing with line numbers could make code more readable by cutting down on the number folded lines. It can also save a lot of paper. I find a 9 or 10 point sans-serif font quite useful or offline review of code.
This issues probably should not be marked as "FIXED" until a robust solution is implemented. As I understand the solution submitted in 3.3M1, it is not robust. (I gather that fonts, page headers, and code folding are still issues.) Discussion of implementing this feature as a plugin has been suggested using integration with PaperClips -- with code for the proof of concept. http://www.eclipseplugincentral.com/PNphpBB2-viewtopic-t-1334.html Starting with a robust API would be easier than starting from scratch. On my list, this feature is important enough to merit inclusion of such an API into the core distribution. I guess BIRT would also have some tools to offer. Just a humble suggestion to consider for a sticky problem. Please consider re-opening this issue until the solution addresses the broader issues discussed in the comments. This is more than just "line numbers".
So which 'patches' do I need to install? Just the last two? And more importantly, will these patch 3.2?
*** Bug 171588 has been marked as a duplicate of this bug. ***
We should either reopen this bug or create a new one because the initial feature request isn't available yet i.e. no line numbers are printed along with code. Sine it would not be good to always print the line numbers we need an enhanced PrintDialog where this can be set. Currently clients are not allowed to subclass it.
Steven what is minimum set of features you need to have this working for Eclipse ? 1) Page Header and Page Footer - We already have that since 2.1 2) Custom font for Line Number - low priority IMO 3) Set the number for each line (for folding) - I agree we need this. Could we get this to work with a int array in StyledTextPrintOptions instead of having a callback mechanism ? I think you used some sort of callback in the patch you sent. I'm not sure I like the callback. Remember that printing runs on a different thread, the callback might not be able to access the thread that owns the content, or the content can change during printing). 4) Margins - low priority IMO -------- Daniel, I'm not sure we can customize the OS PrintDialog to add a print lines check box. On windows I think we can do it, but carbon and gtk I don't think so. Can you add a preference page option for this ?
>Can you add a preference page option for this ? You might want to print line numbers for Fortran but not for Java and text. Each editor kind would have to add that preference which is not a feasible approach.
Would it be possible to wrap the OS dialog in your own or does the OS dialog need its own shell?
I am the person that submitted this bug (in 2002), so I see the comments as they are posted. I just noticed comment # 55 which states: "You might want to print line numbers for Fortran but not for Java and text." I might have mis-understood this comment, but the bug came about because our team was holding code reviews for Java and found it very hard to do this without line numbers. This is especially true if you don't have everyone in the same room. I don't follow the correlation of language and need for line numbers.
I will attempt to answer the questions from comment 54. First, note that my patches are more general than just printing line numbers. They enable the printing of any sort of leading or trailing (Bidi enabled) margin decorator that can be represented as a (short) string, of which line numbers are one example. There are many other possibilities. Also note that I think I have these patches ported on top of 3.3 M1 somewhere on my machine. If it would help to have updated patches from back then, I can root around for it. >>1) Page Header and Page Footer - We already have that since 2.1 Yes, but it is not implemented quite right. Currently, if a header or footer is specified, the space for it is taken from the print area. It should really come from the default (or specified, if we add that support), top and bottom margin areas. My patches do not address this issue. >>2) Custom font for Line Number - low priority IMO Not real important for line numbers. Could be important for others. Certainly lower priority than the rest of this. >>3) Set the number for each line (for folding) - I agree we need this. Could we >>get this to work with a int array in StyledTextPrintOptions instead of having >>a callback mechanism ? >>I think you used some sort of callback in the patch you sent. I'm not sure I >>like the callback. Remember that printing runs on a different thread, the >>callback might not be able to access the thread that owns the content, or the >>content can change during printing). An int array would not provide the flexibility of the callback since it would only support line numbers or some other number that had meaning. The int array would have to be a full mapping of the StyleText widget line numbers to the document model line numbers. This would require to TextViewer subclasses to overright the TextViewer#print() method (certainly possible) and to create the mapping at that point. I am not sure about how feasible it would be to create the map at that time since I have not tried it, but it sounds possible. Also, I think a String array (or map) would be better. You could get back some of the flexibility (maybe all - if you enable two maps, one leading and one trailing). You could get back the one important aspect of having strings that I did take advantage of in my patches, putting the '+' character in the string at the fold points. It makes the print out with folded lines much easier to scan. I honestly can not remember exactly why I went with the callback back when I did this. I think it was because it seems to work more naturally with how the jface text viewers and the AbstractDecoratedTextEditors behind them operate. As for the thread issue, the callback is done along with all the other data caching and copying that was already being done before thread launch in order to avoid that problem (see StyledText.Printing#cacheLineData()). So, that is not an issue. Also, note that StyledText.Printing does not handle the print page range nor print selection options from the print dialog exactly right. This includes copying everything, including calling all my line number mapping callbacks, when it is not all really required. If this is ever optimized one day, the callbacks would get the same benefit. The design that would have the TextViewer calculate the mapping before calling StyledText#print(...) would not be able to optimize this since the print dialog would not have been shown yet. >>4) Margins - low priority IMO Lower priority perhaps, but really nice. Right now in the preferences, General->Editors->Text Editors, there is an option called "Show print margin" (includes be able to specify a number of characters for width) that is worse than totally useless without this support, it is downright misleading. I have not done the work on this, but it would be great to not only be able to specify margins that are a particular size but also be able to say the the print area needs to fit the number of characters specified in that preference. It could be accomplished by shrinking the print font and making small adjustments to the specified margins to hit the "n*fontWidth" calculation just right. Also, note that the current right margin calculation when no margin is specified is wrong (comments say it will be one inch but it is less). I think I noted that in my patch but did not fix it. I did not want to change the existing behavior when print options are not specified. If we went without being able to specify margins sizes, we would probably want to fix this.
That was just an example. The point is, that while it makes sense for code reviews you probably don't want line numbers printed for normal text files.
With regard to comment 55 and comment 57, I do not think there is a need for any new preferences nor print dialog options to indicate if line numbers are printed or not. At General->Editors->Text Editors in the preferences dialog there is already the "Show Line Numbers" option. If this support is added, I would expect that if line numbers are showing that they would be printed and if they are not showing, they would not be printed.
You're right. We already have that preference for the UI and could simply reuse it for printing. >>4) Margins - low priority IMO >Lower priority perhaps, but really nice. Right now in the preferences, >General->Editors->Text Editors, there is an option called "Show print margin" >(includes be able to specify a number of characters for width) that is worse >than totally useless without this support, Maybe the name is misleading but calling this totally useless goes too far because if enabled the margin is shown in the editor and this is really helpful especially if you format your code with same max line width.
Okay, totally useless was a bit harsh. Sorry about that. I was focused on the print aspect and it does not affect the print margin at all as implied by the name. Having a margin indicator in the editor is certainly useful at times.
Steven: If we add String[] lineLabels to StyledTextPrintOptions. Is that good enough ? ;-) I mean, I think margins is totally different problem at this point and probably deserves its own problem report. --- Dani: >You're right. We already have that preference for the UI and could simply >reuse it for printing. So we don't need to touch PrintDialog. Right ?
>So we don't need to touch PrintDialog. Right ? Yes, we can link it to the existing preference that we use for the UI.
A couple of things are not clear to me from the discssion. (Being a intermittant, part time programmer I havn't had a chance to look at the patches. My usage may be different from most programmers. I don't like looking a screen for long periods so I do considerable review and change planning off line with hard copy and pencil.) In the curent fix: 1. Can one specify a font size? Smaller to minimize line folding; Larger for visually impaired or projection. 2. Will it be possible to minimize top and bottom margins. It is not clear to me why one needs big margins on any edge except where 3/4 inches could be used to hole punch for a binder. 3. What is the status of printing for folded lines? How would a folded or multiply folded line appear? What are the options if any?
>>If we add String[] lineLabels to StyledTextPrintOptions. >>Is that good enough ? ;-) Probably, but the key would then be to get the jface viewers to change to use it. Of course, that would be a key in any of these solutions. You would need to validate the size of the array agains StyleText#getLineCount() or be defensive about reaching the end of it. Also, are you proposing one array or two? And would the one, I think that is what you are proposing, be a LEFT margin array or a LEADING array (move to the RIGHT margin if running in RTL)? My patches support that, but interestingly, if you run in RTL with line numbers on, they still show up on the LEFT of the editor. If I recall correctly, I think this is intentional. You may want to let the caller specify if they want them on the LEFT or RIGHT. In the case of numbers, you will want to align the number to the RIGHT (align the units, tens, etc colums like the editor). If the caller adds the '+' character to some lines they should take care to add a ' ' to the others. You may want to mention that in the Javadoc. Of course, there could be cases of things other than numbers where a different alignment would be better. You may want to consider an alignment settings (within the margin) of LEFT, CENTER and RIGHT. My patches had that. So, the simplest implementation would take a single String[] that was always on the LEFT and the text was always RIGHT aligned within that margin (with a note about the '+'/' ' thing). That would solve the original problem that this bug was opened for. Note that I did not raise this requirement, it just seemed like an interesting problem so I dove in. A more complete implementation would take two String[], one for the LEFT and one for the RIGHT (would leave the RTL question to the caller) and would allow an alignment attribute to be specified for each (LEFT, CENTER, RIGHT). I think if you did the simplier one now and named the String[] option leftMarginDecorations or similar, it would be relatively straight forward to expand the API into the more complete solution in the future if needed. So, yes, I think the simpler solution is the the way to go for now.
Regarding folded: code: the question is whether we print what we see in the editor or whether we should print the full text. Other commands take the full folded code and not just what's seen in the editor (e.g. copy).
Created attachment 59913 [details] patch line labels Steven, please test this patch and let me know if you are okay if this fix.
I would like to request that this bug be re-opened, as it hasn't been resolved and I cannot print line numbers. While I understand that there are patches available, those patches do me no good as I use a binary distribution on three different OSes and I don't have the time nor desire to patch all of them. I also use eclipse at work and school, and I can't patch those installs either. This has been ongoing for close to five years now, and as many people have stated, this should be part of the core functionality. Is there any idea when this will be fully resolved - that is, I can take a stock, binary eclipse install, add my plugins and be able to print line numbers?
How can this be declared fixed - I've got 3.3, build: I20070323-1616 installed. I turn on the option to display line numbers as per comment 60. I print out a file and I get no line numbers. So please tell us how this can be fixed? My current workaround - open the files in notepad++ and print them out from there. Is there anyone else who thinks this is embarrassing? (BTW I'm not trying to pick on Felipe or Steven).
I've just tested the final Europa release (3.3) with CDT4.0 and there are no line numbers in printed file! This bug should be re-opened.
If this bug really is RESOLVED/FIXED, would it be possible to add instructions to the "What's new?" discussion telling how to do so? I have a freshly-downloaded copy of JDT 3.3.0.v20070606-... running on Platform 3.3.0.v20070612-... with "Show line numbers" checked. The line numbers display properly in the Java source editor, the XML source editor, and the text editor. However, line numbers are not printing from any of those editors. Is there another preferences option to be set, or is this bug not resolved?
I guess this problem is confusing people. So let me make this clear: I did fix this in SWT, unfortunately the JDT-UI could not use it because the support I added in StyledText was not sufficent (it did not handled folding properly). So I added a patch in comment #68 to fix this. Steven Wasleski: with the support proposed in my last patch can you fix this problem in your side ?
I think the Platform UI team would need to make changes to use this, probably similar to what I did in my suggested patches. But they would be the best people to assess the proposed change's fit. If done properly, the JDT team should not need to change anything and all editors based off the AbstractDecoratedTextEditor should benefit.
>I think the Platform UI team would need to make changes That would be Platform Text, see bug 6877. I'll take a look and report back.
OK, I looked at the current solution and the patch. The current solution has two problems: 1. As already mentioned it is not possible to provide the line numbers and even without folding it will be wrong as StyledText line number printing starts with 0. 2. The line numbers are printed too low (using Courier New Regular 10) compared to the text (see attached picture). The patch allows me to fix problem 1 but problem 2 persists. I suggest to commit the patch right now and track problem 2 in a new bug. This would allow us to ship this new feature with 3.4 M3.
Created attachment 80953 [details] Postscript file showing alignment problem
Kevin, please release the patch.
released Felipe's patch (from comment #68) to HEAD.
This bug is now fixed. I filed bug 207558 for the alignment problem.
