Community
Participate
Working Groups
Steps to reproduce: - edit default text font, change font size - toggle block selection mode for the editor The effect is that the editor switches the font size. In AbstractTextEditor#setBlockSelectionMode it is assured that in block selection mode a monospace font is used. It is determined if the font has to be switched, but the condition does not take into account that only the font size has changed. The expression !normalFont.getFontData()[0].equals(blockFont.getFontData()[0]) will evaluate to true since the font data differs even if just the size was changed. In my case the data is normalFont: 1|Monaco|14.0|0|COCOA|1|Monaco blockFont: 1|Monaco|11.0|0|COCOA|1|Monaco Actually only FontData#getName has to be compared. If the same font (by name) is used, even if it differs in size or style, the font does not need to be switched when entering block selection mode. To solve this, change the condition AbstractTextEditor#setBlockSelectionMode as follows if (!blockFont.equals(normalFont) && !normalFont.getFontData()[0].getName().equals(blockFont.getFontData()[0].getName())) { This will work for the typical case that the default text editor font is used in another size. The effect will appear when another font is used, even if it is also a monospace one. There is no means to identify if a font is monospace. Also the block selection default font can't be set to the same size as the normal font, since it is a fixed font from the FontRegistry.
New Gerrit change created: https://git.eclipse.org/r/43297
Still occurs in Neon
Wouldn't it be better if AbstractTextZoomHandler scales all fonts used by the editor?
(In reply to Stephan Wahlbrink from comment #3) > Wouldn't it be better if AbstractTextZoomHandler scales all fonts used by > the editor? Yes, it would. However, the issue is that there is no good way to list all fonts used by the editor at the moment. 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'm removing the target for this one as M2 code-freeze is today. Whoever would like to give it a new try, feel free to set the fix version according to your availability.
@Karsten: is your use-case only in the context of the Zoom operation? If so, would it be a dup of 492202 ? If it's in the generic case, I believe the issue works as designed. Unfortunately, there is no link between Default and Block Selection fonts. I also regret it but my former attempts to bind those (though inheritance) were vetoed (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=492202#c19 ). (In reply to Mickael Istria from comment #4) > (In reply to Stephan Wahlbrink from comment #3) > > Wouldn't it be better if AbstractTextZoomHandler scales all fonts used by > > the editor? > Yes, it would. However, the issue is that there is no good way to list all > fonts used by the editor at the moment. There is a dependency on bug 483921 for this.
The use case is not directly Zoom after enabling Block mode as in bug#492202. I have scaled the original font of the editor with the Zoom function and then enable Block selection mode. Then the editor font is smaller. I find this is quite disturbing.
After reading multiple comments on this issues and other ones related to BlockSelection, I believe that this issue is either a WONTFIX or is not clearly titled. As mentioned on the patch, the Block Selection Font defined in the appearance page needs to be honored, there is no way we can safely change that. Maybe you can retitle this issue re-focusing on the user-story so we can consider other possible solutions/improvements to it. FYI, I believe sync of Text Font and Block Selection font is the "parent" issue of a few other ones in the tracker, and your initial report is the most generic one. If you agree on making it more generic in the title, we could mark other ones as duplicate of that one.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
