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

[tyru]

Hi Bram!

I want to propose the following settings additionally.

--------------------------------
set ambiwidth=double
set display=lastline
set formatoptions+=j
set nrformats-=octal

let s:is_win = has('win16') || has('win32') || has('win64') || has('win95')
let s:is_msys = has('win32unix') && !has('gui_running')

" Exit diff mode automatically {{{
" https://hail2u.net/blog/software/vim-turn-off-diff-mode-automatically.html

augroup vimrc-diff-autocommands
autocmd!

" Turn off diff mode automatically
autocmd WinEnter *
\ if (winnr('$') == 1) &&
\ (getbufvar(winbufnr(0), '&diff')) == 1 |
\ diffoff |
\ endif
augroup END
" }}}

" Block cursor in MSYS2 console {{{
if s:is_msys
let &t_ti.="\e[1 q"
let &t_SI.="\e[5 q"
let &t_EI.="\e[1 q"
let &t_te.="\e[0 q"
endif
" }}}

" Input Method {{{
if has('multi_byte_ime') || has('xim')
" Set cursor color when IME is on.
highlight CursorIM guibg=Purple guifg=NONE
set iminsert=0 imsearch=0
endif
" }}}

--------------------------------

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

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Takuya Fujiwara

[Nicola]

On 2016-07-24 13:02:56 +0000, Bram Moolenaar said:

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

Talking as someone who has been using Vim only for a couple of years and
who does not work with systems more than a decade old, I would welcome
such changes. And a major release obviously provides the best opportunity
for introducing backward-incompatible changes.

I agree with the defaults you are proposing. How about the following?

1) nnoremap Y y$

2) Make UTF8 the default encoding.

> What we can probably always do:
>

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

I would also set ttymouse=sgr when possible (but I do not know all the
implications).

Nicola

[lilydjwg]

Hi,

On Sun, Jul 24, 2016 at 10:21:32PM +0900, tyru wrote:
> I want to propose the following settings additionally.
>
> --------------------------------
> set ambiwidth=double

Please don't do this for Linux terminals, at least when it doesn't work
well:

For the following text,

“test”
‘test’

gvim works well:
https://img.vim-cn.com/cb/1ef8cb00cb23be45a49ae2764a7c1531fb3cc0.png

But my terminal has some issue with the placement and highlighting:
https://img.vim-cn.com/92/c802187c35e82857c7c96311f9198b71a35a5c.png

The left quotes are placed too left, and the right half doesn't get
highlighted as expected.

When I delete the first t's, the display is wrong:
https://img.vim-cn.com/42/c990d919df4c568f1105063112d0569a7107da.png

This happens to me with both xterm and xfce4-terminal on Arch Linux.

Versions:

* xterm 325
* xfce4-terminal 0.6.3
* gvim 7.4.2098

It displays better with xterm -cjk_width, but there are still some issues:
https://img.vim-cn.com/d6/07e66736903fb6bb55c687237f94637765a77b.png

> set display=lastline
> set formatoptions+=j
> set nrformats-=octal

> [...]

--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

[Yegappan Lakshmanan]

Hi,

On Sun, Jul 24, 2016 at 7:04 AM, lilydjwg <lily...@gmail.com> wrote:
> Hi,
>
> On Sun, Jul 24, 2016 at 10:21:32PM +0900, tyru wrote:
>> I want to propose the following settings additionally.
>>
>> --------------------------------
>> set ambiwidth=double
>
> Please don't do this for Linux terminals, at least when it doesn't work
> well:
>

I agree. This option should not be set to 'double' by default in the system
wide vimrc. I also ran into xterm screen refresh problems with this option.
I have set 'ambiwidth' to 'single' in .vimrc to avoid this problem.

- Yegappan

[Michal Grochmal]

Hi Bram,

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

I will argue that *almost all* Linux user will not see the change. Once
upon a time I had an issue with nocp on my Arch Linux. It turns out
that Arch does `set nocompatible' inside /etc/vimrc that comes with its
packages.

I have also tested on a modern Debian (Jessie) and a modern CentOS (7),
and both also perform `set nocompatible' inside the distributed Vim.

The only package that I found that sets `compatible' was Debian's
`vim-tiny'. But even then, the package explicitly does `set compatible'
inside `/etc/vimrc'. Therefore not even the users of that distribution
of Vim will notice.

(Compiling from source is another story, of course)

--
Mike Grochmal
key ID 0xC840C4F6

[Bram Moolenaar]

Nicola wrote:

> On 2016-07-24 13:02:56 +0000, Bram Moolenaar said:
>
> > 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.
>
> Talking as someone who has been using Vim only for a couple of years and
> who does not work with systems more than a decade old, I would welcome
> such changes. And a major release obviously provides the best opportunity
> for introducing backward-incompatible changes.
>
> I agree with the defaults you are proposing. How about the following?
>
> 1) nnoremap Y y$

Please, this was not an invitation for everybody to mention their
favorite adjustments. In this case it's clear that most people,
including myself, expect Y to yank the current line. Changing this is
clearly a personal preference, not something that will help all users.

> 2) Make UTF8 the default encoding.

That is something that could break things in weird ways. Vim already
automatically sets 'encoding' to utf-8 in situations where it makes
sense.

> > What we can probably always do:
> >
> > " In many terminal emulators the mouse works just fine, thus enable it.
> > if has('mouse')
> > set mouse=a
> > endif
>
> I would also set ttymouse=sgr when possible (but I do not know all the
> implications).

This already happens when the required xterm version is detected.

--
[Autumn changed into Winter ... Winter changed into Spring ... Spring
changed back into Autumn and Autumn gave Winter and Spring a miss and
went straight on into Summer ... Until one day ...]

[Manuel Ortega]

Please do not set &incsearch.  It's one of the more annoying things in all of Vim, and very likely to bring an unexpected "what the heck?"

I am very opposed to everything in the above augroup.  There is no reason to foist this stuff on people just because "7" is changing to "8".   Also that BufReadPost autocmd is not easily reversible for newbs, since it's not a simple "set".

Please don't "setlocal" a &textwidth value for text files.  Don't mess with this at all, but if you do, don't make it "setlocal".  It is extremely annoying to have Vim sometimes hard-wrap lines and sometimes not, depending on which kind of file you're in---unless one specifically authorized this by purposely turning filetype plugins on or having a plugin/package that does this for certain &filetype.

  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?

Definitely not!  Especially "matchit", since it's hard to reverse.  I don't want that thing.  &undofile will leave unexpected litter around, which is ban enough; but since the litter will start with dots it will unintentionally wind up making it into tarballs because people will forget that such files are lurking.  Also, the "backup" related things will mess up "creation date" in mac OS depending on how they're configured.  Currently the creation date is preserved on macOS by Vim's default settings.

 

I'm not in general opposed automatically to the idea of making a small tweak or two for Vim 8, provided they won't affect too many people.  E.g., &nocompatible is probably OK.   But this proposal has too many of them, and for no good reason.  Frankly, for no reason at all other than "they happen to appear in an example of a vimrc".  Probably all that should happen is that &nocompatible is the default.  Definitely add nothing that requires more than  a simple "set" cmd to reverse, and nothing that affects the filesystem.

-Manny

[Manuel Ortega]

On Sun, Jul 24, 2016 at 12:09 PM, Manuel Ortega <manny...@gmail.com> wrote:

On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:

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?

Definitely not!  Especially "matchit", since it's hard to reverse.  I don't want that thing.  &undofile will leave unexpected litter around, which is ban enough; but since the litter will start with dots it will unintentionally wind up making it into tarballs because people will forget that such files are lurking.  Also, the "backup" related things will mess up "creation date" in mac OS depending on how they're configured.  Currently the creation date is preserved on macOS by Vim's default settings.

Scratch what I said about creation-date on macOS.  By default that isn't preserved.  (I mistakenly thought it was because setting &bkc will preserve it, and the docs for &bkc say that it is on by default for "unix".  Apparently OS X doesn't count as "unix", because on OS X &bkc is set to "auto".  Probably the docs should be corrected here.)

But add that setting &backup will leave litter around on the filesystem.  Please don't leave unexpected litter around on the filesystem.   Among other things, such backup files are bound to unintentionally get captured in tarballs.

-Manny

[tyru]

Hi Bram,

2016/07/25 0:33 "Bram Moolenaar" <Br...@moolenaar.net>:

>
>
> Nicola wrote:
>
> > On 2016-07-24 13:02:56 +0000, Bram Moolenaar said:
> >
> > > 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.
> >
> > Talking as someone who has been using Vim only for a couple of years and
> > who does not work with systems more than a decade old, I would welcome
> > such changes. And a major release obviously provides the best opportunity
> > for introducing backward-incompatible changes.
> >
> > I agree with the defaults you are proposing. How about the following?
> >
> > 1) nnoremap Y y$
>
> Please, this was not an invitation for everybody to mention their
> favorite adjustments.

Sorry, it's too much.

so do you think this setting is also personal preference, not 'compatible' one?

set display+=lastline

Any reason to not display long line instead of '@' ?
for speed?
is it really good default value for "normal user" ?

> In this case it's clear that most people,
> including myself, expect Y to yank the current line.  Changing this is
> clearly a personal preference, not something that will help all users.
>
> > 2) Make UTF8 the default encoding.
>
> That is something that could break things in weird ways.  Vim already
> automatically sets 'encoding' to utf-8 in situations where it makes
> sense.
>
> > > What we can probably always do:
> > >
> > >   " In many terminal emulators the mouse works just fine, thus enable it.
> > >   if has('mouse')
> > >     set mouse=a
> > >   endif
> >
> > I would also set ttymouse=sgr when possible (but I do not know all the
> > implications).
>
> This already happens when the required xterm version is detected.
>
> --
>        [Autumn changed into Winter ... Winter changed into Spring ...  Spring
>        changed back into Autumn and Autumn gave Winter and Spring a miss and
>        went straight on into Summer ...  Until one day ...]
>                  "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

[Bram Moolenaar]

Tyru wrote:

> so do you think this setting is also personal preference, not 'compatible'
> one?
>
> set display+=lastline
>
> Any reason to not display long line instead of '@' ?
> for speed?
> is it really good default value for "normal user" ?

I'm not sure if I am a good example, but I don't use that. I don't
often have text with long lines and it's nice to easily see the last
line is incomplete. It's one of those things that make the editor feel
like Vi.

--
My girlfriend told me I should be more affectionate.
So I got TWO girlfriends.

[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

[Ingo Karkat]

Manuel Ortega <manny...@gmail.com> wrote:
> On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:
> > " For all text files set 'textwidth' to 78 characters.
> > autocmd FileType text setlocal textwidth=78

> Please don't "setlocal" a &textwidth value for text files. Don't mess
> with this at all, but if you do, don't make it "setlocal". It is
> extremely annoying to have Vim sometimes hard-wrap lines and sometimes
> not, depending on which kind of file you're in---unless one specifically
> authorized this by purposely turning filetype plugins on or having a
> plugin/package that does this for certain &filetype.

Using :autocmd FileType sets a bad precedent: this doesn't scale (one
autocmd per filetype and setting is too much and bloats the .vimrc), and
Vim has a much better mechanism for filetype-specific settings:
ftplugins (with :filetype plugin on). This way, the change is also
undone (through b:undo_ftplugin), if the user manually changes the
filetype.

With regards to the 'textwidth' setting: I would recommend to leave this
out, as there's no generally accepted notion of a "text" file;
hard-wrapping may be desired or not, so it's best to leave this up to
the user.

-- regards, ingo

[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

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

[Nelo-Thara Wallus]

On 2016-07-24 15:02, Bram Moolenaar wrote:
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78

I'd object to that, autocommands are executed after ftplugins and would
overwrite user settings (unless the user creates an au to change it).

So a user who wants a different textwidth would have to riddle the vimrc
with autocommands or place them in a plugin/ file.

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

These two would be handy by default, imho, but with the addition of
a new default for &backupdir and &undodir:

set backupdir=~/tmp,~/.vim/backup,/tmp/vim-backup
set undodir=~/tmp,~/.vim/undo,/tmp/vim-undo

Or similar - as long as it doesn't include the pwd by default anymore,
since that is causing a lot of confusion with new users.

The same would be nice for the default &dir, which also puts the
swapfiles into the pwd instead of somewhere where it doesn't annoy the
user.

--
Viktoriastrasse 22
76133 Karlsruhe
Nr.: 0721 / 96 55 63 95
Mobile: 0178 / 53 17 067
Web: https://nelo.wallus.de/
/"\ ASCII Ribbon Campaign
\ / - against HTML emails
X - against proprietory attachments
/ \ http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign

[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.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)

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

[Charles E Campbell]

Except for incsearch, my .vimrc already incorporates these settings, so
I'm fine with them myself. incsearch is "noisy" and changes the visual
interface (ie. becomes prominent) and I don't advise doing so, even
though I myself might decide to use it someday. At least its easily
reversible in one's .vimrc.

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

Doesn't modify look&feel (unless one types a "Q", of course). Guess I'm
neutral on this one.

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

Probably a good idea.

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

Setting hlsearch definitely modifies the look&feel, and I myself only
use hls in specific situations. I'd rather not have this one, although
at least its easy to countermand with a set nohls.

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

This modifies look&feel and is difficult to prevent except on a
file-by-file basis. Please don't do this.

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

I myself already do something like this in my .vimrc. However, even
though I like this, it would be difficult not-to-have. Perhaps cp
should have levels: 0=compatible, 1= current nocp, 2=more, etc, or
perhaps a letter-driven selection (something like complete).

>
> augroup END
> else
> set autoindent " always set autoindenting on
> endif

I don't care, I guess -- easily reversed.

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

I had to look this one up as I've never had cause to use it. Easily
reversed, so I'm neutral on this one.

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

Leaving files behind -- I have enough of a problem with macs and .dSYM
directories getting into my tarballs; I use set directory to move swap
files where I don't back them up, and I've not used undofiles. These
two are easily reversible, though. I'm sure I wouldn't like the
proposed ctrl-u map, although I know how to get rid of it so it wouldn't
be a major problem. I think it would be best to document any of these
changes and include how-to-prevent/restore/obviate them. Does the last
item (with matchit) mean that matchit will become a package which must
be packadd'd?

Regards,
Chip Campbell

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 8:03 PM, Charles E Campbell
<drc...@campbellfamily.biz> wrote:
+>> set langnoremap

Actually, matchit is already now a package which the current
vimrc_example.vim packadds. Easier to do than the former
jumping-through-hoops to get it from the "macros" directory where it
used to be distributed. The files in /macros/ are still there, though
the macros/matchit.vim now sources the appropriate matchit.vim script
in the packages directory. If you included a copy or a symlink of
macros/matchit.txt in the doc subdirectory of one of your
'runtimepath' folders, and also source whatever is at any time the
latest vimrc_example.vim, you'll notice that matchit.txt is now listed
twice among the "user additions" near the end of
$VIMRUNTIME/doc/help.txt when invoked from within Vim. Similarly, if
you included the matchit.vim plugin "the old way" and also source the
vimrc_example.vim, ":scriptnames" now also lists matchit twice but it
is a little harder to spot.

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

[Charles E Campbell]

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?
>
>>> 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,
>

How about another opinion? :)

I use ve=all and nowrap, not that I think these should be inflicted on
everyone. However, because of the nowrap, I don't really need the
display+=lastline as I don't get those @s. So I don't suppose I would
be affected either way.

Regards,
Chip

[Manuel Ortega]

On Mon, Jul 25, 2016 at 4: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?

What are the advantages to *setting* it?  This looks like a shining example of "personal preference".

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.

Much of what is in the proposal works contrary to that purpose.

> Keep in mind that most of these defaults are for options that new users

> would not even know about.

This also means some of them are going to be unexpected, even jarring, to new users.

-Manny

[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]

On Tue, Jul 26, 2016 at 12:10 AM, Tumbler Terrall
<kingdom...@gmail.com> wrote:

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

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

[James McCoy]

On Mon, Jul 25, 2016 at 07:39:55AM -0700, Ben Fritz wrote:
> 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?

By now, most of them do this automatically, but I still advocate against
doing this before the vimrc is loaded since it causes non-obvious
problems to users (and am annoyed that Ubuntu deviates from the way I've
setup Debian's packaging in this regard).

The reason this needs to be done is to for ftdetect scripts.

Without doing the equivalent of

:filetype off
" Setup plugin manager
" Re-run :filetype on, if needed

any ftdetect scripts located in the runtime paths handled by the plugin
manager wouldn't have their settings applied.

Now, in Neovim we've enable filetype plugins and indent scripts by
default. However, we also track whether they were enabled
automatically, or modified by the user, so that "filetype plugin on" in
the user's vimrc only enables plugins instead of acting like a no-op.
You can see the discussion of the behavior/implementation at
<https://github.com/neovim/neovim/pull/4223>.

Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB

[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?

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

[Matthew Winn]

On 24/07/16 20:43, Bram Moolenaar wrote:

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

Searching for a pattern is a fundamentally different operation from
highlighting matches of a pattern. I hate it when a system has hlsearch
on by default because most of the time when I'm searching it's so I can
examine each individual match separately and decide what needs to be
done at each location. With multiple matches on the screen it can be
difficult to spot which one is THE match.

--
Matthew Winn

[Tony Mechelynck]

Me, OTOH, I find it useful: when there are several matches on the
screen it's easier to spot them; then if none of them is THE match,
rather nan hit n to get at all of them in turn, I'll move the cursor
to the other side of them all and continue from there.

The default hlsearch colours of gvim (with yellow background instead
of white for Normal, i.e. just enough contrast but not toooooo much) I
prefer to those of less (reverse-video); but of course less uses the
same colours (which are monochrome colours) regardless of the terminal
while Vim has separate settings for term, cterm and gui.

Well, to each his own I suppose. "De gustibus et coloribus non est disputandum."


Best regards,
Tony.

[Thomas Köhler]

Hi Bram,

On Sun, Jul 24, 2016 at 03:02:56PM +0200, Bram Moolenaar <Br...@moolenaar.net> wrote:
> Vim has always been conservative about the default option values.

And that is actually a very good thing.

As I work as a consultant, and the systems the customers use have
a wide variety of Linux distributions of varying age and thus vim
default settings, most often I end up setting a few options
anyway. (I often go with ":se ls=2 nu nocp" and "colorscheme
koehler" for a basic "feel at home" setting, while my .vimrc at
home is rather long (~800 lines)).

I'd like to share some thoughts here.

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

I personally don't like that one, especially the "start" part of
it. I always considered it a feature to not be able to backspace
over the start of insert.
Actually, when I encounter a vim that is configured to add
"start" to 'backspace', I usually unset this as soon as I see it.

> 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

I often use all of those, also adding hlsearch.

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

I don't like this one. But then I occassionally actually use Ex mode.

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

Please... no.
I always hat it whenever a distribution does this by default,
moving the cursor for a simple cut&paste operation.

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

I could live with those (usually using most of that anyway, not
the c_comment_strings however)

> if has("autocmd")
[...]
> endif

I'd suggest not using that.

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

I don't actually care about this one.

> 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

Yes, please leave those out.


Ciao,
Thomas

--
Thomas Köhler Email: jean...@picard.franken.de
<>< WWW: http://gott-gehabt.de
IRC: tkoehler Freenode: thkoehler
PGP public key available from Homepage!

[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!

[Erik Falor]

On Mon, Jul 25, 2016 at 07:37:46AM -0700, Ben Fritz wrote:
> 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.

+1
This would remove a big stumbling block from new users, and would be
minimally invasive to old hands.

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

[Bram Moolenaar]

Arent't users already executing the filetype command early in their
.vimrc? If a plugin manager can't handle that, it has a problem anyway.
It has always been in the vimrc_example.vim.

We could postpone the effect of the :filetype command, but that will
most likely cause problems for users who intentionally do it early and
then overrule some of it.

I think plugins should not use ftdetect/*.vim but execute the
autocommands that it would contain in the plugin. Is there any problem
with that?

--
Lose weight, NEVER Diet again with
The "Invisible Weight Loss Patch"
(spam e-mail)

[Gary Johnson]

No. I execute the filetype command late in my vimrc so that some of
my BufRead autocommands will be executed before Vim's. I want
buffers to be initially configured by project, which means looking
at the full path to the file being opened, and then by filetype.

I turn _off_ filetype detection near the top of my vimrc in
environments where it's been turned on in some system vimrc.

Regards,
Gary

[Bram Moolenaar]

Hmm, this very much depends on what you want to do in your .vimrc.
I think it's still best to enable filetype detection when there is no
.vimrc at all. And I suspect doing what you do, disabling filetype
detection at the start of your .vimrc allows for any sequence that you
choose.


Here is what I have come up with, listenting to the comments so far and
giving it some magic weighing:


" The startup file file.
"
" Maintainer: Bram Moolenaar <Br...@vim.org>
" Last change: 2016 Jul 25
"
" This is loaded very early on startup, execpt with Vim is run with "-u NONE".

" When started as "evim", evim.vim will already have done these settings.
if v:progname =~? "evim"
finish
endif

" Use Vim settings, rather than Vi settings (much better!).
" This must be first, because it changes other options as a side effect.
set nocompatible

" allow backspacing over everything in insert mode
set backspace=indent,eol,start

set history=200 " keep 200 lines of command line history

set ruler " show the cursor position all the time
set showcmd " display incomplete commands

set wildmenu " display completion matches in a status line

" Do incremental searching when it's possible to timeout.
if has('reltime')
set incsearch
endif

" Do not recognize octal numbers for Ctrl-A and Ctrl-X, most users find it
" confusing.
set nrformat-=octal

" For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
" let &guioptions = substitute(&guioptions, "t", "", "g")

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

" CTRL-U in insert mode deletes a lot. Use CTRL-G u to first break undo,
" so that you can undo CTRL-U after inserting a line break.

inoremap <C-U> <C-G>u<C-U>

" In many terminal emulators the mouse works just fine. By enabling it you
" can position the cursor, Visually select and scroll with the mouse.

if has('mouse')
set mouse=a
endif

" Switch syntax highlighting on when the terminal has colors or when using the
" GUI (which always has colors).

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

" I like highlighting strings inside C comments.
let c_comment_strings=1
endif

" Only do this part when compiled with support for autocommands.

if has("autocmd")

" Enable file type detection.

" Use the default filetype settings, so that mail gets 'tw' set to 72,
" 'cindent' is on in C files, etc.
" Also load indent files, to automatically do language-dependent indenting.
filetype plugin indent on

" Put these in an autocmd group, so that we can delete them easily with:
" augroup vimStartup | au! | augroup END
augroup vimStartup
au!

" 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

endif " has("autocmd")

" Convenient command to see the difference between the current buffer and the
" file it was loaded from, thus the changes you made.
" Only define it when not defined already.
if !exists(":DiffOrig")
command DiffOrig vert new | set bt=nofile | r ++edit # | 0d_ | diffthis
\ | wincmd p | diffthis
endif

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

" Prevent that the langmap option applies to characters that result from a
" mapping. If unset (default), this may break plugins (but it's backward
" compatible).
set langnoremap
endif

--
Dreams are free, but there's a small charge for alterations.

[Gary Johnson]

[...]

Not all of those would be my preference, but they seem reasonable,
and as long as all of that is in a file and the compile-time
defaults aren't changed, I'm fine with it.

I was surprised by this:

> " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
> " let &guioptions = substitute(&guioptions, "t", "", "g")

Why substitute() instead of just -=?

set guioptions-=t

Regards,
Gary

[Manuel Ortega]

On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

" Only do this part when compiled with support for autocommands.
if has("autocmd")

  " Enable file type detection.
  " Use the default filetype settings, so that mail gets 'tw' set to 72,
  " 'cindent' is on in C files, etc.
  " Also load indent files, to automatically do language-dependent indenting.
  filetype plugin indent on

This is a plea to not enable ftplugins.  They make using vim analogous to driving a car whose mirrors, seat adjustment, and radio station keep automatically changing depending on what direction the car is pointing.

 

I like that none of this will happen with '-u NONE'.

-Manny

[Manuel Ortega]

On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

" Switch syntax highlighting on when the terminal has colors or when using the
" GUI (which always has colors).
if &t_Co > 2 || has("gui_running")
  syntax on

Wait a sec.  If "syntax on" is done here, then won't it be impossible to use "set guioptions+=M" in the user's .vimrc and have it work?  The docs say that in order for that to work, it must be done "before switching on syntax or filetype recognition".  But if syntax is turned on here, by the time the  "set go+=M" in his .vimrc is encountered it will be too late, right?

-Manny

[Manuel Ortega]

Indeed, that is the case (I tried it).  If you put "syntax on" in the system vimrc, then the user cannot use "set go+=M".   I think this is a good reason to remove "syntax on" from the proposal.  If it's left in, you might as well just eliminate "M" as one of the guioptions, because it's totally unusable unless it goes in the local machine's system vimrc, which many users will not be able to change, or will not want to tweak it every time they build a new Vim.

-Manny

[Manuel Ortega]

If "syntax on" is in the system vimrc as proposed, then I can't seem to find any way *at all* to disable the loading of the system menu.vim (short of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)

Not only that, but the variables in menu.vim intended to be settable by the user to stop certain segments from loading, i.e., 

let did_install_default_menus = 1

let no_buffers_menu =1

let did_install_syntax_menu = 1

... have no effect in the user's vimrc because menu.vim is already loaded by the system vimrc's "syntax on".

Please, please, remove "syntax on" from the proposal.  There is no way for the user to undo its side-effects.

-Manny

[Kazunobu Kuriyama]

Hi, 

After having read your argument through, I’m still for ‘syntax on’.

After all, the problem boils down to this: How many GUI users do they actually set go=+M?

My bet is that the number is nearly zero.

If our system menu were of such less importance that one could kill it at will, it would not be worth being called “the system menu.”

IOW, as long as our system menu has a substantial role in our GUIs, allowing the users to set go+=M doesn’t make sense at all.

Rather, eliminating the M option would be the right way to go.

I think ‘syntax on’ as well as ‘filetype plugin indent on’ constitutes the core of Bram’s proposal and speaks out in an effective way about what the coming default changes are all about. 

I’m afraid its withdrawal will only make people wonder why Vim 8 falls short that way.

Best regards,

Kazunobu Kuriyama 

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James McCoy]

On Jul 27, 2016 6:20 AM, "Kazunobu Kuriyama" <kazunobu...@gmail.com> wrote:
>
> 2016-07-27 17:01 GMT+09:00 Manuel Ortega <manny...@gmail.com>:
>> If "syntax on" is in the system vimrc as proposed, then I can't seem to find any way *at all* to disable the loading of the system menu.vim (short of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>>
>> Not only that, but the variables in menu.vim intended to be settable by the user to stop certain segments from loading, i.e., 
>>
>> let did_install_default_menus = 1
>> let no_buffers_menu =1
>> let did_install_syntax_menu = 1
>>
>> ... have no effect in the user's vimrc because menu.vim is already loaded by the system vimrc's "syntax on".
>>
>> Please, please, remove "syntax on" from the proposal.  There is no way for the user to undo its side-effects.
>>
>> -Manny
>
>
> Hi, 
>
> After having read your argument through, I’m still for ‘syntax on’.
>
> After all, the problem boils down to this: How many GUI users do they actually set go=+M?
>
> My bet is that the number is nearly zero.
>
> If our system menu were of such less importance that one could kill it at will, it would not be worth being called “the system menu.”

I'd wager it's more than you think. I know many people that change gvim to basically look like console vim. Personally, I set 'guioptions' to just "cM".

Cheers,
James

[Christian Brabandt]

Hi James!

On Mi, 27 Jul 2016, James McCoy wrote:

> I'd wager it's more than you think. I know many people that change gvim to
> basically look like console vim. Personally, I set 'guioptions' to just
> "cM".

I do as well, but then I do not use vimrc_example. And that file should
be an example for being more friendly to the average user, not to some
power users, who already know their way around in Vim.

Best,
Christian
--
Ein Mann mit weißen Haaren ist wie ein Haus, auf dessen Dach
Schnee liegt. Das beweist aber noch lange nicht, daß im Herd kein
Feuer brennt.
-- Maurice Chevalier

[Gary Johnson]

On 2016-07-27, Manuel Ortega wrote:

> If "syntax on" is in the system vimrc as proposed, then I can't seem to find
> any way *at all* to disable the loading of the system menu.vim (short of
> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)

How about "sudo rm /usr/share/vim/vimrc"?

Another, less drastic way would be to create a file,
~/.vim/ftdetect/guioptions.vim, containing this:

set guioptions+=M

Regards,
Gary

[Ben Fritz]

I agree that "syntax on" and "filetype on" (maybe even "filetype plugin
indent on") are pretty core features that should probably be enabled by
default, as nearly everyone will use them.

However, I disagree that this should come at the expense of being able
to set up specific options. Anything done in the default settings should
be modifiable by the user, and it looks like in this situation that is
not possible, if the default settings are always sourced.

What if the default settings were not applied, if the user has specified
a .vimrc?

[Ben Fritz]

On Wednesday, July 27, 2016 at 9:45:11 AM UTC-5, Ben Fritz wrote:
>
> What if the default settings were not applied, if the user has specified
> a .vimrc?

...or maybe a new file sourced before the default settings? The default settings file itself could source it, if it exists.

[Manuel Ortega]

On Wed, Jul 27, 2016 at 6:20 AM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

2016-07-27 17:01 GMT+09:00 Manuel Ortega <manny...@gmail.com>:

On Wed, Jul 27, 2016 at 3:51 AM, Manuel Ortega <manny...@gmail.com> wrote:

On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega <manny...@gmail.com> wrote:

On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

" Switch syntax highlighting on when the terminal has colors or when using the
" GUI (which always has colors).
if &t_Co > 2 || has("gui_running")
  syntax on

Wait a sec.  If "syntax on" is done here, then won't it be impossible to use "set guioptions+=M" in the user's .vimrc and have it work?  The docs say that in order for that to work, it must be done "before switching on syntax or filetype recognition".  But if syntax is turned on here, by the time the  "set go+=M" in his .vimrc is encountered it will be too late, right?

Indeed, that is the case (I tried it).  If you put "syntax on" in the system vimrc, then the user cannot use "set go+=M".   I think this is a good reason to remove "syntax on" from the proposal.  If it's left in, you might as well just eliminate "M" as one of the guioptions, because it's totally unusable unless it goes in the local machine's system vimrc, which many users will not be able to change, or will not want to tweak it every time they build a new Vim.

If "syntax on" is in the system vimrc as proposed, then I can't seem to find any way *at all* to disable the loading of the system menu.vim (short of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)

Not only that, but the variables in menu.vim intended to be settable by the user to stop certain segments from loading, i.e., 

let did_install_default_menus = 1

let no_buffers_menu =1

let did_install_syntax_menu = 1

... have no effect in the user's vimrc because menu.vim is already loaded by the system vimrc's "syntax on".

Please, please, remove "syntax on" from the proposal.  There is no way for the user to undo its side-effects.

-Manny

Hi, 

After having read your argument through, I’m still for ‘syntax on’.

After all, the problem boils down to this: How many GUI users do they actually set go=+M?

My bet is that the number is nearly zero.

If our system menu were of such less importance that one could kill it at will, it would not be worth being called “the system menu.”

Really?  One could make the same argument about "the system vimrc", and it would be just as unpersusasive.

&go+=M exists for a reason.  So do "did_install_default_menus", "no_buffers_menu", and "did_install_syntax_menu".

-Many

[Manuel Ortega]

On Wed, Jul 27, 2016 at 10:43 AM, Gary Johnson <gary...@spocom.com> wrote:

On 2016-07-27, Manuel Ortega wrote:

> If "syntax on" is in the system vimrc as proposed, then I can't seem to find
> any way *at all* to disable the loading of the system menu.vim (short of
> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)

How about "sudo rm /usr/share/vim/vimrc"?

That falls under "unacceptable hacks", since it needs to be done every time a fresh vim is installed. 

Another, less drastic way would be to create a file,
~/.vim/ftdetect/guioptions.vim, containing this:

    set guioptions+=M

This is clever.  A trick like this should be added to the documentation (not for my situation, but as a general way of beating a system-vimrc to the punch).  ":helpgrep ftdetect" provides no hint as to why this would work.  I assume that whatever is in ~/.vim/ftdetect is loaded before a system vimrc, but ":help initialize" doesn't say anything about this AFAICT.

As hacks go, it's not as bad as the others.

-Manny

[Manuel Ortega]

I would have no problem with "syntax on" going in a system vimrc if it didn't have unfixable side-effects.

Perhaps it's possible for Bram to change the behavior of "syntax on" so that it doesn't cause menu.vim to be loaded.  Same for "filetype on".

Or perhaps it's possible for Bram to change them so that menu.vim isn't loaded until after the user's vimrc is loaded.  Then the user could at least set the "did_install_*" variables.

-Manny

[Manuel Ortega]

On Wed, Jul 27, 2016 at 11:40 AM, Manuel Ortega <manny...@gmail.com> wrote:

I agree that "syntax on" and "filetype on" (maybe even "filetype plugin
indent on") are pretty core features that should probably be enabled by
default, as nearly everyone will use them.

 

However, I disagree that this should come at the expense of being able
to set up specific options. Anything done in the default settings should
be modifiable by the user, and it looks like in this situation that is
not possible, if the default settings are always sourced.

I would have no problem with "syntax on" going in a system vimrc if it didn't have unfixable side-effects.

Perhaps it's possible for Bram to change the behavior of "syntax on" so that it doesn't cause menu.vim to be loaded.  Same for "filetype on".

Or perhaps it's possible for Bram to change them so that menu.vim isn't loaded until after the user's vimrc is loaded.  Then the user could at least set the "did_install_*" variables.

-Manny

What if "syntax on" and "filetype plugin indent on" were moved into the autocmd group "vimStartup" that the proposed system vimrc defines, under VimEnter autocmds:

au VimEnter * syntax on

au VimEnter * filetype plugin on

This way, everyone who wants them still gets them, and &go+=M still works without modification.  As an added bonus, both of the "ons" can be prevented from ever happening using the same "au!" line that kills the others in that group.

-Manny

[Gary Johnson]

On 2016-07-27, Manuel Ortega wrote:

> What if "syntax on" and "filetype plugin indent on" were moved into the autocmd
> group "vimStartup" that the proposed system vimrc defines, under VimEnter
> autocmds:
>
> au VimEnter * syntax on
> au VimEnter * filetype plugin on
>
> This way, everyone who wants them still gets them, and &go+=M still works
> without modification.  As an added bonus, both of the "ons" can be prevented
> from ever happening using the same "au!" line that kills the others in that
> group.

From ":help VimEnter", the VimEnter event occurs 'After doing all
the startup stuff, including loading .vimrc files, executing the
"-c cmd" arguments, creating all windows and loading the buffers in
them.'

Enabling filetype detection after buffers are loaded is too late.

I suppose you do that and add something like this:

au VimEnter * bufdo filetype detect

I haven't thought that all the way through.

Regards,
Gary

[Manuel Ortega]

On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson <gary...@spocom.com> wrote:

On 2016-07-27, Manuel Ortega wrote:

> What if "syntax on" and "filetype plugin indent on" were moved into the autocmd
> group "vimStartup" that the proposed system vimrc defines, under VimEnter
> autocmds:
>
> au VimEnter * syntax on
> au VimEnter * filetype plugin on
>
> This way, everyone who wants them still gets them, and &go+=M still works
> without modification.  As an added bonus, both of the "ons" can be prevented
> from ever happening using the same "au!" line that kills the others in that
> group.

From ":help VimEnter", the VimEnter event occurs 'After doing all
the startup stuff, including loading .vimrc files, executing the
"-c cmd" arguments, creating all windows and loading the buffers in
them.'

Enabling filetype detection after buffers are loaded is too late.

 

Filetype *detection* is on by default in Vim.  It's not being "turned on" by "filetype plugin indent on".  So what you say will be too late is not too late. 

Now maybe filetype *plugins* need to be loaded before the buffer is loaded, but I kind of doubt it.  They usually just set options and maps.  If I am wrong, then this idea of mine will indeed not work.

-Manny

[Kazunobu Kuriyama]

It may be true that setting go+=M will reduce memory usage and make startup faster.  But I would say the benefit gained by doing that is quite marginal.

A large amount of memory is to be allocated for the menu, the toolbar, the scrollbar and the icon images in gvim and X11 even if they are to be hidden by guioptions such as cM.

And even if those widgets and images are known in advance not to be shown on the screen, a sequence of fairly convoluted calculations for widget geometry is to be done before gvim actually appears on the screen.

Hence, in comparison with those heavy tasks, what is gained by go+=M is negligible. 

I don't understand why go+=M is so important for some people.

-Manny

[Tony Mechelynck]

That ftdetect/guioptions.vim would, with current Vim, be sourced from
$VIMRUNTIME/filetype.vim (at current line 2730, near the end), i.e.
only _after_ filetype detection has been set, which is too late for
clearing menus, unless you first set ":filetype off". But then you
would have to run ":filetype on" afterwards _only_ if it was
originally on.

Best regards,
Tony.

[Gary Johnson]

On 2016-07-27, Manuel Ortega wrote:

> On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson wrote:
>
> On 2016-07-27, Manuel Ortega wrote:
>
> > What if "syntax on" and "filetype plugin indent on" were moved into the
> autocmd
> > group "vimStartup" that the proposed system vimrc defines, under VimEnter
> > autocmds:
> >
> > au VimEnter * syntax on
> > au VimEnter * filetype plugin on
> >
> > This way, everyone who wants them still gets them, and &go+=M still works
> > without modification.  As an added bonus, both of the "ons" can be
> prevented
> > from ever happening using the same "au!" line that kills the others in
> that
> > group.
>
> From ":help VimEnter", the VimEnter event occurs 'After doing all
> the startup stuff, including loading .vimrc files, executing the
> "-c cmd" arguments, creating all windows and loading the buffers in
> them.'
>
> Enabling filetype detection after buffers are loaded is too late.
>
>  
> Filetype *detection* is on by default in Vim.  It's not being "turned on" by
> "filetype plugin indent on".  So what you say will be too late is not too
> late. 

What makes you think filetype detection is on by default? That's
not what I observe.

$ vim -N -u /dev/null hello.c
:set ft?
filetype=

It is turned on by "filetype [args] on" and by "syntax on".

Regards,
Gary

[Gary Johnson]

On 2016-07-27, Tony Mechelynck wrote:

Apparently that's not true: it's not too late.

Here are the initial lines from :scriptnames:

1: ~/.vimrc
2: ~/.vim/filetype.vim
3: /usr/local/share/vim/vim74/filetype.vim
4: ~/.vim/ftdetect/csv.vim
5: ~/.vim/ftdetect/mediawiki.vim
6: /usr/local/share/vim/vim74/menu.vim
7: /usr/local/share/vim/vim74/autoload/paste.vim
8: /usr/local/share/vim/vim74/ftplugin.vim
9: /usr/local/share/vim/vim74/indent.vim
10: /usr/local/share/vim/vim74/syntax/manual.vim
11: /usr/local/share/vim/vim74/syntax/synload.vim
12: /usr/local/share/vim/vim74/syntax/syncolor.vim

You can see that the files in ~/.vim/ftdetect are sourced before
menu.vim, and in fact are sourced before the decision to source
menu.vim is made. I verified that putting "set guioptions+=M" into
~/.vim/ftdetect/guioptions.vim would work before posting that
solution.

Regards,
Gary

[Tony Mechelynck]

Indeed: filetype detection is turned on by the vimrc_example.vim, but
it is neither the 'compatible' nor the 'nocompatible' default in the
absence of startup scripts (i.e. neither "vim -u NONE" nor "vim -u
NONE -N" have it. Even "vim -u NORC -N" i.e., no vimrc but with global
plugins and 'nocompatible' doesn't set it.)

To get a reproducible setup with filetype detection, you might want to
do something like

vim -u /usr/local/share/vim/vim74/vimrc_example.vim

(no need to use -N in this case because the vimrc_example.vim sets it.)


Best regards,
Tony.

[Tony Mechelynck]

Oops, you're right, it is just in time, but barely.

Best regards,
Tony.

[Manuel Ortega]

Because all the files I tested it with had modelines and like an idiot I forgot about that. 

-Manny

[Manuel Ortega]

Perhaps another way to fix this would be if the user could have a ~/.vim/menu.vim that is treated like ~/.vim/filetype.vim is treated.  I.e., that Vim will load the ~/.vim/menu.vim before it loads $VIMRUNTIME/menu.vim.  That way, a user could in his own ~/.vim/menu.vim set some variables that will cause most or all of the $VIMRUNTIME/menu.vim to be skipped.  No need for &go+=M.

-Manny

[Manuel Ortega]

On Wed, Jul 27, 2016 at 1:31 PM, Kazunobu Kuriyama <kazunobu...@gmail.com> wrote:

It may be true that setting go+=M will reduce memory usage and make startup faster.  But I would say the benefit gained by doing that is quite marginal.

It makes a noticeable difference to me.  That's part of why I do it.

 

Hence, in comparison with those heavy tasks, what is gained by go+=M is negligible.

That's not the only reason someone would want to disable the system menus.  Some users just don't want to stare at all that garbage.  It's the *same* justification for the existence of *tons* of other options.

I disable the system menu.vim so that I can source my own custom version that's very bare-bones.  It doesn't cause a noticeable speedup and my screen is uncluttered.  Thus the gain by having go+=M is not negligible.

 

I don't understand why go+=M is so important for some people.

I don't understand why suddenly having a system vimrc after years with none is so important for some people.  Nor do I understand why, if we're going to have one, some people are so desperate that "syntax on" and "filetype blah" be in it.  Is it that important to be able to delete one or two lines that are proably already in your vimrc?

-Manny

[Bram Moolenaar]

Gary Johnson wrote:

> [...]
>
> Not all of those would be my preference, but they seem reasonable,
> and as long as all of that is in a file and the compile-time
> defaults aren't changed, I'm fine with it.
>
> I was surprised by this:
>
> > " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
> > " let &guioptions = substitute(&guioptions, "t", "", "g")
>
> Why substitute() instead of just -=?
>
> set guioptions-=t

Yeah, and why is it commented out? Actually, why don't we make this the
default? I don't think anybody on MS-Windows wants tear-off menus,
unless you know them from Unix perhaps.

--
ROBIN: (warily) And if you get a question wrong?
ARTHUR: You are cast into the Gorge of Eternal Peril.
ROBIN: Oh ... wacho!
"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 ///

[Bram Moolenaar]

Thanks for mentioning this.

I don't think the solution is to not enable syntax highlighting, but
do this in another way. But how?

The trick to do something in an ftdetect script smells like a hack.

Perhaps part of the defaults can be set before loading the .vimrc, so
that they can be overruled, and others can be done after loading the
.vimrc, so that they can be disabled.

Could also move loading menu.vim out of filetype.vim, but it's hard to
predict what side effects this has. E.g. if someone enables filetype
detection and then deletes a menu. That would break.


Another solution: When there is a .vimrc, then don't load startup.vim.
Rely on the user already have his preferences in the .vimrc.
Thus only apply these better defaults when the user doesn't have his own
settings. Ah, I see Ben also had this idea.

The more I think about it, the more this seems like a good solution:
- If the user has a .vimrc, use that.
- If there is no .vimrc, use the default .vimrc.
- When a new user creates a .vimrc, he can source the default one or
copy it. It's possible to do settings before this, such as adding 'M'
to 'guioptions'.

That way anybody which already has a .vimrc isn't bothered by different
defaults. 100% backwards compatible.

New users will get better defaults. When using Vim on a new system it
also has better defaults.

Only those who really want the Vi defaults or the Vim 7 defaults would
need to create a .vimrc and set 'compatible' or 'nocompatible'.

There is some confusion for users who create their .vimrc for the
first time and don't know about the default vimrc. That can be
documented and once discovered it's easy to fix.


--
Sorry, no fortune today.

[Tony Mechelynck]

On Wed, Jul 27, 2016 at 9:09 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Gary Johnson wrote:
>
>> [...]
>>
>> Not all of those would be my preference, but they seem reasonable,
>> and as long as all of that is in a file and the compile-time
>> defaults aren't changed, I'm fine with it.
>>
>> I was surprised by this:
>>
>> > " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
>> > " let &guioptions = substitute(&guioptions, "t", "", "g")
>>
>> Why substitute() instead of just -=?
>>
>> set guioptions-=t
>
> Yeah, and why is it commented out? Actually, why don't we make this the
> default? I don't think anybody on MS-Windows wants tear-off menus,
> unless you know them from Unix perhaps.
>

Well, when I came to Vim I was still on Windows most of the time, and
there I discovered that Vim had that novelty of tear-off menus. So I
used them occasionally. Still now I have the t flag as part of my
'guioptions' (it is part of the default but I set it from scratch,

if has('gui_running')
set guioptions=cgimrLtTp
" ...
endif

) so I wouldn't be annoyed by a change in defaults: I would still have
them. I suppose other people might bitterly miss them though.

Bram, let me point out that with go+=t you _can_ tear off the menus,
you don't _have_ to. If you don't, there is a thin dashed line at the
top of them (which IMHO is no great trouble) in GUIs which support
them, that's all. So I would venture that go+=t would be less of a
bother to people not using tear-off menus, or to most of them, than
go-=t to people using them constantly (and setting their 'guioptions'
by += and -=, relying on the default to set tearoffs).

BTW, the help says tearoff menus are supported on "Win32, GTK and
Motif". Not on Mac? (I know MacVim is a bit of a fork though, so maybe
this question is off-topic for this group.)


Best regards,
Tony.

[Martin Lundberg]

On Tuesday, July 26, 2016 at 11:18:01 PM UTC+2, Bram Moolenaar wrote:
> " Don't use Ex mode, use Q for formatting
> map Q gq

What's the reason for doing this change when the new mapping has just as much key presses? For me it actually feels like it's slower than gq since I need to involve and move both hands.

I can see in the help for gq that Q actually did gq before which could be a reason to change it back but I guess there was a reason for changing it to gq too?

[Bram Moolenaar]

It's an old alias for formatting. "Q" was made Posix compatible at some
point to make it pass some tests.

I don't see Q as two key strokes, I have two fingers that I can use at
the same time.

--
BEDEVERE: How do you know so much about swallows?
ARTHUR: Well you have to know these things when you're a king, you know.

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

[Nikolay Aleksandrovich Pavlov]

2016-07-28 16:58 GMT+03:00 Bram Moolenaar <Br...@moolenaar.net>:
>
> Martin Lundberg wrote:
>
>> On Tuesday, July 26, 2016 at 11:18:01 PM UTC+2, Bram Moolenaar wrote:
>> > " Don't use Ex mode, use Q for formatting
>> > map Q gq
>>
>> What's the reason for doing this change when the new mapping has just
>> as much key presses? For me it actually feels like it's slower than gq
>> since I need to involve and move both hands.
>>
>> I can see in the help for gq that Q actually did gq before which could
>> be a reason to change it back but I guess there was a reason for
>> changing it to gq too?
>
> It's an old alias for formatting. "Q" was made Posix compatible at some
> point to make it pass some tests.
>
> I don't see Q as two key strokes, I have two fingers that I can use at
> the same time.

You can’t. “At the same time” may mean both “<q> pressed slightly
after <S-” and “<q> pressed slightly before <S-”, but you may only
press <q> after <S- to get `Q` and not the other way around. `gq` here
is in par with `Q`: `g` and `q` use different fingers and they need to
be pressed in specific sequence as well. `Q` may actually be worse if
you are trying to press this as fast as possible: you must release <S-
after pressing <q>, but it does not matter when you release <g> and
<q>, only when you press them matters.

Also depends on keyboard and layout: dvorak has <g> and <q> on
different hands, while <q> and <S- are on the same hand (right shift
is harder to use on my keyboard because it has <\> before it which is
not uncommon, so I tend to avoid it, mostly using for `":<>` (us:
`ZQWE`), even A (us: A, one of two keys which match in us and dvorak
layouts) is typed using left shift).

Note: unlike @Martin Lundberg I see that typing `gq` using *two* hands
is *faster* then typing `Q` using *one*. I tried and can type `Q` with
two hands faster then with one, but this makes following text slower
(both because I am not used and because restoring little finger
position from far <S- is slower, whether it matters depends on what
text follows `Q`).

And, if I am not mistaking, requirement to *switch* hands for common
letter combinations is one of the reasons why typing with dvorak is
*faster*. So “involving two hands” could be a word for `Q`, not for me
though due to my far right shift.

>
> --
> BEDEVERE: How do you know so much about swallows?
> ARTHUR: Well you have to know these things when you're a king, you know.
> "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 ///
>

[Bram Moolenaar]

I wrote:

[...]

> Another solution: When there is a .vimrc, then don't load startup.vim.
> Rely on the user already have his preferences in the .vimrc.
> Thus only apply these better defaults when the user doesn't have his own
> settings. Ah, I see Ben also had this idea.
>
> The more I think about it, the more this seems like a good solution:
> - If the user has a .vimrc, use that.
> - If there is no .vimrc, use the default .vimrc.
> - When a new user creates a .vimrc, he can source the default one or
> copy it. It's possible to do settings before this, such as adding 'M'
> to 'guioptions'.
>
> That way anybody which already has a .vimrc isn't bothered by different
> defaults. 100% backwards compatible.
>
> New users will get better defaults. When using Vim on a new system it
> also has better defaults.
>
> Only those who really want the Vi defaults or the Vim 7 defaults would
> need to create a .vimrc and set 'compatible' or 'nocompatible'.
>
> There is some confusion for users who create their .vimrc for the
> first time and don't know about the default vimrc. That can be
> documented and once discovered it's easy to fix.

I haven't heard negative comments for this idea, I'll interpret that as a
positive response. I suppose all of the readers here have a .vimrc,
thus won't be affected by the change. And new users will like (most of)
the new defaults.

I'll send out a patch to do it this way. We can fine tune after that.

--
If an elephant is left tied to a parking meter, the parking fee has to be paid
just as it would for a vehicle.
[real standing law in Florida, United States of America]

[Martin Lundberg]

It's also not just about hitting gq or Shift-Q but being ready for the motion too. I mostyly do gqj, gqip, etc and that is a lot faster when not moving for SHIFT. However as Bram said, people who has a .vimrc won't be affected and if I'm the only one feeling like this then nevermind :)

[Tony Mechelynck]

"map Q gq" has long been part of the vimrc_example.vim. Now it is
moved to defaults.vim which vimrc_example.vim sources. So if you have
a vimrc you won't be affected, even if your own vimrc sources the
vimrc_example.vim, because in that case you already had it and will
keep it. If, like me, you don't like this mapping, you'll do what I've
long been doing: unmap Q at some point after sourcing the
vimrc_example.vim.

This mapping will, in fact, only apply to you if you were relying on
the absence of a vimrc to get a legacy-vi-like 'compatible'
environment. In that case it might be time to set up an empty exrc
file, which IIUC will also leave 'compatible' set, avoid sourcing
defaults.vim, and do nothing else.


