[Discussion/Tracking] Defaults #2676

Open
fmoralesc opened this Issue May 16, 2015 · 100 comments

Projects

None yet
@fmoralesc
Contributor
fmoralesc commented May 16, 2015 edited

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 (#2874) Can be super slow on functional tests
  • showcmd
REJECTED (#2873) 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
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
Contributor

@Pyrohh Added a note about it in the description.

@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
Contributor

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
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 fmoralesc referenced this issue in tpope/vim-sensible May 17, 2015
Closed

Why is scrolloff set to 1? #95

@fmoralesc
Contributor

@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
Contributor

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
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
Contributor

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
Member

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
Contributor

@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
Contributor

@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
Member

Can you tell me what you think of this configuration?

It scrolls the screen, which is IMO very annoying.

@glts
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
Contributor

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
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
Contributor

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
Member
fwalch commented May 19, 2015

@justinmk (#2695 (comment)):

We should set langnoremap by default.

@justinmk
Member

smartindent is obviated by cindent and indentexpr.

@fmoralesc
Contributor

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
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
Contributor

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
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
@fwalch
Member
fwalch commented May 20, 2015

Can we come up with a better default for exiting terminal mode? C-</kbd>C-n is not really "discoverable", I think.

@fmoralesc
Contributor

Can we come up with a better default for exiting terminal mode? C-\C-n is not really "discoverable", I think.

👍 I keep forgetting it...

@justinmk
Member

It isn't really meant to be discoverable, although it is discoverable to any user who is already familiar with the existing function of c-\ c-n.

c-\ c-n is a good choice because it is consistent with existing conventions. Unless we want to map <esc><esc> by default I doubt anything else will be discoverable (we cannot claim <c-c> because it is needed for normal shell operations...).

Why not add a recommended mapping in the help somewhere?

@fmoralesc
Contributor

It isn't really meant to be discoverable, although it is discoverable to any user who is already familiar with the existing function of c-\ c-n.

Sorry, but why do we even have features which are not meant to be discoverable? (I know you didn't really mean that...) We shouldn't expect users to be terribly familiar with that.

Anyway, fair point, but we'll need to emphasize that in the docs about <C-\><C-n>.

@justinmk
Member

Sorry, but why do we even have features which are not meant to be discoverable?

Keymaps in vim are not always meant for the user. E.g. g@ is never actually pressed by users, it's only used by functions. Same with :help c_CTRL-\_e and, I contend, CTRL-\_CTRL-N.

Keymaps in Vim should be treated like functions: they may be "subclassed" by remapping; the base implementation is available via :norm! and noremap...

@fmoralesc
Contributor

Keymaps in vim are not always meant for the user. E.g. g@ is never actually pressed by users, it's only used by functions. Same with :help c_CTRL-_e and, I contend, CTRL-_CTRL-N.

But in this case, <C-\><C-n> has to be used by the user to leave terminal mode, so the point is...?

(Of those, only g@ makes sense being used only in functions, and it really is a shortcut to calling the function defined by operatorfunc; one could in principle replace it with an eval() call... [if vim exposed enough state, which I'm not sure it does now that I think of it])

@justinmk
Member

so the point is...?

The point is not all keymaps are meant to be discoverable. Same problem with :q for new users.

@splinterofchaos
Member

I think this is really a RTFM situation. Any keymap that's totally discoverable will also be accidentally pressable. Vim has never been a "plug and play" program, it targets autodidacts who take the time to learn how it works.

@fmoralesc
Contributor

@justinmk, @splinterofchaos Fair enough. But I think the problem needs more attention (which is why I've been pushing forward #1692 and this). I mean, how the fuck do I RTFM if I don't know how to go into command mode and run help ("I was just trying out this cool new feature, and now I'm stuck! Damn it all!" Which is exactly the same issue that puts people off when trying vim for the first time...)

@splinterofchaos
Member

I mean, how the fuck do I RTFM if I don't know how to go into command mode and run help

Good point. One should know how to exit terminal focus at the same point as they learn about it. How do they learn about it? In :h :terminal, at least we should have a note about <C-\><C-n>, but to even know to run :h :terminal, they must have learnt it somewhere else.

@justinmk
Member

Ok, maybe a default of :tnoremap <esc><esc> <c-\><c-n> makes sense. (As a default user map, not the internal function name. The internal function name should still be <c-\><c-n>)

@fmoralesc
Contributor

<esc><esc> is a lot more convenient, but wouldn't it introduce a delay in the handling of <esc> keys in the terminal? I'm not sure how significant that would be, though.

Btw, I realized why I always forget the <C-\><c-n> mapping: in my keyboard layout ("Spanish (latin-american)"), it is really awkward to perform: I have to type CTRL + ALTGR (the right ALT) + (the second key at the left of BACKSPACE) + CTRL + N. I imagine it is just as bad in other keyboard layouts, if not worse:

latam keyboard layout

As a default user map, not the internal function name.

@justinmk Oh, for sure. As you pointed out, it makes complete sense to keep <c-\><c-n> behaving as it does now. Only thing I worry about is how to implement this: maybe the best is to put it in a plugin which can be disabled through a variable in the user's vimrc?

@fwalch
Member
fwalch commented May 21, 2015

We could also print a message somewhere, similar to Type "visual" to go to Normal mode..

@fmoralesc
Contributor

@fwalch Yes, I thought we might append something like that to the terminal statusline for a while.

@cpenner-va

👍 for <esc><esc>, though with similar concerns regarding a delay from sending esc to the terminal session, thinking about it now though, I think vim is pretty much the only time I need to send <esc> to a terminal program, though I often mash escape to try and exit many programs before I remember they use q instead. E.g., I try to exit 'top' and 'less' with esc almost every time.

That being said, I very much agree, <c-\><c-n> makes sense as the reference 'command', but it's atrociously undiscoverable to any non-guru user (which I HOPE we'll get a lot of 😄 ).

@splinterofchaos
Member

If we use <Esc><Esc> for this, how will I send just an <Esc> to terminal programs? The beauty of <C-/><C-n> is that I can send <C-\> via <C-\><C-\>. Basically, the second press must be a different button, like <Esc><q> or something.

@fmoralesc
Contributor

@splinterofchaos if the timeout expires, it will just send the first <esc>? Or the tui doesn't work that way anymore?

I thought about <A-Esc> (very little chance of collision there) but that doesn't seem to be working...

@splinterofchaos
Member

I thought we wanted to move away from timeout based input. It can be kinda buggy and we already have a few issues related to it.

@justinmk
Member

We only have issues with ttimeout. 'timeout' is not going away.

@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue May 29, 2015
@fmoralesc fmoralesc plugin: extra default keymaps
See `:help nvim-extra-keymaps`.

Re: neovim#2676
970d026
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue May 29, 2015
@fmoralesc fmoralesc defaults: extra mappings
see `:help nvim-extra-mappings`

Re: neovim#2676
19084db
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue May 29, 2015
@fmoralesc fmoralesc defaults: extra mappings
see `:help nvim-extra-mappings`

Re: neovim#2676
2afa22b
@ghost
ghost commented May 29, 2015

@fmoralesc I updated your post regarding nrformats... just want you to know it wasn't a ghost :)

@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue May 30, 2015
@fmoralesc fmoralesc defaults: extra mappings
see `:help nvim-extra-mappings`

Re: neovim#2676
c09b2b0
@frederikvs
Contributor

I seem to be a bit late to this discussion, but still I'd like to make a case for having a simple <Esc> be the default way for a user to leave terminal-mode.

I personally think that many users don't need to send <Esc> to the terminal all that often - and when they do, pressing e.g. <c-\><Esc> is not a huge problem. (This may be just my availability bias speaking, I haven't measured anything. If you do use <Esc> in the terminal a lot, could you let us know which programs you're running, or why it's useful? Don't say 'nvim', you know what I mean.)

Using <Esc> is much more consistent with other modes. Whenever I press <Esc> I would like to be in normal mode. (You can imagine my frustration when I accidentally press q: instead of :q)
The people who need to send <Esc> to the terminal often can always remap any way they like. But I believe the defaults should be sensible, and consistent.

The proposal of using <Esc><Esc> would cause a delay when you want to send <Esc> to the terminal. It would also need two keypresses to leave terminal-mode.
Also, it would be counter-intuitive - terminal mode and insert mode are very close relatives. Having to do different things to leave them means you're being inconsistent. Like I said, IMO, the defaults should be consistent.

BTW, I'm not sure about the proper place to discuss this, there's also #2760, which is more recent, but this already has more of the discussion and argumentation...

P.S. I might add that the current documentation includes the example :tnoremap <Esc> <C-\><C-n> - I take that as a signal that this would indeed be a sensible default.

@fmoralesc
Contributor

I was thinking... is it possible to make <Esc> behave like this in terminal mode?

  • If pressed, pass to the program running in the terminal.
  • If the buffer doesn't change (we can assume pressing <esc> had no effect on the program running in the terminal) before timemout, leave terminal mode.

This would be both consistent with vim's behavior around <Esc> most of the time, and compatible with terminal applications that use <esc>.

@frederikvs
Contributor

I understand where you're going, but I don't think that would work. If I've just started e.g. a make install or something, and I press <Esc>, the buffer would change because of the normal output of the command, not as a result of the <Esc>. There's no way for neovim to know what the cause of the change is, neovim just sees the change, and concludes that I wanted to send <Esc> to the terminal...

@pgdouyon
pgdouyon commented Jun 2, 2015

Looks like I'm a bit late to the party too, but just another argument against any default terminal mapping using <Esc>, which I haven't really seen yet, is vi-keybindings in readline-based programs (i.e. set -o vi in bash or similarly in zsh).

I can imagine that causing a lot of problems for people who mash <Esc> several times to ensure they're out of insert mode or something and then inexplicably find themselves in normal mode in neovim instead of in the terminal.

@pgdouyon
pgdouyon commented Jun 2, 2015

Also as far as discoverability goes I don't see how this is much different from a new user not knowing how to get out of insert mode, quit Vim, or exit Ex mode. If anything it's probably easier than the other ones, because while you're in the terminal you can just fire up a new nvim session and run :h terminal, it's not an ideal solution but the user isn't quite as helpless.

I imagine most people will get around it the same way they've gotten around other strange corners of Vim. It's not a bug likely to bite people more than once, they'll Google it and then make a mapping for it.

Seems like the place for this kind of thing is some form of NvimTutor.

@fmoralesc
Contributor

Also as far as discoverability goes I don't see how this is much different from a new user not knowing how to get out of insert mode, quit Vim, or exit Ex mode.

It is not only bad from a discoverability point of view, it sucks for us with keyboards where the default mapping implies 5 keypresses all over the keyboard... A good default (besides <C-\><C-n>, which should stay anyways, because it is consistent with the rest of vim) is preferable, especially if we manage to avoid the corner cases mentioned in this thread).

@simonweil
Contributor

I use vi mode in bash which which is why I've mapped <esc>``<esc> to exit terminal mode. To me this is very intuitive.

@pgdouyon
pgdouyon commented Jun 2, 2015

I agree a good default is preferable, I just don't think a default starting with <Esc> is a good default given how many terminal programs make use of it (plus ANSI escape codes).

It might be worth looking at how Emacs-Evil solves this problem with eshell/ansi-term. Otherwise, I think neovim is the only modal editor with an embedded terminal.

Personally, I use <C-Q> to exit terminal mode, but that would definitely be a terrible default since it's used for flow control in some terminals.

@frederikvs
Contributor

Also as far as discoverability goes I don't see how this is much different from a new user not knowing how to get out of insert mode, quit Vim, or exit Ex mode.

On the one hand there's discoverability for a new user, for which the difference is rather small. It is still there, though, in the form of inconsistency. It's the difference between saying "to go to normal mode, press escape", or having to explain "to go to normal mode, usually you just press escape, except in these and these situations, where you do something else". (There are already situations where <Esc> doesn't cut it, but let's not make matters worse.)

There is also, however, discoverability for the vim-experienced user, new to neovim. He/she will have heard about this fantastic new feature called terminal mode, and will want to try it out. If it then goes against his years of training "normal mode : escape", that's a bump in the road. One bump may not be enough to make him turn back, but a bunch of bumps and he'll think "I'll come back when they've finished construction".

given how many terminal programs make use of it

So far I've only heard vi-mode in certain shells. Which other programs use it?
I could be mistaken, but I think people using vi-mode are rather rare. Those who do use it are of course still very welcome to remap things to their liking. But I don't think we should choose our defaults for a small subset of users.

Also, as a side note, no matter the result of this discussion, I will be using a single <Esc>. The reason I'm trying to make that the default, is that I believe this will cause the least amount of friction to people getting started. So please make the distinction between "that's how I want to work", and "that's how I believe most people would want to work"

I use vi mode in bash which which is why I've mapped <esc><esc> to exit terminal mode. To me this is very intuitive.

So if you're in normal mode and you want to edit your command, you have to go i<esc> to give commands that modify your command line?

Call me nuts, but I was just thinking : how difficult would it be to modify bash to integrate nicely with nvim? Right now there's have a half-assed implementation of something resembling vim, which doesn't really cooperate with the complete nvim at all. What if you could change it, so that your actual neovim can prepare the command that bash will execute?
Don't ask me what an insane amount of work that would be, I haven't gone that far yet. Maybe it's a crazy idea, but then again, forking one of the most powerful and complex editors around and doing a massive overhaul was crazy too..
Sending images and videos over terminal escape codes was insane as well, but have a look at https://www.enlightenment.org/about-terminology
So all sides can actually be modified to do amazing things...
Might deserve its own thread for discussion though :-)

@simonweil
Contributor

About integration with bash try https://github.com/ardagnir/athame
Haven't used yet myself but it seems interesting. ..

I don't understand your point about i<esc>

@pgdouyon
pgdouyon commented Jun 2, 2015

So far I've only heard vi-mode in certain shells. Which other programs use it?

It's not just some shells though, it's any program that uses the Readline library such as the python REPL IIRC. Also any program that delegates to $EDITOR or $VISUAL like git commit or crontab -e. Using Vim in the terminal to write a quick Git commit message would turn into a big hassle. And it's not enough to say that users should use a plugin like Fugitive because they could also be using a less popular VCS like subversion or cvs. (Granted this could be mitigated with something akin to emacsclient, but as of right now we don't have one included with neovim AFAIK).

It may or may not be a small subset of terminal users that use vi-mode, but I would wager that close to 100% of them are also Vim users. Seems strange to intentionally alienate this group. If neovim allowed for editing the terminal prompt it would mitigate this, but that still leaves programs that delegate to Vim via $EDITOR.

I'm all for consistency and sane defaults, I just personally think <Esc> is a dangerous one. To each his own.

@pgdouyon
pgdouyon commented Jun 2, 2015

Put another way, I think <Esc> as a default mapping would be a fantastic idea if we included something akin to emacsclient that users could set as their $EDITOR and made it possible to edit the terminal prompt obviating the need for vi-mode.

@frederikvs
Contributor

Just a quick reply regarding the $EDITOR thing : there's a feature coming up which will allow us to give commands to a running nvim. If my understanding is correct, we can use this so that when something tries to start an nvim within nvim (e.g. because of a git commit), the inner nvim (or perhaps a wrapper script) could detect this, and instead of actually opening, command the outer nvim to open the files, in much the same way as if you had typed :e <filename>

I'll read and reply to the rest of what's been said when I can give it the time and attention it deserves.

@fwalch
Member
fwalch commented Jun 2, 2015

Call me nuts, but I was just thinking : how difficult would it be to modify bash to integrate nicely with nvim? Right now there's have a half-assed implementation of something resembling vim, which doesn't really cooperate with the complete nvim at all. What if you could change it, so that your actual neovim can prepare the command that bash will execute?

The idea of providing a drop-in replacement for readline has come up before (@bfredl, if I remember correctly). That would certainly be an awesome feature, but let's discuss it in a different issue (feel free to open a new one for that), it's not really related to the defaults.

@frederikvs
Contributor

I don't understand your point about i<esc>

Suppose you're in nvim, a split screen, terminal in one, and you've entered part of a (rather long) command. You're on the other side of the split, e.g. looking something up, and you realise you need to add a flag or a parameter at the beginning of the command. You switch to the terminal-screen. You now need to go i (to get into terminal-mode), <esc> (to get to bash's vi-mode, still in nvim's terminal mode) and then you can press e.g. ^ or a few Bs to get to the point where you want to add the command line flag.
To me this seems strange, having to press i and <esc> right after each other

It may or may not be a small subset of terminal users that use vi-mode, but I would wager that close to 100% of them are also Vim users.

That could very well be true. But if only e.g. 5% of all Vim users are vi-mode users, then our default shouldn't be focused on them. So long as we aren't making things impossible for them, I don't think we're alienating them. It's only a mapping away.
The defaults should be suitable for as many people as possible. The possibilities for advanced users should not be limited. But the default does not limit the advanced user, since he can map.

Put another way, I think <Esc> as a default mapping would be a fantastic idea if we included something akin to emacsclient that users could set as their $EDITOR and made it possible to edit the terminal prompt obviating the need for vi-mode.

Maybe that's exactly what we need to do :)

it's not really related to the defaults.

Except that this feature will influence what the "best" defaults are. If your current nvim-session can take over readline's task, there's hardly any case left where you want to send <Esc> to the terminal, strengthening the case to make that the default.
But indeed, the actual discussion on if/what/how/... should take place in another issue. The result of that discussion should come back to here.

I'll do some more research on what's been proposed so far, and write a proposal in a new issue :-)

@justinmk
Member

re https://gitter.im/neovim/neovim?at=5578faf205c872ce6ac8a0b6 I added this to the list:

set shortmess+=c
@Shougo
Contributor
Shougo commented Jun 12, 2015

set shortmess+=c

It is useful for auto completion plugins.
But I don't think this should be set in default.
It disables all completion messages.

@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 18, 2015
@fmoralesc fmoralesc default: enable 'langnoremap' 834e852
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 18, 2015
@fmoralesc fmoralesc defaults: remove "i" from the default 'complete'
"i" could slow down the completion.

Re: neovim#2676
0f077ed
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 18, 2015
@fmoralesc fmoralesc defaults: enable 'autoread' by default f413f55
@fmoralesc
Contributor

As you can see, I've started working on filling the gaps in the tasks outlined above. If someone wants to help, it would be appreciated.

On one point I want to get some direction, though: most tests assume the old defaults (especially legacy tests; I came up with this when changing 'autoindent' to 1, for example, which made 10 or so tests to fail), and I wanted to know if it's OK to just make those assumptions explicit instead of changing the tests themselves (which is more time demanding). Perhaps the tests should be expanded to deal with the new defaults? /cc @justinmk

@justinmk
Member

Perhaps the tests should be expanded to deal with the new defaults?

That would be ideal, but for now it's fine to add the old default in a before_each (is that what you were thinking?).

@fmoralesc
Contributor

is that what you were thinking?

Yes, but I wasn't too keen on the idea, for obvious reasons. I'll do this for now, and if I get some extra time I'll try to expand the tests.

@justinmk
Member

if I get some extra time I'll try to expand the tests.

Ok, probably the legacy tests should not be updated though (they should use the before_each approach).

@fmoralesc
Contributor

OK. 👍

In the case of autoindent it seems like what is happening is the new value is messing up the helpers.insert() lua function (the characters are fed to vim like they were user input), which in turn causes trouble in a bunch of tests. Resetting 'autoindent' in the affected tests fixes it, but it seems like the wrong solution.

@justinmk
Member

Resetting 'autoindent' in the affected tests fixes it, but it seems like the wrong solution.

I'm ok with actually setting it for the entire test infrastructure (in session.lua) in that case. We can deal with it more rigorously later.

@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: enable 'autoindent' 5f6ae7a
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: enable 'autoindent' b796d3d
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: enable 'incsearch' by default
This also updates the documentation about 'incsearch'.

Re: neovim#2676
46bdaa4
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: enable 'hlsearch' by default
Also, update the documentation regarding the option.

Re: neovim#2676
382f160
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: enable 'hlsearch' by default
Also, update the documentation regarding the option.

Re: neovim#2676
4d1f5fc
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: set 'mouse' to 'a' by default.
Re: neovim#2676

Also, some documentation changes.
5c08457
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: enable 'incsearch' by default
This also updates the documentation about 'incsearch'.

Re: neovim#2676
7a57d68
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 19, 2015
@fmoralesc fmoralesc defaults: enable 'hlsearch' by default
Also, update the documentation regarding the option.

Re: neovim#2676
aaacadd
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 20, 2015
@fmoralesc fmoralesc options: set 'history' to 10000 (the max) by default. c6bad2a
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 20, 2015
@fmoralesc fmoralesc options: set 'history' to 10000 (the max) by default. a3431b0
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 20, 2015
@fmoralesc fmoralesc options: set 'tabpagemax' to 50 by default. 01859be
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 20, 2015
@fmoralesc fmoralesc options: prefix "!" to 'viminfo' by default 139cef8
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 20, 2015
@fmoralesc fmoralesc options: set 'listchars' to "tab:>\ ,trail:-,extends:>,precedes:<,nbs…
…p:+" by default

Re: neovim#2676
dbad62c
@justinmk justinmk added a commit that referenced this issue Jun 20, 2015
@fmoralesc @justinmk fmoralesc + justinmk defaults: enable 'incsearch' by default. #2858
This also updates the documentation about 'incsearch'.

Re: #2676
ffeffcb
@justinmk justinmk added a commit that referenced this issue Jun 20, 2015
@justinmk justinmk defaults: enable 'hlsearch' by default. #2859
Also update the documentation regarding the option.

Re: #2676
9ebb5c6
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 20, 2015
@fmoralesc fmoralesc options: enable 'showcmd' by default on Unix 56c4c3f
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 20, 2015
@fmoralesc fmoralesc options: set 'ruler' by default 09d1070
@justinmk justinmk referenced this issue in tpope/vim-sensible Jun 23, 2015
Closed

if neovim nottimeout #98

@mikeastock mikeastock added a commit to mikeastock/dotfiles that referenced this issue Jun 24, 2015
@mikeastock mikeastock Handle new neovim defaults
See here for defaults neovim/neovim#2676
8cafdc7
@justinmk
Member

Another default we need to fix is 'background'. I think since we neutered 'term' it effectively always defaults to background="light". We should restore the logic outlined in :help 'background', or as a quick-fix, just always default to `"dark".

@fmoralesc
Contributor

@justinmk OK, I'll look into it.

@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 27, 2015
@fmoralesc fmoralesc options: set 'listchars' to "tab:>\ ,trail:-,extends:>,precedes:<,nbs…
…p:+" by default

Re: neovim#2676
64c2176
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 27, 2015
@fmoralesc fmoralesc options: set 'history' to 10000 by default.
Note: the new history value is the max allowed.

Re: neovim#2676
d775ed9
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 27, 2015
@fmoralesc fmoralesc options: set 'history' to 10000 by default.
Note: the new history value is the max allowed.

Re: neovim#2676
9f96c8e
@fwalch
Member
fwalch commented Jun 29, 2015

Related: Update runtime/vimrc_example.vim, since some of the defaults are explicitly set in there.

This file is mentioned at the end of vimtutor (#2700).

@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 29, 2015
@fmoralesc fmoralesc update vimrc_example file
Because of recent work on defaults (see
neovim#2676)
73755ff
@fmoralesc
Contributor

@fwalch Just opened a PR about it.

@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 29, 2015
@fmoralesc fmoralesc update vimrc_example file
Because of recent work on defaults (see
neovim#2676)
5686fa7
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 29, 2015
@fmoralesc fmoralesc update vimrc_example file
Because of recent work on defaults (see
neovim#2676)
fc5e075
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jun 29, 2015
@fmoralesc fmoralesc Update vimrc_example file
Because of recent work on defaults (see
neovim#2676)
b40f95d
@fmoralesc fmoralesc added a commit to fmoralesc/neovim that referenced this issue Jul 19, 2015
@fmoralesc fmoralesc options: set 'history' to 10000 by default.
Note: the new history value is the max allowed.

Re: neovim#2676
136c0e8
@fmoralesc fmoralesc added a commit that referenced this issue Jul 20, 2015
@fmoralesc @justinmk fmoralesc + justinmk defaults: set 'history' to 10000 by default. #2868
Note: the new history value is the max allowed.

Re: #2676
b4a5871
@mgraczyk mgraczyk added a commit to mgraczyk/neovim that referenced this issue Aug 10, 2015
@fmoralesc @mgraczyk fmoralesc + mgraczyk defaults: set 'history' to 10000 by default. #2868
Note: the new history value is the max allowed.

Re: neovim#2676
e8a1cd4
@mgorny mgorny pushed a commit to gentoo/gentoo that referenced this issue Aug 14, 2015
@yngwin yngwin app-editors/neovim: refactor our default nvimrc
Since neovim sets many sensible deafults now (see [1]), we can drop most
general settings that were copied from app-editors/vim-core's vimrc.
Also apply stripping whitespace only to *.e{build,class} and give users an
easy way to turn that off (bug 557352).

1: neovim/neovim#2676

Package-Manager: portage-2.2.20.1
e11e107
@fmoralesc
Contributor

@Hettomei, I think that would require a new option, since it's not covered in one of the currently available settings. This issue is for tracking changes to the current defaults only, not for requesting new features.

@justinmk
Member

I've thought that repurposing the ? register would be good for that. It's an enhancement though, does not belong in this issue.

@fmoralesc
Contributor

All the defaults tagged for the 0.1 release are merged, so I'm changing the milestone for the items left to 0.2 unless someone wants to add something else to 0.1 (syntax on, maybe?)

@justinmk
Member

I'm going to try a PR for the default mappings, then we can close this. Any remaining items can be separate issues.

@fmoralesc
Contributor

👍

@jalcine
jalcine commented Aug 30, 2015

@justinmk commented on Aug 28, 2015, 12:36 PM EDT:

I'm going to try a PR for the default mappings, then we can close this. Any remaining items can be separate issues.

13 days of subscribed updates and I'm excited for this!

@juanibiapina

#276 is a long thread, but it seems you think mouse=a is a good default? It steals the selection from your terminal. Not sane.

Now I have to disable mouse. What if in the future there are more mouse options, do I have to keep disabling them all?

@fmoralesc
Contributor

@juanibiapina When clipboard=autoselect is implemented, mouse=a will make much more sense. (A better config for the popup menu would be helpful too). What is the use-case where this troubles you? What do you need to do?

Also, there are no more mouse related option changes in mind, so there shouldn't be any more issues moving forward.

@fmoralesc
Contributor

@justinmk I had forgotten about it, but you might reuse fmoralesc@fb31fd9 and fmoralesc@aed04b7 for some of the proposed default mappings. I had those in that PR that everyone hated ;).

@juanibiapina

@fmoralesc Thanks, I'll take a look at the clipboard options, see If I can get to a good setup here.

@dbarnett
Contributor

Have we discussed packaging this distribution of default settings up as a plugin (or making available through sensible.vim) so that someone using both vim and neovim can have consistent settings in both environments?

@fmoralesc
Contributor

@noahfrederick for reference, wildmode reverted to 'full'.

@justinmk
Member

@dbarnett These defaults are a subset of sensible.vim. Neovim users should guard sensible.vim in a if !has('nvim') condition. Personally, I've taken to inlining sensible.vim so that I have the settings available on machines where I don't install plugins: https://github.com/justinmk/config/blob/master/.vimrc#L356-L410

@dbarnett
Contributor
dbarnett commented Oct 9, 2015

@justinmk Not quite a subset. mouse=a isn't in sensible.vim, and I think there's also something about the status line appearance that's different.

@fmoralesc
Contributor

@dbarnett The new defaults were polled from sensible.vim and directly from users, so it's true they are not a subset of sensible.vim; instead, they overlap.

@Grimy
Contributor
Grimy commented Oct 26, 2015

Was something decided regarding Y yanks to the end of the line? I think it would be a good idea to have this on by default.

@justinmk
Member

@Grimy It's not an overwhelming win (something like 60/40 for/against) so it's a non-starter.

@Grimy
Contributor
Grimy commented Oct 27, 2015

Oh, okay. I was confused by the original post, which is apparently out-of-date (Y is not marked as REJECTED).

@asthasr
asthasr commented Oct 28, 2015

mouse=a is terrible.

@justinmk
Member

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

@asthasr
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
Member

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

@fmoralesc
Contributor

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
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
Contributor

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

@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
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
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
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 justinmk referenced this issue in tpope/vim-sensible Mar 21, 2016
@tpope tpope Revert "Set lazyredraw"
This reverts commit 2fb074e.
9e91be7
@passy passy added a commit to passy/dotvim that referenced this issue Mar 21, 2016
@passy passy Remove sensible
I think with
neovim/neovim#2676
this shouldn't be necessary.
b9e8eac
@meribold meribold added a commit to meribold/dotfiles that referenced this issue Apr 14, 2016
@meribold meribold 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
fedd0a7
@korovamilk korovamilk added a commit to korovamilk/vim-custom that referenced this issue Oct 19, 2016
@korovamilk korovamilk some suggestions taken from https://github.com/tpope/vim-sensible and n… 32cf44b
@justinmk justinmk referenced this issue in adibis/nvim Oct 28, 2016
Closed

sensible.vim #4

@justinmk justinmk modified the milestone: 0.3, 0.2 Dec 11, 2016
@stsewd stsewd added a commit to stsewd/dotfiles that referenced this issue Dec 27, 2016
@stsewd stsewd Remove already default configurations. 0aa2342
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment