On 2015-05-31, Peng Yu wrote:
> Hi,
>
> The following command can not print the output in color format.
>
> vim -T dumb -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
>
> The following command can print the output in color format. But it
> also print a lot of empty lines.
>
> vim -T xterm-colors -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
>
> I just want to print the output in color with vim without print a lot
> of empty lines.
>
> I have tried to tput to check all the terminals in my system (Mac and
> Ubuntu). But it is hard to find what I want. Could anybody let me know
> there is such a terminal available? Thanks.
I think the problem is that when the terminal is not dumb, Vim first
clears the screen, then echoes your message. In my experimentation,
it appears to be the clearing of the screen that is generating the
extra lines you don't want.
Two approaches to a solution are: 1) start with a full terminal
description (e.g., xterm-color) and remove the capabilities that
allow Vim to clear the screen; 2) start with a dumb terminal and add
the capabilities that allow Vim to display text in color.
For #1, I tried this, which works within tmux running in a GNOME
Terminal but does not work in a GNOME Terminal alone.
vim --cmd 'set t_cl=' -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
For #2, I looked at
:help xterm-color
and added the termcap settings listed there. This seems to work,
but also colors the next shell prompt.
vim -T dumb --cmd 'set t_Co=8 t_Sf=^[[3%dm t_Sb=^[[4%dm' -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
HTH,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sunday, May 31, 2015
Re: How does vim determine the way the text is colored in the section of ":help group-name"?
On 2015-05-31, Peng Yu wrote:
> Hi,
>
> I see the following text in ":help group-name" colored. But when I
> checked the file syntax.txt, I didn't see anything special for
> indicating the colors. Could anybody let me know how vim determines
> the colors? Thanks.
>
> *Comment any comment
>
> *Constant any constant
[...]
> *Todo anything that needs extra attention; mostly the
> keywords TODO FIXME and XXX
The syntax highlighting of help files is controlled by the rules in
$VIMRUNTIME/syntax/help.vim. At line 95 (of version 2014 Feb 12) is
the comment
" Highlight group items in their own color.
followed by syn match rules with patterns that match the lines you
are asking about.
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> Hi,
>
> I see the following text in ":help group-name" colored. But when I
> checked the file syntax.txt, I didn't see anything special for
> indicating the colors. Could anybody let me know how vim determines
> the colors? Thanks.
>
> *Comment any comment
>
> *Constant any constant
[...]
> *Todo anything that needs extra attention; mostly the
> keywords TODO FIXME and XXX
The syntax highlighting of help files is controlled by the rules in
$VIMRUNTIME/syntax/help.vim. At line 95 (of version 2014 Feb 12) is
the comment
" Highlight group items in their own color.
followed by syn match rules with patterns that match the lines you
are asking about.
Regards,
Gary
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
ctrlsf.vim v1.0 has been released, edit mode added
Hi, I have released the latest version of ctrlsf.vim yesterday. In case somebody has never used it before, it is an interface of ack/ag like ack.vim or ag.vim, but shows result not in quickfix window but an individual buffer with more pretty printed context lines. In v1.0, I almost rewritted ctrlsf.vim (2600+ additions and 1000+ deletions) and have most legacy bugs fixed, along with an awesome edit mode! (inspired by vim-ags) It's so useful especially in refactoring that I can recommend to every vimmer with pride.
Github: https://github.com/dyng/ctrlsf.vim
vim.org: http://www.vim.org/scripts/script.php?script_id=5189
If you have any trouble or suggestion with ctrls.vim, feel free to open a new issue, and of course a pull request is so welcome.
--
-- Github: https://github.com/dyng/ctrlsf.vim
vim.org: http://www.vim.org/scripts/script.php?script_id=5189
If you have any trouble or suggestion with ctrls.vim, feel free to open a new issue, and of course a pull request is so welcome.
--
github: https://github.com/dyng
--
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: open file, go to last line, add blank line, change to insert
On Sunday, May 31, 2015 at 12:57:51 PM UTC-5, ZyX wrote:
> 2015-05-30 23:21 GMT+03:00 Rick Dooling
> > Hello,
> >
> > I frequently want to open a text file, go to the last line, open the fold, add one or two blank lines and begin writing.
> >
> > I'm trying to make an alias for vim that does this. Something like:
> >
> > alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
> >
> > Everything works except the attempt to put a blank line. No matter what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
>
> You need to learn how shell processes arguments
>
> `+pu=''` does not work because it is `+pu=`. Dunno why it does not
> give an error, but it is "put empty expression", not "put expressin
> that evaluates to an empty string".
>
> +$pu=' _' is `+= _` (actually, `+${pu}= _`, but I do not think you
> have variable named pu defined in shell; undefined variables expand to
> an empty string). Should give E488 because `=` command does not accept
> _ as an argument.
>
> @TimChase advice avoids escaping issues by creating a string that does
> not need to be escaped. But this is not always possible and if you
> want to know how to fix such issues check out advanced bash scripting
> guide. Quoting is described in
> http://www.tldp.org/LDP/abs/html/quoting.html.
>
> Note about aliases: `alias note={some string}` means "when 'note'
> appears to be a non-escaped separate command substitute 'note' with
> '{some string}'". {Some string} is also subject to various
> expansions/quote removals once at the time alias is being defined so
> you need to quote it so that the result of these expansions is itself
> properly quoted.
>
> >
> > Thanks for any help.
> >
> > Rick
> >
> > --
> > --
> > 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
> >
> > ---
> >
Thanks for the info. It is the type of thing I learn and then forget. Usually I am inside Vim. But this info very helpful.
Rick
--
--
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.
> 2015-05-30 23:21 GMT+03:00 Rick Dooling
> > Hello,
> >
> > I frequently want to open a text file, go to the last line, open the fold, add one or two blank lines and begin writing.
> >
> > I'm trying to make an alias for vim that does this. Something like:
> >
> > alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
> >
> > Everything works except the attempt to put a blank line. No matter what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
>
> You need to learn how shell processes arguments
>
> `+pu=''` does not work because it is `+pu=`. Dunno why it does not
> give an error, but it is "put empty expression", not "put expressin
> that evaluates to an empty string".
>
> +$pu=' _' is `+= _` (actually, `+${pu}= _`, but I do not think you
> have variable named pu defined in shell; undefined variables expand to
> an empty string). Should give E488 because `=` command does not accept
> _ as an argument.
>
> @TimChase advice avoids escaping issues by creating a string that does
> not need to be escaped. But this is not always possible and if you
> want to know how to fix such issues check out advanced bash scripting
> guide. Quoting is described in
> http://www.tldp.org/LDP/abs/html/quoting.html.
>
> Note about aliases: `alias note={some string}` means "when 'note'
> appears to be a non-escaped separate command substitute 'note' with
> '{some string}'". {Some string} is also subject to various
> expansions/quote removals once at the time alias is being defined so
> you need to quote it so that the result of these expansions is itself
> properly quoted.
>
> >
> > Thanks for any help.
> >
> > Rick
> >
> > --
> > --
> > 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
> >
> > ---
> >
Thanks for the info. It is the type of thing I learn and then forget. Usually I am inside Vim. But this info very helpful.
Rick
--
--
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.
Which terminal is similar to dumb but with color support? (for vim -T)
Hi,
The following command can not print the output in color format.
vim -T dumb -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
The following command can print the output in color format. But it
also print a lot of empty lines.
vim -T xterm-colors -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
I just want to print the output in color with vim without print a lot
of empty lines.
I have tried to tput to check all the terminals in my system (Mac and
Ubuntu). But it is hard to find what I want. Could anybody let me know
there is such a terminal available? 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.
The following command can not print the output in color format.
vim -T dumb -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
The following command can print the output in color format. But it
also print a lot of empty lines.
vim -T xterm-colors -c 'echohl ErrorMsg' -c 'echo "Hello World!"' -c q
I just want to print the output in color with vim without print a lot
of empty lines.
I have tried to tput to check all the terminals in my system (Mac and
Ubuntu). But it is hard to find what I want. Could anybody let me know
there is such a terminal available? 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.
How does vim determine the way the text is colored in the section of ":help group-name"?
Hi,
I see the following text in ":help group-name" colored. But when I
checked the file syntax.txt, I didn't see anything special for
indicating the colors. Could anybody let me know how vim determines
the colors? Thanks.
*Comment any comment
*Constant any constant
String a string constant: "this is a string"
Character a character constant: 'c', '\n'
Number a number constant: 234, 0xff
Boolean a boolean constant: TRUE, false
Float a floating point constant: 2.3e10
*Identifier any variable name
Function function name (also: methods for classes)
*Statement any statement
Conditional if, then, else, endif, switch, etc.
Repeat for, do, while, etc.
Label case, default, etc.
Operator "sizeof", "+", "*", etc.
Keyword any other keyword
Exception try, catch, throw
*PreProc generic Preprocessor
Include preprocessor #include
Define preprocessor #define
Macro same as Define
PreCondit preprocessor #if, #else,
I see the following text in ":help group-name" colored. But when I
checked the file syntax.txt, I didn't see anything special for
indicating the colors. Could anybody let me know how vim determines
the colors? Thanks.
*Comment any comment
*Constant any constant
String a string constant: "this is a string"
Character a character constant: 'c', '\n'
Number a number constant: 234, 0xff
Boolean a boolean constant: TRUE, false
Float a floating point constant: 2.3e10
*Identifier any variable name
Function function name (also: methods for classes)
*Statement any statement
Conditional if, then, else, endif, switch, etc.
Repeat for, do, while, etc.
Label case, default, etc.
Operator "sizeof", "+", "*", etc.
Keyword any other keyword
Exception try, catch, throw
*PreProc generic Preprocessor
Include preprocessor #include
Define preprocessor #define
Macro same as Define
PreCondit preprocessor #if, #else,
Re: My approach to a custom status line
On 2015-05-31 02:56:13 +0000, Rick Dooling said:
> Have you ever tried vim-airline?
Sure, I have used it since not long ago, and it's very nice. But now I have
more or less the same amount of configuration code in my vimrc, and a
plugin less.
Nicola
--
--
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.
> Have you ever tried vim-airline?
Sure, I have used it since not long ago, and it's very nice. But now I have
more or less the same amount of configuration code in my vimrc, and a
plugin less.
Nicola
--
--
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: open file, go to last line, add blank line, change to insert
2015-05-30 23:21 GMT+03:00 Rick Dooling <rpdooling@gmail.com>:
> Hello,
>
> I frequently want to open a text file, go to the last line, open the fold, add one or two blank lines and begin writing.
>
> I'm trying to make an alias for vim that does this. Something like:
>
> alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
>
> Everything works except the attempt to put a blank line. No matter what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
You need to learn how shell processes arguments
`+pu=''` does not work because it is `+pu=`. Dunno why it does not
give an error, but it is "put empty expression", not "put expressin
that evaluates to an empty string".
+$pu=' _' is `+= _` (actually, `+${pu}= _`, but I do not think you
have variable named pu defined in shell; undefined variables expand to
an empty string). Should give E488 because `=` command does not accept
_ as an argument.
@TimChase advice avoids escaping issues by creating a string that does
not need to be escaped. But this is not always possible and if you
want to know how to fix such issues check out advanced bash scripting
guide. Quoting is described in
http://www.tldp.org/LDP/abs/html/quoting.html.
Note about aliases: `alias note={some string}` means "when 'note'
appears to be a non-escaped separate command substitute 'note' with
'{some string}'". {Some string} is also subject to various
expansions/quote removals once at the time alias is being defined so
you need to quote it so that the result of these expansions is itself
properly quoted.
>
> Thanks for any help.
>
> Rick
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> Hello,
>
> I frequently want to open a text file, go to the last line, open the fold, add one or two blank lines and begin writing.
>
> I'm trying to make an alias for vim that does this. Something like:
>
> alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
>
> Everything works except the attempt to put a blank line. No matter what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
You need to learn how shell processes arguments
`+pu=''` does not work because it is `+pu=`. Dunno why it does not
give an error, but it is "put empty expression", not "put expressin
that evaluates to an empty string".
+$pu=' _' is `+= _` (actually, `+${pu}= _`, but I do not think you
have variable named pu defined in shell; undefined variables expand to
an empty string). Should give E488 because `=` command does not accept
_ as an argument.
@TimChase advice avoids escaping issues by creating a string that does
not need to be escaped. But this is not always possible and if you
want to know how to fix such issues check out advanced bash scripting
guide. Quoting is described in
http://www.tldp.org/LDP/abs/html/quoting.html.
Note about aliases: `alias note={some string}` means "when 'note'
appears to be a non-escaped separate command substitute 'note' with
'{some string}'". {Some string} is also subject to various
expansions/quote removals once at the time alias is being defined so
you need to quote it so that the result of these expansions is itself
properly quoted.
>
> Thanks for any help.
>
> Rick
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: What is the difference between using multiple -c options and concatenating the options with newline as the separator? (autocmd)
2015-05-31 17:57 GMT+03:00 Peng Yu <pengyu.ut@gmail.com>:
> The following vim command lines show different results. Could anybody
> help me understand why there is a difference? Thanks.
>
> $ vim -T dumb -c autocmd\ BufWrite\ \*\ echom\ \"Writing\ buffer\!\"
> -c w -c messages -c q
> /var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
>
> "/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
> "/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
> 0L, 0C written
> Messages maintainer: Bram Moolenaar <Bram@vim.org>
> "/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
> Writing buffer!
> "/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
> 0L, 0C written
> $ vim -T dumb -c $'autocmd BufWrite * echom "Writing
> buffer!"\nw\nmessages' -c q
> /var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
>
> "/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
-c context is same as in `:execute`. I do not know whether you can
find this in help, but
1. When reading from file \n is "string end". `\` at the start of the
next line joins current line with the next, but it is handled by some
kind of preprocessor. Except for some rare cases Ex commands end also
when string ends.
2. When using :execute \n is "command separator". Follows nearly the
same rules as `|` regarding separating commands. Since `:autocmd`
cannot be separated from another command using bar first variant is
like `autocmd BufWrite * echomsg "Writing buffer!" | write |
messages`: `write` and `messages` commands are part of the autocmd.
>
> --
> 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.
--
--
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.
> The following vim command lines show different results. Could anybody
> help me understand why there is a difference? Thanks.
>
> $ vim -T dumb -c autocmd\ BufWrite\ \*\ echom\ \"Writing\ buffer\!\"
> -c w -c messages -c q
> /var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
>
> "/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
> "/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
> 0L, 0C written
> Messages maintainer: Bram Moolenaar <Bram@vim.org>
> "/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
> Writing buffer!
> "/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
> 0L, 0C written
> $ vim -T dumb -c $'autocmd BufWrite * echom "Writing
> buffer!"\nw\nmessages' -c q
> /var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
>
> "/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
-c context is same as in `:execute`. I do not know whether you can
find this in help, but
1. When reading from file \n is "string end". `\` at the start of the
next line joins current line with the next, but it is handled by some
kind of preprocessor. Except for some rare cases Ex commands end also
when string ends.
2. When using :execute \n is "command separator". Follows nearly the
same rules as `|` regarding separating commands. Since `:autocmd`
cannot be separated from another command using bar first variant is
like `autocmd BufWrite * echomsg "Writing buffer!" | write |
messages`: `write` and `messages` commands are part of the autocmd.
>
> --
> 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.
--
--
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.
What is the difference between using multiple -c options and concatenating the options with newline as the separator? (autocmd)
The following vim command lines show different results. Could anybody
help me understand why there is a difference? Thanks.
$ vim -T dumb -c autocmd\ BufWrite\ \*\ echom\ \"Writing\ buffer\!\"
-c w -c messages -c q
/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
"/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
"/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
0L, 0C written
Messages maintainer: Bram Moolenaar <Bram@vim.org>
"/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
Writing buffer!
"/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
0L, 0C written
$ vim -T dumb -c $'autocmd BufWrite * echom "Writing
buffer!"\nw\nmessages' -c q
/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
"/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
--
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.
help me understand why there is a difference? Thanks.
$ vim -T dumb -c autocmd\ BufWrite\ \*\ echom\ \"Writing\ buffer\!\"
-c w -c messages -c q
/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
"/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
"/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
0L, 0C written
Messages maintainer: Bram Moolenaar <Bram@vim.org>
"/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
Writing buffer!
"/private/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD"
0L, 0C written
$ vim -T dumb -c $'autocmd BufWrite * echom "Writing
buffer!"\nw\nmessages' -c q
/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD
"/var/folders/r7/bvmh1vvx41d63snvgbdz7bl40000gr/T/tmp.ZICAEj0GJD" 0L, 0C
--
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.
configure options in :version
Could the configure options be embedded into the :version output? :version shows the options, but not in a format that can be cut-n-pasted back into a configure command. This would allow someone to (more) easily duplicate how a previous version of vim was compiled.
[cue someone showing a simple way to already get 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.
[cue someone showing a simple way to already get 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.
Saturday, May 30, 2015
Re: Any poets here?
On Friday, January 30, 2015 at 1:58:02 PM UTC-6, Eric Weir wrote:
> Wondering if there are any poets here who use vim in writing poetry, either in the messy creative phase or the later refining, polishing, and editing phase. If so, I'd be interested in knowing how you use vim, how you find vim helpful, and whether there are any plugins that you have found especially helpful.
>
> And if any non-poets here know of poets who use vim who are not here, I'd appreciate a reference.
>
> Thanks,
> ------------------------------------------------------------------------------------------
> Eric Weir
> Decatur, GA USA
>
> "Our world is a human world."
>
> - Hilary Putnam
I've written two novels, many screenplays and teleplays, and a nonfiction book in Vim, later MacVim. I write all my exams (I teach law) in Vim. I write everything in Vim. It's a perfect tool. And now that we have Markdown (Commonmark) and Fountain (Markdown for screenwriters) it's even better.
Rick
--
--
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.
> Wondering if there are any poets here who use vim in writing poetry, either in the messy creative phase or the later refining, polishing, and editing phase. If so, I'd be interested in knowing how you use vim, how you find vim helpful, and whether there are any plugins that you have found especially helpful.
>
> And if any non-poets here know of poets who use vim who are not here, I'd appreciate a reference.
>
> Thanks,
> ------------------------------------------------------------------------------------------
> Eric Weir
> Decatur, GA USA
>
> "Our world is a human world."
>
> - Hilary Putnam
I've written two novels, many screenplays and teleplays, and a nonfiction book in Vim, later MacVim. I write all my exams (I teach law) in Vim. I write everything in Vim. It's a perfect tool. And now that we have Markdown (Commonmark) and Fountain (Markdown for screenwriters) it's even better.
Rick
--
--
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: My approach to a custom status line
On Saturday, May 30, 2015 at 3:45:07 PM UTC-5, Nicola wrote:
> Hi,
> I have recently re-implemented my status line from scratch. Since getting
> to my (hopefully final) solution took a while (and help from this group) I'm
> giving back my approach, in the hope that it may be useful to other
> non-expert Vim users, and maybe to get feedback to improve it even further.
> If you don't feel like reading this somewhat lengthy post, my code is here:
>
> https://github.com/lifepillar/lifepillar-vim-config/blob/master/vimrc#L480
>
> My requirements for a status line are as follows:
>
> 1. show slightly different information for active and inactive status lines;
> 2. display the current mode in the active status line;
> 3. color some parts of the active status line with a second color (besides
> the background) that depends on the current mode;
> 4. do not render everything slow as hell :)
>
> After trying at least three different ways to reach such goals, with varying
> amounts of bugs, and following some advice from the group, I have
> decided to keep it simple, which means:
>
> 1. set g:statusline once, and never redefine it;
> 2. do not use l:statusline, so that plugins (e.g., CtrlP) can override my
> status line without the need for me to add custom logic depending on
> the plugin;
> 3. try to avoid Ex-mode for performance;
> 4. do not maintain buffer or window variables;
> 5. do not use autocommands.
>
> Avoiding 4 and 5 almost surely means avoiding subtle bugs that are hard
> to fix (at least for me).
>
> The main problem is: how does a function that builds a status line know
> whether it is building the status line for the active window? This is
> not trivial
> because (see :h statusline), winnr() is evaluated differently depending on the
> context. Instead of fighting against Vim, I have decided to follow its logic,
> which inevitably leads to define:
>
> set statusline=%!BuildStatusLine(winnr())
>
> Here, winnr() is always the number of the currently *active* window.
> As far as I know, there is no way for BuildStatusLine() to know which window
> it is building a status line for, but it can put the information it knows
> (the number of the active window) into the status line's string. So,
> the minimal
> BuildStatusLine() is:
>
> func! BuildStatusLine(nr)
> return '%{ReallyBuildStatusLine(' . a:nr . ')}'
> endfunc
>
> Since ReallyBuildStatusLine() is evaluated in %{} context, winnr() returns the
> number of the window *that the status line belongs to*. So, a minimal
> implementation is:
>
> func! ReallyBuildStatusLine(nr)
> if (winnr() == a:nr)
> " return active status line
> else
> " return inactive status line
> endif
> endfunc
>
> Discovering that things were this simple was a "a-ha" moment for me. Of course,
> things are not that simple :) If all you want is putting different
> strings in different
> status lines, this is all you need, as far as I can see. But if you want to use
> '%' items, say highlight groups, you'll soon discover that you cannot use them
> in the latter function, because they will be taken as literal strings and not
> interpolated.
>
> To solve this problem, at first I have used a trick like this:
>
> func! SomeText(nr, flag)
> return (winnr() == a:nr) ? (flag ? 'text' : '') : (flag ? '' : 'text')
> endfunc
>
> func! BuildStatusLine(nr)
> return '%#MyHighlight#%{SomeText(' . a:nr . ',1)}%*%{SomeText(' .
> a:nr . ',0)}...'
> endfunc
>
> It works, but it's ugly. Eventually, I decided to redefine a highlight
> group on-the-fly:
>
> func! SetHighlight(nr)
> if (winnr() == a:nr)
> hi! link StlHighlight MyHighlight
> else
> hi! link StlHighlight StatusLineNC
> endif
> return ''
> endfunc
>
> func! BuildStatusLine(nr)
> return '%{SetHighlight(' . a:nr . ')}%#StlHighlight#%{SomeText()}%*...'
> endfunc
>
> I thought this would be slow, but in my (limited) benchmarks this seems
> to perform
> quite well.
>
> So, in the end, I have a bi-colored collapsible status line highlighting the
> current mode (and showing other information), which can be drawn in 1.5x-2x
> time compared to a basic status line. My approach may not be general enough
> to cover all use cases, but I'm pretty satisfied with it! If you know
> how I can do
> better than this, please let me know!
>
> Nicola
Have you ever tried vim-airline?
https://github.com/bling/vim-airline
--
--
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.
> Hi,
> I have recently re-implemented my status line from scratch. Since getting
> to my (hopefully final) solution took a while (and help from this group) I'm
> giving back my approach, in the hope that it may be useful to other
> non-expert Vim users, and maybe to get feedback to improve it even further.
> If you don't feel like reading this somewhat lengthy post, my code is here:
>
> https://github.com/lifepillar/lifepillar-vim-config/blob/master/vimrc#L480
>
> My requirements for a status line are as follows:
>
> 1. show slightly different information for active and inactive status lines;
> 2. display the current mode in the active status line;
> 3. color some parts of the active status line with a second color (besides
> the background) that depends on the current mode;
> 4. do not render everything slow as hell :)
>
> After trying at least three different ways to reach such goals, with varying
> amounts of bugs, and following some advice from the group, I have
> decided to keep it simple, which means:
>
> 1. set g:statusline once, and never redefine it;
> 2. do not use l:statusline, so that plugins (e.g., CtrlP) can override my
> status line without the need for me to add custom logic depending on
> the plugin;
> 3. try to avoid Ex-mode for performance;
> 4. do not maintain buffer or window variables;
> 5. do not use autocommands.
>
> Avoiding 4 and 5 almost surely means avoiding subtle bugs that are hard
> to fix (at least for me).
>
> The main problem is: how does a function that builds a status line know
> whether it is building the status line for the active window? This is
> not trivial
> because (see :h statusline), winnr() is evaluated differently depending on the
> context. Instead of fighting against Vim, I have decided to follow its logic,
> which inevitably leads to define:
>
> set statusline=%!BuildStatusLine(winnr())
>
> Here, winnr() is always the number of the currently *active* window.
> As far as I know, there is no way for BuildStatusLine() to know which window
> it is building a status line for, but it can put the information it knows
> (the number of the active window) into the status line's string. So,
> the minimal
> BuildStatusLine() is:
>
> func! BuildStatusLine(nr)
> return '%{ReallyBuildStatusLine(' . a:nr . ')}'
> endfunc
>
> Since ReallyBuildStatusLine() is evaluated in %{} context, winnr() returns the
> number of the window *that the status line belongs to*. So, a minimal
> implementation is:
>
> func! ReallyBuildStatusLine(nr)
> if (winnr() == a:nr)
> " return active status line
> else
> " return inactive status line
> endif
> endfunc
>
> Discovering that things were this simple was a "a-ha" moment for me. Of course,
> things are not that simple :) If all you want is putting different
> strings in different
> status lines, this is all you need, as far as I can see. But if you want to use
> '%' items, say highlight groups, you'll soon discover that you cannot use them
> in the latter function, because they will be taken as literal strings and not
> interpolated.
>
> To solve this problem, at first I have used a trick like this:
>
> func! SomeText(nr, flag)
> return (winnr() == a:nr) ? (flag ? 'text' : '') : (flag ? '' : 'text')
> endfunc
>
> func! BuildStatusLine(nr)
> return '%#MyHighlight#%{SomeText(' . a:nr . ',1)}%*%{SomeText(' .
> a:nr . ',0)}...'
> endfunc
>
> It works, but it's ugly. Eventually, I decided to redefine a highlight
> group on-the-fly:
>
> func! SetHighlight(nr)
> if (winnr() == a:nr)
> hi! link StlHighlight MyHighlight
> else
> hi! link StlHighlight StatusLineNC
> endif
> return ''
> endfunc
>
> func! BuildStatusLine(nr)
> return '%{SetHighlight(' . a:nr . ')}%#StlHighlight#%{SomeText()}%*...'
> endfunc
>
> I thought this would be slow, but in my (limited) benchmarks this seems
> to perform
> quite well.
>
> So, in the end, I have a bi-colored collapsible status line highlighting the
> current mode (and showing other information), which can be drawn in 1.5x-2x
> time compared to a basic status line. My approach may not be general enough
> to cover all use cases, but I'm pretty satisfied with it! If you know
> how I can do
> better than this, please let me know!
>
> Nicola
Have you ever tried vim-airline?
https://github.com/bling/vim-airline
--
--
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.
[bug] CSApprox plugin gives error building Vim-7.4.729 without GUI support
Hi
I'm using the latest CSApprox plugin 4.0 from Matt Wozniski (in CC)
available at http://www.vim.org/scripts/script.php?script_id=2390
The plugin works fine when I have ":colorscheme ..." in my ~/.vimrc.
However, I noticed a problem which happens with vim-7.4.729 or
older If I don't put the ":colorscheme ..." command in my ~/.vimrc,
or if I just use an empty ~/.vimrc, I then get these errors when
starting vim:
===
Error detected while processing function
<SNR>2_CSApprox..<SNR>2_CSApproxImpl..<SNR>2_FixupGuiInfo:
line 1:
E716: Key not present in Dictionary: 0
E15: Invalid expression: a:highlights[s:hlid_normal].gui.bg == ''
Error detected while processing /home/pel/.vim/after/plugin/CSApprox.vim:
line 28:
E171: Missing :endif
Press ENTER or type command to continue
===
If do "vim foo.txt" then not only do I get the above error, but the
file foo.txt is also not loaded.
Investigating, I found that I get these errors if I build vim without
GUI support i.e.:
./configure --with-features=huge --enable-gui=none
I don't get the errors if I build with the GUI, i.e.:
./configure --with-features=huge --enable-gui=gtk2
In the help file CSApprox.txt, I read:
===
2. Requirements *csapprox-requirements*
For CSApprox to work, there are 2 major requirements that must be met.
a) GUI support (or vim >= 7.3) *csapprox-gui-support* *csapprox-+gui*
NOTE This section only applies to vim versions before 7.3.000 - a modern vim
does not need GUI support in order for CSApprox to function.
===
Since I use Vim-7.4.729, I would thus expect CSApprox to
work fine without GUI support, but somehow there is a bug.
Regards
Dominique
--
--
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 using the latest CSApprox plugin 4.0 from Matt Wozniski (in CC)
available at http://www.vim.org/scripts/script.php?script_id=2390
The plugin works fine when I have ":colorscheme ..." in my ~/.vimrc.
However, I noticed a problem which happens with vim-7.4.729 or
older If I don't put the ":colorscheme ..." command in my ~/.vimrc,
or if I just use an empty ~/.vimrc, I then get these errors when
starting vim:
===
Error detected while processing function
<SNR>2_CSApprox..<SNR>2_CSApproxImpl..<SNR>2_FixupGuiInfo:
line 1:
E716: Key not present in Dictionary: 0
E15: Invalid expression: a:highlights[s:hlid_normal].gui.bg == ''
Error detected while processing /home/pel/.vim/after/plugin/CSApprox.vim:
line 28:
E171: Missing :endif
Press ENTER or type command to continue
===
If do "vim foo.txt" then not only do I get the above error, but the
file foo.txt is also not loaded.
Investigating, I found that I get these errors if I build vim without
GUI support i.e.:
./configure --with-features=huge --enable-gui=none
I don't get the errors if I build with the GUI, i.e.:
./configure --with-features=huge --enable-gui=gtk2
In the help file CSApprox.txt, I read:
===
2. Requirements *csapprox-requirements*
For CSApprox to work, there are 2 major requirements that must be met.
a) GUI support (or vim >= 7.3) *csapprox-gui-support* *csapprox-+gui*
NOTE This section only applies to vim versions before 7.3.000 - a modern vim
does not need GUI support in order for CSApprox to function.
===
Since I use Vim-7.4.729, I would thus expect CSApprox to
work fine without GUI support, but somehow there is a bug.
Regards
Dominique
--
--
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: open file, go to last line, add blank line, change to insert
On Saturday, May 30, 2015 at 3:50:31 PM UTC-5, Tim Chase wrote:
> On 2015-05-30 13:21, Rick Dooling wrote:
> > alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
> >
> > Everything works except the attempt to put a blank line. No matter
> > what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
>
> Try
>
> +put_
>
> instead. :-)
>
> -tim
Presto!
Thanks, 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.
> On 2015-05-30 13:21, Rick Dooling wrote:
> > alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
> >
> > Everything works except the attempt to put a blank line. No matter
> > what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
>
> Try
>
> +put_
>
> instead. :-)
>
> -tim
Presto!
Thanks, 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: quotation text object consternation
Hi Tim!
On Fr, 29 Mai 2015, Tim Chase wrote:
> One of the oddball frustrations I find with vim is that the
> outer-quotation objects eats leading space.
>
> To demonstrate the inconsistency, use the following document
>
> (parens)
> [square brackets]
> {braces}
> "double quotes"
> 'single quotes"
>
> and indent it (unless you copied the leading whitespace too)
>
> :%>
>
> then, on each line, use the associated outer-text-object to change it:
>
> ca(xxx<esc>
> ca[xxx<esc>
> ca{xxx<esc>
> ca"xxx<esc>
> ca'xxx<esc>
>
> Note how the ones with quotes also get un-indented while the others
> don't. I encounter this most frequently when coding in Python where
> I have something like
>
> my_map = {
> "foo": "bar",
> "baz": "whinge",
> "fred": "barney",
> }
>
> and I want to change the keys to constants:
>
> FOO = "foo"
> my_map = {
> FOO: "bar",
> # ...
> }
>
> so I go to the quote object and do
>
> ca"FOO<esc>
>
> only to then need to re-indent it back to the original level (not so
> bad if it's single indent, but when it's multiple levels, it's a
> pain). I've *never* had the eating-of-leading-whitespace as a desired
> behavior.
>
> Is there a way to make this consistent with the other "a" text
> objects? Some option I've missed?
I am not sure. But let's look at the documentation:
,----[ :h text-object (and scroll down a bit) ]-
| For non-block objects:
| For the "a" commands: The operator applies to the object and the white
| space after the object. If there is no white space after the object
| or when the cursor was in the white space before the object, the white
| space before the object is included.
`----
Here is an idea:
Perhaps you can try to always put some whitespace after the quotes, so
that accessing the objects won't use the whitespace in front of it.
Then doing ca' will not un-indent the object. Perhaps, you could even
map that to a function that first adds whitespace before trying to
access that object?
Best,
Christian
--
Was zugunsten des Staates begonnen wird, geht oft zuungunsten der Welt
aus.
-- Karl Kraus
--
--
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 Fr, 29 Mai 2015, Tim Chase wrote:
> One of the oddball frustrations I find with vim is that the
> outer-quotation objects eats leading space.
>
> To demonstrate the inconsistency, use the following document
>
> (parens)
> [square brackets]
> {braces}
> "double quotes"
> 'single quotes"
>
> and indent it (unless you copied the leading whitespace too)
>
> :%>
>
> then, on each line, use the associated outer-text-object to change it:
>
> ca(xxx<esc>
> ca[xxx<esc>
> ca{xxx<esc>
> ca"xxx<esc>
> ca'xxx<esc>
>
> Note how the ones with quotes also get un-indented while the others
> don't. I encounter this most frequently when coding in Python where
> I have something like
>
> my_map = {
> "foo": "bar",
> "baz": "whinge",
> "fred": "barney",
> }
>
> and I want to change the keys to constants:
>
> FOO = "foo"
> my_map = {
> FOO: "bar",
> # ...
> }
>
> so I go to the quote object and do
>
> ca"FOO<esc>
>
> only to then need to re-indent it back to the original level (not so
> bad if it's single indent, but when it's multiple levels, it's a
> pain). I've *never* had the eating-of-leading-whitespace as a desired
> behavior.
>
> Is there a way to make this consistent with the other "a" text
> objects? Some option I've missed?
I am not sure. But let's look at the documentation:
,----[ :h text-object (and scroll down a bit) ]-
| For non-block objects:
| For the "a" commands: The operator applies to the object and the white
| space after the object. If there is no white space after the object
| or when the cursor was in the white space before the object, the white
| space before the object is included.
`----
Here is an idea:
Perhaps you can try to always put some whitespace after the quotes, so
that accessing the objects won't use the whitespace in front of it.
Then doing ca' will not un-indent the object. Perhaps, you could even
map that to a function that first adds whitespace before trying to
access that object?
Best,
Christian
--
Was zugunsten des Staates begonnen wird, geht oft zuungunsten der Welt
aus.
-- Karl Kraus
--
--
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: open file, go to last line, add blank line, change to insert
On 2015-05-30 13:21, Rick Dooling wrote:
> alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
>
> Everything works except the attempt to put a blank line. No matter
> what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
Try
+put_
instead. :-)
-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.
> alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
>
> Everything works except the attempt to put a blank line. No matter
> what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
Try
+put_
instead. :-)
-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.
My approach to a custom status line
Hi,
I have recently re-implemented my status line from scratch. Since getting
to my (hopefully final) solution took a while (and help from this group) I'm
giving back my approach, in the hope that it may be useful to other
non-expert Vim users, and maybe to get feedback to improve it even further.
If you don't feel like reading this somewhat lengthy post, my code is here:
https://github.com/lifepillar/lifepillar-vim-config/blob/master/vimrc#L480
My requirements for a status line are as follows:
1. show slightly different information for active and inactive status lines;
2. display the current mode in the active status line;
3. color some parts of the active status line with a second color (besides
the background) that depends on the current mode;
4. do not render everything slow as hell :)
After trying at least three different ways to reach such goals, with varying
amounts of bugs, and following some advice from the group, I have
decided to keep it simple, which means:
1. set g:statusline once, and never redefine it;
2. do not use l:statusline, so that plugins (e.g., CtrlP) can override my
status line without the need for me to add custom logic depending on
the plugin;
3. try to avoid Ex-mode for performance;
4. do not maintain buffer or window variables;
5. do not use autocommands.
Avoiding 4 and 5 almost surely means avoiding subtle bugs that are hard
to fix (at least for me).
The main problem is: how does a function that builds a status line know
whether it is building the status line for the active window? This is
not trivial
because (see :h statusline), winnr() is evaluated differently depending on the
context. Instead of fighting against Vim, I have decided to follow its logic,
which inevitably leads to define:
set statusline=%!BuildStatusLine(winnr())
Here, winnr() is always the number of the currently *active* window.
As far as I know, there is no way for BuildStatusLine() to know which window
it is building a status line for, but it can put the information it knows
(the number of the active window) into the status line's string. So,
the minimal
BuildStatusLine() is:
func! BuildStatusLine(nr)
return '%{ReallyBuildStatusLine(' . a:nr . ')}'
endfunc
Since ReallyBuildStatusLine() is evaluated in %{} context, winnr() returns the
number of the window *that the status line belongs to*. So, a minimal
implementation is:
func! ReallyBuildStatusLine(nr)
if (winnr() == a:nr)
" return active status line
else
" return inactive status line
endif
endfunc
Discovering that things were this simple was a "a-ha" moment for me. Of course,
things are not that simple :) If all you want is putting different
strings in different
status lines, this is all you need, as far as I can see. But if you want to use
'%' items, say highlight groups, you'll soon discover that you cannot use them
in the latter function, because they will be taken as literal strings and not
interpolated.
To solve this problem, at first I have used a trick like this:
func! SomeText(nr, flag)
return (winnr() == a:nr) ? (flag ? 'text' : '') : (flag ? '' : 'text')
endfunc
func! BuildStatusLine(nr)
return '%#MyHighlight#%{SomeText(' . a:nr . ',1)}%*%{SomeText(' .
a:nr . ',0)}...'
endfunc
It works, but it's ugly. Eventually, I decided to redefine a highlight
group on-the-fly:
func! SetHighlight(nr)
if (winnr() == a:nr)
hi! link StlHighlight MyHighlight
else
hi! link StlHighlight StatusLineNC
endif
return ''
endfunc
func! BuildStatusLine(nr)
return '%{SetHighlight(' . a:nr . ')}%#StlHighlight#%{SomeText()}%*...'
endfunc
I thought this would be slow, but in my (limited) benchmarks this seems
to perform
quite well.
So, in the end, I have a bi-colored collapsible status line highlighting the
current mode (and showing other information), which can be drawn in 1.5x-2x
time compared to a basic status line. My approach may not be general enough
to cover all use cases, but I'm pretty satisfied with it! If you know
how I can do
better than this, please let me know!
Nicola
--
--
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 have recently re-implemented my status line from scratch. Since getting
to my (hopefully final) solution took a while (and help from this group) I'm
giving back my approach, in the hope that it may be useful to other
non-expert Vim users, and maybe to get feedback to improve it even further.
If you don't feel like reading this somewhat lengthy post, my code is here:
https://github.com/lifepillar/lifepillar-vim-config/blob/master/vimrc#L480
My requirements for a status line are as follows:
1. show slightly different information for active and inactive status lines;
2. display the current mode in the active status line;
3. color some parts of the active status line with a second color (besides
the background) that depends on the current mode;
4. do not render everything slow as hell :)
After trying at least three different ways to reach such goals, with varying
amounts of bugs, and following some advice from the group, I have
decided to keep it simple, which means:
1. set g:statusline once, and never redefine it;
2. do not use l:statusline, so that plugins (e.g., CtrlP) can override my
status line without the need for me to add custom logic depending on
the plugin;
3. try to avoid Ex-mode for performance;
4. do not maintain buffer or window variables;
5. do not use autocommands.
Avoiding 4 and 5 almost surely means avoiding subtle bugs that are hard
to fix (at least for me).
The main problem is: how does a function that builds a status line know
whether it is building the status line for the active window? This is
not trivial
because (see :h statusline), winnr() is evaluated differently depending on the
context. Instead of fighting against Vim, I have decided to follow its logic,
which inevitably leads to define:
set statusline=%!BuildStatusLine(winnr())
Here, winnr() is always the number of the currently *active* window.
As far as I know, there is no way for BuildStatusLine() to know which window
it is building a status line for, but it can put the information it knows
(the number of the active window) into the status line's string. So,
the minimal
BuildStatusLine() is:
func! BuildStatusLine(nr)
return '%{ReallyBuildStatusLine(' . a:nr . ')}'
endfunc
Since ReallyBuildStatusLine() is evaluated in %{} context, winnr() returns the
number of the window *that the status line belongs to*. So, a minimal
implementation is:
func! ReallyBuildStatusLine(nr)
if (winnr() == a:nr)
" return active status line
else
" return inactive status line
endif
endfunc
Discovering that things were this simple was a "a-ha" moment for me. Of course,
things are not that simple :) If all you want is putting different
strings in different
status lines, this is all you need, as far as I can see. But if you want to use
'%' items, say highlight groups, you'll soon discover that you cannot use them
in the latter function, because they will be taken as literal strings and not
interpolated.
To solve this problem, at first I have used a trick like this:
func! SomeText(nr, flag)
return (winnr() == a:nr) ? (flag ? 'text' : '') : (flag ? '' : 'text')
endfunc
func! BuildStatusLine(nr)
return '%#MyHighlight#%{SomeText(' . a:nr . ',1)}%*%{SomeText(' .
a:nr . ',0)}...'
endfunc
It works, but it's ugly. Eventually, I decided to redefine a highlight
group on-the-fly:
func! SetHighlight(nr)
if (winnr() == a:nr)
hi! link StlHighlight MyHighlight
else
hi! link StlHighlight StatusLineNC
endif
return ''
endfunc
func! BuildStatusLine(nr)
return '%{SetHighlight(' . a:nr . ')}%#StlHighlight#%{SomeText()}%*...'
endfunc
I thought this would be slow, but in my (limited) benchmarks this seems
to perform
quite well.
So, in the end, I have a bi-colored collapsible status line highlighting the
current mode (and showing other information), which can be drawn in 1.5x-2x
time compared to a basic status line. My approach may not be general enough
to cover all use cases, but I'm pretty satisfied with it! If you know
how I can do
better than this, please let me know!
Nicola
--
--
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.
open file, go to last line, add blank line, change to insert
Hello,
I frequently want to open a text file, go to the last line, open the fold, add one or two blank lines and begin writing.
I'm trying to make an alias for vim that does this. Something like:
alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
Everything works except the attempt to put a blank line. No matter what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
Thanks for any help.
Rick
--
--
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 frequently want to open a text file, go to the last line, open the fold, add one or two blank lines and begin writing.
I'm trying to make an alias for vim that does this. Something like:
alias note="gvim -c $ +foldo +put='' +star /Users/name/Notes/notes.md"
Everything works except the attempt to put a blank line. No matter what I try: :pu='' :$pu=' _' etc it will not add blank lines for me.
Thanks for any help.
Rick
--
--
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, May 29, 2015
Re: AnsiEsc can not show background
I got the following error. Do you know what is wrong?
Also, could you please post it at
<http://www.vim.org/scripts/script.php?script_id=302>.
***vimball*** Source this file to extract it! (:so %)
removed 4 files
Vimball Archive
extracted <plugin/AnsiEscPlugin.vim>: 30 lines
wrote /Users/pengy/.vim/plugin/AnsiEscPlugin.vim
extracted <autoload/AnsiEsc.vim>: 1211 lines
wrote /Users/pengy/.vim/autoload/AnsiEsc.vim
extracted <plugin/cecutil.vim>: 536 lines
wrote /Users/pengy/.vim/plugin/cecutil.vim
extracted <doc/AnsiEsc.txt>: 175 lines
wrote /Users/pengy/.vim/doc/AnsiEsc.txt
did helptags
Error detected while processing SourceCmd Auto commands for "*.vba.gz":
E444: Cannot close last window
On Thu, Dec 11, 2014 at 10:03 PM, Charles E Campbell
<drchip@campbellfamily.biz> wrote:
> Peng Yu wrote:
>>
>> I'm sorry. The previous output is wrong. Here is the correct output.
>>
>> ^[[41m^[[37mhello^[[0m ^[[42m^[[37mworld^[[0m
>>
> Hello, Peng:
>
> Sorry it took so long -- but I think I have AnsiEsc able to handle the
> above.
>
> I've attached a copy.
>
> 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 a topic in the
> Google Groups "vim_use" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/vim_use/OaASJlRyOGo/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.
--
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.
Also, could you please post it at
<http://www.vim.org/scripts/script.php?script_id=302>.
***vimball*** Source this file to extract it! (:so %)
removed 4 files
Vimball Archive
extracted <plugin/AnsiEscPlugin.vim>: 30 lines
wrote /Users/pengy/.vim/plugin/AnsiEscPlugin.vim
extracted <autoload/AnsiEsc.vim>: 1211 lines
wrote /Users/pengy/.vim/autoload/AnsiEsc.vim
extracted <plugin/cecutil.vim>: 536 lines
wrote /Users/pengy/.vim/plugin/cecutil.vim
extracted <doc/AnsiEsc.txt>: 175 lines
wrote /Users/pengy/.vim/doc/AnsiEsc.txt
did helptags
Error detected while processing SourceCmd Auto commands for "*.vba.gz":
E444: Cannot close last window
On Thu, Dec 11, 2014 at 10:03 PM, Charles E Campbell
<drchip@campbellfamily.biz> wrote:
> Peng Yu wrote:
>>
>> I'm sorry. The previous output is wrong. Here is the correct output.
>>
>> ^[[41m^[[37mhello^[[0m ^[[42m^[[37mworld^[[0m
>>
> Hello, Peng:
>
> Sorry it took so long -- but I think I have AnsiEsc able to handle the
> above.
>
> I've attached a copy.
>
> 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 a topic in the
> Google Groups "vim_use" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/vim_use/OaASJlRyOGo/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.
--
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: Fedora 22 and Vim
The /etc/vimrc installed in F22 checks for $COLORTERM to adjust the background, that change the behavior default colorscheme.
Try with "COLORTERM=gnome-terminal" in your environment.
Regards.
--
--
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.
Try with "COLORTERM=gnome-terminal" in your environment.
Regards.
--
--
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: Replicate TextPad feature (copy marked lines)
Hi Tim!
On Do, 28 Mai 2015, Tim Chase wrote:
> On 2015-05-28 13:54, skeept wrote:
> > He would use find with a string or regular expression. Then he can
> > mark all matching lines. He can repeat the process with several
> > strings.
> >
> > After that he would copy all the marked lines and paste to another
> > window.
>
> The common way to do this is to pull the matches into a register:
>
> :let @a='' | g/pattern/y A
>
> This will gather all the lines matching "pattern" into the "a"
> register which you can paste within vim
>
> :new
> "ap
>
> or assign to the system clipboard:
>
> :let @+=@a
>
> If you have multiple search terms, you can (as you mention) build the
> expression out of the gate (or incrementally thanks to Vim's
> command-line history):
>
> :let @a='' | g/pattern1\|pattern2\|pattern3/y A
>
> That is what I usually do when I want this functionality.
>
> If you want to build it incrementally by searching instead, you can
> use the search register, recall the previous search, and append your
> additional term
>
> /pattern1<cr>
> /<up>\|pattern2<cr>
> [repeat until you have all the terms you want]
> :let @a='' | g//y A
>
> There might be some plugins that simplify these actions, but under
> the hood they would likely do the same thing as this.
BTW: My NrrwRgn plugin provides the possibility to mark selected region,
open all selected regions in a new window and write all selected regions
back to its original buffer. This is not limited to a sinlge buffer, so
you can mark several regions in different buffers and write all at the
same time back
Disclaimer: Experimental feature, if it doesn't work for you, open an
issue at the plugin page
Mit freundlichen Grüßen
Christian
--
Ein Künstler, der schätzbare Arbeiten verfertiget, ist nicht
immer imstande, von eignen oder fremden Werken Rechenschaft zu geben.
-- Goethe, Maximen und Reflektionen, Nr. 1122
--
--
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 Do, 28 Mai 2015, Tim Chase wrote:
> On 2015-05-28 13:54, skeept wrote:
> > He would use find with a string or regular expression. Then he can
> > mark all matching lines. He can repeat the process with several
> > strings.
> >
> > After that he would copy all the marked lines and paste to another
> > window.
>
> The common way to do this is to pull the matches into a register:
>
> :let @a='' | g/pattern/y A
>
> This will gather all the lines matching "pattern" into the "a"
> register which you can paste within vim
>
> :new
> "ap
>
> or assign to the system clipboard:
>
> :let @+=@a
>
> If you have multiple search terms, you can (as you mention) build the
> expression out of the gate (or incrementally thanks to Vim's
> command-line history):
>
> :let @a='' | g/pattern1\|pattern2\|pattern3/y A
>
> That is what I usually do when I want this functionality.
>
> If you want to build it incrementally by searching instead, you can
> use the search register, recall the previous search, and append your
> additional term
>
> /pattern1<cr>
> /<up>\|pattern2<cr>
> [repeat until you have all the terms you want]
> :let @a='' | g//y A
>
> There might be some plugins that simplify these actions, but under
> the hood they would likely do the same thing as this.
BTW: My NrrwRgn plugin provides the possibility to mark selected region,
open all selected regions in a new window and write all selected regions
back to its original buffer. This is not limited to a sinlge buffer, so
you can mark several regions in different buffers and write all at the
same time back
Disclaimer: Experimental feature, if it doesn't work for you, open an
issue at the plugin page
Mit freundlichen Grüßen
Christian
--
Ein Künstler, der schätzbare Arbeiten verfertiget, ist nicht
immer imstande, von eignen oder fremden Werken Rechenschaft zu geben.
-- Goethe, Maximen und Reflektionen, Nr. 1122
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vim: Not able to activate plugins , ... missing vim folders? etc
Thanks Chip.
Signature:
"Bad company corrupts good character". -anonymous writer
"Bad company corrupts good character". -anonymous writer
Live Long And Prosper,
FriendOfFatBeagle
On Thu, May 28, 2015 at 9:12 AM, Charles Campbell <Charles.E.Campbell@nasa.gov> wrote:
1: that's not automatic; you need to mkdir $HOME/.vim yourselfFriendOfFatBeagle wrote:
>
> I am learning Vim .... on Linux Mint Cinnamom Rebecca (17.1), 64 bits
>
> I am learning plugins for Vim from here: http://www.swaroopch.com/notes/vim/
> There is a free download book.
>
> Excerpts from page 60 of book (http://files.swaroopch.com/vim/byte_of_vim_v051.pdf):
> " 2. To install your own plugins or plugins that you have download from somewhere, you can use your own plugin directory:
> • $HOME/.vim/plugin/ on Linux/BSD/Mac OS X
> … "
>
> The Vim help files also mentioned this via vim command, :help plugin
> USING A GLOBAL PLUGIN
>
> First read the text in the plugin itself to check for any special conditions.
> Then copy the file to your plugin directory:
>
> system plugin directory ~
> Unix ~/.vim/plugin/
>
>
> My $HOME is :
> ~ $ echo $HOME
> /home/foffb
>
> But there is no $HOME/.vim folder, even after I enable "Show hidden files".
> The vim folder I found is here, and plugin folder also shown is like so:
> /usr/share/vim/addons/plugin
>
> So I downloaded highlight_current_line.vim (found here http://www.vim.org/scripts/script.php?script_id=1652)
> as suggested in the book, and put it in the only Vim plugin folder I found:
>
> /usr/share/vim/addons/plugin/highlight_current_line.vim
>
> When I ran vim, and I moved cursor over a line of texts, the line is not highlighted !
> Meaning plugin, "highlight_current_line.vim", does not work.
>
> Questions … too many, but here are a few for now:
>
> 1) Why do I not a have same folder structure for Vim
> as mention in the Vim's help docs and the "A Byte of Vim" book?
> Meaning there is no .vim under $HOME folder.
> AND ....
> This is all the vim stuff I have under $HOME :
> ~ $ locate $HOME/.vim/plugin
> No returned result ....
> ~ $ locate $HOME/.vim
> /home/foffb/.viminfo
>
> 2) Where should I put the plugin?
> Where does your .vim folder reside in your Linux?
>
> 3) What else did I missed?
>
2: depends on how your plugin is delivered. A vimball will set itself
up, pretty much, for example, with a simple vim plugin.vmb and :so %.
If its not a vimball, perhaps the plugin comes with directions.
Tarballs need you to be in some directory (often $HOME/.vim) before
un-tarring. The other distribution methods (vundle, etc) really need
you to install the associated plugin first -- but I'm sure that they
come with directions, so at least read their installation directions.
3: what kind of vim do you have? try using :version to see. In
particular, you don't want a "Tiny" version if you're intending to use
plugins. I myself use 7.4 with patches 1-725, Huge (for the nonce).
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 a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/8xgv2Z0yEw0/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.
quotation text object consternation
One of the oddball frustrations I find with vim is that the
outer-quotation objects eats leading space.
To demonstrate the inconsistency, use the following document
(parens)
[square brackets]
{braces}
"double quotes"
'single quotes"
and indent it (unless you copied the leading whitespace too)
:%>
then, on each line, use the associated outer-text-object to change it:
ca(xxx<esc>
ca[xxx<esc>
ca{xxx<esc>
ca"xxx<esc>
ca'xxx<esc>
Note how the ones with quotes also get un-indented while the others
don't. I encounter this most frequently when coding in Python where
I have something like
my_map = {
"foo": "bar",
"baz": "whinge",
"fred": "barney",
}
and I want to change the keys to constants:
FOO = "foo"
my_map = {
FOO: "bar",
# ...
}
so I go to the quote object and do
ca"FOO<esc>
only to then need to re-indent it back to the original level (not so
bad if it's single indent, but when it's multiple levels, it's a
pain). I've *never* had the eating-of-leading-whitespace as a desired
behavior.
Is there a way to make this consistent with the other "a" text
objects? Some option I've missed?
-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.
outer-quotation objects eats leading space.
To demonstrate the inconsistency, use the following document
(parens)
[square brackets]
{braces}
"double quotes"
'single quotes"
and indent it (unless you copied the leading whitespace too)
:%>
then, on each line, use the associated outer-text-object to change it:
ca(xxx<esc>
ca[xxx<esc>
ca{xxx<esc>
ca"xxx<esc>
ca'xxx<esc>
Note how the ones with quotes also get un-indented while the others
don't. I encounter this most frequently when coding in Python where
I have something like
my_map = {
"foo": "bar",
"baz": "whinge",
"fred": "barney",
}
and I want to change the keys to constants:
FOO = "foo"
my_map = {
FOO: "bar",
# ...
}
so I go to the quote object and do
ca"FOO<esc>
only to then need to re-indent it back to the original level (not so
bad if it's single indent, but when it's multiple levels, it's a
pain). I've *never* had the eating-of-leading-whitespace as a desired
behavior.
Is there a way to make this consistent with the other "a" text
objects? Some option I've missed?
-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.
Thursday, May 28, 2015
Re: Replicate TextPad feature (copy marked lines)
On 2015-05-28 13:54, skeept wrote:
> He would use find with a string or regular expression. Then he can
> mark all matching lines. He can repeat the process with several
> strings.
>
> After that he would copy all the marked lines and paste to another
> window.
The common way to do this is to pull the matches into a register:
:let @a='' | g/pattern/y A
This will gather all the lines matching "pattern" into the "a"
register which you can paste within vim
:new
"ap
or assign to the system clipboard:
:let @+=@a
If you have multiple search terms, you can (as you mention) build the
expression out of the gate (or incrementally thanks to Vim's
command-line history):
:let @a='' | g/pattern1\|pattern2\|pattern3/y A
That is what I usually do when I want this functionality.
If you want to build it incrementally by searching instead, you can
use the search register, recall the previous search, and append your
additional term
/pattern1<cr>
/<up>\|pattern2<cr>
[repeat until you have all the terms you want]
:let @a='' | g//y A
There might be some plugins that simplify these actions, but under
the hood they would likely do the same thing as this.
-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.
> He would use find with a string or regular expression. Then he can
> mark all matching lines. He can repeat the process with several
> strings.
>
> After that he would copy all the marked lines and paste to another
> window.
The common way to do this is to pull the matches into a register:
:let @a='' | g/pattern/y A
This will gather all the lines matching "pattern" into the "a"
register which you can paste within vim
:new
"ap
or assign to the system clipboard:
:let @+=@a
If you have multiple search terms, you can (as you mention) build the
expression out of the gate (or incrementally thanks to Vim's
command-line history):
:let @a='' | g/pattern1\|pattern2\|pattern3/y A
That is what I usually do when I want this functionality.
If you want to build it incrementally by searching instead, you can
use the search register, recall the previous search, and append your
additional term
/pattern1<cr>
/<up>\|pattern2<cr>
[repeat until you have all the terms you want]
:let @a='' | g//y A
There might be some plugins that simplify these actions, but under
the hood they would likely do the same thing as this.
-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.
Replicate TextPad feature (copy marked lines)
Hi All,
I use vim as much as possible, but today I saw a coworker do something interesting with TextPad.
He would use find with a string or regular expression. Then he can mark all matching lines.
He can repeat the process with several strings.
After that he would copy all the marked lines and paste to another window.
In vim we could do this using the g command by providing multiple expressions separated by \|
My question is if there would exist a way (using plug-in would be fine) to do this sequentially in vim?
Regards,
Jorge
--
--
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 use vim as much as possible, but today I saw a coworker do something interesting with TextPad.
He would use find with a string or regular expression. Then he can mark all matching lines.
He can repeat the process with several strings.
After that he would copy all the marked lines and paste to another window.
In vim we could do this using the g command by providing multiple expressions separated by \|
My question is if there would exist a way (using plug-in would be fine) to do this sequentially in vim?
Regards,
Jorge
--
--
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: Search pattern while excluding some words
kamaraju kusumanchi wrote:
> On Fri, Mar 6, 2015 at 2:58 PM, Charles Campbell
> <Charles.E.Campbell@nasa.gov> wrote:
>> Hello!
>>
>> You might find LogiPat helpful; see
>> http://www.drchip.org/astronaut/vim/index.html#LOGIPAT .
>>
>> :LP !"RCMP" && !"QEII" && !"SPCA" && "[A-Z]\{4,\}"
>>
>> LogiPat allows boolean logic to work with regexp patterns.
>>
>> Regards,
>> Chip Campbell
>>
> I am not the OP but just want to say ...
>
> LogiPat is one of those plugins I can't live without. It is super
> handy when coding... especially when you want to search for
> long_string_A but do not want to include prefixB_long_string_A_suffixC
> in the searches. Thanks for writing it.
>
> Is there any reason for it not to be included in default vim?
>
You're welcome. The question about including it in default vim is up
to Bram Moolenaar.
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.
> On Fri, Mar 6, 2015 at 2:58 PM, Charles Campbell
> <Charles.E.Campbell@nasa.gov> wrote:
>> Hello!
>>
>> You might find LogiPat helpful; see
>> http://www.drchip.org/astronaut/vim/index.html#LOGIPAT .
>>
>> :LP !"RCMP" && !"QEII" && !"SPCA" && "[A-Z]\{4,\}"
>>
>> LogiPat allows boolean logic to work with regexp patterns.
>>
>> Regards,
>> Chip Campbell
>>
> I am not the OP but just want to say ...
>
> LogiPat is one of those plugins I can't live without. It is super
> handy when coding... especially when you want to search for
> long_string_A but do not want to include prefixB_long_string_A_suffixC
> in the searches. Thanks for writing it.
>
> Is there any reason for it not to be included in default vim?
>
You're welcome. The question about including it in default vim is up
to Bram Moolenaar.
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.
Re: Autocmd to have a mapping only for a specific file
alexandre viau wrote:
> But even if i put backspace instead of ctrl-enter it will not be
> executed, only one of the mapping is executed
> Le mer. 29 avr. 2015 à 17:05, Charles Campbell
> <Charles.E.Campbell@nasa.gov <mailto:Charles.E.Campbell@nasa.gov>> a
> écrit :
>
> av wrote:
> > Le jeudi 23 avril 2015 09:25:11 UTC+2, av a écrit :
> >> Hi,
> >>
> >> I try to have an autocommand that would provide a mapping to
> the <enter> and <c-enter> keys only on a certain file name. Like
> myfile.txt for example.
> >>
> >> I have tried a test like this here, and it works for the
> <c-Enter> mapping but not for the <Enter> one:
> >>
> >> autocmd! BufNewFile,BufRead,BufEnter myfile.txt nmap
> <buffer> <Enter> :echo 'Hi!'<cr>
> >> autocmd! BufNewFile,BufRead,BufEnter myfile.txt nmap
> <buffer> <c-Enter> :echo 'Test!'<cr>
> >>
> >> And when I do :map <enter> vim says that there are "No mapping
> found"
> >>
> >> Any ideas why? And please tell me if I chose the right list of
> events.
> >>
> >> Thank you very much,
> >>
> >> Alexandre
> > It seems I cannot use <Enter> and <c-Enter> at the same time,
> only one of the 2 works. Why is that?
> >
> Go into insert mode.
>
> Type ctrl-v [return]
> Type ctrl-v ctrl-[return]
>
> You'll likely find that there's no difference between them.
>
Do the same thing with ctrl-v [backspace] and ctrl-v ctrl-[backspace].
Under gvim I do get a difference (<BS> vs <C-BS>) but not under vim.
btw, bottom posting is preferred on this list.
clearer
writing
makes
it
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.
> But even if i put backspace instead of ctrl-enter it will not be
> executed, only one of the mapping is executed
> Le mer. 29 avr. 2015 à 17:05, Charles Campbell
> <Charles.E.Campbell@nasa.gov <mailto:Charles.E.Campbell@nasa.gov>> a
> écrit :
>
> av wrote:
> > Le jeudi 23 avril 2015 09:25:11 UTC+2, av a écrit :
> >> Hi,
> >>
> >> I try to have an autocommand that would provide a mapping to
> the <enter> and <c-enter> keys only on a certain file name. Like
> myfile.txt for example.
> >>
> >> I have tried a test like this here, and it works for the
> <c-Enter> mapping but not for the <Enter> one:
> >>
> >> autocmd! BufNewFile,BufRead,BufEnter myfile.txt nmap
> <buffer> <Enter> :echo 'Hi!'<cr>
> >> autocmd! BufNewFile,BufRead,BufEnter myfile.txt nmap
> <buffer> <c-Enter> :echo 'Test!'<cr>
> >>
> >> And when I do :map <enter> vim says that there are "No mapping
> found"
> >>
> >> Any ideas why? And please tell me if I chose the right list of
> events.
> >>
> >> Thank you very much,
> >>
> >> Alexandre
> > It seems I cannot use <Enter> and <c-Enter> at the same time,
> only one of the 2 works. Why is that?
> >
> Go into insert mode.
>
> Type ctrl-v [return]
> Type ctrl-v ctrl-[return]
>
> You'll likely find that there's no difference between them.
>
Do the same thing with ctrl-v [backspace] and ctrl-v ctrl-[backspace].
Under gvim I do get a difference (<BS> vs <C-BS>) but not under vim.
btw, bottom posting is preferred on this list.
clearer
writing
makes
it
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.
Re: autocmd BufEnter * :set selection=exclusive
Paul wrote:
> toothpik <toothpik6 <at> gmail.com> writes:
>> On Fri, Apr 24, 2015 at 10:29:00PM +0000, Paul wrote:
>>> Christian Brabandt <cblists <at> 256bit.org> writes:
>>>> Check with :verbose set selection? what caused the change of the
>>>> selection.
>>>>
>>>> If a plugin is the culprit contact the plugin author. He should
>>>> fix it.
>>> It shows that netrw is the last to change the "selection" option.
>>> However, the author confirmed that netrw saves and restores the
>>> original values.
>> when working with said author you need to give specific details
>> about how you invoke netrw and how you leave it -- that plugin has
>> more entries and exits than a big block of swiss cheese and it's
>> possible you've found a way to foil the expected behavior
> That would be challenging...I am not exactly sure *when* the selection
> option gets clobbered and not restored. It's difficult to know which
> method of exiting is causing the problem. And my methods of exiting
> are probably the same as most people's: Change windows, close window,
> close tab, switch tab, open a file, or preview a file.
>
You could put
redir >> $HOME/vss
verbose set selection?
redir END
in s:NetrwOptionSave(). That way a file, "vss", will be created with
the output of "verbose set selection?" -- eventually you'll find a "last
set" message in that file that'll help point you where the problem occurred.
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.
> toothpik <toothpik6 <at> gmail.com> writes:
>> On Fri, Apr 24, 2015 at 10:29:00PM +0000, Paul wrote:
>>> Christian Brabandt <cblists <at> 256bit.org> writes:
>>>> Check with :verbose set selection? what caused the change of the
>>>> selection.
>>>>
>>>> If a plugin is the culprit contact the plugin author. He should
>>>> fix it.
>>> It shows that netrw is the last to change the "selection" option.
>>> However, the author confirmed that netrw saves and restores the
>>> original values.
>> when working with said author you need to give specific details
>> about how you invoke netrw and how you leave it -- that plugin has
>> more entries and exits than a big block of swiss cheese and it's
>> possible you've found a way to foil the expected behavior
> That would be challenging...I am not exactly sure *when* the selection
> option gets clobbered and not restored. It's difficult to know which
> method of exiting is causing the problem. And my methods of exiting
> are probably the same as most people's: Change windows, close window,
> close tab, switch tab, open a file, or preview a file.
>
You could put
redir >> $HOME/vss
verbose set selection?
redir END
in s:NetrwOptionSave(). That way a file, "vss", will be created with
the output of "verbose set selection?" -- eventually you'll find a "last
set" message in that file that'll help point you where the problem occurred.
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.
Re: Vim: Not able to activate plugins , ... missing vim folders? etc
FriendOfFatBeagle wrote:
>
> I am learning Vim .... on Linux Mint Cinnamom Rebecca (17.1), 64 bits
>
> I am learning plugins for Vim from here: http://www.swaroopch.com/notes/vim/
> There is a free download book.
>
> Excerpts from page 60 of book (http://files.swaroopch.com/vim/byte_of_vim_v051.pdf):
> " 2. To install your own plugins or plugins that you have download from somewhere, you can use your own plugin directory:
> • $HOME/.vim/plugin/ on Linux/BSD/Mac OS X
> … "
>
> The Vim help files also mentioned this via vim command, :help plugin
> USING A GLOBAL PLUGIN
>
> First read the text in the plugin itself to check for any special conditions.
> Then copy the file to your plugin directory:
>
> system plugin directory ~
> Unix ~/.vim/plugin/
>
>
> My $HOME is :
> ~ $ echo $HOME
> /home/foffb
>
> But there is no $HOME/.vim folder, even after I enable "Show hidden files".
> The vim folder I found is here, and plugin folder also shown is like so:
> /usr/share/vim/addons/plugin
>
> So I downloaded highlight_current_line.vim (found here http://www.vim.org/scripts/script.php?script_id=1652)
> as suggested in the book, and put it in the only Vim plugin folder I found:
>
> /usr/share/vim/addons/plugin/highlight_current_line.vim
>
> When I ran vim, and I moved cursor over a line of texts, the line is not highlighted !
> Meaning plugin, "highlight_current_line.vim", does not work.
>
> Questions … too many, but here are a few for now:
>
> 1) Why do I not a have same folder structure for Vim
> as mention in the Vim's help docs and the "A Byte of Vim" book?
> Meaning there is no .vim under $HOME folder.
> AND ....
> This is all the vim stuff I have under $HOME :
> ~ $ locate $HOME/.vim/plugin
> No returned result ....
> ~ $ locate $HOME/.vim
> /home/foffb/.viminfo
>
> 2) Where should I put the plugin?
> Where does your .vim folder reside in your Linux?
>
> 3) What else did I missed?
>
1: that's not automatic; you need to mkdir $HOME/.vim yourself
2: depends on how your plugin is delivered. A vimball will set itself
up, pretty much, for example, with a simple vim plugin.vmb and :so %.
If its not a vimball, perhaps the plugin comes with directions.
Tarballs need you to be in some directory (often $HOME/.vim) before
un-tarring. The other distribution methods (vundle, etc) really need
you to install the associated plugin first -- but I'm sure that they
come with directions, so at least read their installation directions.
3: what kind of vim do you have? try using :version to see. In
particular, you don't want a "Tiny" version if you're intending to use
plugins. I myself use 7.4 with patches 1-725, Huge (for the nonce).
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.
>
> I am learning Vim .... on Linux Mint Cinnamom Rebecca (17.1), 64 bits
>
> I am learning plugins for Vim from here: http://www.swaroopch.com/notes/vim/
> There is a free download book.
>
> Excerpts from page 60 of book (http://files.swaroopch.com/vim/byte_of_vim_v051.pdf):
> " 2. To install your own plugins or plugins that you have download from somewhere, you can use your own plugin directory:
> • $HOME/.vim/plugin/ on Linux/BSD/Mac OS X
> … "
>
> The Vim help files also mentioned this via vim command, :help plugin
> USING A GLOBAL PLUGIN
>
> First read the text in the plugin itself to check for any special conditions.
> Then copy the file to your plugin directory:
>
> system plugin directory ~
> Unix ~/.vim/plugin/
>
>
> My $HOME is :
> ~ $ echo $HOME
> /home/foffb
>
> But there is no $HOME/.vim folder, even after I enable "Show hidden files".
> The vim folder I found is here, and plugin folder also shown is like so:
> /usr/share/vim/addons/plugin
>
> So I downloaded highlight_current_line.vim (found here http://www.vim.org/scripts/script.php?script_id=1652)
> as suggested in the book, and put it in the only Vim plugin folder I found:
>
> /usr/share/vim/addons/plugin/highlight_current_line.vim
>
> When I ran vim, and I moved cursor over a line of texts, the line is not highlighted !
> Meaning plugin, "highlight_current_line.vim", does not work.
>
> Questions … too many, but here are a few for now:
>
> 1) Why do I not a have same folder structure for Vim
> as mention in the Vim's help docs and the "A Byte of Vim" book?
> Meaning there is no .vim under $HOME folder.
> AND ....
> This is all the vim stuff I have under $HOME :
> ~ $ locate $HOME/.vim/plugin
> No returned result ....
> ~ $ locate $HOME/.vim
> /home/foffb/.viminfo
>
> 2) Where should I put the plugin?
> Where does your .vim folder reside in your Linux?
>
> 3) What else did I missed?
>
1: that's not automatic; you need to mkdir $HOME/.vim yourself
2: depends on how your plugin is delivered. A vimball will set itself
up, pretty much, for example, with a simple vim plugin.vmb and :so %.
If its not a vimball, perhaps the plugin comes with directions.
Tarballs need you to be in some directory (often $HOME/.vim) before
un-tarring. The other distribution methods (vundle, etc) really need
you to install the associated plugin first -- but I'm sure that they
come with directions, so at least read their installation directions.
3: what kind of vim do you have? try using :version to see. In
particular, you don't want a "Tiny" version if you're intending to use
plugins. I myself use 7.4 with patches 1-725, Huge (for the nonce).
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.
Re: Vim: Not able to activate plugins , ... missing vim folders? etc
Hello Yukihiro Nakadaira:
I will try it out.Signature:
"Bad company corrupts good character". -anonymous writer
"Bad company corrupts good character". -anonymous writer
Live Long And Prosper,
FriendOfFatBeagleOn Thu, May 28, 2015 at 12:52 AM, Yukihiro Nakadaira <yukihiro.nakadaira@gmail.com> wrote:
On Thu, May 28, 2015 at 2:12 PM, FriendOfFatBeagle <avtinc2000@gmail.com> wrote:
I am learning Vim .... on Linux Mint Cinnamom Rebecca (17.1), 64 bits
I am learning plugins for Vim from here: http://www.swaroopch.com/notes/vim/
There is a free download book.
Excerpts from page 60 of book (http://files.swaroopch.com/vim/byte_of_vim_v051.pdf):
" 2. To install your own plugins or plugins that you have download from somewhere, you can use your own plugin directory:
• $HOME/.vim/plugin/ on Linux/BSD/Mac OS X
… "
The Vim help files also mentioned this via vim command, :help plugin
USING A GLOBAL PLUGIN
First read the text in the plugin itself to check for any special conditions.
Then copy the file to your plugin directory:
system plugin directory ~
Unix ~/.vim/plugin/
My $HOME is :
~ $ echo $HOME
/home/foffb
But there is no $HOME/.vim folder, even after I enable "Show hidden files".
The vim folder I found is here, and plugin folder also shown is like so:
/usr/share/vim/addons/plugin
So I downloaded highlight_current_line.vim (found here http://www.vim.org/scripts/script.php?script_id=1652)
as suggested in the book, and put it in the only Vim plugin folder I found:
/usr/share/vim/addons/plugin/highlight_current_line.vim
When I ran vim, and I moved cursor over a line of texts, the line is not highlighted !
Meaning plugin, "highlight_current_line.vim", does not work.
Questions … too many, but here are a few for now:
1) Why do I not a have same folder structure for Vim
as mention in the Vim's help docs and the "A Byte of Vim" book?
Meaning there is no .vim under $HOME folder.
AND ....
This is all the vim stuff I have under $HOME :
~ $ locate $HOME/.vim/plugin
No returned result ....
~ $ locate $HOME/.vim
/home/foffb/.viminfo
2) Where should I put the plugin?
Where does your .vim folder reside in your Linux?
3) What else did I missed?$HOME/.vim folder is not created automatically.You have to craete the folder by yourself.$ mkdir ~/.vim$ mkdir ~/.vim/plugin...--Yukihiro Nakadaira - yukihiro.nakadaira@gmail.com--
--
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/8xgv2Z0yEw0/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: keymodel=stopsel (set by behave mswin) interferes with match_words (matchit plugin) and the textobj-user plugin
Am 2015-05-28 09:11, schrieb Hgs:
> I found out that the
> behave mswin
> command called from $VIM/mswin.vim
> interferes with the matchit plugin when using match_words and with the
> select-i method of the pattern mode of the vim-textobj-user plugin.
> (Both inserted a new line after the end pattern and placed the cursor
> there.)
>
> A closer look revealed that it is the stopsel value of the keymodel
> option which matters.
>
> If one puts
> set keymodel-=stopsel
> directly after "behave mswin" (or the "so $VIM/mswin.vim" statement)
> both plugins work as expected.
You should probably report this issue to the maintainer of the plugins,
so they can fix the problems there.
Best,
Christian
--
--
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 found out that the
> behave mswin
> command called from $VIM/mswin.vim
> interferes with the matchit plugin when using match_words and with the
> select-i method of the pattern mode of the vim-textobj-user plugin.
> (Both inserted a new line after the end pattern and placed the cursor
> there.)
>
> A closer look revealed that it is the stopsel value of the keymodel
> option which matters.
>
> If one puts
> set keymodel-=stopsel
> directly after "behave mswin" (or the "so $VIM/mswin.vim" statement)
> both plugins work as expected.
You should probably report this issue to the maintainer of the plugins,
so they can fix the problems there.
Best,
Christian
--
--
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.
keymodel=stopsel (set by behave mswin) interferes with match_words (matchit plugin) and the textobj-user plugin
I found out that the
behave mswin
command called from $VIM/mswin.vim
interferes with the matchit plugin when using match_words and with the select-i method of the pattern mode of the vim-textobj-user plugin.
(Both inserted a new line after the end pattern and placed the cursor there.)
A closer look revealed that it is the stopsel value of the keymodel option which matters.
If one puts
set keymodel-=stopsel
directly after "behave mswin" (or the "so $VIM/mswin.vim" statement)
both plugins work as expected.
--
--
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.
behave mswin
command called from $VIM/mswin.vim
interferes with the matchit plugin when using match_words and with the select-i method of the pattern mode of the vim-textobj-user plugin.
(Both inserted a new line after the end pattern and placed the cursor there.)
A closer look revealed that it is the stopsel value of the keymodel option which matters.
If one puts
set keymodel-=stopsel
directly after "behave mswin" (or the "so $VIM/mswin.vim" statement)
both plugins work as expected.
--
--
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.
Wednesday, May 27, 2015
Re: Vim: Not able to activate plugins , ... missing vim folders? etc
On Thu, May 28, 2015 at 2:12 PM, FriendOfFatBeagle <avtinc2000@gmail.com> wrote:
--
--
I am learning Vim .... on Linux Mint Cinnamom Rebecca (17.1), 64 bits
I am learning plugins for Vim from here: http://www.swaroopch.com/notes/vim/
There is a free download book.
Excerpts from page 60 of book (http://files.swaroopch.com/vim/byte_of_vim_v051.pdf):
" 2. To install your own plugins or plugins that you have download from somewhere, you can use your own plugin directory:
• $HOME/.vim/plugin/ on Linux/BSD/Mac OS X
… "
The Vim help files also mentioned this via vim command, :help plugin
USING A GLOBAL PLUGIN
First read the text in the plugin itself to check for any special conditions.
Then copy the file to your plugin directory:
system plugin directory ~
Unix ~/.vim/plugin/
My $HOME is :
~ $ echo $HOME
/home/foffb
But there is no $HOME/.vim folder, even after I enable "Show hidden files".
The vim folder I found is here, and plugin folder also shown is like so:
/usr/share/vim/addons/plugin
So I downloaded highlight_current_line.vim (found here http://www.vim.org/scripts/script.php?script_id=1652)
as suggested in the book, and put it in the only Vim plugin folder I found:
/usr/share/vim/addons/plugin/highlight_current_line.vim
When I ran vim, and I moved cursor over a line of texts, the line is not highlighted !
Meaning plugin, "highlight_current_line.vim", does not work.
Questions … too many, but here are a few for now:
1) Why do I not a have same folder structure for Vim
as mention in the Vim's help docs and the "A Byte of Vim" book?
Meaning there is no .vim under $HOME folder.
AND ....
This is all the vim stuff I have under $HOME :
~ $ locate $HOME/.vim/plugin
No returned result ....
~ $ locate $HOME/.vim
/home/foffb/.viminfo
2) Where should I put the plugin?
Where does your .vim folder reside in your Linux?
3) What else did I missed?
$HOME/.vim folder is not created automatically.
You have to craete the folder by yourself.
$ mkdir ~/.vim
$ mkdir ~/.vim/plugin
...
Yukihiro Nakadaira - yukihiro.nakadaira@gmail.com
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Vim: Not able to activate plugins , ... missing vim folders? etc
I am learning Vim .... on Linux Mint Cinnamom Rebecca (17.1), 64 bits
I am learning plugins for Vim from here: http://www.swaroopch.com/notes/vim/
There is a free download book.
Excerpts from page 60 of book (http://files.swaroopch.com/vim/byte_of_vim_v051.pdf):
" 2. To install your own plugins or plugins that you have download from somewhere, you can use your own plugin directory:
• $HOME/.vim/plugin/ on Linux/BSD/Mac OS X
… "
The Vim help files also mentioned this via vim command, :help plugin
USING A GLOBAL PLUGIN
First read the text in the plugin itself to check for any special conditions.
Then copy the file to your plugin directory:
system plugin directory ~
Unix ~/.vim/plugin/
My $HOME is :
~ $ echo $HOME
/home/foffb
But there is no $HOME/.vim folder, even after I enable "Show hidden files".
The vim folder I found is here, and plugin folder also shown is like so:
/usr/share/vim/addons/plugin
So I downloaded highlight_current_line.vim (found here http://www.vim.org/scripts/script.php?script_id=1652)
as suggested in the book, and put it in the only Vim plugin folder I found:
/usr/share/vim/addons/plugin/highlight_current_line.vim
When I ran vim, and I moved cursor over a line of texts, the line is not highlighted !
Meaning plugin, "highlight_current_line.vim", does not work.
Questions … too many, but here are a few for now:
1) Why do I not a have same folder structure for Vim
as mention in the Vim's help docs and the "A Byte of Vim" book?
Meaning there is no .vim under $HOME folder.
AND ....
This is all the vim stuff I have under $HOME :
~ $ locate $HOME/.vim/plugin
No returned result ....
~ $ locate $HOME/.vim
/home/foffb/.viminfo
2) Where should I put the plugin?
Where does your .vim folder reside in your Linux?
3) What else did I missed?
Thanks.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I am learning plugins for Vim from here: http://www.swaroopch.com/notes/vim/
There is a free download book.
Excerpts from page 60 of book (http://files.swaroopch.com/vim/byte_of_vim_v051.pdf):
" 2. To install your own plugins or plugins that you have download from somewhere, you can use your own plugin directory:
• $HOME/.vim/plugin/ on Linux/BSD/Mac OS X
… "
The Vim help files also mentioned this via vim command, :help plugin
USING A GLOBAL PLUGIN
First read the text in the plugin itself to check for any special conditions.
Then copy the file to your plugin directory:
system plugin directory ~
Unix ~/.vim/plugin/
My $HOME is :
~ $ echo $HOME
/home/foffb
But there is no $HOME/.vim folder, even after I enable "Show hidden files".
The vim folder I found is here, and plugin folder also shown is like so:
/usr/share/vim/addons/plugin
So I downloaded highlight_current_line.vim (found here http://www.vim.org/scripts/script.php?script_id=1652)
as suggested in the book, and put it in the only Vim plugin folder I found:
/usr/share/vim/addons/plugin/highlight_current_line.vim
When I ran vim, and I moved cursor over a line of texts, the line is not highlighted !
Meaning plugin, "highlight_current_line.vim", does not work.
Questions … too many, but here are a few for now:
1) Why do I not a have same folder structure for Vim
as mention in the Vim's help docs and the "A Byte of Vim" book?
Meaning there is no .vim under $HOME folder.
AND ....
This is all the vim stuff I have under $HOME :
~ $ locate $HOME/.vim/plugin
No returned result ....
~ $ locate $HOME/.vim
/home/foffb/.viminfo
2) Where should I put the plugin?
Where does your .vim folder reside in your Linux?
3) What else did I missed?
Thanks.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: reformatting comments
On Mi, 27 Mai 2015, Christian Brabandt wrote:
> On Mi, 27 Mai 2015, Ben Fritz wrote:
>
> > On Wednesday, May 27, 2015 at 10:06:11 AM UTC-5, Christian Brabandt wrote:
> > > Hi,
> > > Can someone explain this behaviour?
> > >
> > > vim -u NONE -N --cmd ':set comments=e:%% tw=20' -c 'call setline(1, "%%
> > > ".repeat("foobar ", 10))' -c 'norm! Vgq'
> > >
> > > Output:
> > > ,----
> > > | %% foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
> > > `----
> > > Note: not reformated to fit into the textwidth
> > >
> > > Expected Output:
> > > ,----
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > `----
> > > (Reformated to fit into textwidth, the comment leader might be left
> > > away)
> > >
> >
> > Why do you expect this behavior?
>
> Well, this was a reduced example from a tex file, that I could not
> reformat, because a comment started with %%. I expect even the endpart
> of a comment to be reformatable according to the current &tw setting.
>
> > You're specifying only the end part of a 3-part comment, making it an
> > invalid entry. From :help format-comments:
> >
> > > A three-piece comment must always be given as start,middle,end, with
> > > no other parts in between. An example of a three-piece comment is
> > > sr:/*,mb:*,ex:*/
>
> Well, have you tried it with a complete three-piece comment? Latex Files
> are a good example:
> (taken from $VIMRUNTIME/ftplugin/initex.vim)
>
> vim -u NONE -N --cmd ':set comments=sO:%\ -,mO:%\ \ ,eO:%%,:% tw=20' -c
> 'call setline(1, "%% ".repeat("foobar ", 10))' -c 'norm! Vgq'
>
> (still does not reformat).
Source says this:
/*
* Blank lines, and lines containing only the comment leader, are left
* untouched by the formatting. The function returns TRUE in this
* case. It also returns TRUE when a line starts with the end of a comment
* ('e' in comment flags), so that this line is skipped, and not joined to the
* previous line. A new paragraph starts after a blank line, or when the
* comment leader changes -- webb.
*/
This explains it. It should be documented however, but I can understand
why this is done, because when the end comment occurs, it doesn't make
sense to split the line and insert another end comment marker into newly
created line.
But perhaps, it should only be done, if after the end marker, no other
comment occurs? Or perhaps the latex filetype plugin should remove the
three-part comment altogether, as '%%' does not seem to actually end a
comment in tex files? (Maintainer CC'ed for clarification).
Best,
Christian
--
Die Jugend und die schöne Liebe, alles hat sein Ende.
-- Goethe
--
--
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 Mi, 27 Mai 2015, Ben Fritz wrote:
>
> > On Wednesday, May 27, 2015 at 10:06:11 AM UTC-5, Christian Brabandt wrote:
> > > Hi,
> > > Can someone explain this behaviour?
> > >
> > > vim -u NONE -N --cmd ':set comments=e:%% tw=20' -c 'call setline(1, "%%
> > > ".repeat("foobar ", 10))' -c 'norm! Vgq'
> > >
> > > Output:
> > > ,----
> > > | %% foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
> > > `----
> > > Note: not reformated to fit into the textwidth
> > >
> > > Expected Output:
> > > ,----
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > | %% foobar foobar
> > > `----
> > > (Reformated to fit into textwidth, the comment leader might be left
> > > away)
> > >
> >
> > Why do you expect this behavior?
>
> Well, this was a reduced example from a tex file, that I could not
> reformat, because a comment started with %%. I expect even the endpart
> of a comment to be reformatable according to the current &tw setting.
>
> > You're specifying only the end part of a 3-part comment, making it an
> > invalid entry. From :help format-comments:
> >
> > > A three-piece comment must always be given as start,middle,end, with
> > > no other parts in between. An example of a three-piece comment is
> > > sr:/*,mb:*,ex:*/
>
> Well, have you tried it with a complete three-piece comment? Latex Files
> are a good example:
> (taken from $VIMRUNTIME/ftplugin/initex.vim)
>
> vim -u NONE -N --cmd ':set comments=sO:%\ -,mO:%\ \ ,eO:%%,:% tw=20' -c
> 'call setline(1, "%% ".repeat("foobar ", 10))' -c 'norm! Vgq'
>
> (still does not reformat).
Source says this:
/*
* Blank lines, and lines containing only the comment leader, are left
* untouched by the formatting. The function returns TRUE in this
* case. It also returns TRUE when a line starts with the end of a comment
* ('e' in comment flags), so that this line is skipped, and not joined to the
* previous line. A new paragraph starts after a blank line, or when the
* comment leader changes -- webb.
*/
This explains it. It should be documented however, but I can understand
why this is done, because when the end comment occurs, it doesn't make
sense to split the line and insert another end comment marker into newly
created line.
But perhaps, it should only be done, if after the end marker, no other
comment occurs? Or perhaps the latex filetype plugin should remove the
three-part comment altogether, as '%%' does not seem to actually end a
comment in tex files? (Maintainer CC'ed for clarification).
Best,
Christian
--
Die Jugend und die schöne Liebe, alles hat sein Ende.
-- Goethe
--
--
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: How to uppercase the non-English characters using Windows-1250 code page?
Hi Nikolay!
On Mi, 27 Mai 2015, Nikolay Pavlov wrote:
> This is not strange, tr is somewhat like tolower/toupper (as opposed
> to towlower/towupper):
>
> % echo 'abcабц' | iconv -t CP1251 > /tmp/enctest2
> % cat /tmp/enctest2 | LANG=ru_RU.CP1251 tr '[:lower:]' '[:upper:]'
> | iconv -f CP1251
> ABCАБЦ
> % cat /tmp/enctest2 | iconv -f CP1251 | tr '[:lower:]' '[:upper:]'
> ABCабц
>
> : it works only with single bytes. Each of the characters "čšž" in
> UTF-8 occupies more then one byte, thus you need to use CP1250 locale
> for this to work.
That seems to be correct. In a cp1250 locale, it works as expected:
#v+
~ % locale
LANG=de_DE.cp1250
LANGUAGE=
LC_CTYPE="de_DE.cp1250"
LC_NUMERIC="de_DE.cp1250"
LC_TIME="de_DE.cp1250"
LC_COLLATE="de_DE.cp1250"
LC_MONETARY="de_DE.cp1250"
LC_MESSAGES="de_DE.cp1250"
LC_PAPER="de_DE.cp1250"
LC_NAME="de_DE.cp1250"
LC_ADDRESS="de_DE.cp1250"
LC_TELEPHONE="de_DE.cp1250"
LC_MEASUREMENT="de_DE.cp1250"
LC_IDENTIFICATION="de_DE.cp1250"
LC_ALL=de_DE.cp1250
~ % tr '[:lower:]' '[:upper:]' < /tmp/enctest
ABCČŠŽ
#v-
> Cannot find this in `man tr` though, but `info tr` has
Args, Info files...
Not sure, what the problem for Vim is however.
Best,
Christian
--
Leserlichkeit ist die Höflichkeit der Handschrift.
-- Friedrich Dürrenmatt
--
--
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 Mi, 27 Mai 2015, Nikolay Pavlov wrote:
> This is not strange, tr is somewhat like tolower/toupper (as opposed
> to towlower/towupper):
>
> % echo 'abcабц' | iconv -t CP1251 > /tmp/enctest2
> % cat /tmp/enctest2 | LANG=ru_RU.CP1251 tr '[:lower:]' '[:upper:]'
> | iconv -f CP1251
> ABCАБЦ
> % cat /tmp/enctest2 | iconv -f CP1251 | tr '[:lower:]' '[:upper:]'
> ABCабц
>
> : it works only with single bytes. Each of the characters "čšž" in
> UTF-8 occupies more then one byte, thus you need to use CP1250 locale
> for this to work.
That seems to be correct. In a cp1250 locale, it works as expected:
#v+
~ % locale
LANG=de_DE.cp1250
LANGUAGE=
LC_CTYPE="de_DE.cp1250"
LC_NUMERIC="de_DE.cp1250"
LC_TIME="de_DE.cp1250"
LC_COLLATE="de_DE.cp1250"
LC_MONETARY="de_DE.cp1250"
LC_MESSAGES="de_DE.cp1250"
LC_PAPER="de_DE.cp1250"
LC_NAME="de_DE.cp1250"
LC_ADDRESS="de_DE.cp1250"
LC_TELEPHONE="de_DE.cp1250"
LC_MEASUREMENT="de_DE.cp1250"
LC_IDENTIFICATION="de_DE.cp1250"
LC_ALL=de_DE.cp1250
~ % tr '[:lower:]' '[:upper:]' < /tmp/enctest
ABCČŠŽ
#v-
> Cannot find this in `man tr` though, but `info tr` has
Args, Info files...
Not sure, what the problem for Vim is however.
Best,
Christian
--
Leserlichkeit ist die Höflichkeit der Handschrift.
-- Friedrich Dürrenmatt
--
--
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.
Subscribe to:
Posts (Atom)