Does anybody have problems with the caret when you have a long line of code? On a long line of code stretching from the left margin to almost the right margin, the caret(or insertion point ) is usually 1 to 2 characters out of whack. Is there a workaround? With this type of behaviour, the caret may as well be a carrot. GRRRRRRRR!
Also: Text Cursor. Can you post a picture demonstrating the case? Also cite your OS and Xojo versions.
OS=10.8.5
Xojo r2014 2
Rick I dont think posting a picture will tell you much as the Caret appears to be in its normal place until you start typing
Massimo This is exactly my issue as reported in case #28533
I have observed the same issue on long lines, where the caret appears on the right of the actual insertion point, so a deletion or insertion does not take place where the caret is. It is kind of random, though, and does not happen with all long lines.
The best workaround seems to simply break long lines into smaller ones with the underscore. It makes lines easier to read as well, I think.
It has to do with the font you are using. We’ve found that the character width of " marks are often to blame. If you use a mono spaced font, you’ll have better luck.
Greg - I have noticed something similar on Xojo 2013 r3.1:
If you set a read-only TextField’s cue text, and then click on that TextField when the app is run - the cue text jumps to the right 1 or 2 pixels.
Would this also be caused by the font I am using?
Surely there is a hidden bug here. If Sublime Text can do it, anyone should too.
I do use a Monospaced font, and notice this issue constantly in the IDE
While breaking the lines and using “_” is a work-around, to me it is not an acceptable one, as I should not have to alter my programming style to fit the editor
[quote=107867:@Richard Summers]Greg - I have noticed something similar on Xojo 2013 r3.1:
If you set a read-only TextField’s cue text, and then click on that TextField when the app is run - the cue text jumps to the right 1 or 2 pixels.
Would this also be caused by the font I am using?[/quote]
It’s possible, but unlike TextFields, the code editor is a custom canvas control.
I use Source Code Pro, which is supposed to be mono spaced, and see a similar problem often in long literal strings.
<https://xojo.com/issue/30814>
It is still happening in 2014r2
I gave up on Source Code Pro about a year ago because of this issue. I now use Lucida Console.
Lucida Console is definitely an improvement, but the problem is still there especially with the smaller font sizes. I find if I raise the font size to 20, the problem goes away. Of course, that is way too big to be useful.
Thanks for the tip.
There isn’t
Its literally a cumulative rounding error since text width etc on OS X return doubles
Trust me I’m aware of it as I see it too
Just haven’t sorted out the fix for it
I think this must be a syntax coloring thing these two if statements should be the same length (I added enough spaces and single quotes at the beginning of the lines to get the start of the text to align…)
The caret is at the end of the second line… It looks like the caret position is correct, just the characters are being placed wrong (that cumulative rounding error)… maybe both could be calculated the same way? or the characters should be drawn based on the length of the unformatted text vs cumulative length of the formatted line?
This is with Palatino font… Menlo shows slight misalignment, Monaco looks correct…
Bold chars are a bit fatter too. I feel that the case is narrowing now.
[quote=107933:@jim mckay]I think this must be a syntax coloring thing these two if statements should be the same length (I added enough spaces and single quotes at the beginning of the lines to get the start of the text to align…)
The caret is at the end of the second line… It looks like the caret position is correct, just the characters are being placed wrong (that cumulative rounding error)… maybe both could be calculated the same way? or the characters should be drawn based on the length of the unformatted text vs cumulative length of the formatted line?
This is with Palatino font… Menlo shows slight misalignment, Monaco looks correct…[/quote]
I have no idea how characters spacing is addressed in the canvas itself, but if the system uses doubles, it looks near impossible to apply consistently character by character over a long line. At standard size an N for instance is made of 7 pixels, so applying a double to it implies a quantum rounding of 14% ! And as rounding becomes even more severe for narrower characters like i, the challenge appears daunting. The only way to manage correctly spacing character by character would be in pixels, but I doubt the TrueType or OpenType vector imaging can be as precise as a bitmap font.
Monospaced fonts should produce a more reliable result, though, as all the successive calculus necessary for proportional characters disappears. Yet, if for instance the system reports a width of 7.0526315 pixels per character, the cumulative effect of the rounding will ensue the noted one character offset after 95 characters positions. Changing font can indeed alleviate the phenomenon, though, as the pixel rounding can be more or less severe according to the font spacing. In the current state of screen and font technology combined, the issue maybe impossible to entirely resolve : an OpenType font uses a much, much higher internal metric precision than any current screen. For instance the 7 pixels “N” I talked about above has internally a precision of 1163 units. Even a Retina screen with all its crispness will only use 14 pixels to represent that.
It should be possible to design a font for a given point size that takes into account the pixel quantum effect on spacing. In the case of our “N”, I can design a font where the “elementary” element is designed in 166.142 elementary units increments. An “i” will be exactly that, for instance. One pixel.
Problem is, a font can only have zero problem for a given screen point size, so it would become necessary to have fonts for several point sizes, just as it was the case for bitmapped fonts in the early days of Mac. Moreover, designing close point sizes, for instance 10, 11 and 12 becomes a challenge, as to render pixels on the screen I would still have to take into account the elementary 166.142 unit. So 11 would probably not be possible without visible design alterations…
More details at :
https://en.wikipedia.org/wiki/Em_(typography)
http://www.typophile.com/node/77906
I obviously don’t know what complexity lies in the editor, but what about making the x accumulator a double and rounding at render time rather than rounding to the accumulator? If that even makes sense…
If StringWidth correctly measures a multiple characters string, then it should be possible to place the caret with more precision. Admitting processing does not hinder typing, which has already been accused many times to be slow. But that would imply that before positioning the caret, and after each insert or delete, the width of the entire line to the caret position be calculated…
It’s a problem needing measuring char by char individually. Each glyph (like X, x , X, x X, X, 1, 0, ’ , / ) under same standard size and even with different attributes (italic, bold, etc) have a different sizes. You must keep track of all to know where to insert the text cursor with precision.