On Mon, Sep 18, at 08:58 Jim Gifford wrote: > Ag. Hatzimanikas wrote: > >Included patches from upstream: 1-4, 6-26, 29-31, 33-44, 46-56, 58-64, > >66-73, 75-107, 109 > > > I submitted -12 a few days, ago. Haven't been able to commit -13 due to > issues on the belg server. Should be expecting it very soon. I will be > updating this patch once a week.
Sorry Jim for the late reply,I was out of town for 3 days. It seems I missed your patch.I wonder why it didn't came through the mailing list because I can't find it in my email client. Anyway it doesn't take too much of my time to create a patch for vim. I don't even have to monitor the server at vim.org for new patches,since every patch is posted to the [email protected] so is just a (s) to mutt for me,to save it in the directory where I keep every single Vim patch. Now the problem is that: Even if we let out the patches about gui(s) and different architectures (about 10 of them) still is a huge consolidated patch (around 55 K compressed / 240 uncompressed ) and will get even bigger if Bram will not release soon a new version that will contain all these fixes.And I am afraid this will get a little more far than we were expected. Now either continue this route (create a huge consolidated patch) which is absolutely fine by me,or we stop here and let the user to decide. Greg does this to his Ref. build. Be aware that we don't do it for any other package,why we have to do it for vim? If my opinion counts I would like to continue this way but even if we do maybe we have to change the instructions and use the compressed patch and apply it using bzcat. -- http://linuxfromscratch.org/mailman/listinfo/patches FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
