2017-03-08 1:14 GMT+03:00 Bram Moolenaar <[email protected]>:
>
> Nikolay Pavlov wrote:
>
>> 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.
>
> Macros should be all caps. That some aren't is just because they
> haven't been fixed yet. Lua is not needed and should be avoided.
> The less tools required the better.
I am not saying Vim has (no) such problems. Just showing that naming
style rules have their function.
>
>> - 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.
>
> Hardly and advantage and this is the main cause for merge problems.
> Having the { and } in the same column is an advantage. So this is
> clearly a personal preference.
What is the advantage of them in the same column? More code on screen
means less scrolling and more immediately visible context, this is a
good and measurable metric.
>
>> - 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.)
>
> "figure brackets"? Don't know what that is.
Curly bracket.
>
>> - `//` 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).
>
> Vim is using ANSI C, it does not support // comments, unfortunately.
Neovim has chosen to use C99 and also drop support for many
architectures. This point in the Vim style guide serves its function,
but we have more options.
>
>> - 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.
>
> Not sure what this means.
Something like “+ should be indented with `a` in `(a <EOL>+ b)`.
Though I am just describing function of another point in the style
guide: it is a counter to your statement that styles are mainly
personal preference, not “look Neovim has best style guide ever,
because …”.
>
>> - 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.
>
> Vim already does this.
I never said it does not. I have clearly stated in the first paragraph
that I am showing functions of style guide rules, not showing how
Neovim style is better. Though I think Neovim style guide is better
thought of, so all examples are from there.
>
>> - 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.
>
> Do you mean linter or formatter? I thought this was about formatting.
> It would be nice if it can be done automatically, but I haven't found
> one that's good enough. It's easy enough to do manually, frustrating to
> correct the formatter where it goes wrong.
Exactly linter. We already checked on some formatters and they perform
worse then manual formatting. But some contributors miss some rules,
so linter becomes handy.
>
> --
> hundred-and-one symptoms of being an internet addict:
> 84. Books in your bookcase bear the names Bongo, WinSock and Inside OLE
>
> /// 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.
