If efficiency is not a concern, then you can easily use something like
this (just a quick prototype, didn't verify if it's correct or not):
[...]
Thanks for the free code :)
I think that will be the way to go in my case, since most input will be
ascii and moving the cursor will be
Hi!
This is a really good suggestion, but I think it may add a lot of
overhead
since it would need to go through the entire buffer, and since moving
the
cursor is not very frequent (not more than changing you position or
opening a new buffer), I think it would be better to do it the "lazy"
On Fri, Sep 02, 2022 at 02:08:03PM -0300, atrtar...@cock.li wrote:
> Quite inefficient really, but I guess it's fine since my usage would be
> only user input (left arrow)
If efficiency is not a concern, then you can easily use something like
this (just a quick prototype, didn't verify if it's
Hi atrtarget,
I thought I'd chip in my two cents.
1. Regarding stepping backwards throught the graphemes:
As Laslo explained, trying to find the starting point of the previous
grapheme is simply not possible.
In your situation, if scanning from the front of the string is too
inefficient for
Thank you a lot for spending some time answering!
The problem with this heuristic is that the algorithm can become very
inefficient, especially when you have long preceding segments. If n is
the offset-length, the worst-case runtime could be O((n-1)!) for a
segment that is in fact of length
On Thu, 01 Sep 2022 21:43:06 -0300
atrtar...@cock.li wrote:
Dear atrtarget,
thanks for reaching out!
> libgrapheme looks really useful, but I still don't get some things
> from it. For example, if I need to get back one grapheme, how should
> I do it since there's no
libgrapheme looks really useful, but I still don't get some things from
it. For example, if I need to get back one grapheme, how should I do it
since there's no `grapheme_prev_character_break`? And to get the number
of columns a character takes up, should I convert everything to wchar
and use
