neharob / editra

Automatically exported from code.google.com/p/editra
Other
0 stars 0 forks source link

Caret, selection and text positions get out-of-sync when using certain fonts #666

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. change editor font to one of Ubuntu, Sans, Serif, DejaVu Sans/Serif
2. in a new (python) editor tab add the string:
"fi fo fum"
3. move the cursor around, add/remove text and select parts of the text after 
the 'fi'
4. with brace highlighting add braces and observe similar (related?) problems

What is the expected output? 
Cursor accurately represents current text position,
text gets added at the cursor,
selected text remains in the same position as the original text

What do you see instead?
Cursor may move more than or less than the width of the next character,
text gets added in the correct column but the cursor is somewhere else,
selected text shifts to the position that the cursor 'sees' it
brace highlighting shifts everything similar to selecting text

What version of the product are you using? On what operating system?
Editra 0.6.48 (I haven't seen this behavior in previous versions), Ubuntu 10.04

What method of install was your version installed with (Binary/Source)?
tarball (source)

If from source: What version of python and wxPython are you using?
python 2.6.5, wxGTK 2.8.10.1

Please provide any additional information below.
Some of the fonts that I tried out:
Ubuntu, Sans, Serif, and DejaVu Sans/Serif do this
Verdana, DejaVu Sans Mono, Droid (any), Liberation (any), Times New Roman, 
Trebuchet, any monospace fonts do not.
using Ubuntu-title, characters inside of strings are vertically offset and move 
when selected

Other editors (including scite) don't exhibit this behavior

Original issue reported on code.google.com by airdrik@gmail.com on 2 Jun 2011 at 3:22

GoogleCodeExporter commented 9 years ago
Hi,

This is likely caused when styles that bold the text are applied as the 
non-monospaced fonts in the bolded style will become visually wider on the line 
where as the monospaced ones will not. For programming its usually better to be 
using a monospaced font so that columns line up nicely.

If it doesn't happen in scite it must either be fixed in newer versions of 
Scintilla (the current wx one is quite old) or the styles used in Scite didn't 
use any bold properties.

As a possible work around suggest using StyleEditor to turn off 'bold' property 
on your current style set.

Original comment by CodyPrec...@gmail.com on 2 Jun 2011 at 3:33

GoogleCodeExporter commented 9 years ago
I don't use bold on any of my styles (primarily because I don't like bold very 
much in my code, partially because of the text shifting when highlighting 
braces) - the behavior described was when using entirely normal (non-bold, 
non-italic) styles.  (I also don't like monospace fonts as I find the 
"boxiness" distracting, but that is just a personal preference.  It just seems 
odd that this behavior only happens with certain non-monospace fonts)

Original comment by airdrik@gmail.com on 6 Jun 2011 at 3:47

GoogleCodeExporter commented 9 years ago
Issue 692 has been merged into this issue.

Original comment by CodyPrec...@gmail.com on 3 Sep 2011 at 11:31