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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment