Justin M. Keyes wrote: > On Sat, Mar 4, 2017 at 10:10 PM, Christian Brabandt <[email protected]> > wrote: > > On Sa, 04 Mär 2017, Bram Moolenaar wrote: > > > >> > >> Christian Brabandt wrote: > >> > >> > On Di, 28 Feb 2017, Bram Moolenaar wrote: > >> > > But also testing fdm=marker requires more work, I'll leave that for > >> > > now. > >> > > >> > Are you sure? I think adding a :set fdm=marker and the rest should be > >> > the same, foldmarkers will then be set automatically. > >> > >> Hmm, I thought markers would have to be added to the text. But it > >> appears the default marker and comment work. So that's easier than I > >> thought. > > > > I initially tried the test with fdm=marker (without noticing at first) > > and wondered why it worked. So I noticed that the marker test should > > work easily > > > >> I wish they would have made it easier to make patches work for both. > >> Now patches have to be written and applied twice, for no good reason. > > > > Yeah, that was what I thought as well. I asked him for putting the patch > > right here upstream, but apparently he did not want that (for whatever > > reason). At least he later also provided a Vim compatible patch. > > Neovim devs have gone to great effort to merge thousands of Vim > patches (meanwhile marking the noise-commits related to TINY build as > N/A, since the TINY build is not tested against before committing to > master).
I wonder why you waste so much time on this. If you keep the code more like it is in Vim then merging patches is a lot easier, while the disadvantage of using older style code is hardly relevant. One can spend a lot of time discussing code style, line length, naming, etc. Only in a few cases it's actually worth it, most of it is personal preference. > Now, Vim devs complaining about formatting for a few cases where we > didn't do double-work, is remarkable. The complaint was that this patch for neovim, with nested "if" statements, was quite hard to apply to Vim code, even though the functionality is exactly the same. > By the way, what are the technical (not emotional) reasons that > prevent Vim from adopting the Neovim tree, going forward? I'm sure > there are a few, but listing them out would be very useful. If I change the layout of code, all pending patches are instantly broken. This happened once, when the function headers were changed, and it's painful. The impreovement to the function headers was hopefully worth it. What are the reasons neovim made any changes that just make life hard without a real advantage? You can decide yourself what those are. I would argue that different placement of curly braces is just a matter of preference and has no functional advantage. -- hundred-and-one symptoms of being an internet addict: 54. You start tilting your head sideways to smile. :-) /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
