Community
Participate
Working Groups
Created attachment 253772 [details] Print margin is wrong (cursor is on a line of exactly 100 characters Font: Anonymous Pro (it's a fixed width font) Font size: 18 Eclipse version: Mars (4.5) RC2 I set the print margin at 100 characters, but it is drawn between character 92 and 93 (see screenshot). This happens in any editor, including the plain Text Editor. If I set the font size to anything below 16 it seems to work fine. Anything above triggers this bug. I could not reopen any of the old issues relative to this bug.
Created attachment 257072 [details] Example of the issue where the margin is wider than set I have the same issue: Version: Mars.1 Release (4.5.1) Build id: 20150924-1200 Eclipse C/C++ Development Tools Version: 8.8.0.201509131935 Font: Source Code Pro Font Size: 11
The print margin seems to have stopped working when upgrading to Mars.1 (from Mars). I have two systems with different behavior: 1) Print margin is stuck at 80 chars regardless of the setting. 2) Print margin is not shown at all. Setting is 120 chars and this worked fine in the Mars release Both systems are running: Version: Mars.1 Release (4.5.1) Build id: 20150924-1200 Eclipse C/C++ Development Tools Version: 8.8.0.201509131935 Font: Hack Font Size: 9
Confirm bug: print margin is stuck to 80 characters. Changing the value of "Print margin column" does nothing, the margin is always drawn at 80 characters. Version: Mars.1 Release (4.5.1) Build id: 20150924-1200 Eclipse C/C++ Development Tools Version: 8.8.0.201509131935 Font: Monospace Font size: 10
I confirm bug. You can turn it on & off. You can change the color. However, the column stays stuck at 80. Version: Mars.1 Release (4.5.1) Build id: 20150924-1200 Eclipse C/C++ Development Tools Version: 8.8.0.201509131935 Font: Monospace Font Size: 9
I see this as well. Note that the line shows up in the correct column in the JDT editor but not the CDT editor, so this is likely a CDT specific issue.
I also have it only in CDT, not in other editors like PyDev. Mars 4.5.1 on Ubuntu.
Is this confirmed as a CDT issue? Does it happen with the Java Editor too?
@Lakshmi, as I said in my initial report this happens in any editor, including the plain Text Editor.
When I upgraded to Mars, it kept the old print margin at 120. But then I switched workspaces and found that in other workspace it was drawn at 80 no matter what I tried. I compared workspaces and found that by setting org.eclipse.cdt.core.formatter.lineSplit=120 in the org.eclipse.core.runtime/.settings/org.eclipse.cdt.core.prefs of the other workspace I can force the print margin to be drawn at the correct column.
(In reply to Andris Zeila from comment #9) > I compared workspaces and found that by setting > org.eclipse.cdt.core.formatter.lineSplit=120 in the > org.eclipse.core.runtime/.settings/org.eclipse.cdt.core.prefs of the other > workspace I can force the print margin to be drawn at the correct column. Andris, thanks very much for that tip - it worked for me. In case anyone else wants to use this tip, and is as clueless as me about where the configuration files are, here's a bit more detail... From your workspace directory, the full path the sub-directory that contains the settings file is: .metadata/.plugins/org.eclipse.core.runtime/.settings Within that sub-directory, find the file: org.eclipse.cdt.core.prefs Within that file, find the line that has this: org.eclipse.cdt.core.formatter.lineSplit=??? Insert the value you want.
In Neon Version: Neon Release (4.6.0) Build id: 20160613-1800 I see that the Preferences->General->Editors->Text Editors "Print Margin Column" is overridden by the setting in the Java->Code Style->Formatter->Line Wrapping tab->General Settings->Maximum Line Width setting, with no warning. Took me some time and frustration to work that out.
(In reply to Adam Hardy from comment #11) > I see that the Preferences->General->Editors->Text Editors "Print Margin > Column" is overridden by the setting in the Java->Code > Style->Formatter->Line Wrapping tab->General Settings->Maximum Line Width > setting, with no warning. > > Took me some time and frustration to work that out. Thank you!!! I was struggling to reproduce it (and I've also seen this before many times) , and now I'm really surprised to confirm that baffling inconsistency. If I get it right, both JDT and CDT (and whoever else in the plugins world) has introduced different settings for their editors, which effectively override whatever is set under the General -> Editors -> Text Editors. I will move this bug to Platform UI, because this is something we must do in UI, but this affects all contributors to this preference. org.eclipse.ui.internal.editors.text.TextEditorDefaultsPreferencePage should *at least* warn that custom editor implementations may override the value. Ideally this should provide a "per editor" list and also "don't care and use global value" checkbox.
*** Bug 495490 has been marked as a duplicate of this bug. ***
(In reply to Adam Hardy from comment #11) > In Neon > > I see that the Preferences->General->Editors->Text Editors "Print Margin > Column" is overridden by the setting in the Java->Code > Style->Formatter->Line Wrapping tab->General Settings->Maximum Line Width > setting, with no warning. Oh thank you Adam! Nice find!!
(In reply to Adam Hardy from comment #11) > I see that the Preferences->General->Editors->Text Editors "Print Margin > Column" is overridden by the setting in the Java->Code > Style->Formatter->Line Wrapping tab->General Settings->Maximum Line Width > setting, with no warning. > > Took me some time and frustration to work that out. For me both of those are set to 120 but the line is unfortunatley dispayed at 127.
I have created bug 506166 for the case where the position of the print margin is wrong because the actual average character width is non-integer.
(In reply to Adam Hardy from comment #11) > In Neon > > Version: Neon Release (4.6.0) > Build id: 20160613-1800 > > I see that the Preferences->General->Editors->Text Editors "Print Margin > Column" is overridden by the setting in the Java->Code > Style->Formatter->Line Wrapping tab->General Settings->Maximum Line Width > setting, with no warning. > > Took me some time and frustration to work that out. Well done Adam. This has helped me in the C++ editor, however, in general, there should be no link between the "Maximum Line Width" for a language formatter and the "Print Margin" so this needs to be fixed by someone. If they want to display two lines, fine, but this behaviour is just wrong.
I have both options set to 80 but the line is drawn at position 120.
(In reply to John McCabe from comment #17) > (In reply to Adam Hardy from comment #11) > > In Neon > > > > Version: Neon Release (4.6.0) > > Build id: 20160613-1800 > > > > I see that the Preferences->General->Editors->Text Editors "Print Margin > > Column" is overridden by the setting in the Java->Code > > Style->Formatter->Line Wrapping tab->General Settings->Maximum Line Width > > setting, with no warning. > > > > Took me some time and frustration to work that out. > > Well done Adam. This has helped me in the C++ editor, however, in general, > there should be no link between the "Maximum Line Width" for a language > formatter and the "Print Margin" so this needs to be fixed by someone. If > they want to display two lines, fine, but this behaviour is just wrong. This was done in 4.6 to fix Bug 474062 & Bug 306646 (Print margin should differentiate on file type) .
The implementation is fundamentally wrong. The original request in those stated: "The "Help > Preferences > General > Editors > Text Editors > Print margin column" is helpful to adhere to the style rule, but it's the same for all file types, which means it can be either 80 or 100 columns, but not auto-adjustable according to the file type I'm currently editing." That doesn't mean that the existing functionality should be changed; it means you should be able to over-ride or enhance that functionality. What you need is a print margin option, with either: 1) An option to override the print margin setting based on the filetype's formatter settings OR 2) A SEPARATE option to display a line representing the formatter's maximum width setting, independent of the print margin line.
Please forgive the very long comment, but I'm adding some recent comments/discussion that I've been involved in on bug 306646. It seems a bit pointless having the discussion against that enhancement as it's been done and closed. This one, on the other hand, is still open. If any of you who have already commented here, or voted for this bug, have anything to add that might help support my argument that "print margin" for an editor should not be conflated with a language editor's "maximum line length", please add your thoughts. In the meantime: **** **** Comment 40 John McCabe 2017-01-06 07:19:27 EST **** The implementation of this has resulted in the creation of https://bugs.eclipse.org/bugs/show_bug.cgi?id=468307. You made the wrong choice by not creating a separate option. You have changed existing print margin behaviour based on a vague suggestion, from one person (with a small number of votes), that it might be nice to see what a specific file type's formatter preferences are. The bug report I mentioned above currently has 12 votes, more than double what this 'enhancement' had, which supports the idea that you got it wrong! Existing behaviour should've been retained, with either: 1) an additional option to either allow the editors to override the print margin setting or 2) have the option (as mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=43730) to have multiple lines. **** **** Comment 41 Stefan Xenos 2017-01-06 09:02:21 EST **** I skimmed bug 468307. It shows some user confusion about the fact that the preference has moved. Some degree of user confusion is expected whenever something changes. As far as I can tell it does not make a positive case for why it is preferable to draw the print margin in a different location from the wrap position. Did I miss it? **** **** Comment 42 John McCabe 2017-01-06 09:57:13 EST **** There are a number of points raised on that bug report. First of all, it's not really confusion that the preference has moved, it's the fact that the preference continues to exist as it has for years, but its behaviour has changed with no clear explanation of how it's changed, or what the benefit to the majority of Eclipse users is. How many users' time did you intend to waste in wondering: 1) what on earth has caused the line to move from where it has been for years? 2) why modifying the "print margin column" value in the preferences is having no effect on where the margin is being displayed? If you follow that thread you'll see that it's because one user managed to work out that the line position seemed to be related to a value in a settings file somewhere within their workspace that people are now able to understand where the change has occurred. The other main point is that the line is still shown in the main preferences tab as "Show print margin", "Print margin column" etc; it is NOT shown as "Show formatter wrapping point" etc. Yes, the window shows "Some editors may not honor all of these settings." but, from my point of view, if that's the case then I'd expect, at the very least, for there to be a corresponding "Print margin column" in the specific editor settings (e.g. in Preferences -> C/C++ -> Editor). What I would NOT expect is have to track the actual setting down to some random field in a formatter's configuration that's: 1) not even under the "Editor" settings 2) named something completely different from "Print margin" (Maximum line width in the case if C/C++). Also, if I'm using different languages and want ALL of them to show the same print margin, why should I need to go to EVERY languages formatter settings and make sure they're the same? What you have done is tied a setting related to a physical limitation (i.e. the maximum number of characters that will fit on one line on a particular printer) to a setting that's an arbitrary limit that, nowadays, has no relationship with physical devices. I might want to know exactly what my printer can handle so that, when I'm writing code, I can take account of that and wrap my lines manually to cope, but that doesn't mean that I want to change my company's standard setting for line length for a specific printer. From my point of view, the main principle here is don't change the behaviour of existing features, unless the behaviour is wrong. In this case, there was nothing wrong with the existing behaviour so, to satisfy the OP and the (I suspect, very limited number of people who appear to have voted for this enhancement), you should have made this enhancement optional. It's clear from the discussion on the ticket that a number of people have suggested this (e.g. Dani in Comment 16) but you have decided that you know better as can be seen in Comment 17 where you state: "I'm currently aware of only one use-case for the ruler: to display the point at which whey want their line wraps to occur." and are profoundly wrong. **** **** Comment 43 Stefan Xenos 2017-01-06 14:58:16 EST **** If I may summarize the points made in comment 42: 1. All UI change has a retraining cost. 2. Many users only work in one language and/or use the same wrap position for all files and projects in their workspace, and such users get no benefit from the new feature. 3. Some users may be using the ruler to visualize how their code will look when printed on a physical printer rather than to visualize the text wrapping position. 1 and 2 are the trade-offs that are made whenever anything changes in the UI. No feature is ever used by 100% of users. We can discuss ways to help users discover the new preference location easier, but for a user that knows where to find it the new preference is pretty much as easy to change as the old one so this isn't an argument against the change. 3 is a use-case we didn't consider when making this change. I'd suggest we focus on this since it's a use-case we legitimately can't handle as well with the new code. Could you help me understand 3 better? Why would you want to visualize the width of your printer paper if you don't plan to wrap your code at that point? Are there really a significant number of users who still make physical printouts of their code, or is this just a theoretical problem? ***** It's the weekend, but I'll add my own further comments when I'm back at work next week. Many thanks.
The term "print margin" was a misnomer from day one. Would it resolve the confusion if the misleading term "print margin" were replaced by "right text margin"?
I don't see much of a use case for a print margin that's distinct from the formatter's line wrapping width. However, the user confusion from having a setting in General -> Editors -> Text Editors that's ignored for code files, is real, and IMO a problem. I think there should be a warning under that setting, saying that the column is overridden for specific languages, and maybe even linking to the place(s) where the overriding value can be changed.
Sergey, I'll try to address your comment more fully when I get the chance, but I think Monica Cellio's comment at http://ux.stackexchange.com/questions/8407/making-changes-to-existing-products?rq=1 may be relevant. In the meantime Stefan, refer to https://bugs.eclipse.org/bugs/show_bug.cgi?id=481401#c11 for a description of another missed use case. And also to http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-texteditorprefs.htm which does not mention anything related to the print margin setting being overridden. And also to bug 476248 where the same issue was discussed and another use case ignored.the
(In reply to John McCabe from comment #24) > I'll try to address your comment more fully when I get the chance, but I > think Monica Cellio's comment at > http://ux.stackexchange.com/questions/8407/making-changes-to-existing- > products?rq=1 may be relevant. I agree that the user confusion issue needs to be addressed. I propose that it is addressed by changing wording in the Text Editors preference page. > In the meantime Stefan, refer to > https://bugs.eclipse.org/bugs/show_bug.cgi?id=481401#c11 for a description > of another missed use case. This use case looks contrived. Lack of trust in Java formatter was probably related to formatter bugs that have already been fixed. If the requirement is to have two different line wrap position, one for comments and another one for code, this is a feature request for the Java formatter. > And also to bug 476248 where the same issue was discussed and another use > case ignored. What use case are you referring to specifically?
(In reply to John McCabe from comment #24) > In the meantime Stefan, refer to > https://bugs.eclipse.org/bugs/show_bug.cgi?id=481401#c11 for a description > of another missed use case. Quoting from that comment: > This is somewhat frustrating, because I had previously set the wrapping > boundary to 9999 in order to effectively disable automatic wrapping, but I > wanted to still see where column 80 is so that I can selectively wrap > comments manually. I think disabling automatic line wrapping altogether is a reasonable use case. However, I think setting a value to 9999 is a poor way to go about it. Instead, we could have a checkbox for automatic line wrapping that you just uncheck. The print margin can then revert to the default Text Editor setting, thus satisfying this use case.
(In reply to Nathan Ridge from comment #23) > I don't see much of a use case for a print margin that's distinct from the > formatter's line wrapping width. I do have a use case for exactly that scenario. I want to see when I'm approaching 80 columns and if I'm over or under it, however my formatter is set to *automatically* wrap at 120 columns and above. Because it is totally okay if I go above 80 columns, but it is a hint that maybe the line is becoming too long, but it might still be okay. Actually, I'd have three print margins if Eclipse would allow it, one at 72, one at 80 and one at 120. Now with the print margin showing up at my hard wrap settings of 120+ it is barely inside the code window and if I want to know how close I am to 80 columns I have to move my eyes to the lower right of the window (which is at least half a screen away). Of course, as a workaround I could set the line wrapping margin to 80 and manually disable line wrapping on *every* option selectively (because comments and documentation should still wrap at 80 columns) and that's also most likely what I'm going to do. But all I want is to show that print margin at 80 columns on *all* files I open, no matter what file, no matter the formatter settings. Well, actually, I want multiple print margins, really. So, yeah, I *do* have a use case for that, if you care or not about it (or consider it stupid) is of course none of my business, but incidentally my problem.
(In reply to Sergey Prigogin from comment #25) > (In reply to John McCabe from comment #24) <..snip..> > > And also to bug 476248 where the same issue was discussed and another use > > case ignored. > > What use case are you referring to specifically? Stefan provided details of the use case "Z" Zorzella described in comment 3.
(In reply to Robert Zenz from comment #27) <..snip..> > So, yeah, I *do* have a use case for that, if you care or not about it (or > consider it stupid) is of course none of my business, but incidentally my > problem. Further to Robert's comments, and my earlier ones in response to Stefan: Yes, people do still print code out, at least I do. I work with a lot of 'legacy' C & C++ code. We have code that's been evolving for 15-20 years and have functions that are very large, and oten have sections that are pretty much copied and pasted within e.g. different parts of a switch or if statement. Even with the large monitors I used these days, it is often not possible to see the whole function on the screen. Splitting the editor view has helped but that also narrows the view. By printing sections of code out and sticking the pages together I get a way of seeing the code that: a) Makes patterns of copied/pasted code pretty easy to visualise b) allows me to annotate, on paper, where there is code that is similar but may have slight differences that need to be identified as, e.g. parameters, if I'm planning to refactor and extract that code into a separate function c) just in general helps me annotate code to understand some of the potentially over-complicated conditions that have ended up in the code over the years As a result... USE CASE 1: =========== I want to minimise the number of pages printed on these occasions so, ideally, would print in portrait form as I can get more lines per page. However the width of the page can be an issue there as the text will wrap if it goes past the printer's maximum width (this is a device limit, and independent of any coding standard that specifies where code lines should wrap). In such cases it may be better and clearer to print in landscape form. By setting the "Print margin column" in the Text Editors preferences I can see pretty much at a glance whether portrait or landscape is going to be the best format to print in and, as I mentioned, that's totally independent of any fixed line wrapping point specified in my coding standard and, also, is independent of whatever language I'm coding in at the time, which may be C, C++, Assembler, Python, PHP, Ada or Java. USE CASE 2: =========== Where I work we have a relatively bizarre coding standard that specifies that comments added on the same line as a piece of code must, if possible, start at column 65. I'm not a huge fan of putting comments at the end of code lines, but we have shed loads of legacy code that was written that way. For the last 10 years or so I've had my "print margin column" set to correspond with that restriction so that it is easy to see: a) by looking at where I'm typing (rather than somewhere at the bottom right of the display) where I need to start my comment b) where comments are misaligned in existing code as I scroll through Item a) corresponds to the 2nd paragraph of Robert's comment; with increased screen sizes, having the column number identified so far away from where I'm typing is inefficient and annoying Item b) is actually what brought this issue to my notice in the first place. I was going through a code file moving comments to line up with the "print margin column" I'd set and, eventually, it struck me as a bit odd that so many comments in this file were out of place. I then saw that the line had moved from where I set it, and the next couple of hours of my time were spent trying to work out how that had happened, including re-downloading Eclipse, reinstall, reconfigure plugins, set options etc. ================== With respect to these two use cases, as Robert said, you might not care about them, or you might think they're stupid, but they're certainly valid from my point of view and it's how I've been using this feature for a very long time. In addition, they are distinct enough, in my opinion, from a use case describing the display of a line at a formatter's hard-wrap point to be essentially independent. It may be worth mentioning that I don't actually see any reason why anyone actually needs a formatter's hard-wrap point to be identified by a line in the display; you probably ought to know you're getting close to it as you type anyway and, presumably, it'll just wrap and you'll understand why anyway! However clearly my opinion on that doesn't mean there's no use case that doesn't support that behaviour. Ultimately I think the old behaviour should be reinstated and this new behaviour added as an extension rather than a replacement. Over the weekend I took a look at the Eclipse code so I can see, Sergey, that you've replicated Stefan's Java editor change in the CDT. It also seems to me like it wouldn't be a massive job to provide support for two margin painters (if not more) in SourceViewerDecorationSupport. This could either be by changing SourceViewerDecorationSupport or by deriving from it (there are various examples of this if you search on Google for "extends SourceViewerDecorationSupport"). If you did it that way then it would have to be done in both the CDT and JDT, but I don't see that as a big issue; you can work together to get it right. You probably know all this but, when the margin is enabled it's added to the source viewer using addPainter. As I understand it, that call passes the painter through to a painter manager which stores a list of painters. When the view changes, each of the painters in the list is called to do its job. In other words, it shouldn't be too difficult to add an extra MarginPainter in there whose properties can be controlled on a language by language basis and based on the formatter preferences if necessary (i.e. add extra options to the C/C++ and Java "Editor" setting saying "Show wrap margin" such that, instead of calling: support.setMarginPainterPreferenceKeys( AbstractDecoratedTextEditorPreferenceConstants.EDITOR_PRINT_MARGIN, AbstractDecoratedTextEditorPreferenceConstants.EDITOR_PRINT_MARGIN_COLOR, DefaultCodeFormatterConstants.FORMATTER_LINE_SPLIT); You call something like: support.setWrapMarginPainterPreferenceKeys( <some reference to the language's setting for enable/disable>, <some reference to the language's setting for colour>, DefaultCodeFormatterConstants.FORMATTER_LINE_SPLIT); It wouldn't surprise me if this took less time to implement than the extent of hassle people have discovered by this change, and the amount of discussion that's gone on to try to justify the way it WAS done!
Further to my last comment, I can't believe I missed this in the CDT git repository (I thought it was a MentorGraphics specific version when I found that class on Google!): https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/core/org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/editor/CSourceViewerDecorationSupport.java and(from CEditor.java): ((CSourceViewerDecorationSupport) support).setInactiveCodePainterPreferenceKeys(INACTIVE_CODE_ENABLE, INACTIVE_CODE_COLOR); In other words, pretty much all the infrastructure you need is already there in the CDT (as far as I can see), except for an option to enable the wrap limit line in the C/C++ Preferences.
(In reply to John McCabe from comment #29) > USE CASE 1: This use case would be best served by a print preview. > USE CASE 2: This use case would be best served by supporting multiple user-configurable vertical lines.
(In reply to Sergey Prigogin from comment #31) > (In reply to John McCabe from comment #29) > > USE CASE 1: > > This use case would be best served by a print preview. "best served" is subjective. Prior to my description I'd mentioned "printing sections of code out". In order to do that, I would normally find the start point and then use Shift-PgDn or whatever to scroll through the code to the end point. With the "print margin" in place, AS IT HAS BEEN FOR ABOUT FIFTEEN YEARS BEFORE THIS CHANGE, it's quite obvious to me whether the code is going to print sensibly in portrait view before I choose to print. It's much more efficient that way than doing that scroll through to select the text, set up to print preview, scroll through the preview images, and then make the decision. > > > USE CASE 2: > > This use case would be best served by supporting multiple user-configurable > vertical lines. "best served" is subjective. I only need one line I can place independently of any formatter wrapping limit. In fact, this use case and the previous use case, in my situation, don't even suggest a need for more than one line. Since column 65 is not that far from 80, it's actually not difficult for me to use that single line for both these use cases. If you consider that, for 15 years or so, you had a 'product' that showed a line at an arbitrary column based on the "Text Editor" settings, then the fact that someone has said "it would be really nice if we could have a line like that at the wrapping limit in C/C++ and/or Java editors" suggests that you might want to support an additional line that's drawn in those editors if the user chooses to show it. It doesn't, to me, suggest that you should replace existing functionality. Perhaps you could describe a use case where multiple (i.e. > 2 - one as existed for 15 years and one correspoding to the max line length) user-configurable vertical lines are necessary? In other words, how much clutter do you think is generally needed in the editor window? In more general terms, when you decide to change the UI: 1) Where do you retain copies of the use case descriptions that are used to justify the choice of implementation? 2) How do you interact with other existing users to determine the impact on their usage of the UI?
(In reply to John McCabe from comment #32) > Perhaps you could describe a use case where multiple (i.e. > 2 - one as > existed for 15 years and one correspoding to the max line length) > user-configurable vertical lines are necessary? In other words, how much > clutter do you think is generally needed in the editor window? *coughs* I'm all for having multiple, user-configurable, independent from anything else, margins which I can configure (ay, can I even get them in different colors?). I'd like that. So if the print margin as it exists goes away, and instead we get the option to show/hide the wrapper margin of the formatter *and* we can configure a set of margins ourselves, I believe that that would solve all the problems here: 1. For those who believe that it should be the same as the formatter wrapping value, that margin is displayed. 2. For those who want to also have a margin at a fixed number of columns for everything are just setting it. 3. Those who just need the fixed margin are disabling the formatter option. 4. *I* get multiple margins as I always wanted (because I can deal with clutter very well, I can just ignore what I don't need right now). Otherwise I totally agree with you.
Robert, Thank you for your input. I've just re-read your earlier message and saw that you'd like to be able to put lines at 72, 80 and 120 if you could so, I guess, there's a basis for a use case! Are you aware of the IndentGuide plugin (https://github.com/sschaef/IndentGuide)? The attitude of some of the committers here is driving me towards looking at creating something like IndentGuide that's rather less clever than it is now, and just adds vertical lines from top to bottom. The only problem really is that I haven't got the time to support it.
(In reply to John McCabe from comment #34) > Are you aware of the IndentGuide plugin > (https://github.com/sschaef/IndentGuide)? No, I was not. It actually looks quite straightforward from what I can see. One might be able to crank up such an extension in just a few hours. Ahr, great, now my fingers are itching to create such an extension even though I wanted to work on something else...I'll see if I can do it in reasonable time and drop you an email if I can.
Disclaimer: A little self promotion is incoming, but I do consider it a valid fix for this. Not quite satisfied with the current situation, John McCabe and I set down and created a plugin to remedy this: https://marketplace.eclipse.org/content/arbitrarylines ArbitraryLines allows to configure arbitrary lines which are being drawn inside the editor. You can have as many as you want, at whatever position you want inside the editor. The plugin itself is licensed under the EPL and lives on GitLab: https://gitlab.com/RobertZenz/ArbitraryLines
Your "John McCabe and I set down" comment gives me more credit than I'm due Robert; it's all your work. All I did was encourage you and make/suggest a couple of tweaks :-)
*** Bug 519180 has been marked as a duplicate of this bug. ***
*** Bug 519727 has been marked as a duplicate of this bug. ***
Created attachment 269443 [details] Video example of print margin changing column position when editor display changes size I've uploaded a video example (eclipse-print-margin-bug.mp4) of how the print margin column guide changes numerical column position as I change the editor zoom level with Cmd + and Cmd - This may help to explain why different people report different weird positions of the vertical line. Please let me know if this example belongs in a different bug report. There appear to be at least two distinct issues being discussed so far in this ticket: (1) which Preferences settings should and do affect the line's display position, and (2) the fact that even if all those settings are set to 100 the line still sometimes displays somewhere else like column 95 or column 93. This video is meant to demonstrate only the latter. Operating System: macOS Sierra 10.12.5 Eclipse version: Eclipse IDE for Java Developers Version: Oxygen Release (4.7.0) Build id: 20170620-1800
(In reply to Joe Sondow from comment #40) > Please let me know if this example belongs in a different bug report. There > appear to be at least two distinct issues being discussed so far in this > ticket: (1) which Preferences settings should and do affect the line's > display position, and (2) the fact that even if all those settings are set > to 100 the line still sometimes displays somewhere else like column 95 or > column 93. This video is meant to demonstrate only the latter. Could you kindly file a new bug for issue (2), and post your video there? Thanks!
> Could you kindly file a new bug for issue (2), and post your video there? > Thanks! I think that is discussed in 506166.
Not sure exactly where this bug is at right now, but as it is still open I'm adding a vote for it in the meaning of: "Allow me to show a vertical guide in the Java editor which is independent of the formatter line wrapping settings." Out of interest, whatever happened to the suggestion in bug 306646 comment 20? "I can create a boolean preference called "Print margin displays maximum line length". It will be enabled by default. It can live as a checkbox on the Java > Editor preference page. When enabled, the margin will use the java formatter settings. When disabled, it will follow the text editor preference." That simple addition would seem to satisfy all cases? My only suggestion would that it should be disabled by default, so existing behaviour does not change unless the user specifically requests it, although as this change has already been released it may be too late for that now.
*** Bug 526587 has been marked as a duplicate of this bug. ***
(In reply to Barney Barumba from comment #43) > Not sure exactly where this bug is at right now, but as it is still open I'm > adding a vote for it in the meaning of: "Allow me to show a vertical guide > in the Java editor which is independent of the formatter line wrapping > settings." > > Out of interest, whatever happened to the suggestion in bug 306646 comment > 20? > > "I can create a boolean preference called "Print margin displays maximum > line length". It will be enabled by default. It can live as a checkbox on > the Java > Editor preference page. When enabled, the margin will use the > java formatter settings. When disabled, it will follow the text editor > preference." Can't see you getting very far with that one, but a 3rd party plugin now exists (see Comment #36 I think) that will provide you with what you're looking for.
*** Bug 530573 has been marked as a duplicate of this bug. ***
*** Bug 531965 has been marked as a duplicate of this bug. ***
I think as implemented, bug 306646 was a really bad idea. There was discussion in that bug about having a preference to turn of the editor specific behaviour, which would have been directly related to that setting and simply because of that have been a way better idea than adding a vague text at the top of the preference page.
The part about margin being at incorrect column should be fixed via bug 508600 . The one about pref being overriden is the one left IMHO.
Gah, this is annoying. Very frustrating. Very bad user experience. And it shouldn't require a plugin to fix. I think it's unfortunate that the behavior of 'Print Margin' changed with no real warning. This should be restored. If people want to go in and override the print margin for a specific editor/formatter that's fine... but until that override happens all editors should inherit the print margin setting. It's crazy that there exists a setting that users know and love that is being *silently ignored* by *default*. It's absolutely crazy. Then the user either gives up in disgust or googles desperately and stumbles upon this bug. (Got to say it's stuff like thi that really make Eclipse a hard sell.)
Let's fix this. I will add a new preference that allows to override the value by editors. The default will be 'off'.
Fixed with http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=4ed3b6f29149d8c45e8c51b45c35088f3032cdf9 and update documentation with http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=07019408121006b76a5d7f6269e7cbaf75f2a9b1
Dani, Would you mind describing how this works? Does this code: if (fSourceViewerDecorationSupport == null) { fSourceViewerDecorationSupport= new SourceViewerDecorationSupport(viewer, getOverviewRuler(), getAnnotationAccess(), getSharedColors()); configureSourceViewerDecorationSupport(fSourceViewerDecorationSupport); // Fix for overridden print margin column, see https://bugs.eclipse.org/468307 if (!getPreferenceStore().getBoolean(PRINT_MARGIN_ALLOW_OVERRIDE)) fSourceViewerDecorationSupport.setMarginPainterPreferenceKeys(PRINT_MARGIN, PRINT_MARGIN_COLOR, PRINT_MARGIN_COLUMN); } allow the editor to set the preference keys (via configureSourceViewerDecorationSupport()) then just reinstate the defaults if that option isn't checked? John
(In reply to John McCabe from comment #53) > Dani, > > Would you mind describing how this works? Does this code: > > if (fSourceViewerDecorationSupport == null) { > fSourceViewerDecorationSupport= new SourceViewerDecorationSupport(viewer, > getOverviewRuler(), getAnnotationAccess(), getSharedColors()); > configureSourceViewerDecorationSupport(fSourceViewerDecorationSupport); > > // Fix for overridden print margin column, see > https://bugs.eclipse.org/468307 > if (!getPreferenceStore().getBoolean(PRINT_MARGIN_ALLOW_OVERRIDE)) > > fSourceViewerDecorationSupport.setMarginPainterPreferenceKeys(PRINT_MARGIN, > PRINT_MARGIN_COLOR, PRINT_MARGIN_COLUMN); > } > > allow the editor to set the preference keys (via > configureSourceViewerDecorationSupport()) then just reinstate the defaults > if that option isn't checked? > > John Not defaults but what's chosen/set on the preference page.
Yeah, that's what I meant. Thanks for doing that, although it doesn't solve the issue for people who wanted to have both on.
(In reply to John McCabe from comment #55) > Yeah, that's what I meant. > > although it doesn't solve the issue for people who wanted to have both on. Correct, that would be a separate feature request.
Perhaps consider having two margins: one that displays the editor-specific wrapping point and another - the user-configurable print margin?
(In reply to Stefan Xenos from comment #57) > Perhaps consider having two margins: one that displays the editor-specific > wrapping point and another - the user-configurable print margin? Yes, see my previous comment.
