Skip to content
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
Closed

[Discussion/Tracking] Defaults #2676

fmoralesc opened this issue May 16, 2015 · 102 comments
Milestone

Comments

@fmoralesc
Copy link
Contributor

@fmoralesc 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
Copy link

@ghost 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
Copy link
Contributor Author

@fmoralesc fmoralesc commented May 16, 2015

@pyrohh Added a note about it in the description.

@trusktr
Copy link

@trusktr 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
Copy link
Contributor Author

@fmoralesc 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.

@glts
Copy link
Contributor

@glts 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
Copy link
Contributor Author

@fmoralesc 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
Copy link
Contributor Author

@fmoralesc 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 mentioned this issue May 17, 2015
5 of 5 tasks complete
@glts
Copy link
Contributor

@glts 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
Copy link
Contributor Author

@fmoralesc 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
Copy link
Member

@justinmk 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
Copy link
Contributor Author

@fmoralesc 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
Copy link
Contributor Author

@fmoralesc 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
Copy link
Member

@justinmk 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
Copy link
Contributor

@glts 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
Copy link
Contributor Author

@fmoralesc 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
Copy link

@ghost 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
Copy link
Contributor Author

@fmoralesc 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
Copy link
Member

@fwalch fwalch commented May 19, 2015

@justinmk (#2695 (comment)):

We should set langnoremap by default.

@justinmk
Copy link
Member

@justinmk justinmk commented May 19, 2015

smartindent is obviated by cindent and indentexpr.

@fmoralesc
Copy link
Contributor Author

@fmoralesc 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
Copy link

@ghost 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
Copy link
Contributor Author

@fmoralesc 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
Copy link

@ghost 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
@fmoralesc
Copy link
Contributor Author

@fmoralesc 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
Copy link

@asthasr 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
Copy link
Contributor Author

@fmoralesc fmoralesc commented Oct 28, 2015

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

@asthasr
Copy link

@asthasr 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
Copy link

@trusktr 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
Copy link

@asthasr 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
Copy link
Contributor

@Grimy 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
This reverts commit 2fb074e.
passy added a commit to passy/dotvim that referenced this issue Mar 21, 2016
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
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 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
Copy link
Member

@justinmk justinmk commented Mar 15, 2017

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

@justinmk justinmk mentioned this issue Mar 15, 2017
9 of 20 tasks complete
@justinmk
Copy link
Member

@justinmk 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
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
@gerardroche gerardroche mentioned this issue Jan 11, 2019
49 of 61 tasks complete
jeffkreeftmeijer added a commit to jeffkreeftmeijer/.vim that referenced this issue Dec 23, 2020
[vim-polyglot](https://github.com/sheerun/vim-polyglot) is a collection
of language packs that are loaded on demand by checking the current
file's type. It's great if you switch languages often.

.Managing plugins
****
Vim has a plugin manager since version 8. In the interest of keeping
everything as simple as possible, I'll use that over installing an
external plugin manager.

To install a plugin, place it into `~/.vim/pack/plugins/start` (you can
use any directory name instead of plugins, but this made sense to me).

For more information about packages in Vim, check out `:help packages`.
****

Since this configuration is stored in a [git
repository](https://github.com/jeffkreeftmeijer/.vim), we use git's
submodules to install plugins and update them later.

    $ git submodule add git@github.com:sheerun/vim-polyglot.git pack/plugins/start/vim-polyglot

After installing the plugin, Vim should automatically load the correct
language file for each opened file.

Aside from syntax highlighting, vim-polyglot configures whitespace
preferences per language. Unless you disagree with how whitespace is
handled in the language you use, you can remove your `expandtab` and
`tabstop` configuration and let the language pack handle those.

Lastly, vim-polyglot [includes part of
vim-sensible](https://github.com/sheerun/vim-polyglot/blob/73c518717741fb3ebb6822645d38f37ffae7c19b/plugin/polyglot.vim#L16-L109),
which is loaded unless vim-sensible itself is loaded. On NeoVim, which
[has sensible defaults out of the
box](neovim/neovim#2676), we can disable this
to prevent these defaults from being loaded twice.

    if has('nvim')
      let g:polyglot_disabled = ['sensible']
    endif

Although vim-polyglot checks the presence of vim-sensible by consulting
`g:loaded_sensible`, we're disabling it through vim-polyglot's settings
rather than setting `g:loaded_sensible`. That'll make it easier to take
it out later if we decide to switch away from vim-polyglot.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet