When I start gvim with a file name
Gvim h:\bin\pcalc.pl,
if I edit another file by name, it references the same directory...
However, if I use UNC name,
Gvim \\ishtar\home\linda\bin\pcalc.pl
to edit the same file, my current directory isn't set correctly.
I know I used to have my own script to edit files that worked
in this situation, but I don't know if vim has always been broken this way
or it is a recent development -- maybe only on the 'x64 version
(Running vi 7.33 (2010 Aud 15, compiled Mar 25 2012 (with +perl -- though
it doesn't work with the current version of perl (5.12) as pointed to in the
email...
It seems it uses a fixed version number rather than a generic perl.dll....
Maybe it would be better to use dynamic loading, (like a 'dll') and
call it perl.dll, (as a pointer to some more specific version ... gee this
sounds similar ... I know I've seen this scheme before...)...
but then the loader can cal the dll to find out what functions are
available or
what level - and auto work with a variety of versions rather than being
statically coded to a 'dynamic' library, (!?!talk about missing the
point!)...
Oh,,, I remember the scheme...
but it was slightly different
libXXX.so =link-> lib.so.X =link->lib.so.X.Y
I think I remember it from some system that I worked on 20 or more years
ago... unix or something ...come to think of it... I think some modern
*nixes have
similar...linux or something...
Wow.... Maybe windows could learn about using non-versioned names
(just like
linux could learn better about dynamic runtime configuration based on
available .so's, by using dlopen rather than relying on do-or-die
initial loads....
Oh the promise of computers becoming *easier* to use -- instead...
theyv'e gone in the opposite direction due to industry failure to
preserve or value institutional knowledge...between generations...
--
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
Monday, April 30, 2012
Re: gtk-config not even tried
On Tuesday, May 1, 2012 2:32:51 AM UTC+12, Arno Valentin wrote:
> ... I'm offered "gtk+-1.2.10", "gtk+2-2.24.10", "gtk+3-3.2.4" ...
IIUC, gtk+2-2.24.10 is the one you want, being gtk 2.
In my config.log, configure tries to see what version of gtk is installed by compiling and running a gtk test programme:
configure:7987: checking for GTK - version >= 2.2.0
configure:8054: gcc -o conftest -Wall -Wshadow -Wmissing-prototypes -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/local/include -L/usr/local/lib conftest.c -lnsl -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 >&5
configure:8054: $? = 0
configure:8054: ./conftest
configure:8054: $? = 0
configure:8069: result: yes; found version 2.24.6
If I was missing needed libraries, IIUC I'd see errors about what was missing. However, my config has used pkg-config; IIUC that's part of autotools which you seem to have. It needs to work for configure to decide you've got gtk.
HTH, and regards, John
--
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
> ... I'm offered "gtk+-1.2.10", "gtk+2-2.24.10", "gtk+3-3.2.4" ...
IIUC, gtk+2-2.24.10 is the one you want, being gtk 2.
In my config.log, configure tries to see what version of gtk is installed by compiling and running a gtk test programme:
configure:7987: checking for GTK - version >= 2.2.0
configure:8054: gcc -o conftest -Wall -Wshadow -Wmissing-prototypes -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/local/include -L/usr/local/lib conftest.c -lnsl -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 >&5
configure:8054: $? = 0
configure:8054: ./conftest
configure:8054: $? = 0
configure:8069: result: yes; found version 2.24.6
If I was missing needed libraries, IIUC I'd see errors about what was missing. However, my config has used pkg-config; IIUC that's part of autotools which you seem to have. It needs to work for configure to decide you've got gtk.
HTH, and regards, John
--
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
Re: good 256 color theme for C
On 30/04/12 10:23, sinbad wrote:
> I just started using tmux, and i am exploring 256 color option of
> the terminal. Is there any good colorscheme that uses theses colors
> effectively, especially for C programming ?
>
> cheers
>
For Vim to use 256 colours effectively, you have to make sure that t_Co
gets set to 256 when running in a 256-colour terminal, but not when in a
terminal with fewer colours (such as the Linux hardware-text console or,
I think, the Windows console, at least when in fullscreen mode).
Previous posts in this thread provide several answers to that; mine (not
necessarily the best) is simply
" use 256 colors in Console mode if we think the terminal supports it
if &term =~? 'mlterm\|xterm'
set t_Co=256
endif
Then you need a colorscheme which makes use of them. If you are using a
GUI-enabled Vim in console mode (which is possible on Linux but not on
Windows), you can use the CSApprox plugin, which will "translate" the
24-bit (16 million colors) gui= guibg= guifg= guisp= of any GUI-oriented
colorscheme into something as near as possible to the same colours on a
256- or 88-color terminal. (On a terminal with fewer colours, such as 8
bg + 16 fg, it will simply desist and let the cterm= ctermbg= ctermfg=
colours remain in force.) This way, if your terminal has 88 or more
colours, you'll get approximately the same look and feel as in gvim. I
like it but of course YMMV.
See also http://vim.wikia.com/wiki/Using_GUI_color_settings_in_a_terminal
Best regards,
Tony.
--
GALAHAD: No. Look, I can tackle this lot single-handed!
GIRLS: Yes, yes, let him Tackle us single-handed!
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
--
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
> I just started using tmux, and i am exploring 256 color option of
> the terminal. Is there any good colorscheme that uses theses colors
> effectively, especially for C programming ?
>
> cheers
>
For Vim to use 256 colours effectively, you have to make sure that t_Co
gets set to 256 when running in a 256-colour terminal, but not when in a
terminal with fewer colours (such as the Linux hardware-text console or,
I think, the Windows console, at least when in fullscreen mode).
Previous posts in this thread provide several answers to that; mine (not
necessarily the best) is simply
" use 256 colors in Console mode if we think the terminal supports it
if &term =~? 'mlterm\|xterm'
set t_Co=256
endif
Then you need a colorscheme which makes use of them. If you are using a
GUI-enabled Vim in console mode (which is possible on Linux but not on
Windows), you can use the CSApprox plugin, which will "translate" the
24-bit (16 million colors) gui= guibg= guifg= guisp= of any GUI-oriented
colorscheme into something as near as possible to the same colours on a
256- or 88-color terminal. (On a terminal with fewer colours, such as 8
bg + 16 fg, it will simply desist and let the cterm= ctermbg= ctermfg=
colours remain in force.) This way, if your terminal has 88 or more
colours, you'll get approximately the same look and feel as in gvim. I
like it but of course YMMV.
See also http://vim.wikia.com/wiki/Using_GUI_color_settings_in_a_terminal
Best regards,
Tony.
--
GALAHAD: No. Look, I can tackle this lot single-handed!
GIRLS: Yes, yes, let him Tackle us single-handed!
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
--
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
RE: good 256 color theme for C
Chris Jones wrote:
>>> Ok, My terminal supports 256 colors, How can i use all the 256
>>> colors in VIM in a non gui terminal.
>>
>> http://vim.wikia.com/wiki/256_colors_in_vim
>
> Provided the OP does NOT read the tip and reads Steven
> Black's comment at the bottom of the page instead :-)
Any chance of someone fixing the tip?
If the advice in the body of the tip is not helpful, please just
delete it and move what you think is good into the tip body.
Don't worry about crediting anyone because all the history is
retained and people can see what happened.
I can clean up formatting and English, but I'm not much help
with some topics, like that tip.
People can edit as an IP address, or it's easy to register an
account (enter a bogus birthdate indicating you are more than
13 years old; Google COPPA if want to know why that's needed).
John
--
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
>>> Ok, My terminal supports 256 colors, How can i use all the 256
>>> colors in VIM in a non gui terminal.
>>
>> http://vim.wikia.com/wiki/256_colors_in_vim
>
> Provided the OP does NOT read the tip and reads Steven
> Black's comment at the bottom of the page instead :-)
Any chance of someone fixing the tip?
If the advice in the body of the tip is not helpful, please just
delete it and move what you think is good into the tip body.
Don't worry about crediting anyone because all the history is
retained and people can see what happened.
I can clean up formatting and English, but I'm not much help
with some topics, like that tip.
People can edit as an IP address, or it's easy to register an
account (enter a bogus birthdate indicating you are more than
13 years old; Google COPPA if want to know why that's needed).
John
--
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
Re: good 256 color theme for C
On Mon, Apr 30, 2012 at 07:18:31AM EDT, Christian Brabandt wrote:
> On Mo, 30 Apr 2012, sinbad wrote:
> > Ok, My terminal supports 256 colors, How can i use all the 256 colors
> > in VIM in a non gui terminal.
>
> http://vim.wikia.com/wiki/256_colors_in_vim
Provided the OP does NOT read the tip and reads Steven Black's comment
at the bottom of the page instead :-)
CJ
--
ALL YOUR BASE ARE BELONG TO US!
--
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
> On Mo, 30 Apr 2012, sinbad wrote:
> > Ok, My terminal supports 256 colors, How can i use all the 256 colors
> > in VIM in a non gui terminal.
>
> http://vim.wikia.com/wiki/256_colors_in_vim
Provided the OP does NOT read the tip and reads Steven Black's comment
at the bottom of the page instead :-)
CJ
--
ALL YOUR BASE ARE BELONG TO US!
--
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
Re: Colorschemes and split window
On Monday, April 30, 2012 8:15:26 AM UTC-5, rameo wrote:
> It seems that I have found the solution (after many many hours of trying :-( )
>
> I created the function below.
> The function must do this (and seems to do it):
>
> a) when there is only 1 window:
> check if filetype is "vim" --> Dark_ColorScheme
> if filetype is not "vim" --> Light_ColorScheme
> b) when there is a split window:
> check if exist split window colorscheme variable (g:splitcolor)
> if yes, colorscheme of splitwindow = g:splitcolor
>
> when leaving split window:
> keep the value of the current color in g:splitcolor
>
> Can anyone tell me if I made a mistake and if the function can be simplified?
>
> function SetColors()
> if winnr('$') > 1
> if exists('g:splitcolor')
> exe 'colors '.g:splitcolor
> else
> exe 'colors Light_ColorScheme'
> endif
> elseif winnr('$') == 1 && &ft == 'vim'
> exe 'colors Dark_ColorScheme'
> elseif winnr('$') == 1 && &ft != 'vim'
> exe 'colors Light_ColorScheme'
> endif
> endfunction
> function KeepColors()
> if winnr('$') > 1
> let g:splitcolor = g:colors_name
> endif
> endfunction
> augroup filetype_colorscheme
> au BufEnter * call SetColors()
> au BufLeave * call KeepColors()
> augroup END
Looks like it should do what you want, just fine. A minor note, you don't need the exe if you're providing the colorscheme name literally, e.g. "exe 'colors Dark_ColorScheme'" could be just "colors Dark_ColorScheme", but that's not really an important detail; it should work fine as-is.
--
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
> It seems that I have found the solution (after many many hours of trying :-( )
>
> I created the function below.
> The function must do this (and seems to do it):
>
> a) when there is only 1 window:
> check if filetype is "vim" --> Dark_ColorScheme
> if filetype is not "vim" --> Light_ColorScheme
> b) when there is a split window:
> check if exist split window colorscheme variable (g:splitcolor)
> if yes, colorscheme of splitwindow = g:splitcolor
>
> when leaving split window:
> keep the value of the current color in g:splitcolor
>
> Can anyone tell me if I made a mistake and if the function can be simplified?
>
> function SetColors()
> if winnr('$') > 1
> if exists('g:splitcolor')
> exe 'colors '.g:splitcolor
> else
> exe 'colors Light_ColorScheme'
> endif
> elseif winnr('$') == 1 && &ft == 'vim'
> exe 'colors Dark_ColorScheme'
> elseif winnr('$') == 1 && &ft != 'vim'
> exe 'colors Light_ColorScheme'
> endif
> endfunction
> function KeepColors()
> if winnr('$') > 1
> let g:splitcolor = g:colors_name
> endif
> endfunction
> augroup filetype_colorscheme
> au BufEnter * call SetColors()
> au BufLeave * call KeepColors()
> augroup END
Looks like it should do what you want, just fine. A minor note, you don't need the exe if you're providing the colorscheme name literally, e.g. "exe 'colors Dark_ColorScheme'" could be just "colors Dark_ColorScheme", but that's not really an important detail; it should work fine as-is.
--
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
Re: map Ctrl with special characters
On Saturday, April 28, 2012 2:39:45 AM UTC-5, rameo wrote:
> On Friday, April 27, 2012 5:45:15 PM UTC+2, rameo wrote:
> > I still have problems mapping keys.
> >
> > On my keyboard I have these keys I want to map:
> > <C-ò>
> > <C-à>
> > <C-è>
> > <C-ù>
> > <C-ì>
> >
> > Tony once told in a message these info:
> > ò = (0xF2, o-grave) and <M-r> (Alt+0x72, Alt-r)
> > à = (0xE0, a-grave) and <M-`> (Alt+0x60, Alt-backtick)
> > è = (0xE8, e-grave) and <M-h> (Alt+0x68, Alt-h)
> > ù = (0xF9, u-grave) and <M-y> (Alt+0x79, Alt-y)
> > ì = (0xEC, i-grave) and <M-l> (Alt+0x6C, Alt-l)
> >
> > But how to combine these letters to the Ctrl key?
>
>
> When I hit Ctrl-K in insert mode followed by Ctrl-ò nothing happened.
> When I hit Ctrl-Q (I have the gvim win version) in insert mode followed by Ctrl-ò again nothing happened.
>
> Yes ^V (+ ^K) doesn't disappear near the bottom right corner of the Vim screen as you've indicated.
>
> Does this mean that I can't map these keys with Ctrl?
> I had to use C-Q.
Yes, as Tony said, if you press CTRL-V/CTRL-Q in insert mode, followed by your key combination, and nothing happens, then Vim does not even get the key sequence and you cannot map 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
> On Friday, April 27, 2012 5:45:15 PM UTC+2, rameo wrote:
> > I still have problems mapping keys.
> >
> > On my keyboard I have these keys I want to map:
> > <C-ò>
> > <C-à>
> > <C-è>
> > <C-ù>
> > <C-ì>
> >
> > Tony once told in a message these info:
> > ò = (0xF2, o-grave) and <M-r> (Alt+0x72, Alt-r)
> > à = (0xE0, a-grave) and <M-`> (Alt+0x60, Alt-backtick)
> > è = (0xE8, e-grave) and <M-h> (Alt+0x68, Alt-h)
> > ù = (0xF9, u-grave) and <M-y> (Alt+0x79, Alt-y)
> > ì = (0xEC, i-grave) and <M-l> (Alt+0x6C, Alt-l)
> >
> > But how to combine these letters to the Ctrl key?
>
>
> When I hit Ctrl-K in insert mode followed by Ctrl-ò nothing happened.
> When I hit Ctrl-Q (I have the gvim win version) in insert mode followed by Ctrl-ò again nothing happened.
>
> Yes ^V (+ ^K) doesn't disappear near the bottom right corner of the Vim screen as you've indicated.
>
> Does this mean that I can't map these keys with Ctrl?
> I had to use C-Q.
Yes, as Tony said, if you press CTRL-V/CTRL-Q in insert mode, followed by your key combination, and nothing happens, then Vim does not even get the key sequence and you cannot map 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
Re: gtk-config not even tried
> (...) In all cases you need
> *development* packages for every single bit of software that will be
> compiled into your application.
>
(...)
Well, the problem is: I'm not using Linux, but HP-UX and I don't know how to get gtk-devel. I'm offered "gtk+-1.2.10", "gtk+2-2.24.10", "gtk+3-3.2.4" and all are described as "Gimp Toolkit for creating graphical user interfaces" but nothing beginning with gtk and ending with something like "dev" or "devel".
--
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
> *development* packages for every single bit of software that will be
> compiled into your application.
>
(...)
Well, the problem is: I'm not using Linux, but HP-UX and I don't know how to get gtk-devel. I'm offered "gtk+-1.2.10", "gtk+2-2.24.10", "gtk+3-3.2.4" and all are described as "Gimp Toolkit for creating graphical user interfaces" but nothing beginning with gtk and ending with something like "dev" or "devel".
--
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
Re: Colorschemes and split window
It seems that I have found the solution (after many many hours of trying :-( )
I created the function below.
The function must do this (and seems to do it):
a) when there is only 1 window:
check if filetype is "vim" --> Dark_ColorScheme
if filetype is not "vim" --> Light_ColorScheme
b) when there is a split window:
check if exist split window colorscheme variable (g:splitcolor)
if yes, colorscheme of splitwindow = g:splitcolor
when leaving split window:
keep the value of the current color in g:splitcolor
Can anyone tell me if I made a mistake and if the function can be simplified?
function SetColors()
if winnr('$') > 1
if exists('g:splitcolor')
exe 'colors '.g:splitcolor
else
exe 'colors Light_ColorScheme'
endif
elseif winnr('$') == 1 && &ft == 'vim'
exe 'colors Dark_ColorScheme'
elseif winnr('$') == 1 && &ft != 'vim'
exe 'colors Light_ColorScheme'
endif
endfunction
function KeepColors()
if winnr('$') > 1
let g:splitcolor = g:colors_name
endif
endfunction
augroup filetype_colorscheme
au BufEnter * call SetColors()
au BufLeave * call KeepColors()
augroup END
--
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
I created the function below.
The function must do this (and seems to do it):
a) when there is only 1 window:
check if filetype is "vim" --> Dark_ColorScheme
if filetype is not "vim" --> Light_ColorScheme
b) when there is a split window:
check if exist split window colorscheme variable (g:splitcolor)
if yes, colorscheme of splitwindow = g:splitcolor
when leaving split window:
keep the value of the current color in g:splitcolor
Can anyone tell me if I made a mistake and if the function can be simplified?
function SetColors()
if winnr('$') > 1
if exists('g:splitcolor')
exe 'colors '.g:splitcolor
else
exe 'colors Light_ColorScheme'
endif
elseif winnr('$') == 1 && &ft == 'vim'
exe 'colors Dark_ColorScheme'
elseif winnr('$') == 1 && &ft != 'vim'
exe 'colors Light_ColorScheme'
endif
endfunction
function KeepColors()
if winnr('$') > 1
let g:splitcolor = g:colors_name
endif
endfunction
augroup filetype_colorscheme
au BufEnter * call SetColors()
au BufLeave * call KeepColors()
augroup END
--
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
Re: good 256 color theme for C
On Mon, 2012-04-30 at 01:23 -0700, sinbad wrote:
> I just started using tmux, and i am exploring 256 color option of the
> terminal.
> Is there any good colorscheme that uses theses colors effectively,
> especially
> for C programming ?
>
> cheers
>
I use xterm16
--
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
> I just started using tmux, and i am exploring 256 color option of the
> terminal.
> Is there any good colorscheme that uses theses colors effectively,
> especially
> for C programming ?
>
> cheers
>
I use xterm16
--
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
Re: good 256 color theme for C
Hi sinbad!
On Mo, 30 Apr 2012, sinbad wrote:
> Ok, My terminal supports 256 colors, How can i use all the 256 colors
> in VIM in a non gui terminal.
> Obviously if the terminal supports 256 colors, there should be someway
> of using it in VIM as well ?
http://vim.wikia.com/wiki/256_colors_in_vim
regards,
Christian
--
Wir sind über'n Berg - es geht bergab!
--
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
On Mo, 30 Apr 2012, sinbad wrote:
> Ok, My terminal supports 256 colors, How can i use all the 256 colors
> in VIM in a non gui terminal.
> Obviously if the terminal supports 256 colors, there should be someway
> of using it in VIM as well ?
http://vim.wikia.com/wiki/256_colors_in_vim
regards,
Christian
--
Wir sind über'n Berg - es geht bergab!
--
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
Re: good 256 color theme for C
On Apr 30, 3:17 pm, John Little <John.B.Lit...@gmail.com> wrote:
> On Monday, April 30, 2012 9:55:16 PM UTC+12, sinbad wrote:
> >I just started using tmux, and i am exploring 256 color option of the terminal.
>
> Check out the CSApprox.vim plugin.http://www.vim.org/scripts/script.php?script_id=2390
>
> "This plugin makes GVim-only colorschemes Just Work in terminal Vim".
>
> > does guibg=#aabbcc, doesn't work in non gvim.
>
> Nope, gvim means gui vim.
>
> > hi Comment ctermfg=cyan guibg=#592929 --> this doesn't work.
>
> > but, it works in the following vimrc command.
>
> > highlight OverLength ctermbg=red ctermfg=white guibg=#592929
> > match OverLength /\%81v.*/
>
> Forgive me if I'm pointing out the obvious, but that highlight has "ctermbg", the first doesn't.
>
> Regards, John
Ok, My terminal supports 256 colors, How can i use all the 256 colors
in VIM in a non gui terminal.
Obviously if the terminal supports 256 colors, there should be someway
of using it in VIM as well ?
--
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
> On Monday, April 30, 2012 9:55:16 PM UTC+12, sinbad wrote:
> >I just started using tmux, and i am exploring 256 color option of the terminal.
>
> Check out the CSApprox.vim plugin.http://www.vim.org/scripts/script.php?script_id=2390
>
> "This plugin makes GVim-only colorschemes Just Work in terminal Vim".
>
> > does guibg=#aabbcc, doesn't work in non gvim.
>
> Nope, gvim means gui vim.
>
> > hi Comment ctermfg=cyan guibg=#592929 --> this doesn't work.
>
> > but, it works in the following vimrc command.
>
> > highlight OverLength ctermbg=red ctermfg=white guibg=#592929
> > match OverLength /\%81v.*/
>
> Forgive me if I'm pointing out the obvious, but that highlight has "ctermbg", the first doesn't.
>
> Regards, John
Ok, My terminal supports 256 colors, How can i use all the 256 colors
in VIM in a non gui terminal.
Obviously if the terminal supports 256 colors, there should be someway
of using it in VIM as well ?
--
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
Re: good 256 color theme for C
On Monday, April 30, 2012 9:55:16 PM UTC+12, sinbad wrote:
>I just started using tmux, and i am exploring 256 color option of the terminal.
Check out the CSApprox.vim plugin.
http://www.vim.org/scripts/script.php?script_id=2390
"This plugin makes GVim-only colorschemes Just Work in terminal Vim".
> does guibg=#aabbcc, doesn't work in non gvim.
Nope, gvim means gui vim.
> hi Comment ctermfg=cyan guibg=#592929 --> this doesn't work.
>
> but, it works in the following vimrc command.
>
> highlight OverLength ctermbg=red ctermfg=white guibg=#592929
> match OverLength /\%81v.*/
Forgive me if I'm pointing out the obvious, but that highlight has "ctermbg", the first doesn't.
Regards, John
--
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
>I just started using tmux, and i am exploring 256 color option of the terminal.
Check out the CSApprox.vim plugin.
http://www.vim.org/scripts/script.php?script_id=2390
"This plugin makes GVim-only colorschemes Just Work in terminal Vim".
> does guibg=#aabbcc, doesn't work in non gvim.
Nope, gvim means gui vim.
> hi Comment ctermfg=cyan guibg=#592929 --> this doesn't work.
>
> but, it works in the following vimrc command.
>
> highlight OverLength ctermbg=red ctermfg=white guibg=#592929
> match OverLength /\%81v.*/
Forgive me if I'm pointing out the obvious, but that highlight has "ctermbg", the first doesn't.
Regards, John
--
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
Re: good 256 color theme for C
On Apr 30, 1:23 pm, sinbad <sinbad.sin...@gmail.com> wrote:
> I just started using tmux, and i am exploring 256 color option of the
> terminal.
> Is there any good colorscheme that uses theses colors effectively,
> especially
> for C programming ?
>
> cheers
does guibg=#aabbcc, doesn't work in non gvim.
i am seeing two different behaviors,
hi Comment ctermfg=cyan guibg=#592929 --> this doesn't work.
but, it works in the following vimrc command.
highlight OverLength ctermbg=red ctermfg=white guibg=#592929
match OverLength /\%81v.*/
why is this behavior ?
--
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
> I just started using tmux, and i am exploring 256 color option of the
> terminal.
> Is there any good colorscheme that uses theses colors effectively,
> especially
> for C programming ?
>
> cheers
does guibg=#aabbcc, doesn't work in non gvim.
i am seeing two different behaviors,
hi Comment ctermfg=cyan guibg=#592929 --> this doesn't work.
but, it works in the following vimrc command.
highlight OverLength ctermbg=red ctermfg=white guibg=#592929
match OverLength /\%81v.*/
why is this behavior ?
--
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
good 256 color theme for C
I just started using tmux, and i am exploring 256 color option of the
terminal.
Is there any good colorscheme that uses theses colors effectively,
especially
for C programming ?
cheers
--
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
terminal.
Is there any good colorscheme that uses theses colors effectively,
especially
for C programming ?
cheers
--
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
Sunday, April 29, 2012
RE: Cursor anomoly: apparent and actual positions differ
I confirm there is a bug (Vim 7.3.509 on Windows).
I slightly simplified the example to show the minimum that
demonstrates the problem, as below:
" ----------- start bug.txt ------------------
" To show anomaly, launch Vim as:
" vim -N -u NONE bug.txt
" and enter:
" :so %
" :13
"
if v:version >= 700
au BufLeave * let b:winview = winsaveview()
au BufEnter * if exists('b:winview') | call winrestview(b:winview) | endif
endif
"
" Now enter:
" :copen
" CTRL-W CTRL-W
" Stop and see where cursor is, then press j
" which shows that cursor was NOT where it appeared to be.
" First pressing Ctrl-L or entering :redraw do not help.
" ----------- end bug.txt --------------------
There is no problem if use ':new' or ':rightbelow new' instead
of ':copen'. Seems the quickfix window is part of problem.
I can also see the problem if start Vim normally, then just yank
the two au commands and use :@" to source them, then enter
:copen Ctrl-W w. I have seen the cursor end up in the tildes
after end-of-file.
Using ':echo b:winview' shows:
{'lnum': 13, 'leftcol': 0, 'col': 0, 'topfill': 0,
'topline': 11, 'coladd': 0, 'skipcol': 0, 'curswant': 0}
It looks like topline is wrong.
John
--
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
I slightly simplified the example to show the minimum that
demonstrates the problem, as below:
" ----------- start bug.txt ------------------
" To show anomaly, launch Vim as:
" vim -N -u NONE bug.txt
" and enter:
" :so %
" :13
"
if v:version >= 700
au BufLeave * let b:winview = winsaveview()
au BufEnter * if exists('b:winview') | call winrestview(b:winview) | endif
endif
"
" Now enter:
" :copen
" CTRL-W CTRL-W
" Stop and see where cursor is, then press j
" which shows that cursor was NOT where it appeared to be.
" First pressing Ctrl-L or entering :redraw do not help.
" ----------- end bug.txt --------------------
There is no problem if use ':new' or ':rightbelow new' instead
of ':copen'. Seems the quickfix window is part of problem.
I can also see the problem if start Vim normally, then just yank
the two au commands and use :@" to source them, then enter
:copen Ctrl-W w. I have seen the cursor end up in the tildes
after end-of-file.
Using ':echo b:winview' shows:
{'lnum': 13, 'leftcol': 0, 'col': 0, 'topfill': 0,
'topline': 11, 'coladd': 0, 'skipcol': 0, 'curswant': 0}
It looks like topline is wrong.
John
--
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
Cursor anomoly: apparent and actual positions differ
All,
I've noticed some strange cursor behavior when following one of
the Wiki tips. Below is a 26-line-long file to describe and
demonstrate the problem.
" ----------- start of "cursor-pos-anomoly.txt" ------------------
" To show anomoly, launch Vim as:
" vim -u NONE cursor-pos-anomoly.txt "+source %"
"
" This demonstrates a cursor anomoly (apparent vs. actual position).
"
set nocp | set hls | /^" \(Start\|End\)
"
" From http://vim.wikia.com/wiki/Avoid_scrolling_when_switch_buffers:
" When switching buffers, preserve window view.
if v:version >= 700
au BufLeave * let b:winview = winsaveview()
au BufEnter * if exists('b:winview') | call winrestview(b:winview) | endif
endif
"
" You should initially find the cursor on the following line:
" Start on this line
"
" End seemingly on this line after running the two commands below:
"
" :copen
" CTRL-W CTRL-W
"
" But you're actually still on the "Start" line, which you can see by
" pressing one of these three keys, for example: C D j
" ------------- end of "cursor-pos-anomoly.txt" ------------------
The fact that the cursor appears to be on one line but is
functionally on another seems like a bug to me.
As a separate issue, I don't see anything wrong with the logic
in the wiki tip, but perhaps someone has a better suggestion to
achieve the tip's goal.
Thanks,
Michael Henry
--
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
I've noticed some strange cursor behavior when following one of
the Wiki tips. Below is a 26-line-long file to describe and
demonstrate the problem.
" ----------- start of "cursor-pos-anomoly.txt" ------------------
" To show anomoly, launch Vim as:
" vim -u NONE cursor-pos-anomoly.txt "+source %"
"
" This demonstrates a cursor anomoly (apparent vs. actual position).
"
set nocp | set hls | /^" \(Start\|End\)
"
" From http://vim.wikia.com/wiki/Avoid_scrolling_when_switch_buffers:
" When switching buffers, preserve window view.
if v:version >= 700
au BufLeave * let b:winview = winsaveview()
au BufEnter * if exists('b:winview') | call winrestview(b:winview) | endif
endif
"
" You should initially find the cursor on the following line:
" Start on this line
"
" End seemingly on this line after running the two commands below:
"
" :copen
" CTRL-W CTRL-W
"
" But you're actually still on the "Start" line, which you can see by
" pressing one of these three keys, for example: C D j
" ------------- end of "cursor-pos-anomoly.txt" ------------------
The fact that the cursor appears to be on one line but is
functionally on another seems like a bug to me.
As a separate issue, I don't see anything wrong with the logic
in the wiki tip, but perhaps someone has a better suggestion to
achieve the tip's goal.
Thanks,
Michael Henry
--
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
Re: Colorschemes and split window
On Saturday, April 28, 2012 12:39:51 AM UTC+2, Tony Mechelynck wrote:
> On 27/04/12 23:41, rameo wrote:
> > On Friday, April 27, 2012 8:29:03 PM UTC+2, Tony Mechelynck wrote:
> >> On 27/04/12 18:34, rameo wrote:
> >>> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
> >>>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
> >>>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
> >>>>>
> >>>>> augroup filetype_colorscheme
> >>>>> au BufEnter *
> >>>>> \ if !exists('b:colors_name')
> >>>>> \ | if &ft == "vim"
> >>>>> \ | let b:colors_name = 'color_dark'
> >>>>> \ | else
> >>>>> \ | let b:colors_name = 'color_light'
> >>>>> \ | endif
> >>>>> \ | endif
> >>>>> \ | exe 'colorscheme' b:colors_name
> >>>>> augroup END
> >>>>>
> >>>>> However, it doesn't work fine in split windows.
> >>>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
> >>>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
> >>>>>
> >>>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
> >>>>>
> >>>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
> >>>>> Can anyone help me?
> >>>>
> >>>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
> >>>
> >>> Hi Ben,
> >>>
> >>> That's what I tried.
> >>> But wherever I put it in above code it doesn't work.
> >>> Where would you place this in above code?
> >>>
> >>
> >> Around your autocommand:
> >>
> >> augroup filetype_colorscheme
> >> au BufEnter *
> >> \ if winnr('$') == 1
> >> \ | if !exists('b:colors_name')
> >> \ | if &ft == "vim"
> >> \ | let b:colors_name = 'color_dark'
> >> \ | else
> >> \ | let b:colors_name = 'color_light'
> >> \ | endif
> >> \ | endif
> >> \ | exe 'colorscheme' b:colors_name
> >> \ | else
> >> \ | colorscheme default
> >> | | endif
> >> augroup END
> >>
> >> or (maybe more readable)
> >>
> >> function SetColors()
> >> if exists('b:colors_name')
> >> exe 'colorscheme' b:colors_name
> >> return
> >> endif
> >> if winnr('$') > 1
> >> colorscheme default
> >> elseif &ft == 'vim'
> >> colorscheme color_dark
> >> else
> >> colorscheme color_light
> >> endif
> >> let b:colors_name = g:colors_name
> >> endfunction
> >> augroup filetype_colorscheme
> >> au BufEnter * call SetColors()
> >> augroup END
> >>
> >> This way, the autocommand will be defined unconditionally, but if it
> >> finds that at BufEnter three are more than one window in the current tab
> >> it will go back to the default scheme.
> >>
> >>
> >> Best regards,
> >> Tony.
> >> --
> >> Actor: So what do you do for a living?
> >> Doris: I work for a company that makes deceptively shallow serving
> >> dishes for Chinese restaurants.
> >> -- Woody Allen, "Without Feathers"
> >
> > Thank you very much.
> >
> > Just one little thing..
> >
> > What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
> > (when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
> >
> > Is it possible to do?
> >
>
> Well, it is possible, with a slight refinement to the above. You may
> want to remember the Vim terminology:
>
> - buffer: one file (or file-like data) in Vim memory, with the relevant
> metadata. It may be displayed in zero or more windows.
> - window: a viewport into a buffer. If several windows display the same
> buffer, changes made in one are reflected in all others. Also, if
> several windows display the same buffer, the displayed regions of that
> buffer may or may not overlap.
> - tab page: a set of one or more windows which are displayed at the same
> time.
>
> "another split buffer in a split window" has no meaning. Maybe you meant
> "another window in the current tab"?
>
> You can use variables with different scopes:
>
> b:something local to a buffer
> g:something global to all Vim
> l:something local to a function
> s:something local to a script
> t:something local to a tab page
> v:something predefined at compile-time
> w:something local to a window
>
> With no prefix it falls back to v: for compatibility for a few
> predefined names, otherwise l: if inside a function, otherwise g:
>
> See also the help for the following functions:
>
> bufname()
> bufnr()
> bufwinnr()
> tabpagebuflist()
> tabpagenr()
> tabpagewinnr()
> winbufnr()
> winnr()
>
> See also |setting-tabline| for an example of how to use these functions
> (albeit for a different purpose).
>
>
> Best regards,
> Tony.
> --
> Ten million Linux users can't be wrong!
Can't find the solution.
I tried to change g:colors-name in w/t/s/b:colors-name but nothing works.
Tony or anyone else, any idea?
--
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
> On 27/04/12 23:41, rameo wrote:
> > On Friday, April 27, 2012 8:29:03 PM UTC+2, Tony Mechelynck wrote:
> >> On 27/04/12 18:34, rameo wrote:
> >>> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
> >>>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
> >>>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
> >>>>>
> >>>>> augroup filetype_colorscheme
> >>>>> au BufEnter *
> >>>>> \ if !exists('b:colors_name')
> >>>>> \ | if &ft == "vim"
> >>>>> \ | let b:colors_name = 'color_dark'
> >>>>> \ | else
> >>>>> \ | let b:colors_name = 'color_light'
> >>>>> \ | endif
> >>>>> \ | endif
> >>>>> \ | exe 'colorscheme' b:colors_name
> >>>>> augroup END
> >>>>>
> >>>>> However, it doesn't work fine in split windows.
> >>>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
> >>>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
> >>>>>
> >>>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
> >>>>>
> >>>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
> >>>>> Can anyone help me?
> >>>>
> >>>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
> >>>
> >>> Hi Ben,
> >>>
> >>> That's what I tried.
> >>> But wherever I put it in above code it doesn't work.
> >>> Where would you place this in above code?
> >>>
> >>
> >> Around your autocommand:
> >>
> >> augroup filetype_colorscheme
> >> au BufEnter *
> >> \ if winnr('$') == 1
> >> \ | if !exists('b:colors_name')
> >> \ | if &ft == "vim"
> >> \ | let b:colors_name = 'color_dark'
> >> \ | else
> >> \ | let b:colors_name = 'color_light'
> >> \ | endif
> >> \ | endif
> >> \ | exe 'colorscheme' b:colors_name
> >> \ | else
> >> \ | colorscheme default
> >> | | endif
> >> augroup END
> >>
> >> or (maybe more readable)
> >>
> >> function SetColors()
> >> if exists('b:colors_name')
> >> exe 'colorscheme' b:colors_name
> >> return
> >> endif
> >> if winnr('$') > 1
> >> colorscheme default
> >> elseif &ft == 'vim'
> >> colorscheme color_dark
> >> else
> >> colorscheme color_light
> >> endif
> >> let b:colors_name = g:colors_name
> >> endfunction
> >> augroup filetype_colorscheme
> >> au BufEnter * call SetColors()
> >> augroup END
> >>
> >> This way, the autocommand will be defined unconditionally, but if it
> >> finds that at BufEnter three are more than one window in the current tab
> >> it will go back to the default scheme.
> >>
> >>
> >> Best regards,
> >> Tony.
> >> --
> >> Actor: So what do you do for a living?
> >> Doris: I work for a company that makes deceptively shallow serving
> >> dishes for Chinese restaurants.
> >> -- Woody Allen, "Without Feathers"
> >
> > Thank you very much.
> >
> > Just one little thing..
> >
> > What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
> > (when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
> >
> > Is it possible to do?
> >
>
> Well, it is possible, with a slight refinement to the above. You may
> want to remember the Vim terminology:
>
> - buffer: one file (or file-like data) in Vim memory, with the relevant
> metadata. It may be displayed in zero or more windows.
> - window: a viewport into a buffer. If several windows display the same
> buffer, changes made in one are reflected in all others. Also, if
> several windows display the same buffer, the displayed regions of that
> buffer may or may not overlap.
> - tab page: a set of one or more windows which are displayed at the same
> time.
>
> "another split buffer in a split window" has no meaning. Maybe you meant
> "another window in the current tab"?
>
> You can use variables with different scopes:
>
> b:something local to a buffer
> g:something global to all Vim
> l:something local to a function
> s:something local to a script
> t:something local to a tab page
> v:something predefined at compile-time
> w:something local to a window
>
> With no prefix it falls back to v: for compatibility for a few
> predefined names, otherwise l: if inside a function, otherwise g:
>
> See also the help for the following functions:
>
> bufname()
> bufnr()
> bufwinnr()
> tabpagebuflist()
> tabpagenr()
> tabpagewinnr()
> winbufnr()
> winnr()
>
> See also |setting-tabline| for an example of how to use these functions
> (albeit for a different purpose).
>
>
> Best regards,
> Tony.
> --
> Ten million Linux users can't be wrong!
Can't find the solution.
I tried to change g:colors-name in w/t/s/b:colors-name but nothing works.
Tony or anyone else, any idea?
--
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
Saturday, April 28, 2012
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
On Saturday, April 28, 2012 7:00:43 AM UTC+12, pixelterra wrote:
> Actually, I was wrong, this doesn't work. Sorry for the confusion. Any other options?
It should. Have you got any of VISUAL, EDITOR or FCEDIT set? (A pitfall is to set one of these to just "gvim", which won't work, "gvim -f" is needed.) Is TMPDIR set?
Does vim open in your terminal window? What file is it using? (mine uses /tmp/bash-fc-nnnnnnnnnnn where nnnnnnnnnnn appears to be generated randomly).
You might try setting EDITOR="vim -u NONE" to eliminate the possibility of a .vimrc or plugin interfering.
Regards, John
--
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
> Actually, I was wrong, this doesn't work. Sorry for the confusion. Any other options?
It should. Have you got any of VISUAL, EDITOR or FCEDIT set? (A pitfall is to set one of these to just "gvim", which won't work, "gvim -f" is needed.) Is TMPDIR set?
Does vim open in your terminal window? What file is it using? (mine uses /tmp/bash-fc-nnnnnnnnnnn where nnnnnnnnnnn appears to be generated randomly).
You might try setting EDITOR="vim -u NONE" to eliminate the possibility of a .vimrc or plugin interfering.
Regards, John
--
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
Re: map Ctrl with special characters
On Friday, April 27, 2012 5:45:15 PM UTC+2, rameo wrote:
> I still have problems mapping keys.
>
> On my keyboard I have these keys I want to map:
> <C-ò>
> <C-à>
> <C-è>
> <C-ù>
> <C-ì>
>
> Tony once told in a message these info:
> ò = (0xF2, o-grave) and <M-r> (Alt+0x72, Alt-r)
> à = (0xE0, a-grave) and <M-`> (Alt+0x60, Alt-backtick)
> è = (0xE8, e-grave) and <M-h> (Alt+0x68, Alt-h)
> ù = (0xF9, u-grave) and <M-y> (Alt+0x79, Alt-y)
> ì = (0xEC, i-grave) and <M-l> (Alt+0x6C, Alt-l)
>
> But how to combine these letters to the Ctrl key?
When I hit Ctrl-K in insert mode followed by Ctrl-ò nothing happened.
When I hit Ctrl-Q (I have the gvim win version) in insert mode followed by Ctrl-ò again nothing happened.
Yes ^V (+ ^K) doesn't disappear near the bottom right corner of the Vim screen as you've indicated.
Does this mean that I can't map these keys with Ctrl?
I had to use C-Q.
--
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
> I still have problems mapping keys.
>
> On my keyboard I have these keys I want to map:
> <C-ò>
> <C-à>
> <C-è>
> <C-ù>
> <C-ì>
>
> Tony once told in a message these info:
> ò = (0xF2, o-grave) and <M-r> (Alt+0x72, Alt-r)
> à = (0xE0, a-grave) and <M-`> (Alt+0x60, Alt-backtick)
> è = (0xE8, e-grave) and <M-h> (Alt+0x68, Alt-h)
> ù = (0xF9, u-grave) and <M-y> (Alt+0x79, Alt-y)
> ì = (0xEC, i-grave) and <M-l> (Alt+0x6C, Alt-l)
>
> But how to combine these letters to the Ctrl key?
When I hit Ctrl-K in insert mode followed by Ctrl-ò nothing happened.
When I hit Ctrl-Q (I have the gvim win version) in insert mode followed by Ctrl-ò again nothing happened.
Yes ^V (+ ^K) doesn't disappear near the bottom right corner of the Vim screen as you've indicated.
Does this mean that I can't map these keys with Ctrl?
I had to use C-Q.
--
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
Re: Colorschemes and split window
On Saturday, April 28, 2012 12:39:51 AM UTC+2, Tony Mechelynck wrote:
> On 27/04/12 23:41, rameo wrote:
> > On Friday, April 27, 2012 8:29:03 PM UTC+2, Tony Mechelynck wrote:
> >> On 27/04/12 18:34, rameo wrote:
> >>> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
> >>>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
> >>>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
> >>>>>
> >>>>> augroup filetype_colorscheme
> >>>>> au BufEnter *
> >>>>> \ if !exists('b:colors_name')
> >>>>> \ | if &ft == "vim"
> >>>>> \ | let b:colors_name = 'color_dark'
> >>>>> \ | else
> >>>>> \ | let b:colors_name = 'color_light'
> >>>>> \ | endif
> >>>>> \ | endif
> >>>>> \ | exe 'colorscheme' b:colors_name
> >>>>> augroup END
> >>>>>
> >>>>> However, it doesn't work fine in split windows.
> >>>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
> >>>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
> >>>>>
> >>>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
> >>>>>
> >>>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
> >>>>> Can anyone help me?
> >>>>
> >>>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
> >>>
> >>> Hi Ben,
> >>>
> >>> That's what I tried.
> >>> But wherever I put it in above code it doesn't work.
> >>> Where would you place this in above code?
> >>>
> >>
> >> Around your autocommand:
> >>
> >> augroup filetype_colorscheme
> >> au BufEnter *
> >> \ if winnr('$') == 1
> >> \ | if !exists('b:colors_name')
> >> \ | if &ft == "vim"
> >> \ | let b:colors_name = 'color_dark'
> >> \ | else
> >> \ | let b:colors_name = 'color_light'
> >> \ | endif
> >> \ | endif
> >> \ | exe 'colorscheme' b:colors_name
> >> \ | else
> >> \ | colorscheme default
> >> | | endif
> >> augroup END
> >>
> >> or (maybe more readable)
> >>
> >> function SetColors()
> >> if exists('b:colors_name')
> >> exe 'colorscheme' b:colors_name
> >> return
> >> endif
> >> if winnr('$') > 1
> >> colorscheme default
> >> elseif &ft == 'vim'
> >> colorscheme color_dark
> >> else
> >> colorscheme color_light
> >> endif
> >> let b:colors_name = g:colors_name
> >> endfunction
> >> augroup filetype_colorscheme
> >> au BufEnter * call SetColors()
> >> augroup END
> >>
> >> This way, the autocommand will be defined unconditionally, but if it
> >> finds that at BufEnter three are more than one window in the current tab
> >> it will go back to the default scheme.
> >>
> >>
> >> Best regards,
> >> Tony.
> >> --
> >> Actor: So what do you do for a living?
> >> Doris: I work for a company that makes deceptively shallow serving
> >> dishes for Chinese restaurants.
> >> -- Woody Allen, "Without Feathers"
> >
> > Thank you very much.
> >
> > Just one little thing..
> >
> > What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
> > (when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
> >
> > Is it possible to do?
> >
>
> Well, it is possible, with a slight refinement to the above. You may
> want to remember the Vim terminology:
>
> - buffer: one file (or file-like data) in Vim memory, with the relevant
> metadata. It may be displayed in zero or more windows.
> - window: a viewport into a buffer. If several windows display the same
> buffer, changes made in one are reflected in all others. Also, if
> several windows display the same buffer, the displayed regions of that
> buffer may or may not overlap.
> - tab page: a set of one or more windows which are displayed at the same
> time.
>
> "another split buffer in a split window" has no meaning. Maybe you meant
> "another window in the current tab"?
>
> You can use variables with different scopes:
>
> b:something local to a buffer
> g:something global to all Vim
> l:something local to a function
> s:something local to a script
> t:something local to a tab page
> v:something predefined at compile-time
> w:something local to a window
>
> With no prefix it falls back to v: for compatibility for a few
> predefined names, otherwise l: if inside a function, otherwise g:
>
> See also the help for the following functions:
>
> bufname()
> bufnr()
> bufwinnr()
> tabpagebuflist()
> tabpagenr()
> tabpagewinnr()
> winbufnr()
> winnr()
>
> See also |setting-tabline| for an example of how to use these functions
> (albeit for a different purpose).
>
>
> Best regards,
> Tony.
> --
> Ten million Linux users can't be wrong!
Yes I mean another window in the current tab.
But after an hour of reading help-files I don't have an idea how to adapt the script, sorry.
--
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
> On 27/04/12 23:41, rameo wrote:
> > On Friday, April 27, 2012 8:29:03 PM UTC+2, Tony Mechelynck wrote:
> >> On 27/04/12 18:34, rameo wrote:
> >>> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
> >>>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
> >>>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
> >>>>>
> >>>>> augroup filetype_colorscheme
> >>>>> au BufEnter *
> >>>>> \ if !exists('b:colors_name')
> >>>>> \ | if &ft == "vim"
> >>>>> \ | let b:colors_name = 'color_dark'
> >>>>> \ | else
> >>>>> \ | let b:colors_name = 'color_light'
> >>>>> \ | endif
> >>>>> \ | endif
> >>>>> \ | exe 'colorscheme' b:colors_name
> >>>>> augroup END
> >>>>>
> >>>>> However, it doesn't work fine in split windows.
> >>>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
> >>>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
> >>>>>
> >>>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
> >>>>>
> >>>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
> >>>>> Can anyone help me?
> >>>>
> >>>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
> >>>
> >>> Hi Ben,
> >>>
> >>> That's what I tried.
> >>> But wherever I put it in above code it doesn't work.
> >>> Where would you place this in above code?
> >>>
> >>
> >> Around your autocommand:
> >>
> >> augroup filetype_colorscheme
> >> au BufEnter *
> >> \ if winnr('$') == 1
> >> \ | if !exists('b:colors_name')
> >> \ | if &ft == "vim"
> >> \ | let b:colors_name = 'color_dark'
> >> \ | else
> >> \ | let b:colors_name = 'color_light'
> >> \ | endif
> >> \ | endif
> >> \ | exe 'colorscheme' b:colors_name
> >> \ | else
> >> \ | colorscheme default
> >> | | endif
> >> augroup END
> >>
> >> or (maybe more readable)
> >>
> >> function SetColors()
> >> if exists('b:colors_name')
> >> exe 'colorscheme' b:colors_name
> >> return
> >> endif
> >> if winnr('$') > 1
> >> colorscheme default
> >> elseif &ft == 'vim'
> >> colorscheme color_dark
> >> else
> >> colorscheme color_light
> >> endif
> >> let b:colors_name = g:colors_name
> >> endfunction
> >> augroup filetype_colorscheme
> >> au BufEnter * call SetColors()
> >> augroup END
> >>
> >> This way, the autocommand will be defined unconditionally, but if it
> >> finds that at BufEnter three are more than one window in the current tab
> >> it will go back to the default scheme.
> >>
> >>
> >> Best regards,
> >> Tony.
> >> --
> >> Actor: So what do you do for a living?
> >> Doris: I work for a company that makes deceptively shallow serving
> >> dishes for Chinese restaurants.
> >> -- Woody Allen, "Without Feathers"
> >
> > Thank you very much.
> >
> > Just one little thing..
> >
> > What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
> > (when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
> >
> > Is it possible to do?
> >
>
> Well, it is possible, with a slight refinement to the above. You may
> want to remember the Vim terminology:
>
> - buffer: one file (or file-like data) in Vim memory, with the relevant
> metadata. It may be displayed in zero or more windows.
> - window: a viewport into a buffer. If several windows display the same
> buffer, changes made in one are reflected in all others. Also, if
> several windows display the same buffer, the displayed regions of that
> buffer may or may not overlap.
> - tab page: a set of one or more windows which are displayed at the same
> time.
>
> "another split buffer in a split window" has no meaning. Maybe you meant
> "another window in the current tab"?
>
> You can use variables with different scopes:
>
> b:something local to a buffer
> g:something global to all Vim
> l:something local to a function
> s:something local to a script
> t:something local to a tab page
> v:something predefined at compile-time
> w:something local to a window
>
> With no prefix it falls back to v: for compatibility for a few
> predefined names, otherwise l: if inside a function, otherwise g:
>
> See also the help for the following functions:
>
> bufname()
> bufnr()
> bufwinnr()
> tabpagebuflist()
> tabpagenr()
> tabpagewinnr()
> winbufnr()
> winnr()
>
> See also |setting-tabline| for an example of how to use these functions
> (albeit for a different purpose).
>
>
> Best regards,
> Tony.
> --
> Ten million Linux users can't be wrong!
Yes I mean another window in the current tab.
But after an hour of reading help-files I don't have an idea how to adapt the script, sorry.
--
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
Friday, April 27, 2012
Re: Can Vim remember modes when switching between tabs?
That would probably be the simplest solution, since it's so simple to
enter the Insert mode when coming back to the tab.
-Andrei
On Apr 27, 4:22 pm, Ben Fritz <fritzophre...@gmail.com> wrote:
> On Friday, April 27, 2012 4:45:29 PM UTC-5, Andrei Zmievski wrote:
> > I originally noticed this in MacVim, but turns out this happens in the
> > terminal as well. If you have two tabs open and enter the Insert mode
> > in one, then switch to the other tab (by clicking on it in GUI, for
> > example), the Insert mode is still active. This wreaks havoc when I'm
> > editing something and want to quickly switch to the other tab to
> > search/look up/etc, because the Normal mode keystrokes get inserted
> > into the buffer.
>
> > Any workarounds for this?
>
> How about just always leaving insert mode when leaving the current tab page?
>
> autocmd TabLeave * stopinsert
--
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
enter the Insert mode when coming back to the tab.
-Andrei
On Apr 27, 4:22 pm, Ben Fritz <fritzophre...@gmail.com> wrote:
> On Friday, April 27, 2012 4:45:29 PM UTC-5, Andrei Zmievski wrote:
> > I originally noticed this in MacVim, but turns out this happens in the
> > terminal as well. If you have two tabs open and enter the Insert mode
> > in one, then switch to the other tab (by clicking on it in GUI, for
> > example), the Insert mode is still active. This wreaks havoc when I'm
> > editing something and want to quickly switch to the other tab to
> > search/look up/etc, because the Normal mode keystrokes get inserted
> > into the buffer.
>
> > Any workarounds for this?
>
> How about just always leaving insert mode when leaving the current tab page?
>
> autocmd TabLeave * stopinsert
--
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
Re: Can Vim remember modes when switching between tabs?
On Friday, April 27, 2012 4:45:29 PM UTC-5, Andrei Zmievski wrote:
> I originally noticed this in MacVim, but turns out this happens in the
> terminal as well. If you have two tabs open and enter the Insert mode
> in one, then switch to the other tab (by clicking on it in GUI, for
> example), the Insert mode is still active. This wreaks havoc when I'm
> editing something and want to quickly switch to the other tab to
> search/look up/etc, because the Normal mode keystrokes get inserted
> into the buffer.
>
> Any workarounds for this?
How about just always leaving insert mode when leaving the current tab page?
autocmd TabLeave * stopinsert
--
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
> I originally noticed this in MacVim, but turns out this happens in the
> terminal as well. If you have two tabs open and enter the Insert mode
> in one, then switch to the other tab (by clicking on it in GUI, for
> example), the Insert mode is still active. This wreaks havoc when I'm
> editing something and want to quickly switch to the other tab to
> search/look up/etc, because the Normal mode keystrokes get inserted
> into the buffer.
>
> Any workarounds for this?
How about just always leaving insert mode when leaving the current tab page?
autocmd TabLeave * stopinsert
--
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
Re: Can Vim remember modes when switching between tabs?
On 27/04/12 23:45, Andrei Zmievski wrote:
> I originally noticed this in MacVim, but turns out this happens in the
> terminal as well. If you have two tabs open and enter the Insert mode
> in one, then switch to the other tab (by clicking on it in GUI, for
> example), the Insert mode is still active. This wreaks havoc when I'm
> editing something and want to quickly switch to the other tab to
> search/look up/etc, because the Normal mode keystrokes get inserted
> into the buffer.
>
> Any workarounds for this?
>
You could use some b: variable to remember the mode, and define a
BufLeave autocommand to remember the current mode and a BufEnter
autocommand to set the mode. See also :help mode()
If it isn't possible to detect Insert mode directly from an autocommand,
use (in your status line) a function which returns the empty string,
with a side-effect to set the appropriate buffer-local variable.
Best regards,
Tony.
--
God must love assholes -- She made so many of them.
--
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
> I originally noticed this in MacVim, but turns out this happens in the
> terminal as well. If you have two tabs open and enter the Insert mode
> in one, then switch to the other tab (by clicking on it in GUI, for
> example), the Insert mode is still active. This wreaks havoc when I'm
> editing something and want to quickly switch to the other tab to
> search/look up/etc, because the Normal mode keystrokes get inserted
> into the buffer.
>
> Any workarounds for this?
>
You could use some b: variable to remember the mode, and define a
BufLeave autocommand to remember the current mode and a BufEnter
autocommand to set the mode. See also :help mode()
If it isn't possible to detect Insert mode directly from an autocommand,
use (in your status line) a function which returns the empty string,
with a side-effect to set the appropriate buffer-local variable.
Best regards,
Tony.
--
God must love assholes -- She made so many of them.
--
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
Re: Colorschemes and split window
On 27/04/12 23:41, rameo wrote:
> On Friday, April 27, 2012 8:29:03 PM UTC+2, Tony Mechelynck wrote:
>> On 27/04/12 18:34, rameo wrote:
>>> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
>>>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
>>>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
>>>>>
>>>>> augroup filetype_colorscheme
>>>>> au BufEnter *
>>>>> \ if !exists('b:colors_name')
>>>>> \ | if &ft == "vim"
>>>>> \ | let b:colors_name = 'color_dark'
>>>>> \ | else
>>>>> \ | let b:colors_name = 'color_light'
>>>>> \ | endif
>>>>> \ | endif
>>>>> \ | exe 'colorscheme' b:colors_name
>>>>> augroup END
>>>>>
>>>>> However, it doesn't work fine in split windows.
>>>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
>>>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
>>>>>
>>>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
>>>>>
>>>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
>>>>> Can anyone help me?
>>>>
>>>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
>>>
>>> Hi Ben,
>>>
>>> That's what I tried.
>>> But wherever I put it in above code it doesn't work.
>>> Where would you place this in above code?
>>>
>>
>> Around your autocommand:
>>
>> augroup filetype_colorscheme
>> au BufEnter *
>> \ if winnr('$') == 1
>> \ | if !exists('b:colors_name')
>> \ | if &ft == "vim"
>> \ | let b:colors_name = 'color_dark'
>> \ | else
>> \ | let b:colors_name = 'color_light'
>> \ | endif
>> \ | endif
>> \ | exe 'colorscheme' b:colors_name
>> \ | else
>> \ | colorscheme default
>> | | endif
>> augroup END
>>
>> or (maybe more readable)
>>
>> function SetColors()
>> if exists('b:colors_name')
>> exe 'colorscheme' b:colors_name
>> return
>> endif
>> if winnr('$') > 1
>> colorscheme default
>> elseif &ft == 'vim'
>> colorscheme color_dark
>> else
>> colorscheme color_light
>> endif
>> let b:colors_name = g:colors_name
>> endfunction
>> augroup filetype_colorscheme
>> au BufEnter * call SetColors()
>> augroup END
>>
>> This way, the autocommand will be defined unconditionally, but if it
>> finds that at BufEnter three are more than one window in the current tab
>> it will go back to the default scheme.
>>
>>
>> Best regards,
>> Tony.
>> --
>> Actor: So what do you do for a living?
>> Doris: I work for a company that makes deceptively shallow serving
>> dishes for Chinese restaurants.
>> -- Woody Allen, "Without Feathers"
>
> Thank you very much.
>
> Just one little thing..
>
> What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
> (when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
>
> Is it possible to do?
>
Well, it is possible, with a slight refinement to the above. You may
want to remember the Vim terminology:
- buffer: one file (or file-like data) in Vim memory, with the relevant
metadata. It may be displayed in zero or more windows.
- window: a viewport into a buffer. If several windows display the same
buffer, changes made in one are reflected in all others. Also, if
several windows display the same buffer, the displayed regions of that
buffer may or may not overlap.
- tab page: a set of one or more windows which are displayed at the same
time.
"another split buffer in a split window" has no meaning. Maybe you meant
"another window in the current tab"?
You can use variables with different scopes:
b:something local to a buffer
g:something global to all Vim
l:something local to a function
s:something local to a script
t:something local to a tab page
v:something predefined at compile-time
w:something local to a window
With no prefix it falls back to v: for compatibility for a few
predefined names, otherwise l: if inside a function, otherwise g:
See also the help for the following functions:
bufname()
bufnr()
bufwinnr()
tabpagebuflist()
tabpagenr()
tabpagewinnr()
winbufnr()
winnr()
See also |setting-tabline| for an example of how to use these functions
(albeit for a different purpose).
Best regards,
Tony.
--
Ten million Linux users can't be wrong!
--
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
> On Friday, April 27, 2012 8:29:03 PM UTC+2, Tony Mechelynck wrote:
>> On 27/04/12 18:34, rameo wrote:
>>> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
>>>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
>>>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
>>>>>
>>>>> augroup filetype_colorscheme
>>>>> au BufEnter *
>>>>> \ if !exists('b:colors_name')
>>>>> \ | if &ft == "vim"
>>>>> \ | let b:colors_name = 'color_dark'
>>>>> \ | else
>>>>> \ | let b:colors_name = 'color_light'
>>>>> \ | endif
>>>>> \ | endif
>>>>> \ | exe 'colorscheme' b:colors_name
>>>>> augroup END
>>>>>
>>>>> However, it doesn't work fine in split windows.
>>>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
>>>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
>>>>>
>>>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
>>>>>
>>>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
>>>>> Can anyone help me?
>>>>
>>>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
>>>
>>> Hi Ben,
>>>
>>> That's what I tried.
>>> But wherever I put it in above code it doesn't work.
>>> Where would you place this in above code?
>>>
>>
>> Around your autocommand:
>>
>> augroup filetype_colorscheme
>> au BufEnter *
>> \ if winnr('$') == 1
>> \ | if !exists('b:colors_name')
>> \ | if &ft == "vim"
>> \ | let b:colors_name = 'color_dark'
>> \ | else
>> \ | let b:colors_name = 'color_light'
>> \ | endif
>> \ | endif
>> \ | exe 'colorscheme' b:colors_name
>> \ | else
>> \ | colorscheme default
>> | | endif
>> augroup END
>>
>> or (maybe more readable)
>>
>> function SetColors()
>> if exists('b:colors_name')
>> exe 'colorscheme' b:colors_name
>> return
>> endif
>> if winnr('$') > 1
>> colorscheme default
>> elseif &ft == 'vim'
>> colorscheme color_dark
>> else
>> colorscheme color_light
>> endif
>> let b:colors_name = g:colors_name
>> endfunction
>> augroup filetype_colorscheme
>> au BufEnter * call SetColors()
>> augroup END
>>
>> This way, the autocommand will be defined unconditionally, but if it
>> finds that at BufEnter three are more than one window in the current tab
>> it will go back to the default scheme.
>>
>>
>> Best regards,
>> Tony.
>> --
>> Actor: So what do you do for a living?
>> Doris: I work for a company that makes deceptively shallow serving
>> dishes for Chinese restaurants.
>> -- Woody Allen, "Without Feathers"
>
> Thank you very much.
>
> Just one little thing..
>
> What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
> (when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
>
> Is it possible to do?
>
Well, it is possible, with a slight refinement to the above. You may
want to remember the Vim terminology:
- buffer: one file (or file-like data) in Vim memory, with the relevant
metadata. It may be displayed in zero or more windows.
- window: a viewport into a buffer. If several windows display the same
buffer, changes made in one are reflected in all others. Also, if
several windows display the same buffer, the displayed regions of that
buffer may or may not overlap.
- tab page: a set of one or more windows which are displayed at the same
time.
"another split buffer in a split window" has no meaning. Maybe you meant
"another window in the current tab"?
You can use variables with different scopes:
b:something local to a buffer
g:something global to all Vim
l:something local to a function
s:something local to a script
t:something local to a tab page
v:something predefined at compile-time
w:something local to a window
With no prefix it falls back to v: for compatibility for a few
predefined names, otherwise l: if inside a function, otherwise g:
See also the help for the following functions:
bufname()
bufnr()
bufwinnr()
tabpagebuflist()
tabpagenr()
tabpagewinnr()
winbufnr()
winnr()
See also |setting-tabline| for an example of how to use these functions
(albeit for a different purpose).
Best regards,
Tony.
--
Ten million Linux users can't be wrong!
--
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
Can Vim remember modes when switching between tabs?
I originally noticed this in MacVim, but turns out this happens in the
terminal as well. If you have two tabs open and enter the Insert mode
in one, then switch to the other tab (by clicking on it in GUI, for
example), the Insert mode is still active. This wreaks havoc when I'm
editing something and want to quickly switch to the other tab to
search/look up/etc, because the Normal mode keystrokes get inserted
into the buffer.
Any workarounds for this?
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
terminal as well. If you have two tabs open and enter the Insert mode
in one, then switch to the other tab (by clicking on it in GUI, for
example), the Insert mode is still active. This wreaks havoc when I'm
editing something and want to quickly switch to the other tab to
search/look up/etc, because the Normal mode keystrokes get inserted
into the buffer.
Any workarounds for this?
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Colorschemes and split window
On Friday, April 27, 2012 8:29:03 PM UTC+2, Tony Mechelynck wrote:
> On 27/04/12 18:34, rameo wrote:
> > On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
> >> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
> >>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
> >>>
> >>> augroup filetype_colorscheme
> >>> au BufEnter *
> >>> \ if !exists('b:colors_name')
> >>> \ | if &ft == "vim"
> >>> \ | let b:colors_name = 'color_dark'
> >>> \ | else
> >>> \ | let b:colors_name = 'color_light'
> >>> \ | endif
> >>> \ | endif
> >>> \ | exe 'colorscheme' b:colors_name
> >>> augroup END
> >>>
> >>> However, it doesn't work fine in split windows.
> >>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
> >>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
> >>>
> >>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
> >>>
> >>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
> >>> Can anyone help me?
> >>
> >> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
> >
> > Hi Ben,
> >
> > That's what I tried.
> > But wherever I put it in above code it doesn't work.
> > Where would you place this in above code?
> >
>
> Around your autocommand:
>
> augroup filetype_colorscheme
> au BufEnter *
> \ if winnr('$') == 1
> \ | if !exists('b:colors_name')
> \ | if &ft == "vim"
> \ | let b:colors_name = 'color_dark'
> \ | else
> \ | let b:colors_name = 'color_light'
> \ | endif
> \ | endif
> \ | exe 'colorscheme' b:colors_name
> \ | else
> \ | colorscheme default
> | | endif
> augroup END
>
> or (maybe more readable)
>
> function SetColors()
> if exists('b:colors_name')
> exe 'colorscheme' b:colors_name
> return
> endif
> if winnr('$') > 1
> colorscheme default
> elseif &ft == 'vim'
> colorscheme color_dark
> else
> colorscheme color_light
> endif
> let b:colors_name = g:colors_name
> endfunction
> augroup filetype_colorscheme
> au BufEnter * call SetColors()
> augroup END
>
> This way, the autocommand will be defined unconditionally, but if it
> finds that at BufEnter three are more than one window in the current tab
> it will go back to the default scheme.
>
>
> Best regards,
> Tony.
> --
> Actor: So what do you do for a living?
> Doris: I work for a company that makes deceptively shallow serving
> dishes for Chinese restaurants.
> -- Woody Allen, "Without Feathers"
Thank you very much.
Just one little thing..
What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
(when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
Is it possible to do?
--
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
> On 27/04/12 18:34, rameo wrote:
> > On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
> >> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
> >>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
> >>>
> >>> augroup filetype_colorscheme
> >>> au BufEnter *
> >>> \ if !exists('b:colors_name')
> >>> \ | if &ft == "vim"
> >>> \ | let b:colors_name = 'color_dark'
> >>> \ | else
> >>> \ | let b:colors_name = 'color_light'
> >>> \ | endif
> >>> \ | endif
> >>> \ | exe 'colorscheme' b:colors_name
> >>> augroup END
> >>>
> >>> However, it doesn't work fine in split windows.
> >>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
> >>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
> >>>
> >>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
> >>>
> >>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
> >>> Can anyone help me?
> >>
> >> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
> >
> > Hi Ben,
> >
> > That's what I tried.
> > But wherever I put it in above code it doesn't work.
> > Where would you place this in above code?
> >
>
> Around your autocommand:
>
> augroup filetype_colorscheme
> au BufEnter *
> \ if winnr('$') == 1
> \ | if !exists('b:colors_name')
> \ | if &ft == "vim"
> \ | let b:colors_name = 'color_dark'
> \ | else
> \ | let b:colors_name = 'color_light'
> \ | endif
> \ | endif
> \ | exe 'colorscheme' b:colors_name
> \ | else
> \ | colorscheme default
> | | endif
> augroup END
>
> or (maybe more readable)
>
> function SetColors()
> if exists('b:colors_name')
> exe 'colorscheme' b:colors_name
> return
> endif
> if winnr('$') > 1
> colorscheme default
> elseif &ft == 'vim'
> colorscheme color_dark
> else
> colorscheme color_light
> endif
> let b:colors_name = g:colors_name
> endfunction
> augroup filetype_colorscheme
> au BufEnter * call SetColors()
> augroup END
>
> This way, the autocommand will be defined unconditionally, but if it
> finds that at BufEnter three are more than one window in the current tab
> it will go back to the default scheme.
>
>
> Best regards,
> Tony.
> --
> Actor: So what do you do for a living?
> Doris: I work for a company that makes deceptively shallow serving
> dishes for Chinese restaurants.
> -- Woody Allen, "Without Feathers"
Thank you very much.
Just one little thing..
What I noted is that when I have a split window it gives the default colorscheme (that's ok) but I would like to have the possibility to change the colorscheme of all split buffers in a window with the :color "colorscheme" command (and if possible keep this colorscheme when I switch from one Tab to another and back to the split window or when I click in another split buffer in the split window.
(when I have multiple .vim files in the split window I prefer the dark colorscheme, when I have multiple .txt files in the split, I prefer the light colorscheme. That isn't possible now. When I use :color "colorscheme" and click in another split window all other split windows changes again to the default colorscheme)
Is it possible to do?
--
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
Re: gvim auto copy selected text to clipboard
The problem is solved !
In this thread you can take a patch from Christian Brabandt which make
possible behavior described in Subject and test case.
http://groups.google.com/group/vim_dev/browse_thread/thread/1b50de7f4163dbb5/b36e113b3abebad9?lnk=gst&q=vakulenko&pli=1
On Apr 24, 8:33 am, Chris Jones <cjns1...@gmail.com> wrote:
> On Mon, Apr 23, 2012 at 06:07:24PM EDT, Gary Johnson wrote:
> > On 2012-04-23, Chris Jones wrote:
>
> [..]
>
> > > From a more general perspective, the OP could use the 'autocutsel'
> > > program that keeps X11's clipboard & primary selection in sync'.
>
> > Inspired by this discussion, I decided to install autocutsel and see
> > how that works out.
>
> Did the same but haven't looked into setting it up. Provided the tool
> works as I think it does, namely that from the user's perspective it
> makes the X clipboard and the PRIMARY selection behave as one, the
> question is, do I really want that..? IOW, what are the implications?
>
> It looks as if all the OP wants is X11 to work like Microsoft Windows
> with just one single mechanism & clipboard..?
>
> I rather dread revisiting these issues and fiddling with my environment
> at this point.. I have about ten pages of notes on the subject that
> would likely need to be updated.. I think I'll wait till I upgrade to
> 7.3 so I'm able to see for myself whether the new clipboard=unnamedplus
> option makes any difference.
>
> X was designed by computer scientists.. maybe that's the problem.
>
> CJ
>
> --
> Hi! My name is bobby...
--
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
In this thread you can take a patch from Christian Brabandt which make
possible behavior described in Subject and test case.
http://groups.google.com/group/vim_dev/browse_thread/thread/1b50de7f4163dbb5/b36e113b3abebad9?lnk=gst&q=vakulenko&pli=1
On Apr 24, 8:33 am, Chris Jones <cjns1...@gmail.com> wrote:
> On Mon, Apr 23, 2012 at 06:07:24PM EDT, Gary Johnson wrote:
> > On 2012-04-23, Chris Jones wrote:
>
> [..]
>
> > > From a more general perspective, the OP could use the 'autocutsel'
> > > program that keeps X11's clipboard & primary selection in sync'.
>
> > Inspired by this discussion, I decided to install autocutsel and see
> > how that works out.
>
> Did the same but haven't looked into setting it up. Provided the tool
> works as I think it does, namely that from the user's perspective it
> makes the X clipboard and the PRIMARY selection behave as one, the
> question is, do I really want that..? IOW, what are the implications?
>
> It looks as if all the OP wants is X11 to work like Microsoft Windows
> with just one single mechanism & clipboard..?
>
> I rather dread revisiting these issues and fiddling with my environment
> at this point.. I have about ten pages of notes on the subject that
> would likely need to be updated.. I think I'll wait till I upgrade to
> 7.3 so I'm able to see for myself whether the new clipboard=unnamedplus
> option makes any difference.
>
> X was designed by computer scientists.. maybe that's the problem.
>
> CJ
>
> --
> Hi! My name is bobby...
--
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
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
On 2012-04-27, pixelterra wrote:
> Actually, I was wrong, this doesn't work. Sorry for the confusion.
> Any other options?
What do you mean, "this doesn't work"? If you mean you still want
to have the edited command on the command line and not executed when
you exit vim, I don't think bash lets you do that, but I've heard
zsh does.
I usually just exit with :wq or ZZ and let bash execute it.
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
> Actually, I was wrong, this doesn't work. Sorry for the confusion.
> Any other options?
What do you mean, "this doesn't work"? If you mean you still want
to have the edited command on the command line and not executed when
you exit vim, I don't think bash lets you do that, but I've heard
zsh does.
I usually just exit with :wq or ZZ and let bash execute it.
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
Re: Building Win 7 vim with support for 64 bit perl
Sergey Khorev wrote:
Dang if I didn't transpose those and download 5.14.2...
Is there a reason why it can't be made a bit more general?
I know on *nix, when you 'dlopen a lib, you can look at the version and
the calls available' and config yourself to the version you have loaded.
Is that not possible in windows? Sorta defeats the purpose of **dynamic**,
runtime linking -- if it is really "static", delayed linking...?
Any chance of getting it updated for Active state's current release rather than
one that will be obsolete in a few weeks (5.16 will be out and @ 2 releases
behind , 5.12 will be in line for retirement...)...
(Any chance of me getting it to build with Off-the-shelf, non-proprietary tools without it being a major project??)
Has anyone successfully built Vim for Windows 7 with support for 64 bit perl? �It would be nice if VIM were 64 bit, but 32 bit VIM is OK; �embedded perl must be 5.12 64 bit.32bit application cannot use 64bit dll. Here is x64 Vim built with ActivePerl 5.12.4.1205: http://dl.dropbox.com/u/27071670/gvim-7.3.480.x64.dynperl-5.12.4.1205.zip
Dang if I didn't transpose those and download 5.14.2...
Is there a reason why it can't be made a bit more general?
I know on *nix, when you 'dlopen a lib, you can look at the version and
the calls available' and config yourself to the version you have loaded.
Is that not possible in windows? Sorta defeats the purpose of **dynamic**,
runtime linking -- if it is really "static", delayed linking...?
Any chance of getting it updated for Active state's current release rather than
one that will be obsolete in a few weeks (5.16 will be out and @ 2 releases
behind , 5.12 will be in line for retirement...)...
(Any chance of me getting it to build with Off-the-shelf, non-proprietary tools without it being a major project??)
Re: Colorschemes and split window
Minor correction.
On 2012-04-27, Tony Mechelynck wrote:
> On 27/04/12 18:34, rameo wrote:
> >Where would you place this in above code?
> >
>
> Around your autocommand:
>
> augroup filetype_colorscheme
> au BufEnter *
> \ if winnr('$') == 1
> \ | if !exists('b:colors_name')
> \ | if &ft == "vim"
> \ | let b:colors_name = 'color_dark'
> \ | else
> \ | let b:colors_name = 'color_light'
> \ | endif
> \ | endif
> \ | exe 'colorscheme' b:colors_name
> \ | else
> \ | colorscheme default
> | | endif
^
\
> augroup END
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
On 2012-04-27, Tony Mechelynck wrote:
> On 27/04/12 18:34, rameo wrote:
> >Where would you place this in above code?
> >
>
> Around your autocommand:
>
> augroup filetype_colorscheme
> au BufEnter *
> \ if winnr('$') == 1
> \ | if !exists('b:colors_name')
> \ | if &ft == "vim"
> \ | let b:colors_name = 'color_dark'
> \ | else
> \ | let b:colors_name = 'color_light'
> \ | endif
> \ | endif
> \ | exe 'colorscheme' b:colors_name
> \ | else
> \ | colorscheme default
> | | endif
^
\
> augroup END
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
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
Actually, I was wrong, this doesn't work. Sorry for the confusion. Any other options?
--
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 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
Re: [PS] how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
Sorry...I didn't see the entire subject line on my screen and
assumed you were talking about Vim. The bash vi mode ("set -o
vi") is a separate beast.
> But after I edit the command in vim, how do I get that command
> back to the command line? Or do I have to copy / paste
> manually?
Quitting vim will automatically execute the command as Taylor
mentions, which also puts it in your command history. You may
want to try using something like
bash$ fc -3
to edit the command you issued 3 back (or just "fc" to edit the
most recently issued command). Reading up on the "history"
command and bash's "event designators" may also provide you other
options. In emacs mode, using control+P will scroll back through
the history. In vi mode, hitting <esc> and then using k/j will
scroll around in the history, or you can use "/" and "?" to search.
-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
assumed you were talking about Vim. The bash vi mode ("set -o
vi") is a separate beast.
> But after I edit the command in vim, how do I get that command
> back to the command line? Or do I have to copy / paste
> manually?
Quitting vim will automatically execute the command as Taylor
mentions, which also puts it in your command history. You may
want to try using something like
bash$ fc -3
to edit the command you issued 3 back (or just "fc" to edit the
most recently issued command). Reading up on the "history"
command and bash's "event designators" may also provide you other
options. In emacs mode, using control+P will scroll back through
the history. In vi mode, hitting <esc> and then using k/j will
scroll around in the history, or you can use "/" and "?" to search.
-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
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
pixelterra, Fri 2012-04-27 @ 11:52:29-0700:
> :x did the trick. What exactly is that command?
:help :x
*:x* *:xit*
:[range]x[it][!] [++opt] [file]
Like ":wq", but write only when changes have been
made.
When 'hidden' is set and there are more windows, the
current buffer becomes hidden, after writing the file.
> :x did the trick. What exactly is that command?
:help :x
*:x* *:xit*
:[range]x[it][!] [++opt] [file]
Like ":wq", but write only when changes have been
made.
When 'hidden' is set and there are more windows, the
current buffer becomes hidden, after writing the file.
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
:x did the trick. What exactly is that command?
--
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 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
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
On Friday, April 27, 2012 2:48:06 PM UTC-4, Tim Chase wrote:
> On 04/27/12 13:35, pixelterra wrote:
> > "Suppose you typed a longer command and you noticed that you
> > had made several mistakes, and wanted to do the correction in
> > the vi editor itself. You can type 'v' to edit the command in
> > the editor and not on the command line!"
>
> Are you sure you mean typing "v" to edit the command? Usually it
> defaults to control+F on the command-line (assuming you haven't
> changed the value for 'cedit', something I don't recommend
> doing). This opens the command-line window. It should keep
> 'history' entries around (defaulting to 20)
>
> :help cmdwin
> :help 'history'
> :help 'cedit'
>
> If you want to get to this window again, you can either press the
> colon followed by control+F. Alternatively, you can use
>
> q:
>
> to open the window. Similar editing can be done on search
> history with "q/" or pressing control+F in a "/" or "?" search
> you've already started.
>
> To navigate, you can scroll back using normal Vi navigation
> (searching, h/j/k/l, etc)
>
> > But after I edit the command in vim, how do I get that command
> > back to the command line? Or do I have to copy / paste
> > manually?
>
> You can recall previous commands using control+P (and control+N)
> or <up>/<down>, as well as using Vim navigation in the
> command-line window as mentioned above.
>
> -tim
On Friday, April 27, 2012 2:48:06 PM UTC-4, Tim Chase wrote:
> On 04/27/12 13:35, pixelterra wrote:
> > "Suppose you typed a longer command and you noticed that you
> > had made several mistakes, and wanted to do the correction in
> > the vi editor itself. You can type 'v' to edit the command in
> > the editor and not on the command line!"
>
> Are you sure you mean typing "v" to edit the command? Usually it
> defaults to control+F on the command-line (assuming you haven't
> changed the value for 'cedit', something I don't recommend
> doing). This opens the command-line window. It should keep
> 'history' entries around (defaulting to 20)
>
> :help cmdwin
> :help 'history'
> :help 'cedit'
>
> If you want to get to this window again, you can either press the
> colon followed by control+F. Alternatively, you can use
>
> q:
>
> to open the window. Similar editing can be done on search
> history with "q/" or pressing control+F in a "/" or "?" search
> you've already started.
>
> To navigate, you can scroll back using normal Vi navigation
> (searching, h/j/k/l, etc)
>
> > But after I edit the command in vim, how do I get that command
> > back to the command line? Or do I have to copy / paste
> > manually?
>
> You can recall previous commands using control+P (and control+N)
> or <up>/<down>, as well as using Vim navigation in the
> command-line window as mentioned above.
>
> -tim
Tim, I mean I'm on the linux command line in set -o vi mode.
You can do basic editing there, but anything more complex you can type 'v' and it will open the current command line text in $EDITOR. I'm wondering how to send the edited command back to the LINUX command line (not inside of vim)
--
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
> On 04/27/12 13:35, pixelterra wrote:
> > "Suppose you typed a longer command and you noticed that you
> > had made several mistakes, and wanted to do the correction in
> > the vi editor itself. You can type 'v' to edit the command in
> > the editor and not on the command line!"
>
> Are you sure you mean typing "v" to edit the command? Usually it
> defaults to control+F on the command-line (assuming you haven't
> changed the value for 'cedit', something I don't recommend
> doing). This opens the command-line window. It should keep
> 'history' entries around (defaulting to 20)
>
> :help cmdwin
> :help 'history'
> :help 'cedit'
>
> If you want to get to this window again, you can either press the
> colon followed by control+F. Alternatively, you can use
>
> q:
>
> to open the window. Similar editing can be done on search
> history with "q/" or pressing control+F in a "/" or "?" search
> you've already started.
>
> To navigate, you can scroll back using normal Vi navigation
> (searching, h/j/k/l, etc)
>
> > But after I edit the command in vim, how do I get that command
> > back to the command line? Or do I have to copy / paste
> > manually?
>
> You can recall previous commands using control+P (and control+N)
> or <up>/<down>, as well as using Vim navigation in the
> command-line window as mentioned above.
>
> -tim
On Friday, April 27, 2012 2:48:06 PM UTC-4, Tim Chase wrote:
> On 04/27/12 13:35, pixelterra wrote:
> > "Suppose you typed a longer command and you noticed that you
> > had made several mistakes, and wanted to do the correction in
> > the vi editor itself. You can type 'v' to edit the command in
> > the editor and not on the command line!"
>
> Are you sure you mean typing "v" to edit the command? Usually it
> defaults to control+F on the command-line (assuming you haven't
> changed the value for 'cedit', something I don't recommend
> doing). This opens the command-line window. It should keep
> 'history' entries around (defaulting to 20)
>
> :help cmdwin
> :help 'history'
> :help 'cedit'
>
> If you want to get to this window again, you can either press the
> colon followed by control+F. Alternatively, you can use
>
> q:
>
> to open the window. Similar editing can be done on search
> history with "q/" or pressing control+F in a "/" or "?" search
> you've already started.
>
> To navigate, you can scroll back using normal Vi navigation
> (searching, h/j/k/l, etc)
>
> > But after I edit the command in vim, how do I get that command
> > back to the command line? Or do I have to copy / paste
> > manually?
>
> You can recall previous commands using control+P (and control+N)
> or <up>/<down>, as well as using Vim navigation in the
> command-line window as mentioned above.
>
> -tim
Tim, I mean I'm on the linux command line in set -o vi mode.
You can do basic editing there, but anything more complex you can type 'v' and it will open the current command line text in $EDITOR. I'm wondering how to send the edited command back to the LINUX command line (not inside of vim)
--
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
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
On 04/27/12 13:35, pixelterra wrote:
> "Suppose you typed a longer command and you noticed that you
> had made several mistakes, and wanted to do the correction in
> the vi editor itself. You can type 'v' to edit the command in
> the editor and not on the command line!"
Are you sure you mean typing "v" to edit the command? Usually it
defaults to control+F on the command-line (assuming you haven't
changed the value for 'cedit', something I don't recommend
doing). This opens the command-line window. It should keep
'history' entries around (defaulting to 20)
:help cmdwin
:help 'history'
:help 'cedit'
If you want to get to this window again, you can either press the
colon followed by control+F. Alternatively, you can use
q:
to open the window. Similar editing can be done on search
history with "q/" or pressing control+F in a "/" or "?" search
you've already started.
To navigate, you can scroll back using normal Vi navigation
(searching, h/j/k/l, etc)
> But after I edit the command in vim, how do I get that command
> back to the command line? Or do I have to copy / paste
> manually?
You can recall previous commands using control+P (and control+N)
or <up>/<down>, as well as using Vim navigation in the
command-line window as mentioned above.
-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
> "Suppose you typed a longer command and you noticed that you
> had made several mistakes, and wanted to do the correction in
> the vi editor itself. You can type 'v' to edit the command in
> the editor and not on the command line!"
Are you sure you mean typing "v" to edit the command? Usually it
defaults to control+F on the command-line (assuming you haven't
changed the value for 'cedit', something I don't recommend
doing). This opens the command-line window. It should keep
'history' entries around (defaulting to 20)
:help cmdwin
:help 'history'
:help 'cedit'
If you want to get to this window again, you can either press the
colon followed by control+F. Alternatively, you can use
q:
to open the window. Similar editing can be done on search
history with "q/" or pressing control+F in a "/" or "?" search
you've already started.
To navigate, you can scroll back using normal Vi navigation
(searching, h/j/k/l, etc)
> But after I edit the command in vim, how do I get that command
> back to the command line? Or do I have to copy / paste
> manually?
You can recall previous commands using control+P (and control+N)
or <up>/<down>, as well as using Vim navigation in the
command-line window as mentioned above.
-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
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
On 27/04/12 20:35, pixelterra wrote:
> I recently found this out:
>
> "Suppose you typed a longer command and you noticed that you had made several mistakes, and wanted to do the correction in the vi editor itself. You can type 'v' to edit the command in the editor and not on the command line!"
>
> But after I edit the command in vim, how do I get that command back to the command line? Or do I have to copy / paste manually?
>
What happens if you leave Insert mode (e.g. by <Esc>) then type :x
(followed by <Enter>) in your Vim editor?
Best regards,
Tony.
--
Pittsburgh Driver's Test
(7) The car directly in front of you has a flashing right tail light
but a steady left tail light. This means
(a) one of the tail lights is broken; you should blow your horn
to call the problem to the driver's attention.
(b) the driver is signaling a right turn.
(c) the driver is signaling a left turn.
(d) the driver is from out of town.
The correct answer is (d). Tail lights are used in some foreign
countries to signal turns.
--
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
> I recently found this out:
>
> "Suppose you typed a longer command and you noticed that you had made several mistakes, and wanted to do the correction in the vi editor itself. You can type 'v' to edit the command in the editor and not on the command line!"
>
> But after I edit the command in vim, how do I get that command back to the command line? Or do I have to copy / paste manually?
>
What happens if you leave Insert mode (e.g. by <Esc>) then type :x
(followed by <Enter>) in your Vim editor?
Best regards,
Tony.
--
Pittsburgh Driver's Test
(7) The car directly in front of you has a flashing right tail light
but a steady left tail light. This means
(a) one of the tail lights is broken; you should blow your horn
to call the problem to the driver's attention.
(b) the driver is signaling a right turn.
(c) the driver is signaling a left turn.
(d) the driver is from out of town.
The correct answer is (d). Tail lights are used in some foreign
countries to signal turns.
--
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
Re: how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
pixelterra, Fri 2012-04-27 @ 11:35:39-0700:
> But after I edit the command in vim, how do I get that command back to
> the command line? Or do I have to copy / paste manually?
When you save the buffer and quit the editor, the shell then executes
the contents of the saved buffer. So it happens automatically.
> But after I edit the command in vim, how do I get that command back to
> the command line? Or do I have to copy / paste manually?
When you save the buffer and quit the editor, the shell then executes
the contents of the saved buffer. So it happens automatically.
how to send command back to the command line after typing 'v' from linux command line in set -o vi mode?
I recently found this out:
"Suppose you typed a longer command and you noticed that you had made several mistakes, and wanted to do the correction in the vi editor itself. You can type 'v' to edit the command in the editor and not on the command line!"
But after I edit the command in vim, how do I get that command back to the command line? Or do I have to copy / paste manually?
--
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
"Suppose you typed a longer command and you noticed that you had made several mistakes, and wanted to do the correction in the vi editor itself. You can type 'v' to edit the command in the editor and not on the command line!"
But after I edit the command in vim, how do I get that command back to the command line? Or do I have to copy / paste manually?
--
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
Re: Colorschemes and split window
On 27/04/12 18:34, rameo wrote:
> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
>>>
>>> augroup filetype_colorscheme
>>> au BufEnter *
>>> \ if !exists('b:colors_name')
>>> \ | if &ft == "vim"
>>> \ | let b:colors_name = 'color_dark'
>>> \ | else
>>> \ | let b:colors_name = 'color_light'
>>> \ | endif
>>> \ | endif
>>> \ | exe 'colorscheme' b:colors_name
>>> augroup END
>>>
>>> However, it doesn't work fine in split windows.
>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
>>>
>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
>>>
>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
>>> Can anyone help me?
>>
>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
>
> Hi Ben,
>
> That's what I tried.
> But wherever I put it in above code it doesn't work.
> Where would you place this in above code?
>
Around your autocommand:
augroup filetype_colorscheme
au BufEnter *
\ if winnr('$') == 1
\ | if !exists('b:colors_name')
\ | if &ft == "vim"
\ | let b:colors_name = 'color_dark'
\ | else
\ | let b:colors_name = 'color_light'
\ | endif
\ | endif
\ | exe 'colorscheme' b:colors_name
\ | else
\ | colorscheme default
| | endif
augroup END
or (maybe more readable)
function SetColors()
if exists('b:colors_name')
exe 'colorscheme' b:colors_name
return
endif
if winnr('$') > 1
colorscheme default
elseif &ft == 'vim'
colorscheme color_dark
else
colorscheme color_light
endif
let b:colors_name = g:colors_name
endfunction
augroup filetype_colorscheme
au BufEnter * call SetColors()
augroup END
This way, the autocommand will be defined unconditionally, but if it
finds that at BufEnter three are more than one window in the current tab
it will go back to the default scheme.
Best regards,
Tony.
--
Actor: So what do you do for a living?
Doris: I work for a company that makes deceptively shallow serving
dishes for Chinese restaurants.
-- Woody Allen, "Without Feathers"
--
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
> On Friday, April 27, 2012 6:18:29 PM UTC+2, Ben Fritz wrote:
>> On Friday, April 27, 2012 10:56:55 AM UTC-5, rameo wrote:
>>> I use this code in my .vimrc to use my dark colorscheme when I open a .vim page and my light colorscheme when I open whatever other page:
>>>
>>> augroup filetype_colorscheme
>>> au BufEnter *
>>> \ if !exists('b:colors_name')
>>> \ | if &ft == "vim"
>>> \ | let b:colors_name = 'color_dark'
>>> \ | else
>>> \ | let b:colors_name = 'color_light'
>>> \ | endif
>>> \ | endif
>>> \ | exe 'colorscheme' b:colors_name
>>> augroup END
>>>
>>> However, it doesn't work fine in split windows.
>>> When I click on a .vim file in the split window all not .vim files changes to the dark colorscheme as well.
>>> I would like to keep them their own colorscheme; a .vim page always the dark colorscheme and whatever other file always the light colorscheme.
>>>
>>> I've learned that colorschemes will always affect the entire vim instance and that it is not possible to have a different color scheme per split window.
>>>
>>> In that point I would like to disable above code for split windows in order to give all split windows the default colorscheme (which I can change afterwards using :color "colorscheme") but don't know how to realize this. Whatever I tried didn't do what I want it to do.
>>> Can anyone help me?
>>
>> You can check the number of windows with winnr('$'). If > 1, you have multiple split windows.
>
> Hi Ben,
>
> That's what I tried.
> But wherever I put it in above code it doesn't work.
> Where would you place this in above code?
>
Around your autocommand:
augroup filetype_colorscheme
au BufEnter *
\ if winnr('$') == 1
\ | if !exists('b:colors_name')
\ | if &ft == "vim"
\ | let b:colors_name = 'color_dark'
\ | else
\ | let b:colors_name = 'color_light'
\ | endif
\ | endif
\ | exe 'colorscheme' b:colors_name
\ | else
\ | colorscheme default
| | endif
augroup END
or (maybe more readable)
function SetColors()
if exists('b:colors_name')
exe 'colorscheme' b:colors_name
return
endif
if winnr('$') > 1
colorscheme default
elseif &ft == 'vim'
colorscheme color_dark
else
colorscheme color_light
endif
let b:colors_name = g:colors_name
endfunction
augroup filetype_colorscheme
au BufEnter * call SetColors()
augroup END
This way, the autocommand will be defined unconditionally, but if it
finds that at BufEnter three are more than one window in the current tab
it will go back to the default scheme.
Best regards,
Tony.
--
Actor: So what do you do for a living?
Doris: I work for a company that makes deceptively shallow serving
dishes for Chinese restaurants.
-- Woody Allen, "Without Feathers"
--
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
Re: Plugin manager with dependencies and selective bundle load
Marc Weber wrote:
> Excerpts from Pablo Giménez's message of Thu Apr 26 20:00:23 +0200 2012:
>
>> I dont know exactly how it works but this is what it is doing ans is great.
>> AFAIK in vam you have to activate the plugins manually using
>> ActivateAddons, then the plugin rather than being waiting to be called it
>> is loaded.
>>
> There is a 'func not defined' hook which can be used. Maybe that is
> used.
> You're right, VAM does not support such yet.
> Feel free to use VAM to :InstallAddons only and use tplugin for
> activating them.
>
> My understanding of pludins is:
>
> plugin/*.vim: everything the user can customize (settings, interface,
> mappings, commansds)
>
plugin/*.vim holds scripts that will be loaded. Customization is a
totally different issue, and is often done by setting variables in .vimrc.
> autoload/*: everything else
>
autoload/*.vim holds scripts that will be loaded on demand; ie. when a
mapping or command in a plugin/something.vim script attempts to call a
function of the form
something#AFunction(), then autoload/something.vim will be loaded and
then the function call performed. This process does require that the
plugins be written/changed to accomodate this style.
That's why I wrote AsNeeded -- it introduces a new folder (AsNeeded/, of
course), wherein scripts reside that are not particularly written for
the autoload method. It makes a pass through scripts in that directory
and builds a single file, ANcmds.vim, that contain just enough to
support commands, sourcing the AsNeeded/function.vim scripts on demand.
It doesn't support building maps that way, though. There's a command
":AN somefile.vim" that will source an AsNeeded script, too.
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
> Excerpts from Pablo Giménez's message of Thu Apr 26 20:00:23 +0200 2012:
>
>> I dont know exactly how it works but this is what it is doing ans is great.
>> AFAIK in vam you have to activate the plugins manually using
>> ActivateAddons, then the plugin rather than being waiting to be called it
>> is loaded.
>>
> There is a 'func not defined' hook which can be used. Maybe that is
> used.
> You're right, VAM does not support such yet.
> Feel free to use VAM to :InstallAddons only and use tplugin for
> activating them.
>
> My understanding of pludins is:
>
> plugin/*.vim: everything the user can customize (settings, interface,
> mappings, commansds)
>
plugin/*.vim holds scripts that will be loaded. Customization is a
totally different issue, and is often done by setting variables in .vimrc.
> autoload/*: everything else
>
autoload/*.vim holds scripts that will be loaded on demand; ie. when a
mapping or command in a plugin/something.vim script attempts to call a
function of the form
something#AFunction(), then autoload/something.vim will be loaded and
then the function call performed. This process does require that the
plugins be written/changed to accomodate this style.
That's why I wrote AsNeeded -- it introduces a new folder (AsNeeded/, of
course), wherein scripts reside that are not particularly written for
the autoload method. It makes a pass through scripts in that directory
and builds a single file, ANcmds.vim, that contain just enough to
support commands, sourcing the AsNeeded/function.vim scripts on demand.
It doesn't support building maps that way, though. There's a command
":AN somefile.vim" that will source an AsNeeded script, too.
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
Re: map Ctrl with special characters
On 27/04/12 17:45, rameo wrote:
> I still have problems mapping keys.
>
> On my keyboard I have these keys I want to map:
> <C-ò>
> <C-à>
> <C-è>
> <C-ù>
> <C-ì>
>
> Tony once told in a message these info:
> ò = (0xF2, o-grave) and <M-r> (Alt+0x72, Alt-r)
> à = (0xE0, a-grave) and <M-`> (Alt+0x60, Alt-backtick)
> è = (0xE8, e-grave) and <M-h> (Alt+0x68, Alt-h)
> ù = (0xF9, u-grave) and <M-y> (Alt+0x79, Alt-y)
> ì = (0xEC, i-grave) and <M-l> (Alt+0x6C, Alt-l)
>
> But how to combine these letters to the Ctrl key?
>
I'm not sure you can.
Try hitting Ctrl-K in Insert mode, followed by the desired key
combination, and see if anything appears. If yes, it is the <> form of
whatever Vim sees.
Or try hitting Ctrl-V in Insert mode followed by the key combination.
Vim will tell you what (if anything) it gets from the keyboard. For
instance if you hit Ctrl-V Ctrl-è and Vim inserts è it means that it
can't tell the difference between è and Ctrl-è. If you hit Ctrl-V Ctrl-à
and Vim doesn't insert anything (and, if 'showcmd' is on, you see that
^V doesn't disappear near the bottom right corner of the Vim screen),
then Vim hasn't got anything from the keyboard interface for your Ctrl-à
combo.
Best regards,
Tony.
--
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.
--
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
> I still have problems mapping keys.
>
> On my keyboard I have these keys I want to map:
> <C-ò>
> <C-à>
> <C-è>
> <C-ù>
> <C-ì>
>
> Tony once told in a message these info:
> ò = (0xF2, o-grave) and <M-r> (Alt+0x72, Alt-r)
> à = (0xE0, a-grave) and <M-`> (Alt+0x60, Alt-backtick)
> è = (0xE8, e-grave) and <M-h> (Alt+0x68, Alt-h)
> ù = (0xF9, u-grave) and <M-y> (Alt+0x79, Alt-y)
> ì = (0xEC, i-grave) and <M-l> (Alt+0x6C, Alt-l)
>
> But how to combine these letters to the Ctrl key?
>
I'm not sure you can.
Try hitting Ctrl-K in Insert mode, followed by the desired key
combination, and see if anything appears. If yes, it is the <> form of
whatever Vim sees.
Or try hitting Ctrl-V in Insert mode followed by the key combination.
Vim will tell you what (if anything) it gets from the keyboard. For
instance if you hit Ctrl-V Ctrl-è and Vim inserts è it means that it
can't tell the difference between è and Ctrl-è. If you hit Ctrl-V Ctrl-à
and Vim doesn't insert anything (and, if 'showcmd' is on, you see that
^V doesn't disappear near the bottom right corner of the Vim screen),
then Vim hasn't got anything from the keyboard interface for your Ctrl-à
combo.
Best regards,
Tony.
--
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.
--
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
Re: Plugin manager with dependencies and selective bundle load
2012/4/27 Marc Weber <marco-oweber@gmx.de>
Excerpts from Pablo Giménez's message of Thu Apr 26 20:00:23 +0200 2012:
> I dont know exactly how it works but this is what it is doing ans is great.There is a 'func not defined' hook which can be used. Maybe that is
> AFAIK in vam you have to activate the plugins manually using
> ActivateAddons, then the plugin rather than being waiting to be called it
> is loaded.
used.
You're right, VAM does not support such yet.
Feel free to use VAM to :InstallAddons only and use tplugin for
activating them.
Yep I think I am going to try this route .
My understanding of pludins is:
plugin/*.vim: everything the user can customize (settings, interface,
mappings, commansds)
autoload/*: everything else
This is also what I think about how to develop plugins, problem arise if you want to override all the public interface, like commands or keymaps for your own ones and mainly use what is uner autoload.
VAM has an experimental function to "merge" all plugin/* files so that
only one file is sources - but this still assumes that plugins only put
minimal configuration into the plugin files - and the if .. finish line
may be causing trouble easily and such.
Due to commands I personally assume that plugin files should always be
read - you're right, you can replace commansds/ mappings by "fake"
implementations activating a plugin first.
Before you make me spend time on such do profiling and tell me what's
causing most trouble to you.
You're welcome. Its easy to miss a detail if there is so much new stuff.
> Yep sorry my bad I got this working.
plugin2 depending on plugin1 and auto activation:
Retry again. This would be a serious bug.
Auto activation, Ill look into the dos for this, I dont know about the autoactivation feature.
If can't make it work I can invite you to a SSH session so that you can
proof me that its behaving wrong easily.
Marc Weber
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
--
Un saludo
Best Regards
Pablo Giménez
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
Re: gtk-config not even tried
On 27/04/12 17:03, Arno Valentin wrote:
> I have two HP-UX machines say A and B with HP-UX 11.11 and 11.31
> respectively. I'have compiled gvim 7.3 from source an B, and gvim 7.0
> on A, both with same options for configure..
>
> On A, gvim uses "version with GTK GUI", Compilation with gcc (...) -
> DFEAT_GUI_GTK and all works fine.
>
> On B, gvim looks different and uses "version with X11-Motif GUI",
> compilation with -DFEAT_GUI_MOTIF.
>
> Here ssh -X does not copy paste on selection:
>
> - copy/paste via select works on a GVim window on A, but not on B.
> - When I select some text in the GVim window, I can paste it via
> right-click within that window, but I cannot paste it into another
> window in X. When I select something on another X-Window, I can paste
> it within X but when I paste into the GVim window, it pastes the last
> thing selected in the GVim window, not the last thing selected an X.
>
> This problem is described elsewhere and the solution was to build gvim
> using gtk2.
>
> The Problem is: I cannot rebuild gvim with gtk. Although I have
> installed GTK+ on the machine via HP depot (GTK 2.6) and using gtk+ is
> called default in the Makefile configure ends up with compiler option
> "gcc (...) -DFEAT_GUI_MOTIF".
>
> to be more specific:
> configure gives:
>
> checking --enable-gui argument... yes/auto - automatic GUI support
> checking whether or not to look for GTK+ 2... yes
>
> but doesn't search for gtk Libraries. It only looks for Motif:
>
> checking for location of Motif GUI libs... /usr/lib/Motif1.1
>
> It doesn't tell me that it is missing anything I can provide!
> In the directory "auto" the file configure.log shows no failure in
> searching for GTk, it just doesnt look for!
>
> configure:7577: result: yes/auto - automatic GUI support
> configure:7609: checking whether or not to look for GTK+ 2
> configure:7618: result: yes
> configure:7627: checking whether or not to look for GNOME
> configure:7636: result: no
> configure:7644: checking whether or not to look for Motif
> configure:7653: result: yes
> configure:7661: checking whether or not to look for Athena
> configure:7670: result: yes
> configure:7678: checking whether or not to look for neXtaw
> configure:7687: result: yes
> configure:7695: checking whether or not to look for Carbon
> configure:7704: result: yes
> configure:7752: checking --disable-gtktest argument
> configure:7762: result: gtk test enabled
> configure:7772: checking for pkg-config
> configure:7803: result: no
> configure:8035: checking for location of Motif GUI includes
> configure:8047: result: in default path
> configure:8062: checking --with-motif-lib argument
> configure:8076: result: no
> configure:8081: checking for location of Motif GUI libs
> configure:8099: result: /usr/lib/Motif1.1
> configure:8202: checking for XShapeQueryExtension in -lXext
>
>
> And make starts with OPTION Motif:
>
> avalenti@ncc1n:/usr/local/src/vim/vim73/src >make | tee make-
> minimal.results
> mkdir objects
> CC="gcc -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/local/
> include " srcdir=. sh ./osdef.sh
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/local/
> include -g -O2 -D_FORTIFY_SOURCE=1 -o objects/buffer.o buffer.c
> (...)
>
> If I force usings gtk with
>
> configure --enable-gui=gtk2
>
> make ends up with no error but gvim says:
>
> "E25: GUI cannot be used: Not enabled at compile time"
>
> In another thread here in vim_use I saw configure mention using gtk-
> config.
> I don't get any message from configure, that it tries or searches for
> gtk-config.
>
> It's in my search-path, but it is not used by gvim build procedure.
>
> avalenti@ncc1n:/opt/gtk2.6/lib >type gtk-config
> gtk-config is /usr/local/bin/gtk-config
>
> How can I force gvim to compile using gtk2?
>
>
>
The first thing is to check your configure listing for possible missing
software packages. Maybe gtk2-devel (or gtk2-dev or similar depending on
distribution), but there might be others. In all cases you need
*development* packages for every single bit of software that will be
compiled into your application.
If the stdout/stderr log from configure doesn't give you enough clues,
check src/auto/config.log which is more detailed (but also contains more
information which you *won't* need).
If you find possible missing packages and install them, run "make
reconfig" to reconfigure and recompile.
See also:
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
Best regards,
Tony.
--
DINGO: And after the spanking ... the oral sex.
GALAHAD: Oh, dear! Well, I...
GIRLS: The oral sex ... The oral sex.
GALAHAD: Well, I suppose I could stay a BIT longer.
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
--
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
> I have two HP-UX machines say A and B with HP-UX 11.11 and 11.31
> respectively. I'have compiled gvim 7.3 from source an B, and gvim 7.0
> on A, both with same options for configure..
>
> On A, gvim uses "version with GTK GUI", Compilation with gcc (...) -
> DFEAT_GUI_GTK and all works fine.
>
> On B, gvim looks different and uses "version with X11-Motif GUI",
> compilation with -DFEAT_GUI_MOTIF.
>
> Here ssh -X does not copy paste on selection:
>
> - copy/paste via select works on a GVim window on A, but not on B.
> - When I select some text in the GVim window, I can paste it via
> right-click within that window, but I cannot paste it into another
> window in X. When I select something on another X-Window, I can paste
> it within X but when I paste into the GVim window, it pastes the last
> thing selected in the GVim window, not the last thing selected an X.
>
> This problem is described elsewhere and the solution was to build gvim
> using gtk2.
>
> The Problem is: I cannot rebuild gvim with gtk. Although I have
> installed GTK+ on the machine via HP depot (GTK 2.6) and using gtk+ is
> called default in the Makefile configure ends up with compiler option
> "gcc (...) -DFEAT_GUI_MOTIF".
>
> to be more specific:
> configure gives:
>
> checking --enable-gui argument... yes/auto - automatic GUI support
> checking whether or not to look for GTK+ 2... yes
>
> but doesn't search for gtk Libraries. It only looks for Motif:
>
> checking for location of Motif GUI libs... /usr/lib/Motif1.1
>
> It doesn't tell me that it is missing anything I can provide!
> In the directory "auto" the file configure.log shows no failure in
> searching for GTk, it just doesnt look for!
>
> configure:7577: result: yes/auto - automatic GUI support
> configure:7609: checking whether or not to look for GTK+ 2
> configure:7618: result: yes
> configure:7627: checking whether or not to look for GNOME
> configure:7636: result: no
> configure:7644: checking whether or not to look for Motif
> configure:7653: result: yes
> configure:7661: checking whether or not to look for Athena
> configure:7670: result: yes
> configure:7678: checking whether or not to look for neXtaw
> configure:7687: result: yes
> configure:7695: checking whether or not to look for Carbon
> configure:7704: result: yes
> configure:7752: checking --disable-gtktest argument
> configure:7762: result: gtk test enabled
> configure:7772: checking for pkg-config
> configure:7803: result: no
> configure:8035: checking for location of Motif GUI includes
> configure:8047: result: in default path
> configure:8062: checking --with-motif-lib argument
> configure:8076: result: no
> configure:8081: checking for location of Motif GUI libs
> configure:8099: result: /usr/lib/Motif1.1
> configure:8202: checking for XShapeQueryExtension in -lXext
>
>
> And make starts with OPTION Motif:
>
> avalenti@ncc1n:/usr/local/src/vim/vim73/src >make | tee make-
> minimal.results
> mkdir objects
> CC="gcc -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/local/
> include " srcdir=. sh ./osdef.sh
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -I/usr/local/
> include -g -O2 -D_FORTIFY_SOURCE=1 -o objects/buffer.o buffer.c
> (...)
>
> If I force usings gtk with
>
> configure --enable-gui=gtk2
>
> make ends up with no error but gvim says:
>
> "E25: GUI cannot be used: Not enabled at compile time"
>
> In another thread here in vim_use I saw configure mention using gtk-
> config.
> I don't get any message from configure, that it tries or searches for
> gtk-config.
>
> It's in my search-path, but it is not used by gvim build procedure.
>
> avalenti@ncc1n:/opt/gtk2.6/lib >type gtk-config
> gtk-config is /usr/local/bin/gtk-config
>
> How can I force gvim to compile using gtk2?
>
>
>
The first thing is to check your configure listing for possible missing
software packages. Maybe gtk2-devel (or gtk2-dev or similar depending on
distribution), but there might be others. In all cases you need
*development* packages for every single bit of software that will be
compiled into your application.
If the stdout/stderr log from configure doesn't give you enough clues,
check src/auto/config.log which is more detailed (but also contains more
information which you *won't* need).
If you find possible missing packages and install them, run "make
reconfig" to reconfigure and recompile.
See also:
http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
Best regards,
Tony.
--
DINGO: And after the spanking ... the oral sex.
GALAHAD: Oh, dear! Well, I...
GIRLS: The oral sex ... The oral sex.
GALAHAD: Well, I suppose I could stay a BIT longer.
"Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
--
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
Re: Plugin manager with dependencies and selective bundle load
2012/4/27 lith <minilith@gmail.com>
Hi,
I'm not sure what you mean by "not loading plugins". Since version 0.14, you can define "shallow" root directories. Plugins in such a directory can be loaded by means of the :TPlugin command but shouldn't be automatically loaded if you call one if its commands or functions etc.
> I love how fast vim loads using tplugin and how it changes the runtime path on demand.
> But then I also found some limitations. Seems thare is no way to tell the tool not to load some plugins, also the dependency system looks a little but clunky because it is based on files rather than bundles.
Cool I have missed this feature from the docs.
Dependency handling can admittedly be improved. tplugin knows three ways of handling dependencies:
(1) Don't handle dependencies and load plugins as needed (this won't work if a plugin tests if another plugin was already loaded by checking the existence of a variable)
(2) Check if a plugins checks for the existence of loaded_PLUGIN_NAME (this requires that the plugin authors adhered to the formatting rules which they probably didn't :-)
How can I use this?
I understand TPluginDependencies only accepts file name patterns, no plugin names. at least is what the docs says.
I understand TPluginDependencies only accepts file name patterns, no plugin names. at least is what the docs says.
(3) Use the info in *-addon-info.txt files if the plugin provides one.
Mmmm is this the same file used by vim-addon-manager?
If the above fails, you can define a file _tplugin_PLUGIN_NAME.vim to define dependencies like:
call TPluginDependencies('THIS_PLUGIN', ['OTHER_PLUGIN'])
Ok so TPluginDependencies( accepts plugins names isnt it?
I guess you could put this definitions also into vimrc.
HTH
Tom
--
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
--
Un saludo
Best Regards
Pablo Giménez
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
Subscribe to:
Posts (Atom)