Re: Slow highlighting (Re: "drop-in replacement" and transpose-words-match)

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 12 February 2016 at 10:41, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Feb 11, 11:43am, Sebastian Gniazdowski wrote:
> }
> } The point of this tangent example is: every indexing works by
> } iterating over buffer and counting characters.
>
> That's only true for indexing from the end of the string (negative indices).
> Normal indexing should be direct and very fast.

I was on this some time ago. I remember, and now it also looks like
being so, that following block of code does the iteration for indices
>, =, < 0:

https://github.com/zsh-users/zsh/blob/master/Src/params.c#L1348-L1394

It comes down to following loop for indices > 0:

for (t = s; nchars && *t; nchars--) t += (lastcharlen = MB_METACHARLEN(t));

It counts characters (nchars--), skips bytes (lastcharlen).

> } The only solution is apparently making Zsh storing strings as real
> } arrays, of wint_t type.
>
> I'm not sure what kind of arrays you think are "real" as compared to
> what zsh uses now, but vast tracts of the shell would have to be
> entirely rewritten if we were to change the C string paradigm.

In C one can optimize the paradigm. Carefully skip multibyte
characters once, then keep and pass pointer. That optimization comes
to my mind. In Zsh there are no pointers. One keeps index but it
causes full reiteration each time it's used (if that's confirmed).

However maybe there could be added something similar? To get special
pointer: byte offset – via some flag. Then, to index with byte
pointer, when connected with some flag.

byteoffset=$long_string[(x)2500]
character=$long_string[(X)$byteoffset]

Best regards,
Sebastian Gniazdowski