On 1/6/09, Tony Mechelynck wrote:
> On 1/6/09, Matt Wozniski wrote:
>> echo matchstr(getline('.'), '\%' . col('.') . 'c.')
>
> Again, col('.') is a byte index, not a column. What about virtcol('.')
> instead?
Nope. \%15c is also a byte index, not a column (which is also
counter-intuitive, and brings us back to the problem - that however
well documented it is, even experienced vimscript programmers get this
stuff wrong regularly.)
>>> Changing an existing construct from byte-oriented to
>>> multibyte-character-oriented would probably break a lot of existing
>>> scripts. I don't believe Bram would ever accept that.
>>
>> But sometimes, breaking things is required to make progress. The fact
>> that we're having a conversation with both of us suggesting (fairly
>> complicated) things that haven't worked is a perfect proof for the
>> fact that the current system is counterintuitive and hard to use...
>
> That's no reason for breaking what does work. I don't mind
> counterintuitive as long as it's documented.
See above. If no one can remember how to use it, or the workarounds
to make it work are worth more trouble to the author than the trouble
of not having it work on multibyte input, I'd say that it _doesn't_
work as is.
In fact, I'd argue that having string indexing be byte-oriented after
multibyte was added was a regression that broke things that did work:
before, getline('.')[col('.')-1] was a valid way to get the character
under the cursor, and afterwards it was not. Changing this behavior
would probably break very few scripts, since I doubt most scripters
are defensive about doing it correctly, and would mean that all the
broken code that already exists, and even the code that was written
before proper multibyte support was added (I believe it was added
after vimscript, right?), would continue to work *unless* it was
written intentionally to work around this issue. And I think that
authors who knew enough to work around this would, by and large, be
happy to see it fixed. I think that the advantages of having new
scripts work the way that they should, instead of the way that they
do, would greatly outweigh the disadvantages of breaking scripts
depending on the broken behavior. But, Bram's opinion is the final
answer, so we'll see if he weighs in.
~Matt
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