Best regards,
Tony.

[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.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)

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

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

[Kevin Lyda]

On Sunday, July 24, 2016 at 2:03:06 PM UTC+1, 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.

So this was unfortunate.

I like the idea of moving forward but kind of bummed how it was done. Specifically:

On Ubuntu the vim8 package has a /etc/vim/vimrc which pulls in a /etc/vim/vimrc.local if it exists. With vim8 "set mouse=a" is the default when a mouse is detected. And that's fine for lots of folks but I'm not a fan so I'd like to disable it system-wide. So I put "set mouse=" in /etc/vim/vimrc.local and I'm good, yes?

No. No I'm not. It seems that /usr/share/vim/vim80/defaults.vim (which was mildly hard to find btw) is sourced after /etc/vim/vimrc and /etc/vim/vimrc.local. This seems unfortunate. And yes, I'm aware per-user .vimrc's are a thing but I'd rather set this system-wide w/o editing the distribution files.

And that was possible with /etc/vim/vimrc.local but now is not. Is this something that could be changed and would it be a vim issue or a vim packaging issue?

Kevin

[Christian Brabandt]

See the discussion in the following issue:
https://github.com/vim/vim/issues/2042


Christian
--
Und die Sonne Homers, siehe! Sie lächelt auch uns.
-- Friedrich Schiller

[Tony Mechelynck]

For me nothing changed. My vimrc used to source the vimrc_example.vim,
it still does, but now vimrc_example.vim just sources the
defaults.vim, which contains what used to be in the vimrc_example.vim.
No sweat.

About system vimrc files, I hate them: in my experience they contain
the misguided and undocumented opinions of some
<s>sysadmin</s><u>BOFH</u> about what is best for me. This is one of
the reasons why I compile my own Vim (so it looks for a system vimrc
at $VIM/vimrc, doesn't find it, and bypasses my distro's system vimrc
at /etc/vimrc). The other reason is that openSUSE's so-called "stable"
version of Vim is unreasonably behind the times (currently 7.4.326).

Best regards,
Tony.

[Bram Moolenaar]

Keven Lyda wrote:

> On Sunday, July 24, 2016 at 2:03:06 PM UTC+1, 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.
>
> So this was unfortunate.

And more than a year ago...

> I like the idea of moving forward but kind of bummed how it was done.
> Specifically:
>
> On Ubuntu the vim8 package has a /etc/vim/vimrc which pulls in a
> /etc/vim/vimrc.local if it exists. With vim8 "set mouse=a" is the
> default when a mouse is detected. And that's fine for lots of folks
> but I'm not a fan so I'd like to disable it system-wide. So I put
> "set mouse=" in /etc/vim/vimrc.local and I'm good, yes?
>
> No. No I'm not. It seems that /usr/share/vim/vim80/defaults.vim (which
> was mildly hard to find btw) is sourced after /etc/vim/vimrc and
> /etc/vim/vimrc.local. This seems unfortunate. And yes, I'm aware
> per-user .vimrc's are a thing but I'd rather set this system-wide w/o
> editing the distribution files.
>
> And that was possible with /etc/vim/vimrc.local but now is not. Is
> this something that could be changed and would it be a vim issue or a
> vim packaging issue?

System-wide Vim initialisation, especialy from a distribution, generally
makes things more complicated. It's like second guessing the Vim
defaults, and then letting the user figure out what happened. The help
will show different values, thus the user is confused.

Ubuntu is quite conservitive in /etc/vim/vimrc, this appears to be
coming from Debian. Lots of comments, what is actually doing something:

runtime! debian.vim

Hmm, this depends on 'runtimepath' which would have to be build into the
executable. If you compile your own Vim this probably doesn't work.

It triggers the load of /usr/share/vim/vim80/debian.vim, which contains
some random settings that the Debian maintainer apparently prefers. It
sets 'history' to 50, even though that's already the default. And turns
on 'ruler', which seems like a random choice.

Then there is:

if has("syntax")
syntax on
endif

OK, so force syntax highlighting onto all users. And before loading
color schemes and setting up your own filetypes...

Oh well, if you compile your own Vim then /etc/vim/vimrc most likely
won't be used.

Realy, the system-wide vimrc was meant to be used for system-specific
settings. E.g. the path of tools, spell files, etc. Not for user
preferences.

--
Friends? I have lots of friends! In fact, I have all episodes ever made.