On 2018-05-30T09:17:22-0600, Theo de Raadt wrote:
> This approach seems misguided.  Let me tell a story.
> 
> More than two decades ago, I made a fork of mg which was 100% byte
> clean.  Unfortunately I lost the source code of that change.  mg's data
> buffers are a linked list of lines, with a \n implied by the end of each
> string.  0 bytes are unsupported.  Supporting multibyte risks a string
> merger getting confused by these problems and creating junk.  My fork
> changed mg to embed \n and \0 in the strings, and have the display code
> understand that.  All buffer-search functionalities also learned of this
> change.  The change had to be made quite incrementally and carefully,
> but I recall the end result deleted far more code than it added.  mg became
> 100% 8-bit clean, I could edit binaries with it.
> 
> I think trying to shoehorn utf8 in before mg is 8-bit clean is a recipe
> for disaster.  There are too many functions (imagine search-replace)
> which already have nasty special cases for \n, and now will need nasty
> special cases for utf8 and I don't think this will work out nice.

Fair enough. I am decidely not up for reworking all of mg. It seems
better that this patch, as it is, remain off to the side in case
someone wants to use it themselves.

-- 
S. Gilles

Reply via email to