defaults, part 1

[fmoralesc]

I'm opening this issue to consolidate the discussions in #276, #1664, #1667, #2071 and elsewhere, and to have a place to track progress on the change of default settings.

Notes

RULE 1 of the default club: These defaults should be adjusted considering the most common use cases for nvim.

RULE 2 of the default club: If possible, changes to the defaults should be available in the scenario where there is no $VIMRUNTIME available (e.g., the nvim executable was copied over to a remote server).

PRs opened for this must have options: as a prefix.

There must be a unequivocal argument in favor of changing the defaults, or to reject the proposed changes.

@justinmk has stressed the need to keep the set -& and set -&vim idioms behaving as they do now (which means the approach in #1667 is not viable) (see #1664 (comment), #1667 (comment)) (There's been some discussion on whether it's worth it to keep the set-& idiom, but that is lower priority).

The vi defaults are not to be changed or removed (see #1667 (comment)). This means that if the option uses the P_VI_DEF flag, you'll have to change it to P_VIM and change the default for vim only. E.g.:

  {"wildmode",    "wim",  P_STRING|P_VI_DEF|P_COMMA|P_NODUP,
   (char_u *)&p_wim, PV_NONE,
   {(char_u *)"full", (char_u *)0L} SCRIPTID_INIT},

becomes

  {"wildmode",    "wim",  P_STRING|P_VIM|P_COMMA|P_NODUP,
   (char_u *)&p_wim, PV_NONE,
   {(char_u *)"full", (char_u *)"list:longest,full"} SCRIPTID_INIT},

Changing some of these settings will cause the tests to behave differently, so keep it in mind when working on this.

Also keep in mind you'll need to update vim_diff.txt as well.

These changes are not a priority, and could be introduced after the first release.

New defaults and progress

(These were the settings I had in #1667, which are based on sensible.vim and the discussions in #276. Feel free to comment on them).

Setting	Status	Notes
filetype plugin indent on	INCLUDED (#4252)	can also be fixed by including a default plugin manager
syntax enable	INCLUDED (#4252)	idem
langnoremap	INCLUDED (#2853)
autoindent	INCLUDED (#2857)
backspace=indent,eol,start	INCLUDED (#2639)
complete-=i	INCLUDED (#2854)	Reason: i can make completion slow as currently implemented.
smarttab	INCLUDED (#2855)
nrformats-=octal	INCLUDED (#2668)
ttimeout ttimeoutlen=100	REJECTED
incsearch	INCLUDED (#2858)
hlsearch	INCLUDED (#2859)
mouse=a	INCLUDED (#19290)
laststatus=2	INCLUDED (#2876)
ruler	REJECTED (#6087)	Can be super slow on functional tests
showcmd	REJECTED (#6087)	Can be super slow on the functional tests
wildmenu	INCLUDED (#2677)
wildmode=list:longest,full	REJECTED (#2677) (#3395)	Not a clear win over the Vim default.
scrolloff=1	REJECTED	(PR: #2687)
sidescrolloff=5	REJECTED	(for same reasons as scrolloff=1.)
sidescroll=1		https://ddrscott.github.io/blog/2016/sidescroll/
display+=lastline	INCLUDED (#2866)
listchars=tab:>\ ,trail:-,nbsp:+	INCLUDED (#2872)
formatoptions+=j	INCLUDED (#2669)
search upwards for tags file. setglobal tags-=./tags tags^=./tags;	INCLUDED (#2670)
autoread	INCLUDED (#2856)
fileformats+=mac	REJECTED (#2867)
history=10000	INCLUDED (#2868)
tabpagemax=50	INCLUDED (#2869)
viminfo^=!	INCLUDED (#2870)
sessionoptions-=options	INCLUDED (#2871)
runtime! macros/matchit.vim	INCLUDED (#2723)
shortmess+=c	REJECTED	might not be appropriate generally, helps with autocomplete plugins
background=dark	#2894	details
auto-create 'backupdir' if 'backup' is set

Some mappings have been proposed too:

Mapping	Status	Notes
Y yanks to the end of the line. noremap Y y$	REJECTED
allow undoing <C-u> (delete text typed in the current line) inoremap <C-U> <C-G>u<C-U>	DECIDED AGAINST
<home> goes to the beginning of the text on first press and the beginning of the line on second. it alternates afterwards. noremap <expr> <home> virtcol('.') - 1 <= indent('.') && col('.') > 1 ? '0' : '_'	DECIDED AGAINST
<esc><esc> leaves terminal mode.	REJECTED
use <C-L> to clear the highlighting of :set hlsearch. nnoremap <silent> <C-L> :nohlsearch<CR><C-L>	DECIDED AGAINST

Other tasks

• Update runtime/vimrc_example.vim

[ghost]

Just a note to anyone who wants to send PRs regarding this: please update vim_diff.txt as well.

[fmoralesc]

@pyrohh Added a note about it in the description.

[trusktr]

allow undoing (delete text typed in the current line) inoremap <C-U> <C-G>u<C-U>

Does <C-G>u<C-U> revert to previous nodes in the undo tree? It doesn't do that for me, but rather it creates new undo tree nodes, and then in NORMAL mode I can undo the undos which finally brings me back to what I undid while I was in INSERT mode, then I can undo one more time to undo that whole thing.

[fmoralesc]

Does <C-G>u<C-U> revert to previous nodes in the undo tree? It doesn't do that for me, but rather it creates new undo tree nodes...

No, it does what you say. There's an explanation at the vim wiki:

Generally, when you insert text (after an i or o or other similar command) you make a single modification to the file that forms one undo block. Pressing Ctrl-u or Ctrl-w while in insert mode is just part of that single modification. After pressing Esc to return to Normal mode, if you press u you will undo all your typing. Therefore, you have lost text deleted with Ctrl-u or Ctrl-w.

However, some insert-mode commands break the undo block so the insertion consists of more than a single modification. One of those commands is Ctrl-g u.

[glts]

I don't see the point of set scrolloff=1.

It reduces my 'text canvas' (the screen area I can reach without scrolling) by one line at the top and one line at the bottom. There would now be two lines visible on the screen that I can't reach directly any more (H becomes Hk and scrolls the screen). But in Vim, I expect to be in charge of my cursor. I expect H to take me to the very top of the screen.

I've just checked TextEdit and gEdit, both behave as with scrolloff=0. They don't scroll when there's no need to, only when the cursor would leave the screen. Most editors work this way, don't they?

I think scrolloff=0 seems like a reasonable default. scrolloff=1 seems ok, too, but the behaviour is slightly less expected (cue Stackoverflow questions 'can't move my cursor to the first line in Neovim!'), and for advanced users perhaps slightly less useful.

[fmoralesc]

@glts Been thinking of this, and I tend to agree with you. I asked @tpope at vim-sensible about the rationale behind it, just so we have more info about this.

[fmoralesc]

This is the reply I got:

Based entirely on my personal experience, adding just a single line of mandatory context greatly reduces my need to fiddle with /. If I read you correctly, you are asserting that it causes H to move the viewport, but it does not: It changes which line is jumped to. (I agree this is a bit unfortunate, but it is still very predictable, just a bit harder to explain.)

(For the "if I read you correctly" part, I was a bit confused about scrolloffs behavior.) I think @tpope also makes a good point. He also adds:

I would further add that you are the first person to bring this up, which is saying a lot if you've taken a look at the sort of petty objections people raise. Whether that justifies changing the neovim default, I cannot say. I can say you have the advantage it can still be trivially overridden in a user's own config, unlike for late loading sensible.vim.

which I found insightful.

[glts]

I went outside for a walk, and am now convinced that scrolloff=0 is the better default.

One, scrolloff=1 'breaks' the firmly entrenched idiom H M L to go to the top, middle, bottom of the screen. This is advertised in many Vim tutorials, in :h 03.5, in Practical Vim, etc. Vim is famous for letting you go to anywhere on your screen with two or three keystrokes max, and H and L are part of this game. It would not be Vim-like to put the training wheels on H/L and not let them jump to top/bottom any longer.

Two, scrolloff=1 is inconsistent with the experience in other editors, which do not do this by default. Of the dozen or so editors on my machine I found only one that does it like scrolloff=1 by default (IntelliJ IDEA).

I conclude that scrolloff is a nice feature for those who do feel they need one additional line of context at all times, but I believe it should be opt-in; it should not be made the default.

And that's it from me. 😄

[fmoralesc]

What about making H and L jump to the line that's on top or bottom of the window and scroll scrolloff lines up or down? (Basically, make H a mapping for H{scrolloff}<C-Y> and L a mapping for H{scrolloff}<C-U>). That way, you still jump to the line you want, and the extra context is shown.

[justinmk]

Agreed with @glts , I had always expected that we would not adopt scrolloff from sensible.vim. Same with sidescrolloff.

Just to get my other objections out of the way:

• ttimeout should continue to be disabled for Neovim. (I question whether we should support this option at all)
• history should be 10,000 (with @ZyX-I 's shada this makes even more sense)

[fmoralesc]

@glts, @justinmk Can you tell me what you think of this configuration?

set scrolloff=1
noremap <expr> H 'H' . eval('&scrolloff') . '<C-u>'
noremap <expr> L 'L' . eval('&scrolloff') . 'j'

EDIT: The mapping for L needed some tweaking. Wonder why H and L behave differently.

[fmoralesc]

@justinmk I agree about ttimeout, and I like that value for history better. We can defer to @ZyX-I's shada work for changes in that setting, i'll make a reference to it in the description.

[justinmk]

Can you tell me what you think of this configuration?

It scrolls the screen, which is IMO very annoying.

[glts]

@fmoralesc I think the mappings aren't too bad, but then there's a rat-tail of other commands that you might want to 'fix' in this way such as zt ...

I appreciate this 'Defaults' initiative, I really do, but in the case of scrolloff=1 I believe it's a matter of taste; there doesn't seem to be an obvious, unequivocal argument to justify the change. And such an argument should exist to make it the default.

[fmoralesc]

there doesn't seem to be an obvious, unequivocal argument to justify the change. And such an argument should exist to make it the default.

OK, then, let's make that a policy. I'll include it to the Notes here, and mark this one setting as a dud, like I did with ttimeout.

But we also might need a policy not to prevent a setting to be the default unless a good argument is provided against it :p

[ghost]

I'm fine with autoindent, but I haven't used smartindent for a while and am unsure it's needed. I found this SO thread, which might explain why I've never noticed any change in functionality since I stopped using it. Not sure about all that, so please correct me if I'm wrong.

[fmoralesc]

Hm... that SO thread has a good point. Since we are enabling filetype plugins (hopefully ;)), indentation should be better than what smartindent provides for most use cases, so smartindent is probably not necessary. As a general purpose thing, though, it isn't a bad default (and it is disabled when some indentexpr is given, so the negatives are somewhat limited).

[fwalch]

@justinmk (#2695 (comment)):

We should set langnoremap by default.

[justinmk]

smartindent is obviated by cindent and indentexpr.

[fmoralesc]

Adding langnoremap to the set of new defaults.

Btw, did someone took out smartindent from the list, or was it never there? Did @pyrohh confuse it with smarttab?

[ghost]

Btw, did someone took out smartindent from the list, or was it never there? Did @pyrohh confuse it with smarttab?

I never edit people's posts, so it wasn't me. In any case, I'm pretty sure I just saw smarttab there and accidentally read it as smartindent.

[fmoralesc]

I won't mind if anyone with access touches up the issue here (for example, if someone opens a PR about one of these, I might not see it right away and the issue description might get outdated); anyway, i just realized we had derrailed on the smartindent stuff. I wasn't pointing fingers or anything ;)

[ghost]

I won't mind if anyone with access touches up the issue here (for example, if someone opens a PR about one of these, I might not see it right away and the issue description might get outdated)

👍 I'll mark some checkboxes if I see they're outdated.

I wasn't pointing fingers or anything ;)

Oh yeah, of course. I was just clarifying I wouldn't edit posts (unless something was said, like you did above).

[justinmk]

@fmoralesc Any recollection about why we decided against inoremap <C-U> <C-G>u<C-U> ?

[justinmk]

Continued at #6289