The cursor has a problem, the location is displayed.

[xubing6243]

os: windows7

[matthew-dean]

Is the cursor always in the wrong position for you, or under certain conditions (resizing, switching tabs, etc)? Do any of those actions correctly re-position the cursor?

[xubing6243]

I am not very clear, this problem is not often appear! I don't know what's causing it!

I'll be testing for a while, and so have the results to tell you!

[Pantyboy]

My cursor has an "extra" space between the character and the cursor itself.

It took me several attempts to delete a character before I figured this one out.

[matthew-dean]

@Pantyboy Also on Windows? If so, what version?

[TommyTheBlackbird]

It happens to me in Windows 10 (64 bits).
Crunch 2.0.5 - beta 5

[Pantyboy]

@matthew-dean I'm using Crunch 2 Pro on Windows 10, 64 bit.

[matthew-dean]

This one will probably prove difficult. It's either an Ace (editor) bug or a bug in Chromium for Windows. The only way this would happen (I think) is if it measured character width and the browser engine returned an inaccurate width.

See if you can note any pattern, like resizing / switching / anything like that. I might be able to make a workaround if I know where it happens.

[matthew-dean]

@Pantyboy For you, is this a problem all the time? And if it's all the time, is it a problem no matter where the cursor is on the line? (For example, is it as "wrong" at the beginning of the line as a long line, or does the distance shift?)

[Pantyboy]

@matthew-dean The gap is only really visible at the end of the line so this is only when you notice the problem.

[PSEAlex]

[ghost]

Screen cap of the cursor issue in beta 6. I had just typed the 'x' in the screenshot. If I were to backspace once from where the cursor is the 'x' would be deleted.

[matthew-dean]

This is technically an Ace issue, which I've raised with them, but I'll try to keep figuring out a workaround. I think rather than measuring the actual position of those characters, Ace attempts to math it out by measuring individual characters and some similar CSS to what's rendered in order to guess the cursor position. It appears those guesses are sometimes wrong under some unknown circumstances which seem to have been triggered in Crunch.

[matthew-dean]

Is this still an issue as of beta 8 for you in Windows?

[Pantyboy]

@matthew-dean From my perspective, this is fixed. Great job!

[sacerro]

No problem with beta 8 on Windows 10 x64

[TommyTheBlackbird]

I'm still having some cursor issues (beta8 Win10 x64). The problem seems to appear when the cursor is next to some mark characters like colon and semicolon.

[matthew-dean]

@TommyTheBlackbird Nuts. It's hard to guess where the failure point is. It might be some combination of how Ace is measuring lines + font + Chrome + Windows font rendering. Are all of you in the Facebook beta testing group? I might have to do some test builds with slightly different settings to see what fixes it for you.

[nightwing]

@TommyTheBlackbird could you try the editor at https://ace.c9.io/#nav=about?

[matthew-dean]

Ah, I can reproduce now in a Parallels virtual Win 10.

[matthew-dean]

Apparently Atom, which is pretty similar to NW.js as far as platform, has had lots of text-measuring issues, especially in regards to text-rendering: optimizeLegibility, and fonts with ligatures like Hasklig, which Crunch is currently using. See: atom/atom#8811.

In the short term, if Ace doesn't have a fix, I might try to sub in Source Code Pro (which Hasklig is based on), and turn off optimizeLegibility (or text-rendering: geometricPrecision which I also have tried).

[matthew-dean]

Okay, with some more testing, I could reproduce cursor positioning problems on both Mac & Windows, not just Windows. After toggling text-rendering settings on/off, I think the problem might, in fact, be Hasklig, which claims to be a monospace font, but ends up not being monospace in Chromium. Ace only works with monospace fonts, so this is probably the issue. I'll do some test builds with Source Code Pro & text-rendering settings turned off for the editor.

[matthew-dean]

The problem was not the font. What the problem is, I'm not exactly sure, but I think I have a working workaround.

[matthew-dean]

Fixed in beta 9.

[TommyTheBlackbird]

Fix confirmed here! Nice job!

[PSEAlex]

beta9 on win7 home premium x64 - working fine 👍

[matthew-dean]

*whew *

[SBRK]

I had the same problem, only on Mac. On words like "difficult" the f and i would get grouped. This was due to a global font-feature-settings: liga I had.

I added

  font-feature-settings: "liga" 0;
  font-variant-ligatures: none;

To my Ace editor wrapper and voila