defaults, part 3

[gpanders]

previous: #6289

Feature description

A few more proposals for defaults:

• 'shada' oldfiles exclude defaults: skip common junk in 'shada' oldfiles #21637
• change eob fillchar to middle-dot instead of tilde "~" defaults: change eob (end-of-buffer) from tilde "~" to "middle dot" #21694
• nnoremap & <Cmd>&&<CR>
  • Rationale: The & key repeats the last :s command, but does not re-use the flags of the last command. Meaning if you last ran :s/foo/bar/g to replace all instances of foo in a line with bar, then move your cursor to a different line and press &, it will still only replace the first instance of foo with bar. The :&& ex command does re-use the flags, but is relatively more cumbersome (four key presses rather than one). The latter is much more useful and a more common operation. To regain the original behavior, users can still use the :& ex command.
  • Status: Done feat(defaults): nnoremap & :&&<CR> #19365
• 🚫 Swap p and P in visual mode (xnoremap p P | xnoremap P p)
  • Rationale: The fact that "pasting" in visual mode clobbers the yanked contents is a common footgun in Vim. The P key was added to avoid this: it preserves the contents of the unnamed register so that you can use P repeatedly to "paste" the same contents. This behavior is more intuitive and commonplace in other editing environments, so let's make it the default for p. If a user wants the original behavior, they can use P (or unmap the defaults).
  • Status: There are a number of good arguments against this; see here and here.
• Map gs to :sort
  • Rationale: The default gs mapping is so utterly useless it almost seems like a joke. Instead, make gs an operator in normal mode that sorts the given range (in visual mode, make it sort the selection). I currently use this:

  function! Sort(...) abort
    '[,']sort
    call setpos('.', getpos("''"))
  endfunction
  nnoremap gs m'<Cmd>set operatorfunc=Sort<CR>g@
  xnoremap gs :sort<CR>

  • Status: Make gs some kind of "substitute" operator for consistency with the default s mapping. Example: xnoremap gs mr:s/\%V (and an equivalent operator in normal mode)
• 'title' and 'titlestring' ? implement default titlestring using statusline #1248
• shortmess+=C defaults: shortmess+=C #23907
• smoothscroll defaults: smoothscroll #23939
• termguicolors feat(defaults): enable 'termguicolors' by default when supported by terminal #26407

[justinmk]

nnoremap & <Cmd>&&<CR>

👍
ref: tpope/vim-sensible@e48a405

Swap p and P in visual mode (xnoremap p P | xnoremap P p)

idk about this, feels like entropy. P is, thankfully, available by default now and pretty easy to use. Swapping p/P could feel like randomization, hard to remember.

Map gs to :sort ... The default gs mapping is so utterly useless

Mapping gs to some sort of useful operator is a good idea. But not sure about "sort", I find that {visual}:sort works well when I need it. What about a "subsitute" mapping? Currently I have xnoremap gs mr:s/\%V in my config, have wanted to make a normal-mode operator too, idk if this is useful enough though.

[lewis6991]

Swap p and P in visual mode (xnoremap p P | xnoremap P p)

I'm in favour of this. I always forget P even exists and end up using p which disrupts my workflow. I would bet a majority of users are the same.

Mapping gs to some sort of useful operator is a good idea. But not sure about "sort", I find that {visual}:sort works well when I need it. What about a "subsitute" mapping? Currently I have xnoremap gs mr:s/%V in my config, have wanted to make a normal-mode operator too, idk if this is useful enough though.
@justinmk

Mapping to 'substitute' makes much more sense given how s and S are already substitute mappings. I currently have nnoremap <leader>s :%s/\<<C-R><C-W>\>\C//g<left><left> for substituting the word under the cursor (which I use all the time), but something more general would be preferable.

Another option would be to just unmap it entirely, as I bet more people hit this by accident than on purpose.

[gpanders]

I'm quite fond of my sort mapping (I use gsip to sort #includes in C files all the time), but as long as we can agree on something, I'd be happy. The substitute mapping could be made an operator too, of course.

Re: the p/P swap, I think the biggest argument against it is that for better or worse p has been around in Vim for so long that a lot of people have just gotten used to it, and changing it now might be disruptive. I'm still in favor of changing it though, because I think P as the default behavior is much more sane. In ~10 years of using Vim as my primary editor, I don't think I have ever intentionally used the fact that p replaces the unnamed register. It's always been something I've lived with or worked around. Granted I'm a sample size of one, but I wouldn't be surprised if many others feel the same.

