Community
Participate
Working Groups
In a text or Java editor, enable Block Selection (Alt+Shift+A). Now, the Zoom In/Out commands modify the non-block-selection font instead of the currently used font.
On Linux, it seems even worse: using Ctrl+ when block selection is on seems to cause the IDE to freeze then stop.
I could see a StackOverflow in the log, that may be related: java.lang.StackOverflowError at org.eclipse.swt.graphics.TextLayout.computeRuns(TextLayout.java:104) at org.eclipse.swt.graphics.TextLayout.getLineCount(TextLayout.java:1061) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:983) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:714) at org.eclipse.swt.custom.StyledText.getPointAtOffset(StyledText.java:5497) at org.eclipse.swt.custom.StyledText.setCaretLocation(StyledText.java:8613) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:1017) at org.eclipse.swt.custom.StyledTextRenderer.getTextLayout(StyledTextRenderer.java:714) [... repeat chorus ad lib...] This part of the issue seems more like a SWT Bug.
(In reply to Mickael Istria from comment #2) > I could see a StackOverflow in the log, that may be related: This StackOverflow seems caused by some other editor(s?) being open. I closed all editors, reopened a JDT one and didn't get this error again. I didn't manage to get any hint about which editor, or combination of editors caused the issue. Once this StackOverflow doesn't happen, I can reproduce the reported issue. The cause is that the handler is using "textEditor.getSymbolicFontName()" which doesn't return the "current" font, but the "declared" one in editor description. I don't know a good solution to get the "current" font, some hints would be welcome. Although, as a kind of not reliable workaround and for IDE consistency, I suggest that by default we make the default Text font inherit from the block-selection font.
[the stack overflow is already reported and fixed, see bug 490743]
Or maybe can we assume that for all text editors, when the block selection is on, the block-selection font is the one to tweak? We could hardcode that rule in the handler, but I'm not sure of whether all text editors do handle selection block the same way (using an alternative font).
A related issue occurs in the Wikitext editor of Mylyn. The current implementation of AbstractTextZoomHandler resizes the default text font (org.eclipse.mylyn.wikitext.ui.presentation.textFont), but not the monospace font used for code regions.
(In reply to Stephan Wahlbrink from comment #6) > The current implementation of AbstractTextZoomHandler resizes the default > text font (org.eclipse.mylyn.wikitext.ui.presentation.textFont), but not the > monospace font used for code regions. As there seems to be no generic relationship between both fonts (the AbstractTextEditor misses a method to retrieve all used fonts inside editor and there is not one default to the other and vice-versa), I don't have a clue of a better way to determine that the "code" font size should be increased. What we can think of to generalize the AbstractTextZoomHandler is to compare the font size only rather than the whole FontData when computing the affected fonts, but that wouldn't work in your case since: * There's no defaultsTo * Both font don't have the same size by default
(In reply to Mickael Istria from comment #3) > Although, as a kind of not reliable workaround and for IDE consistency, I > suggest that by default we make the default Text font inherit from the > block-selection font. or vice-versa. @Markus: do you think adding defaultsTo from one to the other would be ok?
A declarative way to mark a font definition as text editor font would be helpful to get all fonts to change. (In reply to Mickael Istria from comment #7) * Both font don't have the same size by default IMHO all text editor fonts should be resized, independent of the current configuration. If a different font is configured by the user, that font should be resized by the same factor/step.
(In reply to Stephan Wahlbrink from comment #9) > IMHO all text editor fonts should be resized, independent of the current > configuration. If a different font is configured by the user, that font > should be resized by the same factor/step. There is no such thing as "text editors font" in the internal models. Font are declared but there's no way to decide in which context they're used. So we cannot just increase all font sizes defined in IDE as many of them aren't for editor. > A declarative way to mark a font definition as text editor font would be helpful to get all fonts to change. Does the editor definition accept extra properties that we could use to find additional fonts involved?
(In reply to Mickael Istria from comment #10) > There is no such thing as "text editors font" in the internal models. Font > are declared but there's no way to decide in which context they're used. So > we cannot just increase all font sizes defined in IDE as many of them aren't > for editor. I wanted to note, that the current implementation not only requires that the font is the defaultTo the "Text Font", but also requires the same font data. If you set the block selection font defaultTo "Text Font", zoom in/zoom out does not longer work, when the user configures a custom font. But IMHO the custom font should be resized by the same step.
*** Bug 502201 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/83087
Gerrit change https://git.eclipse.org/r/83087 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=aa914d41a7dc9eda9677687190f78ac64bacf9be
Despite not being a true solution, this patch should greatly improve the situation (unless user directly customize their block selection font)
New Gerrit change created: https://git.eclipse.org/r/83184
Gerrit change https://git.eclipse.org/r/83184 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=4e0ccc65bc342e12a6b0de55d9b4bbca90ed5179
(In reply to Mickael Istria from comment #16) > Despite not being a true solution, this patch should greatly improve the > situation (unless user directly customize their block selection font) I reverted that change, since it destroys the block selection feature if a non-monospaced font is used.
But the default text font is a monospace, isn't it? I don't see how the defaultsTo changes anything regarding ability for user to destroy this feature.
I believe this issue with block selection requring to be monospace should be handled separately and not block this change. see bug 505951 for a proposal.
(In reply to Mickael Istria from comment #20) > But the default text font is a monospace, isn't it? I don't see how the > defaultsTo changes anything regarding ability for user to destroy this > feature. The whole point of the block selection font is that it works automatically even if the user changes the Text, Java or any other editor font. This has to stay that way. The suggested workaround is not acceptable.
(In reply to Dani Megert from comment #22) > The suggested workaround is not acceptable. Plus, it only works around that particular scenario. There might be other contributed fonts that behave the same and are also broken
(In reply to Dani Megert from comment #23) > Plus, it only works around that particular scenario. There might be other > contributed fonts that behave the same and are also broken Indeed, there are. I can't find the bug # right now, but somewhere someone from mylyn wikitext reported that as their editors use multiple fonts, only one is zoomed. A solution for it would be to introduce a new API in platform text to ask an editor about "all used Text fonts"
(In reply to Mickael Istria from comment #24) > I can't find the bug # right now, but somewhere someone > from mylyn wikitext reported that as their editors use multiple fonts, only > one is zoomed. It's this bug, use Ctrl+F. > A solution for it would be to introduce a new API in platform > text to ask an editor about "all used Text fonts" Sounds good. Make sure that the new API won't make the fix for bug 482913 harder.
*** Bug 509109 has been marked as a duplicate of this bug. ***
see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=509108
I believe the root issue is that when block selection is set, the "textEditor.getSymbolicFontName()" is expected to return the main active font of the editor, in this case, the block selection one.
*** Bug 509108 has been marked as a duplicate of this bug. ***
*** Bug 519676 has been marked as a duplicate of this bug. ***
From https://bugs.eclipse.org/bugs/show_bug.cgi?id=461441#c4 """ Maybe we can simply make a special case of the "Block Selection" font in the AbstractTextZoomHandler: if we see that the modified font has the same font data as the block selection one and if the regular Text Font is part of the pool of fonts to modify, we include the BLock Selection font (and inheriting descendants) to the pool of fonts to be modified. That would probably match users expectation properly and wouldn't risk to break the way Block Selection font is used or defined. """
I've got a few questions, mostly for Dani about this: * Is there a way to detect whether a font is monospaced or not programatically? * If so, could we place a warning when Block Selection font is changed to non-monospace to remind user that they broke a rule? * If so, could we "link" through inheritance the Block Selection font as a sub-font of the Default one, and then the warning would pop-up if Block Selection (or parent one when inheriting) font is editor to non-monospace one?
*** Bug 535607 has been marked as a duplicate of this bug. ***
(In reply to Mickael Istria from comment #32) > I've got a few questions, mostly for Dani about this: > * Is there a way to detect whether a font is monospaced or not > programatically? A quick check in SWT Font and FontData show that this is not implemented in SWT. At least on Windows this information is available in LOGFONT.lfPitchAndFamily. See Bug 74292 for this API request. > * If so, could we place a warning when Block Selection font is changed to > non-monospace to remind user that they broke a rule? > * If so, could we "link" through inheritance the Block Selection font as a > sub-font of the Default one, and then the warning would pop-up if Block > Selection (or parent one when inheriting) font is editor to non-monospace > one? Instead of falling back to some font, the current selected font could also be forced to be monospaced, See 69253. This would also prevent problems when the bold gryph is different from the normal one.
*** Bug 560794 has been marked as a duplicate of this bug. ***
I was going to create a duplicate of this issue then I found this one. I work on different types of screens with different resolutions. One has a 3840x2160 resolution with Windows scaling of 150%. On that screen, I like Eclipse to use bigger fonts, so I hit Ctrl-Shift-+ to change the font size. Unfortunately, this short cut doesn't affect the text editor block selection font, even when I'm in block selection mode, and I'm a heavy user of that feature. The going back and forth is quite annoying. In a different work environment, I have smaller resolutions, where I don't need to zoom in. There, the default settings work just fine. I understand the rationales discussed here and in https://bugs.eclipse.org/bugs/show_bug.cgi?id=278831, that block selection may require a separate font specification in some scenarios, but in mine, which I believe is quite default, I've never changed any font settings in Eclipse other than zooming in and out for *all* fonts, I much prefer it to be a selection-only feature, not switching fonts entirely. So, how about: - Having some sort of toggle whether the block selection font has been changed at all by the user - If not, then pretend it doesn't exist as a separate setting, and let it use whatever font the current editor is using
I'm considering trying the opposite of what was attempted in comment #15: the block selection has to be a monospace font, and we'd like the block and regular font to have a relationship so the zoom command would propagate, and by default, the regular font is monospaced; so we can probably make the default text font "defaultTo" the block selection one.
But FWIW, I believe that block selection is not really worth the investment now; and building a more natural multi caret experience directly in StyledText and TextEditor without need of a block selection will allow users to not have to both with block selection and font management; and may even allow to start deprecating the block selection at some point. See bug 562676 and related ones.
> and building a more natural multi caret experience directly in StyledText and TextEditor without need of a block selection will allow users to not have to both with block selection and font management Can't disagree with that! :)
*** Bug 578993 has been marked as a duplicate of this bug. ***
*** Bug 509113 has been marked as a duplicate of this bug. ***
