Tony Mechelynck wrote:
> On Mon, Dec 10, 2018 at 3:55 PM Peng Yu <pengyu.ut@gmail.com> wrote:
>> Hi,
>>
>> I am wondering how to debug a vim plugin (for example, the following
>> one) in an efficient way.
>>
>> https://github.com/Clavelito/indent-sh.vim/blob/master/indent/sh.vim
>>
>> The main difficulty that I see is that a vim plugin is different from
>> a typical program is that in a typical programming language one can
>> easily isolate a piece of code and insert print statements. But in a
>> vim plugin, since it causes some effects in the code shown in vim, I
>> am not sure how a print statement can help much.
>>
>> Also, in a regular programming language, one can run a function with
>> different parameters, then check its behavior. But a vim plugin is
>> just a whole piece of code, it is not clear how to run a piece of code
>> in an isolated environment to inspect its behavior.
>>
>> Does anybody have any tips on how to debugging vim plugins? Thanks.
>>
>> --
>> Regards,
>> Peng
> Debugging Vim-script language is Dr. Chip's province; he even wrote a
> script to help debug other scripts. You may already check if
> http://www.drchip.org/astronaut/vim/#DECHO helps you, otherwise I'm
> adding Dr. Chip as Cc in case he might have other helpful information
> for you.
>
> Best regards,
> Tony.
>
Hello:
Decho.vim would be my suggestion, too. Decho provides several ways to
help you get your debugging information out; a separate window on the
current tab, a separate tab, via vim's messages facility, and to a
remote vim. The latter provides the most isolation of debugging output
capture from effects on the script's display.
Regards,
Chip Campbell
--
--
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.
Tuesday, January 29, 2019
Sunday, January 27, 2019
Re: CTRL-F Setting
Hi,
2019/1/26 Sat 6:49:01 UTC+9 SteveW wrote:
> I realize this topic is kind of old but I think it is important.
>
> Remapping basic vim functionality (such as Ctrl-F) should NEVER be done by default. At a minimum, mswin.vim should not be setup to be sourced by default (with notes on how to add it if you want the Windows functionality).
>
> Vim is vim - basic functions should not be changed just because you are on Windows.
This discussion is outdated. Have you tried the new installer after 8.0.1232?
Now the installer has a choice whether you want to source mswin.vim or not.
(And it doesn't source mswin.vim by default now.)
Regards,
Ken Takata
--
--
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.
2019/1/26 Sat 6:49:01 UTC+9 SteveW wrote:
> I realize this topic is kind of old but I think it is important.
>
> Remapping basic vim functionality (such as Ctrl-F) should NEVER be done by default. At a minimum, mswin.vim should not be setup to be sourced by default (with notes on how to add it if you want the Windows functionality).
>
> Vim is vim - basic functions should not be changed just because you are on Windows.
This discussion is outdated. Have you tried the new installer after 8.0.1232?
Now the installer has a choice whether you want to source mswin.vim or not.
(And it doesn't source mswin.vim by default now.)
Regards,
Ken Takata
--
--
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.
Saturday, January 26, 2019
Re: strange stray unicode character on the second line of all files
On Sat, Jan 26, 2019 at 2:19 PM Bram Moolenaar <Bram@moolenaar.net> wrote:
Aryeh Friedman wrote:
> On Sat, Jan 26, 2019 at 9:13 AM Bram Moolenaar <Bram@moolenaar.net> wrote:
> >
> > Aryeh Friedman wrote:
> >
> > > For some odd reason (bug?) a stray unprintable unicode character appear=
> s
> > > several spaces over on the second line of every file I edit (even when
> > the
> > > second line is nothing more then a new line):
> > >
> > > // src/java/specmed/devinv/DevInvUtil.java
> > > =EF=BF=BD <-- The stray unicode character
> > > Here is the output for cat -e of the first two lines of the same file:
> > >
> > > // src/java/specmed/devinv/DevInvUtil.java$
> > > $
> > >
> > > Platform info:
> > > OS: FreeBSD 11.2
> > > Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4
> > desktop
> > > (4.12)
> > > Vim --version output:
> > > VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
> > > Included patches: 1-676
> > > Compiled by aryehl@timeless
> > > Huge version with GTK2 GUI. Features included (+) or not (-):
> >
> > Looks like a leftover for the 'ambiwidth' test. This outputs a
> > character in the second like and requests the cursor position, to find
> > out the width of that character. It is then overwritten by two spaces.
> > The character used is 0x25bd, the character you see appears to be 0xfffd.
> > I guess the terminal didn't properly clean up.
> >
> > The character is not in the text, how do you get it?
> >
>
> By simply opening the file (vim [file] -- no command line switches).... see
> the resubjected thread for a lot more detail
The problem is probably caused by the terminal or a wrong termcap entry.
Try adding this to your .vimrc:
set t_u7=
That worked now to track down the root cause.
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: strange stray unicode character on the second line of all files
Aryeh Friedman wrote:
> On Sat, Jan 26, 2019 at 9:13 AM Bram Moolenaar <Bram@moolenaar.net> wrote:
> >
> > Aryeh Friedman wrote:
> >
> > > For some odd reason (bug?) a stray unprintable unicode character appear=
> s
> > > several spaces over on the second line of every file I edit (even when
> > the
> > > second line is nothing more then a new line):
> > >
> > > // src/java/specmed/devinv/DevInvUtil.java
> > > =EF=BF=BD <-- The stray unicode character
> > > Here is the output for cat -e of the first two lines of the same file:
> > >
> > > // src/java/specmed/devinv/DevInvUtil.java$
> > > $
> > >
> > > Platform info:
> > > OS: FreeBSD 11.2
> > > Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4
> > desktop
> > > (4.12)
> > > Vim --version output:
> > > VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
> > > Included patches: 1-676
> > > Compiled by aryehl@timeless
> > > Huge version with GTK2 GUI. Features included (+) or not (-):
> >
> > Looks like a leftover for the 'ambiwidth' test. This outputs a
> > character in the second like and requests the cursor position, to find
> > out the width of that character. It is then overwritten by two spaces.
> > The character used is 0x25bd, the character you see appears to be 0xfffd.
> > I guess the terminal didn't properly clean up.
> >
> > The character is not in the text, how do you get it?
> >
>
> By simply opening the file (vim [file] -- no command line switches).... see
> the resubjected thread for a lot more detail
The problem is probably caused by the terminal or a wrong termcap entry.
Try adding this to your .vimrc:
set t_u7=
--
Futility Factor: No experiment is ever a complete failure - it can always
serve as a negative example.
/// 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.
> On Sat, Jan 26, 2019 at 9:13 AM Bram Moolenaar <Bram@moolenaar.net> wrote:
> >
> > Aryeh Friedman wrote:
> >
> > > For some odd reason (bug?) a stray unprintable unicode character appear=
> s
> > > several spaces over on the second line of every file I edit (even when
> > the
> > > second line is nothing more then a new line):
> > >
> > > // src/java/specmed/devinv/DevInvUtil.java
> > > =EF=BF=BD <-- The stray unicode character
> > > Here is the output for cat -e of the first two lines of the same file:
> > >
> > > // src/java/specmed/devinv/DevInvUtil.java$
> > > $
> > >
> > > Platform info:
> > > OS: FreeBSD 11.2
> > > Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4
> > desktop
> > > (4.12)
> > > Vim --version output:
> > > VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
> > > Included patches: 1-676
> > > Compiled by aryehl@timeless
> > > Huge version with GTK2 GUI. Features included (+) or not (-):
> >
> > Looks like a leftover for the 'ambiwidth' test. This outputs a
> > character in the second like and requests the cursor position, to find
> > out the width of that character. It is then overwritten by two spaces.
> > The character used is 0x25bd, the character you see appears to be 0xfffd.
> > I guess the terminal didn't properly clean up.
> >
> > The character is not in the text, how do you get it?
> >
>
> By simply opening the file (vim [file] -- no command line switches).... see
> the resubjected thread for a lot more detail
The problem is probably caused by the terminal or a wrong termcap entry.
Try adding this to your .vimrc:
set t_u7=
--
Futility Factor: No experiment is ever a complete failure - it can always
serve as a negative example.
/// 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: strange stray unicode character on the second line of all files
On Sat, Jan 26, 2019 at 9:13 AM Bram Moolenaar <Bram@moolenaar.net> wrote:
Aryeh Friedman wrote:
> For some odd reason (bug?) a stray unprintable unicode character appears
> several spaces over on the second line of every file I edit (even when the
> second line is nothing more then a new line):
>
> // src/java/specmed/devinv/DevInvUtil.java
> � <-- The stray unicode character
> Here is the output for cat -e of the first two lines of the same file:
>
> // src/java/specmed/devinv/DevInvUtil.java$
> $
>
> Platform info:
> OS: FreeBSD 11.2
> Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop
> (4.12)
> Vim --version output:
> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
> Included patches: 1-676
> Compiled by aryehl@timeless
> Huge version with GTK2 GUI. Features included (+) or not (-):
Looks like a leftover for the 'ambiwidth' test. This outputs a
character in the second like and requests the cursor position, to find
out the width of that character. It is then overwritten by two spaces.
The character used is 0x25bd, the character you see appears to be 0xfffd.
I guess the terminal didn't properly clean up.
The character is not in the text, how do you get it?
By simply opening the file (vim [file] -- no command line switches).... see the resubjected thread for a lot more detail
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: (editor/vim) Re: strange stray unicode character on the second line of all files
On Sat, Jan 26, 2019 at 11:08 AM Adam Weinberger <adamw@freebsd.org> wrote:
On Sat, Jan 26, 2019 at 9:00 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>
>
>
> On Sat, Jan 26, 2019 at 10:56 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>>
>>
>>
>> On Sat, Jan 26, 2019 at 9:54 AM Adam Weinberger <adamw@freebsd.org> wrote:
>>>
>>> On Sat, Jan 26, 2019 at 1:59 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>>> >
>>> > Note I have added the maintainer of the vim port on FreeBSD to the To header for reasons given in the body of the reply
>>> >
>>> > On Fri, Jan 25, 2019 at 6:43 PM Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:
>>> >>
>>> >> On Sat, Jan 26, 2019 at 12:31 AM Aryeh Friedman
>>> >> <aryeh.friedman@gmail.com> wrote:
>>> >> >
>>> >> > Forgot to mention that hitting ^R or ^L will clear the character from the screen
>>> >> >
>>> >> > On Fri, Jan 25, 2019 at 4:40 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>>> >> >>
>>> >> >> For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):
>>> >> >>
>>> >> >> // src/java/specmed/devinv/DevInvUtil.java
>>> >> >> � <-- The stray unicode character
>>> >> >> Here is the output for cat -e of the first two lines of the same file:
>>> >> >>
>>> >> >> // src/java/specmed/devinv/DevInvUtil.java$
>>> >> >> $
>>>
>
> Appears to happen if, and ONLY if, the second line is blank (i.e. ^$ will match it as a regex)
>
>>>
>>>
>>> I update the FreBSD Vim port on the first of every month, but I'm
>>> happy to update early if there's a breakage.
>>>
>>> Updating is a matter of changing PORTVERSION in
>>> /usr/ports/editors/vim/Makefile, and running 'make makesum' from that
>>> dir.
>>
>>
>> Updated to 822 with no effect (see below)
>>
>>>
>>> Does this behavior change if you change TERM (say, screen-256color)?
>>
>>
>> No (with screen-256color)
>>
>>>
>>> If you ssh from the console? If you use a different terminal emulator?
>>
>>
>> If I use xterm (default settings and -rv) it disappears.
Interesting. And does that only happen for java files, or for other
files as well?
Could it be related to a plugin? Or do you have a listchars that
specifies a unicode character that isn't present in the font that
xfce4-term is using? You might try enabling plugins one at a time, not
setting listchars, and make sure that the file you're editing is using
UNIX line-endings.
It does on all files (for example here is a case of doing it on my vimrc)... the file in question was created from scratch in vim on FreeBSD 11.2 (version controlled by devel/aegis [which I am the maintainer of]):
set term=xterm-256color
�
set t_Co=256
runtime colorscheme colors/slate.vim
syntax enable
:noh
:hi Constant ctermfg=220
:hi String ctermfg=220
:hi Identifier ctermfg=lightblue
:hi javaCommentTitle ctermfg=yellow
:hi javaDocComment ctermfg=178
:hi javaCommentTitle ctermfg=178
:hi javaAnnotation ctermfg=lightblue
:hi Comment ctermfg=178
:hi javaDocTags ctermfg=Yellow
:hi htmlTag ctermfg=220
:hi htmlEndTag ctermfg=220
:hi javaScriptBraces ctermfg=white
:hi javaScriptParens ctermfg=white
:hi javaScriptType ctermfg=white
:hi javaScriptFunction ctermfg=lightblue
:hi xmlTag ctermfg=lightblue
:hi xmlTagName ctermfg=lightblue
:set t_ti=^[[?1049h
:set t_te=
�
set t_Co=256
runtime colorscheme colors/slate.vim
syntax enable
:noh
:hi Constant ctermfg=220
:hi String ctermfg=220
:hi Identifier ctermfg=lightblue
:hi javaCommentTitle ctermfg=yellow
:hi javaDocComment ctermfg=178
:hi javaCommentTitle ctermfg=178
:hi javaAnnotation ctermfg=lightblue
:hi Comment ctermfg=178
:hi javaDocTags ctermfg=Yellow
:hi htmlTag ctermfg=220
:hi htmlEndTag ctermfg=220
:hi javaScriptBraces ctermfg=white
:hi javaScriptParens ctermfg=white
:hi javaScriptType ctermfg=white
:hi javaScriptFunction ctermfg=lightblue
:hi xmlTag ctermfg=lightblue
:hi xmlTagName ctermfg=lightblue
:set t_ti=^[[?1049h
:set t_te=
For completeness here is my uname -a:
FreeBSD timeless 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #1 r339445: Sat Oct 20 02:23:58 EDT 2018 root@timeless:/usr/obj/usr/src/sys/GENERIC amd64
As far I know I am not using any plugins unless they came installed with the default port options here is my /var/db/ports/editors_vim/options:
# This file is auto-generated by 'make config'.
# Options for vim-8.1.0555
_OPTIONS_READ=vim-8.1.0555
_FILE_COMPLETE_OPTIONS_LIST=CSCOPE DEFAULT_VIMRC NLS XTERM_SAVE CTAGS_BASE CTAGS_EXUBERANT CTAGS_UNIVERSAL ATHENA CONSOLE GNOME GTK2 GTK3 MOTIF X11 LUA PERL PYTHON2 PYTHON3 RUBY SCHEME TCL
OPTIONS_FILE_SET+=CSCOPE
OPTIONS_FILE_SET+=DEFAULT_VIMRC
OPTIONS_FILE_SET+=NLS
OPTIONS_FILE_UNSET+=XTERM_SAVE
OPTIONS_FILE_UNSET+=CTAGS_BASE
OPTIONS_FILE_SET+=CTAGS_EXUBERANT
OPTIONS_FILE_UNSET+=CTAGS_UNIVERSAL
OPTIONS_FILE_UNSET+=ATHENA
OPTIONS_FILE_UNSET+=CONSOLE
OPTIONS_FILE_UNSET+=GNOME
OPTIONS_FILE_SET+=GTK2
OPTIONS_FILE_UNSET+=GTK3
OPTIONS_FILE_UNSET+=MOTIF
OPTIONS_FILE_UNSET+=X11
OPTIONS_FILE_UNSET+=LUA
OPTIONS_FILE_SET+=PERL
OPTIONS_FILE_SET+=PYTHON2
OPTIONS_FILE_UNSET+=PYTHON3
OPTIONS_FILE_SET+=RUBY
OPTIONS_FILE_UNSET+=SCHEME
OPTIONS_FILE_UNSET+=TCL
# Options for vim-8.1.0555
_OPTIONS_READ=vim-8.1.0555
_FILE_COMPLETE_OPTIONS_LIST=CSCOPE DEFAULT_VIMRC NLS XTERM_SAVE CTAGS_BASE CTAGS_EXUBERANT CTAGS_UNIVERSAL ATHENA CONSOLE GNOME GTK2 GTK3 MOTIF X11 LUA PERL PYTHON2 PYTHON3 RUBY SCHEME TCL
OPTIONS_FILE_SET+=CSCOPE
OPTIONS_FILE_SET+=DEFAULT_VIMRC
OPTIONS_FILE_SET+=NLS
OPTIONS_FILE_UNSET+=XTERM_SAVE
OPTIONS_FILE_UNSET+=CTAGS_BASE
OPTIONS_FILE_SET+=CTAGS_EXUBERANT
OPTIONS_FILE_UNSET+=CTAGS_UNIVERSAL
OPTIONS_FILE_UNSET+=ATHENA
OPTIONS_FILE_UNSET+=CONSOLE
OPTIONS_FILE_UNSET+=GNOME
OPTIONS_FILE_SET+=GTK2
OPTIONS_FILE_UNSET+=GTK3
OPTIONS_FILE_UNSET+=MOTIF
OPTIONS_FILE_UNSET+=X11
OPTIONS_FILE_UNSET+=LUA
OPTIONS_FILE_SET+=PERL
OPTIONS_FILE_SET+=PYTHON2
OPTIONS_FILE_UNSET+=PYTHON3
OPTIONS_FILE_SET+=RUBY
OPTIONS_FILE_UNSET+=SCHEME
OPTIONS_FILE_UNSET+=TCL
# Adam
--
Adam Weinberger
adamw@adamw.org // adamw@FreeBSD.org
https://www.adamw.org
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: (editor/vim) Re: strange stray unicode character on the second line of all files
On Sat, Jan 26, 2019 at 10:56 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
On Sat, Jan 26, 2019 at 9:54 AM Adam Weinberger <adamw@freebsd.org> wrote:On Sat, Jan 26, 2019 at 1:59 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>
> Note I have added the maintainer of the vim port on FreeBSD to the To header for reasons given in the body of the reply
>
> On Fri, Jan 25, 2019 at 6:43 PM Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:
>>
>> On Sat, Jan 26, 2019 at 12:31 AM Aryeh Friedman
>> <aryeh.friedman@gmail.com> wrote:
>> >
>> > Forgot to mention that hitting ^R or ^L will clear the character from the screen
>> >
>> > On Fri, Jan 25, 2019 at 4:40 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>> >>
>> >> For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):
>> >>
>> >> // src/java/specmed/devinv/DevInvUtil.java
>> >> � <-- The stray unicode character
>> >> Here is the output for cat -e of the first two lines of the same file:
>> >>
>> >> // src/java/specmed/devinv/DevInvUtil.java$
>> >> $
Appears to happen if, and ONLY if, the second line is blank (i.e. ^$ will match it as a regex)
I update the FreBSD Vim port on the first of every month, but I'm
happy to update early if there's a breakage.
Updating is a matter of changing PORTVERSION in
/usr/ports/editors/vim/Makefile, and running 'make makesum' from that
dir.Updated to 822 with no effect (see below)
Does this behavior change if you change TERM (say, screen-256color)?No (with screen-256color)If you ssh from the console? If you use a different terminal emulator?If I use xterm (default settings and -rv) it disappears.
--Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: (editor/vim) Re: strange stray unicode character on the second line of all files
On Sat, Jan 26, 2019 at 9:54 AM Adam Weinberger <adamw@freebsd.org> wrote:
On Sat, Jan 26, 2019 at 1:59 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>
> Note I have added the maintainer of the vim port on FreeBSD to the To header for reasons given in the body of the reply
>
> On Fri, Jan 25, 2019 at 6:43 PM Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:
>>
>> On Sat, Jan 26, 2019 at 12:31 AM Aryeh Friedman
>> <aryeh.friedman@gmail.com> wrote:
>> >
>> > Forgot to mention that hitting ^R or ^L will clear the character from the screen
>> >
>> > On Fri, Jan 25, 2019 at 4:40 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>> >>
>> >> For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):
>> >>
>> >> // src/java/specmed/devinv/DevInvUtil.java
>> >> � <-- The stray unicode character
>> >> Here is the output for cat -e of the first two lines of the same file:
>> >>
>> >> // src/java/specmed/devinv/DevInvUtil.java$
>> >> $
>> >>
>> >> Platform info:
>> >> OS: FreeBSD 11.2
>> >> Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop (4.12)
>> >> Vim --version output:
>> >> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
>> >> Included patches: 1-676
>> >> Compiled by aryehl@timeless
>> >> Huge version with GTK2 GUI. Features included (+) or not (-):
>>
>> This problem, or something quite like it, has recently been reported and fixed.
>>
>> The above is Vim 8.1.676. The latest source as of this writing is
>> 8.1.822; IOW there has already been 146 patches since the version you
>> used. Please try again with a newer Vim.
>
>
> 1. Since FreeBSD uses a centralized port and the port is currently only up through 676 I will wait until the official maintainer updates the port
>
> 2. I do not see any patches with descriptions off hand in the patch inventory after 676 that appear to relate to this issue.
I update the FreBSD Vim port on the first of every month, but I'm
happy to update early if there's a breakage.
Updating is a matter of changing PORTVERSION in
/usr/ports/editors/vim/Makefile, and running 'make makesum' from that
dir.
Updated to 822 with no effect (see below)
Does this behavior change if you change TERM (say, screen-256color)?
No (with screen-256color)
If you ssh from the console? If you use a different terminal emulator?
If I use xterm (default settings and -rv) it disappears.
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: strange stray unicode character on the second line of all files
Aryeh Friedman wrote:
> For some odd reason (bug?) a stray unprintable unicode character appears
> several spaces over on the second line of every file I edit (even when the
> second line is nothing more then a new line):
>
> // src/java/specmed/devinv/DevInvUtil.java
> � <-- The stray unicode character
> Here is the output for cat -e of the first two lines of the same file:
>
> // src/java/specmed/devinv/DevInvUtil.java$
> $
>
> Platform info:
> OS: FreeBSD 11.2
> Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop
> (4.12)
> Vim --version output:
> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
> Included patches: 1-676
> Compiled by aryehl@timeless
> Huge version with GTK2 GUI. Features included (+) or not (-):
Looks like a leftover for the 'ambiwidth' test. This outputs a
character in the second like and requests the cursor position, to find
out the width of that character. It is then overwritten by two spaces.
The character used is 0x25bd, the character you see appears to be 0xfffd.
I guess the terminal didn't properly clean up.
The character is not in the text, how do you get it?
--
Proverb: A nightingale that forgets the lyrics is a hummingbird.
/// 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.
> For some odd reason (bug?) a stray unprintable unicode character appears
> several spaces over on the second line of every file I edit (even when the
> second line is nothing more then a new line):
>
> // src/java/specmed/devinv/DevInvUtil.java
> � <-- The stray unicode character
> Here is the output for cat -e of the first two lines of the same file:
>
> // src/java/specmed/devinv/DevInvUtil.java$
> $
>
> Platform info:
> OS: FreeBSD 11.2
> Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop
> (4.12)
> Vim --version output:
> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
> Included patches: 1-676
> Compiled by aryehl@timeless
> Huge version with GTK2 GUI. Features included (+) or not (-):
Looks like a leftover for the 'ambiwidth' test. This outputs a
character in the second like and requests the cursor position, to find
out the width of that character. It is then overwritten by two spaces.
The character used is 0x25bd, the character you see appears to be 0xfffd.
I guess the terminal didn't properly clean up.
The character is not in the text, how do you get it?
--
Proverb: A nightingale that forgets the lyrics is a hummingbird.
/// 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: CTRL-F Setting
> I realize this topic is kind of old but I think it is important.
>
> Remapping basic vim functionality (such as Ctrl-F) should NEVER be
> done by default. At a minimum, mswin.vim should not be setup to be
> sourced by default (with notes on how to add it if you want the
> Windows functionality).
>
> Vim is vim - basic functions should not be changed just because you
> are on Windows.
There are two camps:
1. "This is Windows, so things should work like everything does on
Windows".
2. "This is Vim, so things should work the same on all platforms".
Can't possibly do both, thus the user has to make a choice.
--
"Shoot for the moon. Even if you miss, you'll land among the stars."
/// 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.
>
> Remapping basic vim functionality (such as Ctrl-F) should NEVER be
> done by default. At a minimum, mswin.vim should not be setup to be
> sourced by default (with notes on how to add it if you want the
> Windows functionality).
>
> Vim is vim - basic functions should not be changed just because you
> are on Windows.
There are two camps:
1. "This is Windows, so things should work like everything does on
Windows".
2. "This is Vim, so things should work the same on all platforms".
Can't possibly do both, thus the user has to make a choice.
--
"Shoot for the moon. Even if you miss, you'll land among the stars."
/// 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: Strange Characters in TOC window when using vim-pandoc plugin
On Saturday, January 26, 2019 at 7:14:54 PM UTC+8, Joey Ling wrote:
> When I execute the :TOC command in Vim, TOC window apperars in the left, but the headers show strange characters like <ac> ...
>
> Why and how to fix it?
If I put a <space> between # and words in the headers, the <ac> disappears, like this:
# 爷爷
but #爷爷 shows the <ac>.
--
--
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.
> When I execute the :TOC command in Vim, TOC window apperars in the left, but the headers show strange characters like <ac> ...
>
> Why and how to fix it?
If I put a <space> between # and words in the headers, the <ac> disappears, like this:
# 爷爷
but #爷爷 shows the <ac>.
--
--
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.
Strange Characters in TOC window when using vim-pandoc plugin
When I execute the :TOC command in Vim, TOC window apperars in the left, but the headers show strange characters like <ac> ...
Why and how to fix it?
--
--
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.
Why and how to fix it?
--
--
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.
(editor/vim) Re: strange stray unicode character on the second line of all files
Note I have added the maintainer of the vim port on FreeBSD to the To header for reasons given in the body of the reply
On Fri, Jan 25, 2019 at 6:43 PM Tony Mechelynck <antoine.mechelynck@gmail.com> wrote:
On Sat, Jan 26, 2019 at 12:31 AM Aryeh Friedman
<aryeh.friedman@gmail.com> wrote:
>
> Forgot to mention that hitting ^R or ^L will clear the character from the screen
>
> On Fri, Jan 25, 2019 at 4:40 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>>
>> For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):
>>
>> // src/java/specmed/devinv/DevInvUtil.java
>> � <-- The stray unicode character
>> Here is the output for cat -e of the first two lines of the same file:
>>
>> // src/java/specmed/devinv/DevInvUtil.java$
>> $
>>
>> Platform info:
>> OS: FreeBSD 11.2
>> Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop (4.12)
>> Vim --version output:
>> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
>> Included patches: 1-676
>> Compiled by aryehl@timeless
>> Huge version with GTK2 GUI. Features included (+) or not (-):
This problem, or something quite like it, has recently been reported and fixed.
The above is Vim 8.1.676. The latest source as of this writing is
8.1.822; IOW there has already been 146 patches since the version you
used. Please try again with a newer Vim.
1. Since FreeBSD uses a centralized port and the port is currently only up through 676 I will wait until the official maintainer updates the port
2. I do not see any patches with descriptions off hand in the patch inventory after 676 that appear to relate to this issue.
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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.
Friday, January 25, 2019
Re: strange stray unicode character on the second line of all files
On Sat, Jan 26, 2019 at 12:31 AM Aryeh Friedman
<aryeh.friedman@gmail.com> wrote:
>
> Forgot to mention that hitting ^R or ^L will clear the character from the screen
>
> On Fri, Jan 25, 2019 at 4:40 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>>
>> For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):
>>
>> // src/java/specmed/devinv/DevInvUtil.java
>> � <-- The stray unicode character
>> Here is the output for cat -e of the first two lines of the same file:
>>
>> // src/java/specmed/devinv/DevInvUtil.java$
>> $
>>
>> Platform info:
>> OS: FreeBSD 11.2
>> Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop (4.12)
>> Vim --version output:
>> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
>> Included patches: 1-676
>> Compiled by aryehl@timeless
>> Huge version with GTK2 GUI. Features included (+) or not (-):
This problem, or something quite like it, has recently been reported and fixed.
The above is Vim 8.1.676. The latest source as of this writing is
8.1.822; IOW there has already been 146 patches since the version you
used. Please try again with a newer Vim.
For a one-line description of every 8.1 patch so far, see
http://ftp.vim.org/pub/vim/patches/8.1/
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.
<aryeh.friedman@gmail.com> wrote:
>
> Forgot to mention that hitting ^R or ^L will clear the character from the screen
>
> On Fri, Jan 25, 2019 at 4:40 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
>>
>> For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):
>>
>> // src/java/specmed/devinv/DevInvUtil.java
>> � <-- The stray unicode character
>> Here is the output for cat -e of the first two lines of the same file:
>>
>> // src/java/specmed/devinv/DevInvUtil.java$
>> $
>>
>> Platform info:
>> OS: FreeBSD 11.2
>> Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop (4.12)
>> Vim --version output:
>> VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
>> Included patches: 1-676
>> Compiled by aryehl@timeless
>> Huge version with GTK2 GUI. Features included (+) or not (-):
This problem, or something quite like it, has recently been reported and fixed.
The above is Vim 8.1.676. The latest source as of this writing is
8.1.822; IOW there has already been 146 patches since the version you
used. Please try again with a newer Vim.
For a one-line description of every 8.1 patch so far, see
http://ftp.vim.org/pub/vim/patches/8.1/
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: Evaluating the cost to type something in vim
On Thu, 24 Jan 2019, Peng Yu <pengyu.ut@gmail.com> wrote:
>> finding the minimal user input that yields a buffer with the input
>> falls under https://en.wikipedia.org/wiki/Code_golf
> This kind of competition is not relevant to what I am not talking
> about. One has to spend extra effort to come up with the absolute
> shortest code. That effort must be considered into the cost as well.
> What I am talking about is "cost", which ultimately map to all
> programmer's time involved in typing and thinking about what to type.
> (But not include thinking about algorithm, data structure, etc.)
Speaking from my own experiences, I use vi and vim differently under
those (increasingly rare, but not never) circumstances where I have a
slow connection. When I can type, say, a half line ahead of where the
system has echoed back my keystrokes, I find myself looking for ways
to optimize the effectiveness of what I type.
If I'm copying something from the line above on a fast connection, I'm
likely to just hit <ctrl-Y> in insert mode a lot. On a slower connection
I'll <esc>ky5f,jpa (as an example, to copy up to the fifth comma).
I'm well aware of the "cost" differences, as you put it. Keeping my
fingers in one location and repeating a single keystroke is very fast
mentally and fairly fast in action on a good system. Over a bad network
link, it's a lot slower because I can't get the immediate visual
feedback. But I have the time to reason out the exact sequence of
movements that will minimize my typing and that increases my effective
speed over the link in two ways: each packet of TCP connection can hold
more response from the server, and I rely on fewer packets sent to the
remote end.
Vi is highly adapted to needs of such slow connection thoughtful
editing. I find the same action optimization skills useful in
constructing macros, too. Explictly separation of searching for a string
anywhere or a character within a line means I can efficiently mix "n"
and ";" searches for finding a matching line and a matching position on
that line (which might not be the start of my match string). Then add in
a "@" action and I can make tail recursive macros easily.
Consider a CSS file with a bunch of inlined images, and other
stuff nearby:
.svg {
background-image:url(data:image/svg+xml;base64,PHN2Zy....)
}
.png {
background-image: url(data:image/png;base64,iVBORw....)
}
.jpg {
background-image:url(data:image/jpeg;base64,/9j/45....); color:#FFF
}
.gif {
border:0;background-image:url(data:image/gif;base64,R0lGOD....)
}
Let's pretend there are zillions of them and we want to replace
all of those with regular https URLs.
First key up a search:
/background-image: *url *(data:
Then find the ( with "f("
Now create a temporary line in the file:
(https://static.example.com/image.png)
And then capture the contents to register c (sans newline):
0"cD
Now reuse that temporary line to write a macro:
n;d%"cp@q
And then capture the contents to register q (sans newline), then
delete the line:
0"qDdd
Finally run the macro with @q
Presto, all instances changed! (And a single 'u' will undo all of the
changes at once.) All because of the same optimizations that help me on
slow links. (And resorting to no vim-isms.)
Elijah
--
--
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.
>> finding the minimal user input that yields a buffer with the input
>> falls under https://en.wikipedia.org/wiki/Code_golf
> This kind of competition is not relevant to what I am not talking
> about. One has to spend extra effort to come up with the absolute
> shortest code. That effort must be considered into the cost as well.
> What I am talking about is "cost", which ultimately map to all
> programmer's time involved in typing and thinking about what to type.
> (But not include thinking about algorithm, data structure, etc.)
Speaking from my own experiences, I use vi and vim differently under
those (increasingly rare, but not never) circumstances where I have a
slow connection. When I can type, say, a half line ahead of where the
system has echoed back my keystrokes, I find myself looking for ways
to optimize the effectiveness of what I type.
If I'm copying something from the line above on a fast connection, I'm
likely to just hit <ctrl-Y> in insert mode a lot. On a slower connection
I'll <esc>ky5f,jpa (as an example, to copy up to the fifth comma).
I'm well aware of the "cost" differences, as you put it. Keeping my
fingers in one location and repeating a single keystroke is very fast
mentally and fairly fast in action on a good system. Over a bad network
link, it's a lot slower because I can't get the immediate visual
feedback. But I have the time to reason out the exact sequence of
movements that will minimize my typing and that increases my effective
speed over the link in two ways: each packet of TCP connection can hold
more response from the server, and I rely on fewer packets sent to the
remote end.
Vi is highly adapted to needs of such slow connection thoughtful
editing. I find the same action optimization skills useful in
constructing macros, too. Explictly separation of searching for a string
anywhere or a character within a line means I can efficiently mix "n"
and ";" searches for finding a matching line and a matching position on
that line (which might not be the start of my match string). Then add in
a "@" action and I can make tail recursive macros easily.
Consider a CSS file with a bunch of inlined images, and other
stuff nearby:
.svg {
background-image:url(data:image/svg+xml;base64,PHN2Zy....)
}
.png {
background-image: url(data:image/png;base64,iVBORw....)
}
.jpg {
background-image:url(data:image/jpeg;base64,/9j/45....); color:#FFF
}
.gif {
border:0;background-image:url(data:image/gif;base64,R0lGOD....)
}
Let's pretend there are zillions of them and we want to replace
all of those with regular https URLs.
First key up a search:
/background-image: *url *(data:
Then find the ( with "f("
Now create a temporary line in the file:
(https://static.example.com/image.png)
And then capture the contents to register c (sans newline):
0"cD
Now reuse that temporary line to write a macro:
n;d%"cp@q
And then capture the contents to register q (sans newline), then
delete the line:
0"qDdd
Finally run the macro with @q
Presto, all instances changed! (And a single 'u' will undo all of the
changes at once.) All because of the same optimizations that help me on
slow links. (And resorting to no vim-isms.)
Elijah
--
--
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: CTRL-F Setting
Completely agree!
On Fri, Jan 25, 2019, 1:49 PM SteveW <wilcoxon@gmail.com wrote:
I realize this topic is kind of old but I think it is important.
Remapping basic vim functionality (such as Ctrl-F) should NEVER be done by default. At a minimum, mswin.vim should not be setup to be sourced by default (with notes on how to add it if you want the Windows functionality).
Vim is vim - basic functions should not be changed just because you are on Windows.
--
--
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 a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/hdiaDiH2I8E/unsubscribe.
To unsubscribe from this group and all its topics, 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: CTRL-F Setting
Sent from my T-Mobile 4G LTE Device
-------- Original message --------
From: SteveW <wilcoxon@gmail.com>
Date: 1/25/19 1:49 PM (GMT-08:00)
To: vim_use <vim_use@googlegroups.com>
Subject: Re: CTRL-F Setting
Remapping basic vim functionality (such as Ctrl-F) should NEVER be done by default. At a minimum, mswin.vim should not be setup to be sourced by default (with notes on how to add it if you want the Windows functionality).
Vim is vim - basic functions should not be changed just because you are on Windows.
--
--
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: CTRL-F Setting
I realize this topic is kind of old but I think it is important.
Remapping basic vim functionality (such as Ctrl-F) should NEVER be done by default. At a minimum, mswin.vim should not be setup to be sourced by default (with notes on how to add it if you want the Windows functionality).
Vim is vim - basic functions should not be changed just because you are on Windows.
--
--
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.
Remapping basic vim functionality (such as Ctrl-F) should NEVER be done by default. At a minimum, mswin.vim should not be setup to be sourced by default (with notes on how to add it if you want the Windows functionality).
Vim is vim - basic functions should not be changed just because you are on Windows.
--
--
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: Evaluating the cost to type something in vim
On Tue, Jan 22, 2019 at 02:20:50PM -0600, Peng Yu wrote:
> Is there a tool to evaluate the least cost to type something in vim as
> accurately as possible? Thanks.
'cost' best can be measured with two variables: time and
keystrokes/mouse distance. for both there must be software to keep
record of typing time, the number of keystrokes and the distance and
number of clicks with a mouse.
I don't know of any comparisons that quantify the vim statement 'editing
with the speed of thought', but you could do a test with a few
writers/programmers to make quasi accurate, but comparable measurements.
just ask people to reproduce the same text/code with their favourite editor,
make measurements and then compare.
I think it is important to let your testers work with _their_ favourite
tool. that way you make use of their high(er) level skills, which should
give more accurate time/keystroke measurements on the long run. it is
not realistic to ask a Word user to try the same text in Vim, or ask a
profound Vimmer to use a GUI editor -- both get lost (the Word user will
never quit ;-)
will be a nice experiment, maybe you can ask more people over the net to
participate and make your 'n' bigger.
//meine
--
--
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.
> Is there a tool to evaluate the least cost to type something in vim as
> accurately as possible? Thanks.
'cost' best can be measured with two variables: time and
keystrokes/mouse distance. for both there must be software to keep
record of typing time, the number of keystrokes and the distance and
number of clicks with a mouse.
I don't know of any comparisons that quantify the vim statement 'editing
with the speed of thought', but you could do a test with a few
writers/programmers to make quasi accurate, but comparable measurements.
just ask people to reproduce the same text/code with their favourite editor,
make measurements and then compare.
I think it is important to let your testers work with _their_ favourite
tool. that way you make use of their high(er) level skills, which should
give more accurate time/keystroke measurements on the long run. it is
not realistic to ask a Word user to try the same text in Vim, or ask a
profound Vimmer to use a GUI editor -- both get lost (the Word user will
never quit ;-)
will be a nice experiment, maybe you can ask more people over the net to
participate and make your 'n' bigger.
//meine
--
--
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: strange stray unicode character on the second line of all files
Forgot to mention that hitting ^R or ^L will clear the character from the screen
On Fri, Jan 25, 2019 at 4:40 AM Aryeh Friedman <aryeh.friedman@gmail.com> wrote:
For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):// src/java/specmed/devinv/DevInvUtil.java
� <-- The stray unicode characterHere is the output for cat -e of the first two lines of the same file:// src/java/specmed/devinv/DevInvUtil.java$
$Platform info:OS: FreeBSD 11.2Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop (4.12)Vim --version output:VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
Included patches: 1-676
Compiled by aryehl@timeless
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +extra_search +mouse_netterm +tag_old_static
+arabic +farsi +mouse_sgr -tag_any_white
+autocmd +file_in_path +mouse_sysmouse -tcl
+autochdir +find_in_path +mouse_urxvt +termguicolors
-autoservername +float +mouse_xterm +terminal
+balloon_eval +folding +multi_byte +terminfo
+balloon_eval_term -footer +multi_lang +termresponse
+browse +fork() -mzscheme +textobjects
++builtin_terms +gettext +netbeans_intg +textprop
+byte_offset -hangul_input +num64 +timers
+channel +iconv +packages +title
+cindent +insert_expand +path_extra +toolbar
+clientserver +job +perl +user_commands
+clipboard +jumplist +persistent_undo +vartabs
+cmdline_compl +keymap +postscript +vertsplit
+cmdline_hist +lambda +printer +virtualedit
+cmdline_info +langmap +profile +visual
+comments +libcall +python +visualextra
+conceal +linebreak -python3 +viminfo
+cryptv +lispindent +quickfix +vreplace
+cscope +listcmds +reltime +wildignore
+cursorbind +localmap +rightleft +wildmenu
+cursorshape -lua +ruby +windows
+dialog_con_gui +menu +scrollbind +writebackup
+diff +mksession +signs +X11
+digraphs +modify_fname +smartindent -xfontset
+dnd +mouse +startuptime +xim
-ebcdic +mouseshape +statusline +xpm
+emacs_tags +mouse_dec -sun_workshop +xsmp_interact
+eval -mouse_gpm +syntax +xterm_clipboard
+ex_extra -mouse_jsbterm +tag_binary -xterm_save
system vimrc file: "/usr/local/etc/vim/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/usr/local/etc/vim/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/local/etc/vim"
f-b for $VIMRUNTIME: "/usr/local/share/vim/vim81"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/include/gtk-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0 -D_THREAD_SAFE -pthread -DLIBICONV_PLUG -I/usr/local/include -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/local/include
Linking: cc -L/usr/local/lib -L/usr/local/lib -L. -fstack-protector -rdynamic -Wl,-R/usr/local/lib/perl5/5.26/mach/CORE -fstack-protector -L/usr/local/lib -Wl,--as-needed -o vim -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lpthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lelf -pthread -lncurses -lintl -Wl,-R/usr/local/lib/perl5/5.26/mach/CORE -pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/local/lib/perl5/5.26/mach/CORE -lperl -lpthread -lm -lcrypt -lutil -L/usr/local/lib/python2.7/config -lpython2.7 -ldl -L/usr/local/lib -lintl -lutil -lm -Wl,--export-dynamic -lruby24 -lelf -lunwind -lexecinfo -lprocstat -lthr -ldl -lcrypt -lm -lpthread -L/usr/local/lib -L/usr/local/lib -L/usr/local/libDefault system vim configUser vimrc:set term=xterm-256color
set t_Co=256
runtime colorscheme colors/slate.vim
syntax enable
:noh
:hi Constant ctermfg=220
:hi String ctermfg=220
:hi Identifier ctermfg=lightblue
:hi javaCommentTitle ctermfg=yellow
:hi javaDocComment ctermfg=178
:hi javaCommentTitle ctermfg=178
:hi javaAnnotation ctermfg=lightblue
:hi Comment ctermfg=178
:hi javaDocTags ctermfg=Yellow
:hi htmlTag ctermfg=220
:hi htmlEndTag ctermfg=220
:hi javaScriptBraces ctermfg=white
:hi javaScriptParens ctermfg=white
:hi javaScriptType ctermfg=white
:hi javaScriptFunction ctermfg=lightblue
:hi xmlTag ctermfg=lightblue
:hi xmlTagName ctermfg=lightblue
:set t_ti=^[[?1049h
:set t_te=--Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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.
strange stray unicode character on the second line of all files
For some odd reason (bug?) a stray unprintable unicode character appears several spaces over on the second line of every file I edit (even when the second line is nothing more then a new line):
// src/java/specmed/devinv/DevInvUtil.java
� <-- The stray unicode character
� <-- The stray unicode character
Here is the output for cat -e of the first two lines of the same file:
// src/java/specmed/devinv/DevInvUtil.java$
$
$
Platform info:
OS: FreeBSD 11.2
Terminal type: ssh (xterm-256color) via xfce4-term 0.8.7.4 on xfce4 desktop (4.12)
Vim --version output:
VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 25 2019 04:31:10)
Included patches: 1-676
Compiled by aryehl@timeless
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +extra_search +mouse_netterm +tag_old_static
+arabic +farsi +mouse_sgr -tag_any_white
+autocmd +file_in_path +mouse_sysmouse -tcl
+autochdir +find_in_path +mouse_urxvt +termguicolors
-autoservername +float +mouse_xterm +terminal
+balloon_eval +folding +multi_byte +terminfo
+balloon_eval_term -footer +multi_lang +termresponse
+browse +fork() -mzscheme +textobjects
++builtin_terms +gettext +netbeans_intg +textprop
+byte_offset -hangul_input +num64 +timers
+channel +iconv +packages +title
+cindent +insert_expand +path_extra +toolbar
+clientserver +job +perl +user_commands
+clipboard +jumplist +persistent_undo +vartabs
+cmdline_compl +keymap +postscript +vertsplit
+cmdline_hist +lambda +printer +virtualedit
+cmdline_info +langmap +profile +visual
+comments +libcall +python +visualextra
+conceal +linebreak -python3 +viminfo
+cryptv +lispindent +quickfix +vreplace
+cscope +listcmds +reltime +wildignore
+cursorbind +localmap +rightleft +wildmenu
+cursorshape -lua +ruby +windows
+dialog_con_gui +menu +scrollbind +writebackup
+diff +mksession +signs +X11
+digraphs +modify_fname +smartindent -xfontset
+dnd +mouse +startuptime +xim
-ebcdic +mouseshape +statusline +xpm
+emacs_tags +mouse_dec -sun_workshop +xsmp_interact
+eval -mouse_gpm +syntax +xterm_clipboard
+ex_extra -mouse_jsbterm +tag_binary -xterm_save
system vimrc file: "/usr/local/etc/vim/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/usr/local/etc/vim/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/local/etc/vim"
f-b for $VIMRUNTIME: "/usr/local/share/vim/vim81"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/include/gtk-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0 -D_THREAD_SAFE -pthread -DLIBICONV_PLUG -I/usr/local/include -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/local/include
Linking: cc -L/usr/local/lib -L/usr/local/lib -L. -fstack-protector -rdynamic -Wl,-R/usr/local/lib/perl5/5.26/mach/CORE -fstack-protector -L/usr/local/lib -Wl,--as-needed -o vim -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lpthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lelf -pthread -lncurses -lintl -Wl,-R/usr/local/lib/perl5/5.26/mach/CORE -pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/local/lib/perl5/5.26/mach/CORE -lperl -lpthread -lm -lcrypt -lutil -L/usr/local/lib/python2.7/config -lpython2.7 -ldl -L/usr/local/lib -lintl -lutil -lm -Wl,--export-dynamic -lruby24 -lelf -lunwind -lexecinfo -lprocstat -lthr -ldl -lcrypt -lm -lpthread -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib
Included patches: 1-676
Compiled by aryehl@timeless
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +extra_search +mouse_netterm +tag_old_static
+arabic +farsi +mouse_sgr -tag_any_white
+autocmd +file_in_path +mouse_sysmouse -tcl
+autochdir +find_in_path +mouse_urxvt +termguicolors
-autoservername +float +mouse_xterm +terminal
+balloon_eval +folding +multi_byte +terminfo
+balloon_eval_term -footer +multi_lang +termresponse
+browse +fork() -mzscheme +textobjects
++builtin_terms +gettext +netbeans_intg +textprop
+byte_offset -hangul_input +num64 +timers
+channel +iconv +packages +title
+cindent +insert_expand +path_extra +toolbar
+clientserver +job +perl +user_commands
+clipboard +jumplist +persistent_undo +vartabs
+cmdline_compl +keymap +postscript +vertsplit
+cmdline_hist +lambda +printer +virtualedit
+cmdline_info +langmap +profile +visual
+comments +libcall +python +visualextra
+conceal +linebreak -python3 +viminfo
+cryptv +lispindent +quickfix +vreplace
+cscope +listcmds +reltime +wildignore
+cursorbind +localmap +rightleft +wildmenu
+cursorshape -lua +ruby +windows
+dialog_con_gui +menu +scrollbind +writebackup
+diff +mksession +signs +X11
+digraphs +modify_fname +smartindent -xfontset
+dnd +mouse +startuptime +xim
-ebcdic +mouseshape +statusline +xpm
+emacs_tags +mouse_dec -sun_workshop +xsmp_interact
+eval -mouse_gpm +syntax +xterm_clipboard
+ex_extra -mouse_jsbterm +tag_binary -xterm_save
system vimrc file: "/usr/local/etc/vim/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/usr/local/etc/vim/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/local/etc/vim"
f-b for $VIMRUNTIME: "/usr/local/share/vim/vim81"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/local/include/gtk-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0 -D_THREAD_SAFE -pthread -DLIBICONV_PLUG -I/usr/local/include -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/local/include
Linking: cc -L/usr/local/lib -L/usr/local/lib -L. -fstack-protector -rdynamic -Wl,-R/usr/local/lib/perl5/5.26/mach/CORE -fstack-protector -L/usr/local/lib -Wl,--as-needed -o vim -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lpthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lelf -pthread -lncurses -lintl -Wl,-R/usr/local/lib/perl5/5.26/mach/CORE -pthread -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/local/lib/perl5/5.26/mach/CORE -lperl -lpthread -lm -lcrypt -lutil -L/usr/local/lib/python2.7/config -lpython2.7 -ldl -L/usr/local/lib -lintl -lutil -lm -Wl,--export-dynamic -lruby24 -lelf -lunwind -lexecinfo -lprocstat -lthr -ldl -lcrypt -lm -lpthread -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib
Default system vim config
User vimrc:
set term=xterm-256color
set t_Co=256
runtime colorscheme colors/slate.vim
syntax enable
:noh
:hi Constant ctermfg=220
:hi String ctermfg=220
:hi Identifier ctermfg=lightblue
:hi javaCommentTitle ctermfg=yellow
:hi javaDocComment ctermfg=178
:hi javaCommentTitle ctermfg=178
:hi javaAnnotation ctermfg=lightblue
:hi Comment ctermfg=178
:hi javaDocTags ctermfg=Yellow
:hi htmlTag ctermfg=220
:hi htmlEndTag ctermfg=220
:hi javaScriptBraces ctermfg=white
:hi javaScriptParens ctermfg=white
:hi javaScriptType ctermfg=white
:hi javaScriptFunction ctermfg=lightblue
:hi xmlTag ctermfg=lightblue
:hi xmlTagName ctermfg=lightblue
:set t_ti=^[[?1049h
:set t_te=
set t_Co=256
runtime colorscheme colors/slate.vim
syntax enable
:noh
:hi Constant ctermfg=220
:hi String ctermfg=220
:hi Identifier ctermfg=lightblue
:hi javaCommentTitle ctermfg=yellow
:hi javaDocComment ctermfg=178
:hi javaCommentTitle ctermfg=178
:hi javaAnnotation ctermfg=lightblue
:hi Comment ctermfg=178
:hi javaDocTags ctermfg=Yellow
:hi htmlTag ctermfg=220
:hi htmlEndTag ctermfg=220
:hi javaScriptBraces ctermfg=white
:hi javaScriptParens ctermfg=white
:hi javaScriptType ctermfg=white
:hi javaScriptFunction ctermfg=lightblue
:hi xmlTag ctermfg=lightblue
:hi xmlTagName ctermfg=lightblue
:set t_ti=^[[?1049h
:set t_te=
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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.
Thursday, January 24, 2019
Re: Evaluating the cost to type something in vim
> What I am talking about is "cost", which ultimately map to all
> programmer's time involved in typing and thinking about what to type.
> (But not include thinking about algorithm, data structure, etc.)
Hi Peng,
It sounds like you are measuring cost as equal to time. If you want to know
the answer to that, you would need a study that somehow compares time taken
between one or more people using Vim, and some number of other people using
various other editors. You can use google to see whether such studies have
been done and what their conclusions were ;)
Note that, different tools could be more optimal for different text. For an
extremely silly example, if you want to write out "lorem ipsum" text, you
can do it many times more efficiently with a lorem-ipsum generator than by
typing it out in Vim.
A less silly example is the difference between natural language and
programming code. Code is often line-based, and can thus take advantage of
Vim's linewise mappings; for natural language, new sentences do not
necessarily induce line-break (as you can see in the current email). So,
Vim is optimised for coders, and might appear less efficient when used for
natural language.
In other words, first define what type of text you are measuring the cost
for.
I would furthermore claim there exist other "costs" to consider, in
addition to the naive metric of "how long does it take to type something or
other".
I exclusively use Linux, and my work involves a lot of sshing around
between various servers. And all my workstations, laptops, raspberry pis
and NAS run Linux and can be accessed with ssh. For this ecosystem, Vim is
ubiquitous, fast, rock-solid, bandwidth-friendly, and integrates well with
other command-line tools. Regardless of whether I could save a few seconds
on writing this email by using some other editor, that would not stop Vim
from being the overwhelmingly correct choice for me.
In other words, it is not sensible to measure the "cost" of just one tool
as though it exists in isolation; it is better to focus on the pros and
cons of different working ecosystems of tools.
Eg, I would not recommend Vim to someone who has the unfortunate type of
job where they need to work a lot in Windows writing VBA apps (as I did in
a past life). For that kind of work, you are better off using the VBA
editor.
~ 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.
> programmer's time involved in typing and thinking about what to type.
> (But not include thinking about algorithm, data structure, etc.)
Hi Peng,
It sounds like you are measuring cost as equal to time. If you want to know
the answer to that, you would need a study that somehow compares time taken
between one or more people using Vim, and some number of other people using
various other editors. You can use google to see whether such studies have
been done and what their conclusions were ;)
Note that, different tools could be more optimal for different text. For an
extremely silly example, if you want to write out "lorem ipsum" text, you
can do it many times more efficiently with a lorem-ipsum generator than by
typing it out in Vim.
A less silly example is the difference between natural language and
programming code. Code is often line-based, and can thus take advantage of
Vim's linewise mappings; for natural language, new sentences do not
necessarily induce line-break (as you can see in the current email). So,
Vim is optimised for coders, and might appear less efficient when used for
natural language.
In other words, first define what type of text you are measuring the cost
for.
I would furthermore claim there exist other "costs" to consider, in
addition to the naive metric of "how long does it take to type something or
other".
I exclusively use Linux, and my work involves a lot of sshing around
between various servers. And all my workstations, laptops, raspberry pis
and NAS run Linux and can be accessed with ssh. For this ecosystem, Vim is
ubiquitous, fast, rock-solid, bandwidth-friendly, and integrates well with
other command-line tools. Regardless of whether I could save a few seconds
on writing this email by using some other editor, that would not stop Vim
from being the overwhelmingly correct choice for me.
In other words, it is not sensible to measure the "cost" of just one tool
as though it exists in isolation; it is better to focus on the pros and
cons of different working ecosystems of tools.
Eg, I would not recommend Vim to someone who has the unfortunate type of
job where they need to work a lot in Windows writing VBA apps (as I did in
a past life). For that kind of work, you are better off using the VBA
editor.
~ 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: Evaluating the cost to type something in vim
> well, vi (and ergo vim) keystrokes are
> https://en.wikipedia.org/wiki/Turing_completeness (also see
> https://stackoverflow.com/questions/7284/what-is-turing-complete ). As a
> result, finding the minimal user input that yields a buffer with the input
> falls under https://en.wikipedia.org/wiki/Code_golf
This kind of competition is not relevant to what I am not talking
about. One has to spend extra effort to come up with the absolute
shortest code. That effort must be considered into the cost as well.
What I am talking about is "cost", which ultimately map to all
programmer's time involved in typing and thinking about what to type.
(But not include thinking about algorithm, data structure, etc.)
> or perhaps
> https://en.wikipedia.org/wiki/Kolmogorov_complexity . Also see
> http://www.vimgolf.com/ for vim golf.
--
Regards,
Peng
--
--
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.
> https://en.wikipedia.org/wiki/Turing_completeness (also see
> https://stackoverflow.com/questions/7284/what-is-turing-complete ). As a
> result, finding the minimal user input that yields a buffer with the input
> falls under https://en.wikipedia.org/wiki/Code_golf
This kind of competition is not relevant to what I am not talking
about. One has to spend extra effort to come up with the absolute
shortest code. That effort must be considered into the cost as well.
What I am talking about is "cost", which ultimately map to all
programmer's time involved in typing and thinking about what to type.
(But not include thinking about algorithm, data structure, etc.)
> or perhaps
> https://en.wikipedia.org/wiki/Kolmogorov_complexity . Also see
> http://www.vimgolf.com/ for vim golf.
--
Regards,
Peng
--
--
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: Evaluating the cost to type something in vim
Hi Peng,
On Tue, 22 Jan 2019 14:20:50 -0600
Peng Yu <pengyu.ut@gmail.com> wrote:
> Hi,
>
> I'd like to evaluate the cost of typing in vim. It should not just
> simply counting the number of characters or words.
>
> For example, the metric should capture things like the following and more.
>
> - If there are two lines that are the same, people would type the
> first line and copy-paste to generate the 2nd line. So the number of
> keystrokes would be less than the total number of characters.
> - If two strings are similar, people would make a copy and edit the copy.
> - Repeatedly type something would be considered of less cost than type
> non-repetitive characters of the same length.
> - ctrl-P/N to save keystrokes for the words already typed before.
> etc.
>
> Is there a tool to evaluate the least cost to type something in vim as
> accurately as possible? Thanks.
>
well, vi (and ergo vim) keystrokes are
https://en.wikipedia.org/wiki/Turing_completeness (also see
https://stackoverflow.com/questions/7284/what-is-turing-complete ). As a
result, finding the minimal user input that yields a buffer with the input
falls under https://en.wikipedia.org/wiki/Code_golf or perhaps
https://en.wikipedia.org/wiki/Kolmogorov_complexity . Also see
http://www.vimgolf.com/ for vim golf.
Regards,
Shlomi
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Parody of "The Fountainhead" - http://shlom.in/towtf
<rindolf> We have a saying: "We survived Pharaoh - we'll survive this."
<sorabji5252> I suppose it's all cake after Pharaoh.
— Freenode's #reddit channel
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
--
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.
On Tue, 22 Jan 2019 14:20:50 -0600
Peng Yu <pengyu.ut@gmail.com> wrote:
> Hi,
>
> I'd like to evaluate the cost of typing in vim. It should not just
> simply counting the number of characters or words.
>
> For example, the metric should capture things like the following and more.
>
> - If there are two lines that are the same, people would type the
> first line and copy-paste to generate the 2nd line. So the number of
> keystrokes would be less than the total number of characters.
> - If two strings are similar, people would make a copy and edit the copy.
> - Repeatedly type something would be considered of less cost than type
> non-repetitive characters of the same length.
> - ctrl-P/N to save keystrokes for the words already typed before.
> etc.
>
> Is there a tool to evaluate the least cost to type something in vim as
> accurately as possible? Thanks.
>
well, vi (and ergo vim) keystrokes are
https://en.wikipedia.org/wiki/Turing_completeness (also see
https://stackoverflow.com/questions/7284/what-is-turing-complete ). As a
result, finding the minimal user input that yields a buffer with the input
falls under https://en.wikipedia.org/wiki/Code_golf or perhaps
https://en.wikipedia.org/wiki/Kolmogorov_complexity . Also see
http://www.vimgolf.com/ for vim golf.
Regards,
Shlomi
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Parody of "The Fountainhead" - http://shlom.in/towtf
<rindolf> We have a saying: "We survived Pharaoh - we'll survive this."
<sorabji5252> I suppose it's all cake after Pharaoh.
— Freenode's #reddit channel
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
--
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.
Tuesday, January 22, 2019
Evaluating the cost to type something in vim
Hi,
I'd like to evaluate the cost of typing in vim. It should not just
simply counting the number of characters or words.
For example, the metric should capture things like the following and more.
- If there are two lines that are the same, people would type the
first line and copy-paste to generate the 2nd line. So the number of
keystrokes would be less than the total number of characters.
- If two strings are similar, people would make a copy and edit the copy.
- Repeatedly type something would be considered of less cost than type
non-repetitive characters of the same length.
- ctrl-P/N to save keystrokes for the words already typed before.
etc.
Is there a tool to evaluate the least cost to type something in vim as
accurately as possible? Thanks.
--
Regards,
Peng
--
--
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.
I'd like to evaluate the cost of typing in vim. It should not just
simply counting the number of characters or words.
For example, the metric should capture things like the following and more.
- If there are two lines that are the same, people would type the
first line and copy-paste to generate the 2nd line. So the number of
keystrokes would be less than the total number of characters.
- If two strings are similar, people would make a copy and edit the copy.
- Repeatedly type something would be considered of less cost than type
non-repetitive characters of the same length.
- ctrl-P/N to save keystrokes for the words already typed before.
etc.
Is there a tool to evaluate the least cost to type something in vim as
accurately as possible? Thanks.
--
Regards,
Peng
--
--
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.
Saturday, January 19, 2019
termguicolors and xterm
I came across a new 'termguicolors' option in Vim.
I took a closer look using KDE's Konsole and gnome-terminal and it
appears to work out of the box: just a matter of adding a ":set
termguicolors" statement to your ~/.vimrc and 16M colors color schemes
written with gvim in mind are correctly displayed on these two
terminals.
Since I do not normally use Konsole or gnome-terminal I proceeded to
take a look at xterm where I was unable to get this new Vim magic to
work.
Has anyone been able to get the 'termguicolors' option to work on xterm
or does xterm altogether lack the capability?
Tested with XTerm(327) on debian stable (stretch).
Thanks,
CJ
--
--
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.
I took a closer look using KDE's Konsole and gnome-terminal and it
appears to work out of the box: just a matter of adding a ":set
termguicolors" statement to your ~/.vimrc and 16M colors color schemes
written with gvim in mind are correctly displayed on these two
terminals.
Since I do not normally use Konsole or gnome-terminal I proceeded to
take a look at xterm where I was unable to get this new Vim magic to
work.
Has anyone been able to get the 'termguicolors' option to work on xterm
or does xterm altogether lack the capability?
Tested with XTerm(327) on debian stable (stretch).
Thanks,
CJ
--
--
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.
How to use "syntax" method fold after conceal "#" symbol in Markdown file?
After I set conceallevel=3, "#" symbol is concealed, but the text can't be folded, why? And how to fix it?
ps: I have set foldmethod=syntax.
--
--
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.
ps: I have set foldmethod=syntax.
--
--
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] How to automatically check background color?
Zdenek wrote:
> I'm currently trying to write test script for checking background type
> (based on terminal color) in Vim. I have 'dark' terminal, so Vim
> normally recognizes it and sets 'background' to 'dark', but when I
> use:
>
> $ vim -c 'redir @">|silent set bg?|redir END|enew|put|w! testfile|q'
>
> then I have 'backgroung=light' (I think it is default, according some
> test scripts in src/testdir). Vim will probably communicate with
> terminal about background after my command is done, so the value is
> correct in fully loaded Vim... is there a way how to get correct value
> of 'background'?
Vim tries to obtain the background color from the terminal by sending
t_RB. So first check if t_RB is set.
This doesn't happen right away, thus Vim may first draw the windows
before the response comes. Then Vim will redraw if needed. You can
find the response in v:termrbgresp. You could set a timer to check for
the value and act accordingly. Or use an OptionSet autocommand to
trigger on 'background' changing.
--
Vi is clearly superior to emacs, since "vi" has only two characters
(and two keystrokes), while "emacs" has five. (Randy C. Ford)
/// 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.
> I'm currently trying to write test script for checking background type
> (based on terminal color) in Vim. I have 'dark' terminal, so Vim
> normally recognizes it and sets 'background' to 'dark', but when I
> use:
>
> $ vim -c 'redir @">|silent set bg?|redir END|enew|put|w! testfile|q'
>
> then I have 'backgroung=light' (I think it is default, according some
> test scripts in src/testdir). Vim will probably communicate with
> terminal about background after my command is done, so the value is
> correct in fully loaded Vim... is there a way how to get correct value
> of 'background'?
Vim tries to obtain the background color from the terminal by sending
t_RB. So first check if t_RB is set.
This doesn't happen right away, thus Vim may first draw the windows
before the response comes. Then Vim will redraw if needed. You can
find the response in v:termrbgresp. You could set a timer to check for
the value and act accordingly. Or use an OptionSet autocommand to
trigger on 'background' changing.
--
Vi is clearly superior to emacs, since "vi" has only two characters
(and two keystrokes), while "emacs" has five. (Randy C. Ford)
/// 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.
Friday, January 18, 2019
Re: How to conceal the "#" markdown symbol?
On Sat, Jan 19, 2019 at 6:25 AM Joey Ling <lingyao1986@gmail.com> wrote:
>
> 1. I want to conceal the "#" markdown symbol in all cases except when I start to edit the header line like the Typora style?
see :help conceal
>
> 2. What's the <ac> symbol in the toc buffer like the screenshot below and how to remove it?
>
> https://groups.google.com/group/pandoc-discuss/attach/113699c84bafcf/TIM%E6%88%AA%E5%9B%BE20190118145234.png?part=0.1&view=1&authuser=0
I think it represents the byte 0xAC and that that byte is not a
"printable character" in your 'encoding'.
See
:help 'display'
:help 'isprint'
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.
>
> 1. I want to conceal the "#" markdown symbol in all cases except when I start to edit the header line like the Typora style?
see :help conceal
>
> 2. What's the <ac> symbol in the toc buffer like the screenshot below and how to remove it?
>
> https://groups.google.com/group/pandoc-discuss/attach/113699c84bafcf/TIM%E6%88%AA%E5%9B%BE20190118145234.png?part=0.1&view=1&authuser=0
I think it represents the byte 0xAC and that that byte is not a
"printable character" in your 'encoding'.
See
:help 'display'
:help 'isprint'
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.
How to conceal the "#" markdown symbol?
1. I want to conceal the "#" markdown symbol in all cases except when I start to edit the header line like the Typora style?
2. What's the <ac> symbol in the toc buffer like the screenshot below and how to remove it?
https://groups.google.com/group/pandoc-discuss/attach/113699c84bafcf/TIM%E6%88%AA%E5%9B%BE20190118145234.png?part=0.1&view=1&authuser=0
--
--
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.
2. What's the <ac> symbol in the toc buffer like the screenshot below and how to remove it?
https://groups.google.com/group/pandoc-discuss/attach/113699c84bafcf/TIM%E6%88%AA%E5%9B%BE20190118145234.png?part=0.1&view=1&authuser=0
--
--
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.
shtags.pl
Hi Stephen,
just found your shtags script, thanks for that!
I wonder if we could adopt it to search for function calls also? It's
"simple commands" for shell.
Universal-ctags has special "reference" tags, which we could use with
your modified parser.
What do you think?
--
--
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.
just found your shtags script, thanks for that!
I wonder if we could adopt it to search for function calls also? It's
"simple commands" for shell.
Universal-ctags has special "reference" tags, which we could use with
your modified parser.
What do you think?
--
--
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] How to automatically check background color?
Hi!
I'm currently trying to write test script for checking background type (based on terminal color) in Vim. I have 'dark' terminal, so Vim normally recognizes it and sets 'background' to 'dark', but when I use:
$ vim -c 'redir @">|silent set bg?|redir END|enew|put|w! testfile|q'
then I have 'backgroung=light' (I think it is default, according some test scripts in src/testdir). Vim will probably communicate with terminal about background after my command is done, so the value is correct in fully loaded Vim... is there a way how to get correct value of 'background'?
Thank you in advance and have a nice day,
Zdenek
--
--
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.
I'm currently trying to write test script for checking background type (based on terminal color) in Vim. I have 'dark' terminal, so Vim normally recognizes it and sets 'background' to 'dark', but when I use:
$ vim -c 'redir @">|silent set bg?|redir END|enew|put|w! testfile|q'
then I have 'backgroung=light' (I think it is default, according some test scripts in src/testdir). Vim will probably communicate with terminal about background after my command is done, so the value is correct in fully loaded Vim... is there a way how to get correct value of 'background'?
Thank you in advance and have a nice day,
Zdenek
--
--
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.
Thursday, January 17, 2019
Re: Help! how to switch between visual mode and insert mode ?
在 2019年1月17日星期四 UTC+8下午11:51:45,Tony Mechelynck写道:
> On Thu, Jan 17, 2019 at 4:10 PM 王子陌 <wangzimo67james@gmail.com> wrote:
> >
> > Help! I want to get to visual mode when I'm in insert mode, the problem is:
> >
> > if there's a line:
> >
> > abcdefg
> >
> > When the cursor is at the end of the line and I use <ESC> to switch to normal mode and use v to visual mode, the cursor goes left, which made me unable to map a command that is universe.
> >
> > Help!
>
> AFAIK, <Esc> in Insert mode always moves the cursor left by one
> column, unless you're already at the left margin. However:
> 1. If 'virtualedit' is set to "onemore" you can move the cursor to one
> column past the last character without leaving Normal mode;
> 2. Or, regardless of how 'virtualedit' is set, if you're on the last
> character of the line in Normal mode, vlol will put you in Visual
> mode, with only the end-of-line (which is "one past" the last
> character on the line) selected, as follows:
> v go to characterwise visual
> l move right by one column
> o move cursor to the other end of the visual area
> l move right by one column
>
> Best regards,
> Tony.
Thank you so much! 'set virtualedit=onemore' worked perfectly!
For the second solution, it's great but will conflict when setting 'map', so I didn't use it in my settings.
Best regards,
王子陌
James
--
--
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.
> On Thu, Jan 17, 2019 at 4:10 PM 王子陌 <wangzimo67james@gmail.com> wrote:
> >
> > Help! I want to get to visual mode when I'm in insert mode, the problem is:
> >
> > if there's a line:
> >
> > abcdefg
> >
> > When the cursor is at the end of the line and I use <ESC> to switch to normal mode and use v to visual mode, the cursor goes left, which made me unable to map a command that is universe.
> >
> > Help!
>
> AFAIK, <Esc> in Insert mode always moves the cursor left by one
> column, unless you're already at the left margin. However:
> 1. If 'virtualedit' is set to "onemore" you can move the cursor to one
> column past the last character without leaving Normal mode;
> 2. Or, regardless of how 'virtualedit' is set, if you're on the last
> character of the line in Normal mode, vlol will put you in Visual
> mode, with only the end-of-line (which is "one past" the last
> character on the line) selected, as follows:
> v go to characterwise visual
> l move right by one column
> o move cursor to the other end of the visual area
> l move right by one column
>
> Best regards,
> Tony.
Thank you so much! 'set virtualedit=onemore' worked perfectly!
For the second solution, it's great but will conflict when setting 'map', so I didn't use it in my settings.
Best regards,
王子陌
James
--
--
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.
Syntax-highlighting last character in a line
Hello,
I am trying to transition to format=flowed for e-mails, which is
harder than it should be. I'd like to enlist vim to help me.
What I would like to achieve is to highlight any final characters of
a line that aren't spaces, i.e. /\S$/, unless the line is followed
by an empty line. The idea is that I I'll be visually alerted to
lines in paragraphs that don't fit the format=flowed structure.
Using "match Error /\S$/" works, but that also covers quotes,
signature, and header, where format=flowed doesn't really apply. And
it highlights the final character of the last line of a paragraph,
which it shouldn't.
I'd like to restrict the matching to just the plain text in the mail
body, more specifically to all but the last line of a paragraph
(where paragraphs are separated by an empty line).
This sounds like syntax highlighting to me.
Syntax highlighting for mails in Vim already knows when I am in the
plain text (synID == 0). How can I leverage this knowledge and add
a new syntax highlighting?
At this stage, I cannot even get any result out of
syn match mailBodyTrailingNonspace "/\S$"
and I would appreciate if anyone could provide me with any clues.
Thank you!
--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
"the truth is rarely pure and never simple. modern life would be very
tedious if it were either, and modern literature a complete
impossibility!"
-- oscar wilde
spamtraps: madduck.bogus@madduck.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.
I am trying to transition to format=flowed for e-mails, which is
harder than it should be. I'd like to enlist vim to help me.
What I would like to achieve is to highlight any final characters of
a line that aren't spaces, i.e. /\S$/, unless the line is followed
by an empty line. The idea is that I I'll be visually alerted to
lines in paragraphs that don't fit the format=flowed structure.
Using "match Error /\S$/" works, but that also covers quotes,
signature, and header, where format=flowed doesn't really apply. And
it highlights the final character of the last line of a paragraph,
which it shouldn't.
I'd like to restrict the matching to just the plain text in the mail
body, more specifically to all but the last line of a paragraph
(where paragraphs are separated by an empty line).
This sounds like syntax highlighting to me.
Syntax highlighting for mails in Vim already knows when I am in the
plain text (synID == 0). How can I leverage this knowledge and add
a new syntax highlighting?
At this stage, I cannot even get any result out of
syn match mailBodyTrailingNonspace "/\S$"
and I would appreciate if anyone could provide me with any clues.
Thank you!
--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
"the truth is rarely pure and never simple. modern life would be very
tedious if it were either, and modern literature a complete
impossibility!"
-- oscar wilde
spamtraps: madduck.bogus@madduck.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: Help! how to switch between visual mode and insert mode ?
On Thu, Jan 17, 2019 at 4:10 PM 王子陌 <wangzimo67james@gmail.com> wrote:
>
> Help! I want to get to visual mode when I'm in insert mode, the problem is:
>
> if there's a line:
>
> abcdefg
>
> When the cursor is at the end of the line and I use <ESC> to switch to normal mode and use v to visual mode, the cursor goes left, which made me unable to map a command that is universe.
>
> Help!
AFAIK, <Esc> in Insert mode always moves the cursor left by one
column, unless you're already at the left margin. However:
1. If 'virtualedit' is set to "onemore" you can move the cursor to one
column past the last character without leaving Normal mode;
2. Or, regardless of how 'virtualedit' is set, if you're on the last
character of the line in Normal mode, vlol will put you in Visual
mode, with only the end-of-line (which is "one past" the last
character on the line) selected, as follows:
v go to characterwise visual
l move right by one column
o move cursor to the other end of the visual area
l move right by one column
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.
>
> Help! I want to get to visual mode when I'm in insert mode, the problem is:
>
> if there's a line:
>
> abcdefg
>
> When the cursor is at the end of the line and I use <ESC> to switch to normal mode and use v to visual mode, the cursor goes left, which made me unable to map a command that is universe.
>
> Help!
AFAIK, <Esc> in Insert mode always moves the cursor left by one
column, unless you're already at the left margin. However:
1. If 'virtualedit' is set to "onemore" you can move the cursor to one
column past the last character without leaving Normal mode;
2. Or, regardless of how 'virtualedit' is set, if you're on the last
character of the line in Normal mode, vlol will put you in Visual
mode, with only the end-of-line (which is "one past" the last
character on the line) selected, as follows:
v go to characterwise visual
l move right by one column
o move cursor to the other end of the visual area
l move right by one column
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.