Re: Changing the defaults with Vim 8

Tim Chase wrote:

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

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

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

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

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

OK.

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

Not this then.

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

That works.

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

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

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

First time I hear about this.

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

/// Bram Moolenaar -- Bram@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_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.