On 2018-06-01T11:02:57+0200, Stefan Sperling wrote: > On Wed, May 30, 2018 at 04:01:57PM -0400, S. Gilles wrote: > > 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. > > The feedback you got to your patch may seem like a setback. > But framing it as people asking you to "rework all of mg" by yourself > doesn't really align with what's happening here.
My apologies -- I wasn't entirely clear in my reply. I know that nobody's asking me to do rework all of mg (either alone or working with others), I just wanted to make it clear that it's not in my plans to do so. If someone with an itch for a better mg wants to recreate a nice, 8-bit clean version, I don't want to hold them back with thoughts that their work would be redundant (or, worse, that I might resent it). > What is really being asked for is work which improves the overall quality > of this editor and makes UTF-8 support easier to add in the long term. > Ideally, this isn't done by just one person, There needs to be a review > process and pooling of expertise held in the minds of various people. > > I'll note that someone else (Leonid), and not you, posted this patch of > yours to this list and thereby started a review process which you might > not even want to be part of. And that's fine, you don't need to be here. > I don't know if you were even asked before your patch was posted. > > Generally we expect people who post patches to also take care of any > feedback they get for those patches themselves. But Lenoid just funnelled > our feedback back to you, which isn't how this is supposed to work. > > Nobody expects anyone to get anything done within any particular > amount of time. If there is no fun in it for you anymore, just stop. > Somebody who cares (or several people who care) enough about mg might > eventually put in the work to make happen what the community wants. I haven't really thought about this code since I worked on it 2+ years ago. Even then, my motivation was rather more selfish than improving the overall quality of mg -- I just wanted to write emails to a guy with "รก" in his name and not deal with "\303\241". Back then, I got what I wanted and made the upstream maintainers aware that 1) at least one user wanted that functionality, and 2) code existed, either to take wholesale or use as inspiration. Doing so carries a lot more weight than a simple "please add X", and is a pre-emptive answer to the reply "patches welcome". :) Now, as someone who published a bit of code to the world, I do have moderate responsibility to consider feedback and to fix easy bugs with it; I don't begrudge that at all. But I don't have any special motivation beyond that. That's pretty much it. -- S. Gilles