Hi,
I reviewed the code a little yesterday, and the current state is quite
sad: there are many lurking bugs which do not occur simply because we
use an encoding which is the identity in most cases (utf8).
At the moment I think that moving to the "character view" is the only
sensible option. The encoding-dependent features can be added later,
even though they will have a "hackish flavour".
> Although I don't want to develop a separate byte editor neither.
> I guess that we will be able to select the encoding in which we want to edit
> the file, and here we will be able to open without encoding.
The internal representation will be (isomorphic to) [Char], to there
must always be
a relation ([Byte] <-> [Char]). There is no such thing as "no encoding".
> If this is the case one just have to list features about bytes and classify
> them.
Ok!
> While looking at the Vim manual about the 'go' command:
>
> :[range]go[to] [count] *:go* *:goto* *go*
> [count]go Go to {count} byte in the buffer. Default [count] is
> one, start of the file. When giving [range], the
> last number in it used as the byte count.
> End-of-line
> characters are counted depending on the current
> 'fileformat' setting.
> {not in Vi}
> {not available when compiled without the
> |+byte_offset| feature}
>
> Notice the mentioned "byte_offset" feature :)
This could be implemented by converting to utf8, finding the character
that corresponds to the count, then jump to that character.
> Vim also have a feature to look at the underlying character representation,
> which is extremely valuable when dealing with encodings problems accents and
> the like.
It would be trivial to convert the current character to utf8 (or
whatever encoding).
> If someone else have ideas about features that could break, please add it to
> this topic.
Thanks!
-- JP
--~--~---------~--~----~------------~-------~--~----~
Yi development mailing list
[email protected]
http://groups.google.com/group/yi-devel
-~----------~----~----~----~------~----~------~--~---
