Changing the defaults with Vim 8

[Bram Moolenaar]

Vim has always been conservative about the default option values.
Without any .vimrc the default is 'compatible'. That's nice for people
who rely on the old Vi. But how many of these still exist? I expect
nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.

What has stopped me from changing this is the unexpected change. Many
users will notice that Vim suddenly behaves differently. Some may be
upset. The release of Vim 8.0 might be the best point in time to do
this. If we do this.

Besides making 'nocompatible' the default, there are a few options that
should probably be on by default. Currently these are in
$VIMRUNTIME/vimrc_example.vim. Most of these only have a visual effect
or slightly change how editing works. You will notice this right away.
The ones that have unexpected effects should be avoided.

If someone wants to start in the old way, the -C flag should be used:
vim -C

If someone wants to start with 'nocompatible', but not all of the new
option values, a .vimrc would be needed to change the settings. This is
the most common and also most tricky part. Assuming that the user will
want most of the new option values, but not all, he should be able to
revert to the old value. For options that is easy. But including the
matchit plugin is not easy to revert.

What we can probably always do:

set backspace=indent,eol,start
set history=50 " keep 50 lines of command line history
set ruler " show the cursor position all the time
set showcmd " display incomplete commands
set incsearch " do incremental searching

" Don't use Ex mode, use Q for formatting
map Q gq

" In many terminal emulators the mouse works just fine, thus enable it.
if has('mouse')
set mouse=a
endif
if &t_Co > 2 || has("gui_running")
syntax on
set hlsearch
let c_comment_strings=1
endif

if has("autocmd")
" Enable file type detection.
filetype plugin indent on

augroup vimrcEx
au!

" For all text files set 'textwidth' to 78 characters.
autocmd FileType text setlocal textwidth=78

" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event handler
" (happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line("'\"") >= 1 && line("'\"") <= line("$") |
\ exe "normal! g`\"" |
\ endif

augroup END
else
set autoindent " always set autoindenting on
endif

if has('langmap') && exists('+langnoremap')
set langnoremap
endif


Probably not:

" these two leave files behind
set backup
set undofile

" may conflict with a user mapping
inoremap <C-U> <C-G>u<C-U>

" hard to revert
if has('syntax') && has('eval')
packadd matchit
endif

Comments?

--
TALL KNIGHT: When you have found the shrubbery, then you must cut down the
mightiest tree in the forest ... with a herring.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

> set backspace=indent,eol,start

+1

> set history=50 " keep 50 lines of command line history

Why only 50?

And while we are it, increase the undolevels setting

> set ruler " show the cursor position all the time
> set showcmd " display incomplete commands
> set incsearch " do incremental searching
> " Don't use Ex mode, use Q for formatting
> map Q gq
>
> " In many terminal emulators the mouse works just fine, thus enable it.
> if has('mouse')
> set mouse=a
> endif

don't care.

> if &t_Co > 2 || has("gui_running")
> syntax on
> set hlsearch

please no hlsearch. That is most often annoying.

> if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on

+1

>
> augroup vimrcEx
> au!
>
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78

Isn't text a fallback, that is used, when no other type is found? I
wouldn't set this one then.

> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
> \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> \ exe "normal! g`\"" |
> \ endif

+1

> Probably not:
>
> " these two leave files behind
> set backup
> set undofile
>
> " may conflict with a user mapping
> inoremap <C-U> <C-G>u<C-U>
>
> " hard to revert
> if has('syntax') && has('eval')
> packadd matchit
> endif

+1 for not setting those. although I would still make <c-u> in insert
mode undoable.

some more I would set, the mentioned
:set display+=lastline
:set nrformat-=octal (often does unexpected things, when the user does
not expect it)

and possibly also:
:set laststatus=2

Best,
Christian
--
Charade

Das Erste, das ist immer,
Und wenn auch die Welt vergeht;
Das Zweite ist man und bleibt man,
Wenn man zu lesen versteht.

-- Heinrich Heine

[Tim Chase]

On 2016-07-24 15:02, Bram Moolenaar wrote:
> What has stopped me from changing this is the unexpected change.
> Many users will notice that Vim suddenly behaves differently. Some
> may be upset. The release of Vim 8.0 might be the best point in
> time to do this. If we do this.

Agreed that 8.0 is a good break-a-little-compatibility-if-needed
moment compared to a point release.

Though my understanding is that vim behaves differently if invoked as
"vi" vs. "vim"/"gvim" and if there's a .vimrc vs no .vimrc

So if invoked as "vi" and there's no .vimrc, I'd expect 'compatible'
behavior with no/minimal breaking changes. However if there's
indication that the user wants vim-not-vi (either invoking as "vim"
or having a .vimrc/.gvimrc), then I'd be more open to more
invasive/incompatible changes.

> If someone wants to start in the old way, the -C flag should be
> used: vim -C

I'd also include "or invoking as `vi` or having no .vimrc"

> What we can probably always do:
>
> set backspace=indent,eol,start

+1 here

> set history=50 " keep 50 lines of command line history

at *least* 50 but otherwise +1

> set ruler " show the cursor position all the time

I'm slightly concerned about things that eat more screen real-estate
unbidden. Not *greatly* concerned, but at least enough to raise the
issue. +0

> set showcmd " display incomplete commands

+1

> set incsearch " do incremental searching

My only concern here is that some regexps can have pathological
search time, and searching unbidden (either by hitting enter or by
using 'incsearch') can hang vim.

> " Don't use Ex mode, use Q for formatting
> map Q gq

I don't object in vim; only mildly concerned regarding vi (would have
to dredge up a POSIX vi to check whether Q was used). But mostly Q
is an annoyance to just about everybody I've talked to, good only for
VimGolf hacks.

