New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion/Tracking] Defaults #2676

Closed
fmoralesc opened this Issue May 16, 2015 · 102 comments

Comments

Projects
None yet
@fmoralesc
Contributor

fmoralesc commented May 16, 2015

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 (#2860)
  • 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

This comment has been minimized.

ghost commented May 16, 2015

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

@fmoralesc

This comment has been minimized.

Contributor

fmoralesc commented May 16, 2015

@Pyrohh Added a note about it in the description.

@trusktr

This comment has been minimized.

trusktr commented May 17, 2015

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

This comment has been minimized.

Contributor

fmoralesc commented May 17, 2015

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.

@justinmk justinmk added the defaults label May 17, 2015

@glts

This comment has been minimized.

Contributor

glts commented May 17, 2015

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

This comment has been minimized.

Contributor

fmoralesc commented May 17, 2015

@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 comment has been minimized.

Contributor

fmoralesc commented May 17, 2015

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.

@fmoralesc fmoralesc referenced this issue May 17, 2015

Closed

[WIP] options: set default &scrolloff to 1 #2687

5 of 5 tasks complete
@glts

This comment has been minimized.

Contributor

glts commented May 17, 2015

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

This comment has been minimized.

Contributor

fmoralesc commented May 17, 2015

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

This comment has been minimized.

Member

justinmk commented May 17, 2015

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

This comment has been minimized.

Contributor

fmoralesc commented May 17, 2015

@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

This comment has been minimized.

Contributor

fmoralesc commented May 17, 2015

@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

This comment has been minimized.

Member

justinmk commented May 17, 2015

Can you tell me what you think of this configuration?

It scrolls the screen, which is IMO very annoying.

@glts

This comment has been minimized.

Contributor

glts commented May 17, 2015

@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

This comment has been minimized.

Contributor

fmoralesc commented May 17, 2015

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

This comment has been minimized.

ghost commented May 19, 2015

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

This comment has been minimized.

Contributor

fmoralesc commented May 19, 2015

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

This comment has been minimized.

Member

fwalch commented May 19, 2015

@justinmk (#2695 (comment)):

We should set langnoremap by default.

@justinmk

This comment has been minimized.

Member

justinmk commented May 19, 2015

smartindent is obviated by cindent and indentexpr.

@fmoralesc

This comment has been minimized.

Contributor

fmoralesc commented May 19, 2015

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

This comment has been minimized.

ghost commented May 19, 2015

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

This comment has been minimized.

Contributor

fmoralesc commented May 19, 2015

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

This comment has been minimized.

ghost commented May 19, 2015

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).

@fwalch fwalch added this to the first release milestone May 19, 2015

@asthasr

This comment has been minimized.

asthasr commented Oct 28, 2015

mouse=a is terrible.

@justinmk

This comment has been minimized.

Member

justinmk commented Oct 28, 2015

@asthasr for another reason or the same as already mentioned?

@asthasr

This comment has been minimized.

asthasr commented Oct 28, 2015

@justinmk The same, with a bit more detail: I tend to use vim over ssh, which means that if mouse=a is the default, I have to explicitly turn it off on every machine where I use neovim. I have never wanted or needed to use the mouse in a terminal application, so the previous behavior was fine for me without ever thinking about it. Now I have to explicitly think about it. (I could turn off mouse integration in my terminal emulator, but then I have to do that on every computer or VM I use, also an unnecessary usage tax...)

@justinmk

This comment has been minimized.

Member

justinmk commented Oct 28, 2015

I'm fine with reverting it, though I use nvim over ssh and have no problems (and the mouse works, too)...

@fmoralesc

This comment has been minimized.

Contributor

fmoralesc commented Oct 28, 2015

I still think mouse=a is strictly the better default because of the UX benefits its has, but mainly, because it makes the behavior of nvim more consistent with other applications. Imho, the only thing nvim lacks so it's perfect is the support for clipboard=autoselect. Then those who like that clipboard model can be happy with it. The fact that nvim steals the selection is the point.

@asthasr

This comment has been minimized.

asthasr commented Oct 28, 2015

Does it make nvim more consistent with other console applications? I expect to use the keyboard to manage my vim selections, etc., while the mouse belongs to my GUI. It is very unintuitive for an app running on a remote box to steal the mouse, and I can't think of any other console application that shares this behavior. The only benefit I can think of is resizing panes inside nvim, but that seems a lot less relevant (at least to me) than copy and paste behaving as I expect from within my terminal.

@fmoralesc

This comment has been minimized.

Contributor

fmoralesc commented Oct 28, 2015

@asthasr: As I see it, that problem is autoselect not working, not nvim stealing the mouse.

@asthasr

This comment has been minimized.

asthasr commented Oct 28, 2015

Even if autoselect works locally, in most cases X will not be forwarded to remote machines over ssh and, as such, there should be no expectation of clipboard availability remotely. In these instances (which are the majority of my workflow), I want the terminal emulator to own the mouse. Having nvim take it over by default doesn't conform with my expectations of a Unix console application.

@trusktr

This comment has been minimized.

trusktr commented Oct 28, 2015

Blake, what terminal are you in on the GUI side? In most terminals you can
hold shift while clicking and dragging to use your GUI selection instead of
the console app's.

/#!/JoePea
On Oct 28, 2015 8:03 AM, "Blake Hyde" notifications@github.com wrote:

Even if autoselect works locally, in most cases X will not be forwarded
to remote machines over ssh and, as such, there should be no expectation of
clipboard availability remotely. In these instances (which are the majority
of my workflow), I want the terminal emulator to own the mouse. Having nvim
take it over by default doesn't conform with my expectations of a Unix
console application.


Reply to this email directly or view it on GitHub
#2676 (comment).

@asthasr

This comment has been minimized.

asthasr commented Oct 28, 2015

@trusktr Good point, didn't realize that. I still don't like the default, but knowing that, it isn't as bad.

@Grimy

This comment has been minimized.

Contributor

Grimy commented Nov 3, 2015

I suggest having nojoinspaces by default. When editing code, you definitely don’t want it on. Even when editing natural language, you probably don’t want it on either (unless you follow the archaic convention of using two spaces after each period).

justinmk referenced this issue in tpope/vim-sensible Mar 21, 2016

Revert "Set lazyredraw"
This reverts commit 2fb074e.

passy added a commit to passy/dotvim that referenced this issue Mar 21, 2016

Remove sensible
I think with
neovim/neovim#2676
this shouldn't be necessary.

meribold added a commit to meribold/dotfiles that referenced this issue Apr 14, 2016

Remove `filetype plugin indent on` and `sy enable`
The settings are [defaults in Neovim][1] and these commands are actually
redundant for Vim as well, because [vim-plug applies the same
settings][2].

[1]: neovim/neovim#2676
[2]: https://github.com/junegunn/vim-plug/wiki/faq

korovamilk added a commit to korovamilk/vim-custom that referenced this issue Oct 19, 2016

@justinmk justinmk referenced this issue Oct 28, 2016

Closed

sensible.vim #4

@justinmk justinmk modified the milestones: 0.3, 0.2 Dec 11, 2016

stsewd added a commit to stsewd/dotfiles that referenced this issue Dec 27, 2016

@justinmk

This comment has been minimized.

Member

justinmk commented Mar 15, 2017

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

@justinmk justinmk referenced this issue Mar 15, 2017

Open

defaults, part 2 #6289

5 of 12 tasks complete
@justinmk

This comment has been minimized.

Member

justinmk commented Mar 15, 2017

Continued at #6289

@justinmk justinmk closed this Mar 15, 2017

elasticdog added a commit to elasticdog/dotfiles that referenced this issue May 8, 2017

Remove options that are now upstream Neovim defaults
I've also tweaked wildmode a bit more to my liking after having
attention drawn to it in the defaults debate issue.

See: neovim/neovim#2676
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment