Re: Mac Questions
On Tue, Jan 09, 2007 at 10:23:25AM +0100, Bram Moolenaar wrote:
Dave Land wrote:
On Jan 8, 2007, at 3:03 PM, Dave Land wrote:
Happily, Apple provided a utility that handles it for you:
defaults read ${HOME}/.MacOSX/environment
Actually, making this work in bash (or other shell) requires a little
more than just reading the file... Here's the relevant chunk from
my .bashrc:
# Get environment variables from ~/.MacOSX/environment.plist
# (This avoids the sin of duplicating data here and in that file)
if [[ `uname` == 'Darwin' ]] ; then
defaults read ~/.MacOSX/environment | grep -v '[{}]' | tr '' ' |
awk '{ print declare -x,$1=$3 }' | while read -r OneLine; do eval
$OneLine; done;
fi
To give credit where it's due, this came from a comment on
macosxhints.com.
The conditional (if [[ `uname` == Darwin' ]]) is because I use this
same .bashrc across several hosts, including Solaris, Linux, and Mac
OS X.
This issue comes up often enough that it deserves a section in the help.
Could you perhaps write some text? If you can send me a patch that
would be great.
The docs already explain one way to set $PATH.
:help mac-faq
As it says there, the system vimrc files in the versions distributed at
macvim.org/OSX already use this method. The same method should work for
other environment variables ... but AFAIK the only one that matters is
$PATH.
HTH --Benji Fisher
Re: Pasting utf8
On Fri, Dec 01, 2006 at 11:31:50AM -0800, Bill Moseley wrote: VIM - Vi IMproved 7.0 (2006 May 7, compiled Nov 15 2006 16:24:17) Included patches: 1-164 I don't normally use utf8, but I have a uxterm running on Linux. If I copy and paste some UTF8 text from Firefox into Vim I see: Weeding for Your Library\u2019s Health ^^^ But, pasting into the xterm it works fine. That is, in my uxterm I do this (which works correctly): $ echo Weeding for Your Library’s Health utf8-test Where Weeding... was pasted into the xterm with my middle mouse click. Now in Vim I open utf8-test my screen looks fine and encoding? shows encoding=utf8: Weeding for Your Library’s Health ~ ~ ~ 1,16 All But, if I paste with my middle mouse button into Vim I get: Weeding for Your Library’s Health Weeding for Your Library\u2019s Health --- pasted line ~ ~ ~ -- INSERT -- 2,18 Bot What is it not pasting the utf8 character? set mouse? shows mouse=a. I cannot reproduce this problem. Do you get the same behavior if you paste with *p (starting in Normal mode) or C-R* (starting in Insert mode)? What if you start vim with $ vim -u NONE (If your locale is set to something unicode, then 'encoding' should still be set to utf-8; but it is still worth checking this and correcting if I am wrong.) There may be something wrong with your terminal, or some sort of argument between uxterm and vim. Do you have a problem with gvim or with vim running in other terminals? I use gnome-terminal, but I get the same (expected) result when I try with uxterm. HTH --Benji Fisher
Re: Execute command for current block of code
On Wed, Nov 22, 2006 at 11:32:46AM -0800, Gary Johnson wrote: On 2006-11-22, A.J.Mechelynck [EMAIL PROTECTED] wrote: vobject where object is a Normal-mode object, will highlight the concerned object. Example: vip for the inner paragraph. And if you're using the matchit.vim plugin with your tags specified in b:match_words, then a% will highlight the current block as defined by your tags. :help v_a% I was thinking of the same thing. Two more points: if you have not yet installed the help files for matchit.vim, see :help matchit-install After that, you should have help tags for v_a% . See also :help matchit-newlang for how to recognize your custom tags. HTH --Benji Fisher
Re: syntax file from different directory
On Fri, Nov 24, 2006 at 05:08:47AM -0800, Muddassirali Mirzani wrote: The GVIM i'm using is compiled by the system admin. The syntax directory (common to all users) the GVIM executable points does not allow me to write. I have downloaded a new syntax file (vera.vim) and placed it in my $HOME/.vim/syntax and modified the filetype.vim (in $HOME/.vim/)appropriate file extensions recognize this syntax file. (i.e. au BufNewFile,BufRead *.vr,*.vri,*.vrh set ft=vera) I source the filetype.vim and set syntax on in my .gvimrc Now when I try to open somefile.vr it doesn't 'syntax highlight' the file . but if i check with :set syntax=tab it gives me vera . (If I source the vera.vim file in .gvimrc it give the syntax highlighting.) I tried to set the $VIMRUNTIME to $HOME/.vim but was of no avail. How do I get GVIM to read these syntax files ? :version gives the following output :version VIM - Vi IMproved 5.7 (2000 Jun 24, compiled Mar 15 2001 16:09:17) We are using vim 7.0 these days. If you cannot talk your sysadmin to upgrade, maybe you can just compile it yourself and install to $HOME/bin/ ? Try something like this: :set verbose=2 :e foo.vr :set ft? syntax? What do you get? Also, do you have syntax highlighting for other file types? HTH --Benji Fisher
Re: Rephrased: debugging errorformat strings.
On Fri, Nov 24, 2006 at 04:23:32PM +, Hugh Sasse wrote: I'm resubmitting this, clarifying a few points and fixing a typo in the process, because I've seen no responses. Sorry if this is premature: I know it could be due to people being busy. Hopefully the parts I've rephrased will be clearer than my earlier post. [snip] Can you try making the question shorter? --Benji Fisher
Re: Can't change search background color
On Tue, Nov 21, 2006 at 03:25:13AM -0600, Larry Alkoff wrote: I'm using Vim64 in Kubuntu and cannot change the color background when doing a search. The background color is a kind of darkish orange - I _think_ it's numbe 3. I'd like to have LightYellow but nothing I have done so far changes it. From my ~/.vimrc: set hlsearch toggle hlsearch in normal mode: map F1 :set hlsearch!CR or insert mode with imap: imap F1 ESC:set hlsearch!CRa result of :hi search is xxx term=reverse ctermbg=3 (orangy) 14 is ltyellow None of the below worked hi search guibg=LightBlue hi Search guifg=#ec guibg=#c4a000 hi Search guibg=14 Any ideas how to change the background? Larry It helps to be clear about what you have typed and what vim responds, as in :hi search Search xxx term=reverse ctermfg=0 ctermbg=14 guibg=Yellow instead of mixing your comments (such as results of ... is and (orangy) 14 is ltyellow. I suggest using :redir and the :Echo command from foo.vim, my file of example vim functions: http://www.vim.org/script.php?script_id=72 I am guessing that you are using vim, not gvim. If I ma right, then chaining guibg is not going to help. Try :hi Search ctermbg=14 instead. :help :hi in general and :help highlight-args in particular. HTH --Benji Fisher
Re: Problem with Quickfix and Latex
On Thu, Nov 16, 2006 at 06:33:07PM -0200, Luis A. Florit wrote: Pals, I have a recurrent problem with quickfix and Latex. I use the tex.vim compiler by Srinath Avadhanula. I tried both the 2003 version contained in the last LatexSuite plugin http://www.vim.org/scripts/script.php?script_id=475 and version '2006-03-20 09:45:45Z'. Same result. The problem: After make, when there is an error, it jumps to an unwanted file. This is so because the efm variable is not correctly set. For example, after deleting a '$' in a file 'file.tex' and doing make, I read this in the quickfix window: ## || ) (./file.aux) /usr/share/texmf/tex/generic/xypic/xy.sty| error| Missing $ inserted. $ \lambda =1$) and identifying the upper $2\times 2$ matrix in ## Then, a new buffer is loaded with the file xy.sty, and vim tries to go to the line in that line (then it goes to the last). It seems that the problem is that the string '/usr/share/texmf/tex/generic/xypic/xy.sty' was not deleted by efm. [snip] I never looked at the 'errorformat' option until a few weeks ago, when I tried (with less than perfect success) to come up with a good setting for plain TeX. So I think I am not the most qualified person to deal with this. I hope someone else will take a stab at it. --Benji Fisher
Re: search between two brackets
On Mon, Nov 13, 2006 at 01:05:00PM -0600, Ben K. wrote:
Vimmers,
I have a long source code consisting of multiple modules wrapped in {}.
Sometimes I use * to find the next match. But I'd like to search only
within the same module or class that I started from. (which is wrapped
inside sub ... {})
In the following example, I'd like * or n to at least let me know that I
crossed the module boundary for instance 3. Or not match it at all.
If there's a way to highlight between the matching brackets
(open/close),
it would also be helpful, even if it doesn't allow highlighting of the
searched pattern.
sub aaa {
...
instance 1# Begin by *
...
instance 2# This is OK.
...
}
sub bbb {
...
instance 3# This is not what I want
...
}
Is there a simple way to do it?
If you are using vim 7.0, then you can take advantage of the
optional stopline argument in the search() function:
:let pat = '\' . expand('cword') . '\'
:let stopline = searchpair('{', '', '}', 'n')
:call search(pat, '', stopline)
Of course, that does not count as simple, but you can wrap those three
lines in a function and map * to call it:
:nmap * :call MySearch()CR
fun! MySearch()
let pat = '\' . expand('cword') . '\'
let stopline = searchpair('{', '', '}', 'n')
call search(pat, '', stopline)
endfun
Or you could choose another key, and of course there are various ways t
make it all more flexible.
I am not sure exactly what sort of highlighting you want.
HTH --Benji Fisher
Re: Search unfolded lines only
On Mon, Nov 13, 2006 at 04:35:51PM -0500, Jean-Rene David wrote:
Is there any way to search for text in open folds
only? For example, if fold 1 and fold 2 below are
closed and fold 3 is open, and placing the cursor
on the line which says Start search here, I
would like to end up on the foo in fold 3 when
typing /fooCR.
Start search here
{{{
fold1
foo
fold1
}}}
{{{
fold2
foo
fold2
}}}
{{{
fold3
foo
fold3
}}}
--
JR
vim: fdm=marker
It helps to
:set foldopen-=search
Then, as you search for foo, the closed folds stay closed; and if
foo matches more than once in a given fold, n will still move the
the next foo outside the fold. If that is not enough, you can map a
key to do
/foo
:while foldclosed(.) != -1
call search(@/, 'W')
endwhile
(untested).
For details on the 'foldopen' option,
:help 'foldopen'
To help find the option you did not know existed,
:options
HTH --Benji Fisher
Re: RFE: :amap and :menu buffer
On Thu, Nov 09, 2006 at 12:37:48PM -0700, Christian J. Robinson wrote: On Thu, 9 Nov 2006, Bram Moolenaar wrote: buffer-local menus are complicated. What about menus that are not for the current buffer, hide them? Would make jumping between buffers very slow. When I've defined menus that are only applicable to a buffer or a filetype I've just defined autocommands that does an :amenu disable on BufLeave and :amenu enable on BufEnter. I've found this is usually the best compromise and in fact has some advantages; it can be confusing and otherwise problematic to have menu items, or entire menus--especially toplevel menus--disappear and reappear. - Christian Thanks. I had forgotten about the :menu disable option. The disadvantage is that if I have several different file types open, each with its own top-level menu, then my menu bar will be crowded with disabled menus. --Benji Fisher
RFE: :amap and :menu buffer
Maps and menus work in much the same way, and when writing a vim script (especially an ftplugin) I like to make a menu item corresponding to each key map that I define. Unfortunately, there are two ways that maps and menus differ: 1. There is an :amenu command (and also :anoremenu), but there is no :amap command (nor :anoremap). 2. I can make buffer-local maps with :map buffer, but :menu buffer does not work. Both of these shortcomings can be overcome with scripting, but it would be more convenient and more consistent if :amap and :menu buffer were both implemented. --Benji Fisher
Re: Lapsus in usr_10.txt?
On Sat, Nov 04, 2006 at 10:01:24PM +0100, Guido Van Hoecke wrote: Fellow Vimmers, Lines 185-186 in usr_10.txt claim ... Other flags include p (print), which causes the :substitute command to print out each line it changes. ... This is not what happens. Line 639 in change.txt correctly describes the actual behaviour: [p] Print the line containing the last substitute. The text in usr_10.txt should be changed into something like: ... Other flags include p (print), which causes the :substitute command to print out the last line it changes. ... Cordially, Guido. Thanks for reporting this. In the future, you can make things a little easier for Bram if you produce a patch, like the one below. For details on patch format, see my tip at http://www.vim.org/tips/tip.php?tip_id=618 HTH --Benji Fisher *** /usr/local/share/vim/vim70/doc/usr_10.txt 2006-05-08 10:42:46.0 -0400 --- /home/benji/temp/usr_10.txt 2006-11-06 08:27:47.358006837 -0500 *** *** 183,190 Teacher Smith criticized Teacher Johnson today. ~ Other flags include p (print), which causes the :substitute command to print ! out each line it changes. The c (confirm) flag tells :substitute to ask you ! for confirmation before it performs each substitution. Enter the following: :%s/Professor/Teacher/c --- 183,191 Teacher Smith criticized Teacher Johnson today. ~ Other flags include p (print), which causes the :substitute command to print ! out the last line it changes. The c (confirm) flag tells :substitute to ask ! you for confirmation before it performs each substitution. Enter the ! following: :%s/Professor/Teacher/c
Re: disappearing echo in ':nmap *'
On Mon, Nov 06, 2006 at 10:55:34AM +0100, Zdenek Sekera wrote: I had many cases of disappearing echo in the past, I was mostly able to solve with some or other tricks. This one is difficult, I cannot solve it whatever I try (echo in the rhs of 'nmap *'): 1. :nnoremap * :exe norm! * bar echomsg bla blacr 2. :help help 3. /forcr 4. press * * * * * * * Message bla bla mostly does not appear (very rarely, it does; :mess shows that mapping was triggered) Why ? I don't know why but I have that problem since a long time (from vim 5 already!). Yes, sometimes tricks (like introducing dummy 'echo ' before the real echo help, but sometimes they don't. I think Bram knows about it. Searching for echo in todo.txt, I did not find any mention of this. Maybe this item? 9 Check handling of overwriting of messages and delays: Very wrong: errors while redrawing cause endless loop. When switching to another file and screen scrolls because of the long message and return must be typed, don't scroll the screen back before redrawing. It seems to me that the message is wiped out when the screen scrolls. If the cursor move on the same screen, or if the screen redraws, then I see the bla bla. Aha: this seems to help: :nnoremap * :execute norm! * Bar redraw Bar echomsg bla blaCR HTH --Benji Fisher
Re: noimd don't works under linux
On Mon, Nov 06, 2006 at 07:28:35PM +0800, Eddy Zhao wrote:
2006/11/6, Benji Fisher [EMAIL PROTECTED]:
[snip]
Part of the problem is that you defined the :map commands with
notation before setting 'nocp'. From another post on this thread, I see
that you want to try this with gvim, not terminal vim. So please try
$ gvim -u NONE
:set nocp
:set laststatus=2 stl=%{imd}
:inoremap ESC ESC:set imdCR
:nnoremap i :set noimdCRi
and *then* try going from Normal mode to Insert mode and back with i and
Esc. The status line should show the current value of the 'imdisable'
option.
This time status line output switch between 0 and 1
What it reveals ?
This means that the 'imdisable' option is being set when you leave
Insert mode with Esc, and it is being reset when you enter Insert mode
with i, both as intended. Thus the source of the problem is not what
you first guessed it was.
Perhaps it would help if you described more precisely what is not
working the way it should (or the way you expect).
HTH --Benji Fisher
Re: noimd don't works under linux
On Sun, Nov 05, 2006 at 03:13:20PM +0800, Eddy Zhao wrote:
[snip]
Thanks (I forget to set ls).
I do the following
- gvim -u NONE
- :set stl=%{imd} ls=2
- :inoremap ESC ESC:set imdCR
- :nnoremap i :set noimdCRi
- :set nocp
- switching back forth between normal mode insert mode using ESC i
When I pressing i, the input focus is on command line command line
shows :set noimdCRi.
Part of the problem is that you defined the :map commands with
notation before setting 'nocp'. From another post on this thread, I see
that you want to try this with gvim, not terminal vim. So please try
$ gvim -u NONE
:set nocp
:set laststatus=2 stl=%{imd}
:inoremap ESC ESC:set imdCR
:nnoremap i :set noimdCRi
and *then* try going from Normal mode to Insert mode and back with i and
Esc. The status line should show the current value of the 'imdisable'
option.
If the 0 or 1 in the status line is too terse, you could be a
little fancier. For example,
:set laststatus=2 stl=%{imd?'IM\ disabled':'IM\ enabled'}
HTH --Benji Fisher
Re: script able to detect +NUM commandline option ?
On Fri, Nov 03, 2006 at 01:49:24PM +0200, Yakov Lerner wrote: Whether Bram thinks it's useful to store this info in some v:variable (so script can know it) ? Within last year, there were requests how script can know whether vim had +NUM option on command line. Yakov You mean as in :help -+ I guess? That is too specific; why not make the entire command line available? We have v:progname but not the command-line options (including +NUM). I have wanted this, too. BTW, there are too many v: variables for my taste. Why not put all the v:beval_* variables in a v:beval Dictionary? Of course, the old ones would have to be kept around for compatibility for a few releases ... HTH --Benji Fisher
Re: --remote diff to tab
On Wed, Nov 01, 2006 at 02:15:53PM +0100, Hugo Ahlenius wrote: Hi, I am trying to set up my subversion client(s) so that I can get any diffs open in a proper diff mode, in an existing gvim session, in a new tab... Any tips for that? Do you I have to construct a more complicated command-line for that -- I just tried: --remote-tab -d %1 %2 but that opened each file in a separate tab... Did you try (untested by me) --remote-tab +diffsplit %2 %1 (Will the %2 need any special escaping inside the quotes? What if %2 has spaces in the file name (ugh)?) On Thu, Nov 02, 2006 at 09:20:42AM +0100, Hugo Ahlenius wrote: | I don't know how to do exactly what you ask, but have you seen | vcscommand.vim? | | http://www.vim.org/scripts/script.php?script_id=90 | | It has a VCSVimDiff command that will use the svn client to get a diff | and then show the result as a vimdiff. Hi Al, I have that, and that is what I would use from within vim - but there are times when I would like to have things open from external tools, like my svn browser (or my cvs manager). There are other cases as well. Have you tried something like --remote-tab +VCSVimDiff %1 yet? I do not use this, so I have no idea what the syntax of the :VCSVimDiff command is. HTH --Benji Fisher
Re: long line display in gvimdiff
On Wed, Nov 01, 2006 at 09:03:54AM -0500, Dmitriy Yamkovoy wrote: It should apply on a per-window basis, so you may have to execute it in each diff window. Or if you're feeling lazy, :windo set wrap :windo set nowrap These enable or disable wrapping for all windows in the current tab. As long as we are considering easy/efficient/lazy ways to do it, I prefer :windo set wrap! to toggle the setting of 'wrap'. Then I can use @: to change it back. Of course, the same thing works one window at a time without the :windo modifier. As for the problem of affecting non-diff windows, I suggest the following command: Diffdo command applies :command in all windows where 'diff' is set. :command! -nargs=+ -complete=command Diffdo \ windo if diff Bar execute q-args Bar endif HTH --Benji Fisher
Re: Command line tab completion
On Thu, Nov 02, 2006 at 04:25:39PM +0800, [EMAIL PROTECTED] wrote: Gary Johnson [EMAIL PROTECTED] 写于 2006-11-02 15:55:34: This behavior might be affected by 'wildmode'. Mine is set to longest,list. I also tried longest,list:longest, but the behavior was the same. Regards, Gary To make things clear, I had just tried: vim -u NONE -U NONE then :set nocp (Must set nocompatible or the tab completion will be disabled.) and then :help pre followed by tab It works well, so the tab completion should be okay on default. You can try that also, if that works for you, then you may need to check your ~/.vimrc and your ~/.vim directories to see what's different from the default. Then reset the suspected option to default. I agree with Gary. I tried $ vim -u NONE :set nocp wildmenu wildmode=longest:list :help termiTab :help preserTab I was hoping for termin in the first case and preserve in the second, but I was stuck with termi and preser. HTH --Benji Fisher P.S. Has there been a patch that affects this? I am still using vim 7.0.000 .
Re: Smart use of Tab
On Tue, Oct 31, 2006 at 03:57:18PM +, A. S. Budden wrote: [snip] The key problem here is that the autoindenting is, rather understandably, using tabs to achieve the indent, but if another developer works on the code with ts set to something different, the comment on the third line won't line up. Has anyone got any suggestions or am I asking too much from my editor?! :help 'preserveindent' :help 'copyindent' HTH --Benji Fisher
Re: mapping with delay processing
On Sun, Oct 29, 2006 at 01:38:36PM +0200, Yakov Lerner wrote: How can I make mapping or abbrev that behaves as follows: when I type echo (echospace) and I type nothing else within 1 second, it adds '' (so it becomes 'echo '). If I continue typing quickly after 'echo ', then [] is not added. I'm sure it's possible. Yakov Untested: use an abbreviation that defines two autocommands: :augroup Hack :au CursorHoldI * execute normal a\\Esc :au CursorHoldI,InsertLeave,CursorMovedI * au! Hack :agroup END What I did test is that CursorMovedI is triggered when you insert a character. Thus both autocommands are cleared after 'updatetime' or the first typed character (or cursor movement or leaving Insert mode). I am not sure whether the :normal command will work. Of course, you can also have the abbreviation change updatetime and have the autocommands restore it. HTH --Benji Fisher
Re: Setting window size at startup under linux
On Mon, Oct 30, 2006 at 11:30:40AM +1000, John Orr wrote: Hi all, I'm using Suse Linux, with KDE, and have a vim function to set my window size on startup. The function just sets columns and lines, and calls winpos, depending upon various other variables I provide. Previously I was registering this function to be called by an autocmd on the GUIEnter event - but I found that the window seemed to be resized by the operating system afterwards. I tried changing to the VimEnter event which should come last - and that works most of the time, but not always. I tried inserting a 5 second sleep into my function triggered by VimEnter - so the operating system could mess around with the window size before I then set it to the size I want - but no, I get a 5 second delay, my window is then set to my size - and then reset by the OS. It's not dramatically reset - eg, I set it to 360 columns (spanning two monitors), and the OS reset it to 315. If I run my function again manually, it sets the 360 columns perfectly. I guess there may be some X related ways to achieve what I want - but all I really want to do is wait until after the operating system has had it's play with the window size, and then let my function go to work. Anyone got any hints please? Thanks in advance, John If you are right that the OS is messing with your window, then this may not help, but it does not hurt to try: :verbose set lines? columns? after starting up. Somewhat more involved is to set 'verbose' to something big and log all messages. If you are using vim 7.0, this is pretty easy: :help 'verbosefile' It is a little harder with earlier versions of vim. Again, this may not help at all. On the other hand, if there is a way to fix it in your vimrc file, then looking at these messages should point to it. HTH --Benji Fisher
Re: Smart use of Tab
On Fri, Oct 27, 2006 at 04:46:02PM +0100, A. S. Budden wrote: Dear all, I've recently started using the CleverTab function below, modified from the bottom of the comments page on tip 102. This is brilliant from my point of view: - tab produces tabs at the start of the line for indenting*; - tab shows the longest unique option in the omnicomplete list when using omnicompletion; - tab cycles through the list of completions if the popup menu is visible but omnicompletion isn't used; - otherwise, it returns a tab. What I'd like to do is change the last one of those so that it puts in enough spaces to reach the next tabstop so that good formatting is maintained regardless of the tabstop setting on a users editor. However, I can't figure out how to achieve this. The 'expandtab' option is no use as it will change the tabs at the start of the line (used for indentation) to spaces, which will result in a really badly formatted piece of source code (as it is edited by several people who all like different tab stops)*. Similarly, replacing \Tab in the last return line with is no use as it will always insert four spaces, even if we're halfway through a tab stop (it's also not very flexible for different tabstop settings). Can anyone offer any suggestions for this? [snip] The 'expandtab' option does not affect existing tabs in the file (unless you :retab) so it should be safe to have your function reset/set it depending on whether you are at the start of the line or not. I have not tested this. For another approach, pretty much what you suggested, look at the VarTab() function in foo.vim, my file of example vim functions: http://www.vim.org/script.php?script_id=72 This function returns a calculated number of spaces, and it should be pretty easy to use the same idea for your function. (It just takes a little :while loop.) HTH --Benji Fisher
Re: Problems with Align.vim
On Tue, Oct 24, 2006 at 03:29:25PM -0700, Diwaker Gupta wrote: I'm using Vim 7.0.122 on Debian Unstable. I can send output of :version if needed. I've recently started having problems using Align.vim: Error detected while processing function AlignWrapperStart: line 28: E117: Unknown function: Align#AlignPush I've tried installing the script from both vim.sf.net as well as Dr. Chip's astro-page. Both of them fail with the same error. In the future, please give a link, such as http://mysite.verizon.net/astronaut/vim/vbafiles/Align.vba.gz Infact, when I extract the files from the vimball using ':so %', it generates weird file names: AlignMaps.vim?[[[1 AlignPlugin.vim?[[[1 cecutil.vim?[[[1 Any ideas? Thanks in advance, Diwaker There are a few problems here. First, it is too easy to miss the warning BE SURE TO GET THE LATEST VIMBALL PLUGIN BEFORE ATTEMPTING TO USE SCRIPTS UPLOADED ON OR AFTER AUG 1, 2006 posted on http://mysite.verizon.net/astronaut/vim/index.html . Ideally, all links to recent plugins would redirect to a page line http://mysite.verizon.net/astronaut/vim/newvimball.html?file=Align.vba.gz and this page would give links to the new version of vimball and the desired plugin. Second, the link to the new version of vimball is broken: http://mysite.verizon.net/astronaut/vim/tarfiles/vimball.vba.gz This does work: http://mysite.verizon.net/astronaut/vim/tarfiles/vimball.tar.gz The point is that the newest version cannot be extracted by the older version, so it is distributed as a tarball instead of a vimball. You can also get the new version of vimball from http://www.vim.org/scripts/script.php?script_id=1502 . The installation instructions there do not mention that the latest version should be extracted using tar. When installing vimball, do it in your $VIMRUNTIME directory. (For me, this means /usr/local/share/vim/vim70 , and I need to use su or sudo to install.) There may be an even newer version distributed with vim 7.1 or later, and you do not want this version in your personal runtime directory to be used when you upgrade. Third problem. This may have been my fault, but when I installed the vimball plugin, with $ cd /usr/local/share/vim/vim70 $ sudo tar xzf path/to/vimball.tar.gz some of the files had the wrong permissions, so I had to fix it with $ sudo chmod a+r autoload/vimball.vim doc/pi_vimball.txt plugin/vimballPlugin.vim Like you, I had some wrong files installed at this point. I cleaned up with $ cd ~/.vim $ rm -i */*[[[* HTH --Benji Fisher
Re: jumplist/mark ' problem
On Tue, Oct 24, 2006 at 07:03:37PM -0700, Hari Krishna Dara wrote: I am facing a weird problem with the '' marker not getting set. Here is what I am doing, but this may be more generic than what I do, but this scenario is the most I use: - While on an identifier, use ^W^] to jump to the id definition. - Mark the line, say, ma - move a few lines up using k, say kkk - yank the range using y'a - Try to go back to the original position using '' Instead of cursor going back to the original line, it goes to the start of the file. This behavior is really irritating, as I end up doing this sequence repeatedly and it surprises me everytime. I have a feeling that this wasn't happening in prior versions. Is there a flag that that I might have changed? I think it will work the way you want if you stay within the same file. Looking quickly, I do not see it stated explicitly, but I think all of the other maps are local to the file (or maybe buffer), like 'a to 'z . Only 'A to 'Z and '0 to '9 move between files. In particular, '' will jump to the '' mark in the current file. You can use C-O or C-T to jump back to your previous position. To reproduce: :help '' Then follow the links to :keepjumps (in the same file) or restore-position (different file) and try '' or C-O in either case. HTH --Benji Fisher
Re: Bold font in OS X GUI?
On Wed, Oct 25, 2006 at 03:58:36PM +1000, Peter Hodge wrote: Hello, I am having trouble with OS X GUI, none of the highlighting is in Bold. Is this a Bug, or does Bold font just not work in the OS X gui? regards, peter There are known problems with fonts in the OS X GUI, but it is hard to find a volunteer to work on this problem. If none of the suggestions at http://macvim.org/OSX/index.php#FAQ (item #2) then you will have to wait until someone fixes the problem. HTH --Benji Fisher
Re: inserting backticks
On Wed, Oct 25, 2006 at 12:02:51PM +0200, Alexander 'boesi' Bösecke wrote: Hi Am 25.10.2006 10:32:47 schrieb A.J.Mechelynck: Unless you have a mapping for something starting with a backtick, Well according to :verb imap ` I don't have one. Did you also try :verbose imap Space :verbose iabbrev ` and so on? I suggest typing CTRL-V before the back-tick and before the space. Just to be sure, I would also try starting vim with $ vim -u NONE If that solves the problem, then you have some mapping, abbreviation, or *something*. If it does not solve the problem, then PEBKAV (Problem Exists Between Keyboard And Vim). HTH --Benji Fisher
Re: inserting backticks
On Wed, Oct 25, 2006 at 09:29:45AM +0200, Alexander 'boesi' Bösecke wrote: Hi When inserting a backtick (`) I normally type `space. But sometimes nothing happens... When I enter a 2. space, I get a space. I can enter as many spaces as I want, but I get no backtick. When I type a letter, eg. d, _than_ I get `d at the current cursor position. Wnen I type a 2. ` instead of d, I get ``. And really strange is that I can't reproduce this behaviour constantly. Eg. starting with an empty Vim (no file opened) and the backtick+space works as it should. Starting an empty Vim again and it doesn't work... I've tested it with python and tex files. Sometime `space produce a backtick, but mostly not. Well I could use a mapping like this: imap `space ``C-Ox But this is IMHO a bit too hackish. I'm using gVim 7 on WinXP. The Console-Vim seems to work correctly. Is this a matter of my configuration? Or where is the ` waiting? On Wed, Oct 25, 2006 at 08:23:40PM +0200, Alexander 'boesi' Bösecke wrote: Hi Am 25.10.2006 15:08:23 schrieb Benji Fisher: [snip] I suggest typing CTRL-V before the back-tick and before the space. Just to be sure, I would also try starting vim with $ vim -u NONE Both don't change anything. But as I've noted earlier, console-vim doesn't have this problem - only gvim. Sorry, I did not read the original post carefully the first time. If it does not solve the problem, then PEBKAV (Problem Exists Between Keyboard And Vim). Hmpf Can somebody at least confirm my problem? The mapping from my first mail solves it, but I'd like to know the cause... I do not see any such problem using gvim on Linux. If you want someone to try to reproduce the problem, we need more information. Where did you get your copy of vim; or, if you compiled yourself, how did you do it? (In the first case, please give a link to the download site. In the second case, we need to know patch level, which compiler, what options you used to compile, etc.) If in fact PEBKAV, then it probably makes a difference what language/localization you have for WinXP. I still suspect that a mapping or abbreviation is involved. Especially since you mentioned tex: have you installed latex-suite? If so, then :set ft=tex :imap ` should show that there is a mapping defined by plugin/imaps.vim . Even with this, I cannot reproduce the problem, though. If there is no problem with console-vim, then I want to know the result of starting gvim while skipping all your startup files. I am not sure of the right syntax from an XP command line, but something like $ gvim.exe -u NONE -U NONE should do it. If you still see the problem after starting gvim this way, then I will be convinced that there is no errant mapping causing problems. (I think the -U NONE is redundant, but it does not hurt much to leave it in.) HTH --Benji Fisher
Re: Need to write a language
On Wed, Oct 25, 2006 at 06:42:15PM -0400, Karl Guertin wrote: On 10/25/06, Billy Patton [EMAIL PROTECTED] wrote: My questions. 1. Can vim be configured to automatically start in edit mode? Yes, but I forget what the setting is, you can just push it into insert mode when you enter a buffer if nothing else. Add :set insertmode :help 'insertmode' 3. Can vim do word completion? Many types. :help completion Especially read :help 'complete' :help 'dictionary' You may also find something worth borrowing in my word-completion plugin: http://vim.sourceforge.net/scripts/script.php?script_id=73 4. Can vim offer all possible spellings for partial word completion? It does by default and you can view them as a menu if you're using Vim 7. If you want to provide a list of possible words to be completed, it can be done by creating a ctags file. :help completeopt I am not sure why you suggest a tags file, unless you intend :set complete=t I was thinking of :set complete=k/path/to/babylanguage.txt If the answer to most of qeustion above is yes 5. Can I do the programming? I do perl, c, c++, csh and sh programming. Most vim scripting is done in vimscript, which I consider to be fairly close to bash/sh. You can also do scripting in Python. I'm not sure about the perl interface. I suggest looking at some of the files in $VIMRUNTIME/plugin/ to get an idea of what you can do with a vim script. Then it helps to look at the list of built-in functions, :help functions HTH --Benji Fisher
Re: Only curiosity: Optimizing a vimtip (modified)
On Tue, Oct 24, 2006 at 08:47:46AM -0400, Dave Roberts wrote: Meino Christian Cramer wrote: Hi, I read of a vimtip, that one can move/copy lines of a text which match a cvertina pattern to line 0 (top) of the text. This is a nice trick to gather material for a kinda quick'n'dirty Table of contents it has one drwaback: The copied lines are in reversed order. Surely it is possible to write a fairly simple function with a counter, which keeps track to what line something is copied. But it would be interesting whether it is possible to achieve this with more condensed tricks without writing a function in beforehand. Thank you very much for any idea/hack/trick in advance! Keep hacking! mcc You could use the reverse lines trick to reorder the copied lines. Use the following to put the lines at the top of the file: :let cnt=0|g/(regexp)/copy 0|let cnt=cnt+1 Then re-reverse the copied lines at the top of the file: :exe 1,.cnt.g/^/m0 Easy enough to put that into a function passing the 'regexp' to it... - Dave Another possibility is to copy all of the lines to the end of the file (:copy $ instead of :copy 0 ). Then, having saved line($) before adding lines, you know how many lines to :move to the top. plug Some time ago, answering a similar question on this list, I wrote the Pippo() function and added it to foo.vim, my file of example vim functions: http://www.vim.org/script.php?script_id=72 This is more of an index function than a table-of-contents function: it searches for words (matching a given regular expression) and appends them to the end of the file, one per line. /plug HTH --Benji Fisher
Re: Vim function to toggle Ruby block type
On Tue, Oct 24, 2006 at 10:29:43PM +1000, Mark Woodward wrote:
Hi everyone,
has anyone written a vim function to toggle/convert ruby block types?
ie:
{ |x| puts x }
toggled becomes:
do |x|
puts x
end
toggled becomes:
{ |x| puts x }
again
So if the cursor is within the {} or between the do/end hitting a mapped
'toggle key' will convert one to the other.
If not any ideas what would be the best way to attack this? Thought I'd
ask before I try to reinvent the wheel.
--
Mark
If you use the matchit plugin (:help matchit-install) then this may
be easier. If the cursor is inside the block (either the multi-line
do/end block or the one-line {/} block) then you can use the [% motion
to go to the start of the block. Then you can enter Visual mode (v or
V) and use % to get to the end of the block. I suggest doing this
manually, then letting your function/command/menu item take over, but
you could also do it inside your function with something like
:normal [%vg%
While testing this, I noticed a bug in the [% motion that is
triggered by languages (like ruby) that have escaped colons in their
matching patterns. If you want to use [% with ruby, first get the
latest matchit.vim from
http://www.vim.org/scripts/script.php?script_id=39 .
HTH --Benji Fisher
Re: [PATCH] zip plugin: support any filename
On Mon, Oct 23, 2006 at 10:42:41PM +0200, Martin Stubenschrott wrote: On Mon, Oct 23, 2006 at 10:02:48PM +0200, [EMAIL PROTECTED] wrote: I'm using this to edit firefox extensions directly inside their jar files. I'm also attaching a patch that adds the required associations (jar and xpi, I'm sure there are more). I exactly wanted to do the same, but it didn't work. Hopefully your patch gets accepted (didn't test it myself yet though). The patch applies to runtime files, so you should be able to apply it without having to re-compile. HTH --Benji Fisher
Re: REQ: gq and swap file stuff?
On Sat, Oct 21, 2006 at 10:40:32PM +0200, Pero Brbora wrote: Hi ... When there is no empty lines bellow the long line (at the end of file) you can't format the line using gq option... I agree with one of the other replies: gqq works for me. Also it would be less annoying when opening file and swap file is found (another vim is running in this case). Then you click on Quit and you have to press a key! IMHO annoying... This stands for gvim 7.0.109 on Windows 2000, MinGW compile (gcc 3.4.2)... I did the compiles but this was in previous releases of gvim I didn't compile by myself... One more thing. Syntax highlighting doesn't work well when fdm=marker is set... I have encountered this mostly on shell scripts (bash). For example when you unqoute string text bellow highlights as string but, doesnt unhighlights when you qoute it agsin. You should mention this to Dr. C, who maintains the syntax file (in this case $VIMRUNTIME/syntax/sh.vim). First, check his web site in case there is a newer version of the syntax file that already fixes the problem: http://mysite.verizon.net/astronaut/vim/index.html#vimlinks_syntax If not, try e-mailing him directly. Both the web site and his e-mail address (the latter somewhat obfuscated) are in the comments at the top of the syntax file. HTH --Benji Fisher
Re: getchar() trick with recursive expr map
On Thu, Oct 19, 2006 at 11:26:53PM -0700, Hari Krishna Dara wrote: [snip] imap buffer silent expr F12 Double(\F12) function! Double(mymap) try let char = getchar() catch /^Vim:Interrupt$/ let char = \Esc endtry exec BPBreakIf(char == 32, 1) if char == '^\d\+$' || type(char) == 0 Don't you want =~ above instead of == ? let char = nr2char(char) endif It is the ascii code. if char == \Esc return '' endif redraw return char.char.\C-R=Redraw()\CR.a:mymap endfunction function! Redraw() redraw return '' endfunction You can do almost eanything that you can do normally in an insert mode, press BS, C-U etc. Hope someone finds this useful. I will also post this as a tip. How does this approach affect the undo history. That is, if I start in Normal mode and type AfooEsc (without the quotes) can I undo the append with u and repeat it with .? HTH --Benji Fisher
Re: Plain TeX support ?
On Mon, Sep 25, 2006 at 08:07:22PM +0200, Meino Christian Cramer wrote:
[snip]
After I wrote my first TeX-text without Emacs/AucTeX spontaneous I
would say the following things are missing:
A Keystrokes to insert {\bf X }, {\it X \/} and such where X marks the
cursor position after doing the keystroke.
B Interface to run TeX and a viewer (configurable) on the file one is
editing which ensures, that the file on the HD is uptodate.
C Defintions to automatically map word to ``word'' and to remap
- in my case - german umlauts to the TeX-commandsequences. This
should be done for any non-ASCII-character. Most of the bugs I had
to remove while trying to tex my file were of such kind.
I have not proofen that this is not already implemented, I only read
the few lines of the help text for ft-tex-plugin. And didn't fiddle
with quickfix and such. May be quickfix can be misused for texing ?
Dont know.
I am sorry to have left this alone for so long. I have been busy.
I spent too much time, shortly after the last note on this thread,
trying to get the 'errorformat' right for plain TeX, then I did not have
time to let you know about it.
I just posted a preliminary version of plaintex support at
http://vim.sourceforge.net/scripts/script.php?script_id=1685
Please try it out. If I get any feedback (from you or others) then I am
more likely to improve it.
A. I chose C-B for \bf and C-T for \it . (Why not C-I? Because
vim sees that as a Tab, and I do not want to remap that.) In Insert
mode, you get {\bf }++ or {\it \/}++, with the cursor inside the
braces, and C-J will jump to the ++ marker. In Visual mode, you get
the Visual selection wrapped in {\bf and } or {\it and \/}.
In Normal mode, the word under the cursor is wrapped.
If you have similar requests, they are easy to add.
B. Next version. This is not too hard to do. What viewer do you use?
xdvi maybe?
C. I map (in Insert mode) to produce either `` or '' (or if it is
after a \ or in Math mode). Do you also want something, maybe C-Q, to
act like C-B, so that it will work in Normal, Visual, and Insert
modes?
I have not tried it, but there is already a script that translates
various non-ASCII characters into TeX commands. I think it does the
translation when reading and writing the file. Unfortunately,
www.vim.org is not responding right now, so I cannot give you a pointer.
[snip]
PS: By the way: Are you using Ruby, Benji? I know The principle of
least surprise from programming Ruby...
No, I do not use Ruby. I think the principle is older than that
language.
HTH --Benji Fisher
Re: Plain TeX support ?
On Fri, Oct 20, 2006 at 03:31:33PM -0400, Benji Fisher wrote: B. Next version. This is not too hard to do. What viewer do you use? xdvi maybe? I forgot: you mentioned Kdvi in an earlier post. I have not tried it, but there is already a script that translates various non-ASCII characters into TeX commands. I think it does the translation when reading and writing the file. Unfortunately, www.vim.org is not responding right now, so I cannot give you a pointer. The site is back up, now. Both http://vim.sourceforge.net/scripts/script.php?script_id=284 and http://vim.sourceforge.net/scripts/script.php?script_id=1262 seem to do what you want. HTH --Benji Fisher
Re: path is changing mysteriously...
On Thu, Oct 19, 2006 at 07:46:04PM +0200, Yakov Lerner wrote:
On 10/19/06, Lev Lvovsky [EMAIL PROTECTED] wrote:
For some reason, with the many buffers that I have open, the path
that a particular file takes, is instead of the initial directory
where I started from (which is what I want), the directory that the
file resides in. Trying :cd, or :lcd only temporarily changes
it, and in a few seconds it changes back to the directory that the
file actually resides in - what's going on?
'set acd' ('set autochdir') does it. Try :set noacd
If that doesn't help, this means you have autocmd that
does it.
I suspect you are right, but then the question is where 'acd' was
set. The way to find out is
:verbose set acd?
It is also possible that an autocommand (perhaps from a system vimrc
file) is causing the directory changes.
HTH --Benji Fisher
Re: checking for cp in plugins
On Thu, Oct 19, 2006 at 11:43:22PM +0200, Yakov Lerner wrote: I am making a plugin which naturally requires nocp because it uses keys in lhs and rhs of mappings it defines. What if that plugin sees cp, what it shall do ? Shall I save old value of cp, then temporarily 'set nocp', define mappings, then restore cp ? Is this OK ? Or it shall check cp and silently not load if it's cp!=0 ? Or it shall not check cp and define bogus mappings and to hell with checking cp ? Yakov Have a look at some of the default plugins. Exit quickly when: - this plugin was already loaded (or disabled) - when 'compatible' is set - the CursorMoved autocmd event is not availble. if exists(g:loaded_matchparen) || cp || !exists(##CursorMoved) finish endif let g:loaded_matchparen = 1 if v:version 700 echohl WarningMsg | echo ***netrw*** you need vim version 7.0 for this version of netrw | echohl None finish endif let s:keepcpo= cpo set cpovim [snip] let cpo= s:keepcpo unlet s:keepcpo The matchparen plugin works automatically, which seems likely to annoy someone who wants vim to be 'compatible', so it makes sense for it to bail out. The netrw plugin provides new commands, so it is less likely to annoy. So one bails out when 'cp' is set, and the other saves and restores. HTH --Benji Fisher
Re: filename completion not recognising pdf's
On Thu, Oct 19, 2006 at 11:57:22PM +0200, Eric Smith wrote: Vim does not complete pdf files with C-X C-F. Is there a place where I can alter this (mis)behavior? -- Eric Smith It does for me. Two options that may affect this are 'suffixes' and 'wildignore'. The first just gives listed suffixes lower priority, and the second removes them completely. :help 'suffixes' :help 'wildignore' :verbose set suffixes? wildignore? HTH --Benji Fisher
Re: search visual block
On Wed, Oct 18, 2006 at 12:28:28PM +0200, Robert Cussons wrote:
Jean-Rene David wrote:
[snip]
-- cut here ---
Search for visually selected text {{{
From an idea by Michael Naumann, Jürgen Krämer.
function! VisualSearch(direction) range
let l:saved_reg = @
execute normal! vgvy
let l:pattern = escape(@, '\\/.*$^~[]')
let l:pattern = substitute(l:pattern, \n$, , )
if a:direction == 'b'
execute normal ? . l:pattern .
else
execute normal / . l:pattern .
endif
let @/ = l:pattern
let @ = l:saved_reg
endfunction
vnoremap silent * :call VisualSearch('f')CR
vnoremap silent # :call VisualSearch('b')CR
-- cut here ---
This sounds brilliant Jean-Rene, I put it into my .vimrc, but it doesn't
seem to work, I did notice that between the if and else there are
which just act as comments as they are on newlines, didn't know if this
was just my text wrapping, so I tried putting them on the line above,
both with a space between or not, didn't know if that might be cause but
that didn't seem to help either. Sorry I may be missing something
obvious, but I'd like to get this to work as it seems very useful.
I was selecting text in visual mode, then pressing / or ? and I just get
the normal action of pressing / or ?
I think the original included raw CR characters in the two :execute
lines. Both are intended to end with ^M (which is how they appeared
in my copy of Jean-Rene's note). I think your e-mail client broke the
lines, leading to syntax errors.
I try to avoid such problems by not including raw CR, ESC, etc.
characters in my vim scripts. I suggest replacing the two :execute
lines with
execute normal ? . l:pattern . \CR
and
execute normal / . l:pattern . \CR
HTH --Benji Fisher
Re: VIM help for normal text files with extension .lib (on UNIX)
On Sun, Oct 15, 2006 at 11:37:33PM -0700, Kunapuli, Udaykumar wrote: Hi, I am using VIM 7.0 on UNIX. I have files with extension .lib (*.lib files). VIM automatically thinks that it is a Cobol filetype. The file has nothing to do with Cobol. I have tried setting the following things in my .vimrc. au BufNewFile,BufRead *.lib set ft=text au BufNewFile,BufRead *.lib filetype off au BufNewFile,BufRead *.lib filetype plugin indent off The first line should be enough. The 'filetype' (abbreviated 'ft') option is local to the buffer and should be set each time you edit a *.lib buffer. The :filetype command is global. If you want to turn off all filetype detection, add the line filetype off to your vimrc file. I cannot think of any situation in which it makes sense to put it in a BufNewFile,BufRead autocommand. I could take away the glaring syntax highlighting (red background on all text!!!), but it was not of any help in terms of searching and regular expression. In ordinary text files, underscore (_) is considered as a legal part of the word (or the regular expression \w). However in files with extension .lib, VIM seems to consider underscore (_) as a special character. Is there anyway for me to make *.lib files to be treated as ordinary text files by VIM for everything (syntax highlighting, indenting, regular expression searching etc.)? The problem is that autocommands are executed in the order in which they are defined. Apparently, the autocommand in your vimrc file, setting ft=text, comes after the one that sets ft=cobol. Thus things happen in this order: :set ft=cobol :source $VIMRUNTIME/syntax/cobol.vim :setlocal isk=@,48-57,- :set ft=text and nothing undoes the 'iskeyword' setting. The simple solution is to make sure that your autocommand comes before any filetype on or source $VIMRUNTIME/vimrc_example.vim in your vimrc file. A more robust method (since it does not rely on the order of lines in your vimrc file) is to use either method A or C from :help new-filetype I tried editing the filetype.vim in the runtime directory and commenting the portion with the .lib extension. But it didn't work. That is not recommended. If you fix problems by editing things under $VIMRUNTIME, then you will have to remember to fix them each time you upgrade to a new version of vim. In the long run, it is easier to fix things in your own vim directory. Thanks, Uday HTH --Benji Fisher
Re: gvim-7-0-118.exe virus found??
On Mon, Oct 16, 2006 at 03:08:58PM +0800, Edward Wong wrote: Dear all, Just tried downloading gvim-7-0-118 from sourceforge and AVG detects there is a trojan virus. Can it be a false alarm? Ed Please be more specific. Can you give a link to the archive you downloaded? Or did you use CVS or SVN (and , if so, what command did you use)? HTH --Benji Fisher
Re: Undo between sessions
On Mon, Oct 16, 2006 at 02:31:40PM -0700, Max Dyckhoff wrote: I am almost certain that this has been asked before, and I am almost sure that the answer is no, that would be silly, but I can't find anything in the archives, in :help or on Google in general. I am suffering the aftereffects of a bout of flu today, so perhaps I'm just being bad at searching. Basically, is there any (easy) way of preserving the undo stack between sessions? I typically work with half a dozen tabs and 20-30 files open at any one time and whenever I need to reboot my machine then I do a :mksession and reload it when I come back. It is ridiculously useful, but I would love if the undo was stored too. Cheers, and sorry for asking this over-asked question again. Max Have you tried saving the swap file? While editing foo.txt, that file would normally be .foo.txt.swp. Normally, it is deleted when you quit vim. If you save and restore the swap file (and maybe also the version of the file before you started editing it) then I think you will be back where you started. :help swap-file Disclaimer: I have not tried this myself, and you *really* want to test this idea before using it on files that matter! HTH --Benji Fisher
Re: Auto-guessing file encoding and integration with Vim (works for Latin1, GBK, and Big5 now)
On Sat, Oct 14, 2006 at 03:36:19AM +0200, A.J.Mechelynck wrote: Yongwei Wu wrote: Hi Benji, On 10/12/06, Benji Fisher [EMAIL PROTECTED] wrote: Perhaps you can package your vim functions as a plugin so that they can be used without adding anything to the vimrc file. :help write-plugin I thought of doing this, but this seems far too personal. My script works best on Simplified Chinese locale, with the ability to tell between utf-8, gb2312/gbk, big5, and latin1. Some small tweaks are probably needed when the environment or requirements are different. So maybe it is more suitable to be a tip. If it is only in the mailing list, it can quickly get lost. So I will consider your suggestion and try to do something. I suspect you are not the only person using Vim to edit Simplified Chinese; furthermore, I suspect that your script might be useful, if only as a source of inspiration, to someone wishing to discriminate between the various encodings used for the other CJK languages, viz. Traditional Chinese, Japanese and Korean. IMHO it would be better as a script than as a tip because it is easier to upload new versions of a script. Or maybe a script to do the job and a tip explaining to Vim users, in pain language, what to look for when trying to guess the encoding for CJK text files. Nothing is ever lost, but it is harder for others to find it in the archives of the mailing list than in the tips database, if only because there are a lot more e-mails on the list than there are tips. So it really comes down to a question of convenience. Similarly, if the scripts are in a tip, then users have to copy them into a file to be :source'd, which is less convenient than having them in a plugin. As Tony points out, it is easier to update scripts than tips. A reader may have to read through the comments section of a tip to find changes that (s)he will want to apply: not at all convenient! Of course, updating the script means more work for you, but it gives you an opportunity to implement the tweaks needed for other environments as you get feedback from other users. Of course, the only reward you get for any of this effort is the satisfaction of helping others in the vim community. --Benji Fisher
:diffsplit | verbose set fdm?
While replying to a post on the vim users' list, I noticed a slight problem. The diff commands set some options, but this is not reported with verbose set. For example :e foo.txt :set fdm=marker :diffsplit bar.txt :wincmd wback to foo.txt :verbose set fdm? foldmethod=diff :only :verbose set fdm? foldmethod=manual --Benji Fisher
Re: diffoff
On Fri, Oct 13, 2006 at 10:47:33AM +0100, Vigil wrote: Is it on the to-do list to make diffoff restore from previous values rather than default ones, or is there already an option somewhere that toggles the behaviour? AFAIK you have to save the options before starting diff mode and restore them later. At least, that is the answer to the question you asked. Maybe if you give more detail about what you are trying to do, someone can give a more helpful answer. I had a file open with foldmethod=marker, then I :vimdiff'd it against another file, made my changes to the original file, then :q'd the second file and :diffoff'd the first, but it was still using foldmethod=diff. I do not think that :vimdiff is a command. Did you start a new instance of vim from the shell with $ vimdiff or did you use some other command within vim? I tried :tab sp foo.txt :set fdm=marker :diffsplit bar.txt do some editing ending in bar.txt :wq :diffoff :set fdm? foldmethod=manual This is the expected behavior. HTH --Benji Fisher
Re: Local scope ?
On Tue, Oct 03, 2006 at 10:00:51PM -0700, Hari Krishna Dara wrote: Yegappan already answered your question. However, in case you want to do the whole of it in the same function, I recommend the below pattern: let _ic = ignorecase set noic try do something finally let ignorecase = _ic endtry So far, I have been too lazy to use try/finally/endtry. I guess the point is that if the do something generates an error, then the option is still restored? (Of course, my vim scripts never generate errors. ;) Another refinement is to avoid setting the global option. Use l:ignorecase to access (read and write) the local value of the option. If the option happens to be global, I do not think using the l: prefix will cause any problems. HTH --Benji Fisher
Re: Auto-guessing file encoding and integration with Vim (works for Latin1, GBK, and Big5 now)
On Sat, Oct 07, 2006 at 12:37:33AM +0800, Yongwei Wu wrote: This is a report of what I have already achieved. If you are dealing with more encodings than the fileencodings option can handle, esp. if you read and write Simplified and Traditional Chinese, please read on. I write English almost exclusively, so this is not something I will use. If this is useful for others (and I expect it will be) then I suggest posting it as a script at http://www.vim.org/scripts/index.php . In the description, you can post a link (as snipped below) to tellenc. Perhaps you can package your vim functions as a plugin so that they can be used without adding anything to the vimrc file. :help write-plugin HTH --Benji Fisher
Re: BOF
On Fri, Oct 06, 2006 at 02:49:57AM -0500, Bill McCarthy wrote: Hello Vim List, I listened to Bram's BOF this past weekend. I still don't know what BOF means. From Wikipedia: BoF is an acronym for: Basic Oxygen Furnace Birds of a Feather beginning of file Body-on-frame Breath of Fire [snip] I would guess Birds of a Feather. Which is it? Yes, I think that is right. It is used in the aphorism Birds of a feather flock together. At a large meeting, a group of people with a common interest (or some other commonality) may be referred to as BOF and hold a BOF session. HTH --Benji Fisher
Re: number of folds in foldtext
On Sun, Oct 08, 2006 at 05:49:38PM +0200, Eric Smith wrote: Is it possible for foldtext to show the number of the fold block. For example there are n paragraphs in a document and folding is by expression defined as a blank line. I want the number of the paragraph to show in the foldtext. This is just proof of concept: set foldtext=MyFoldText() function MyFoldText() let parcnt = 0 execute v:foldstart . , . v:foldend . g/^$/let parcnt += 1 return parcnt . paragraphs endfunction You might want to return something like substitute(foldtext, :, , . parcnt . paragraphs:, ) (untested). HTH --Benji Fisher
Re: diffoff
On Tue, Oct 10, 2006 at 12:29:51PM +0100, Vigil wrote: The :diffoff command resets the relevant options to their default value. This may be different from what the values were before diff mode was started, the old values are not remembered. Is it on the to-do list to make diffoff restore from previous values rather than default ones, or is there already an option somewhere that toggles the behaviour? AFAIK you have to save the options before starting diff mode and restore them later. At least, that is the answer to the question you asked. Maybe if you give more detail about what you are trying to do, someone can give a more helpful answer. HTH --Benji Fisher
Re: select/insert switching
On Thu, Sep 28, 2006 at 10:31:33PM +0200, A.J.Mechelynck wrote: DISCLAIMER: the following is untested, I may have goofed. If by command mode you mean what Vim documentation calls Normal mode: Like you, I prefer to call it Normal mode. That is how it is usually (almost always?) called in the docs. It is acceptable (and reasonable, especially for newbies) to call it Command mode: :help command-mode 1. Esc already switches from Insert to Normal. If you are dead set on prefixing it by Ctrl-O you can use If one sets the 'insertmode' optionm, then Esc has no effect in Insert mode (except for a slight delay on some terminals) and actually goes to Insert mode from Normal mode if you manage to get there. HTH --Benji Fisher
Re: BUG: inputdialog() does not resize on Mac
On Thu, Sep 28, 2006 at 01:27:26PM -0400, David Fishburn wrote: Running this command: echo inputdialog(Choose # of database type:\n1. None\n2. ASA\n3. MYSQL\n4. SQLSERVER\n5. DB2,1,-1) On Windows and Linux will correctly size the inputdialog box so that the entire text is displayed. On the Mac platform the inputdialog does not size appropriately and will cut off lines 3-5. :ver VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 27 2006 15:36:56) MacOS X (unix) version Included patches: 1-110 Compiled by [EMAIL PROTECTED] Normal version with Carbon GUI. Features included (+) or not (-): [snip] I can confirm the problem. I am cc'ing the vim-mac list. Maybe someone there can look into it. HTH --Benji Fisher
Re: Non-intuitive default behaviour of gI
On Tue, Sep 26, 2006 at 09:14:46PM -0700, Gautam Iyer wrote: Hi All, I noticed that pressing gI inserts text at column 1 of the current line (as documented in the help). However given the commands gj and gk, wouldn't it be more intuitive to have gI insert text at the first screen column? I guess I can just do nmap gI g0i in my ~/.vimrc, but I though I would point out the inconsistent behaviour. Unless I am missing something, the current meaning of gI is not very useful. Is there any difference between [count]gI and 0[count]i ? (Note that both have the same number of key strokes.) Unfortunately, I think it is too late to change it to something like g0i, which would save a key stroke. I am not convinced by the consistency argument. IIUC, g is not a Normal-mode command in traditional vi (and it may be the only alphabetic character with this distinction.) Thus g is used in vim for a wide variety of commands, with gchar usually meaning some variant of char. See :help g for a list. HTH --Benji Fisher
Re: escape button to alt space
On Tue, Sep 26, 2006 at 05:27:53PM +0200, Horvath Adam wrote: Hi, I try to remap the escape button to alt+space combination to come back from insert mode to command mode. :map M-Space Esc It works, but: after hitting alt+space the cursor jump to the beginning of the next line. Why? It's really disturbing. How can I correct? Thanks, Adam I cannot test this because my windowing system grabs S-Space instead of letting vim (or gvim) handle it. Perhaps you have :map M-Space Esc instead of :map M-Space Esc (Note the trailing space!) That would explain it. HTH --Benji Fisher
Re: abbreviations + indent + movement commands
On Mon, Sep 25, 2006 at 08:29:02PM +0200, Kim Schulz wrote:
On Sat, 23 Sep 2006 17:08:39 +0200
Luc Hermitte [EMAIL PROTECTED] wrote:
[snip]
I guess it is in the mark for place of last change, but I just cant
get iabbrev to execute my movement command (other than using left
right up down). Is there any way to do this?
I finally converged to the use of search(), on a placeholder
regex-pattern. This way neither @/ nor the search history are messed
up by irrelevant patterns.
I have been playing around with the search() but I couldn't quite get
the hang of it.
Could you maybe give me an example on how to use it in relation to an
abbrev. What I tried was:
:iabbrev for( for
(!cursor!;+++;+++){\n+++\n}C-R=search('!cursor!',b)crc/+/ecr
but this inserts the linenumber where it finds the placeholder.
I would rather like it ro remove the placeholder and move the cursor
there.
any ideas?
That is because search() returns a value. It is a little odd that
you mix markers, using both !cursor! and ++, but I guess that makes it
easier to jump back to the first one. This is a little closer to what
you want:
:iabbrev for( for(!cursor!;+++;+++){\n+++\n}Esc:call
search('!cursor!','b')crcf!
Instead of using C-R= , I go into Command-Line mode with Esc: . I
added quotes around the 'b' flag for search() and I used f! (in Normal
mode) rather than /+/e because (1) it goes to the end of the first
marker, not the second and (2) it does not affect the search history.
(It does affect the , and ; commands, though.)
HTH --Benji Fisher
Re: Piping messages from ex commands into a new tab
On Mon, Sep 25, 2006 at 10:21:23PM +0100, Tom Carr wrote: I'm trying to pipe messages from ex commands (e.g. :map , :version) into a new tab. I've found http://vim.sourceforge.net/tips/tip.php?tip_id=95, but I was hoping for a better way. Ideally I would type something like :tabmesages :map and it would show :map in a new tab, without printing it to the screen, without waiting for additional keypresses, and without using up registers. You can turn the tip into a user-defined command, and if you are using vim 7, then you can avoid using a register. Personally, I would use a function to take advantage of local variables. fun! TabMessage(cmd) redir = message silent execute a:cmd redir END tab split put=message endfun command! -nargs=+ -complete=command TabMessage call TabMessage(q-args) HTH --Benji Fisher
Re: per-window search highlighting/colors
On Tue, Sep 26, 2006 at 12:27:39AM -0500, Brian Lewis wrote: I'm editing a file and open a preview window. When I search with /, I'd like the main window to show highlighted matches, but for the preview window not to. nohlsearch seems to be global, so I can't :setl nohlsearch in the preview window to get what I want. Maybe there's a way to modify color scheme settings in the preview window to make highlighted matches look as if they aren't highlighted? Thanks for the help. I cannot think of a way to do this. Syntax-based highlighting is local to the buffer, so it can be changed for the preview window, but the Search highlight group is not syntax-based. --Benji Fisher
Re: Turning abbreviations on and off
On Mon, Sep 25, 2006 at 12:58:51PM +, Yakov Lerner wrote:
On 9/25/06, Marius Roets [EMAIL PROTECTED] wrote:
I have a in my plsql.vim filetype plugin a lot of abbreviations to the
effect of :
iabbrev buffer then THEN
iabbrev buffer else ELSE
... So I was wondering if there was a
way where I could turn a set of abbreviations on and off, on the fly,
without reloading the buffer.
How about this:
function! MyAbbrevs()
iabbrev buffer then THEN
iabbrev buffer else ELSE
let g:myabbrev_set=1
endfunc
function! UnsetMyAbbrev()
iunabbrev bufferthen
iunabbrev bufferelse
let g:myabbrev_set=0
endfunc
function! ToggleMyAbbrev()
if exists(g:myabbrev_set) g:myabbrev_set
call UnsetMyAbbrev()
else
call MyAbbrevs()
endif
endfunc
call MyAbbrevs() initial setting
nmap F5 :call ToggleMyAbbrev()cr
Yakov
You forgot to set g:myabbrev_set to 0 or 1 in the ToggleMyAbbrev()
function. Easily fixed.
Here is another way to do it, using the new Dictionary type
introduced in vim 7.0. I have not tested this! I also use a single
function, with an argument, instead of three, and I think it makes more
sense to use a buffer-local variable to keep track of the state. This
version has the advantage that if you add an abbreviation, you do not have to
remember to add the unabbreviation in a different place.
let s:abbs = {'then': 'THEN', 'else': 'ELSE'}
Set action to 's' for set, 'u' for unset, or 't' for toggle.
fun! MyAbbrevs(action)
if (s:action == 's') ||
\ (s:action == 't' exists(b:myabbrev_set) b:myabbrev_set)
for [lhs, rhs] in items(s:abbs)
execute 'iabbrev buffer' lhs rhs
endfor
let b:myabbrev_set = 1
return 0
elseif (s:action == 'u' || s:action == 't')
for lhs in keys(s:abbs)
execute 'iunabbrev buffer' lhs
endfor
let b:myabbrev_set = 0
return 0
else unrecognized parameter
return 1
endif
endfun
HTH --Benji Fisher
Re: Plain TeX support ?
On Sun, Sep 24, 2006 at 04:37:16PM +0200, Meino Christian Cramer wrote:
[snip]
After I wrote my first TeX-text without Emacs/AucTeX spontaneous I
would say the following things are missing:
A Keystrokes to insert {\bf X }, {\it X \/} and such where X marks the
cursor position after doing the keystroke.
B Interface to run TeX and a viewer (configurable) on the file one is
editing which ensures, that the file on the HD is uptodate.
C Defintions to automatically map word to ``word'' and to remap
- in my case - german umlauts to the TeX-commandsequences. This
should be done for any non-ASCII-character. Most of the bugs I had
to remove while trying to tex my file were of such kind.
I have not proofen that this is not already implemented, I only read
the few lines of the help text for ft-tex-plugin. And didn't fiddle
with quickfix and such. May be quickfix can be misused for texing ?
Dont know.
Keep hacking and TeXing!
mcc
First, let me make some general remarks. With vim 7.0, we
introduced the file type plaintex. I made this the default, which
annoys some LaTeX users, so I am glad to know that there are still some
people out there who are using plain TeX (and editing with vim). I
maintain the ftplugin files for tex and plaintex, so I could add some
features there; but I try to be conservative, and follow the principle
of least surprise. So I prefer not to add too many key mappings to the
default ftplugin files (even smart quotes, which would be a *pleasantC*
surprise for most users).
A. What keys do you suggest for entering {\bf X } and {\it X \/}, and
do you really want a space after the X (cursor)? Perhaps using the
control or meta (alt) key? (I hope no one flames me for suggesting that
meta and alt are the same thing, when I really know better!) Do you
want a marker added so that you can jump out of the braces and continue
input? Presumably, whatever key you use to do {\bf X} in Insert mode
should also apply in Visual mode to insert {\bf before the Visual
selection and append } after it.
B. Another reply pointed out how to go in the other direction: from a
viewer (such as Yap) to the tex file. Of course, that depends on the
viewer. Note that you can start vim (not gvim) with the --servername
TEX option, provided that vim is compiled with the +clientserver option.
(This may not be the default if vim is compiled without GUI support.
Check the output of
:version
to see if is is there.)
It is certainly possible to compile using the quickfix commands. I
think the compiler plugin was not updated when the plaintex file type
was introduced, so you may have to do something like
:let b:tex_flavor = 'plain'
:compiler tex
:make %
I will test this, and I may add something to the default
ftplugin/plaintex.vim to make it easier to use.
Calling a viewer from withing vim is not hard to arrange, but it
depends on what OS you are using and what viewer. I think that
latex-suite already does this; maybe I can steal something from there.
C. I wrote a TeXquotes() function years ago, and it has been
incorporated into latex-suite. I will stick this, and some of the other
things I mentioned, into an ftplugin file and post it to vim.org . I
think latex-suite also has something for translating umlauts into teX
sequences.
HTH --Benji Fisher
Re: accents and tex
On Mon, Sep 25, 2006 at 12:04:45PM -0300, Matias Grana wrote:
On Tue, Sep 19, 2006 at 08:36:13AM -0400, Benji Fisher wrote:
On Mon, Sep 18, 2006 at 04:47:14PM -0300, Matias Grana wrote:
[snip]
excerpt of .vimrc -
augroup acentos
autocmd!
autocmd BufReadPost *.tex call Acentua()
autocmd BufWritePre *.tex exe normal mm | call Desacentua()
autocmd BufWritePost *.tex call Acentua() | exe normal `m
augroup END
[snip]
end of excerpt
[snip]
So far, so good. Now I have two problems:
1) the substitutions in the functions Acentua and Desacentua are saved
as changings. So undo commands mess with them. I'd like those changings
not to be seen by undo/redo commands. Is it possible?
I have not tried using this new vim-7 feature, but you might try
experimenting with :undojoin .
:help :undojoin
Seems to work, except for the fact that I can't do an :undojoin after an
undo. So I resort in the script to
a) do a dummy change
b) :undojoin
c) change the things I want to change
d) save the file
e) undo
Is it possible to do it without the dummy change?
As I said, I have not tried using :undojoin yet. At this point,
your guess is better than mine.
HTH --Benji Fisher
Re: sorting lines on lenght of characters
On Fri, Sep 22, 2006 at 07:59:37AM -0500, Tim Chase wrote:
Is it possible to sort lines on line length?
Shortes firsts, longest last?
If so how do you do this?
This is a common use of the decorate-sort-undecorate pattern.
You can do something like:
:%s/^/\=strlen(getline('.')).':'
:%sort n
:%s/^[^:]*:
[snip]
Depending on exactly what you want, you may prefer the following
method. This works only with vim 7! First, define a comparison
function based on the built-in strlen() function:
fun! MyCmp(a, b)
let x = strlen(a:a)
let y = strlen(a:b)
return (x == y) ? 0 : (x y) ? -1 : 1
endfun
Next, yank the lines you want into a variable. For the sake of
illustration, I will assume that you have marked them in Visual mode, so
I will use the Visual marks ' and ' :
:let a = getline(', ')
Finally, sort using the custom comparison functions and replace with
setline():
:call setline(', sort(a, MyCmp))
Yes, it can all be done in one line (exercise for the reader).
:help getline()
:help setline()
:help sort()
HTH --Benji Fisher
Re: Plain TeX support ?
On Sat, Sep 23, 2006 at 06:54:29AM +0200, Meino Christian Cramer wrote: Hi, Looking into :help \TeX\ does not that much information about the support of generating nice and find documents via plain TeX. Where can I get informations about what I can do/download/install/read to get a TeX-support a la AucTeX for Emacs ? Keep hacking! mcc That is an odd looking use of :help . Perhaps you meant to try :helpgrep \TeX\ instead? Note that the tex file type is for LaTeX and plaintex is used for plain TeX. See :help ft-tex-plugin if your plain TeX files are given file type tex. (I am assuming you are using vim 7. Correct me if I am wrong!) The default ftplugin/plaintex.vim does a few things: it sets options so that \input files will be recognized for include-file searches (:help include-search) and comments are recognized as such. What are the three features you miss most from AucTeX? HTH --Benji Fisher
Re: [BUG] with 'scrolloff' and Visual mode
I agree. I confirmed this odd behavior with $ gvim -u NONE -N :set so=4 and adding 100 lines to the buffer. As you say, for Step 1 it is important to click and drag; entering Visual mode with v or double-clicking does not reproduce the bug. For Step 2, I simply used H (without the quotes). HTH --Benji Fisher On Thu, Sep 21, 2006 at 04:32:31PM -0700, Max Dyckhoff wrote: Addendum: You actually have to drag with the mouse. Just double clicking on a word will not cause this erroneous behaviour. [1-4]-clicking and then dragging will make it happen. Max -Original Message- From: Max Dyckhoff [mailto:[EMAIL PROTECTED] Sent: Thursday, September 21, 2006 11:18 AM To: vim@vim.org Cc: [EMAIL PROTECTED] Subject: [BUG] Having just activated scrolloff=4 (which is great!) I have noticed one small bug in gvim. If you do a visual select using the mouse, then the scrolloff will be entirely ignored. 1. Select some text with the mouse. 2. Use the keyboard to move the cursor up to the top of the window. 3. Watch the cursor break through the 4 line buffer described by scrolloff. 4. Press escape. 5. Use the keyboard to move the cursor up or down. 6. Observe as the buffer jumps down to compensate for the scrolloff. Nothing major, but thought I would mention it! :) Max
Re: ctrl-v after a o command
On Thu, Sep 21, 2006 at 07:37:47PM -0700, lll wrote: Hello: I'm using VIM 7.0 in windows OS. Whenever I paste something using ctrl-v after typing o to insert on next line, the pasted string would not follow the indentation of the curser. It would paste the string from the beginning of the line. This is a new behavior compare to version 6.2. Does anybody know how to set the behavior back so ctrl-v will paste the string right where the curser is? I think this is a problem that has already been fixed. I assume you are using mswin.vim, which maps C-v in Insert mode to do a paste. Try :imap C-v When I do this, I get i C-VxBSEsc:call paste#Paste()CRgi If you are missing the xBS at the beginning of the mapping, that would explain the problem. You can fix it by getting the updated files $VIMRUNTIME/mswin.vim $VIMRUNTIME/autoload/paste.vim HTH --Benji Fisher
Re: --enable-pythoninterp gives unrecognized option `-pthread' on MacOS X
On Fri, Sep 22, 2006 at 09:53:06AM +0200, Christian Ebert wrote: Hello, I wanted to ask this for quite a long time (Vim 6.4 actually): When I compile with --enable-pythoninterp I get the following warnings: $ head -n5 vim-make.log Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src gnumake first CC=gcc -Iproto -DHAVE_CONFIG_H -I/sw/include-I/sw/include -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include -I/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/CORE -I/sw/include/python2.4 -pthreadsrcdir=. sh ./osdef.sh gcc: unrecognized option `-pthread' [...] etc. $ grep pthread vim-configure.log checking if -pthread should be used... yes checking for pthread_np.h... no $ ls -1 /usr/include/pthread* /usr/include/pthread.h /usr/include/pthread_impl.h $ vim --version VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 16 2006 00:05:46) Included patches: 1-109 Compiled by [EMAIL PROTECTED] Huge version without GUI. Features included (+) or not (-): [snip] +python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent [snip] system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc fall-back for $VIM: /usr/local/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -I/sw/include -I/sw/include-I/sw/include -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include -I/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/CORE -I/sw/include/python2.4 -pthread Linking: gcc -L/sw/lib -L/usr/local/lib -o vim -lncurses -liconv -L/sw/lib -L/usr/local/lib /sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a -L/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/CORE -lperl -lm -lc -L/sw/lib/python2.4/config -lpython2.4 -u _PyMac_Error This is on MacOS 10.3.9: $ uname -a Darwin krille.blacktrash.org 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc However it seems to work. But I can't be sure because I don't use 'pythoninterp' very often. Ideas anyone? I also have OS X 10.3.9, but I usually compile with the Carbon/Aqua GUI. I do not see pthread anywhere in the output of make. Where do your log files come from? Are you using a script to compile vim? If you tell me what you do to configure and build, I can try to reproduce the problem. HTH --Benji Fisher
Re: :helpgrep and 'ignorecase'
On Thu, Sep 21, 2006 at 10:16:16AM +, Yakov Lerner wrote: Looks like :helpgrep does not take 'ignorecase' setting into account. Is this by design ? :set ignorecase :helpgrep bufwrite E480: No match: bufwrite :helpgrep \cbufwrite ... now it finds matches ... Yakov Yes. I guess the reason is that 'ignorecase' is normally changed based on the file type, which should not affect how you interact with vim's help system. :help :helpgrep *:helpg* *:helpgrep* :helpg[rep] [EMAIL PROTECTED] [snip] 'ignorecase' is not used, add \c to ignore case. Example for case sensitive search: :helpgrep Uganda Example for case ignoring search: :helpgrep uganda\c Example for searching in French help: :helpgrep [EMAIL PROTECTED] HTH --Benji Fisher
Re: How pair g /g
On Mon, Sep 18, 2006 at 10:23:27PM +0200, Thomas Holder wrote:
Yakov Lerner wrote:
On 9/18/06, Thomas Holder [EMAIL PROTECTED] wrote:
Peng Yu wrote:
I'm writing some xml code in vim. In xml, there are some pair like
g /g. Would you please let me know how to pair them as { and
} such that I can us % to visit them?
source $VIMRUNTIME/macros/matchit.vim
let b:match_words = 'g:/g'
Hmm, the set of xml tags that I have is large and
basically open-ended. Do you mean, there is no method
to let plugin handle *any* ... tag, automatically ?
Isn't it unproductive to add manually each and every tag
to b:match_words ?
Try this:
let b:match_words = '\(\w\+\)\(\s[^]*\)\?:/\1'
This pattern also allows attributes inside the opening tag after some
space (but not newline). You could figure this out yourself if you would
read the help file for this macro.
Regards,
Thomas
Do not reinvent the wheel! Assuming that you have filetype support
enabled, i.e., something like
:filetype plugin on
in your vimrc file, $VIMRUNTIME/ftplugin/xml.vim will be :source'd
automatically whenever you edit an xml file. It already sets
b:match_words to something reasonable. To test, try
:e foo.xml
:echo b:match_words
If you want to use matchit rather than default % pairing all the
time, add something like
source $VIMRUNTIME/macros/matchit.vim
or
runtime macros/matchit.vim
to your vimrc file.
Historical note: Johannes Zellner suggested adding support for
variable matching pairs (such as matching anything with /anything in
*ML) shortly after I started maintaining the script. Implementing that
suggestion was complicated enough that I started to think of it as my
script, rather than just something I had tinkered with.
HTH --Benji Fisher
Re: accents and tex
On Mon, Sep 18, 2006 at 04:47:14PM -0300, Matias Grana wrote: [snip] excerpt of .vimrc - augroup acentos autocmd! autocmd BufReadPost *.tex call Acentua() autocmd BufWritePre *.tex exe normal mm | call Desacentua() autocmd BufWritePost *.tex call Acentua() | exe normal `m augroup END [snip] end of excerpt [snip] So far, so good. Now I have two problems: 1) the substitutions in the functions Acentua and Desacentua are saved as changings. So undo commands mess with them. I'd like those changings not to be seen by undo/redo commands. Is it possible? I have not tried using this new vim-7 feature, but you might try experimenting with :undojoin . :help :undojoin 2) Although I put a mark on the line I am at, and then go back to it in BufWritePost, sometimes the window scrolls a few lines, which is not very nice. Is it possible to save the first line appearing in the window, and, at the end of the saving process, end up seeing exactly the same lines I was seeing before? :help winsaveview() (This is also a new feature in vim 7.) For something that works with older versions of vim, you can see how this is done in the Mark() function defined in foo.vim, my file of example vim functions: http://www.vim.org/script.php?script_id=72 HTH --Benji Fisher
Re: How does vim recognize file type?
On Mon, Sep 18, 2006 at 12:50:59PM +0200, Andrea Spadaccini wrote: Ciao Samuel, In your vim folder you probably have a filetype.vim which has a couple of lines per file type to detect when an extension is opened or created, and set the filetype automatically. Thanks, I modified it and it works like a charm! :) The standard advice is *not* to modify any files under $VIMRUNTIME, including the filetype.vim that comes with the standard vim distribution. One reason is that any changes you make will be lost when you upgrade to a new version of vim. If your files end in .tex and are not being recognized as LaTeX (i.e., the 'filetype' option is not being set to tex) then the simplest solution is probably to add the line let tex_flavor = latex to your vimrc file. See :help ft-tex-plugin HTH --Benji Fisher
Re: Convert to HTML patch. Opinions / Testing.
On Fri, Sep 15, 2006 at 01:37:57PM +0100, Edd Barrett wrote: On 15/09/06, Benji Fisher [EMAIL PROTECTED] wrote: I think the decision of whether to include the p tags should be based on principles of logical mark-up: are these naturally paragraphs? This depends upon if you are writing a book or some code. The spacing of the lines should be governed by the whitespace of the sourcecode, and I cant think of how you define a paragraph of code. But consider this: The whole file is contained in a p, so the gap introduced (if any) will either be right at the top or bottom of the code (or both?), neither of which are benificial to the format of the page. Agree? I agree that enclosing the whole file in p and /p tags is not very helpful. HTH --Benji Fisher
Re: Matchit's match_words Question
On Tue, Sep 12, 2006 at 07:30:55PM -0500, Bill McCarthy wrote: Thanks, Tony. I was just getting ready to respond to myself with another solution I found with a hint from the help file: let b:match_words = \'\%(\S\+\)\@!text\s*$:\%(\S\+\)\@!endtext\s*$' Hint from :help matchit-spaces Also :help /\@! But I'm still wondering why '\zs' didn't work. Even I do not know for sure. I think the point is that matchit takes 'pat1:pat2' and builds up the regex /\%(pat1\)\|\%(pat2\)/ . If you are just searching for /pat1/ then it does not matter if pat1 is \s*\zstext or \(\s*\)\@=text , but when you build the larger regex, it does make a difference. IIRC, early versions of the script were written before \@= was added so I included a special marker ( I think, inspired by :menu syntax) for when you wanted to position the cursor somewhere other than at the start of the match. HTH --Benji Fisher
Re: Convert to HTML patch. Opinions / Testing.
On Sat, Sep 09, 2006 at 07:03:14PM +0100, Edd Barrett wrote: Here is the patch: http://arameus.net/users/edd/vim-test/2html.vim.diff Also in the same directory you will see the output of my tests, please test them on other browsers. I viewed the output using the following systems and browsers: Linux, Mozilla 1.7.12 Windows XP, Mozilla 1.7.12 and IE 6.0.2900.2180.xpsp_sp2_gds.050301-1519 Mac OS X, Mozilla 1.7.12, IE 5.2.3, OmniWeb 4.5, and Safari 1.3.2 Note that two of the Mac browsers are a couple of years old. The pages all looked pretty much the same. On IE/Mac, the CSS versions seemed to use slightly smaller fonts than the non-CSS versions. In several browsers, the CSS versions had a little more white space at the top of the screen than the non-CSS versions. (Maybe because of the pre tags?) I do not see any problems in my browsers, so I vote in favor of improved compliance with the W3 standards. Minor point: in http://arameus.net/users/edd/vim-test/xhtml_no_css.html (XHTML without CSS) there are some empty tags such as br/. Isn't the standard advice to add a space before the slash, as in br /? I think this still complies with the standard, and it is supposed to be easier for some older browsers to parse. I am completely new to your development community (but I've been using vim for many years), so I aplogize if I have broken any coding style rules/other rules. =) I like to think that we are not too picky. Thanks for the contribution. HTH --Benji Fisher
Re: testing patchlevel from script
On Sun, Sep 10, 2006 at 01:05:11PM +, Yakov Lerner wrote: How can a script test for specific patchlevel ? For example, I have vim 7.0.86 and I need to check in the script that patchlevel is = 7.0.86. But v:version is 700. How ? It would be nice if to have patchlist available through some v: variable. I agree that a List of patch numbers would be convenient. You can test for a specific patch with has(patch86). :help has-patch HTH --Benji Fisher
Re: +clientserver on Mac OS X
On Fri, Sep 08, 2006 at 09:57:41AM +1000, Peter Hodge wrote: Hello, Is it possible to run the clientserver feature on Mac OS X? I cannot see anywhere in the help that directly states that clientserver only runs on Windows or X11. I am pretty sure that this is not implemented for OS X. I agree that the docs are not clear on this point, but I think that if you scroll down from :help +feature-list to :help +clientserver you will find Unix and Win32. OK, so Unix includes Linux and maybe FreeBSD but not OS X ... as I said, I agree that the docs are not clear. --Benji Fisher
Re: matchparen tweak
On Wed, Sep 06, 2006 at 02:15:36AM +0200, A.J.Mechelynck wrote: Benji Fisher wrote: Now that the problem has been pointed out, I think the patch should be made in the official distribution. How about (simple but oh, so clever) let plist = split(matchpairs, '.\zs.') which removes every second character? Will that have trouble with multibyte characters? Are these even allowed in 'matchpairs'? The help for 'matchparen' mentions only single characters which must be different. You might try it with Arabic ornate parentheses, U+FD3E (left i.e. closing) and U+FD3F (right i.e.opening), which are obviously meant to pair with each other. I assume you mean the help for 'matchpairs', not 'matchparen'. I tried :let mps = \uFD3E:\uFD3F :set mps? and the value was not changed. I think the docs should be changed to mention that multi-byte characters are not allowed; as I read it, single characters does not rule out multi-byte characters. I also do not like the absence of an error message. I guess this is an issue with :let since I do get an E474 from :set mps=C-VuFD3E:C-VuFD3F (*not* typed literally). IIUC, a dot in a pattern matches one character, which may be one or more bytes, and which may occupy one screen cell, two for a wide CJK character, one to eight for a tab, etc. Yes, and :echo split(\uFD3E:\uFD3F, '.\zs.') returns ['﴾', '﴿'] as expected. So I think my proposal for matchparen.vim is safe even if 'matchpairs' is changed to allow multi-byte characters. HTH --Benji Fisher
mixed filetypes (was: Smarter Indent)
On Wed, Sep 06, 2006 at 11:54:23AM +, Yakov Lerner wrote: On 8/7/06, Benji Fisher [EMAIL PROTECTED] wrote: Let me take this opportunity to try once again to drum up support for an idea that I have proposed before. IMO it is too restrictive to make options (such as syntax highlighting, 'textwidth', and indent-related options) apply to a whole file. There should be a convenient, consistent way to tell vim to treat different sections of a file as having different file types. Examples: * code snippets in an e-mail * PHP in an HTML file (or vice-versa) * perl/python/ruby inside a vim script * comments, text, and math inside LaTeX/plain TeX/conTeXt True. I use perl -e perl scripts embedded into shell scripts, and I am missing perl syntax inside shell scripts. OTOH, it is possible in vim. What is missing here is some doc section in the syntax.vim doc. Doc sestion that'd describe the official recommended method of embedding one syntax (filetype) into another; like php syntax includes the html syntax. Syntax coloring can be made to work, but what about options, key mappings, etc.? If you use omnicompletion in your perl files, wouldn't you like it to work when you are embedding perl in a shell script? HTH --Benji Fisher
matchparen tweak (was: vim 7 errors)
On Wed, Sep 06, 2006 at 01:20:13AM +0200, A.J.Mechelynck wrote: It's supposed to treat ? and : on the one hand, and = and ; on the other hand, as paired brackets. However, the matchparen plugin uses a rather elementary algorithm to split 'matchpairs' into individual items: any colons and commas are regarded as delimiters, and then odd parts are treated as left brackets, even ones as right brackets. Good catch. I think the line you are referring to is let plist = split(matchpairs, ':\|,') in $VIMRUNTIME/plugin/matchparen.vim . I see the following possible cures, use only one of them: (a) disable matchparen matching :set loaded_matchparen = 1 (b) remove the questionable pair ?:: from the 'matchpairs' options (c) patch plugin/matchparen.vim to refine the splitting algorithm, so that a colon should be treated as either a separator or a bracket depending on position within the option. Now that the problem has been pointed out, I think the patch should be made in the official distribution. How about (simple but oh, so clever) let plist = split(matchpairs, '.\zs.') which removes every second character? Will that have trouble with multibyte characters? Are these even allowed in 'matchpairs'? HTH --Benji Fisher P.S. cc'ed to vim-dev for further discussion
Re: Syntax question regarding \%[
On Tue, Sep 05, 2006 at 06:51:57PM +1000, Peter Hodge wrote: Hello all, Given the following text: inte integ intege integer inter interv interva interval is there any easy way to make these two commands work? syntax match Error /int\%[eger]/ syntax match Error /int\%[erval]/ The second match begins taking priority as soon as the word is 'inte', and prevents 'integer' from being matched correctly. regards, Peter How about adding end-of-word patterns: syntax match Error /int\%[eger]\/ syntax match Error /int\%[erval]\/ HTH --Benji Fisher
Re: vim 7 errors
On Wed, Sep 06, 2006 at 01:03:04AM +0200, Paul van Erk wrote: More info; I found this in my .(g)vimrc : set matchpairs+=?::,=:; so that's: PLUS EQUALS QUESTION_MARK COLON COLON COMMA EQUALS COLON SEMICOLON It's been in there for ages (checked some backups and I've had my rc file for 2 years or so, I think) and never gave me any problems. Does anyone know what it's supposed to do and what the syntax should be? For now I'll comment it out, so the errors are gone. Grts, Paul The 'matchpairs' option controls how % finds matching characters. Just as ( and ) are paired, your setting pairs ? with : and = with ; . The matchparen plugin uses the 'matchpairs' option as well. For more details, :help 'matchpairs' HTH --Benji Fisher
matchparen tweak (was: vim 7 errors)
On Wed, Sep 06, 2006 at 01:20:13AM +0200, A.J.Mechelynck wrote: It's supposed to treat ? and : on the one hand, and = and ; on the other hand, as paired brackets. However, the matchparen plugin uses a rather elementary algorithm to split 'matchpairs' into individual items: any colons and commas are regarded as delimiters, and then odd parts are treated as left brackets, even ones as right brackets. Good catch. I think the line you are referring to is let plist = split(matchpairs, ':\|,') in $VIMRUNTIME/plugin/matchparen.vim . I see the following possible cures, use only one of them: (a) disable matchparen matching :set loaded_matchparen = 1 (b) remove the questionable pair ?:: from the 'matchpairs' options (c) patch plugin/matchparen.vim to refine the splitting algorithm, so that a colon should be treated as either a separator or a bracket depending on position within the option. Now that the problem has been pointed out, I think the patch should be made in the official distribution. How about (simple but oh, so clever) let plist = split(matchpairs, '.\zs.') which removes every second character? Will that have trouble with multibyte characters? Are these even allowed in 'matchpairs'? HTH --Benji Fisher P.S. cc'ed to vim-dev for further discussion
Re: Fixing cweb.vim
On Sat, Sep 02, 2006 at 01:36:06AM +0300, Ilya wrote: Benji Fisher wrote: On Fri, Sep 01, 2006 at 09:36:55AM +0300, Ilya wrote: David Brown wrote: [...] However, tex.vim frequently will enclose large sections of the document within a region and the cweb.vim which the webCRegion is not part of. I think I can fix this by adding an appropriate containedin=... field to the definition of webCRegion. What I'm having difficulty with is figuring out what to put there. Is there a way of finding out what region a given part of the buffer is in? From :help synID Example (echoes the name of the syntax item under the cursor): :echo synIDattr(synID(line(.), col(.), 1), name) IIUC, synIDattr() always returns a syn-match or syn-keyword group. It does not tell you whether you are in a syn-region. HTH --Benji Fisher It does return region names for me. So it does, but only if there is no active match nor keyword at the cursor. What I should have said is that synIDattr() (or maybe I should say synID()) reports only the innermost syntax item at the cursor. For example, :help r :normal 6j0 :echo synIDattr(synID(line(.), col(.), 1), name) reports helpLesdBlank but does not mention that this syn-match (defined with contained) is inside a helpExample syn-region. (Verify this by moving the cursor to the first non-blank on the lins.) In brief, synID() *sometimes* reports the current syn-region, and I do not think this is good enough for David Brown's purposes. HTH --Benji Fisher
Re: Using commands that use unix EDITOR environment variable
On Sat, Sep 02, 2006 at 12:02:02PM +0530, Ujjal Bose wrote: Hi , in my machine if I set EDITOR as gvim and then try to execute commands like crontab -e that invoke editors, I get a gvim window , but it does not open my existing crontab file, nor does it allow me to do any changes. But if I set the EDITOR as vi , everything works. Any clues ? -Ujjal I think the problem is that, by default, gvim forks and immediately returns control to the calling process. Try setting EDITOR to vim or to gvim --nofork. HTH --Benji Fisher
Re: bug in confirm() and default option
On Sat, Sep 02, 2006 at 12:05:57AM -0700, Hari Krishna Dara wrote: According to the help, if you specify a value of 0 for default, none of the choices should be selected, but this is not how it is working. I tried both on win32 and cygwin (X) gvim and both default to 1 instead. Is there another trick to not select any of the choices? I get the same behavior on Linux (FC2). In vim (not gvim), :echo confirm(Save changes?, Yes\nNo\nCancel, 0) echoes 0 if I hit CR without making a choice. HTH --Benji Fisher
Re: Fixing cweb.vim
On Fri, Sep 01, 2006 at 09:36:55AM +0300, Ilya wrote: David Brown wrote: [...] However, tex.vim frequently will enclose large sections of the document within a region and the cweb.vim which the webCRegion is not part of. I think I can fix this by adding an appropriate containedin=... field to the definition of webCRegion. What I'm having difficulty with is figuring out what to put there. Is there a way of finding out what region a given part of the buffer is in? From :help synID Example (echoes the name of the syntax item under the cursor): :echo synIDattr(synID(line(.), col(.), 1), name) IIUC, synIDattr() always returns a syn-match or syn-keyword group. It does not tell you whether you are in a syn-region. HTH --Benji Fisher
Re: better recognising of tex vs plaintex filetype
On Tue, Aug 29, 2006 at 09:16:41PM +0200, Stefano Zacchiroli wrote:
On Tue, Aug 29, 2006 at 03:06:39PM -0400, Benji Fisher wrote:
I do not think there is any reliable way to distinguish between
plain TeX and LaTeX. After my RFC, I decided to treat plain TeX as the
default, since it is the more basic, even though I agree that LaTeX is
probably far more common now. I suggest adding
let tex_flavor = latex
to your vimrc file.
Hi Benji, thanks for your feedback.
In my mail I was more talking as the maintainer of the vim package (and
of the vim-latexsuite add-on), than as a vim user. Since I've been
bugged by users asking for more recognition of LaTeX I was wondering if
you agree to change the vim-wide default, instead of changing it on a
per-user basis.
If you maintain a vim package (for Debian, guessing from your
sig?), then you can always define g:tex_flavor in a system vimrc if you
want. BTW, the documentation for this is under
:help ft-tex-plugin
Having already made the decision one way after a RFC, I am reluctant to
reverse it. If I then get a rash of complaints from plain TeX and
conTeXt users, would I have to reverse it again?
Since you agree that LaTeX is more common, what is exactly your argument
against having it as the default?
Plain TeX came first, so it has priority. (Maybe LaTeX 2ε is an
independent format, but I remember when LaTeX first came out that it was
actually a bunch of \def's made on top of plain TeX.) This is the same
logic that leads to keeping vi-compatible regular expressions, despite
the persistent suggestions that vim adopt PCRE.
Defaults should cater to users who do simple things, and plain TeX
is simpler than LaTeX. Writing LaTeX and splitting your document among
multiple files (so that most of them do not have the \begin{document}
line) is complicated, and anyone doing this should be willing to
customize his or her vimrc file appropriately.
Please read the thread on this list started Mar 2, 2006, with the
subject
RFC: filetypes for TeX, LaTeX, ConTeXT (others?)
Beside that, I agree with the other proposal in this thread of
recognizing as LaTeX files which starts with a sectioning command (after
several possible blanks of course), and I'm going to implement it.
Any comments on that choice?
Do you mean you plan to implement it as a proposed modification to
$VIMRUNTIME/filetype.vim in the standard distribution, or a change to
your vim package? I agree with the comment that plain TeX users may
also define such sectioning commands. Maybe it would be safe if you
check for such definitions, using an include-file search ... but of
course, that is more convenient after ftplugin/plaintex.vim has been
:source'd.
HTH --Benji Fisher
vim mailing lists
On Sun, Aug 27, 2006 at 02:40:24PM +0200, Bram Moolenaar wrote: Apparently the sorbs blacklist mechanism is still being used, causing trouble for some people. I have asked the mail server maintainer to remove sorbs a few times now... Twice recently, sorbs has bounced my mails to the list because some server between my ISP and the vim-dev list is on its blacklist. Do you have any plans to move the vim mailing lists to a new server, where you (or someone more responsive) has administrative control? --Benji Fisher
Re: Re [2]: again: % does not work with ' ( '
Yes, b:match_skip is relevant here. The matchit default is to skip strings and comments (unless you use % starting inside a string or comment). The matchit script relies on the syntax mechanism to recognize strings and comments. HTH --Benji Fisher On Wed, Aug 30, 2006 at 05:37:38PM +1000, Peter Hodge wrote: Hey, Thanks for that important clue. It seems the secret to making it work is in the values of the b:match_skip and b:match_words variables. Thank you, this problem has been bugging me for a while. regards, Peter Addendum: It depends on the 'filetype' and possibly on whether %-jumping is done by Vim C code or by the matchit script: with the same file, if :set filetype=vim % jumps between 1 and 6 (but here the matchit plugin comes into play), and matchparen pairs 1 with 6 too. Best regards, Tony.
Re: better recognising of tex vs plaintex filetype
On Sat, Aug 26, 2006 at 01:38:11AM +0200, Stefano Zacchiroli wrote: [ Forwarded to vim-dev, as requested by Bram. Consider both the patch and the suggested default change as RFCs ] Hi Bram, could you please consider the attached patch for filetype.vim? It provides better recognition of 'tex' filetypes against 'plaintex' ones. It looks for sectioning commands that are specific to latex (\part, \section, \paragraph, ...). Also, according to a comment in filetype.vim, the code distinguishing between 'tex' and 'plaintex' should default to 'tex', whereas, according to these lines: Default value, may be changed later: let format = exists(g:tex_flavor) ? g:tex_flavor : 'plain' I assume it defaults to 'plaintex'. Is there a reason for that or it is just a typo? I found the default to 'tex' much more reasonable, as most of people write latex these days ... What about changing it so that it matches the comment? Many thanks in advance, Cheers. I believe that Bram does not use any version of TeX himself. I maintain the plaintex and latex ftplugins, and I suggested the current detection scheme (after a RFC before vim 7.0 was released). If the comments, documentation, and code do not agree, it is probably my fault. I do not think there is any reliable way to distinguish between plain TeX and LaTeX. After my RFC, I decided to treat plain TeX as the default, since it is the more basic, even though I agree that LaTeX is probably far more common now. I suggest adding let tex_flavor = latex to your vimrc file. HTH --Benji Fisher
Re: How to insert text via script/function call ?
On Fri, Aug 18, 2006 at 04:44:26AM +0200, Meino Christian Cramer wrote: Hi, I often need to place a header above a function defintion (C-source) fpr documentational purposes. What I treid is to write a short function for vim, which dioes insert the text skeleton -- but I did not find any already existing function in the API which does this for me. With :i I got weird effects -- sure my fault, but... . How can I insert text via a script ? Kind regards, mcc One way to do this is the ClassHeader() function (and associated map/autocommand) in my file of example vim functions, foo.vim : http://www.vim.org/script.php?script_id=72 This one is pretty old: I wrote it before there were such things as buffer-local mappings and ftplugins. HTH --Benji Fisher
Re: an indentation question
On Fri, Aug 18, 2006 at 10:36:32AM +0200, A.J.Mechelynck wrote: steven woody wrote: i use vim on both linux and windows. but i found their indentation behavior a little differently. say i was coding a c program on the below line void foo_fun( int p1 then i press return on linux, the cursor come to a pleasant position, that became, void foo_fun( int p1 , int p2 ); but when i was on windows and do the same thing, it became void foo_fun( int p1 , int p2 ); and i dont like that. i compared .vimrc files on linux and windows, but got nothing. so i am wandering whether someone here got know a setting which helps. thanks. there are some options which might be relevant, like 'cindent' and 'indentexpr'. You might also want to check :filetype (without arguments) to see if filetype-related indentation is or isn't on on both sides. Best regards, Tony. Also check the output of :version If one system has version 6.x of vim and the other has 7.0, that could explain a lot of differences. You will also see (after the feature list) the location of the system vimrc file, if any. You should compare those (if they exist) as well as your personal vimrc files on the two systems. HTH --Benji Fisher
Re: more on local additions in help.txt -- debian bug?
On Wed, Aug 16, 2006 at 03:33:42PM -0400, Gabriel Farrell wrote: Aha. Benji's explanation is correct. My $VIM points at /usr/share/vim/addons/ which contains doc/matchit.txt, doc/tags, and plugin/matchit.vim. This is the default for the Debian installation. The screwy thing is that unless I copy matchit.vim into $HOME/.vim/plugin/, matchit isn't installed, and I can't see any help for it because, as you surmised, :helptags hasn't been run on /usr/share/vim/addons/doc/ -- the tags file in that directory is empty. I'm not sure if this is a bug in vim or the debian package; I think mostly the package. gabe I think you are right that the package only partially installs the plugin. Just to be clear, there are three related things; I will use rtp to denote a path that is in the 'runtimepath' option. (1) A line appears under :help local-additions if rtp/doc/matchit.txt exists. (2) A tags file for dir/matchit.txt is created if you run :helptags dir and :help will find those tags if dir is in 'runtimepath'. (3) The plugin will be effective if rtp/plugin/matchit.vim exists. This particular plugin also relies on rtp/ftplugin/*.vim to set buffer-local variables that control its behavior. HTH --Benji Fisher
Re: more on local additions in help.txt
On Wed, Aug 16, 2006 at 02:18:55AM +0200, A.J.Mechelynck wrote: Gabriel Farrell wrote: Hi, Regarding a thread [1] back in February on this list about local additions, I'm not seeing some of the errors remarked upon at that time, but I do see 'matchit.txt' under the LOCAL ADDITIONS heading even when it's not installed. If I do copy it into the doc directory and run helptags, it's listed twice. A minor annoyance, to be sure. gabe [1] http://marc.theaimsgroup.com/?t=11395267213 What you see there may depend on how you update your Vim runtime files, and when you last did. I do it by downloading the contents of ftp://ftp.vim.org/pub/vim/runtime/ except its dos/ subdirectory, my help.txt is dated: *help.txt*For Vim version 7.0. Last change: 2006 Jun 16 I have matchit.txt (and two more files) in $VIM/vimfiles/doc, and I see LOCAL ADDITIONS: *local-additions* |matchit.txt| Extended % matching |pi_netrw.txt| For Vim version 7.0. Last change: 2006 Jun 08 |pi_vimball.txt| For Vim version 7.0. Last change: 2006 Jun 19 -- Running less on the same file shows that the LOCAL ADDITIONS section is actually empty in the file as it resides on disk. You might want to open it with a text editor other than Vim, and remove all non-blank lines between LOCAL ADDITIONS and the horizontal line. Best regards, Tony. If there are any non-blank lines there, I would consider the file corrupted. The documentation on this feature is a little terse. Using :helpgrep local-add leads to :help write-local-help which explains where those lines come from. The surprising thing (for me) is that these lines are added whether or not :helptags has been run on the directory containing the doc files. I did not figure this out until I looked at the source: vim70/src $ grep local-add *.c vim70/src $ vim ex_cmds.c /local-add According to the comments there, vim builds the LOCAL ADDITIONS section by looking for doc/*.txt in every 'runtimepath' directory other than $VIMRUNTIME and extracting the first line. Conclusion: if you have a line for matchit.txt under LOCAL ADDITIONS, then you probably have doc/matchit.txt somewhere in your runtime path; if you have duplicate entries, then you have duplicate files. It does not matter whether you have installed the help files with :helptags . Does this explain what you see? HTH --Benji Fisher
Re: [RFC] fixing f-args wrt '\\ ' handling
On Thu, Aug 10, 2006 at 11:38:25PM +0300, Yakov Lerner wrote:
XX \\ works, 2 args ('\\')
Is that correct?
XX a bworks, 2 args ('a','b')
XX a\ b works, 1 arg ('a b')
XX a\\b 1 arg ('a\\b') Shall it be 1 arg('a\b') ?
So I guess XX a\b gives 1 arg ('a\b') ?
XX a\\ b bug: 1 arg('a\ b') Expected 2 args('a\','b')
XX a\\ b bug: 2 args ('a\ ','b'). Expected 2 args('a\','b')
I agree with Matthew on this. If '\\' will be used for '\' in some
situations, it is easier to remember if it always means that. So if you
want 'a\b', use 'a\\b' and if you want 'a\\b', then use 'ab'.
$0.02 --Benji Fisher
P.S. I cannot resist tweaking a vim function:
command! -nargs=* XX :call Test(f-args)
fun! Test(...)
echo XX: .a:0. args(
echo XX: a:0 args(
Both :echo and :execute (!) accept multiple arguments.
let i=1
let argc=a:0
Warning: variable argc is defined but never referenced.
while i = a:0
echon '.a:{i}.'
if i != a:0 | echon , | endif
Instead of the above two lines, I prefer
echon ' . a:{i} . ' . (i != a:0 ? , : )
let i = i + 1
endwhile
echon )
endfun
Re: Invoke _gvimrc.vim / unexpected expansions
On Fri, Aug 11, 2006 at 07:07:58AM -0400, James Vega wrote: On Fri, Aug 11, 2006 at 08:43:10AM +0200, jandl wrote: Dear colleagues, I have 2 problems with gvim 1/ when I start gvim in Windows XP (double click on icon), gvim opens without invoking the _gvimrc.vim. I have _gvimrc.vim located in c:\programs\vim. I have also tried to put _gvimrc.vim into c:\programs\vim\vim70 but it was not automatically started from there either. 2/ I am using gvim for edition my latex files and have the Latex-Suite as an add-in. That has generated some conflict: whenever I press a '.' I get 'C-R=SIDSmartDots()CR'. Here is my _gvimrc.vim: [snip] To use it, copy it to for Unix and OS/2: ~/.gvimrc for Amiga: s:.gvimrc for MS-DOS and Win32: $VIM\_gvimrc As your _gvimrc says, there should be no .vim extension on your _gvimrc (or _vimrc). :) That will fix 1). As for 2), you may have to edit the plugin to change that mapping so it doesn't override a normal Vim command. I think there is a good chance that, since the gvimrc file is never :souce'd, the OP is running with 'compatible' set, and that this causes the problem. If so, then fixing the first problem will fix the second. HTH --Benji Fisher
Re: Indentation changes when calling functions
On Tue, Aug 08, 2006 at 05:05:15AM +0200, Preben Randhol wrote: imap \sf c-o:call insert_text()CR Now, say I have typed: def some_func(): '''Some func''' print Hello World | (| = cursor position) if I now use the \sf mapping then the cursor moves to: print Hello World | It is not clear from what you have written: if the def line is indented, does the cursor get indented too? It does not for me, so I will assume that all the indent was removed and that you indented the whole example. This behavior is (almost) explained under :help 'autoindent' I say almost because C-O is not listed along with Esc and CR as one of the keys that will remove all indent if typed on an empty line. I have mapped the function in this way: imap \sf xc-oxc-o:call insert_text()CR which solves the problem as the cursor doesn't jump out, but isn't there a cleaner way to do this? This is slightly simpler: imap \sf xBSc-o:call insert_text()CR HTH --Benji Fisher
Re: No way to color-region(s) of text -- highlighter mode.
Vim does a lot of optimization of regular expressions, but I do not know how it would perform in this case. I would just try it and see. If it does not work well, that would be a good reason to try :syn match instead of :match . HTH --Benji Fisher On Sun, Aug 06, 2006 at 09:59:31AM -0700, Mohsin wrote: I can try making a large regexp. I was under the impression that alternating regexps can be exponentially slow. Is %l %c %v matching is implemented in constant time? ie. Does vim try to match the regexp at every point - or it can optimize and start matching from the given line? Nothing to do with implementation just the hard theoretical limit, I am afraid, this might not work on slower machines. thanks mohsin On 8/5/06, Benji Fisher [EMAIL PROTECTED] wrote: I think that Tony mentioned :help /\| in a previous post, but maybe you missed it. I just tried :highlight User1 term=bold,underline cterm=bold,underline gui=bold,underline :match User1 /\%3l.\%7l\\%3v.\%7v\|\%12l.\%18l\\%33v.\%20v/ ^^ and it marked two rectangular regions in this e-mail. I admit that this is just a proof of concept, not very convenient to use. It should not be too hard to store a List of Lists, each inner list giving the boundaries of a rectangle (four Numbers), and then to write a function that processes this list to :execute the appropriate :match statement. Then another function could add or remove Lists to the outer List. :help List vim 7.0 only :help :for ditto It is also possible to use :syn match instead of :match. Each approach has some advantages. Without knowing how you would want to use such a feature, I do not know which would be more appropriate. HTH --Benji Fisher
Re: editing within visual block
On Fri, Aug 04, 2006 at 01:25:27PM -0700, Weiguang Shi wrote: Thanks Tony. Dr. Chip's site seems to have a lot of vim-plugins. So far I just tried out the DrawIt. It looks like a good start and I search for more. See also http://www.vim.org/scripts/script.php?script_id=1195 (Extended Visual Mode Commands, Substitutes, and Searches). Editing within visual blocks, I suspect, however, sounds like a feature better supported natively by Vim than its scripts. I do not see how this would work. Are you thinking of extra commands in Visual mode, Normal mode, or some new mode? HTH --Benji Fisher
Re: Smarter Indent (an odd problem)
On Sat, Aug 05, 2006 at 02:24:45PM -0400, JStrom wrote: Recently though, I noticed that the PHP formatting also uses the HTML formatting code, and I do like PHP's smart-indentation. Is there some way I can tell vim to bring the indentation settings back alive within the ?php ... ? tags? Let me take this opportunity to try once again to drum up support for an idea that I have proposed before. IMO it is too restrictive to make options (such as syntax highlighting, 'textwidth', and indent-related options) apply to a whole file. There should be a convenient, consistent way to tell vim to treat different sections of a file as having different file types. Examples: * code snippets in an e-mail * PHP in an HTML file (or vice-versa) * perl/python/ruby inside a vim script * comments, text, and math inside LaTeX/plain TeX/conTeXt --Benji Fisher
Re: can vim do this?
On Thu, Aug 03, 2006 at 02:23:39PM -0700, Lev Lvovsky wrote: * regional undo - can I select a region, and perform an undo for all of the changes only in that region? This has been requested before, but it is not implemented and I do not expect that it will be added any time soon. The problem is how to define a region, when lines can be added, removed, or deleted at will. If you have a satisfactory answer to this question, you can fake a region-undo as follows. Delete the region to be changed; undo levels, or however many you choose; yank the same region; redo levels; paste. If you have a simple description of what constitutes a region, you could define a mapping or menu item to do this conveniently. I think all the other questions were answered by other posts on this thread. Let us know if you want more information on any of them. HTH --Benji Fisher