> " In many terminal emulators the mouse works just fine, thus
> enable it. if has('mouse')
> set mouse=a
> endif

I don't have much input here as I don't use the mouse with vim (other
than middle-button pasting content as if I typed it)

> if &t_Co > 2 || has("gui_running")
> syntax on

It may ruffle some feathers, but again, if it's vim-not-vi, I think
most users already do something like this; and that those who don't
prefer to invoke it as vi.

> set hlsearch

The 'hlsearch' annoys me and is the sort of thing I only turn on as
needed and then promptly turn back off again. Pretty -1 on this one.

> if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on

Might get some detractors, but I don't object here.

> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78

I'd find this more annoying. I tend to jockey 'tw' based on my
environment/content. Email gets tw=65, my HTML is usually tw=75, my
prose is often tw=0, etc.

> autocmd BufReadPost *
> \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> \ exe "normal! g`\"" |
> \ endif

How would this interact with command-line offsets if the file had
been previously edited?

$ vim +21 file.txt

I'd also want to ensure it doesn't impact scripts/macros that assume
files start at the same place. Currently, I can do things like

$ vim *.html
:argdo /<h\d\>\c/put='below first HTML heading'

and know where things will go. But if the cursor location is
restored when a buffer is opened, that might drop me in an unexpected
location.

So I'd vote as a -0 on that one.


As a backwards incompatible change, my biggest want would be that the
outer-quotation text objects (a" and a') would no longer eat leading
whitespace. I've never wanted the out-of-box behavior, always
wanting to change just the string-cum-quotes.

http://vim.1045645.n5.nabble.com/quotation-text-object-consternation-td5725045.html

Or at least an option to control that.

-tim

[Bram Moolenaar]

Christian Brabandt wrote:

> > set backspace=indent,eol,start
>
> +1
>
> > set history=50 " keep 50 lines of command line history
>
> Why only 50?

Good point, the Vim default already is 50. That changed a while back.
How about 200?

> And while we are it, increase the undolevels setting

The default already is 1000. A higher value is mainly useful in
combination with 'undofile', but we don't want to set that.

> > set ruler " show the cursor position all the time
> > set showcmd " display incomplete commands
> > set incsearch " do incremental searching
> > " Don't use Ex mode, use Q for formatting
> > map Q gq
> >
> > " In many terminal emulators the mouse works just fine, thus enable it.
> > if has('mouse')
> > set mouse=a
> > endif
>
> don't care.
>
> > if &t_Co > 2 || has("gui_running")
> > syntax on
> > set hlsearch
>
> please no hlsearch. That is most often annoying.

Well, I find it useful. But I suppose that's more a personal
preference.

> > if has("autocmd")
> > " Enable file type detection.
> > filetype plugin indent on
>
> +1
>
> >
> > augroup vimrcEx
> > au!
> >
> > " For all text files set 'textwidth' to 78 characters.
> > autocmd FileType text setlocal textwidth=78
>
> Isn't text a fallback, that is used, when no other type is found? I
> wouldn't set this one then.

No, but it can trigger quite often. I suppose this is too arbitrary.

>
> > " When editing a file, always jump to the last known cursor position.
> > " Don't do it when the position is invalid or when inside an event handler
> > " (happens when dropping a file on gvim).
> > autocmd BufReadPost *
> > \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> > \ exe "normal! g`\"" |
> > \ endif
>
> +1
>
> > Probably not:
> >
> > " these two leave files behind
> > set backup
> > set undofile
> >
> > " may conflict with a user mapping
> > inoremap <C-U> <C-G>u<C-U>
> >
> > " hard to revert
> > if has('syntax') && has('eval')
> > packadd matchit
> > endif
>
> +1 for not setting those. although I would still make <c-u> in insert
> mode undoable.

OK.

> some more I would set, the mentioned
> :set display+=lastline

As mentioned, I don't use it myself, I expect long time Vi/Vim users to
be surprised if this changes.

> :set nrformat-=octal (often does unexpected things, when the user does
> not expect it)

OK.

> and possibly also:
> :set laststatus=2

That takes an extra line from the screen. I suppose it's useful if you
have a plugin for a super status line.

--
The Law of VIM:
For each member b of the possible behaviour space B of program P, there exists
a finite time t before which at least one user u in the total user space U of
program P will request b becomes a member of the allowed behaviour space B'
(B' <= B).
In other words: Sooner or later everyone wants everything as an option.
-- Vince Negri

[Bram Moolenaar]

Tim Chase wrote:

> On 2016-07-24 15:02, Bram Moolenaar wrote:
> > What has stopped me from changing this is the unexpected change.
> > Many users will notice that Vim suddenly behaves differently. Some
> > may be upset. The release of Vim 8.0 might be the best point in
> > time to do this. If we do this.
>
> Agreed that 8.0 is a good break-a-little-compatibility-if-needed
> moment compared to a point release.
>
> Though my understanding is that vim behaves differently if invoked as
> "vi" vs. "vim"/"gvim" and if there's a .vimrc vs no .vimrc
>
> So if invoked as "vi" and there's no .vimrc, I'd expect 'compatible'
> behavior with no/minimal breaking changes. However if there's
> indication that the user wants vim-not-vi (either invoking as "vim"
> or having a .vimrc/.gvimrc), then I'd be more open to more
> invasive/incompatible changes.
>
> > If someone wants to start in the old way, the -C flag should be
> > used: vim -C
>
> I'd also include "or invoking as `vi` or having no .vimrc"

There was a discussion about this long ago. The main reason not to do
this is that many users rename vim to vi. Most Linux systems already
call it vi. There might not even be a vim binary.

> > What we can probably always do:
> >
> > set backspace=indent,eol,start
>
> +1 here
>
> > set history=50 " keep 50 lines of command line history
>
> at *least* 50 but otherwise +1
>
> > set ruler " show the cursor position all the time
>
> I'm slightly concerned about things that eat more screen real-estate
> unbidden. Not *greatly* concerned, but at least enough to raise the
> issue. +0
>
> > set showcmd " display incomplete commands
>
> +1
>
> > set incsearch " do incremental searching
>
> My only concern here is that some regexps can have pathological
> search time, and searching unbidden (either by hitting enter or by
> using 'incsearch') can hang vim.

There is a timeout, but only with the +reltime feature. We can have it
depend on that.

> > " Don't use Ex mode, use Q for formatting
> > map Q gq
>
> I don't object in vim; only mildly concerned regarding vi (would have
> to dredge up a POSIX vi to check whether Q was used). But mostly Q
> is an annoyance to just about everybody I've talked to, good only for
> VimGolf hacks.
>
> > " In many terminal emulators the mouse works just fine, thus
> > enable it. if has('mouse')
> > set mouse=a
> > endif
>
> I don't have much input here as I don't use the mouse with vim (other
> than middle-button pasting content as if I typed it)
>
> > if &t_Co > 2 || has("gui_running")
> > syntax on
>
> It may ruffle some feathers, but again, if it's vim-not-vi, I think
> most users already do something like this; and that those who don't
> prefer to invoke it as vi.
>
> > set hlsearch
>
> The 'hlsearch' annoys me and is the sort of thing I only turn on as
> needed and then promptly turn back off again. Pretty -1 on this one.

OK.

> > if has("autocmd")
> > " Enable file type detection.
> > filetype plugin indent on
>
> Might get some detractors, but I don't object here.
>
> > " For all text files set 'textwidth' to 78 characters.
> > autocmd FileType text setlocal textwidth=78
>
> I'd find this more annoying. I tend to jockey 'tw' based on my
> environment/content. Email gets tw=65, my HTML is usually tw=75, my
> prose is often tw=0, etc.

Not this then.

> > autocmd BufReadPost *
> > \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> > \ exe "normal! g`\"" |
> > \ endif
>
> How would this interact with command-line offsets if the file had
> been previously edited?
>
> $ vim +21 file.txt

That works.

> I'd also want to ensure it doesn't impact scripts/macros that assume
> files start at the same place. Currently, I can do things like
>
> $ vim *.html
> :argdo /<h\d\>\c/put='below first HTML heading'
>
> and know where things will go. But if the cursor location is
> restored when a buffer is opened, that might drop me in an unexpected
> location.
>
> So I'd vote as a -0 on that one.

I find it very, very useful to come back where I was in a file the last
time. I never encounter negative effects.

> As a backwards incompatible change, my biggest want would be that the
> outer-quotation text objects (a" and a') would no longer eat leading
> whitespace. I've never wanted the out-of-box behavior, always
> wanting to change just the string-cum-quotes.
>
> http://vim.1045645.n5.nabble.com/quotation-text-object-consternation-td5725045.html
>
> Or at least an option to control that.

First time I hear about this.

--
In Africa some of the native tribes have a custom of beating the ground
with clubs and uttering spine chilling cries. Anthropologists call
this a form of primitive self-expression. In America we call it golf.

[h_east]

Hi Tim and Bram,

I react only to the last sentence.

2016-7-25(Mon) 4:43:30 UTC+9 Bram Moolenaar:

Please refer to the last two lines of `:help iquote`.
DOC> i" v_iquote iquote
DOC> i' v_i' i'
DOC> i` v_i` i`
DOC> Like a", a' and a`, but exclude the quotes and
DOC> repeating won't extend the Visual selection.
DOC> Special case: With a count of 2 the quotes are
DOC> included, but no extra white space as with a"/a'/a`.

In the current situation, it can be avoided in the following way.

c2i"

--
Best regards,
Hirohito Higashi (a.k.a. h_east)

[Tony Mechelynck]

Hi Bram,

For about as long as I've been using Vim, I've had a .vimrc with a
"runtime vimrc_example.vim" line in it and a few (and then more than
only a few) lines added to it to tweak it to my liking. For instance a
number of additional mappings.

To revert part of the "filetype plugin indent on" in the
vimrc_example.vim I add "filetype indent off" after sourcing it, thus
keeping filetype and syntax detection but not autoindent. I recently
noticed, to my happy surprise, that matchit was now included by
default by the vimrc_example.vim so the lines I had (a symlink in
~/.vim/doc and a plugin with only a runtime line in ~/.vim/plugin)
have now become obsolete.

I'm appending a copy of my vimrc and of my "almost-default"
colorscheme — most of them is not meant as a new standard but as an
example of how one particular user may want to customise his own Vim:
it works for me, it might or might not work for you. Other plugins I
got from the "vim scripts" site, among which CSApprox and CloseTag
(and others which I use less often), I'm not detailing them here. Nor
am I detailing all the scripts (often one-liner ftplugins, but also
keymaps etc.) which I have in subdirectories of ~/.vim/ and
$VIM/vimfiles/

Best regards, and… Have fun!
Tony.

[Gary Johnson]

On 2016-07-24, Bram Moolenaar wrote:
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'. That's nice for people
> who rely on the old Vi. But how many of these still exist? I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change. Many
> users will notice that Vim suddenly behaves differently. Some may be
> upset. The release of Vim 8.0 might be the best point in time to do
> this. If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default. Currently these are in
> $VIMRUNTIME/vimrc_example.vim. Most of these only have a visual effect
> or slightly change how editing works. You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings. This is
> the most common and also most tricky part. Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy. But including the
> matchit plugin is not easy to revert.
>
> What we can probably always do:

[...]

> Comments?

I think that for all the reasons you have given over the years,
changing the default behavior or default option values is a bad
idea.

I'm not sure what problem you're trying to solve.

Experienced users of Vim have already tweaked their vimrc files with
their preferred settings. Changing the defaults is not going to
help them.

The Windows installer already creates a default system _vimrc in
$VIM which is used until a user creates their own ~/_vimrc. The
system _vimrc could be changed to use whatever options values you
think would be better. New users will get the new option values.
Existing users will keep their existing option values.

Linux users usually start with the Vim package for their
distribution. Fedora-derived distributions and Ubuntu-derived
distributions at least provide system vimrc files with the option
values those package maintainers think are best. So those users
already get "better" initial option values.

Many Linux users build their own Vim. These users are usually
experienced enough to have a vimrc that sets their preferred option
values. For those users that are not so experienced, you could
change "make install" to look for ~/.vim/vimrc, and if it doesn't
already exist, create one that has your idea of better initial
settings.

I understand that Vim could be made more useful and appealing to new
users with different default settings, but putting those settings in
a configuration file (such as $VIM/_vimrc on Windows or $VIM/vimrc
on Unix if not already present) could solve that problem without
changing the actual default settings or breaking existing users'
expectations or configurations.

Regards,
Gary

[romainla...@gmail.com]

Ideally, starting the program as 'vim' would automatically give the user the improvements promised in the name. And 'vi' would hide all those improvements.

Here is my list of options to set when run as 'vim':

set nocompatible

Just because.

set autoindent

It's smart enough to cover most basic needs.

set backspace=indent,eol,start

Because the default behavior weirds out new users.

set hidden

Because 'nohidden' is too inflexible and 'hidden' would prevent new users from using tab pages as file proxies.

set ruler

Minimal information.

set wildmenu

Makes command-line completion incredibly useful.

syntax on

Syntax highlighting has been an expectation for a long time.

I'm partial to 'filetype plugin indent on' too but it *may* do a bit too much for some users. 'filetype on' (automatic with 'syntax on' is a good start, though.

Some common issues:

- Indentation settings are too complex. Autodetection should be a built-in feature.
- When switching buffers/windows, the cursor position should be more predictable by default, adding vimscript to one's 'vimrc' shouldn't be needed for that.
- '$MYRUNTIME' would be a very useful addition.

[Erik Christiansen]

On 24.07.16 15:02, Bram Moolenaar wrote:
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings. This is
> the most common and also most tricky part. Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy. But including the
> matchit plugin is not easy to revert.

That "not easy to revert" initially sounds decidedly scary to one who
has never heard of matchit. ... Ah, it merely adds matching HTML tags to
the sensibilities of %, apparently? (Had to read ":h matchit" several
times to distil that nub. I.e. it doesn't "makes the "%" command jump",
but rather _adds_ targets to the preexisting functionalityi, AIUI.)

What about putting new defaults into a default .vimrc, installed as part
of the Vim package, iff no .vimrc preexists at install time? Then any
hirsute gremlins with bad breath ought not be irrevertible, I figure.

> What we can probably always do:
>
> set backspace=indent,eol,start
> set history=50 " keep 50 lines of command line history
> set ruler " show the cursor position all the time
> set showcmd " display incomplete commands
> set incsearch " do incremental searching

Wouldn't change anything here, except the last one, and that's easily
negated with a .vimrc setting.

> " Don't use Ex mode, use Q for formatting
> map Q gq

The additional formatting mapping would do no harm.
(The only related thing used here is: noremap ^W gq}
but that'd doubtless not suit many others at all, if any.)

> " In many terminal emulators the mouse works just fine, thus enable it.
> if has('mouse')
> set mouse=a
> endif

Copying/pasting to/from terminal windows with Vim has worked fine for
many years without that, i.e. "mouse=". The only doubt I have is that
"mouse=a" might enable associated defaults, leading to the need to
fiddle them or restore "mouse=", neither of which is a biggie.

> if &t_Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
> endif

Well, that horror is quickly fixed with a "syntax off", so it's not a
problem. (But the negative vote on this one seems to be climbing.)

> if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on

The "indent" could perhaps be an unwelcome surprise? Didn't know about
"filetype indent" until now. Haven't yet found any mention of
pre-existing indent files, or link thereto, at *:filetype-indent-on*.
Will also have to do some digging for indent file syntax, examples, etc.

> augroup vimrcEx
> au!
>
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
>
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
> \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> \ exe "normal! g`\"" |
> \ endif
>
> augroup END
> else
> set autoindent " always set autoindenting on
> endif

Having a bunch of my own autocommands for textwidth, the above stuff
would only be welcome if included in a default .vimrc which would not
displace or interact with the user's, if extant. During a multi-file
edit, :bu already brings me back to the previous line, and complains if
it's gone, so I don't understand what the above line restoration stuff
adds? (If it adds persistence, then that'd be horrible.)

> if has('langmap') && exists('+langnoremap')
> set langnoremap
> endif

Seems good - though I haven't used langmap, as a switch to Danish needs
extra characters, not substitutions, so I use mappings for åæø.
For the very occasional bit of German, äöüß, I merely resort to ^k.

>
> Probably not:
>
> " these two leave files behind
> set backup
> set undofile

I've never used them, and would object to the clutter.

> " may conflict with a user mapping
> inoremap <C-U> <C-G>u<C-U>

Good guess. :-) I have:

" ^U Uppercase current word, _in_insert_mode!:
inoremap <C-U> <Esc>gUiw`]a

There's some chance of remembering that; ^F, no chance.

> " hard to revert
> if has('syntax') && has('eval')
> packadd matchit
> endif

"hard to revert" == "impermissible default", _if_ it could be a problem.
But if % bounces between HTML tags, and that isn't desired, then don't
press %, or get off the HTML tag, I figure.

I second Christian's nrformats suggestion, as far as excluding octal by
default, but would go further with nrformats=hex,alpha as a default.
Having those in addition to the implicit decimal default is useful, and
I can't quite see where it could be harmful.

Many thanks for the world's best editor, which exceeds my needs to the
point I've had to become choosy about features I'll stop to learn.
(Wouldn't give up the several kinds of folding for anything, though.)

Erik

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 11:00 AM, <romainla...@gmail.com> wrote:
> Ideally, starting the program as 'vim' would automatically give the user the improvements promised in the name. And 'vi' would hide all those improvements.
>
> Here is my list of options to set when run as 'vim':

[...]

> set hidden
>
> Because 'nohidden' is too inflexible and 'hidden' would prevent new users from using tab pages as file proxies.

[...]

I disagree.
When I :quit a file, or otherwise |abandon| it, I want it to be quit,
not to remain there in-memory-but-not-saved. I use 'autowriteall' to
save it _to disk_ if possible, but I don't pretend that everyone will
want that setting. And if I want my changes to be lost (which happens,
but rarely) I explicitly use :q! instead of :q when quitting the file.

If _you_ want to use 'hidden', then set it in your vimrc, but don't
force every people who don't want it to explicitly ":set nohidden" in
_their_ vimrc. When I first became a serious Vim user, I went through
all the options and added vimrc lines for those where I wanted a
nondefault value (or to be precise, a different value than what the
vimrc_example.vim sets, since it sets most, but not all, of my
preferred settings and I source it in my vimrc); I definitely did not
add :set lines for _all_ of those whose defaults where the values I
preferred; reading your post makes me thing maybe I should have after
all.


Best regards,
Tony.

[Ben Fritz]

On Monday, July 25, 2016 at 8:02:21 AM UTC-5, Tony Mechelynck wrote:
> On Mon, Jul 25, 2016 at 11:00 AM, <romainla...@gmail.com> wrote:
> > Ideally, starting the program as 'vim' would automatically give the user the improvements promised in the name. And 'vi' would hide all those improvements.
> >
> > Here is my list of options to set when run as 'vim':
> [...]
> > set hidden
> >
> > Because 'nohidden' is too inflexible and 'hidden' would prevent new users from using tab pages as file proxies.
> [...]
>
> I disagree.
> When I :quit a file, or otherwise |abandon| it, I want it to be quit,
> not to remain there in-memory-but-not-saved. I use 'autowriteall' to
> save it _to disk_ if possible, but I don't pretend that everyone will
> want that setting. And if I want my changes to be lost (which happens,
> but rarely) I explicitly use :q! instead of :q when quitting the file.
>
> If _you_ want to use 'hidden', then set it in your vimrc, but don't
> force every people who don't want it to explicitly ":set nohidden" in
> _their_ vimrc.

I agree with Tony, 'hidden' is not actually very friendly to new users.

And, I don't see how it's going to prevent anyone from using tab pages as file proxies.

If one were to change anything for ease-of-use for new users, it wouldn't be 'hidden', it would be 'confirm', so that Vim becomes consistent with many other programs which don't just refuse to quit when you have unsaved changes, they instead ask you whether you want to save first.

[Ben Fritz]

On Sunday, July 24, 2016 at 8:03:06 AM UTC-5, Bram Moolenaar wrote:
>
> if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>

Don't common plugin managers require you to turn on filetype stuff at a very specific location, e.g. *after* loading the plugin manager functionality?

I.e. will this interfere with plugin managers? Or is it enough for them to document "filetype off...enableMe()...filetype plugin indent on" in their installation instructions?

I guess many Vim distributions already enable filetype stuff in the system vimrc, so maybe the installation instructions already account for this.

[h_east]

Hi Bram and All,

I think it is better to change the default value of Vim body for some of the options.

i.e.
set wildmenu
set ruler
set showcmd
set tags=./tags;,tags;
etc...

Obviously useful things should be changed.

Thanks.

[Tony Mechelynck]

":filetype plugin indent on" is one of the settings in the
vimrc_example.vim. I don't know when it was put there but it was
before my time, so I expect that most users have this as part of their
vimrc (either by sourcing the vimrc_example.vim from their vimrc, as I
do, or by having copied what was then the current vimrc_example.vim to
their first vimrc).

As said before, I source the vimrc_example.vim then I set ":filetype
indent off" because I personally find the filetype-dependent indenting
too overwhelming for my taste. Plain 'smartindent' is enough for me,
and perhaps just a tiny wee bit much, but that's what I use; but
filetype detection (and ":syntax on" which the example vimrc also
sets, and relies on knowing the filetype) I have liked from the start.

If a plugin manager expects to run before filetype detection is
enabled, it would have to be sourced from a _system_ vimrc, which is
one of the very few vimscripts run before the _user_ vimrc; however in
that case it would also find itself in 'nocompatible' mode since at
that point Vim hasn't yet asked itself "Does this user have a vimrc?"


Best regards,
Tony.

[Bram Moolenaar]

Hirohito Higashi wrote:

> I think it is better to change the default value of Vim body for some
> of the options.
>
> i.e.
> set wildmenu
> set ruler
> set showcmd
> set tags=./tags;,tags;
> etc...
>
> Obviously useful things should be changed.

A few people have mentioned setting 'wildmenu'. I also have that set.
I wonder if there are real disadvantages to setting it by default?

Keep in mind that most of these defaults are for options that new users
would not even know about. It's possible that a few users don't like it
and have to disable it in their .vimrc. So long as that number is
small (less than 1%?) that would be an acceptable price for helping new
users enjoying Vim more.

--
ARTHUR: Charge!
[They all charge with swords drawn towards the RABBIT. A tremendous twenty
second fight with Peckinpahish shots and borrowing heavily also on the
Kung Fu and karate-type films ensues, in which some four KNIGHTS are
comprehensively killed.]
ARTHUR: Run away! Run away!

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Christian Brabandt]

Hi Bram!

On So, 24 Jul 2016, Bram Moolenaar wrote:

> > please no hlsearch. That is most often annoying.
>
> Well, I find it useful. But I suppose that's more a personal
> preference.

perhaps, if we made ctrl-l clear the search highlighting by default?

> > some more I would set, the mentioned
> > :set display+=lastline
>
> As mentioned, I don't use it myself, I expect long time Vi/Vim users to
> be surprised if this changes.

Really? I think the default of a bunch of '@'
doesn't really help anybody, instead show at least the beginning of the
line.

Just my opinion however,


Best,
Christian
--
Gemeinsame Erinnerungen sind manchmal die besten Friedensstifter.
-- Marcel Proust

[Tumbler Terrall]

On Monday, July 25, 2016 at 3:11:11 PM UTC-5, Christian Brabandt wrote:
> Hi Bram!
>
> On So, 24 Jul 2016, Bram Moolenaar wrote:
>
> > > please no hlsearch. That is most often annoying.
> >
> > Well, I find it useful. But I suppose that's more a personal
> > preference.
>
> perhaps, if we made ctrl-l clear the search highlighting by default?

I personally like the idea of turning on hlsearch by default, but +1 to
the idea of also making ctrl-l clear the hl.

~Tumbler Terrall

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 10:10 PM, Christian Brabandt <cbl...@256bit.org> wrote:
> Hi Bram!
>
> On So, 24 Jul 2016, Bram Moolenaar wrote:
>
>> > please no hlsearch. That is most often annoying.
>>
>> Well, I find it useful. But I suppose that's more a personal
>> preference.
>
> perhaps, if we made ctrl-l clear the search highlighting by default?
>
>> > some more I would set, the mentioned
>> > :set display+=lastline
>>
>> As mentioned, I don't use it myself, I expect long time Vi/Vim users to
>> be surprised if this changes.
>
> Really? I think the default of a bunch of '@'
> doesn't really help anybody, instead show at least the beginning of the
> line.
>

For people like me, who set 'wrap', display-=lastline would replace a
"long last line" by several rows of @@@@@... which can be _extremely_
annoying. Just @@@ at bottom right (or at bottom left if 'rightleft'
is set) should IMHO be sufficient to show that the line goes on after
the end of the screen, without filling maybe half the screen with only
row after row after row of only at-signs.

Of course I set +=lastline myself, since I need it and ATM it is not a
default, but I can't imagine someone hollering in dismay if a last
line (of several screen lines if 'wrap' is set) weren't anymore filled
with at-signs only, but only the last three character cells were.

> Just my opinion however,
>
>
> Best,
> Christian

And just mine.

Best regards,
Tony.

[Tony Mechelynck]

'incsearch' and 'hlsearch' are part of the settings set by the
vimrc_example.vim, and I like them. Clearing the highlight whenever I
repaint the screen? Hm, I'm not convinced. I dont like the idea of
having Ctrl-L serve as both ":redraw" and ":nohls" which are totally
unrelated in my mind. I prefer the latest search highlight to remain
highlighted regardless of possible screen repaints, until or unless I
explicitly turn it off with either ":nohls" or ":let @/ = ''" (i.e.,
in case your email reader doesn't clearly display quotation marks,
make the search register an empty string).

Best regards,
Tony.

[Gary Johnson]

The only time I use Ctrl-L is when something has messed up my
display and I want to redraw it. I just want it redrawn exactly as
it was, including any search highlights. If you want to have Ctrl-L
also execute :nohls, create a mapping.

Regards,
Gary

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 10:00 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Hirohito Higashi wrote:
>
>> I think it is better to change the default value of Vim body for some
>> of the options.
>>
>> i.e.
>> set wildmenu
>> set ruler
>> set showcmd
>> set tags=./tags;,tags;
>> etc...
>>
>> Obviously useful things should be changed.
>
> A few people have mentioned setting 'wildmenu'. I also have that set.
> I wonder if there are real disadvantages to setting it by default?
>
> Keep in mind that most of these defaults are for options that new users
> would not even know about. It's possible that a few users don't like it
> and have to disable it in their .vimrc. So long as that number is
> small (less than 1%?) that would be an acceptable price for helping new
> users enjoying Vim more.
>

I use 'wildmenu' too, but it should be remembered that it goes hand in
hand with 'wildmode' and for the latter I'm not sure everyone, or even
most people, use the same setting (I use ":set
wildmode=longest:full,full".)

Otherwise I like it so much that I source menu.vim in my vimrc
(guarded of course by "if has('menu') && !has('gui_running')") in
order to be able to use the gvim-like menus (File, Edit, etc.) even in
Console mode, on the statusline (and even though I actually don't use
them often).

Best regards,
Tony.

[Tim Chase]

On 2016-07-25 18:25, Gary Johnson wrote:
> If you want to have Ctrl-L also execute :nohls,

I do...


> create a mapping.

I do. Though I also agree that it's the sort of thing that people
will change if they want different behavior. So I don't see changing
it just for the sake of changing things as it only serves the group
of "people who want this behavior and haven't figured out how to do
it already". Maybe I'm just a curmudgeon like that. But doesn't that
go with using vi? :-)

-tim

[Bram Moolenaar]

The problem of the current "lastline" implementation is that the @@@ at
the end is quite hard to spot. Switching from the old Vi behavior of
all "@" lines to that is quite a big jump:

old:
asdf asdf asdf asdf asd
@
@
@
@

lastline:
asdf asdf asdf asdf asd
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fas@@@

At the same time, the "@" lines filling most of the screen it useless.
I think everybody agrees with that.

So, trying to find a solution that we can use as default for everybody,
how about this: Show "@@@" in the last line, no other text. Then it's
clear there is more following, but still showing the lines that are
available. For a two-screen-line while there is only space for one, you
would only get "@@@". Users who want more can switch to "lastline" as
before. We could call this "truncate"

truncate:
asdf asdf asdf asdf asd
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
@@@


--
ROBIN: The what?
ARTHUR: The Holy Hand Grenade of Antioch. 'Tis one of the sacred relics
Brother Maynard always carries with him.
ALL: Yes. Of course.
ARTHUR: (shouting) Bring up the Holy Hand Grenade!

[Greg Vilardi]

Hi Bram, et al.

As a long time lurker on the list, and user of vim since somewhere in v5 and vi
since 1987, I first want to say thank you for vim, and especially for the
careful thought and way you pay attention to details like these. I agree that
updating the default settings is reasonable, and your choice of timing is well
reasoned.

As someone who edits lots of files with really long lines, I have to say that
this change will definitely violate the rule of least surprise for me, but that
I will be very happy about it after the first week. I would definitely want the
continuation marker to begin in column 1 as you propose.

If it helps any, I also source vimrc_example.vim as the starting point of my
.vimrc.

-Greg
--
Greg Vilardi |Technical Lead E-mail:vil...@panix.com
USnail: 354 Indian Head Rd |Vormittag Associates, Inc. Home:(631)864-1310
Commack, NY 11725 |Ronkonkoma, NY 11779 Cell:(631)627-1448
.sig Version 0.71 I thought, I wrote, I posted.

[Erik Falor]

On Sun, Jul 24, 2016 at 07:50:51PM -0700, h_east wrote:
> Please refer to the last two lines of `:help iquote`.
> DOC> i" v_iquote iquote
> DOC> i' v_i' i'
> DOC> i` v_i` i`
> DOC> Like a", a' and a`, but exclude the quotes and
> DOC> repeating won't extend the Visual selection.
> DOC> Special case: With a count of 2 the quotes are
> DOC> included, but no extra white space as with a"/a'/a`.
>
> In the current situation, it can be avoided in the following way.
>
> c2i"

Well, that's a cool trick indeed, and scratches the itch nicely. It's
too bad that it costs an extra keystroke and is a *really* special
case.

I would definitely get on board with an option that allows for
fine-grain control over how some of the "a" text objects treat
surrounding whitespace.

--
Erik Falor
Registered Linux User #445632 http://unnovative.net

[Brennen Bearnes]

A note in support of the idea that 8.0 seems like a
reasonable time for this kind of change. Vim's maximum
utility and friendliness really only come after some
configuration work, and I don't expect that to change any
time soon, but nudging it towards more modern out-of-the-box
behavior for new users seems like a fine idea at this point
in 2016.

As a data point re: hlsearch, it's something that I find
useful in small doses, and thus have a mapping to toggle. I
don't feel super strongly that it should be off by default,
but I'd probably turn it off in my own .vimrc if it were
on by default.

-- bpb

[h_east]

Hi Bram and list,

2016-7-24(Sun) 22:03:06 UTC+9 Bram Moolenaar:

> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'. That's nice for people
> who rely on the old Vi. But how many of these still exist? I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change. Many
> users will notice that Vim suddenly behaves differently. Some may be
> upset. The release of Vim 8.0 might be the best point in time to do
> this. If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default. Currently these are in
> $VIMRUNTIME/vimrc_example.vim. Most of these only have a visual effect
> or slightly change how editing works. You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>

> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings. This is
> the most common and also most tricky part. Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy. But including the
> matchit plugin is not easy to revert.
>

> What we can probably always do:
>
> set backspace=indent,eol,start
> set history=50 " keep 50 lines of command line history
> set ruler " show the cursor position all the time
> set showcmd " display incomplete commands
> set incsearch " do incremental searching
>

> " Don't use Ex mode, use Q for formatting
> map Q gq
>

> " In many terminal emulators the mouse works just fine, thus enable it.
> if has('mouse')
> set mouse=a
> endif

> if &t_Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
> endif
>

> if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>

> augroup vimrcEx
> au!
>
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
>
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
> \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> \ exe "normal! g`\"" |
> \ endif
>
> augroup END
> else
> set autoindent " always set autoindenting on
> endif
>

> if has('langmap') && exists('+langnoremap')
> set langnoremap
> endif
>
>

> Probably not:
>
> " these two leave files behind
> set backup
> set undofile
>

> " may conflict with a user mapping
> inoremap <C-U> <C-G>u<C-U>
>

> " hard to revert
> if has('syntax') && has('eval')
> packadd matchit
> endif
>

> Comments?

Sorry for late reply :-)

I want to add the following setting:

" If Vim cause malfunctioning cursor keys on slow terminals or very busy systems, adjust the value or comment out this.
set ttimeoutlen=0

'ttimeoutlen' default value is -1.
This means that use the 'timeoutlen' to the key code time-out value.
That one second.
I think most user feels "Vim is slow" in the following operation. This is disadvantage.
- When the transition to the normal-mode by pressing the XXX in insert-mode.
i<Esc>
- Similarly, in visual-mode.
V<Esc>
- Similarly, in cmdline-mode.
:<Esc>

Yes, I know that lag does not occur if the input without waiting for the display is switched.
But, most people would wait until the display is switched. And they feels "Vim is slow...".

`set ttimeoutlen=0` will solve the above.

I have invested in above setting more than a year, but the trouble does not happen even once.

thanks.

[Bram Moolenaar]

Hirohito Higashi wrote:

> Sorry for late reply :-)
>
> I want to add the following setting:
>
> " If Vim cause malfunctioning cursor keys on slow terminals or very busy systems, adjust the value or comment out this.
> set ttimeoutlen=0
>
> 'ttimeoutlen' default value is -1.
> This means that use the 'timeoutlen' to the key code time-out value.
> That one second.
> I think most user feels "Vim is slow" in the following operation. This is disadvantage.
> - When the transition to the normal-mode by pressing the XXX in insert-mode.
> i<Esc>
> - Similarly, in visual-mode.
> V<Esc>
> - Similarly, in cmdline-mode.
> :<Esc>
>
> Yes, I know that lag does not occur if the input without waiting for
> the display is switched.
> But, most people would wait until the display is switched. And they
> feels "Vim is slow...".
>
> `set ttimeoutlen=0` will solve the above.
>
> I have invested in above setting more than a year, but the trouble
> does not happen even once.

Zero only works when you are directly using a terminal. When using a
remote shell it might not work properly. But one second is indeed too
much.

I have it set to 200, this still has some lag. I think 100 would work
for just about everyone.

--
Latest survey shows that 3 out of 4 people make up 75% of the
world's population.

[Marcin Szamotulski]

Hi Tim and Bram

> > > As a backwards incompatible change, my biggest want would be that the
> > > outer-quotation text objects (a" and a') would no longer eat leading
> > > whitespace. I've never wanted the out-of-box behavior, always
> > > wanting to change just the string-cum-quotes.
> > >
> > > http://vim.1045645.n5.nabble.com/quotation-text-object-consternation-td5725045.html
> > >
> > > Or at least an option to control that.
> >
> > First time I hear about this.
>
> Please refer to the last two lines of `:help iquote`.
> DOC> i" v_iquote iquote
> DOC> i' v_i' i'
> DOC> i` v_i` i`
> DOC> Like a", a' and a`, but exclude the quotes and
> DOC> repeating won't extend the Visual selection.
> DOC> Special case: With a count of 2 the quotes are
> DOC> included, but no extra white space as with a"/a'/a`.
>
> In the current situation, it can be avoided in the following way.
>
> c2i"
>
> --
> Best regards,
> Hirohito Higashi (a.k.a. h_east)

I agree with Tim that this would be a nice, though incompatible change
for vim. I use these mappings to make a" leave the space intact:
xmap <silent> a" i"lOhO
omap <silent> a" :<C-U>normal! vi"lOhO<CR>

Best regards,
Marcin

[Michael Henry]

On 08/20/2016 01:22 PM, Bram Moolenaar wrote:

> Hirohito Higashi wrote:
>> `set ttimeoutlen=0` will solve the above.
>>
>> I have invested in above setting more than a year, but the
>> trouble does not happen even once.
>
> Zero only works when you are directly using a terminal. When
> using a remote shell it might not work properly. But one
> second is indeed too much.
>
> I have it set to 200, this still has some lag. I think 100
> would work for just about everyone.

I ran for a long time without trouble using 50 milliseconds.
But even this eventually proved too long once I began using
Alt-letter mappings in console Vim. The key sequence for Alt-j
is <Esc>j. I would frequently press <Esc> to exit insert mode
followed quickly by the j key, and Vim would misinterpret the
sequence as Alt-j (which would then invoke my insert-mode
mapping for Alt-j). I found experimentally that I could set
ttimeoutlen to 5 to avoid most instances of this kind of
incorrect key interpretation. This value has never proved to be
too small in my use. I've never noticed a case of Vim timing
out in the middle of a valid multi-key sequence and splitting it
incorrectly into multiple keypresses, even when using Vim across
an SSH connection; however, these connections were typically
done over a local Ethernet, so on a slower network it's possible
that such splitting could occur (such that Alt-j might be split
erroneously into <Esc> followed by j). I consider this an
unlikely case, since the multi-key sequence will probably be
written to the network as a unit and carried in a single network
packet, regardless of the speed of the network; still, until we
start using uniquely decodable key sequences so we don't have to
rely on timeouts, there will always be some risk of incorrect
key interpretation.

I think 100ms is better than 200ms as a default. I wouldn't
suggest a default as low as 5ms due to the possible risk of
misinterpreting multi-byte key sequences, even though I've never
personally noticed such a failure. Users like myself who
require shorter values can always override the default. I'll
also note that I've seen 100ms used elsewhere, such as in Tim
Pope's "Sensible Defaults" plugin:
https://github.com/tpope/vim-sensible/blob/master/plugin/sensible.vim#L28

Michael Henry

[h_east]

Hi Michael,

2016-8-21(Sun) 21:58:54 UTC+9 Michael Henry:

Thanks for the reply.
`set ttimeoutlen=100` is already included at patch 7.4.2232.
https://github.com/vim/vim/commit/e07e797db0c5ef1aafc650d8bb0d39fb052cf1e1

I think "100" is enough as the default.
I might be okay with a smaller value, I think that it would be changed in the individual.