Re: Question born from pure curiosity...

2016-07-31 16:00 GMT+03:00 Nikolay Aleksandrovich Pavlov <zyx.vim@gmail.com>:
> 2016-07-31 10:31 GMT+03:00 <Meino.Cramer@gmx.de>:
>> Hi,
>>
>> this NOT meant as implicit or explicit critism, complain
>> or what else...
>>
>> Its just interest in vim and driven by curiosity... :)
>>
>> To set an option or feature inside vim one do
>>
>> : set <option>=<value>
>>
>> But why it is
>>
>> :colorscheme <value>
>
> :colorscheme is *not* an option. It is a shortcut to `runtime
> colors/<value>.vim` with some more work (e.g. `doautocmd ColorScheme
> <value>` or dealing with g:colors_name).

I would rather ask why &syntax or &filetype are options: setting them
does similar things as :colorscheme or :compiler (note: this is also
not an option).

>
>>
>> ???
>>
>> Best regards,
>> Meino
>>
>>
>> --
>> --
>> 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.

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

Re: Question born from pure curiosity...

2016-07-31 10:31 GMT+03:00 <Meino.Cramer@gmx.de>:
> Hi,
>
> this NOT meant as implicit or explicit critism, complain
> or what else...
>
> Its just interest in vim and driven by curiosity... :)
>
> To set an option or feature inside vim one do
>
> : set <option>=<value>
>
> But why it is
>
> :colorscheme <value>

:colorscheme is *not* an option. It is a shortcut to `runtime
colors/<value>.vim` with some more work (e.g. `doautocmd ColorScheme
<value>` or dealing with g:colors_name).

>
> ???
>
> Best regards,
> Meino
>
>
> --
> --
> 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.

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

Question born from pure curiosity...

Hi,

this NOT meant as implicit or explicit critism, complain
or what else...

Its just interest in vim and driven by curiosity... :)

To set an option or feature inside vim one do

: set <option>=<value>

But why it is

:colorscheme <value>

???

Best regards,
Meino


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

Re: Compilation fails on Allwinner H3 platform (Orage PI PC)

sycc <sycc90@mail.com> [16-07-30 20:44]:
>
>
> On 07/30/2016 09:54 AM, Meino.Cramer@gmx.de wrote:
> >Hi,
> >
> >I got some problems to comile vim (current patch level) on an Orangs
> >PI PC (Allwinner H3) and Armbian Linux.
> >
> >The make command:
> >./configure --prefix=/usr/local --sysconfdir=/etc/vim
> >--with-features=huge --enable-luainterp=yes --enable-pythoninterp &&
> >make
> >
> >The compilation itsself does not prodyce any error.
> >
> >The linking fails:
> >
> >...
> >
> >"omp" looks like "Open Multi Processing"...but I cannot find the
> >according lib ... maybe I am looking for the wrong name of it?
> >
> >How can I fix that?
> >
> >Thank you very much in advance for any help!
> >Best regards,
> >mcc
>
> Could it be that gcc is missing the -fopenmp flag?
>
> --
> --
> 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.
>

Yes, it misses that...
I think, the platform does not support that (the H3 CPU has four cores
though) since the "official armbian distro build" only has a gcc
without that feature.

Intrestingly vim's configure recognized that (no openmp
available....yes), but later make seems to forget that
fact...

On the other hand: Armbian comes with an (old) version of vim...
so someone must have found a way.
Unfortunately it is not me...

Best
Meino


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

Re: Compilation fails on Allwinner H3 platform (Orage PI PC)

On 07/30/2016 09:54 AM, Meino.Cramer@gmx.de wrote:
> Hi,
>
> I got some problems to comile vim (current patch level) on an Orangs
> PI PC (Allwinner H3) and Armbian Linux.
>
> The make command:
> ./configure --prefix=/usr/local --sysconfdir=/etc/vim --with-features=huge --enable-luainterp=yes --enable-pythoninterp && make
>
> The compilation itsself does not prodyce any error.
>
> The linking fails:
>
> ...
>
> "omp" looks like "Open Multi Processing"...but I cannot find the
> according lib ... maybe I am looking for the wrong name of it?
>
> How can I fix that?
>
> Thank you very much in advance for any help!
> Best regards,
> mcc

