DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: https://www.fltk.org/str.php?L2822
Version: 1.4-feature


@Matt: I don't think that the info you posted helps in any way to solve the
issue.

What we'd need is a bunch of new methods that let the user input a
character index rather than a byte count (offset).

We have, for instance:

  int Fl_Input_::replace(int b, int e, const char *text, int ilen = 0);

Docs say: "Deletes text from b to e and inserts the new string text. ..."


In this method `b' and `e' are byte offsets in the string buffer. IMHO we
can't change this because it would break all programs that use it.

What we'd need is an additional method, like (maybe):

  int Fl_Input_::replace_char(int b, int e, const char *text, int ilen =
0);

where `b' and `e' are *character* indices (or offsets) in the string, such
that you could replace text in a specific *column* (or columns) of an
Fl_Input widget (provided you use a fixed font for displaying in
"columns").

This is only one example of many, and the postfix "_char" could also be
"_utf8" or "_uc" (for unicode) or anything else. The problem is that such
methods would need UTF-8 character counting from the beginning of the
buffer to determine the byte positions.

And last but not least: this would need a **bunch** of new methods that do
character counting to find the correct byte offsets, not only in Fl_Input
but also in many other widgets. At least if we wanted to be "complete" by
any means.

I'm not sure if this is feasible, particularly since UTF-8 handling in FLTK
is meanwhile pretty old and well established. OTOH it could simplify user
code if we had it, at the price of a lot more methods and character
counting in many widgets.


Link: https://www.fltk.org/str.php?L2822
Version: 1.4-feature