[justinmk]

In ~10 years of using Vim as my primary editor, I don't think I have ever intentionally used the fact that p replaces the unnamed register

It's commonly used as a poor man's "swap". I use it when stuck on a machine without my config. The behavior of P is definitely a better default, but P is quite easy to use, so the churn of swapping p/P is hard to justify. But we could try it, maybe I'm wrong...

[andrewferrier]

I'm quite fond of my sort mapping (I use gsip to sort #includes in C files all the time), but as long as we can agree on something, I'd be happy. The substitute mapping could be made an operator too, of course.

For a contrasting perspective, I think quite a lot of folks use gs already as some kind of sort operator. For example, I've had vim-sort-motion in my init.lua (and before that, ~/.vimrc), as I sort all the time, and it uses gs by default. That plugin is popular, although not quite as popular as it used to be (it's very much Vim-era). It would wonderful to have a built-in way to do this, and kill the plugin, for simple sorting usecases.

[justinmk]

What's all this sorting for? Doesn't {visual}:sort<cr> get you 98% of the way there? Are you dot-repeating these sort operations?? Organizing imports is more of an LSP or treesitter task, which implies the value of a sort operation has limited shelf-life as those mature.

It sounds more like we want a g: operator that allows any : command to be invoked as a dot-repeatable operation. Then one could do g:{motion}sort<cr>.

[lewis6991]

Most g mappings are alternatives to the non-g mappings, or, as some form of goto mapping. E.g:

• j/k and gj/gk
• */# and g*/g#
• ^/$ and g^/g$
• n/N and gn/gN
• e/E and ge/gE
• i/I and gi/gI
• p/P and gp/gP
• ~ and g~
• r and gr
• R and gR
• J and gJ
• % and g%
• gd/gD: goto declaration
• gg: goto line
• gf/gF: goto file
• g'/g` : goto mark
• g,/g;: goto newer/older posiiton in change list
• gt/gT: goto tab

Current exceptions to this rule:

• gu/gU
• g?
• gq
• g@
• ga (this should be another candidate for changing)
• gO
• gQ (I hate this one)
• gh/gH
• gV
• gv (though this relates to visual selection)

I think if we want to map gs to anything, it should relate to s in some way, otherwise it would be best to unmap it and let user continue to map it to what they want.

[clason]

Also exception: gq -- which would be a precedent for gs as proposed here.

[andrewferrier]

What's all this sorting for? Doesn't {visual}:sort<cr> get you 98% of the way there? Are you dot-repeating these sort operations??

In many cases, yes :) Besides, gsip is a bit nimbler than vip:sort<CR>. Visual mode is always a second-class citizen to a well-defined operator IMHO.

It sounds more like we want a g: operator that allows any : command to be invoked as a dot-repeatable operation. Then one could do g:{motion}sort<cr>.

That would definitely be really interesting (EDIT: Actually, super-cool, now I think about it!)

Saving the trouble of typing out "sort" is rather low-value for such a nice mapping as gs. Organizing imports is more of an LSP or treesitter task, which implies the value of a sort operation has near-term shelf-life as those mature.

Perhaps. That's very far from the only reason for sorting lists (for example, for many non-programming usecases I like to sort lists in Markdown), but point taken.

I don't have a super-strong opinion about this. After all, these are only defaults, and I can always remap myself. Just giving you a view from someone who's been using Vim a while and has his fingers hardcoded to gs meaning sort ;)

[andrewferrier]

Also exception: gq -- which would be a precedent for gs as proposed here.

Also, ga, and gf, and gF, and gt ;)

[yamatsum]

How about making the following settings the defaults?

vim.o.ignorecase = true
vim.o.smartcase = true

It seems that kickstart.nvim and many others are also set, and other editors seem to be able to search case-insensitively by default.
Are there any disadvantages to setting?

[justinmk]

'ignorecase' discussed in tpope/vim-sensible#132 . Doesn't seem like a clear win, will need a lot of discussion.

I just noticed that 'title' and 'titlestring' are not set by default, maybe it's time to set those #1248

[zeertzjq]

If one wants to use replace whole lines with same lines multiple times, they'll use V to select the lines to replace, and in this case P is better.

[andmis]

I didn't know about this way of using p in Visual mode, and actually it solves a long-standing problem for me, namely having a poor-man's swap, as @justinmk put it. So I am excited about using p this way (as it works by default).

