Hi Tim and Bram, I react only to the last sentence.
2016-7-25(Mon) 4:43:30 UTC+9 Bram Moolenaar: > Tim Chase wrote: > > > On 2016-07-24 15:02, Bram Moolenaar wrote: > > > What has stopped me from changing this is the unexpected change. > > > Many users will notice that Vim suddenly behaves differently. Some > > > may be upset. The release of Vim 8.0 might be the best point in > > > time to do this. If we do this. > > > > Agreed that 8.0 is a good break-a-little-compatibility-if-needed > > moment compared to a point release. > > > > Though my understanding is that vim behaves differently if invoked as > > "vi" vs. "vim"/"gvim" and if there's a .vimrc vs no .vimrc > > > > So if invoked as "vi" and there's no .vimrc, I'd expect 'compatible' > > behavior with no/minimal breaking changes. However if there's > > indication that the user wants vim-not-vi (either invoking as "vim" > > or having a .vimrc/.gvimrc), then I'd be more open to more > > invasive/incompatible changes. > > > > > If someone wants to start in the old way, the -C flag should be > > > used: vim -C > > > > I'd also include "or invoking as `vi` or having no .vimrc" > > There was a discussion about this long ago. The main reason not to do > this is that many users rename vim to vi. Most Linux systems already > call it vi. There might not even be a vim binary. > > > > What we can probably always do: > > > > > > set backspace=indent,eol,start > > > > +1 here > > > > > set history=50 " keep 50 lines of command line history > > > > at *least* 50 but otherwise +1 > > > > > set ruler " show the cursor position all the time > > > > I'm slightly concerned about things that eat more screen real-estate > > unbidden. Not *greatly* concerned, but at least enough to raise the > > issue. +0 > > > > > set showcmd " display incomplete commands > > > > +1 > > > > > set incsearch " do incremental searching > > > > My only concern here is that some regexps can have pathological > > search time, and searching unbidden (either by hitting enter or by > > using 'incsearch') can hang vim. > > There is a timeout, but only with the +reltime feature. We can have it > depend on that. > > > > " Don't use Ex mode, use Q for formatting > > > map Q gq > > > > I don't object in vim; only mildly concerned regarding vi (would have > > to dredge up a POSIX vi to check whether Q was used). But mostly Q > > is an annoyance to just about everybody I've talked to, good only for > > VimGolf hacks. > > > > > " In many terminal emulators the mouse works just fine, thus > > > enable it. if has('mouse') > > > set mouse=a > > > endif > > > > I don't have much input here as I don't use the mouse with vim (other > > than middle-button pasting content as if I typed it) > > > > > if &t_Co > 2 || has("gui_running") > > > syntax on > > > > It may ruffle some feathers, but again, if it's vim-not-vi, I think > > most users already do something like this; and that those who don't > > prefer to invoke it as vi. > > > > > set hlsearch > > > > The 'hlsearch' annoys me and is the sort of thing I only turn on as > > needed and then promptly turn back off again. Pretty -1 on this one. > > OK. > > > > if has("autocmd") > > > " Enable file type detection. > > > filetype plugin indent on > > > > Might get some detractors, but I don't object here. > > > > > " For all text files set 'textwidth' to 78 characters. > > > autocmd FileType text setlocal textwidth=78 > > > > I'd find this more annoying. I tend to jockey 'tw' based on my > > environment/content. Email gets tw=65, my HTML is usually tw=75, my > > prose is often tw=0, etc. > > Not this then. > > > > autocmd BufReadPost * > > > \ if line("'\"") >= 1 && line("'\"") <= line("$") | > > > \ exe "normal! g`\"" | > > > \ endif > > > > How would this interact with command-line offsets if the file had > > been previously edited? > > > > $ vim +21 file.txt > > That works. > > > I'd also want to ensure it doesn't impact scripts/macros that assume > > files start at the same place. Currently, I can do things like > > > > $ vim *.html > > :argdo /<h\d\>\c/put='below first HTML heading' > > > > and know where things will go. But if the cursor location is > > restored when a buffer is opened, that might drop me in an unexpected > > location. > > > > So I'd vote as a -0 on that one. > > I find it very, very useful to come back where I was in a file the last > time. I never encounter negative effects. > > > As a backwards incompatible change, my biggest want would be that the > > outer-quotation text objects (a" and a') would no longer eat leading > > whitespace. I've never wanted the out-of-box behavior, always > > wanting to change just the string-cum-quotes. > > > > http://vim.1045645.n5.nabble.com/quotation-text-object-consternation-td5725045.html > > > > Or at least an option to control that. > > First time I hear about this. Please refer to the last two lines of `:help iquote`. DOC> i" v_iquote iquote DOC> i' v_i' i' DOC> i` v_i` i` DOC> Like a", a' and a`, but exclude the quotes and DOC> repeating won't extend the Visual selection. DOC> Special case: With a count of 2 the quotes are DOC> included, but no extra white space as with a"/a'/a`. In the current situation, it can be avoided in the following way. c2i" -- Best regards, Hirohito Higashi (a.k.a. h_east) -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.