Could it be that gcc is missing the -fopenmp flag?

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

Compilation fails on Allwinner H3 platform (Orage PI PC)

Hi,

I got some problems to comile vim (current patch level) on an Orangs
PI PC (Allwinner H3) and Armbian Linux.

The make command:
./configure --prefix=/usr/local --sysconfdir=/etc/vim --with-features=huge --enable-luainterp=yes --enable-pythoninterp && make

The compilation itsself does not prodyce any error.

The linking fails:


gcc -L/usr/local/lib -Wl,--as-needed -o vim objects/arabic.o objects/buffer.o objects/blowfish.o objects/charset.o objects/crypt.o objects/crypt_zip.o objects/dict.o objects/diff.o objects/digraph.o objects/edit.o objects/eval.o objects/evalfunc.o objects/ex_cmds.o objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o objects/ex_getln.o objects/farsi.o objects/fileio.o objects/fold.o objects/getchar.o objects/hardcopy.o objects/hashtab.o objects/if_cscope.o objects/if_xcmdsrv.o objects/list.o objects/mark.o objects/memline.o objects/menu.o objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/normal.o objects/ops.o objects/option.o objects/os_unix.o objects/pathdef.o objects/popupmnu.o objects/quickfix.o objects/regexp.o objects/screen.o objects/search.o objects/sha256.o objects/spell.o objects/spellfile.o objects/syntax.o objects/tag.o objects/term.o objects/ui.o objects/undo.o objects/userfunc.o objects/version.o objects/window.o objects/gui.o objects/gui_athena.o objects/gui_x11.o objects/pty.o objects/gui_beval.o objects/gui_at_sb.o objects/gui_at_fs.o objects/netbeans.o objects/channel.o objects/json.o objects/main.o objects/memfile.o objects/message.o -lXaw -lXmu -lXext -lXt -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -ldl -lm -ltinfo -lnsl -ldl
objects/edit.o: In function `change_indent':
edit.c:(.text+0x88d2): undefined reference to `GOMP_parallel'
objects/edit.o: In function `change_indent._loopfn.0':
edit.c:(.text+0xd9ea): undefined reference to `omp_get_num_threads'
edit.c:(.text+0xd9f0): undefined reference to `omp_get_thread_num'
objects/fileio.o: In function `readfile':
fileio.c:(.text+0x59d0): undefined reference to `GOMP_parallel'
objects/fileio.o: In function `readfile._loopfn.0':
fileio.c:(.text+0xac08): undefined reference to `omp_get_num_threads'
fileio.c:(.text+0xac0e): undefined reference to `omp_get_thread_num'
objects/hardcopy.o: In function `prt_write_real':
hardcopy.c:(.text+0x112a): undefined reference to `GOMP_parallel'
objects/hardcopy.o: In function `prt_write_real._loopfn.0':
hardcopy.c:(.text+0x475e): undefined reference to `omp_get_num_threads'
hardcopy.c:(.text+0x4764): undefined reference to `omp_get_thread_num'
objects/misc1.o: In function `set_indent':
misc1.c:(.text+0x292c): undefined reference to `GOMP_parallel'
objects/misc1.o: In function `ins_char_bytes':
misc1.c:(.text+0x301e): undefined reference to `GOMP_parallel'
objects/misc1.o: In function `get_cmd_output':
misc1.c:(.text+0xa9c4): undefined reference to `GOMP_parallel'
objects/misc1.o: In function `set_indent._loopfn.0':
misc1.c:(.text+0xba62): undefined reference to `omp_get_num_threads'
misc1.c:(.text+0xba68): undefined reference to `omp_get_thread_num'
objects/misc1.o: In function `ins_char_bytes._loopfn.1':
misc1.c:(.text+0xbbda): undefined reference to `omp_get_num_threads'
misc1.c:(.text+0xbbe0): undefined reference to `omp_get_thread_num'
objects/misc1.o: In function `get_cmd_output._loopfn.2':
misc1.c:(.text+0xbea6): undefined reference to `omp_get_num_threads'
misc1.c:(.text+0xbeac): undefined reference to `omp_get_thread_num'
objects/netbeans.o: In function `nb_get_buf':
netbeans.c:(.text+0x2a2): undefined reference to `GOMP_parallel'
objects/netbeans.o: In function `nb_get_buf._loopfn.0':
netbeans.c:(.text+0x3f5a): undefined reference to `omp_get_num_threads'
netbeans.c:(.text+0x3f60): undefined reference to `omp_get_thread_num'
objects/buffer.o: In function `build_stl_str_hl':
buffer.c:(.text+0x3eb8): undefined reference to `GOMP_parallel'
objects/buffer.o: In function `build_stl_str_hl._loopfn.0':
buffer.c:(.text+0x82b0): undefined reference to `omp_get_num_threads'
buffer.c:(.text+0x82b6): undefined reference to `omp_get_thread_num'
objects/ex_cmds.o: In function `ex_retab':
ex_cmds.c:(.text+0x2358): undefined reference to `GOMP_parallel'
objects/ex_cmds.o: In function `ex_retab._loopfn.0':
ex_cmds.c:(.text+0x9cb6): undefined reference to `omp_get_num_threads'
ex_cmds.c:(.text+0x9cbc): undefined reference to `omp_get_thread_num'
objects/ex_cmds2.o: In function `do_source':
ex_cmds2.c:(.text+0x51ba): undefined reference to `GOMP_parallel'
objects/ex_cmds2.o: In function `do_source._loopfn.0':
ex_cmds2.c:(.text+0x5d96): undefined reference to `omp_get_num_threads'
ex_cmds2.c:(.text+0x5d9c): undefined reference to `omp_get_thread_num'
objects/ex_getln.o: In function `init_history':
ex_getln.c:(.text+0x4a22): undefined reference to `GOMP_parallel'
ex_getln.c:(.text+0x4bfe): undefined reference to `GOMP_parallel'
objects/ex_getln.o: In function `init_history._loopfn.0':
ex_getln.c:(.text+0x9d72): undefined reference to `omp_get_num_threads'
ex_getln.c:(.text+0x9d78): undefined reference to `omp_get_thread_num'
objects/ex_getln.o: In function `init_history._loopfn.1':
ex_getln.c:(.text+0x9efe): undefined reference to `omp_get_num_threads'
ex_getln.c:(.text+0x9f04): undefined reference to `omp_get_thread_num'
objects/farsi.o: In function `farsi_f9':
farsi.c:(.text+0x2ac6): undefined reference to `GOMP_parallel'
objects/farsi.o: In function `farsi_f9._loopfn.0':
farsi.c:(.text+0x32a6): undefined reference to `omp_get_num_threads'
farsi.c:(.text+0x32ac): undefined reference to `omp_get_thread_num'
objects/fold.o: In function `setManualFoldWin':
fold.c:(.text+0x2bc8): undefined reference to `GOMP_parallel'
objects/fold.o: In function `foldCreate':
fold.c:(.text+0x35b4): undefined reference to `GOMP_parallel'
objects/fold.o: In function `setManualFoldWin._loopfn.0':
fold.c:(.text+0x414e): undefined reference to `omp_get_num_threads'
fold.c:(.text+0x4154): undefined reference to `omp_get_thread_num'
objects/fold.o: In function `foldCreate._loopfn.1':
fold.c:(.text+0x421e): undefined reference to `omp_get_num_threads'
fold.c:(.text+0x4224): undefined reference to `omp_get_thread_num'
objects/if_cscope.o: In function `cs_find_common':
if_cscope.c:(.text+0x1fdc): undefined reference to `GOMP_parallel'
objects/if_cscope.o: In function `cs_find_common._loopfn.0':
if_cscope.c:(.text+0x357e): undefined reference to `omp_get_num_threads'
if_cscope.c:(.text+0x3584): undefined reference to `omp_get_thread_num'
objects/memline.o: In function `ml_append_int.part.6':
memline.c:(.text+0x1ba2): undefined reference to `GOMP_parallel'
memline.c:(.text+0x1cda): undefined reference to `GOMP_parallel'
objects/memline.o: In function `ml_flush_line':
memline.c:(.text+0x2f70): undefined reference to `GOMP_parallel'
objects/memline.o: In function `ml_recover':
memline.c:(.text+0x4c16): undefined reference to `GOMP_parallel'
objects/memline.o: In function `ml_append_int.part.6._loopfn.0':
memline.c:(.text+0x645a): undefined reference to `omp_get_num_threads'
memline.c:(.text+0x6460): undefined reference to `omp_get_thread_num'
objects/memline.o: In function `ml_append_int.part.6._loopfn.1':
memline.c:(.text+0x6552): undefined reference to `omp_get_num_threads'
memline.c:(.text+0x6558): undefined reference to `omp_get_thread_num'
objects/memline.o: In function `ml_flush_line._loopfn.2':
memline.c:(.text+0x664c): undefined reference to `omp_get_num_threads'
memline.c:(.text+0x6652): undefined reference to `omp_get_thread_num'
objects/memline.o: In function `ml_recover._loopfn.3':
memline.c:(.text+0x6922): undefined reference to `omp_get_num_threads'
memline.c:(.text+0x6928): undefined reference to `omp_get_thread_num'
objects/misc2.o: In function `coladvance2':
misc2.c:(.text+0x29b6): undefined reference to `GOMP_parallel'
misc2.c:(.text+0x2c76): undefined reference to `GOMP_parallel'
objects/misc2.o: In function `coladvance2._loopfn.0':
misc2.c:(.text+0x513a): undefined reference to `omp_get_num_threads'
misc2.c:(.text+0x5140): undefined reference to `omp_get_thread_num'
objects/misc2.o: In function `coladvance2._loopfn.1':
misc2.c:(.text+0x5406): undefined reference to `omp_get_num_threads'
misc2.c:(.text+0x540c): undefined reference to `omp_get_thread_num'
objects/ops.o: In function `str_to_reg':
ops.c:(.text+0xbca): undefined reference to `GOMP_parallel'
objects/ops.o: In function `str_to_reg._loopfn.0':
ops.c:(.text+0xaf12): undefined reference to `omp_get_num_threads'
ops.c:(.text+0xaf18): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `copy_text_attr':
screen.c:(.text+0x25a): undefined reference to `GOMP_parallel'
objects/screen.o: In function `win_redr_custom.part.15':
screen.c:(.text+0x418e): undefined reference to `GOMP_parallel'
screen.c:(.text+0x4202): undefined reference to `GOMP_parallel'
objects/screen.o: In function `draw_tabline':
screen.c:(.text+0x7e38): undefined reference to `GOMP_parallel'
screen.c:(.text+0x812a): undefined reference to `GOMP_parallel'
objects/screen.o:screen.c:(.text+0xdfa2): more undefined references to `GOMP_parallel' follow
objects/screen.o: In function `copy_text_attr._loopfn.0':
screen.c:(.text+0x114d6): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x114dc): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_redr_custom.part.15._loopfn.1':
screen.c:(.text+0x116de): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x116e4): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_redr_custom.part.15._loopfn.2':
screen.c:(.text+0x118e6): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x118ec): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `draw_tabline._loopfn.3':
screen.c:(.text+0x11aee): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x11af4): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `draw_tabline._loopfn.4':
screen.c:(.text+0x11cf6): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x11cfc): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_update._loopfn.5':
screen.c:(.text+0x11f2e): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x11f34): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_update._loopfn.6':
screen.c:(.text+0x12136): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x1213c): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_update._loopfn.7':
screen.c:(.text+0x1233e): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x12344): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_update._loopfn.8':
screen.c:(.text+0x12546): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x1254c): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_update._loopfn.9':
screen.c:(.text+0x1274e): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x12754): undefined reference to `omp_get_thread_num'
objects/screen.o: In function `win_update._loopfn.10':
screen.c:(.text+0x12956): undefined reference to `omp_get_num_threads'
screen.c:(.text+0x1295c): undefined reference to `omp_get_thread_num'
objects/search.o: In function `find_pattern_in_path':
search.c:(.text+0x73f4): undefined reference to `GOMP_parallel'
search.c:(.text+0x777e): undefined reference to `GOMP_parallel'
objects/search.o: In function `find_pattern_in_path._loopfn.0':
search.c:(.text+0x852e): undefined reference to `omp_get_num_threads'
search.c:(.text+0x8534): undefined reference to `omp_get_thread_num'
objects/search.o: In function `find_pattern_in_path._loopfn.1':
search.c:(.text+0x85fa): undefined reference to `omp_get_num_threads'
search.c:(.text+0x8600): undefined reference to `omp_get_thread_num'
objects/sha256.o: In function `sha2_seed':
sha256.c:(.text+0x268a): undefined reference to `GOMP_parallel'
sha256.c:(.text+0x26d0): undefined reference to `GOMP_parallel'
objects/sha256.o: In function `sha2_seed._loopfn.0':
sha256.c:(.text+0x29b2): undefined reference to `omp_get_num_threads'
sha256.c:(.text+0x29b8): undefined reference to `omp_get_thread_num'
objects/sha256.o: In function `sha2_seed._loopfn.1':
sha256.c:(.text+0x2b2a): undefined reference to `omp_get_num_threads'
sha256.c:(.text+0x2b30): undefined reference to `omp_get_thread_num'
objects/syntax.o: In function `syntax_start':
syntax.c:(.text+0x89a2): undefined reference to `GOMP_parallel'
objects/syntax.o: In function `syntax_start._loopfn.0':
syntax.c:(.text+0xc6ee): undefined reference to `omp_get_num_threads'
syntax.c:(.text+0xc6f4): undefined reference to `omp_get_thread_num'
objects/gui_at_fs.o: In function `SFpathSliderMovedCallback':
gui_at_fs.c:(.text+0xd3a): undefined reference to `GOMP_parallel'
objects/gui_at_fs.o: In function `SFupdatePath':
gui_at_fs.c:(.text+0x1a7a): undefined reference to `GOMP_parallel'
gui_at_fs.c:(.text+0x1f40): undefined reference to `GOMP_parallel'
objects/gui_at_fs.o: In function `SFupdatePath._loopfn.1':
gui_at_fs.c:(.text+0x3b8a): undefined reference to `omp_get_num_threads'
gui_at_fs.c:(.text+0x3b90): undefined reference to `omp_get_thread_num'
objects/gui_at_fs.o: In function `SFupdatePath._loopfn.2':
gui_at_fs.c:(.text+0x3caa): undefined reference to `omp_get_num_threads'
gui_at_fs.c:(.text+0x3cb0): undefined reference to `omp_get_thread_num'
objects/channel.o: In function `channel_get_all':
channel.c:(.text+0x1602): undefined reference to `GOMP_parallel'
objects/channel.o: In function `write_buf_line':
channel.c:(.text+0x1ea2): undefined reference to `GOMP_parallel'
objects/channel.o: In function `channel_get_all._loopfn.0':
channel.c:(.text+0x53fa): undefined reference to `omp_get_num_threads'
channel.c:(.text+0x5400): undefined reference to `omp_get_thread_num'
objects/channel.o: In function `write_buf_line._loopfn.1':
channel.c:(.text+0x550e): undefined reference to `omp_get_num_threads'
channel.c:(.text+0x5514): undefined reference to `omp_get_thread_num'
collect2: error: ld returned 1 exit status
link.sh: Linking failed
Makefile:1856: recipe for target 'vim' failed
make[1]: *** [vim] Error 1
make[1]: Leaving directory '/home/meino/CVS-Archive/VIM/vim.build/vim/src'
Makefile:26: recipe for target 'first' failed
make: *** [first] Error 2
[1] 12168 exit 2 ./build.sh


"omp" looks like "Open Multi Processing"...but I cannot find the
according lib ... maybe I am looking for the wrong name of it?

How can I fix that?

Thank you very much in advance for any help!
Best regards,
mcc


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

Re: vim.org STILL fails to redirect to www.vim.org

On Fri, Jul 29, 2016 at 10:16 PM, Andrew Pennebaker
<andrew.pennebaker@gmail.com> wrote:
> For the love of Web accessibility, please do whatever is necessary to have vim.org redirect to www.vim.org. Broken domains suck.
>

For me it does. But it may be because Mozilla browsers (SeaMonkey and,
I think, Firefox) try pefixing www. by default when the raw domain
name isn't found.

See the following preferences in about:config (which, in SeaMonkey,
have default values as shown):

browser.fixup.alternate.enabled
true
browser.fixup.alternate.prefix
www.
browser.fixup.alternate.suffix
.com

Non-Mozilla browsers may or may not have a similar mechanism,
depending on the browser.


Best regards,
Tony.

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

Re: vim.org STILL fails to redirect to www.vim.org

On Fr, 29 Jul 2016, Andrew Pennebaker wrote:

> For the love of Web accessibility, please do whatever is necessary to
> have vim.org redirect to www.vim.org. Broken domains suck.

That has been discussed several times. Quick solution: always use www

Best,
Christian
--
Ich will euch mein Erfolgsrezept verraten: Meine ganze Kraft ist
nichts als Ausdauer.
-- Louis Pasteur

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

vim.org STILL fails to redirect to www.vim.org

For the love of Web accessibility, please do whatever is necessary to have vim.org redirect to www.vim.org. Broken domains suck.

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

vim.exe: shortens Command Prompt window

When I use Vim in cmd.exe, Vim shrinks the Command Prompt window by half until I quit Vim.

Configuration:

https://github.com/mcandre/dotfiles/blob/master/.vimrc

System:

* Vim 7.4 via Chocolatey
* Windows 10 Professional x86_64

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

Re: Argument complaint

On Tuesday, 17 May, 2016 at 16:40:10 BST, h_east wrote:
>I have the measures of the following commands.
> :rewind
> :first
> :last

Your patch is working for me in this use case, thanks :)

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

Re: Changing the defaults with Vim 8

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

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

-- bpb

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

Re: Changing the defaults with Vim 8

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

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

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

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

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

Re: Changing the defaults with Vim 8

On Tue, Jul 26, 2016 at 01:21:56PM +0200, Bram Moolenaar wrote:
>
> Tony Mechelynck wrote:
>
> > On Mon, Jul 25, 2016 at 10:10 PM, Christian Brabandt <cblists@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.
>
> 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
> @@@

Hi Bram, et al.

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

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

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

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

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

Re: Changing the defaults with Vim 8

Tony Mechelynck wrote:

> On Mon, Jul 25, 2016 at 10:10 PM, Christian Brabandt <cblists@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.

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!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

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

Re: Changing the defaults with Vim 8

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

I do...


> create a mapping.

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

-tim











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

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 10:00 PM, Bram Moolenaar <Bram@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.

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

Re: Changing the defaults with Vim 8

On 2016-07-26, Tony Mechelynck wrote:
> On Tue, Jul 26, 2016 at 12:10 AM, Tumbler Terrall
> <kingdombound13@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).

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

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

Re: Changing the defaults with Vim 8

On Tue, Jul 26, 2016 at 12:10 AM, Tumbler Terrall
<kingdombound13@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.

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

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 10:10 PM, Christian Brabandt <cblists@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.

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

Re: Changing the defaults with Vim 8

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

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

Re: Changing the defaults with Vim 8

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

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

Re: Changing the defaults with Vim 8

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

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

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 4:39 PM, Ben Fritz <fritzophrenic@gmail.com> 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?
>
> 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.
>

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

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

Re: Changing the defaults with Vim 8

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)

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

Re: Changing the defaults with Vim 8

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.

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

Re: Changing the defaults with Vim 8

On Monday, July 25, 2016 at 8:02:21 AM UTC-5, Tony Mechelynck wrote:
> On Mon, Jul 25, 2016 at 11:00 AM, <romainlafourcade@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.

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

Re: Changing the defaults with Vim 8

On Mon, Jul 25, 2016 at 11:00 AM, <romainlafourcade@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.

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

Re: Changing the defaults with Vim 8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Good guess. :-) I have:

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

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

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

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

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

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

Erik

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

Re: Changing the defaults with Vim 8

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

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

set nocompatible

Just because.

set autoindent

It's smart enough to cover most basic needs.

set backspace=indent,eol,start

Because the default behavior weirds out new users.

set hidden

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

set ruler

Minimal information.

set wildmenu

Makes command-line completion incredibly useful.

syntax on

Syntax highlighting has been an expectation for a long time.

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

Some common issues:

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

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

Re: Changing the defaults with Vim 8

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

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

Re: Changing the defaults with Vim 8

Hi Bram,

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

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

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

Best regards, and… Have fun!
Tony.

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

Re: Changing the defaults with Vim 8

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.

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.