survey: options defaults

[echasnovski]

Feature already in Vim?

No

Feature description

Hello! This issue is not really a feature request, but rather a follow-up to Neovim built-in options survey I conducted for the past two weeks and a place to discuss its results. I decided to create this mainly because @justinmk expressed an openness for looking into it once it is over.

Here is a gist with full results along with description of how to read them and scripts used. Total number of legible answers were 227. Analysis was done with R, script is in the gist. I decided to not make initial answers public, but if anyone from Neovim core wants to look at them, I'll send them by e-mail or open access to a Google Form (needs Google account).

Here is a plot with summary of basic options usage (options were picked by hand):

Basic options summary plot

Here is a table with top non-default option values:

Option	Value	Number of answers	Percent
termguicolors	true	216	95%
helplang	en	200	88%
number	true	196	86%
expandtab	true	187	83%
ignorecase	true	185	81%
smartcase	true	183	81%
splitright	true	161	71%
splitbelow	true	155	68%
cursorline	true	150	66%
leader	<Space>	150	66%
undofile	true	147	65%
relativenumber	true	135	59%
mouse	a	132	58%
showmode	false	129	57%
statusline	%#Normal#	126	56%
laststatus	3	123	54%
signcolumn	yes	106	47%
wrap	false	105	46%
tabstop	4	103	45%
clipboard	unnamedplus	101	44%
list	true	101	44%
shiftwidth	4	101	45%
shiftwidth	2	96	42%
showtabline	2	96	42%
smartindent	true	94	41%
tabstop	2	91	40%
linebreak	true	78	34%
breakindent	true	67	30%
softtabstop	4	64	28%
lazyredraw	true	60	26%
updatetime	300	60	27%
completeopt	"menu,menuone,noselect"	57	25%

Note: helplang="en" is a part of result because default value is described as "messages language or empty", but vim.api.nvim_get_option_info('helplang') returns only "" as default.

So it seems that there is quite a few basic options which are used with non-default values. For completeness, here are some possible pitfalls of this survey:

• Not that large sample size (227). Maybe this survey will prompt Neovim core to make their own, official so to speak, poll.
• Possible sampling bias due survey procedure (user needed to download script, execute it, and post results), which might poorly represent not so tech-savvy users.

My personal opinion is that all boolean option values with 80% here seem like widespread enough to become default.

Thanks for reading this!

[gpanders]

My personal opinion is that all boolean option values with 80% here seem like widespread enough to become default.

This includes number, expandtab, ignorecase, and smartcase. The default value of expandtab is (mostly) meaningless because that should be set by individual filetype plugins. That really just leaves number, ignorecase, and smartcase for consideration.

For what it's worth, I'm not in favor of changing any of these. In particular, enabling ignorecase and smartcase violates the principle of least surprise. It's fine if someone enables those options understanding what they do, but as default behavior it could be surprising or unexpected (as another point of reference, other standard tools that perform "search" such as grep or less do not ignore case by default either). I'm more ambivalent about number; I don't personally use it, but I don't have a very strong argument against it. Just preference.

That's my 2c.

[justinmk]

This is great data, thanks.

• ✅ 'termguicolors' is probably worth considering (done: feat(defaults): enable 'termguicolors' by default when supported by terminal #26407)
• Many of these are (useful) indications about needed documentation improvements rather than signals that we need to set these defaults.
  • E.g. 'number' is a signal that 'ruler' and g ctrl-g should be mentioned it at :help 'number', to start with.
• Perhaps we could add a :checkhealth section that gives advice.

[echasnovski]

• Many of these are (useful) indications about needed documentation improvements rather than signals that we need to set these defaults.

  • E.g. 'number' is a signal that ctrl-g should be mentioned it at :help 'number', to start with.

Not really sure, how it might look like. The wording "Default value is false, but many seems to use true" seems odd.

Do you mind clarifying how ctrl-g will help inside 'number' documentation?

[justinmk]

how ctrl-g will help inside 'number' documentation?

oops I meant g ctrl-g, but actually 'ruler' is the main reason why 'number' is pointless. You don't actually need a grid constantly telling you the row/col of everything on the screen.

[echasnovski]

how ctrl-g will help inside 'number' documentation?

oops I meant g ctrl-g, but actually 'ruler' is the main reason why 'number' is pointless. You don't actually need a grid constantly telling you the row/col of everything on the screen.

Makes sense. Personally, I am rarely comfortable without line numbers, but it sure is a case of preference.

[WhiteBlackGoose]

Hey there, a bit of my input on this. I think this is a great survey, but I suspect quite a big bias here due to the selection of of the respondents.

Possible sampling bias due survey procedure (user needed to download script, execute it, and post results), which might poorly represent not so tech-savvy users

Not just that - people who take such serveys are already active & involved users of nvim. The survey was posted on reddit, on a subreddit dedicated to neovim - it's a very specific audience, not representing your average nvim user. No way 59% of regular nvim users - or, honestly, even 20 - use relativenumber. (although I don't have any data to prove my suspicion).

FWIW, last point I'd like to make, is that I think there are two kinds of people

• Those who use the default config or just have a couple of lines in it
• Those who extensively tweak nvim
  And imo, the first group is rather conservative, so they'd be annoyed by a sudden change of behaviour, while the second group can tweak it all either way, regarldess of the defaults.

Again, I have no data, these are my thoughts

[echasnovski]

Not just that - people who take such serveys are already active & involved users of nvim. The survey was posted on reddit, on a subreddit dedicated to neovim - it's a very specific audience, not representing your average nvim user.

Although true, unfortunately this line of reasoning can be applied to any voluntary survey announced not through Neovim application itself. People who are not really interested in spending time configuring their setup probably won't be reading any place where announcement might be posted or take part in the survey.

The only solution to this is the mandatory telemetry inside Neovim itself. Which is far from ideal :)

Say, there is a task/need/curiosity to know how people are actually using Neovim. I am really curious to hear any suggestions to get the representative sample of whole Neovim users population.

[lucastrvsn]

Seems like the termguicolors is the most important one for me. I've heard from some coworkers about how "vim/neovim is ugly", but it's just because they're not using termguicolors at launch. Should be the default if the terminal support it? And a follow-up from this, I think the default colorscheme needs some work to be less intimidate to new people 😆

[david-agnostix]

Just noting in passing that lazyredraw breaks updates to the search hit counter, so it probably should not be set as a default. As the docs state, "This may occasionally cause display errors. It is only meant to be set temporarily".

[gpanders]

For 'termguicolors', https://github.com/termstandard/colors#checking-for-colorterm has some useful information for determining support.

This would not be hard for us to implement. We have the technology.

1. If $COLORTERM is truecolor or 24bit, enable 'tgc'
2. If $COLORTERM is set, but is not truecolor or 24bit, disable 'tgc'
3. If $COLORTERM is unset, check terminfo for RGB and Tc capabilities (the former is the "official" capability from ncurses, but the latter has some uses in the wild because of tmux). If either is present, set 'tgc'
4. If neither RGB nor Tc is present in terminfo, query the terminal using the process outlined in the link above. If the terminal's response indicates that it supports truecolor, enable 'tgc'

This sidesteps most common issues:

1. The big issue with $COLORTERM is that it is not forwarded over SSH or with sudo, but the terminfo and query checks get around that
2. The issue with terminfo is that it can be outdated, absent, or incorrect (especially on remote machines). The query check gets around that
3. The query is the ultimate source of truth, but we only fall back to that if necessary (the other methods are much faster)

There is a possibility of a false positive, if a user has $COLORTERM incorrectly set or is using the incorrect terminfo intentionally (e.g. by forcing TERM=xterm-256color or something), but these scenarios are the results of hacks/incorrect configuration.

[justinmk]

Perhaps we should go further and default to 'tgc', and disable it if the above feature-detection fails. That also makes the opt-out logic easy to implement: if user has set 'notgc' then we skip feature-detection.