> I have found a workaround for it.
> I want to detect when command-line mode starts.
Tell about the whole use case. Why do you want to detect switching to
normal mode?
There is InsertLeave. But this doesn't catch visual -> normal.
Marc Weber
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
One workaround is to unmap the disturbing mapping and remap it againlater.. But this can be unfeasible..
In general it is worth talking about the task you're trying to solve
rather than asking about how to implement the solution you think is
best. So which is your use case leading to this question?
I am using NERDTree plugin and it is highlighted well.
When I source _vimrc, highlight of its buffer is down.
I would like to avoid to highlight down this particular buffer.
No name is reusable cause expand("%:p:h") tell me mycurrentdir.
My _vimrc is that one :
colorscheme nuvola " Color, Font
filetype plugin on
" Only do this part when compiled with support for autocommands.
if has("autocmd")
filetype plugin indent on
" Put these in an autocmd group, so that we can delete them easily.
augroup vimrcEx
au!
autocmd FileType text setlocal textwidth=90
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal! g`\"" |
\ endif
augroup END
endif
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
One workaround is to unmap the disturbing mapping and remap it again
later.. But this can be unfeasible..
In general it is worth talking about the task you're trying to solve
rather than asking about how to implement the solution you think is
best. So which is your use case leading to this question?
Marc Weber
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
Is there a command which can be used to go to Normal mode but no
mapping is used in the Normal mode?
That would be similar to :normal!, but in this case I can only start
from Command-Line mode.
So, the command that I need is like
<Command>dd
I can start from any mode, <Command> will make Vim switch to Normal
mode, then it deletes the current line.
Any advice on this matter?
Thank you very much.
Anna
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
> Hi Raúl,
> I've been having the same problem. Somewhere along the line the
> copied text is getting converted from ISO-8859-1 to utf-8. This
> causes problems because it's actually already in UTF-8. So to convert
> the current line back you can do
>
> :.!iconv -f utf-8 -t ISO-8859-1
>
> I have no idea why this is, but this is at least a usable workaround.
> I'd like to know more about this.
>
> I've noticed what seems to be a related issue: If you _select_ (not
> copy) your name in Chrome, and then go to a console and type
> xclip -o
> the ú will be garbled.
FWIW, this appears to work fine for me (both selection and
copying-to-clipboard) with Chromium 4.0.266.0 (Developer Build 33995).
Chromium still seems to be in very volatile development. (I didn't
realize there was even a 'real' Chrome for Linux, though.) It wouldn't
surprise me if this simply 'fixes itself' in some future Chrome release.
--
Best,
Ben
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
:.!iconv -f utf-8 -t ISO-8859-1
I have no idea why this is, but this is at least a usable workaround.
I'd like to know more about this.
I've noticed what seems to be a related issue: If you _select_ (not
copy) your name in Chrome, and then go to a console and type
xclip -o
the ú will be garbled.
A bit more detail:
$ xclip -o | xxd
0000000: 5261 fa6c Ra.l
It looks like the opposite is happening here, ie it is being converted
from UTF-8 into ISO-8859-1:
$ xclip -o | iconv -f ISO-8859-1 -t utf-8 | xxd
0000000: 5261 c3ba 6c Ra..l
$ echo -n "Raúl" | xxd
0000000: 5261 c3ba 6c Ra..l
Both of these are the correct UTF-8 rendering of your name.
On Mar 31, 4:54 pm, Raúl Núñez de Arenas Coronado <raul...@gmail.com>
wrote:
> Hi all :)
>
> Since this may be my fault (or Chrome's fault) I won't go into deep
> details. Instead, I'll show a small example.
>
> I select and copy in Google Chrome (using Ctrl-C) the word "Raúl"
> (that is, my name). I open any program and paste, and the text pasted
> is exactly "Raúl".
>
> Now I open console Vim under gnome-terminal and I run ":registers".
> This is what I have (excerpted):
> "* Raúl
> "+ Raúl
>
> In the first line the text is correct, but in the second line the
> uacute doesn't appear and instead you can see the latin-1
> representation.
>
> Any other program I've tested works perfectly when pasting text from
> Google Chrome, and Vim works perfectly when pasting text from other
> programs, so the problem looks like a weird interaction between Google
> Chrome and Vim, or just with the way Google Chrome uses the clipboard
> selection.
>
> Anyone knows which can be the problem?
>
> Thanks in advance, guys!
>
> --
> Raúl "DervishD" Núñez de Arenas Coronado
> Linux Registered User 88736 |http://www.dervishd.net
> It's my PC and I'll cry if I want to... RAmen!
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
Hm. The status lines allows a "left-side group" and a "right-side group"
of items, separated by %= and in addition you may have one %< item to
define where to truncate the line if too long.
I haven't tried bracketing an item (or a set of items) between two %=
markers. If it doesn't give an error, it might be what you want.
See :help 'statusline'
Best regards,
Tony.
--
Taxes, n.:
Of life's two certainties, the only one for which you can get
an extension.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
" Setup:
let testdict = { }
funct! testdict.funct()
echo "called"
endfunct
" Tests:
" Following each line is an indented comment containing its
output in message land, ie what was echoed.
call testdict.funct()
" called
echo testdict.funct
" 667
echo string(testdict.funct)
" function('667')
echo function('667')
" E475: Invalid argument: 667
echo function('testdict.funct')
" testdict.funct
call call(testdict.funct, [ ])
" E725: Calling dict function without Dictionary: 667
" Same deal if there's an intermediate variable involved.
let TestdictDotFunct = testdict.funct
echo TestdictDotFunct
" 667
echo string(TestdictDotFunct)
" function('667')
call TestdictDotFunct()
" E725: Calling dict function without Dictionary: 667
From the help topic *E725*:
It is also possible to add a function without the "dict" attribute
as a
Funcref to a Dictionary, but the "self" variable is not available
then.
So logic would seem to indicate that if "self" is not available, then
it should be possible to call the function referenced by the Funcref
without a Dictionary. However this doesn't seem to be the case. Am I
missing something?
Vim version info:
$ aptitude show vim-gnome
Package: vim-gnome
State: installed
Automatically installed: no
Version: 2:7.2.245-2ubuntu2
$ vim --version
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Sep 21 2009 11:22:21)
Included patches: 1-245
Compiled by buildd@crested.buildd
Huge version with GTK2-GNOME GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -
ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path
+float +folding -footer +fork() +gettext -hangul_input +iconv
+insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds
+localmap
+menu +mksession +modify_fname +mouse +mouseshape +mouse_dec
+mouse_gpm
-mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm
+multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl
+postscript
+printer +profile +python +quickfix +reltime +rightleft +ruby
+scrollbind
+signs +smartindent -sniff +statusline -sun_workshop +syntax
+tag_binary
+tag_old_static -tag_any_white +tcl +terminfo +termresponse
+textobjects +title
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
+viminfo
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset
+xim
+xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -
D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/
include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/
include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/
usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/
include -DORBIT2=1 -pthread -D_REENTRANT -I/usr/include/
libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/
include/gnome-keyring-1 -I/usr/include/libgnome-2.0 -I/usr/include/
libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/
gtk-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -
I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/
include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/
include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/
include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/
usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/gtk-2.0/
include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/
directfb -I/usr/include/libpng12 -Wall -g -O2 -D_REENTRANT -
D_GNU_SOURCE -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.10/CORE -I/usr/include/
python2.6 -pthread -I/usr/include/tcl8.4 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/x86_64-
linux
Linking: gcc -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-
dynamic -Wl,-E -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -
latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lgio-2.0 -
lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lglib-2.0 -lgnomeui-2 -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -
lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2 -
lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -
lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -
lgconf-2 -lgthread-2.0 -lrt -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -
lXt -lncurses -lselinux -lacl -lgpm -Wl,-E -L/usr/local/lib -L/usr/
lib/perl/5.10/CORE -lperl -L/usr/lib/python2.6/config -lpython2.6 -L/
usr/lib -lz -lutil -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-
functions -L/usr/lib -ltcl8.4 -lieee -lruby1.8 -lrt -lm
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
The problem is that your 'formatoptions' (or just 'fo') option
includes the 'o' flag. It sounds like you want the 'r' flag but not
the 'o' flag. See
:help fo-table
for an explanation of what the various flags do.
To the question of why that behavior seems to have changed for you
recently, execute this:
:verbose set fo?
That will tell you the current value of the 'fo' option and where it
was last set. The proper way to set or restore the value of 'fo'
to what you want will depend on the output from that command.
My preferred value of 'formatoptions' contains 'r' but not 'o'.
That way I can easily insert code below a comment by typing 'o' on
the last comment line. If instead I want to insert more lines of
comment below an existing comment, I move the cursor to the last
comment line, hit 'A' then Enter, and I have a new line beginning
with the comment leader.
HTH,
Gary
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
when i open a new line from a "commented line" then vim
automatically copies the comment indentation. feature.
if however i dont want the comment on the line then
i simply delete it (within insert mode) with CTRL-U.
no need to change the comments options or anything.
easy and effective. :-)
Sven
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
On Mi, 31 Mär 2010, Christian Brabandt wrote:
> Hi,
>
> sometimes I am using fold expressions to simply hide away unwanted
> parts. Usually this boils down to
> :set fdm=expr fde=getline(v:lnum)!~getreg('/',1)
>
> While this works fine, it is only limited to whatever was in register @/
> when this setting was entered. Now this leaves an interesting question:
> When are 'foldexpr' reevaluated (are they at all)? Reading :h fold.txt
> does not mentioned when the fold expressions are reevaluated and folds
> are updated (or I might have missed it).
>
> Now the obvious cure to this is to reenter the foldexpression. So if I
> am searching for a different term, I need to enter
> :set fde=getline(v:lnum)!~getreg('/',1)
> and the folds will be updated.
>
> Of course, I could define my own :Foldupdate like this:
> :com! Foldupdate :exe "set fde=".&fde
>
> But this looks so fundamental, that I am wondering, whether I am the
> only one who is missing :foldupdate. Does anybody else think so? Or am I
> missing something obvious?
>
> PS: Looking at the source, it does not seem too hard, to define an extra
> :foldupdate command. Does that sound like a reasonable idea? I could
> prepare a patch for this, if there is interest.
>
> regards,
> Christian
>
> (Actually, I'd really like an RegisterChanged autocommand event, which
> could trigger an :foldupdate)
Ok, here is a patch, that implements :foldupdate as ex command and zU as
normal mode command.
Here is the testcase:
go to the vim-Src directory and execute the attached vim-script:
chrisbra t41:~/vim/src [1296]% ./vim -u NONE -N -S foldupdate.vim eval.c
Note, how the folding will be wrong, after the second search command
(and I have found no way to refresh the folding. zx and zX do not work,
though its description led me believe it could have. Well actually I
found one way: filtering the whole buffer through cat will also update
the folding)
When recompiling vim with the patch, the folding will be updated, when
:foldupdate is called.
regards,
Christian
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
How do I center-align some items on statusline ?
Thanks.
Viki
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
> You've never needed more than eight letters? --Antony
For what ? -- Yakov
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
> On Wed, March 31, 2010 5:15 pm, Benjamin R. Haskell wrote:
> > On Wed, 31 Mar 2010, Paul wrote:
> >> On Wed, Mar 31, 2010 at 03:02:41PM +0200, Christian Brabandt wrote:
> >> > But this looks so fundamental, that I am wondering, whether I am
> >> > the only one who is missing :foldupdate. Does anybody else think
> >> > so? Or am I missing something obvious?
> >>
> >> You are not the only one. Every once in a while I will somehow see
> >> my folds messed up after some serious editing, when I know they are
> >> correct, and have to quit and re-edit the file in order to have
> >> them show correctly.
> >
> > I generally just type Ctrl-L to clear and redraw the screen. For
> > most filetypes I prefer fdm=syntax, so maybe something's different
> > with fdm=expr.
>
> Ctrl-L does not update folds.
Are you sure? Ctrl-L appears to just call redraw_later, and I didn't
fully trace the call tree, but redraw_later seems to end up calling
FOR_ALL_WINDOWS...redraw_win_later, which would end up calling
redrawWinline (which does something with folds), eventually... yes?
All I know is that every time I've noticed an improper fold, I've hit
Ctrl-L to correct the problem.
But again, I don't use fdm=expr. So, maybe whatever mechanism marks a
fold as invalid doesn't use the same logic when fdm=syntax.
--
Best,
Ben
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
Since this may be my fault (or Chrome's fault) I won't go into deep
details. Instead, I'll show a small example.
I select and copy in Google Chrome (using Ctrl-C) the word "Raúl"
(that is, my name). I open any program and paste, and the text pasted
is exactly "Raúl".
Now I open console Vim under gnome-terminal and I run ":registers".
This is what I have (excerpted):
"* Raúl
"+ Raúl
In the first line the text is correct, but in the second line the
uacute doesn't appear and instead you can see the latin-1
representation.
Any other program I've tested works perfectly when pasting text from
Google Chrome, and Vim works perfectly when pasting text from other
programs, so the problem looks like a weird interaction between Google
Chrome and Vim, or just with the way Google Chrome uses the clipboard
selection.
Anyone knows which can be the problem?
Thanks in advance, guys!
--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
> - disable existing last-position-jump code in the vimrc
> - put the attached file in the plugin folder
It seems to work very nicely. Thanks.
NB: Your code works when "set insertmode" is present in .vimrc (as a
special case gvim -y).
It does not work when "startinsert" is used instead (which has the
advantage of keeping the Esc key).
Could you cure that?
Best regards
Jean Johner
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
:D perhaps. Turns out you can turn omnicompletion/ctags right off and
use your own dictionary:
set complete=k
set dictionary=/path/yourtagsdictionary
This way it doesn't even need to be a ctags formatted file. I got
turned onto the completion functions with omincomplete, I didn't
realize there were other options. The options are under:
:help ins-completion
But the bit about how to set which option is indeed under "help
complete". Thanks!
--
MK <halfcountplus@intergate.com>
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
:help 'complete'
perhaps?
HTH,
Gary
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
--
MK <halfcountplus@intergate.com>
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
" [1] added, although jumping to help tags seems to work without this
" guard
map <Plug>LastPos <Nop>
cmap <Plug>LastPos <Nop>
ino <silent> <Plug>LastPos <C-R>=''[setpos('.',getpos("'\""))]<CR>
augroup LastPos
au! BufReadPost * call s:LastPos(&insertmode)
augroup END
func! s:LastPos(mode)
if a:mode == 2
au! LastPos InsertEnter
call feedkeys("\<Plug>LastPos")
return
endif
let m = "'\""
if getpos(m) != [0,1,1,0] && line(m) <= line("$")
\ && getpos(".") == [0,1,1,0]
\ && &buftype == ""
if a:mode == 1
au LastPos InsertEnter * call s:LastPos(2)
else
normal! g`"
endif
endif
endfunc
" vim:et tw=72:
Am 31.03.2010 16:42, schrieb Jean Johner:
> On Mar 31, 1:01 am, Tony Mechelynck<antoine.mechely...@gmail.com>
> wrote:
>
>> so Christian's observations leave
>> me baffled.
>
> Please find below a reproduceable situation where help side-effects of
> Andy's code appear:
>
> Use vimrc_example.vim completed with Andy's code as .vimrc
> Go to home directory
> rm .viminfo (DON'T FORGET)
> gvim file1
> :set insertmode
> CTRL-O :h zR
>
> Result: the help window opens at the beginning of fold.txt (not the
> correct place)
>
> If :set insertmode is not typed, the problem does not occur.
>
> Do you reproduce that?
Yes. Vim first jumps to the tag, then lastpos jumps to `" which is
initialized with (line 1, col 1).
I added more guards.
Installation (suggestion only):
- disable existing last-position-jump code in the vimrc
- put the attached file in the plugin folder
--
Andy
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
Ctrl-L does not update folds.
(Usually I don't use folding. Only when searching for something
I find foldmethod=expr convenient).
> I notice the improper folds most frequently when I've just added another
> branch to a conditional (e.g. turning something with the structure
> if(1){}else{}
> into
> if(1){}elsif(2){}else{}
> ) but I can't seem to come up with a good minimal case. I'll try to do
> that next time I notice the problem.
I remember that fdm=syntax is mentioned several times in todo.txt.
regards,
Christian
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
The getqflist() is the approach I took:
function! Grep(pattern, location)
exe "noautocmd vimgrep /" . a:pattern . "/gj " . a:location
if (!empty(getqflist()))
silent exe 'copen'
endif
endfunction
which works nicely for me.
Cheers!
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
You can use a :try :catch block and catch pattern E480.
(Seems like the help tag E480 is wrong).
And you can also check, whether the result returned by getqflist() is
empty.
see
:h :try
:h :catch
:h getqflist()
regards,
Christian
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
Is it possible to check the return code of an Ex command? I currently have:
function! Grep(pattern, location)
exe "noautocmd vimgrep /" . a:pattern . "/gj " . a:location " | copen"
endfunction
which causes an error with copen if vimgrep doesn't return anything.
I'd like to handle the error a little more gracefully if possible.
Thank you,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
> On Wed, Mar 31, 2010 at 03:02:41PM +0200, Christian Brabandt wrote:
> > But this looks so fundamental, that I am wondering, whether I am the
> > only one who is missing :foldupdate. Does anybody else think so? Or
> > am I missing something obvious?
>
> You are not the only one. Every once in a while I will somehow see my
> folds messed up after some serious editing, when I know they are
> correct, and have to quit and re-edit the file in order to have them
> show correctly.
I generally just type Ctrl-L to clear and redraw the screen. For most
filetypes I prefer fdm=syntax, so maybe something's different with
fdm=expr.
I notice the improper folds most frequently when I've just added another
branch to a conditional (e.g. turning something with the structure
if(1){}else{}
into
if(1){}elsif(2){}else{}
) but I can't seem to come up with a good minimal case. I'll try to do
that next time I notice the problem.
In case they affect anything, I also still have the following mappings
in place:
aug NoInsertFolding
au!
au InsertEnter * let b:oldfdm = &l:fdm | setlocal fdm=manual
au InsertLeave * let &l:fdm = b:oldfdm
aug END
They have their own problems (referenced in another thread), but are
better than the madness of folds changing mid-insert.
--
Best,
Ben
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
IIUC, for xxxxxx (the highlight group name) almost any keyword is
_permitted_, but a name is only useful if it is _used_ somewhere.
- Some groups are predefined by Vim:
:help hl-<Ctrl-D>
- Some others, even without a help entry, are defined by :syntax on:
:view $VIMRUNTIME/syntax/syncolor.vim
- Some more are defined by the various syntax scripts, usually (but not
always: see for instance htmlBold, htmlItalic, etc.) by linking to one
of Vim's default groups:
:view $VIMRUNTIME/syntax/vim.vim
:view $VIMRUNTIME/syntax/c.vim
:view $VIMRUNTIME/syntax/html.vim
:view $VIMRUNTIME/syntax/sh.vim
:view $VIMRUNTIME/syntax/dosbatch.vim
:view $VIMRUNTIME/syntax/perl.vim
:view $VIMRUNTIME/syntax/python.vim
etc. etc. etc.
- You may use any existing name (including a new one that you define
yourself) for matching:
:help :match
:help :2match
:help :3match
:help matchadd()
:help matchdelete()
For cccc, the color name, some names are permitted for ctermbg=
ctermfg=; the same, plus many more, are permitted for guibg= guifg=
First, in the console: see
:help cterm-colors.
Numbers from 0 to one less than 't_Co' are permitted (but they don't
mean the same everywhere: for instance 1 means red on the Linux console,
but blue on the Dos console), and also the names listed in that help topic.
For the GUI, the list can be obtained by looking at the file rgb.txt. On
Unix/Linux, you probably already have one but its location varies from
one distro to the next, you may have to search. On Windows, you may or
may not have one in $VIMRUNTIME for use by gvim. On Windows, OS-defined
names are also permitted, see
:help gui-colors
:help win32-colors
:help dos-colors
In addition, in the GUI, colors can be defined as #xxxxxx where xxxxxx
are six hex digits (no more, no less): two for the red component, then
two for the green component, then two for the blue component.
"Abbreviated" values with only three hex digits, as used in HTML and
CSS, are not accepted by Vim.
Best regards,
Tony.
--
Nihilism should commence with oneself.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
You are not the only one. Every once in a while I will somehow see my folds messed up after some serious editing, when I know they are correct, and have to quit and re-edit the file in order to have them show correctly.
--
.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
>so Christian's observations leave
> me baffled.
Please find below a reproduceable situation where help side-effects of
Andy's code appear:
Use vimrc_example.vim completed with Andy's code as .vimrc
Go to home directory
rm .viminfo (DON'T FORGET)
gvim file1
:set insertmode
CTRL-O :h zR
Result: the help window opens at the beginning of fold.txt (not the
correct place)
If :set insertmode is not typed, the problem does not occur.
Do you reproduce that?
Best regards
Jean Johner
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
Thank you. Good luck.
Regards
Jean
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
I do see the effect -- its on my todo list. It might be awhile, though...
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
To unsubscribe, reply using "remove me" as the subject.
sometimes I am using fold expressions to simply hide away unwanted
parts. Usually this boils down to
:set fdm=expr fde=getline(v:lnum)!~getreg('/',1)
While this works fine, it is only limited to whatever was in register @/
when this setting was entered. Now this leaves an interesting question:
When are 'foldexpr' reevaluated (are they at all)? Reading :h fold.txt
does not mentioned when the fold expressions are reevaluated and folds
are updated (or I might have missed it).
Now the obvious cure to this is to reenter the foldexpression. So if I
am searching for a different term, I need to enter
:set fde=getline(v:lnum)!~getreg('/',1)
and the folds will be updated.
Of course, I could define my own :Foldupdate like this:
:com! Foldupdate :exe "set fde=".&fde
But this looks so fundamental, that I am wondering, whether I am the
only one who is missing :foldupdate. Does anybody else think so? Or am I
missing something obvious?
PS: Looking at the source, it does not seem too hard, to define an extra
:foldupdate command. Does that sound like a reasonable idea? I could
prepare a patch for this, if there is interest.
regards,
Christian
(Actually, I'd really like an RegisterChanged autocommand event, which
could trigger an :foldupdate)
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
I had no answer for the above message.
My version of netrw is v137l.
With "let g:netrw_fastbrowse" absent, "let g:netrw_fastbrowse=0", "let
g:netrw_fastbrowse=1", the netrw buffer is always marked unlisted (It
appers with "u" when you type :ls!), so that it never shows when you
use :bp. Which is in my opinion the expected behaviour.
With "let g:netrw_fastbrowse=2", the netrw buffer is no longer
unlisted after the second ":e." call, so that it shows when you
use :bp. Can you reproduce that?
Best regards
Jean Johner
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
I'm not sure even *Bram* keeps his Vim runtimes as up-to-date as
diligently as you do... ;-)
-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
To unsubscribe, reply using "remove me" as the subject.
$TERM=xterm-color
vim version 7.0.237
i686-redhat-linux-gnu
I have added to my .vimrc file:
highlight comment ctermfg=darkgray
highlight constant ctermfg=darkblue
highlight Identifier ctermfg=black " html < and />
highlight search ctermbg=lightYellow ctermfg=black
highlight Special ctermfg=Gray
highlight Statment ctermfg=red ctermbg=yellow
highlight Function ctermfg=darkGray " begin tag wickets , =
highlight Type ctermfg=Darkgray
highlight Question ctermfg=red ctermbg=blue
highlight NonText ctermfg=darkGray
highlight PreProc ctermfg=darkGray
highlight htmlTitle ctermfg=DarkGray
The entire .vimrc is at http://www.Real-World-Systems.com/docs/vimrc
when editing an .html file
text is in black, that's good
wickets ( < and > ) are in black, that's ok
HTML tag names are in yellow (?) that's good
broken tag , (second < in a row ) is gray/red that's good
& etc are shown in gray. that's Not Nice
keywords before = are blackBold
values after = are blue, that's ok
h3 is in violet(?)
1) what colornames are permitted, ( orange is not )
2) where is the list of keywords?
Thanks in advance
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Benjamin Haskell told you, but you should have checked the date on line
1 of the file. Apparently not everyone keeps his Vim runtimes up-to-date
as diligently as I do. ;-)
The latest version of that file is always available at
ftp://ftp.vim.org/pub/vim/runtime/doc/todo.txt so you could have done:
:sview +2245 ftp://ftp.vim.org/pub/vim/runtime/doc/todo.txt
(there is also an rsync server). Sorry I didn't think to mention this
command earlier.
>
> Thanks
> Jeenu
>
My pleasure.
Tony.
--
"My particular problem is with registry entries, which seem to just
accumulate
like plastic coffee cups..." -- Paul Moore
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
For buffers, it's easy: see :help :ls; but for use in a script see the
help links near the bottom of this message.
For windows, it's more involved: windows are defined by their number
(starting at 1 at top-left and with the highest number at bottom-right)
within their tabpages (which are also numbered starting at 1). Unlike
buffers, there is no "window identifier" which remains unchanged when
you move windows and tabpages around, or open and close them.
Now here we go:
tabpagenr()
the number of the current tab page
tabpagenr('$')
the total number of tab pages
winnr()
the number of the current window within the current tab page
winnr('$')
the number of windows within the current tab page
winnr('#')
the number of the latest window accessed in this tab
before the current one; or 0 if there was no previous window
or if it was in a different tabpage
tabpagewinnr(t)
the number of the current window in the t-th tab
tabpagewinnr(t,'$')
the total number of windows in the t-th tab
tabpagwinnr(t,'#')
the previous window for the t-th tab
tabpagebuflist()
a List whose items are the buffer numbers for the current tab
This is zero-based!
tabpagebuflist()[0] is the number of the buffer in window 1
tabpagebuflist(t)
the same for the t-th tab
Notes:
- In case of error (t < 1 || t > tabpagenr('$'),
the number 0 is returned.
- A buffer can be displayed in more than one window.
winbufnr(0)
the number of the buffer in the current window
(of the current tab)
winbufnr(w)
the number of the buffer in the w-th window
(of the current tab)
== tabpagebuflist()[w - 1]
Returns -1 if there is no w-th window
See also:
:help tabp*(<Ctrl-D>
:help win*(<Ctrl-D>
:help buf*(<Ctrl-D>
where <Ctrl-D> means: hit Ctrl-D (i.e. hit d while holding Ctrl).
And see ":help setting-tabline" for a couple of user-defined functions
which use these builtin functions in order to display the text-mode tab
line (showing the current buffer in each tab). See also the example
under tabpagebuflist() to get a List of all buffers in all tabs (some of
them may appear more than once, and hidden buffers, which are loaded but
not displayed, won't appear at all in that List). Either of these
examples can be expanded to get a two-level list of all buffers listed
per tab.
Best regards,
Tony.
--
Adore, v.:
To venerate expectantly.
-- Ambrose Bierce, "The Devil's Dictionary"
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
This ought not to influence other helpfiles, and even in help.txt the
tags file for help contains search commands, not line numbers (see :help
help-tags; the single exception is the entry for help-tags itself, which
sends you to line 1 of the tags file), so I don't believe it would be
relevant either.
As for updating it "frequently", does Vim update it more often than (1)
at startup and (2) when :helptags is run? That should be enough,
shouldn't it?
OTOH, all helpfiles have 'nomodifiable' set, and IIRC you're setting the
cursor location at an InsertEnter autocommand, which ought not to be
triggered for a 'nomodifiable' file, so Christian's observations leave
me baffled.
Best regards,
Tony.
--
If anything can go wrong, it will.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
I think the vimrc_example.vim should set an example, and as such it
cannot afford to be sloppy. Anything in it which doesn't work as
intended should be corrected, if possible: that's why I recommend to
implement it by sourcing it from the user's vimrc (so the most recent
version is always used) rather than by copying it (which "freezes" the
version used) then more or less misguidedly adding the user's settings
in the same file. (I know Bram disagrees about this source-vs.-copyedit
preference, and I don't completely fathom his reasons for it.)
Best regards,
Tony.
--
default, n.:
[Possibly from Black English "De fault wid dis system is you,
mon."] The vain attempt to avoid errors by inactivity. "Nothing will
come of nothing: speak again." -- King Lear.
-- Stan Kelly-Bootle, "The Devil's DP Dictionary"
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
I think it's got something to do with the way Vim handles Windows
input messages (since the console Windows version works OK).
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
An AOL-like 'me too!'.
--
.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
I agree: both "exe[cute]" and "echo" treat their arguments the same way:
any number of expressions are allowed, and their values are concatenated
space-separated into one long string before being further processed.
Then :echo displays the result while :exe treats it as an ex-command
line. IOW you can always use :echo instead of :exe to make sure which
ex-command :exe would generate.
Me too, I prefer using
:exe "command" variable1 variable2 variable3
rather than
:exe "command " . variable1 . " " . variable2 . " " . variable3
It's easier to type, and at least as easy to understand once you
remember that :echo and :exe both accept any number of arguments, which
they will concatenate in the same manner.
And indeed, that behaviour is not going to change: it would needlessly
break compatibility with uncounted existing scripts, something which
Bram would never accept (needlessly breaking, I mean: a compatibility
break is only accepted when there is an obvious advantage and no great
risk in doing so, for instance when 1.23 was redefined as the floating
number "one unit and twenty-three hundredths" where before it had been
the string expression 1 . 23, which evaluated to '123' [and with the
spaces it still does]).
Best regards,
Tony.
--
Experience is what you get when you don't get what you want.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
That was 2148 on mine...
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
In Emacs, you have overlays (arbitrary text regions) that can store
metadata about the text within that region and have special mappings.
IIRC this also makes it easy to define popup menus specific to that
region.
I don't think this would make things overly complicated. IMHO it would
rather simplify writing certain type of plugins that now have to store
that metadata someplace.
You could simplify window-local maps with buffer-local maps that
behave differently depending on the value of a window-local variable,
I guess.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
> On 30/03/10 14:18, Jeenu wrote:
> > Hi,
> >
> > I know of<buffer> local mapping and global mapping. I wonder why
> > there isn't a<window>/<tab> local mapping option for Vim. I use
> > some Vim windows/tabs exclusively for navigating quick fix lists. On
> > those windows, I keep<C-N> nd<C-P> globally mapped to :lnext (or
> > :cnext) and :lprevious. The problem with buffer-local mappings here
> > is that every time the list will load a new buffer which might not
> > have this mapping set. Had the mappings been window- or tab-local, I
> > could have reused the same mappings on other windows for something
> > else - may be page navigation.
> >
> > Any reason why those are omitted, and any plans to have them in Vim?
> >
> > Thanks
> > Jeenu
> >
>
> See line 2245 in $VIMRUNTIME/doc/todo.txt (:help todo.txt) dated 2010
> Mar 02 as shown on its first line.
That was line 1722 on my system (Last change: 2009 Aug 09). Might be
hard to find, and it's short. Reproduced here:
In the section 'User Friendlier:'
...
- Add mappings local to a window: ":map <window> ..."?
The '-' indicates 'unclassified' as to its priority (as seen at the top
of that file)
--
Best,
Ben
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Sorry. The said doc on my Vim (Ubuntu) doesn't have anything
interesting at that line. What I've is:
2242 specific prefixes with suffixes.
2243 Alternative:
2244 PSFX {flag} {pchop} {padd} {pcond} {schop} {sadd}[/flags]
{scond}
2245 We might not need this at all, you can use the NEEDAFFIX flag
and the
2246 affix which is required.
2247 - When a suffix has more than one syllable, it may count as a
word for
2248 COMPOUNDWORDMAX.
2249 - Add flags to count extra syllables in a word. SYLLABLEADD1
SYLLABLEADD2,
2250 etc.? Or make it possible to specify the syllable count of a
word
Um, what's that you're pointing at?
Thanks
Jeenu
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe, reply using "remove me" as the subject.
I'd write or script it as
:map <window> <C-N> :lnext
:map <window> <C-P> :lnext
when I'm at the required window
Thanks
Jeenu
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
See line 2245 in $VIMRUNTIME/doc/todo.txt (:help todo.txt) dated 2010
Mar 02 as shown on its first line.
Best regards,
Tony.
--
"Nuclear war would mean abolition of most comforts, and disruption of
normal routines, for children and adults alike."
-- Willard F. Libby, "You *Can* Survive Atomic Attack"
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
I use MacVim here on Snow Leopard and it works perfectly fine.
Is there any difference between MacVim and Vim?
I don't think so. If you want a commandline Vim and you have
MacVim installed you can simply run
/Applications/MacVim.app/Contents/MacOS/Vim.
It you need any more compiletime options you can simply compile MacVim
yourself which also works perfectly fine.
On 3/30/10 3:44 PM, Robert H wrote:
> I know there is MacVim but I want a stock Vim.
> [...]
> Bob
--
Viele Grüße,
Andreas Klein
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
make[1]: *** [objects/gui_mac.o] Error 1
make: *** [first] Error 2
Plus a whole lot of gui_mac warnings....
I passed in via a sourced script:
export CONF_OPT_PERL='--enable-perlinterp'
export CONF_OPT_PYTHON='--enable-pythoninterp'
export CONF_OPT_TCL='--enable-tclinterp --with-tcl=tclsh8.5'
export CONF_OPT_MZSCHEME='--enable-mzschemeinterp'
export CONF_OPT_CSCOPE='--enable-cscope'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_FEAT='--with-features=huge'
export CONF_OPT_COMPBY='"--with-compiledby=my@address.com"'
Bob
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Do you think of
:map <window>
:map <tabpage>
next to
:map <buffer>
?
Hmm, logic says using more modifiers is a bit wrong, as
<window>, <tabpage>, <buffer> cannot be combined in one mapping.
There have been similar requests for mappings local to the filetype
(why have duplicated mappings in all buffers sharing the same
filetype?), and mappings local to a specific syntax region (inspired
by TextMate?).
But I guess, all these will just make Vim overly complicated; and with
some scripting it is already possible.
Another problem:
how do you think windows should be identified -- by number?
--
Andy
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
> On 28 March 2010 09:25, Teemu Likonen <tlikonen@iki.fi> wrote:
>> DISCLAIMER: My tests may suck so I suggest everyone do better ones.
>> :-)
>
> :-). Well I think I should mention that GForth is VM based, or it was
> last I looked.
More accurately GForth uses GCC to compile direct or indirect threaded
code.
> A fast commercial Forth is probably pretty close to the optimised
> SBCL.
Yes, that's very likely. Here's an old comparison between Forth systems:
http://www.complang.tuwien.ac.at/forth/performance.html
GForth seems to be the fastest of those which do not produce pure native
code.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Now do CTRL-O several times. You go to pattern2, then to pattern1,
then to line1, column 1. All as expected.
CTRL-I goes to pattern1, pattern2, end-of-file (OK)
2) Now do the same in insert mode.
gvim -u NONE file1 (cursor is on line1, column1)
i (to go to insert mode)
<C-O>/pattern1 (cursor at the beginning of pattern1)
<C-O>/pattern2 (cursor at the beginning of pattern2)
CTRL-End (to go to end-of-file)
Now do "CTRL-O CRTL-O" several times. You go to pattern1, then to
line1, column1.
"CTRL-O CTRL-I" goes to pattern1, end-of-file.
Conclusion: pattern2 has vanished from the jumplist in 2).
NB: It does not occur if you repalce CTRL-End with <C-O>G in 2)
(this can be a work-around)
Best regards
Jean Johner
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
I know of <buffer> local mapping and global mapping. I wonder why
there isn't a <window>/<tab> local mapping option for Vim. I use some
Vim windows/tabs exclusively for navigating quick fix lists. On those
windows, I keep <C-N> nd <C-P> globally mapped to :lnext (or :cnext)
and :lprevious. The problem with buffer-local mappings here is that
every time the list will load a new buffer which might not have this
mapping set. Had the mappings been window- or tab-local, I could have
reused the same mappings on other windows for something else - may be
page navigation.
Any reason why those are omitted, and any plans to have them in Vim?
Thanks
Jeenu
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
> Please try netrw v137l.
Perfect!
> So you're a physicist -- are you working with the LHC?
I work in the French Thermonuclear Fusion lab (CEA/Cadarache) close to
future ITER site.
Best regards
Jean Johner
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Using Ctrl-C, Ctrl-X and Ctrl-V for copy, cut and paste has nothing to
do with ":behave mswin" (which is just a kind of abbreviation for ":set
selectmode=mouse,key mousemodel=popup keymodel=startsel,stopsel
selection=exclusive"), it has everything to do with sourcing mswin.vim
(which you also do in your vimrc). It ought to work even in gvim, unless
something else is at work.
To see if something else is overriding mswin.vim's mapping, try
:verbose map <C-C>
in a running gvim.
In any case I don't recommend sourcing mswin.vim, which masks useful Vim
key bindings; instead, in Vim it helps to keep in mind that the
clipboard is "register-plus" and to use the following:
- To move data to and from the clipboard, for copy / cut / paste to and
from other applications:
Normal commands
"+x delete (cut) one character to the clipboard
"+d{motion} delete to the clipboard
"+dd delete <count> lines to clipboard
{Visual}"+d delete selection to clipboard
"+y{motion} yank (copy) to the clipboard
"+yy yank <count> lines to the clipboard
{Visual}"+y yank selection to clipboard
"+P put (paste) clipboard before cursor
"+p put clipboard after cursor
Ex-commands (always linewise)
:[range]yank +
:[range]delete +
:[range]put +
which can be abbreviated to :y :d and :pu respectively. For :d and :y
the [range] is the set of (consecutive) lines to be cut or copied, for
:put the [range] is the single line after which to paste (or $ for
"after last line" or 0 for "before first line" or omitted for "after
current line" etc.); or with bang (i.e. :put! +) it is the line before
which to paste.
In gvim you can also use the Edit=>Copy, Edit=>Cut and Edit=>Paste menu
items.
If you hit the colon key in Visual mode, Vim prefills the command-line
with :'<,'> which means "from first to last line of the latest Visual
selection" -- just the range that you need in this case.
To move data within a single Vim, the clipboard isn't needed (and then
it works even in the Linux console, which has no access to X): normally
one would use the "unnamed register" by omitting the "+ before Normal
commands or the + after Ex-commands. Or you can use any one of the 26
"letter registers" by replacing the plus sign by a lowercase letter, or,
for yank and delete, by an uppercase letter to append to the register
instead of replacing its contents.
Notes:
- This vimrc will give you errors if ever you try to use it in a Vim
version missing one or more of the +eval +mouse +wildmenu features, and
this gvimrc will give an error if used in a gvim with any GUI other than
GTK2; but I suppose you don't mind these limitations -- at least for now.
- If 7.2.245 is the "latest" Vim Ubuntu has to offer, then they are
taking their time upgrading: the latest "official" patchlevel is
currently 7.2.411 -- IOW you're missing almost half the bugfixes already
published for Vim 7.2; see http://ftp.vim.org/pub/vim/patches/7.2/README
for a list of what these patches are all about, and (if desired)
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm for a HowTo
page about compiling Vim on Unix/Linux. Also
http://vim.wikia.com/wiki/Build_Vim_with_your_name_included which is
less detailed than the above-mentioned HowTo but has a paragraph about
building Vim on Ubuntu.
Best regards,
Tony.
--
Unfair animal names:
-- tsetse fly -- bullhead
-- booby -- duck-billed platypus
-- sapsucker -- Clarence
-- Gary Larson
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
> Please try netrw v137l.
Perfect!
> So you're a physicist -- are you working with the LHC?
I work in the French Thermonuclear Fusion lab (CEA/Cadarache) close to
the future ITER site.
Best regards
Jean
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
I am using Ubuntu 9.10 with vim installed from the official repo:
version 7.2.245 or as Ubuntu names it - 2:7.2.245-2ubuntu2
Here is my .vimrc:
set nocompatible
source $VIMRUNTIME/mswin.vim
behave mswin
set tabstop=4
set shiftwidth=4
set expandtab
set shiftround
set hls
set wildmenu
set showcmd
set showmatch
set ignorecase
set mouse=a
set background=dark
set list listchars=tab:»-,trail:·,extends:>,precedes:<
match ErrorMsg '\%>80v.\+'
let NERDTreeMouseMode=1
let g:netrw_browse_split=4
let g:netrw_hide=0
And here is my .gvimrc:
colorscheme desert
set guifont=monospace\ 13
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
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Hm, I think there's something in this argument. On Unix, long names have
been permitted since I don't know when, but what are the names used? ls
(not "directory_list": "list" would still be ambiguous), cat (not
"concat" and even less "concatenate"), mv (not "move" and even less
"rename"), cp (not "copy"), rm (not "remove" or "delete"), sed (not
"streamedit"), tar (not "tape_archiver" or even "archiver" for who uses
tapes nowadays, at least on Linux?), man (not "manual") and so on and so
forth. So Unix users have to commit to memory that, for instance, to
"rename" a file they must use the "mv" program. Now how can they
remember that? Yet they do.
On Dos/Windows, there are alias pairs: chdir = cd, mkdir = md, rmdir =
rd, del = erase, etc. So what do the overwhelming majority of the users
type in practice? Always the shorter member of the pair.
With Vim commands and options it is maybe less systematic; but after
some time, for the really much-used ones, the abbreviated name always
gets the upper hand: :e (not :edit), :w (not :write), :q (not :quit), :x
(not :exit), :au (not :autocmd), etc. For the options, which ones are
most used may vary somewhat from person to person, but when I'm typing
for myself I use gfn, enc, tenc, fenc, fencs, ff, ffs, imi, ..., even
though when I'm explaining I write about 'guifont', 'encoding',
'termencoding', 'fileencoding', 'fileencodings', 'fileformat',
'fileformats', 'iminsert', etc.
Best regards,
Tony.
--
"I had to censor everything my sons watched ... even on the Mary Tyler
Moore show I heard the word 'damn'!"
-- Mary Lou Bax
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
To unsubscribe from this group, send email to vim_use+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
