Uncertain about STB_TEXTEDIT_GETWIDTH

[sgraham]

// STB_TEXTEDIT_GETWIDTH(obj,n,i) returns the pixel delta from the xpos of the i-1'th
// character to the i'th char for a line of characters
// starting at character #n (i.e. accounts for kerning
// with previous char)

I believe it should be the delta from the i'th to i+1'th. In particular, for i==0, with the description above, I would expect to return 0.f, assuming that "xpos" means the logical x of the character near the bottom left baseline, but it seems that i==0 should return the width of the 0th character (more in line with the name).

Relatedly (? lumping in here in case I'm misinterpreting above) mouse click selection doesn't seem quite right. At the moment, it behaves as if clicking anywhere in the bounding box of a character puts the cursor at the index of that character. I think clicking should be trying to select the holes in between characters, not the characters themselves, so the X range check should be checking 0.5 of the step width as it searches. i.e. Clicking on the left half of a character should selects before it, and clicking on the right half should select after it. (This is easiest to see if you compare behaviour against e.g. notepad.exe set to a very large font size).

(I'm happy to attempt the code changes, I just wanted to confirm whether you agree with this before I do.)

[nothings]

STB_TEXTEDIT_GETWIDTH:

I'll have to check my actual use of it at work next week.

Mouse click selection:

While notepad shows the behavior you describe, metapad (which I believe uses the windows rich text edit control) and the github comment form in Firefox both appear to move the cursor to before the character you click on, regardless of how far through the character you click. For this reason I've never worried about this clicking behavior.

If you want to pursue it, please check out some more applications--for example Word, the default form-fill-in on Firefox or Chrome or others, the filename field of the Windows standard save dialog, etc. If a substantial fraction of them do it the way you describe, I guess we can implement as an option (and if a vast majority do it the way you describe, make it the default).

[sgraham]

I tested VS2013, Firefox, Chrome, IE, File Save dialog in IE, gVim 7.3, Wordpad, Notepad.

gVim is the only one that behaves the same way as stb_textedit, all others behave as I describe. This probably is reasonable for Vim in normal mode as it's not too mouse-oriented and doesn't believe in being between characters or past the last character.

One thing that's slightly confusing is that the registration point for the I-Beam cursor is not directly on the centre of the bar, but actually a couple pixels to the left of the bar, so for small text sizes it can be difficult to tell exactly where you're clicking (perhaps intentionally). I tested by either Ctrl-+'ing very large for the web browsers or setting the font size very large in VS/Worpad/Notepad.

Perhaps there's a difference based on OS too? I'm on Win81.

[nothings]

Yeah, I mostly tried at small point sizes (some things like the file dialog you can't easily increase the font size of). Probably that's not an intentional pixel-offset, but something to do with the always counting the advance width between characters as part of the right side of the character. My advice would be to not try any explicit pixel offset and just see what emerges when you do it.

Implementing correctly should be straightforward: find the first character boundary that's to the right of the mouse location, then check whether the mouse is left or right of the halfway point of the previous char.

[nothings]

And based on your testing, we'll make the fixed behavior be the only behavior (not a configurable option).

[nothings]

Regarding the original issue, you are correct, it is the distance from the start of the i'th character to the start of the i+1th character. Fixed docs for next version.