macguitabline patch v4
Hi, here's the fourth version of the guitabline patch for mac os x. I removed some dead code, and, more importantly, changed the code that it runs on 10.2 - 10.3 without changes (I could only test 10.3, though). There was a call to a 10.4-only function (DataBrowserChangeAttributes()), this function is now loaded at runtime. Furthermore, the patch is against the current svn version. Apply with -p0 in vim's root directory. Some feedback, especially for 10.2 and 10.3 systems, would be nice :-) Bye, Nico macguitab.v4.patch.1 Description: Binary data
missing help tag c_CTRL-]
Dear Bram, I think there ought to be a help tag for c_CTRL-] (either synonymous with i_CTRL-] , resending to it, or with a similar text). What do you think? Abbreviations are terminated the same way in Insert and Command-line modes aren't they? Best regards, Tony.
Re: Gvim for KDE
On Monday 17 July 2006 03:40, Mikolaj Machowski wrote: Dnia poniedziałek, 17 lipca 2006 17:09, Charles E Campbell Jr napisał: As I recall, the vim7 kde port was dropped because there was no maintainer for the port. I'm not a KDE user myself, so I'm not a candidate, but perhaps if you volunteered to do KDE port+maintenance, you might be able to get it back in. I am not programmer but use KDE. IMO come back to KDE should wait until release of Qt4.2 . It should support glib event loop. Conflicts between glib and Qt event loops were major reasons for unresponsiveness of kvim. m. Back when I was looking for a KDE version of Vim, I found a program called yzis http://yzis.org/ that was effectively a new Vim-like program made for KDE (along with a CLI version) and a different set of ideas to work behind for future development. If a KVim version can be made with Qt4.2, I love you long time. -- Matt Sicker pgpQLldHA1cNX.pgp Description: PGP signature
Re: Gvim for KDE
Matt Sicker wrote: On Monday 17 July 2006 03:40, Mikolaj Machowski wrote: Dnia poniedziałek, 17 lipca 2006 17:09, Charles E Campbell Jr napisał: As I recall, the vim7 kde port was dropped because there was no maintainer for the port. I'm not a KDE user myself, so I'm not a candidate, but perhaps if you volunteered to do KDE port+maintenance, you might be able to get it back in. I am not programmer but use KDE. IMO come back to KDE should wait until release of Qt4.2 . It should support glib event loop. Conflicts between glib and Qt event loops were major reasons for unresponsiveness of kvim. m. Back when I was looking for a KDE version of Vim, I found a program called yzis http://yzis.org/ that was effectively a new Vim-like program made for KDE (along with a CLI version) and a different set of ideas to work behind for future development. If a KVim version can be made with Qt4.2, I love you long time. My distribution of SuSE 9.3 came with a program named kvim which is a version of gvim 6.2.14, modified for kde (and, IIUC, Qt) (but --version says compiled by [EMAIL PROTECTED] and no modified-by line). (The console Vim that came with it was a 6.3.58.). Good luck to you if you want to merge kvim into mainstream Vim with a proper set of #ifdef's. BTW, the Qt version installed here goes by the cryptic name of qt3-3.3.4-11.3 (as listed by rpm -qa | grep qt, without the quotes of course ;-) ). Best regards, Tony.
Re: missing help tag c_CTRL-]
Tony Mechelynck wrote: I think there ought to be a help tag for c_CTRL-] (either synonymous with i_CTRL-] , resending to it, or with a similar text). What do you think? Abbreviations are terminated the same way in Insert and Command-line modes aren't they? Right. I'll add the tag and also an entry in the command index. -- How To Keep A Healthy Level Of Insanity: 3. Every time someone asks you to do something, ask if they want fries with that. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: colors
If you find the syntax file for Vim 6.4, and put it into your own .vim directory, you may get the colors before. If you want to change it, just copy the syntax file into your own .vim directory and edit it. -- Sincerely, Pan, Shi Zhu. ext: 2606 Bill Hollingsworth [EMAIL PROTECTED] wrote on 2006.07.18 04:53:57: Hi, I recently upgraded to VIM 7.0 and now the color settings for my PERL programs are different. I liked the way the colors were before. Could someone tell me how to return to the old settings, or how to set the colors myself? For instance, now comments and variable names are the same color. Thanks and best wishes, Bill Hollingsworth University of Cambridge Computer Laboratory
test if insert mode
How do I implement a conditional to test if in insert or normal mode? Thanks -- Eric Smith
Re: test if insert mode
On 7/18/06, Eric Smith [EMAIL PROTECTED] wrote: How do I implement a conditional to test if in insert or normal mode? There is funciton mode(), but it might not work for you. But see cautionary sentence at the end of :help mode(). People reported problems. if mode() == 'i' in insert mode else if mode() == 'n' in normal mode endif See :help mode() If you experience problems, then tell us what are you trying to do, like, for what you are trying to use it. Yakov
Re: Generic xml omnicomplete
David Purton wrote: Hi all, I gather that the vim7 xml omnicomplete needs a data file to work - which is fair enough, since you can get all the attributes as well this way. But, how can I get a generic xml omnifunction system where vim will just close the last open tag for me. eg, at present, for html, I have vim set up to close the current tag as soon as I type '/' cheers dc Such generic xml/html ftplugins are distributed with Vim. You must activate them by having one (not all) of the following lines in your vimrc: filetype plugin on filetype plugin indent on source $VIMRUNTIME/vimrc_example.vim runtime vimrc_example.vim (I recommend the last one, near the top of your vimrc, but YMMV.) Then you trigger omni-completion by hitting Ctrl-X Ctrl-O in Insert mode. In either HTML or XML, if the cursor is immediately after / Vim should then close the current tag. Omni-completion also functions at other places, for instance (IIRC) in HTML after hitting Ctrl-X Ctrl-O should give you a menu of possible tag names, after DIV a menu of possible attributes, etc. You can also assing a single-key shortcut for it, e.g. :imap F12 C-XC-O to use F12 instead of Ctrl-X plus Ctrl-O Best regards, Tony.
Re: ftplugin not detected
[EMAIL PROTECTED] wrote:
Hi Tony and Chip,
Yes indeed. When processing with my test there was a local $HOME/.vimrc
file.
First case: without line filetype plugin on in $HOME/.vimrc file.
Second case: with line filetype plugin on in $HOME/.vimrc file.
In both cases: no $HOME/.vim/filetype.vim file and no file in
$HOME/.vim/ftplugin directory.
In the first case, the Ctrl-] shortcut calls the tag in my ./tags file. The
:verbose map C-] echos:
No mapping found
on the command line.
In the second case, the Ctrl-] shortcut echos :call JumpToTag_ada('') on
the command line. The :verbose map C-] echos:
n C-] *@:call JumpToTag_ada('')CR
on the command line.
JumpToTag() lies in the default ada ftplugin:
$ grep -n -R JumpToTag_ada /usr/share/vim/
/usr/share/vim/vim63/ftplugin/ada.vim:37: nnoremap unique buffer C-]
:call JumpToTag_ada('')cr
/usr/share/vim/vim63/ftplugin/ada.vim:40: nnoremap unique buffer
gC-] :call JumpToTag_ada('','stj')cr
/usr/share/vim/vim63/ftplugin/ada.vim:168:function! JumpToTag_ada(word,...)
So in the first case, the C-] was no particular mapping but the default
behaviour which works.
In the second case, the C-] is mapped to the special function
JumpToTag_ada() from $VIMRUNTIME/ftplugin/ada.vim filetype plugin file.
That function is:
function! JumpToTag_ada(word,...)
if a:word == ''
Get current word
let word = AdaWord()
if word == ''
return
endif
else
let word = a:word
endif
if a:0 0
let mode = a:1
else
let mode = 'tj'
endif
let v:errmsg = ''
execute 'silent!' mode word
if v:errmsg != ''
if v:errmsg =~ '^E426:' Tag not found
let ignorecase = ignorecase
set ignorecase
execute mode word
let ignorecase = ignorecase
else
Repeat to give error
execute mode word
endif
endif
endfunction
if mapcheck('C-]','n') == ''
nnoremap unique buffer C-]:call JumpToTag_ada('')cr
endif
which is supposed to call :tj on the word under the cursor.
The word under the cursor is indeed the right one. I called an word =
AdaWord(); echo word to be sure.
The bug is in the function JumpToTag_ada().
To convince everyone, I added the following lines in my local ada.vim
ftplugin file (which overwrites that of $VIMRUNTIME)):
function! GetToTag(...)
let word = AdaWord()
execute tj word
endfunction
noremap unique buffer C-] :call GetToTag()cr
Those lines make everything work fine. So the few lines of JumpToTag_ada()
seem to be bugged.
What to you think?
Regards,
Julien
Mappings defined in an ftplugin ought, for sanity, to have the buffer
attribute so they don't interfere with other filetypes. If the mapping
defined by the ada ftplugin remains active even when the active cursor
is in a file of a different filetype, then IMHO it's a bug in the ada
ftplugin and in that case you should contact its maintainer (look for a
comment near the top of $VIMRUNTIME/ftplugin/ada.vim).
OTOH, if you experience the disturbing behaviour _only_ when editing an
ada source file, then it could be either a bug or a feature. In that
case, since I don't know ada myself, I'm not qualified to offer an opinion.
Best regards,
Tony.
Re: ftplugin not detected
Hi Tony,
That's fine, thanks. When I have some time, I'll try and have a look at the
script in detail.
If I have further questioning I'll then directly contact the maintainer.
Regards,
Julien
Internet
[EMAIL PROTECTED] - 07/18/2006 01:52 PM
To:Julien 3 NGUYEN
cc:drchip, vim
Subject:Re: ftplugin not detected
[EMAIL PROTECTED] wrote:
Hi Tony and Chip,
Yes indeed. When processing with my test there was a local $HOME/.vimrc
file.
First case: without line filetype plugin on in $HOME/.vimrc file.
Second case: with line filetype plugin on in $HOME/.vimrc file.
In both cases: no $HOME/.vim/filetype.vim file and no file in
$HOME/.vim/ftplugin directory.
In the first case, the Ctrl-] shortcut calls the tag in my ./tags file.
The
:verbose map C-] echos:
No mapping found
on the command line.
In the second case, the Ctrl-] shortcut echos :call JumpToTag_ada('')
on
the command line. The :verbose map C-] echos:
n C-] *@:call JumpToTag_ada('')CR
on the command line.
JumpToTag() lies in the default ada ftplugin:
$ grep -n -R JumpToTag_ada /usr/share/vim/
/usr/share/vim/vim63/ftplugin/ada.vim:37: nnoremap unique buffer
C-]
:call JumpToTag_ada('')cr
/usr/share/vim/vim63/ftplugin/ada.vim:40: nnoremap unique buffer
gC-] :call JumpToTag_ada('','stj')cr
/usr/share/vim/vim63/ftplugin/ada.vim:168:function!
JumpToTag_ada(word,...)
So in the first case, the C-] was no particular mapping but the default
behaviour which works.
In the second case, the C-] is mapped to the special function
JumpToTag_ada() from $VIMRUNTIME/ftplugin/ada.vim filetype plugin file.
That function is:
function! JumpToTag_ada(word,...)
if a:word == ''
Get current word
let word = AdaWord()
if word == ''
return
endif
else
let word = a:word
endif
if a:0 0
let mode = a:1
else
let mode = 'tj'
endif
let v:errmsg = ''
execute 'silent!' mode word
if v:errmsg != ''
if v:errmsg =~ '^E426:' Tag not found
let ignorecase = ignorecase
set ignorecase
execute mode word
let ignorecase = ignorecase
else
Repeat to give error
execute mode word
endif
endif
endfunction
if mapcheck('C-]','n') == ''
nnoremap unique buffer C-]:call JumpToTag_ada('')cr
endif
which is supposed to call :tj on the word under the cursor.
The word under the cursor is indeed the right one. I called an word =
AdaWord(); echo word to be sure.
The bug is in the function JumpToTag_ada().
To convince everyone, I added the following lines in my local ada.vim
ftplugin file (which overwrites that of $VIMRUNTIME)):
function! GetToTag(...)
let word = AdaWord()
execute tj word
endfunction
noremap unique buffer C-] :call GetToTag()cr
Those lines make everything work fine. So the few lines of
JumpToTag_ada()
seem to be bugged.
What to you think?
Regards,
Julien
Mappings defined in an ftplugin ought, for sanity, to have the buffer
attribute so they don't interfere with other filetypes. If the mapping
defined by the ada ftplugin remains active even when the active cursor
is in a file of a different filetype, then IMHO it's a bug in the ada
ftplugin and in that case you should contact its maintainer (look for a
comment near the top of $VIMRUNTIME/ftplugin/ada.vim).
OTOH, if you experience the disturbing behaviour _only_ when editing an
ada source file, then it could be either a bug or a feature. In that
case, since I don't know ada myself, I'm not qualified to offer an opinion.
Best regards,
Tony.
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: ftplugin not detected
[EMAIL PROTECTED] wrote: Hi Tony, That's fine, thanks. When I have some time, I'll try and have a look at the script in detail. If I have further questioning I'll then directly contact the maintainer. Regards, Julien A last word of caution (well, maybe it should have been first): don't make changes-in-place anywhere in $VIMRUNTIME or its subdirectories, because any upgrade of Vim may silently remove any changes there. If you want to owncode small changes to the ada ftplugin, place them (for Unix) in ~/.vim/after/ftplugin/ada.vim or (for Windows) in ~/vimfiles/after/ftplugin/ada.vim . Or, for system-wide changes, you can alternately place them in $VIM/vimfiles/after/ftplugin/ada.vim (all platforms). If you want to do a full top-to-bottom rewrite of the script, omit the /after/ link in the directory chain (e.g., $VIM/vimfiles/ftplugin/ada.vim). Create any not-yet-existent-but-needed directories and/or files as you go. Best regards, Tony.
Re: ftplugin not detected
[EMAIL PROTECTED] wrote:
Yes indeed. When processing with my test there was a local $HOME/.vimrc
file...snip
In the second case, the Ctrl-] shortcut echos :call JumpToTag_ada('') on
the command line. The :verbose map C-] echos:
n C-] *@:call JumpToTag_ada('')CR
on the command line.
JumpToTag() lies in the default ada ftplugin:
As A.M. said, you may contact the ada plugin maintainer.
IMHO, instead of:
if mapcheck('C-]','n') == ''
nnoremap unique buffer C-]:call JumpToTag_ada('')cr
endif
the plugin should be using: (untested, as I don't use Ada myself)
if !hasmapto('PlugJumpToTag_ada')
nno unique buffer c-] PlugJumpToTag_ada
endif
nmap silent script PlugJumpToTag_ada :call JumpToTag_ada('')cr
With the hasmapto() method, you could retain functionality by mapping
whatever
key combo you like to the the PlugJumpToTag_ada by putting
nno buffer SomeKeyComboHere PlugJumpToTag_ada
in your .vimrc file. Of course, then you'd also get the normal c-]
meaning back.
Regards,
Chip Campbell
Re: ftplugin not detected
Charles E Campbell Jr wrote:
[EMAIL PROTECTED] wrote:
Yes indeed. When processing with my test there was a local $HOME/.vimrc
file...snip
In the second case, the Ctrl-] shortcut echos :call
JumpToTag_ada('') on
the command line. The :verbose map C-] echos:
n C-] *@:call JumpToTag_ada('')CR
on the command line.
JumpToTag() lies in the default ada ftplugin:
As A.M. said, you may contact the ada plugin maintainer.
IMHO, instead of:
if mapcheck('C-]','n') == ''
nnoremap unique buffer C-]:call JumpToTag_ada('')cr
endif
the plugin should be using: (untested, as I don't use Ada myself)
if !hasmapto('PlugJumpToTag_ada')
nno unique buffer c-] PlugJumpToTag_ada
endif
nmap silent script PlugJumpToTag_ada :call JumpToTag_ada('')cr
With the hasmapto() method, you could retain functionality by mapping
whatever
key combo you like to the the PlugJumpToTag_ada by putting
nno buffer SomeKeyComboHere PlugJumpToTag_ada
in your .vimrc file. Of course, then you'd also get the normal c-]
meaning back.
Regards,
Chip Campbell
IIUC, you could also get back with another key to the old meaning of
Ctrl-] by means of, for instance,
:noremap F9 C-]
(-nore- is important here, to avoid remapping of the {rhs} ).
Best regards,
Tony.
Re: ftplugin not detected
Ok. Thanks to both of you. I'll have a look in the detail about how to properly map a command as you suggest. As for the choice of the right file to edit, do not worry, I do not have the permissions to edit the $VIMRUNTIME directory :-D At least we have got a clean Linux Box. As for my problem, there's an else case missing in the handling of the exceptions in the JumpToTag_ada() function. It forgets to deal with the usual case when the tag is found :-) : function! JumpToTag_ada(word,...) if a:word == '' Get current word let word = AdaWord() if word == '' return endif else let word = a:word endif if a:0 0 let mode = a:1 else let mode = 'tj' endif let v:errmsg = '' execute 'silent!' mode word if v:errmsg != '' if v:errmsg =~ '^E426:' Tag not found let ignorecase = ignorecase set ignorecase execute mode word let ignorecase = ignorecase else Repeat to give error execute mode word endif These two lines beneath are to be added else execute mode word End of lines to add endif endfunction I'll email the maintainer to have his opinion. Regards, Julien Internet [EMAIL PROTECTED] - 07/18/2006 02:39 PM To:Julien 3 NGUYEN cc:drchip, vim Subject:Re: ftplugin not detected [EMAIL PROTECTED] wrote: Hi Tony, That's fine, thanks. When I have some time, I'll try and have a look at the script in detail. If I have further questioning I'll then directly contact the maintainer. Regards, Julien A last word of caution (well, maybe it should have been first): don't make changes-in-place anywhere in $VIMRUNTIME or its subdirectories, because any upgrade of Vim may silently remove any changes there. If you want to owncode small changes to the ada ftplugin, place them (for Unix) in ~/.vim/after/ftplugin/ada.vim or (for Windows) in ~/vimfiles/after/ftplugin/ada.vim . Or, for system-wide changes, you can alternately place them in $VIM/vimfiles/after/ftplugin/ada.vim (all platforms). If you want to do a full top-to-bottom rewrite of the script, omit the /after/ link in the directory chain (e.g., $VIM/vimfiles/ftplugin/ada.vim). Create any not-yet-existent-but-needed directories and/or files as you go. Best regards, Tony. This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: Generic xml omnicomplete
Dnia wtorek, 18 lipca 2006 06:23, David Purton napisał: Hi all, I gather that the vim7 xml omnicomplete needs a data file to work - which is fair enough, since you can get all the attributes as well this way. But, how can I get a generic xml omnifunction system where vim will just close the last open tag for me. eg, at present, for html, I have vim set up to close the current tag as soon as I type '/' Ugh. Forgot about that. Current implementation requires all that xml stuff to close tags. Normally if you have data file you can do:: inoremap / /c-xc-o and it will close your tag. I've made corrections and sent it to Bram. In few days it should be available on vim ftp in runtime package. I will also make it available as: http://skawina.eu.org/mikolaj/xmlcomplete.vim m.
Re: Generic xml omnicomplete
Dnia wtorek, 18 lipca 2006 13:28, A.J.Mechelynck napisał: You can also assing a single-key shortcut for it, e.g. :imap F12 C-XC-O to use F12 instead of Ctrl-X plus Ctrl-O I have swapped CapsLock and left Control and use: imap C-O C-XC-O Exteremely handy :) m.
Re: ftplugin not detected
Hello,
Charles E Campbell Jr [EMAIL PROTECTED] wrote:
[...]
the plugin should be using: (untested, as I don't use Ada myself)
if !hasmapto('PlugJumpToTag_ada')
nno unique buffer c-] PlugJumpToTag_ada
endif
nmap silent script PlugJumpToTag_ada :call JumpToTag_ada('')cr
With the hasmapto() method, you could retain functionality by mapping
whatever key combo you like to the the PlugJumpToTag_ada by putting
nno buffer SomeKeyComboHere PlugJumpToTag_ada
in your .vimrc file.
The .vimrc is not suited to buffer-local definitions. One of the best solution,
IMHO, is to have a ftplugin, dedicated to settings and options, that overides
default settings.
When the definitions come from a standard ftplugin, just drop the
configuration ftplugin into ~/.vim (/ $HOME/vimfiles).
- ~/.vim/ftplugin/ada/ada_config.vim
nno buffer SomeKeyComboHere PlugJumpToTag_ada
--
Luc Hermitte
http://hermitte.free.fr/vim/
Re: netrw with hiding
On Mon 17-Jul-06 9:10am -0600, Charles E Campbell Jr wrote: Bill McCarthy wrote: (concerning updating to netrw v102i) After some struggling to get the .vba file, it installed nicely in my vimfiles/ directory. It didn't work at all until I removed the v98 distribution files: [c:\vim\vim70]zip -rm netrw98 . -i *netrw* Yes, that's why I said to be sure to remove all vestiges of older netrw. Netrw has the common to plugins feature to prevent itself from being loaded more than once. Here's my rtp setting from _vimrc: set rtp=$vim\\vimfiles,$vimruntime,$vim\\vimfiles\\after That should avoid the problem. It doesn't. The reason is that your netrwPlugin.vim in both the distribution (v98) and the latest on your site contains this line near the top in your Load Once section: if exists(g:loaded_netrw) At startup, both versions of nnetrwPlugin are sourced and things get confused. A simple solution, which appears to work fine, is to change that line (in both files) to: if exists(g:loaded_netrwPlugin) and adding a line after the 'if v:version 700' block: let g:loaded_netrwPlugin = netrw Now the update in vimfiles\ can safely coexist with the release. I noticed that some files are always missing from the list. For example, .exe .jpg .gif Why is this and how do we override? Netrw doesn't normally suppress these; I don't know why these files are missing from your listings. In fact, netrw provides a mapping for x so that the cursor selected file with one of those extensions can be visualized. After a little trial and error, I found that eliminating one line from my _vimrc solves the problem. That line is: set wildignore=*.exe,*.dll,*.jpg,*.gif,*.o,*.obj Merely because I don't want file completion on these files doesn't imply that I don't want them showing up in a directory listing. Any way around this? I see you have made a few changes in the script. One change, to determine whether cmd.exe or 4nt.exe is the shell, contains this line: if shell =~ \\%(cmd.exe\|4nt.exe\)$ That would work if you used single quotes (a literal instead of a string). But even that would not work if the user had 'noic' (the default) and 'shell' was in uppercase. Also, the '.' wildcard is not helpful. This tests fine: if shell =~ '\v%(cmd|4nt)\.exe$\c' -- Best regards, Bill
Re: posting to vim
Jason Weber wrote: Can one of you regular posters tell my how I can successfully post to [EMAIL PROTECTED] I tried my regular email, as well as the exact email I receive postings on. I also reapplied for a new account on the same address and posted again. I still don't see anything showing up on the list. Does anyone dredge the spam folder looking for problems with good honest well-meaning posters? Do you have to pay to post? Would it help? No, you don't have to pay, but you have to have a valid email address and to mention it in the From field of emails sent from that same address. Subscribing to the list is a process consisting of the following steps: 1. Send an email (whose body) may be blank to [EMAIL PROTECTED] 2. The vim-list robot will reply to whatever address was on the From line of the email sent at step 1 (so that address had better be yours), giving you further instructions on how to finalize your subscription. (This avoids the case where someone would subscribe you against your will.) You should obey the instructions in that email. Shortly after you do, the list posts should start arriving (and they are quite frequent: don't mistake this flooding of your mailbox for spam; after all, you requested it and confirmed that it was you). If someone filters your incoming email, sending mail arriving from the Vim list to the trash bin before you see it, then I guess you should either make your spam filters less strict (possibly by complaining to whoever is responsible for setting the filters), or if you can't, take a different email address. You might even try something that you can read by webmail (i.e., by using a web browser, not a mail client: e.g. @netscape.net, @yahoo.co.uk, etc.) so you can bypass all filters including those built into your company's mail routers. For more details, browse to http://www.vim.org/ and click Community in the left margin. Best regards, Tony.
Re: Generic xml omnicomplete
Mikolaj Machowski wrote: Dnia wtorek, 18 lipca 2006 06:23, David Purton napisał: Hi all, I gather that the vim7 xml omnicomplete needs a data file to work - which is fair enough, since you can get all the attributes as well this way. But, how can I get a generic xml omnifunction system where vim will just close the last open tag for me. eg, at present, for html, I have vim set up to close the current tag as soon as I type '/' Ugh. Forgot about that. Current implementation requires all that xml stuff to close tags. Normally if you have data file you can do:: inoremap / /c-xc-o and it will close your tag. I've made corrections and sent it to Bram. In few days it should be available on vim ftp in runtime package. I will also make it available as: http://skawina.eu.org/mikolaj/xmlcomplete.vim m. IMHO, inoremapping / to /C-XC-O might be included as a vim-online tip but definitely not as part of the standard XML/HTML filetype plugins. Include it at the appropriate place under ~/.vim/after/ if you want to; I hope Bram will have the sense _not_ no make it part of the standard $VIMRUNTIME distribution. Remember also that if you include that mapping, you won't see the of an _opening_ tag until after you've typed the ! of a !-- comment or the first letter of the tag name. Best regards, Tony.
Re: colors
As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall On Jul 17, 2006, at 7:01 PM, A.J.Mechelynck wrote: Bill Hollingsworth wrote: Hi, I recently upgraded to VIM 7.0 and now the color settings for my PERL programs are different. I liked the way the colors were before. Could someone tell me how to return to the old settings, or how to set the colors myself? For instance, now comments and variable names are the same color. Thanks and best wishes, Bill Hollingsworth University of Cambridge Computer Laboratory I guess the easiest way is to write your own colorscheme. For instance I use the attached colorscheme which I wrote, named $HOME/.vim/colors/almost-default.vim and invoked by :colorscheme almost-default. It is a simple example which might help you create your own. You will have to find out the names of the highlight groups for which you need a non-default color. (Try Comment and Identifier; I guess changing them will also change perlComment and PerlIdentifier, or however they are named). You can set different colors for console Vim and gvim by using, in the same :highlight command, arguments cterm= ctermfg= ctermbg= on the one hand, and gui= guibg= guifg= onthe other hand. There are also a number of colorschemes available in your distribution (in $VIMRUNTIME/colors) and at vim-online (which can be installed by dropping them in one of the following: - system-wide: $VIM/vimfiles/colors - user-private on Unix: ~/.vim/colors - user-private on Windows: ~/vimfiles/colors ). Don't change anything in $VIMRUNTIME or its subdirs, because any upgrade can silently overwrite any changes you made there. See :help :highlight :help :colorscheme :view $VIMRUNTIME/colors/README.txt HTH, Tony. Vim color file Maintainer: Tony Mechelynck [EMAIL PROTECTED] Last Change: 2006 Jun 21 This is almost the default color scheme. It doesn't define the Normal highlighting, it uses whatever the colors used to be. Only the few highlight groups named below are defined; the rest (most of them) are left at their compiled-in default settings. Set 'background' back to the default. The value can't always be estimated and is then guessed. hi clear Normal set bg Remove all existing highlighting and set the defaults. hi clear Load the syntax highlighting defaults, if it's enabled. if exists(syntax_on) syntax reset endif Set our own highlighting settings hi Errorguibg=red guifg=black hi clear ErrorMsg hi link ErrorMsg Error hi StatusLine gui=NONE,bold guibg=red guifg=white hi StatusLineNC gui=reverse,bold hi TabLine gui=NONEguibg=#DD guifg=black hi TabLineFill gui=NONEguibg=#AA guifg=red hi User1ctermfg=magenta guibg=white guifg=magenta hi User2ctermfg=darkmagenta guibg=#DD guifg=magenta remember the current colorscheme name let colors_name = almost-default vim: sw=2
Re: ftplugin not detected
[EMAIL PROTECTED] wrote:
Hello,
Charles E Campbell Jr [EMAIL PROTECTED] wrote:
[...]
the plugin should be using: (untested, as I don't use Ada myself)
if !hasmapto('PlugJumpToTag_ada')
nno unique buffer c-] PlugJumpToTag_ada
endif
nmap silent script PlugJumpToTag_ada :call JumpToTag_ada('')cr
With the hasmapto() method, you could retain functionality by mapping
whatever key combo you like to the the PlugJumpToTag_ada by putting
nno buffer SomeKeyComboHere PlugJumpToTag_ada
in your .vimrc file.
The .vimrc is not suited to buffer-local definitions. One of the best solution,
IMHO, is to have a ftplugin, dedicated to settings and options, that overides
default settings.
When the definitions come from a standard ftplugin, just drop the
configuration ftplugin into ~/.vim (/ $HOME/vimfiles).
- ~/.vim/ftplugin/ada/ada_config.vim
probably in ~/.vim/after/ftplugin/ada.vim (see :help after-directory)
for small tweaks not requiring a full aye-to-zed rewrite of the whole
ftplugin.
nno buffer SomeKeyComboHere PlugJumpToTag_ada
--
Luc Hermitte
http://hermitte.free.fr/vim/
Re: ftplugin not detected
A.J.Mechelynck [EMAIL PROTECTED] wrote: [...] The .vimrc is not suited to buffer-local definitions. One of the best solution, IMHO, is to have a ftplugin, dedicated to settings and options, that overides default settings. When the definitions come from a standard ftplugin, just drop the configuration ftplugin into ~/.vim (/ $HOME/vimfiles). - ~/.vim/ftplugin/ada/ada_config.vim nno buffer SomeKeyComboHere PlugJumpToTag_ada probably in ~/.vim/after/ftplugin/ada.vim (see :help after-directory) for small tweaks not requiring a full aye-to-zed rewrite of the whole ftplugin. In that particular case [*], not using the after sub-hierarchy avoids the mapping to the default key-binding. [*] when there is a PlugSomething, and that its definition is protected with hasmapto() as Charles suggested. -- Luc Hermitte
Re: Website Sign-up
Perhaps out of respect for the people and the skill of the people who are knowledgeable enough and have the skills to contribute material to the site that benefit the rest of us so much. The site that people who ask this kind of question just slurp up and devour the information but do not have the class, upbringing or respect to even bother to register or log in. On 17 Jul 2006, at 01:25, Vigil wrote: I hate sites that have the ability to log in but don't tell you why, so: why should I register on vim.org? -- .
Re: colors
Marshall Abrams wrote: As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall My answer to that (and it is a personal opinion, not a dogma) is that most of the alphabetic keys (with or without Shift or Ctrl) are already assigned in standard Vim (including gg for go to top if you don't like the hand movement and Shift chord required by 1G), and more of them if possible are likely to get mapped in the future, so it's risky business at best to try mapping one's own functions to them. An infamous example of the latter is the mswin.vim plugin, which overrides several of the Ctrl-letter keys with its own Windows-like mappings, thus obliterating many useful Vim keystrokes. OTOH, the F keys (other than F1 and sometimes F10) are available by default; so my advice is to map user-defined mappings to F keys with or without Shift/Ctrl/Alt, and mappings defined in unofficial plugins to multikey sequences starting with Leader LocalLeader etc. Best regards, Tony.
www.vim.org ?
Did http://www.vim.org - http://vim.sf.net redirection stopped working ? Yakov
Re: posting to vim
Jason Weber wrote: Can one of you regular posters tell my how I can successfully post to [EMAIL PROTECTED] I tried my regular email, as well as the exact email I receive postings on. I also reapplied for a new account on the same address and posted again. I still don't see anything showing up on the list. Does anyone dredge the spam folder looking for problems with good honest well-meaning posters? Do you have to pay to post? Would it help? No, you don't have to pay, but you have to have a valid email address and to mention it in the From field of emails sent from that same address. Subscribing to the list is a process consisting of the following steps: 1. Send an email (whose body) may be blank to [EMAIL PROTECTED] 2. The vim-list robot will reply to whatever address was on the From line of the email sent at step 1 (so that address had better be yours), giving you further instructions on how to finalize your subscription. (This avoids the case where someone would subscribe you against your will.) You should obey the instructions in that email. Shortly after you do, the list posts should start arriving (and they are quite frequent: don't mistake this flooding of your mailbox for spam; after all, you requested it and confirmed that it was you). If someone filters your incoming email, sending mail arriving from the Vim list to the trash bin before you see it, then I guess you should either make your spam filters less strict (possibly by complaining to whoever is responsible for setting the filters), or if you can't, take a different email address. You might even try something that you can read by webmail (i.e., by using a web browser, not a mail client: e.g. @netscape.net, @yahoo.co.uk, etc.) so you can bypass all filters including those built into your company's mail routers. For more details, browse to http://www.vim.org/ and click Community in the left margin. Best regards, Tony. Assuming this works, I've found my problem. I was receiving vim postings through an alias [EMAIL PROTECTED] while I always send from [EMAIL PROTECTED] I re-subscribed and noticed the difference in the header of a duplicate message. As for the spam folder, I meant does anyone admin'ing the list look through the rejects to see if anyone is making honest mistakes? Imagining the mountains of spam that must come through, I'm guessing no. That's ok. No complaints, now that I see what's going on. -- Jason Weber
Re: Generic xml omnicomplete
On 7/18/06, David Purton [EMAIL PROTECTED] wrote: But, how can I get a generic xml omnifunction system where vim will just close the last open tag for me. It's not the vim7 way, but I use Devin Weaver's xmledit [1]. I strongly prefer automatically closing tags as they're created. [1] http://www.vim.org/scripts/script.php?script_id=301
Re: www.vim.org ?
Yakov Lerner wrote: Did http://www.vim.org - http://vim.sf.net redirection stopped working ? Yakov Dunno. Here, http://www.vim.org/ and http://vim.sourceforge.net/ give identical pages, except for the contents of the URL bar. OTOH, http://vim.sf.net/ redirects to http://vim.sourceforge.net/ (changing the URL bar to the latter). Apparently, www.vim.org means 66.35.250.210 while vim.sourceforge.net means 66.35.250.209 -- for broader bandwidth maybe? A side-effect is that my browser has to separately remember identical username/password pairs for www.vim.org and vim.sourceforge.net, since it doesn't know that they access the same site. Best regards, Tony.
Re: posting to vim
Jason Weber wrote: As for the spam folder, I meant does anyone admin'ing the list look through the rejects to see if anyone is making honest mistakes? Imagining the mountains of spam that must come through, I'm guessing no. That's ok. As I understand things, vim.sf.net is minimally maintained. Some folks have had problems in getting off the mailing list, for example, and there's essentially no administrator willing to take the time to do that. My impression, which may well be utterly wrong, is that the owners of the machine supporting the site are willing to reboot the machine when necessary. Regards, Chip Campbell
Re: posting to vim
Jason Weber wrote: [...] As for the spam folder, I meant does anyone admin'ing the list look through the rejects to see if anyone is making honest mistakes? Imagining the mountains of spam that must come through, I'm guessing no. That's ok. No complaints, now that I see what's going on. -- Jason Weber The functioning of the Vim mailing lists is almost fully automatic. AFAIK, a human never looks into it unless a very very serious bug is noticed and brought to Bram's (or someone's) attention. If a posting arrives in HTML, or from an unsubscribed address, it is just silently discarded with no reply, as if it had never existed. Best regards, Tony.
Re: posting to vim
Charles E Campbell Jr wrote: Jason Weber wrote: As for the spam folder, I meant does anyone admin'ing the list look through the rejects to see if anyone is making honest mistakes? Imagining the mountains of spam that must come through, I'm guessing no. That's ok. As I understand things, vim.sf.net is minimally maintained. Some folks have had problems in getting off the mailing list, for example, and there's essentially no administrator willing to take the time to do that. My impression, which may well be utterly wrong, is that the owners of the machine supporting the site are willing to reboot the machine when necessary. Regards, Chip Campbell ;-) ... which maybe very rarely, since I've heard talk of Unix machines running for years on end without a reboot. (Unbelieveable to a Windows user.) Maybe they don't even ever reboot unless they have to upgrade the kernel, or unless there is a power outage (in which case the machine may well be set up to reboot automatically when the power comes back). ;-) Best regards, Tony.
Re: www.vim.org ?
Yakov Lerner wrote: Did http://www.vim.org - http://vim.sf.net redirection stopped working ? Doesn't look like there is a problem now. Sourceforge does appear to have problems with their servers and they fix it quite slowly. -- How To Keep A Healthy Level Of Insanity: 8. Don't use any punctuation marks. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: How to distinguish [L]esen ( Readonly) from (L)öschen (Delete) ?
Hi, Georg Dahn wrote: Hi! --- Andre Massing [EMAIL PROTECTED] wrote: probably a rather stupid question, but using german language makes it impossible for me to choose (L)öschen (Delete) instead of [L]esen (Readonly) by typing just l if there exists a swap-file from a chrashed session. This is an error of the german translation, which unfortunately has been noticed only after the release of Vim 7.0. Since I am the maintainer of the German translation for some months now, I am very sorry for this inconvenience. There is a newer file on the FTP server of Vim: http://ftp.vim.org/editors/vim/messages/de.po Just compile this and replace the distributed version with the compiled version of the latest messages. If you cannot compile it yourself, be free to ask me for my compiled version (I have compiled it under MS Windows, thus I am not sure, if it will work on Linux, too). I fetched the file and recompiled vim, it works pretty fine now (under Linux), so thanks a lot! Regards, Andre
Using :g to delete patterns that span multiple lines
I used this pattern to select sections of test that belong to me
when CVS or SVN generates a merge conflict. This pattern works fine:
/^\_.\{-}===.*$/
I have search highlighting turned on and I can see the multiline
patterns get highlighted as expected.
Then I tried to delete all of those highlighted areas by using
the global command:
:g//d
This didn't work. It would delete the FIRST line of the pattern match, but
leave all the other lines. So I figured that maybe there was some trick to
using // to recall the last search pattern that I was not aware of, so
I tried typing in the pattern to :g:
:g/^\_.\{-}===.*$/d
Again, this would only delete the first line of the pattern match.
From the vim :g documentation I read this:
The global commands work by first scanning through the [range] lines and
marking each line where a match occurs (for a multi-line pattern, only the
start of the match matters).
What is the best way to do what I am trying to do?
I want to delete all text that matches a pattern, including
multi-line patterns.
Yours,
Noah
Firefox and VIM?
When is someone going to write a VIM plugin for Mozilla Firefox? Yours, Noah :wq
Re: Firefox and VIM?
On 18/07/06, Noah Spurrier [EMAIL PROTECTED] wrote: When is someone going to write a VIM plugin for Mozilla Firefox? Yours, Noah :wq Excellent question. It'd be nice to be able to use vim to edit emails in google mail, for example. MC
Re: Using :g to delete patterns that span multiple lines
Noah Spurrier wrote:
I used this pattern to select sections of test that belong to me
when CVS or SVN generates a merge conflict. This pattern works fine:
/^\_.\{-}===.*$/
I have search highlighting turned on and I can see the multiline
patterns get highlighted as expected.
Then I tried to delete all of those highlighted areas by using
the global command:
:g//d
This didn't work. It would delete the FIRST line of the pattern match, but
leave all the other lines. So I figured that maybe there was some trick to
using // to recall the last search pattern that I was not aware of, so
I tried typing in the pattern to :g:
:g/^\_.\{-}===.*$/d
Again, this would only delete the first line of the pattern match.
From the vim :g documentation I read this:
The global commands work by first scanning through the [range] lines and
marking each line where a match occurs (for a multi-line pattern, only the
start of the match matters).
What is the best way to do what I am trying to do?
I want to delete all text that matches a pattern, including
multi-line patterns.
Yours,
Noah
Try the :s command, defining a pattern matching characterwise what you
want to delete, possibly including the ending linebreak, and replacing
it by nothing.
(Untested)
:1,$s/^\_.\{-}===.*\n//
Best regards,
Tony.
Re: Firefox and VIM?
Noah Spurrier wrote: When is someone going to write a VIM plugin for Mozilla Firefox? Yours, Noah :wq You can use Vim as external editor. Depending on which extensions you have, you can use it for userChrome.css, userContent.css, possibly even textareas in forms. Try the External Editor and/or MR-Tech Local Install extensions; and maybe others -- I haven't reviewed them all in detail. Best regards, Tony.
Re: Firefox and VIM?
On 7/19/06, Noah Spurrier [EMAIL PROTECTED] wrote: When is someone going to write a VIM plugin for Mozilla Firefox? For Mozilla Mozilla browser, such thing exists -- http://mozex.mozdev.org (i say mozilla mozilla to distinguish it from mozilla firefox :-) For Firefox, I'm not sure. Yakov
Re: Firefox and VIM?
Right, mozex for firefox is at https://addons.mozilla.org/firefox/40/ But it seems not maintained for a long time Yakov On 7/19/06, Max Dyckhoff [EMAIL PROTECTED] wrote: From that very page: Mozex works with both Mozilla and Firebird. Interesting, I might try that out! Max -Original Message- From: Yakov Lerner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 3:28 PM To: Noah Spurrier Cc: vim@vim.org Subject: Re: Firefox and VIM? On 7/19/06, Noah Spurrier [EMAIL PROTECTED] wrote: When is someone going to write a VIM plugin for Mozilla Firefox? For Mozilla Mozilla browser, such thing exists -- http://mozex.mozdev.org (i say mozilla mozilla to distinguish it from mozilla firefox :-) For Firefox, I'm not sure. Yakov
Key mappings (was: Re: colors)
On Jul 18, 2006, at 2:33 PM, A.J.Mechelynck wrote: Marshall Abrams wrote: As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall My answer to that (and it is a personal opinion, not a dogma) is that most of the alphabetic keys (with or without Shift or Ctrl) are already assigned in standard Vim I have noticed that, but I'm not a fan of it. Fortunately, I rarely need the functions assigned to g+something. I occasionally undo my q mapping in order to record a macro. (including gg for go to top if you don't like the hand movement and Shift chord required by 1G), and more of them if possible are likely to get mapped in the future, so it's risky business at best to try mapping one's own functions I was mapping g long before vim started mapping things to it. So from my point of view, it was the developers who engaged in risky behavior. (Let me emphasize that I remain extremely grateful.) to them. An infamous example of the latter is the mswin.vim plugin, which overrides several of the Ctrl-letter keys with its own Windows-like mappings, thus obliterating many useful Vim keystrokes. OTOH, the F keys (other than F1 and sometimes F10) are available by default; so my advice is to map user-defined mappings to F keys with or without Shift/Ctrl/Alt, and mappings defined in unofficial plugins to multikey sequences starting with Leader LocalLeader etc. Uggh. F-keys. That's why I kept using Emacs for a long time. Why I switched to vi for even greater ease. So my fingers wouldn't have to leave the letter keys. (Esc is an exception, but easy to slap.) Same reason I don't like editors that make essential use of the mouse. Let nothing intervene between thought and text. Best regards, Tony. Oh well. Thanks Tony. Marshall
Re: Firefox and VIM?
* Yakov Lerner [EMAIL PROTECTED] [060719 00:50]: Right, mozex for firefox is at https://addons.mozilla.org/firefox/40/ But it seems not maintained for a long time Try the ViewSourceWith (http://dafizilla.sourceforge.net/viewsourcewith/) extension. It supports editing textareas with a configurable external editor. -- Regards, Andi
RE: colors
I am afraid that I have to agree with the complaint against drastically changing the default color scheme. As a sight-impaired user I relied on the color scheme that I was using before version 7.0. I did not create it myself; I developed my own convention for using the color scheme that was there as a default. Now that the colors have change in a bad way (e.g. PERL comments are the same color as PERL variables) I do not have time to invest in learning how to program a new color scheme. My only solution right now is to try to uninstall VIM and reinstall the old version. For future versions I would encourage developers to offer changes to default settings only as an option. There is of course the standards issue, but there is also an accessibility issue that might not have been considered. Bill Hollingsworth University of Cambridge Computer Laboratory Original Message Subject: Re: colors From: A.J.Mechelynck [EMAIL PROTECTED] Date: Tue, July 18, 2006 7:33 pm To: Marshall Abrams [EMAIL PROTECTED] Cc: vim@vim.org Marshall Abrams wrote: As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall My answer to that (and it is a personal opinion, not a dogma) is that most of the alphabetic keys (with or without Shift or Ctrl) are already assigned in standard Vim (including gg for go to top if you don't like the hand movement and Shift chord required by 1G), and more of them if possible are likely to get mapped in the future, so it's risky business at best to try mapping one's own functions to them. An infamous example of the latter is the mswin.vim plugin, which overrides several of the Ctrl-letter keys with its own Windows-like mappings, thus obliterating many useful Vim keystrokes. OTOH, the F keys (other than F1 and sometimes F10) are available by default; so my advice is to map user-defined mappings to F keys with or without Shift/Ctrl/Alt, and mappings defined in unofficial plugins to multikey sequences starting with Leader LocalLeader etc. Best regards, Tony.
Re: Generic xml omnicomplete
Hi Tony, On Tue, Jul 18, 2006 at 01:28:22PM +0200, A.J.Mechelynck wrote: David Purton wrote: Hi all, I gather that the vim7 xml omnicomplete needs a data file to work - which is fair enough, since you can get all the attributes as well this way. But, how can I get a generic xml omnifunction system where vim will just close the last open tag for me. eg, at present, for html, I have vim set up to close the current tag as soon as I type '/' cheers dc Such generic xml/html ftplugins are distributed with Vim. You must activate them by having one (not all) of the following lines in your vimrc: filetype plugin on filetype plugin indent on source $VIMRUNTIME/vimrc_example.vim runtime vimrc_example.vim [SNIP] Ah - it seems I'm missing something. I have this sort of thing in my .vimrc already and omni-complete works just fine for any xml type that has an xml-omni-datafile in autoload/xml. But what about xml data types that do not have a datafile? eg, when I do something like this: $ touch foo.xml $ vim foo.xml Then enter in the following into vim: ?xml version=1.0 encoding=UTF-8? foo /C-XC-O omni complete doesn't work. I get: -- Omni completion (^O^N^P) Pattern not found I first need to use :XMLns *something* Then tag completion works. The *something* just needs to be one of the datafiles - doesn't seem to matter which one. But of course there is extraneous info in these data files. For the simple case above, all I want is tag completion. Does that make sense? cheers dc -- David Purton Haese Harris Publications Phone: +61 8 8355 9444Email: [EMAIL PROTECTED] Fax: +61 8 8355 9471Web: http://www.haeseandharris.com.au/
Re: Generic xml omnicomplete
Hi Mikolaj, On Tue, Jul 18, 2006 at 06:48:38PM +0200, Mikolaj Machowski wrote: Dnia wtorek, 18 lipca 2006 06:23, David Purton napisał: Hi all, I gather that the vim7 xml omnicomplete needs a data file to work - which is fair enough, since you can get all the attributes as well this way. But, how can I get a generic xml omnifunction system where vim will just close the last open tag for me. eg, at present, for html, I have vim set up to close the current tag as soon as I type '/' Ugh. Forgot about that. Current implementation requires all that xml stuff to close tags. Normally if you have data file you can do:: inoremap / /c-xc-o and it will close your tag. I've made corrections and sent it to Bram. In few days it should be available on vim ftp in runtime package. I will also make it available as: http://skawina.eu.org/mikolaj/xmlcomplete.vim Perfect. Thanks for fixing this. cheers dc -- David Purton Haese Harris Publications Phone: +61 8 8355 9444Email: [EMAIL PROTECTED] Fax: +61 8 8355 9471Web: http://www.haeseandharris.com.au/
RE: colors
Hi Bill, You do not have to program a new colorscheme. If you run this command: :source $VIMRUNTIME/syntax/hitest.vim ... you will get a window containing all the highlighting colours used by Vim. There's hundreds of colours listed, but there are prossibly only two that you want to change, under the 'Syntax Highlighting Groups' section. Add something like this to your ~/.vimrc change default colors for color terminal highlight Comment ctermfg=Blue cterm=Underline highlight Identifier ctermfg=Red cterm=Bold change default colors for GUI highlight Comment guifg=Blue gui=Underline highlight Identifier guifg=Red gui=Bold It shouldn't be too difficult to change those colors to something which works for you. I hope you don't have to go back to using Vim 6.4. I am afraid that I have to agree with the complaint against drastically changing the default color scheme. As a sight-impaired user I relied on the color scheme that I was using before version 7.0. I did not create it myself; I developed my own convention for using the color scheme that was there as a default. Now that the colors have change in a bad way (e.g. PERL comments are the same color as PERL variables) I do not have time to invest in learning how to program a new color scheme. My only solution right now is to try to uninstall VIM and reinstall the old version. I can see your point and it is concerning that the colour change is enough to force you to go back to Vim 6.4, but Bram (or any software package author) must reserve privileges to change things and make them the default, otherwise everyone gets a Vim 7.0 which behaves exactly like 6.4 and 70% of the user base doesn't have the time or knowledge to find and activate the new features. I regularly confront this issue as I write the PHP syntax as I must decided whether to A) make a feature ON by default and frustrate lots of people; or B) make a feature OFF by default so that no one gets annoyed, but risk that many people will miss out on that feature because they don't know how to turn it on. regards, Peter On Yahoo!7 Messenger - Make free PC-to-PC calls to your friends overseas. http://au.messenger.yahoo.com
Re: Firefox and VIM?
Mozex is still supported for Firefox. Here's where you can download it: * https://nic-nac-project.de/~kaosmos/mozex107-en.html ...and here's how you can configure it with gnome-terminal: * http://blogs.sun.com/roller/page/alanbur/20041007#making_those_long_weblog_posts ...and here's what's in my Textareas field on Windows XP: * C:\PROGRA~1\vim\vim70\gvim.exe %t HTH! Tom Purl On Wed, Jul 19, 2006 at 01:39:07AM +0300, Yakov Lerner wrote: Right, mozex for firefox is at https://addons.mozilla.org/firefox/40/ But it seems not maintained for a long time Yakov On 7/19/06, Max Dyckhoff [EMAIL PROTECTED] wrote: From that very page: Mozex works with both Mozilla and Firebird. Interesting, I might try that out! Max -Original Message- From: Yakov Lerner [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 18, 2006 3:28 PM To: Noah Spurrier Cc: vim@vim.org Subject: Re: Firefox and VIM? On 7/19/06, Noah Spurrier [EMAIL PROTECTED] wrote: When is someone going to write a VIM plugin for Mozilla Firefox? For Mozilla Mozilla browser, such thing exists -- http://mozex.mozdev.org (i say mozilla mozilla to distinguish it from mozilla firefox :-) For Firefox, I'm not sure. Yakov
Re: A card game for Vim
First of all, thanks a lot for trying it, you are the only who showed enthusism until now :) See below for my responses. On Wed, 19 Jul 2006 at 12:02am, Mikolaj Machowski wrote: Dnia wtorek, 18 lipca 2006 03:57, Hari Krishna Dara napisa³: I am creating a new card game for Vim7 and wonder if anyone is interested to try it and give me feedback. The game is quite usable at the current state, though there are some pending issues. Here are a couple of snapshots of the game to get you interested: http://haridara.googlepages.com/arimona.html http://haridara.googlepages.com/arimona-middle.html I have only tried the game so far on Windows, and the Unicode symbols that the game requires are found to be in the following fonts (out of those that I have installed): Works perfectly on Linux with always present families: Nimbus, Bitstream/DejaVu. Thanks, I will note this down. Unlike in solitaire however, you can't move cards back from foundation. Unpossibility to break stack into parts is feature or bug? If feature not in rules would be handy. (Stack is sequence of eg. 6432 and I want to move only 32 to uncover 4). It is a feature (restriction), and that is how the game behaved on t68i phone. As you said, I should mention this in the rules. The game changes the global 'encoding' to utf-8, as it uses the Unicode symbols to show the card symbols. I don't know the complete impact of this on an existing Vim session, Possibly disastrous. No, Arimona didn't destroy anything - just wrong experiences from the past. In which case, there should probably be an option to use letters instead of symbols to represent suits, to avoid starting a fresh Vim instance. Thanks, much fun :) m. ps. Any plans for final animation? ;) I don't know how easy it is going to be, but I would rather spend time in writing a different game (say solitaire). -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: colors
Peter Hodge [EMAIL PROTECTED] wrote on 2006.07.19 09:32:47: I can see your point and it is concerning that the colour change is enough to force you to go back to Vim 6.4, but Bram (or any software package author) must reserve privileges to change things and make them the default, otherwise everyone gets a Vim 7.0 which behaves exactly like 6.4 and 70% of the user base doesn't have the time or knowledge to find and activate the new features. I regularly confront this issue as I write the PHP syntax as I must decided whether to A) make a feature ON by default and frustrate lots of people; or B) make a feature OFF by default so that no one gets annoyed, but risk that many people will miss out on that feature because they don't know how to turn it on. regards, Peter Hi Peter, My opinion is: if I can live with the previous version, then that's it, and I certainly can live with the new version without the new features turn on by default. If there is something I cannot live with in the previous version, or if I feel I must have the new feature, then I will try to find how to turn it on. Any way, Vim is not an editor which people can learn without any effort, do you think those who are willing to spend time to learn Vim do not want to learn the new features they DO want? If I do really want the feature, I will try to find how to turn it on, otherwise, I'd rather the authors just leave it OFF. For example, after installed Vim 7.0 I found the cursor movement become unacceptably slow, I spend too much time, finally I found its due to the matchparen plugin, and I spend much more time to find how to disable it in an elegant way. if the new feature are OFF by default, my life would have been much easier. Again, after installed Vim 7.0, the VisVim behaves strange, and have a high chance not opening the specified file at all. I don't know where the problem is, so I have to use Vim 6.4 with VS.
