2017-03-05 16:56 GMT+03:00 Bram Moolenaar <[email protected]>: > > 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.
Many parts of the style are more functional then personal preference: e.g. (note: I am commenting some Neovim code style rules, *not* differences between Neovim and Vim rules) - How exactly you are going to distinguish between type of identifiers is preference, but different type of identifiers exhibit different behaviour. E.g. you may expect `ASCII_ISALPHA(*(p++))` not function properly (i.e. increment p twice), but you never expect this from `ascii_isalpha`. Probably most significant difference between Vim and Neovim here is naming of enums, and that is there because you can use enum constants from luajit ffi by simply “sourcing” preprocessed header and you can’t do the same for macros. - Egyptian brackets have their function as well: it means you can see more code on screen at once. Yet it does not make code harder to understand. - Forcing figure brackets is needed to prevent line additions touching more line then needed in diff and prevent errors like https://www.viva64.com/en/w/V563/ and https://www.viva64.com/en/w/V705/. Also consider a case when you need to add debugging print to the branch which only has one line: having figure bracket is better then not having it. (Using PVS-studio diagnostic messages to show that authors of commercial product found these errors common enough to make these diagnostics; and also because they advertise actively enough for me to know about them having these warnings.) - `//` comments do not need neither user nor editor (syntax highlighting) keep (not) commented state in mind and toggle it on `/*`/`*/`. They are also normally either less verbose (more code on screen) or easier to edit (depending on where you place `/*` and `*/`: on the line with text or on its own). - Rules for alignment/indentation of multiline expressions were written to make it easier to understand which exactly are operands/what function arguments actually belong to. - Also it is easier to determine what is the operator if it is on the first non-blank column of the new line rather then at the end of the previous line. - … - Availability of tools to lint the code and their features is not something that should be missed as well. Google linter is really easy to customize, but adjusting it to the completely alien (to the linter) style of Vim would be hard. It is good having a linter on CI because people normally don’t argue with programs and you do not need to either be too pushy about the style or do much manual merging. And it is good to have customizeable linter so that common contributors’ mistakes or adjustments made to the style guide may be added as rules. > >> 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. -- -- 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.
