On 11/03/14 20:46, Evan Laforge wrote:
I support this idea for purely selfish reasons. I write haskell in vim, and I'm constantly bothered by vim bugs that will likely never be fixed, and I don't dare try to fix them myself because vim source is such a jungle. I have several extensions for syntactic manipulation written in vimscript and python, and they mostly work but not entirely reliably because vim extension is clumsy. I use tags and they also have problems, but once again I'm not about to go in and redo vim's tag support. Etc. etc.
I do hope that this is where a lot of support for Yi will come from.
Yi is tempting because it promises to be a place where I could fix these things for real, but I've been discouraged in the past by immaturity (can't even get it to build) and lack of documentation. So I think some concentrated attention to the build, documentation, general cleanliness, and performance would be a great idea. I'm not too fussed about a lack of concurrency since I think there are more fundamental problems, but if it would result in improvements to those fundamental problems, I'm all for it.
While there are more fundamental problems as you mention, we don't stand a chance without concurrency to come close to what existing editors can do. Certainly documentation will get written during the project. I don't explicitly mention it partly because it should implied that we document what we're doing and partly because Google doesn't allow for documentation projects so I didn't want to make it sound like one. PS: If you can't get it to build or are struggling otherwise, please pop into #yi on Freenode and we will almost certainly be able to help you (although you might have to wait for one of us to be online). There's also a mailing list although you might have to wait a bit longer (although a reply is more certain). If you have any specific issues (even if they are “Please document XYZ”), please do make issues on GitHub! -- Mateusz K.