I just tried the Vim emulation plugins in VS Code and the JetBrains suite, and they both implement Visual-mode p "correctly", as in, they match the current Vim/Neovim behavior. (Interestingly, as long as we're talking about consistency, VSCodeVim uses the equivalent of :nnoremap Y y$ and IdeaVim does not.) I think consistency in the text-editing DSL layer is a big strength of the Vim ecosystem, so my humble vote is to leave p and P alone in Visual mode.

[ad-chaos]

nnoremap & &&
Rationale: The & key repeats the last :s command, but does not re-use the flags of the last command. Meaning if you last ran :s/foo/bar/g to replace all instances of foo in a line with bar, then move your cursor to a different line and press &, it will still only replace the first instance of foo with bar. The :&& ex command does re-use the flags, but is relatively more cumbersome (four key presses rather than one). The latter is much more useful and a more common operation. To regain the original behavior, users can still use the :& ex command.

I wonder if it would make sense to have gdefault instead of that, because almost all the time I am using /g

[justinmk]

would make sense to have gdefault instead of that, because almost all the time I am using /g

gdefault was rejected previously:

• breaks plugins: Add option for magic mode by default? #6158 (comment)
• breaks plugins: :Man has display problems if gdefault is set #5181
• rationale: substitute all matches in a line instead of just the first tpope/vim-sensible#39

  This makes it so if you do use a /g, you don't get all matches. Gross, and screws with anyone with muscle memory for the proper way.

[ad-chaos]

For what its worth, :Man looks perfectlly normal to me with :set gdefault on HEAD with nvim --clean and the rationale is muscle memory which is fair, but to me /g is two characters too many :) and I am fairly certain new users would love to have gdefault since the cases where you substitute without /g are too few and far in between.

I am not sure if it actually breaks plugins, None of my plugins are broken, here's a list of them

Plugins

• wbthomason/packer.nvim
• nvim-lua/popup.nvim
• Mofiqul/dracula.nvim
• folke/tokyonight.nvim
• hrsh7th/nvim-cmp
• hrsh7th/cmp-buffer
• hrsh7th/cmp-path
• hrsh7th/cmp-cmdline
• hrsh7th/cmp-nvim-lsp
• L3MON4D3/LuaSnip
• saadparwaiz1/cmp_luasnip
• nvim-telescope/telescope.nvim
• nvim-telescope/telescope-fzf-native.nvim
• lewis6991/gitsigns.nvim
• neovim/nvim-lspconfig
• nvim-treesitter/nvim-treesitter
• chrisbra/Colorizer
• godlygeek/tabular
• terrortylor/nvim-comment
• lewis6991/spellsitter.nvim
• sbdchd/neoformat
• kylechui/nvim-surround
• nvim-treesitter/playground

And this is excluding the matchit and netrw which also work perfectly with gdefault

[clason]

I see no tpope plugins in this list, which makes it of limited relevance to this question...

[ad-chaos]

fair, but the statement was it breaks plugins not it breaks *tim pope* plugins.

[clason]

Sorry, but for "it breaks plugins" to hold true, it suffices to break some plugins. And for various reasons, tpope plugins are of prime concern here -- both as the ones most likely to break, and the ones we most care about in this regard.

[ad-chaos]

I agree, if that's the case then maybe I am wrong and set gdefault is a bad idea to be set by default 👍

[ggandor]

enabling ignorecase and smartcase violates the principle of least surprise

#21342 (comment)

[echasnovski]

Sorry for out of nowhere comment, as I had a thought which seems worth sharing.

The gs mapping seems like an ideal prefix candidate for a possible surround operator (if it is decided to be worth adding to core). Like gsa - add surrounding, gsd - delete surrounding, gsr - replace surrounding.

(Very side note. If using only Lua code for surrounding implementation will be considered enough, I am happy to collaborate, as I have relevant experience)

[justinmk]

why wouldn't vim-surround's ys, ds be used for surround? moot point though, we aren't going to add a default surround plugin.

[echasnovski]

why wouldn't vim-surround's ys, ds be used for surround?

Some people (quite reasonably) prefer the "prefix style" as it is more descriptive (as ys is not a "yank surrounding" but "add surrounding"). So I thought I'd share my thought.

moot point though, we aren't going to add a default surround plugin.

Sure, understood. Sorry for the noise.

[mortezadadgar]

can we have a saner default for diffopt as well? there are some nice options to improve the diff output but most of users are not aware of them, my proposal:

vim.opt.diffopt:append {
	"indent-heuristic",
	"algorithm:patience",
}