Armel Asselin:
why UTF-16? what advantage? it has the same properties as UTF8 but is bigger most of the time at least for Western languages. translation from UTF-8 to UTF-16 is low cost and purely functional, keeping UTF-8 seems a better idea... moreover _all_ the code assumes 'char*', going to UTF16 would involve changes in _all_ the code...
I'm not completely opposed to UTF-16 as an option but can't see many advantages either. Some per-character transformations like case conversion or case insensitive searching may be a little simpler.
there is one problem though: most styling API need to accept "long" (so as to have at least 32 bits) and in the styling buffer somewhere scintilla uses an array of such 'long', particularly during line layout, it may take much memory (4 times as before for this buffer) so the first question is this acceptable for the main stream distrib?
For the LineLayout object, going for 4 byte styles always will multiply line layout size by a little less than a factor of 2 as there is already an int for each position. I feel this is an unreasonable burden to current users memory budgets especially those who have turned on whole document layout caching. Allocating style values inside LineLayout the same width as in CellBuffer would be more reasonable allowing users to control the memory budget. I'm not sure the additional capability of 32 bits is worth the cost over 16 bits. As I'm concerned about potential problems with this change, it would be best to publish a version with the change to it can be exercised by more people before integration into the main distribution. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
