Re: Multiple syntax behaviour inside a file
On 6/5/07, Fabien Meghazi [EMAIL PROTECTED] wrote:
Hi all,
I would like to know if it's possible to do this crazy thing with vim :
I have a bunch of xml files wich contains template of many different
type of text : html, css, ruby, javascript, ...
Here's what it looks like :
?xml version=1.0?
templates
t name=test_css type=css
body {
background: white;
}
/t
t name=test_js type=javascript
function test(s) {
console.log(s);
}
/t
t name=test_html type=html
html
body
Test
/body
/html
/t
/templates
I guess the answer is no but I would like to know if it's possible
to make vim use different syntax highlighting and different folding
rules for each type of code ?
I've written a vim-help syntax file that does this for code examples,
e.g. perl, vim script, sh. Look at the syn-include section of the
syntax.txt helpfile.
--
Ian Tegebo
Re: Syntax highlightning
On 5/16/07, Meier Zwei [EMAIL PROTECTED] wrote: Hi list, I'm currently customizing my one syntax file for C and C++. Therby I don't understand one little detail: How can I outline C functions? I didn't find a syntax file that does similar. What do you mean by outline? There is a vimscript that creates a sidebar containing folds. It then tries to indent them based on fold level: http://www.vim.org/scripts/script.php?script_id=500 Many filetype plugins for code create folds for each function so this should provide a way to create function outlines. -- Ian Tegebo
Re: How to make a replacer function
On 5/14/07, fREW [EMAIL PROTECTED] wrote: How does one make a function that will surround a visual selection? Example: Hello, my name is fREW. Select my name and say, :Bang() and the text should now be Hello, bmy name/b is fREW. I presume it will have something to do with using ' and ', but beyond that I am not really sure. Thanks! -fREW Have you seen the surround plugin? http://www.vim.org/scripts/script.php?script_id=1697 -- Ian Tegebo
Re: VimWiki - again - but with a brand new option
On 5/8/07, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-05-08, Ian Tegebo [EMAIL PROTECTED] wrote: On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. I was assuming the wiki that would be chosen would allow for some level of access control. I'm also assuming a group of trusted long-time users could be delegated the responsibility of administering the wiki. If Bram is the only one who should make changes to an object than I agree that those objects wouldn't be useful in a wiki. I think it's possible to have a protected part of the wiki for helpfiles that is write restricted and have another part that is more open that can easily reference those files. Of course, if the value added by more hands on the helpfiles doesn't exceed the cost in maintenance than this is a poor choice. I don't think I've really seen any issues with updates to helpfiles, they were just an example. So far I think the point was to just be able to link to parts of them more easily - I didn't really mean to dwell on the help system. I was just hoping to carry the point that wikis _can_ provide a lot of valuable function if properly cultivated. In all this I've lost track of what the purpose of a VimWiki would be. Was it just meant to host vim tips? Thinking about the format of tips now, I wonder if a blog format wouldn't be more suitable. For example, tips are posts that then have comments while most blogs have these features as well as search and RSS. VimBlog? To this end I wonder if there are enough people to support more apps given the work load the vimonline team has: Bugs https://sourceforge.net/tracker/?atid=391887group_id=27891func=browse Features https://sourceforge.net/tracker/?atid=391890group_id=27891func=browse -- Ian Tegebo
Re: VimWiki - again - but with a brand new option
On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: On 5/6/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Independent of the implementation used, I suggest to develop good guidelines. The Wiki should be really valuable and not redundant to vim-tips or mailing-lists. I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. Please use the wiki for tips. That is an addition to the help files. For example, I would love to be able to quickly correct spelling mistakes or contribute to plugin helpfiles a la a Wiki interface. I could then imagine updating my local helpfiles through the Wiki interface via a sync-plugin. If you see spelling mistakes in the help files please send them to me. I just fixed 250 of them, because someone send me a list. That's useful for everyone. The main goal now is to get the Vim tips collection back to live. It has been dead for three months now! Does the VimOnline team want help? How does one sign up? There are a lot of bugs at the sourceforge site that aren't triaged. Some are misdirected vim-dev@/vim@ posts. -- Ian Tegebo
Re: VimWiki - again - but with a brand new option
On 5/8/07, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-05-08, Ian Tegebo [EMAIL PROTECTED] wrote: On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. I was assuming the wiki that would be chosen would allow for some level of access control. I'm also assuming a group of trusted long-time users could be delegated the responsibility of administering the wiki. If Bram is the only one who should make changes to an object than I agree that those objects wouldn't be useful in a wiki. I think it's possible to have a protected part of the wiki for helpfiles that is write restricted and have another part that is more open that can easily reference those files. Of course, if the value added by more hands on the helpfiles doesn't exceed the cost in maintenance than this is a poor choice. I don't think I've really seen any issues with updates to helpfiles, they were just an example. So far I think the point was to just be able to link to parts of them more easily - I didn't really mean to dwell on the help system. I was just hoping to carry the point that wikis _can_ provide a lot of valuable function if properly cultivated. In all this I've lost track of what the purpose of a VimWiki would be. Was it just meant to host vim tips? Thinking about the format of tips now, I wonder if a blog format wouldn't be more suitable. For example, tips are posts that then have comments while most blogs have these features as well as search and RSS. VimBlog? To this end I wonder if there are enough people to support more apps given the work load the vimonline team has: Bugs https://sourceforge.net/tracker/?atid=391887group_id=27891func=browse Features https://sourceforge.net/tracker/?atid=391890group_id=27891func=browse -- Ian Tegebo
Re: VimWiki - again - but with a brand new option
On 5/6/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Independent of the implementation used, I suggest to develop good guidelines. The Wiki should be really valuable and not redundant to vim-tips or mailing-lists. I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. For example, I would love to be able to quickly correct spelling mistakes or contribute to plugin helpfiles a la a Wiki interface. I could then imagine updating my local helpfiles through the Wiki interface via a sync-plugin. The Wiki would ideally understand how to link to vim-scripts and vim-tips like vimonline currently does. As a bonus, mailing-list posts would also linkable and magical indexing would populate the bottom of each Wiki page with relevant search results from the list similar to O'Reilly's Safari. It's fun to dream! I'm serious about getting the helpfiles imported into the Wiki though. I know about the VimDoc project; I think this could be the next evolution in that direction. http://vimdoc.sourceforge.net/htmldoc/usr_toc.html -- Ian Tegebo
Re: VimWiki - again - but with a brand new option
On 5/6/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Independent of the implementation used, I suggest to develop good guidelines. The Wiki should be really valuable and not redundant to vim-tips or mailing-lists. I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. For example, I would love to be able to quickly correct spelling mistakes or contribute to plugin helpfiles a la a Wiki interface. I could then imagine updating my local helpfiles through the Wiki interface via a sync-plugin. The Wiki would ideally understand how to link to vim-scripts and vim-tips like vimonline currently does. As a bonus, mailing-list posts would also linkable and magical indexing would populate the bottom of each Wiki page with relevant search results from the list similar to O'Reilly's Safari. It's fun to dream! I'm serious about getting the helpfiles imported into the Wiki though. I know about the VimDoc project; I think this could be the next evolution in that direction. http://vimdoc.sourceforge.net/htmldoc/usr_toc.html -- Ian Tegebo
Re: vim 7.1?
On 4/28/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: On 4/27/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Jonathan Smith wrote: With the insane number of patches collecting against 7.0, and presumably the new features accumulating in the devel tree, is anyone thinking about when a 7.1 release might be made? Yeah, it's about time for Vim 7.1. Unfortunately I haven't found a good moment to make a new release. And I don't see it happening in the coming weeks either... Would it be possible for people to help make new releases? You can certainly help fixing bugs. There is about a hundred of them at the top of the todo list. Is the most updated TODO list for bug fixes and features vim -c ':help todo.txt' on a fresh build? -- Ian Tegebo
vi-improved.org domain needs renewal
Has anyone else noticed that http://www.vi-improved.org/ expired about a week ago? -- Ian Tegebo
Re: vim 7.1?
On 4/27/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Jonathan Smith wrote: With the insane number of patches collecting against 7.0, and presumably the new features accumulating in the devel tree, is anyone thinking about when a 7.1 release might be made? Yeah, it's about time for Vim 7.1. Unfortunately I haven't found a good moment to make a new release. And I don't see it happening in the coming weeks either... Would it be possible for people to help make new releases? -- Ian Tegebo
Re: FW: verilog-mode, veri-tedium
On 4/27/07, Albie Janse van Rensburg [EMAIL PROTECTED] wrote: -Original Message- From: Albie Janse van Rensburg [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 11:19 PM To: Normandie Azucena Cc: vim@vim.org Subject: Re: FW: verilog-mode, veri-tedium Normandie Azucena wrote: hi all vim lovers! is there no script available that works like the veri-tedium plugin of xemacs? if there is none, can any guru do it? =) pls?pls?pls? What is xemacs? =) Normandie Azucena wrote: are u serious? or u r mocking xemacs? =) First, please don't top-post. (I rearranged the flow to read more naturally). Secondly, I am posting this to the list so other people can share in the fun ;-). Next time, instead of using Reply, use Reply to all or, if your mail client has it, Reply to list. Back to the topic. I /was/ just making a bit fun, actually. Seriously though, I see that there is a way to invoke emacs, and get it to do the veri-tedium reduction you are asking for. Read more about it at http://www.veripool.com/verilog-mode_veritedium.html#TOC9 I personally don't use emacs or Verilog, so I can't really help you, but maybe there are some other users out there that are in a similar boat... Of course, nothing stops you from writing a plugin yourself! Doing a script search for 'verilog' returns a number of results: http://www.vim.org/scripts/script_search_results.php?keywords=verilog Are any of those helpful? -- Ian Tegebo
Re: A challenge for those who feel like it
On 4/27/07, Dave Land [EMAIL PROTECTED] wrote:
Francis,
I took your challenge a long time ago, because I do the same thing:
when I'm editing JSP source code, I want to follow long chains of
included files, so I think I know just what you want...
map silent C-G C-Wgf:tabm 999CR
It opens the file under the cursor in a new tab, then moves the tab
to position 999, which is generally way after any tabs I have open, so
it goes to the end.
I use a Mac, so control-g is free for me. You can, of course, put it
on whatever key makes you happy.
Dave
On Apr 27, 2007, at 4:57 AM, Dolazy wrote:
Yesterday I wanted to write a function for opening files that
resembled the
Firefox feature of right clicking a link and choose 'Open link in
new tab'.
With the difference that I would use a hotkey instead of the mouse.
The requirements where this:
- open the file indicated by the filename under the cursor in a new
tab
- the new tab had to be the last tab
- the new tab would be opened 'in background', in other words: the
original
tab would remain active
- afterwards the cursor should go one line down, so that you can
repeat the
command by pressing the same keystroke again
How would this be done? (I found a solution yesterday, but I feel
so proud
of it that I don't want to share it immediately and see what you
would come
up with..)
Happy Friday!
Francis
--
View this message in context: http://www.nabble.com/A-challenge-for-
those-who-feel-like-it-tf3657250.html#a10217805
Sent from the Vim - General mailing list archive at Nabble.com.
Here's my version:
--
func! BgTab()
Get the number of the active tab.
let s:active = tabpagenr()
Get file to open
let s:newfile = expand('cWORD')
Go to last tab
exe ':tabl'
Open newfile in next tab
exe ':tabnew '.s:newfile
Go back to original tab page and down one line
exe ':tabnext '.s:active
normal j
endfunc
map silent C-G Esc:call BgTab()CR
--
For extra credit, if expand('cWORD') fails to find a valid file,
perhaps this function could use the lookupfile script:
http://www.vim.org/scripts/script.php?script_id=1581
If not, perhaps at least findfile().
--
Ian Tegebo
Re: Wish, Kate like file list.
On 4/12/07, Ingo Karkat [EMAIL PROTECTED] wrote: Edd Barrett wrote: Hi, This might already be possible, please excuse me if it is. I love the editting features of vim, but find that navigating between open files is quite difficult. Ideally I think I would be quite confortable with a kate like interface for listing open files: http://www.kde.org/screenshots/images/3.1/fullsize/2.png (screenshot) I got quite close by messing about with netrw in a vertical split, but the list pane did not: - Remain the same size - Show only one file to be open in the right hand pane. It would always split again for each newly selected file. Does anyone know how to do this? Would anyone find this useful? I have looked into using vim-part inside kate, but this is not supported for my UNIX distribution. I haven't used Kate, but I'm using a combination of - project (http://vim.sourceforge.net/scripts/script.php?script_id=69) to (re-)open files belonging to a custom file structure, - ProjectBrowse (http://vim.sourceforge.net/scripts/script.php?script_id=943) to open files in subdirectories and - most useful - - bufexplorer (http://vim.sourceforge.net/scripts/script.php?script_id=42) to navigate between files currently open in buffers. I've set up those plugins to open in a vertical split at the left side (like in most IDEs). Each view can be toggled on/off via a function key (F2, F3, F4). If one view is already open, trying to open another one will close the former, so that they don't eat up all of my window space. I was hoping the SideBar.vim plugin would do this for me: http://www.vim.org/scripts/script.php?script_id=720 Unfortunately it's broken for me in vim70 (shame on me for not contacting the maintainer or fixing it myself). At the moment it doesn't properly control the width of the sidebar. I was hoping to use only one function key that would cycle through my sidebars; maybe CTRL-FX would drop a sidebar or prompt to add another. Thanks for you code! -- Ian Tegebo
Re: Wish, Kate like file list.
On 4/12/07, Edd Barrett [EMAIL PROTECTED] wrote: Hi, This might already be possible, please excuse me if it is. I love the editting features of vim, but find that navigating between open files is quite difficult. Ideally I think I would be quite confortable with a kate like interface for listing open files: http://www.kde.org/screenshots/images/3.1/fullsize/2.png (screenshot) You might want to look at winmanager: http://robotics.eecs.berkeley.edu/~srinath/vim/snapshot2.JPG http://www.vim.org/scripts/script.php?script_id=95 It seems a very popular plugin for accomplishing this. If you search for 'tree' or 'file explorer' in the scripts section you'll see many more options. -- Ian Tegebo
Re: hilight blocks
On 4/12/07, Kirk [EMAIL PROTECTED] wrote: Is there any simple way to have custom blocks of code highlighted and the remaining code outside the blocks not highlighted? For example: # file.txt some plain text [my-custom-tag] some custom text [/my-custom-tag] Some more plain text ... # end of file So the idea would be to open VIM using file.txt and the code inside the custom tags would be highlighted. I've been working something very similar for highlighting code examples in vim helpfiles. As an example: = Begin Example Block: MyExample let s:myvar = testing call myfunc(an arg) Text that shouldn't get highlighted. = End Example = --- Begin Code - syn include @VimL syntax/vim.vim syn match blocktestPrefix /^Block:/ contained nextgroup=blocktestDesc syn match blocktestDesc /\(Block:\)\@=.*$/ contained syn region blocktestText contains=blocktestPrefix,blocktestDesc,blocktestBody,@VimL start=/^Block:.*$\n^\s\+/me=s+1 end=/^\S/me=s-1 Highlight Linking hi def link blocktestPrefix Todo hi def link blocktestDesc PreProc hi def link blocktestBody Label hi def link blocktestComment Comment -- End Code - I found |syntax.txt| and |usr_44.txt| to be helpful. -- Ian Tegebo
Using variables in syntax definitions
Is doesn't seem possible to store my patterns in variables for use in syntax definitions like the following: let s:mypattern = '#.*' syn match myPattern s:mypattern I get 'pattern delimiter not found' and what not. Is there a way to achieve this? The general problem I'm trying to solve is having to update patterns in syntax files when they're used in multiple places and to reduce the line length of syntax definitions; I've tried using line continuations but highlighting in the definition file itself seems to fail in this case. -- Ian Tegebo
Re: Using variables in syntax definitions
On 4/10/07, Peter Hodge [EMAIL PROTECTED] wrote: Hello, You'll probably need to use 'execute': execute 'syn match myPattern' s:mypattern but again, highlighting won't work for you then. I see what you're talking about in the syntax files like rst, c, sql, and gdb. I wonder how hard it would be to modify the vim.vim syntax file to highlight just that construct, e.g. execute 'syn...'. --- Ian Tegebo [EMAIL PROTECTED] wrote: Is doesn't seem possible to store my patterns in variables for use in syntax definitions like the following: let s:mypattern = '#.*' syn match myPattern s:mypattern I get 'pattern delimiter not found' and what not. Is there a way to achieve this? The general problem I'm trying to solve is having to update patterns in syntax files when they're used in multiple places and to reduce the line length of syntax definitions; I've tried using line continuations but highlighting in the definition file itself seems to fail in this case. -- Ian Tegebo Send instant messages to your online friends http://au.messenger.yahoo.com -- Ian Tegebo
Re: syntax/man.vim: manSubHeading is a bit too general?
On 4/9/07, Nikolai Weibull [EMAIL PROTECTED] wrote:
The manSubHeading is defined as
syn match manSubHeading ^\s\{3\}[a-z][a-z ]*[a-z]$
This will, however, match more lines than I think is intended. It
will, for example, match the line
\t returns are what are recorded and compared with the data git keeps
where \t is a horizontal tabulation. I'm guessing that the actual
regex should be
^ \{3\}[a-z][a-z ]*[a-z]$
I hope nobody minds if I take this opportunity to ask a question about
vim's pattern matching.
After reading |pattern| I wonder if the following is more efficient:
syn match manSubHeading '^ \{3\}\l\l\?\l$'
Taken from |pattern|:
- Matching with a collection can be slow, because each character in
the text has to be compared with each character in the collection.
Use one of the other atoms above when possible. Example: \d is
much faster than [0-9] and matches the same characters
Do people find this to make a different for moderate file sizes, e.g.
the man page for 'less' being ~2000 lines?
--
Ian Tegebo
Re: Folding in vim helpfiles
On 4/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quoting Mikolaj Machowski [EMAIL PROTECTED]: On pitek 06 kwiecieD 2007, vim@vim.org wrote: After looking at foldutil.vim and AutoFold.vim I'm not sure what the best way is going to be for exploiting the outline format of helpfiles to automatically create folds. Has anyone done this before? Ideally, I'd like to use this with the foldlist.vim plugin to have something like a left-side nav-bar while reading helpfiles. AFAIR Chip Campbell on his page had special version of help.vim with folding, extended highlighting etc. I have an additional-help syntax file at my website (and it does support syntax-based folding): http://mysite.verizon.net/astronaut/vim/index.html#HELP I updated the one on my website, too. Caveat: I used to have a version on vim.sf.net, but it was receiving -1s, so I withdrew it. Nonetheless, I use it all the time (the withdrawn one didn't support syntax folding, because vim itself didn't support folding back then). Its in vimball format; you'll need a new vimball plugin to extract it. Directions for that are also on my website. The new vimball plugin has been fairly stable recently, so hopefully when the new vim comes out whenever this will be considerably simpler. Thanks a lot! Folding works on the GetLatestVimScripts helpfile but I'm not getting folds for the non-local addition helpfiles, e.g. usr_41.txt. If I change the start pattern for the 'fold' line in the help.vim syntax file to the following I get what I expect: start=^\*\?\d\+\.\(\d\+\)\*\?\(\s\|\a\) I'm new to fold definitions in syntax files, how could I define subfolds for sections that you see in helpfiles like usr_41.txt? I feel confident constructing the start/end pattens for those regions that are delimited by all-caps headings. After reading syn-fold I think all I have to do is add: syn match helpSubsection ... start=all-caps heading ... At any rate, I'll keep playing around; this did just what I was looking for. -- Ian Tegebo
Re: Folding Perl POD
Have you seen this plugin already?
POD Folder : Creates folds in POD files based on =head[123] sections
http://www.vim.org/scripts/script.php?script_id=691
On 4/3/07, Bill Moseley [EMAIL PROTECTED] wrote:
I don't use folding often, but I'm not figuring out if/how to fold
POD documentation in a Perl module.
I have a module that includes:
=head1 METHODS
=over 4
=item wazbat
This method returns the wazbat of the current object.
=cut
sub wazbat {
my $self = shift;
return $self-{wazbat}
=item fromp
This methods implements the fromp operation.
=cut
sub fromp {
return fromp;
}
=back
=head1 WARNINGS
[...]
Is it possible to fold the =head1 or =item sections within a given
=head1 section?
--
Bill Moseley
[EMAIL PROTECTED]
--
Ian Tegebo
Folding in vim helpfiles
After looking at foldutil.vim and AutoFold.vim I'm not sure what the best way is going to be for exploiting the outline format of helpfiles to automatically create folds. Has anyone done this before? Ideally, I'd like to use this with the foldlist.vim plugin to have something like a left-side nav-bar while reading helpfiles. -- Ian Tegebo
Building Vim7 with perl support using Aap
I followed the instructions at: http://www.a-a-p.org/ports.html and that installation yielded a vim without perl support. After looking at: http://www.a-a-p.org/examples.html#variants It seems like adding several flags shouldn't be that hard; I could even imagine that recipe files have already been written for this. Any recommendations? -- Ian Tegebo
