Re: file operation in vimcommander?
On poniedziałek 16 kwiecień 2007, vim@vim.org wrote: > hi, > I found vimcommander which is a wonderful file management script for > vim, but when I select a file, say foo.pdf, it just open it in vim, not > xpdf I expect, so I have a question, whether vimcommander can use other > progam to open the file and how, or it's taget is just simple file > management like copy/move? Don't know vimcommander but if it uses for underlying operations netrw you can use gx to "execute" files. m.
Re: script boolean operators
On środa 11 kwiecień 2007, Jürgen Krämer wrote:
> >
> > normal G
> > let numberofrows = line(".")
>
> oh, and the above two statements can also be replaced by
>
> let numberofrows = line("$")
>
Very good advice. normal command can cause flickering of screen when
executing scripts.
m.
Re: Silly Question
On piątek 06 kwiecień 2007, vim@vim.org wrote: > On 4/6/07, Mikolaj Machowski <[EMAIL PROTECTED]> wrote: > > On piątek 06 kwiecień 2007, vim@vim.org wrote: > > > Has anyone else heard of the vi name game? > > > > Sure :) > > > > "Mikolaj" just inserts kolaj at the beginning of middle line of > > screen. > > I didn't know about the M command. I never needed it before. I even > learned something new from a silly question. What a great mailing > list! H and L are even more useful :) m.
Re: Folding in vim helpfiles
On piątek 06 kwiecień 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. m.
Re: Silly Question
On piątek 06 kwiecień 2007, vim@vim.org wrote: > Has anyone else heard of the vi name game? Sure :) "Mikolaj" just inserts kolaj at the beginning of middle line of screen. m.
Re: Updated Windows installer 7.0.219
On wtorek 20 marzec 2007, vim@vim.org wrote: > firewall our build machine sits behind. So I'm open to solutions for > how to remove obsoletes from the file set. I had considered deleting > the oldest files, but in most cases (such as the current) the files to > be removed are generally newer than the rest. The best I can do is to > occasionally delete the whole set and re-download, but with the new > spelling dictionaries, this is 200+ MB each time and I hate to waste > the bandwidth. Suggestions? Put that on users bandwidth -> let download dictionaries during install from Vim page, distribute only English dicts. Dictionary can be downloaded later even when trying to use particular dictionary. m.
Re: star key separators
On niedziela 25 luty 2007, vim@vim.org wrote: > Hi list, > > Where are the separators defined for the star key? I mean if I press :help 'iskeyword' m.
Re: The Seven Habits Of Effective Text Editing 2
On niedziela 18 luty 2007, Jimmy Mack wrote: > The slides are available here: > http://www.moolenaar.net/habits_2007.pdf > > I'll do an announcement soon. If you spot something wrong in the notes > let me know, I can still fix those. Second page: "Rest of the time is spend on meetings." Shouldn't it be: "Rest of the time is spent on meetings." ^ ? Fourth page: List at the end. Is it sentence or not? Get rid of S or add period somewhere. m.
Re: The Seven Habits Of Effective Text Editing 2
On sobota 17 luty 2007, VIM mail list wrote: > The original "seven habits of effective text editing" was fascinating > and useful. I am sure that I'm not the only vimmer who would be > interested in hearing more about this updated version. However, I can't > find any links to either a video or a transcript of this talk. Are you > planning to make this available on your website? Is it available > elsewhere? http://video.google.com/videoplay?docid=2538831956647446078&q=engedu+vim 1h 20m. m.
Re: gvim and Unicode
On sobota 27 styczeń 2007, vim@vim.org wrote: > (it appears gvim assumes the documents are ISO-8859 encoded.) In > addition, in the documentation and menus, I see nothing mentioned about > Unicode, UTF-8 encoding, etc. :help utf-8 :help unicode m.
Re: omni complete for php is really slooow
On czwartek 18 styczeń 2007, Mikolaj Machowski, vim@vim.org wrote: > >On my Sempron2200, 512MB RAM it may be not very fast but IMO is > > acceptable. Looks like something is wrong with your setup. Do you use > > tags files? > > You mean ctags? > Yes. I'm using it > Anyway thanks for your response. I will recheck my config. Maybe you have big project. I am testing functionality and performance against osCommerce. m. -- Histories are more full of examples of the fidelity of dogs than of friends - Alexander Pope
Re: omnicompletion vs. old Ctrl-n
On czwartek 18 styczeń 2007, vim@vim.org wrote: > Hi list, > > I'm using vim 6.3 and was thinking about upgrading to 7.0 especially > because of the new omni completion feature. But at the moment I'm not > quite sure what I would gain as there is the old Ctrl-n key in insert > mode which does code completion. So what does omni completion add that > Ctrl-n doesn't know currently? Ctrl-n will complete *all* words matching word before cursor. Omnicompletion will suggest words matching word and matching context of word. m.
Re: omni complete for php is really slooow
On wtorek 16 styczeń 2007, vim users list wrote: > The mail subject says it all:omni complete for php in vim7 in my PC (P4 > D, 1GB Ram) is really slooow. > > How about omni complete for php in vim7 in in your PC? Fast or Slow??? > How can I make it faster? Only for price in functionality. You can just comment various levels of completion logic. On my Sempron2200, 512MB RAM it may be not very fast but IMO is acceptable. Looks like something is wrong with your setup. Do you use tags files? m.
Re: Mac Questions
On pon sty 8 2007, vim@vim.org wrote: > I thought the same thing. But it does not appear to source my > .bash_profile or .bashrc. > > Anyone out there got some clues...? /etc/profile /etc/bashrc ? This will be global for all users (if working :)). m.
Re: .vimrc from URL
On pią sty 5 2007, Mikolaj Machowski wrote:
> Mikolaj Machowski wrote:
> > On pią sty 5 2007, Maurício wrote:
> >> Or else, have the following at the top of the vimrc:
> >>
> >>let g:vimrcdate = "4 Jan 2007 22:49 UTC"
> >>echo This vimrc was last changed on" g:vimrcdate
> >>if input("Do you want to continue? ") !~? "y"
> >>qall!
> >>endif
> >
> > Since this requires specific .vimrc OP can explicitly source netrw
^^^
> > at the beginning of .vimrc; open net address; write it to temporary
> > file; source that file; remove temporary file.
> >
> > m.
>
> I repeat: when the vimrc is sourced, the plugins (such as netrw) are NOT
> YET sourced. So if the vimrc tries to issue
That is why I wrote "explicitly source netrw".
m.
Re: .vimrc from URL
On pią sty 5 2007, Maurício wrote: > The vimrc is sourced before the global plugins, in particular before the > netrw plugin. So I think the short answer is no. BTW - if netrw could directly source files over the net it could open interesting possibilities for script repositories. m.
Re: .vimrc from URL
On pią sty 5 2007, Maurício wrote:
>
> Or else, have the following at the top of the vimrc:
>
> let g:vimrcdate = "4 Jan 2007 22:49 UTC"
> echo This vimrc was last changed on" g:vimrcdate
> if input("Do you want to continue? ") !~? "y"
> qall!
> endif
Since this requires specific .vimrc OP can explicitly source netrw
at the beginning of .vimrc; open net address; write it to temporary
file; source that file; remove temporary file.
m.
Re: automatic code completion in vim
On pon sty 1 2007, Mikolaj Machowski wrote:
> This won't work: you need a different variable name, see ":help E706".
Yeah, I forgot (not only about that).
This is complete solution::
function! UpdateTags()
call writefile(getline(1, '$'), '.tmp.cc', 'b')
let tags = system('ctags --c++-kinds=+p --fields=+iaS --extra=+q -f
- .tmp.cc')
" Note: whitespaces around expand are tab chars.
let alltags = system('grep -v " '.expand('%').' " tags')
let tagstable = split(alltags, '\n')
call add(tagstable, tags)
call writefile(tagstable, 'tags', 'b')
redraw!
return ';'
endfunction
inoremap ; UpdateTags()
Note: this is untested in real life, it doesn't return any errors.
In good conditions execution of whole function takes 0.46s on big tags
file (KMail source, tags size over 4MB, 1 lines). Delay noticeable
on my computer Sempron 2200, 512M RAM, old HD 5400rpm. In worse conditions
it was taking up to 0.75s::
FUNCTION UpdateTags()
Called 1 time
Total time: 0.527128
Self time: 0.401542
count total (s) self (s)
1 0.000551 call writefile(getline(1, '$'),
'.tmp.cc', 'b')
1 0.026373 0.000298 let tags = system('ctags --c++-kinds=+p
--fields=+iaS --extra=+q -f - .tmp.cc')
1 0.91 let stags = split(tags, '\n')
1 0.130731 0.031220 let alltags = system('grep -v "
'.expand('%').' "
tags')
1 0.128909 let tagstable = split(alltags, '\n')
1 0.43 call extend(tagstable, stags)
1 0.240341 call writefile(tagstable, 'tags', 'b')
1 0.33 return ';'
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 0.527128 0.401542 UpdateTags()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
1 0.527128 0.401542 UpdateTags()
Note however I've made one fatal mistake. ``ctags fname`` will point to
tags in file .tmp.cc not our real current file! Filtering tags in Vim is
possible and on small sample quite fast but still 0.5s is long. Maybe we
should put that strain to the system::
function! UpdateTags()
call writefile(getline(1, '$'), '.tmp.cc', 'b')
call system('grep -v " '.expand('%').' " tags > tags2 && mv -f
tags2
tags')
let tags = system('ctags --c++-kinds=+p --fields=+iaS --extra=+q -f
- .tmp.cc | sed "s/\t\.tmp\.cc\t/\t'.expand('%').'\t/" >> tags')
return ';'
endfunction
inoremap ; UpdateTags()
And here we have the winner::
FUNCTION UpdateTags()
Called 1 time
Total time: 0.145700
Self time: 0.001068
count total (s) self (s)
1 0.000523 call writefile(getline(1, '$'),
'.tmp.cc', 'b')
1 0.096118 0.000195 call system('grep -v " '.expand('%').'
" tags >
tags2 && mv -f tags2 tags')
1 0.049003 0.000294 call system('ctags --c++-kinds=+p
--fields=+iaS
--extra=+q -f - .tmp.cc | sed "s/\t\.tmp\.cc\t/\t'.expand('%').'\t/" >>
tags')
1 0.29 return ';'
FUNCTIONS SORTED ON TOTAL TIME
count total (s) self (s) function
1 0.145700 0.001068 UpdateTags()
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
1 0.145700 0.001068 UpdateTags()
Below 0.15s (and even in worse conditions only up to 0.25s)! This is
less then one keystroke of good touchtyper. This is for the price of
portability but you can find grep/sed/mv for other systems so situation
isn't hopeless.
HTH
m.
Re: automatic code completion in vim
Dnia pon sty 1 2007, napisałeś:
> remove() doesn't accept regexps only indexes. To remove offending lines
> use filter()::
>
> call filter(alltags, "v:val !~ fname")
I've made some tests and on big tags files it can be slow. The fastest
method is::
let alltags = system('grep -v '.fname)
let alltags = split(alltags, '\n') " you have to end with List
m.
Re: automatic code completion in vim
On pon sty 1 2007, Mikolaj Machowski wrote:
> >Note: much faster, noticeable on big files, would be reading of
> > tags file into buffer and just g//d proper lines and add tags at the
> > end
>
> how to read tags into the buffer and what does "g//d proper lines" mean?
:new somename
:g/\t{filename}\t/d
> >- but I hate buffer management in scripts, YMMV.
> >
> > Sounds complicated but Vim should be able to perform all actions with
> > reasonable speed. The most expensive is f) .
> >
> > You should carefully consider when this function should be performed.
> > I would vote for ; and BufLeave and BufWritePre autocommands.
> >
> > m.
>
> I write the function like this, but there are some problems.
> This is my first time to write vim script, so please give me a hand.
>
> inoremap ; UpdateTags()
> func UpdateTags()
> "get the file name of the current buffer
> let currentfilename=bufname("%")
Safer::
let fname = expand('%:p')
Full path will prevent ambiguity in some corner cases.
> "get the last line number in the current buffer
> let lastline=line('$')
> let currentfile=getline(1 , lastline)
Just::
let currentfile=getline(1, '$')
> "how to define the temporary file name
> call writefile(currentfile , ".tmp.cc" , "b")
> call system('ctags --c++-kinds=+p --fields=+iaS --extra=+q -f .tags
> .tmp.cc')
> let currenttags=readfile(".tags" , "b")
As I wrote, better to skip writing of tags to file, faster and you avoid
messing with filenames::
let currenttags = system('ctags --c++-kinds=+p -- fields=+iaS
--extra=+q -f - .tmp.cc')
> "remove the comment in the tags file
> call remove(currenttags , "^!")
Another benefit of using '-f -' - ctags when dealing with STDOUT doesn't
add !comment lines. Note for future - remove() doesn't accept RE, only
indexes.
> let alltags=readfile("tags" , "b")
> call remove(alltags , currentfilename)
remove() doesn't accept regexps only indexes. To remove offending lines
use filter()::
call filter(alltags, "v:val !~ fname")
> echo currenttags
> substitute(currenttags , ".tmp.cc" , currentfilename , "g")
> "here I want to replace ".tmp.cc" with currentfilename in the new
> created tags file,
> "but vim always gives me an error "E486: Pattern not found: currenttags
> , ".tmp.cc" , currentfilename , "g")"
??? substitute() is for strings. Now you can do::
let newtags = alltags + currenttags
> "echo currenttags has showed me currenttags contains ".tmp.cc".
> call add(alltags , currenttags)
> call writefile(alltags , "tags" , "b")
call writefile(newtags, "tags", 'b')
> "I want to write the updated tags into the file "tags" , but failed.
> "The error is "E730: using List as a String"
> "I don't understand
> endfunc
>
> Zheng Da
m.
Re: automatic code completion in vim
On nie gru 31 2006, Zheng Da wrote: > but i remember that , the (enhanced) ctags do have the option to > append the tag files. > you can see the manual more seriously , so i think you can find it " > --append" Yes, but they are not removing older entries. When doing corrections in file it may result with wrong suggestions - no longer existing in source. m.
Re: automatic code completion in vim
On sob gru 30 2006, Mikolaj Machowski wrote:
> Do you mean create tags files for every code file, and change tags
> file when switching between different code files?
> But how to combine all of these actions to a hotkey?
> If ctags can provide an update option, the problem can be solved very
> easily. But it seems ctags doesn't provide this option any longer.
No. It should looks like this:
1. Map common key to action. For language like C++ ";" (semicolon) is
good choice (eg. for Python it should be ).
2. inoremap it to function which will insert ; and perform some
function.
3. This function should:
a) get contents of file (:help getline())
b) write it to temporary file (:help writefile, :help tempname; wide
workaround but we don't want to write current file, it could break
some things)
c) execute ctags on that file (:help system(), man ctags - you can
get tags directly into variable (note: this is string)::
:let a = system('ctags -f - '.file)
Good thing would be to remove header of tags file (lines beginning
with '!').
Now we have file with updated definitions of tags for current file.
Rest depends on how do you organize your tags files. Lets assume you
have one big tags file for whole project.
d) find tags file (:help 'tags' and check how omnicomplete functions
are finding tags files)
e) read this file (:help readfile())
f) delete lines containing definitions from current file (:help :for,
:help remove())
g) connect your new tags and global tags
h) overwrite old tags file.
Note: much faster, noticeable on big files, would be reading of tags
file into buffer and just g//d proper lines and add tags at the end
- but I hate buffer management in scripts, YMMV.
Sounds complicated but Vim should be able to perform all actions with
reasonable speed. The most expensive is f) .
You should carefully consider when this function should be performed.
I would vote for ; and BufLeave and BufWritePre autocommands.
m.
Re: automatic code completion in vim
On sob gru 30 2006, vim@vim.org wrote: > Hello, > > I hope vim can run automatically a completion after a '.', '->' or '::' > when I write c++ program. I know omnicppcomplete plugin can do this job. > But omnicppcomplete needs tag database. So if I want omnicppcomplete to > tell me members of a class, I have to keep updating the tag database > even though I only make a little change. > So is there other ways to do the completion? Or is there some way to let > omnicppcomplete update the tag database automatically? Some time ago I was experimenting with PHP files and remapping of ; to recreate tags file including changes from current file (even when non-written). On big projects it was taking too much time. On small to middle ones behaviour was acceptable. You could try similar thing or better: create tags only for current file and later replace proper entries in project tags file. Should give significant speed gains comparing to my approach. m.
Re: Learning the vim Programming
On pią gru 22 2006, vim@vim.org wrote: > I have been using vim since three years ago . > Vim gives me happy and sometimes agony^_^ > > i Just want to leaning more about the vim programming. > > But the vim doc which can be called out via "help XXX" is more like a > dictionary rather than a book for teaching. Vim docs are in fact two manuals: Vim User Manual and Vim Reference Guide Second one is where you usually land after use of :help command but first - User Manual is really great and usually under appreciated source of knowledge about Vim. > Anyone have some e-books for leaning the vim programming? > Or is there some website ? Print out User Manual and read it *from the beginning*. Not only usr_41. Only in this case you will get good grasp of nuances of various Vim modes. m.
Re: your best vim scripting tip
On nie gru 3 2006, vim@vim.org wrote: > Hi, > It you should give one (or more) tips to a person who was going to > start creating scripts for vim, then what would it be? > (besides "know your :help" :-) ) > > ideas could be: > Do's and dont's Keep ff=unix . In other case your scripts won't be working under non windows systems. Always supply modeline to make sure basic editing things will be working for others. When changing options use setlocal not set - be polite to user environment. Try to cut on g:variables (see above). Try to maintain documentation, not only for use of script but also for messing with it. > best util script Each script covers only part of Vim functionality. It is hard to say which one is best for learning. > often used functions It depends on what are you want to achieve. > ways of optimization Avoid \| in complex regexps, often two, separate substite() are faster than one substite() with \|. Avoid * whenever possible, try to use \+ if appropriate. \x class is faster than [collection] When doing complex substitutions it is often faster to check if some part of pattern already exists and only if this is true execute substitution. m. -- I am social scientist - I don't know the difference between good and bad, only the difference between difference.
Re: vim spelling checker and "po" files
On nie lis 26 2006, vim@vim.org wrote: > I see that the ":syntax" command accepts the @Spell > argument, to specify where to use the spelling checker. > However, I do not see how to use this for setting up > the spelling checker in multiple languages. It is not possible. Yet, I hope ;) m.
Re: g/pat/s/pat.*/to/ vs :%s/pat.*/to/
On śro lis 22 2006, Vim List wrote:
> In vim docs, there is example like this:
>g/pat/s/pat.*/to/
> As far as I know, it is also possible to do it without g:
>%s/pat.*/to/
> Is there a difference, a reason to prefer the
> first form, the longer for with 'g' ?
It is useful when you want to change some pattern but only in lines
where is other pattern. Example::
g/^#IDO/s/\\/\//g
It will change \ in / but only in lines beginning with '#IDO'.
Combining of g// and s/// with similar {from} string may be faster to
execute (not type ;) when s/// is very complex regexp. You prefilter
file to catch only lines where possibility of substitution is high and
later you only test this subset of lines. But it pays off only on big
files and complicated regexps.
m.
Re: XML file creation and validation based on schema]
On czw lis 16 2006, vim@vim.org wrote: > Hi, > > Is it possible to create and validate xml files, based on xml schema > (xsd files) in vim. The features, like automatic closing tags, automatic > insertion of mandatory tags, suggestion of tags, based on the schema etc > will be very useful. Is there any plugins available to do this.? No. Only through DTD (in fact through data file created from DTD, if you know tools to process Schema files...). m.
ANN: VST 1.4
Hello, Vim7 required. VST is script which makes possible to export text files with simple markup to HTML, LaTeX or HTML S5 presentation format to create even complex documents. Script doesn't require any external dependency and will work on any platform Vim7 is available. VST is Vim only implementation of reStructuredText. Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip ChangeLog ' - 31 Oct 2006 - **1.3** announcement - FIX: Vst link broken - FIX: & in URLs double encoded - FIX: broken chained links with uppercase letters List of changes with working links to documentation: http://skawina.eu.org/mikolaj/vst.html#lchangelog Supported elements of inline markup: - emphasised text (italic) - strongly emphasised text (bold) - hyperlinks (in various syntax forms) - custom decorations (among them: sub, sup, big, small) Elements of documents structure: - paragraphs - block quotes - ordered lists - unordered lists - option lists - footnotes - citations - images - preformatted text - colorized preformatted text (HTML export only) - tables - admonitions - table of contents Also bunch of auxiliary commands which should ease writing of document and navigating (folding, text table of contents, lists or declared links, replacements) Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip To install, place archive in ~/.vim directory and unpack it there. Following versions of help file was produced without any modifications to HTML or LaTeX source: HTML: http://skawina.eu.org/mikolaj/vst.html LaTeX file exported from vst.txt: http://skawina.eu.org/mikolaj/vst.tex PDF file produced from vst.tex: http://skawina.eu.org/mikolaj/vst.pdf m.
ANN: VST 1.3 Halloween
Hello, Vim7 required. VST is script which makes possible to export text files with simple markup to HTML, LaTeX or HTML S5 presentation format to create even complex documents. Script doesn't require any external dependency and will work on any platform Vim7 is available. VST is Vim only implementation of reStructuredText. Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip ChangeLog ' Looong list of improvements, changes and bugfixes: - 13 Oct 2006 - **1.2** announcement - ADD: show number of directive line and percentage position in file for easier navigation when folding by directive - ADD: proper encryption of URIs (amp, percentage) - ADD: make preproc auxiliary command recursive - ADD: fold according to level of headers: fold1, fold2, etc. - ADD: recursive folding: foldr - ADD: [LaTeX] containers as ghost commands - ADD: [LaTeX] Generator line (debug purposes) - CHG: make folding by directive more flexible - CHG: improve layout of fold texts with centered titles - CHG: improve layout of text table of contents with centered titles - CHG: level of recursiveness is now &maxfuncdepth/2 (50 should be enough for everybody!) - CHG: [HTML] when source are lists starting from no-one use transitional doctype, otherwise strict - CHG: [HTML] "Downgrade" to HTML 4.01 (no sense to use XHTML doctype when using content text/html) - FIX: length of ornaments inserted with o - FIX: show output of auxiliary commands depending on table - FIX: presence of apostrophes in section titles could cause problems in folding - FIX: internal links in fancy formatted text could be broken - FIX: unnecessary creation of targets from links broken in several lines - FIX: minor fixes in docs - FIX: optimizations, 10-15% speed gains - FIX: [LaTeX] too much whitespace at the end of footnotes - FIX: [LaTeX] internal links work again - FIX: [S5] uploaded CSS files for web page to make presentation work (sorry George!) List of changes with working links to documentation: http://skawina.eu.org/mikolaj/vst.html#lchangelog Supported elements of inline markup: - emphasised text (italic) - strongly emphasised text (bold) - hyperlinks (in various syntax forms) - custom decorations (among them: sub, sup, big, small) Elements of documents structure: - paragraphs - block quotes - ordered lists - unordered lists - option lists - footnotes - citations - images - preformatted text - colorized preformatted text (HTML export only) - tables - admonitions - table of contents Also bunch of auxiliary commands which should ease writing of document and navigating (folding, text table of contents, lists or declared links, replacements) Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip To install, place archive in ~/.vim directory and unpack it there. Following versions of help file was produced without any modifications to HTML or LaTeX source: HTML: http://skawina.eu.org/mikolaj/vst.html LaTeX file exported from vst.txt: http://skawina.eu.org/mikolaj/vst.tex PDF file produced from vst.tex: http://skawina.eu.org/mikolaj/vst.pdf m.
Re: no special treatment of & and ~ in substitute? possible?
On pon paź 30 2006, vim@vim.org wrote:
> How can I tell vim to not tread & and ~ in a special way when using
> substitute?
>
> compare
> echo substitute(substitute('a','a','b','&'),'b','c &','')
> and
> echo substitute(substitute('a','a','b','&'),'b',substitute('c
> &','\V\(&\|~\)','\\\1','g'),'') using substitute works but seems to be
> more ugly when used in scripts?
:help escape()
m.
Re: getchar() trick with recursive map
On śro paź 25 2006, Mikolaj Machowski wrote: > > In Linux terminal and GTK2 versions cursor is stuck in command line > > and don't at its real position making inserting of text almost random. > Getting stuck at command-line is normal, as it is always waiting on > getchar(). I realize will not be suitable for all applications, but > works well for what I am trying to achieve. I don't however understand > the random part that you are mentioning. What exactly is happening? Is > the position where the text is inserted random? No, just impression of randomness - user is accustomed to cursor and when doesn't see it he is lost. In heavily restricted environment like forms this is not so important. m.
Re: has('unix')
On śro paź 25 2006, vim@vim.org wrote:
> Hello,
>
> for my font plug in I need to know which OS I am running on to choose an
> appropriate font. Now when Sun Solaris where added to the list of OS I
> use I run into a little problem: there is only "has('unix')" - but
> that's not good enough as Linux allows for anti alias fonts and Sun
> Solaris does not.
>
> Any ideas?
if has('unix')
let os = system('uname -a')
endif
Depending on value of os proceed.
m.
Re: Changing omnicomplete lifetime?
Dnia poniedziałek, 23 października 2006 23:23, Bill Mill napisał: > On 10/23/06, Mikolaj Machowski <[EMAIL PROTECTED]> wrote: > > Dnia poniedziałek, 23 października 2006 15:18, Bill Mill napisał: > > > How would you recommend getting this to work? Should I try and edit > > > supertab? Is there an easy way to change it? > > > > Maybe try to change 'completeopt' value. longest option? > > I already have that set. > Hmm. I tested this with HTML and looks(?) like bug. is now exiting ins-completion mode. m.
Re: Changing omnicomplete lifetime?
Dnia poniedziałek, 23 października 2006 15:18, Bill Mill napisał: > How would you recommend getting this to work? Should I try and edit > supertab? Is there an easy way to change it? Maybe try to change 'completeopt' value. longest option? m.
Re: getchar() trick with recursive map
Dnia piątek, 20 października 2006 08:26, Hari Krishna Dara napisał: > Here is a demo that shows how to use it in insert mode. What the > function does is to double every key you press, except and , > when it breaks the loop. If world could be so beautiful... In Linux terminal and GTK2 versions cursor is stuck in command line and don't at its real position making inserting of text almost random. :( m.
Re: Slightly OT: HELP! IDE ahead !
Dnia środa, 18 października 2006 05:13, A.J.Mechelynck napisał: > Well, I guess if you can configure gvim as your "embedded editor" for > kdevelop, you will be able to edit your files with Vim and "make > believe" that you're using kdevelop, so everyone'll be happy. (My SuSE > system came with kvim set up as the embedded editor for any KDE > applications that use one; but that means a Vim version 6.2.14 -- you > bet I changed that to my homemade 7.0 ! ) If someone want to have Vim7 kvim, he should dig CVS. There was time in alpha state when kvim was in main Vim tree. AFAIK that was before omnicompletion but already with spelling. Application was stable. It was removed because no one was eager to maintain those features. m. ps. With release of Qt4.2 with supported glib event loop I hope someone will try again with qvim (before KDE4 there is no sense to start kvim). But it would require writing from scratch...
Re: Automatically adding header into file with specific extension
Dnia środa, 18 października 2006 10:19, Gundala Viswanath napisał: > Hi, > > I want to be able to have VIM automatically > insert this line: :help skeleton m.
Re: Using output of Vim commands in scripts
Dnia poniedziałek, 16 października 2006 15:05, Marius Roets napisał: > Hi everybody, > Is it possible to use the output of Vim commands in a script? My > specific problem currently is that I would like to use the output of > > :tabs in a script. I cannot find a Vim function that does the same as > > this command. Any ideas? :help :redir From third entry you have what you want (redirect to register/variable/clipboard etc.). m.
ANN: VST 1.2 "Friday 13th"
Hello, Hello, VST is script which makes possible to export text files with simple markup to HTML, LaTeX or HTML S5 presentation format to create even complex documents. Script doesn't require any external dependency and will work on any platform Vim7 is available. VST is Vim only implementation of reStructuredText. Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip ChangeLog ' - ADD: o auxiliary mapping for ornaments - ADD: section numbers in fold auxiliary command - ADD: section numbers in toc auxiliary command - ADD: [LaTeX] raw directive accepts tex, not only latex argument - CHG: don't look for including commands in auxiliary commands - massive speed gains - CHG: [LaTeX] change default font size for 12pt - FIX: [HTML] all styles from multiple 2html directives are in - FIX: [HTML] @ in 2html directive was breaking syntax highlighting - FIX: [HTML] restore validity of generated documents - FIX: [LaTeX] bug with _ in filenames in raw latex file option - FIX: many minor bugs List of changes with working links to documentation: http://skawina.eu.org/mikolaj/vst.html#lchangelog Supported elements of inline markup (among others): - emphasised text (italic) - strongly emphasised text (bold) - hyperlinks (in various syntax forms) - custom decorations (among them: sub, sup, big, small) Elements of documents structure: - paragraphs - block quotes - ordered lists - unordered lists - option lists - footnotes - citations - images - preformatted text - colorized preformatted text (HTML export only) - tables - admonitions - table of contents Also bunch of auxiliary commands which should ease writing of document and navigating (folding, text table of contents, lists or declared links, replacements) Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip To install, place archive in ~/.vim directory and unpack it there. Following versions of help file was produced without any modifications to HTML or LaTeX source: HTML: http://skawina.eu.org/mikolaj/vst.html LaTeX file exported from vst.txt: http://skawina.eu.org/mikolaj/vst.tex PDF file produced from vst.tex: http://skawina.eu.org/mikolaj/vst.pdf m.
Re: VimL and Exuberant tags - Suggestions please
Dnia piątek, 13 października 2006 02:16, David Fishburn napisał:
>
>
> Instead of simply grouping everything under variables, should we
> distinguish between different types?
> let forms#form = {
> \ 'title': 'Address Entry Form',
> \ 'fields': [],
> \ 'defaultbutton': 'ok',
> \ 'fieldMap': {},
> \ 'hotkeyMap': {},
> \ }
>
> Right now this is identified as a variable, should we identify it as a
> Dictionary by adding another kind of tag?
Detection of variable type (string, list, dictionary) would be great
thing.
m.
Re: vim | editing pdf files with vim
Dnia wtorek, 10 października 2006 15:58, Nikolaos A. Patsopoulos napisał: > Hi all, > > is there a way to edit pdf files with vim? If not pdf as is, then eps or > postscript? I tried with either format but the text kept been converted > to sthl ike ASCII code. Try pdftk and vim plugin for that program (sorry, don't remember site address). But this is only for correcting singular typos or compatible, nothing more. m.
Re: Forms highlighting
Dnia sobota, 7 października 2006 09:23, napisałeś: > There is a new version at: > > http://haridara.googlepages.com/forms.vim > > Significant changes being: > - Support for disabling fields. This may be question of gusto but IMO disabled field should be visible but greyed out, not completely hidden. I know some usability studies favor hiding it but it is usually in GUI when disabled element is completely removed, empty lines in Vim form look strange. Rest feels very nice. Thanks for fixing multiple same-hotkeys problem. > > I modified the demo to include both enabling/disabling fields as well as > validation (zip field). When inserting non-valid data it is almost impossible to leave zip field. At least some warning message would be appropriate. This is not for forms stuff but demoform should set good standards for interaction :) > On Thu, 5 Oct 2006 at 1:19pm, Mikolaj Machowski wrote: > > , ? It should work everywhere and is quite natural for Vim > > users (IMO). > > Now and also work like and . Thanks. It has problems when leaving combobox backward but so far it is the best way to navigate in Linux terminal. > > I would expect some simplifying in use. For example why explicitly > > declare them? Create listeners automatically. > > I am not still clear. How can you create listeners automatically? Can > you give some example? Maybe by comparison. Now creation of form is: 1. Create listener 2. Define listener functions 3. Create form (g:forms#form.new) 4. Add fields and in buttons declare listener explicitly 5. Add loop to add listener to all other fields 6. Add listener events functions Steps 1. 5. and second half of 4. IMO are not really necessary. Make it: 1. Create form (g:forms#form.new) 2. Define listener functions 3. Add fields 4. Add listener events functions Creation of listener could be done in form.new depending on argument of call. > > > - Validators. > > > > Local validation (onBlur event) can be already done. Problem is when > > doing after pressing OK. Hmm, in fact it can be also done but is > > boring ;) to do. Some API for that would be good. > > How was onBlur event possible? Previously you could do validation in the > valueChanged() callback, but you couldn't constrain the focus, but the > new isValid() callback allows that. My mistake, looked like valueChanged works in way of onBlur. > > Title may be declared. Make it support for non showing it, like:: > > What is the use of declaring it when not showing? Are you thinking of it > as an identifier, like a name for fields? Yes. > > One change which would be good to introduce before official beta: > > obligatory fields. As I wrote earlier - full validation if possible > > but laborious. And declaring it in API should allow for some emphasis > > (highlighting?). > > Does the new isValid() callback meet your expectations? Sorry, don't have time to test it but I suspect this is exactly what I want. m.
Re: Forms highlighting
Dnia czwartek, 5 października 2006 01:16, Hari Krishna Dara napisał:
> I have 6.3 version of cygwin and arrows work fine in rxvt. I stil think
> your term settings are not right. But this is not really concern forms
> plugin, though it means we might have to support some other maps that
> will reliably work in all the terms.
, ? It should work everywhere and is quite natural for Vim
users (IMO).
> > Another thing. Until now I was only playing with demo. Now I tried to
> > do my own form and have one thing to say:
> >
> > Listener stuff is complicated. Can it be done simpler?
>
> Do you mean simplify the listener interface, or completely do away with
> them?
Former.
> - If you mean the former, then the alternative is to accept a function
> name (this is what my previous version worked). But a big problem with
> this is that the function has to be global and I hate defining global
> functions without intending them to be part of API, and I know several
> others feel the same. The current scheme of expecting a dict object
> should be more familiar to many, who worked with the newer GUI
> frameworks (such as Swing and Flex). While not having to define a
> global dict variable, it also provides a way to create more
> "contextual" listeners (you can e.g., put the form that the listener
> is attached to, without having to modify the listener interface to
> also expect the form object).
I would expect some simplifying in use. For example why explicitly
declare them? Create listeners automatically.
Check example I send earlier. Core stuff is quite simple, big part of it
is overhead dealing with listeners.
> What do you think are the next priority TODO items before making the
> first release (or a beta release)? I am thinking if I fix the known
> issues and implement the items that improve the overall feel of a static
> form, it will be good enough. Right now, there are too many ways the
> user can end up in 'modifiable' mode and just remove/change anything,
> giving the impression that the plugin is not robust).
> - Pressing in textfield doesn't let you into the existing
value
> (need to set backspace=start, but this is global).
> - Support for radio buttons.
> - Optional user completion for textfields and comboboxes (no preset
data).
> - Support for disabling fields (greyed out and no editing or focusing).
> - Validators.
Local validation (onBlur event) can be already done. Problem is when
doing after pressing OK. Hmm, in fact it can be also done but is boring
;) to do. Some API for that would be good.
> - For non-editable comboboxes, don't accept a value that is not in the
data.
> - in select mode should cancel selection and bring up popup (or
do
> nothing by setting 'keymodel' to empty value, but this is global).
> - When the focus is moved in, explicitly set the value again, to make
> sure any fouled up entries are fixed.
Don't understand that. Maybe you were thinking about "moving out" of
field (onBlur JavaScript event)? It is already possible.
> - Detect cusor movements beyond the fields and disable modifiable. This
will
> reduce the chance of accidentally mucking up the form.
> - Avoid first empty line (in an empty buffer).
> - Recognize no/empty title.
Title may be declared. Make it support for non showing it, like::
let demoform = g:forms#form.new('Address Entry Form', 1)
To show it and 0 for non showing it.
> - Encode the field boundaries (like [], <>) in the field itself. This
will
> make some of the logic more generic and will make it more flexible to
> change them.
One change which would be good to introduce before official beta:
obligatory fields. As I wrote earlier - full validation if possible but
laborious. And declaring it in API should allow for some emphasis
(highlighting?).
m.
Forms example
Dnia środa, 4 października 2006 05:06, Hari Krishna Dara napisał:
> A new version is available, to try:
>
> - Download the below file and put it in your autoload directory:
> http://haridara.googlepages.com/forms.vim
>
> - Start a fresh Vim session and execute:
> :call forms#demo()
>
> The new version has support for listening to changes in the field
> values. The demo can now automatically lookup city and state when you
> fill in your zipcode using a webservice (you need wget in the path and
> need Internet connection).
Using this version I wrote example tag form generated from xml data
file. It uses simple validation (only two fields: accesskey and dir)
acting when leaving field.
Playing with it gave me some more ideas:
- obligatory fields (and highlighting of that)
- single hotkey per form is real problem (try o), at least shortcut
should take to *first* field with that letter not last
- bug when first field is empty; cursor is placed directly after ':' in
label, only Tab is taking it to real field; below workaround is
putting always ' ' as value if field is empty.
How to use.
- open it ;)
- correct path to xml/xhtml10s.vim
- so %
-
" Form
" Data about attributes:
" g:xmldata_{b:html_omni_flavor}[tagname][1]
if !exists('g:xmldata_xhtml10s')
source ~/.vim/autoload/xml/xhtml10s.vim
endif
let attrs = g:xmldata_xhtml10s['a'][1]
let g:tfList = {}
function! g:tfList.actionPerformed(name)
if a:name ==# 'ok'
let output =
\ "Output:\n"
for i in g:formfields
if b:curForm.getFieldValue(i) !~ '^\s*$'
let output .= i.'="'.b:curForm.getFieldValue(i)."\"\n"
endif
endfor
call input(output)
redraw
else
call input('Form cancelled, closing window')
return ":bw!\"
endif
endfunction
function! g:tfList.valueChanged(name, oldval, newval)
if a:name == 'accesskey'
function! UpdateAcckey()
if len(b:curForm.getFieldValue('accesskey')) > 1
call b:curForm.fieldMap['accesskey'].setValue(' ')
endif
endfunction
return ":call UpdateAcckey()\"
elseif a:name == 'dir'
function! UpdateDir()
if b:curForm.getFieldValue('dir') !~ '^\(\s*\|ltr\|rtl\)$'
call b:curForm.fieldMap['dir'].setValue(' ')
endif
endfunction
return ":call UpdateDir()\"
endif
return ''
endfunction
let htmlform = g:forms#form.new("Tag a")
let g:formfields = []
for attr in sort(keys(attrs))
if len(attrs[attr]) == 0
call htmlform.addTextField(attr, attr.':', ' ', attr[0])
else
call htmlform.addComboBox(attr, attr.':', '', attrs[attr],
attr[0], 1)
endif
let g:formfields += [attr]
endfor
call htmlform.addButton('ok', 'OK', '', 'o', g:tfList)
call htmlform.addButton('cancel', 'cancel', '', 'c', g:tfList)
call htmlform.setDefaultButton('ok')
for field in htmlform.fields
if field.type != g:forms#FT_BUTTON
call field.setListener(g:tfList)
endif
endfor
vert new
exe "normal! 30\|"
call forms#ShowForm(htmlform)
-
Re: Forms highlighting
Dnia środa, 4 października 2006 05:06, Hari Krishna Dara napisał: > > > > No. They are inserting some version of keycode: OA, OB, OC, OD. In gui > > everything works well. In menus enabled > > Doesn't that just mean your term is not properly setup? I tried it on > win32 console vim and it worked just fine. It is normal setup. Arrows doesn't work in xterm, konsole, rxvt. > > Bug: When completely remove value, leave field and later return > > to it default value is forgotten, Esc is going to Normal mode. > > This is not a bug. When you leave the field, the value is immediately > saved, which means the new empty value overwrote the old value. When you > return back to the field, this empty value becomes your new default > value. Hmm. Not sure if this is expected behavior, maybe other users could tell more? > > Bug: Form is creating swap file which makes hard to use simultaneously > > the same form in various Vims when editing files in the same > > directory. Solution: Add 'setl noswapfile' after 'setl nomodified' in > > SetupBuf function (this is local option and but it is easier to read > > when explicitly declaring as local). > > This is really not a bug. Since the user is creating the buffer, it is > his responsibility to set noswapfile if he is intending to open the same > form multiple times. We could set noswapfile in forms, but then if the > Vim crashes in the middle of the form entry, the user could loose some > important data :) OK. At least for demo use just "new" instead of "new Form". > I don't know if this is more intuitive, but I know Java Swing/AWT > framework (the only GUI framework that I am familiar with) doesn't have > separate widgets. OK. > We have to be careful in doing this. E.g., if you change the height > while there is only one window, Vim will behave strangely. Yes. > I don't know > if there is any similar side effect of changing the width when there is > only one window. No. > Again, since user is creating the window for now I > think we should leave this to the user. When buffer management is > implemented in forms, we can set these parameters. Problem with current implementation is that user cannot influence dimensions of buffer. Before calling ShowForm he don't know them later it doesn't work. Don't know why, when placing above lines after ShowForm call formwidth is computed but it only places _ in first field. > > Unfortunately it goes wild when form will be opened in vertical > > window... > > What do you mean? Status lines goes up. One bug: On X11 @* (you are using to store form in clipboard) is selection, which means that it will be overwritten by [OK] (visually selected with normal navigation). At least on Unix systems you should use @+ clipboard (don't know how it works on Windows). BTW - you don't have to play with if/endif:: let @* = address let @+ = address will do. Another thing. Until now I was only playing with demo. Now I tried to do my own form and have one thing to say: Listener stuff is complicated. Can it be done simpler? m.
Re: Forms highlighting
Dnia wtorek, 3 października 2006 02:35, Hari Krishna Dara napisał:
> - Start a fresh Vim session and execute:
> :call forms#demo()
Looks very good (I am using last version).
> > Problems with current version of forms:
> >
> > - arrows doesn't work in terminal. They are completely messing things
> > eg. destroy knowledge about default value.
>
> Do arrows work like j and k outside form? Since I am mapping and
> keys, as long as they work outside form, I am assuming they
> shoudl work inside form also.
No. They are inserting some version of keycode: OA, OB, OC, OD. In gui
everything works well. In menus enabled
Bug: When completely remove value, leave field and later return
to it default value is forgotten, Esc is going to Normal mode.
Bug: Form is creating swap file which makes hard to use simultaneously
the same form in various Vims when editing files in the same directory.
Solution: Add 'setl noswapfile' after 'setl nomodified' in SetupBuf
function (this is local option and but it is easier to read when
explicitly declaring as local).
Wish: different highlighting of <> in drop-down menu (State) and
combobox (Country). Maybe use {} somewhere?
I looked in the code: you are making just difference between editable
and non-editable combobox. IMO would be better to split this in two
widgets: combobox and dropdown menu. With that you will be able to make
visual differences between those two items (highlighting, braces).
> > After some consideration wasn't best suggestion. I think in such
> > forms is bigger probability of digraphs than somewhere else. Other
> > possibilities; (may break behave mswin and/or Cream - obvious
> > client of such script); no mnemonic value but are covering
> > indenting mappings.
>
> How about using ? i_CTRL_G is used to move around the buffer, which
> we prevent anyway, and it could be a good mnemonic too.
OK for me.
> > Maybe you are right. I am biased here - I hate buffer management and
> > if someone else can take care about that... ;)
>
> I agree, buffer management is messy, which is why putting the task on
> the user makes it a little easier for the first version to get out :)
>
> I have now uploaded a version with your changes.
>
> http://haridara.googlepages.com/forms.vim
>
> This version also contains an API to create forms. The forms#demo()
>
> function shows you how to use the API. You can invoke it as:
> :call forms#demo()
>
> I will enhance the demo with some buffer management as a suggested
> pattern for the users.
Good thing would be possibility to scale height of buffer to height of
form and width [1]. Usually when filling you want to check context. Also
in space preserving department: header is 3 lines high. First - empty
line should go to /dev/null; second - value of separator is doubtful
when highlighting works.
[1] User may want to split window vertically. Maybe full buffer
management isn't required but some elements for making it easier to user
would be good: eg. length and width of form.
This is complete addition to beginning SetupBuf::
setl noswapfile
let formheight = len(b:curForm.fields) + 3
exe "normal! ".formheight."\_"
let formwidth = b:curForm.maxLblSize * 2
exe "normal! ".formwidth."\|"
Unfortunately it goes wild when form will be opened in vertical
window...
> Are you interested to use the forms for any of your plugins or are you
> just helping me out? :) (in either case, many thanks).
I have idea where I would like to use it but at the moment it is rather
vague (tag form for HTML/XML editing). At the moment I want to have
something good in tool-box (new screwdriver syndrome ;)
m.
Forms highlighting
Hello,
Below patch to yesterday version of forms.vim .
Rather proof of concept than full solution but looks much nicer:
Features:
- highlight header of form in Comment
- highlight labels of fields as Questions
- hightlight hotkeys as Statements
Limitations:
- Buttons are not supported
Problems with current version of forms:
- arrows doesn't work in terminal. They are completely messing things
eg. destroy knowledge about default value.
- when there is more than one the same character as hotkey repeating
hotkey doesn't cycle between them. It stucks with last entry with that
hotkey
--- /home/mikolaj/kget/forms.vim2006-10-02 10:31:54.0 +0200
+++ forms.vim 2006-10-03 01:26:04.0 +0200
@@ -182,13 +182,20 @@
let a:form.stLine = line('$') + 1
" Center it.
silent! put =a:form.title
+ exe 'syn match formHeader /\%'.line('.').'l.*/'
silent! put =substitute(a:form.title, '.', '-', 'g')
+ exe 'syn match formHeader /\%'.line('.').'l.*/'
for field in a:form.fields
let field.stLine = line('$')+1
call s:SetCurFieldValue(field, field.value)
let a:form.fieldMap[field.name] = field
let a:form.hotkeyMap[field.hotkey] = field
+exe 'syn match formLabel /\%'.field.stLine.'l.*\%<'.(maxLblSize+2).'c/
contains=formHotkey'
+exe 'syn match formHotkey /\c\%'.field.stLine.'l'.field.hotkey.'\%<'.
(maxLblSize+2).'c/'
endfor
+ hi def link formHeader Comment
+ hi def link formLabel Question
+ hi def link formHotkey Statement
setl nomodifiable
call s:SetupBuf()
Re: forms support for Vim
Dnia poniedziałek, 2 października 2006 01:41, Hari Krishna Dara napisał: > First, a big thank you for trying it and giving feedback. > > On Sun, 1 Oct 2006 at 4:11pm, Mikolaj Machowski wrote: > > Hello, > > > > Interesting concept. The most difficult thing are Vim habits. Seeing > > spelling error in line before I tend to make k than which > > is obviously messing things. > > Yes, that will be a problem, For short forms, this will not be much of a > problem, as you don't expect to spend a lot of time on them (that is > when your inherent habits start to show up). Covering all the vim > movement commands and supporting them will be a lot of pain and > maintenance. Maybe not all. You should catch "only" switching between major modes and vertical movement. The rest isn't so important. > > Avoid mappings. They don't always and everywhere work. Better use > > something like f to go to the First name field. > > Good comment, I am now mapping both the meta keys as well as your > suggested keys. After some consideration wasn't best suggestion. I think in such forms is bigger probability of digraphs than somewhere else. Other possibilities; (may break behave mswin and/or Cream - obvious client of such script); no mnemonic value but are covering indenting mappings. > > > Hotkey emphasis should be rather done with syntax highlighting, not > > underscore (not always available). > > I took note of this. I don't have much idea of how to implement syntax > coloring right now. You know where key label ends. Use \% > Full version should take care about creation and destruction of > > buffer. With all this mappings it is tricky. > > For the first implementation, this is not important. With all the > mappings, it is hard for the plugin to manage a single buffer for all > the forms. E.g., if clicking on a button should bring up another form, > then it is better to use a different buffer. It is easier for the client > of forms plugin to create a new window with a new temp buffer and show > forms, and wipe it off at the end. Handling this inside forms plugin > will need more thought. Your comments are welcome. Maybe you are right. I am biased here - I hate buffer management and if someone else can take care about that... ;) > Thanks again for your feedback. I uploaded the new version here: > > http://haridara.googlepages.com/forms.vim > I will check it in the evening. m.
Re: forms support for Vim
Hello, Interesting concept. The most difficult thing are Vim habits. Seeing spelling error in line before I tend to make k than which is obviously messing things. >- Use in fields to cancel changes and restore old value. This doesn't work. I am getting 17|v$h Cannot accept entry from combobox, CTRL-Y jumps to first element, anything else doesn't work or insert 17|v$h. thing is inserted also when hitting twice. > I would appreciate any kind of feedback on this. Random remarks: After completely removing of entry tabbing goes wild (it works only from first entry to removed one). Combobox (Zip-code) is only drop-down menu: in combobox you should be able to insert your own values. Avoid mappings. They don't always and everywhere work. Better use something like f to go to the First name field. Introduce Arrows (, ) navigation. Although Tab works everywhere doesn't work in terminal. Currently , are extending visual selection to other fields. Hotkey emphasis should be rather done with syntax highlighting, not underscore (not always available). Full version should take care about creation and destruction of buffer. With all this mappings it is tricky. m.
Re: Mapping of keysequences...
Dnia niedziela, 1 października 2006 14:54, Meino Christian Cramer napisał: > Hi, > > is it possible to map the sequence of > > b > > to anything (and how?)? > > I tried as a first brute-force experiment > > noremap b echo "works" If you want to print it in the buffer it should be:: noremap b iecho "works" If you want to echo it in command line:: noremap b :echo "works" Normal mode mappings begin in Normal mode, not Insert or Command-Line. m.
Re: Vim7 and ispell?
Dnia czwartek, 28 września 2006 10:50, Markus Vuori napisał: > Hello, > > I'm a great fan of VIm editor and I've been using it for several years > now though I subscribed this list just a few minutes ago. :) > > I'd like to know how I can combine the Vim7 spellchecker > with ispell? I need ispell because Finnish requires an intelligent > spellchecker instead of just a "word list". Did you try built-in spellchecker? m.
Re: vim nxml?
Dnia środa, 20 września 2006 19:55, Aaron Mehl napisał: > Hi all, > > I asked this a while ago, but I will try again, > > Is there anything like nxml mode for vim? > > Especially for Docbook? > > and not just syntax highlighting but autocomplete and parse as you go > and . completion is available through omnicompletion. Data file for DocBook 4.4 (also script for generating other data files from DTDs) is available on vim-online. :h ft-xml-omni :h dtd2vim m.
Re: completeopt issue
Dnia czwartek, 7 września 2006 01:30, Chris Sutcliffe napisał: > Hey All, > > I'm not sure if this is a bug or if I'm missing something. In my > _vimrc file I have: What language do you want to complete? Maybe there is no completion script. m.
Re: mixed filetypes (was: Smarter Indent)
Dnia środa, 6 września 2006 14:22, Benji Fisher napisał: > If you use omnicompletion in your perl files, wouldn't > you like it to work when you are embedding perl in a shell script? This can be done already. In fact I've done it in php/js/html/css omnicompletion plugins. But it requires some imagination from script author and isn't easily extendible so some improvements would be nice. Almost perfect for this purposes was patch for GetChar autocommand but it was sent just before vim7 release :( m.
Re: PHP omni-completion, PHP objects
Had to got message from Yahoo Groups, original post was lost somewhere:
> with vim7's omni-completion how do you call/get functions/variables
> relating to a specific class?
>
> $object = new HTML_QuickForm();
> $object->
>
> And then after you type -> how do i call for completions only relating
> to the HTML_QuickForm class? I've tried the patch for ctags for PHP5
> but my results are the same, are there specific parameters to build
> the tags file for vim so i can call for suggestions relating to a
> specific class/object? I've been going into my pear/lib dir and
> typing:
> ctags -R
> I've also tried
> ctags -R --fields=+S
> But every time after i type -> i will always just get everything in
> the tags file including new class names. Is there a specific key combo
> i must press to get suggestions relating to the class/object?
This one was solved on priv. Implemented new feature, with positive
feedback new version will be sent to Bram to place on ftp.
> Also how can i build a tags file where functions will have parameters
> in the preview window? It already does this for php functions but for
> some reason pear libs and my code will always just be
> function_name()
> instead of
> function_name($param1,$param2,$etc)
Ctags for PHP is very simple and line based. If in PEAR functions are
defined in one line::
function fname($param2, $param1)
It should be extracted by ctags, will be shown in tags file and
omnicompletion plugin should show it in preview window.
Check if generated tags file has similar line::
write_cache cache.php /^ function write_cache(&$var,
$filename) {$/;"f
If answer is positive there is probably something wrong with plugin, if
negative check PEAR code or play with ctags options.
m.
Re: syntax borked
Dnia poniedziałek, 4 września 2006 16:44, Jorge Almeida napisał: > I've upgraded to vim-7.0.17. I don't know which version I had before, > probably 6.4. I run linux (gentoo). > After upgrading, syntax for perl seems to have gone to the trash. > Colours appear chaotic and pressing 'o' in normal mode opens a new line > but without the proper identation. How can such a thing happen? For syntax: you probably have some personalized syntax files which clash with default Vim7 ones. Changes required with spell checking could cause that effect. Check your .vim directory (and .vimrc file) and remove/comment all your definitions for perl files. Later you can reintroduce them carefully. m. -- W każdym z nas drzemie świnia. Ale u niektórych cierpi na bezsenność
For all people thinking about interface changes
Hello, Post from comp.editors: -- From: "Sascha T." <[EMAIL PROTECTED]> Newsgroups: comp.editors Subject: Re: The vim and emacs wars Date: 3 Sep 2006 16:21:41 -0700 I've been using Emacs eversince - for something like ten years, I guess. Really, I am extraordinary fast, I know every keystroke I need, even when asleep... Still, I've decided to switch to vim last week. Why? Well, because I have to be flexible. I am using Linux, Windows and MacOs to log into Linux/Aix/Whatever-Systems. And it is one thing to know every keystroke... but another thing to realize, that the META-key will not work, e.g. from OsX logging into Linux; or setting up a system that lacks of Emacs. Vi(m), luckily, lacks of the META-Key usage ;-) Really, the only powerfull, full-featured, highly customizable editor available on *every* system I've ever worked on is vi(m). And, most important to me, its user-interface is completely indifferent to the operating-system I use. That's why I decided to kiss Emacs good-bye... Sascha T.: --
Re: Vim BOF session
Dnia sobota, 2 września 2006 12:36, Kim Schulz napisał: > Omnicompletion++: > --- > Omnicompletion is a great new feature, but I would like to see it > become even stronger. The intellisense plugin for gvim on win32 has > some of the features I would love to see in the generic omni completion: > quickhelp for items in list if available: > http://insenvim.sourceforge.net/images/vis_help.jpg > parameter help in tooltip: > http://insenvim.sourceforge.net/images/vis_tooltip.jpg > Some of this might be possible to make with scripts, but it often tend > to become slow if not natively implemented. (and please kill the pink > color - it is really ugly) You point can be split in two: 1. Intellisense plugin is tied to widget system. It could mean that popup system had to be written each time for each GUI. Monstrous effort for writing and maintaining. 2. Info provided by intellisense can be provided by current implementation of omnicompletion. Problem is efficiency and size of data. For example inclusion of built-in functions in PHP omnicompletion caused that phpcomplete.vim has almost 300K. Adding help would easily explode that file to few M [1]. Parsing of PHPdoc is also possible but it could take time (phpcomplete is already sluggish). [1] Hmm. It could be done by external manual and dependency on `lynx -dump`. OK, done (1h), but it is unusable because scrolling of info window is practically impossible. m.
Re: Vim BOF session
Dnia sobota, 2 września 2006 04:21, Gabriel B. napisał: > didn't get if it was just a invitation to the brussels' talk or a > invite to a vim8 suggestion fest. so i'm bitting :) > > wrote that about vim7: > http://gabriel.barros.googlepages.com/vim7reviewrant Few comments: > - Spell checking support for about 50 languages > > I never dweled in the spellcheking, but i haven't seen any mention of aspell > or other well stabilished architeture used, so i assumed it was written from > scratch. Don't think that was clever. But i'm not going to look the horse's > teeths :) > Vim spellchecker is better than "aspell or other well stablished architecture". I was testing it extensively for Polish and helping (I hope ;) in development in non-coding way. > - Internal grep; works on all platforms, searches compressed files > > now, this i feel like making the same rant as the spell check. Why? oh why? > think of the children! > !grep Internal grep is godsend for people working on different architectures. No more guessing dialect of grep and supported regexp features. Also using all the time the same regular expressions is making life easier for script developers - point as above plus passing string to external program was always risky. All this quotes mess. > vim8 should be about interface and feedback. What about interface? Consistency and thesameness of interface on all platforms is what I like (and I think many people are sharing my sentiments). Sure, Vim could use more ncurses features like menus and dialogs but no serious overhaul can expected. > It's functional as it is today. But not easy yet. I don't suspect "easy" was goal for Vim ever. Effective, yes. m.
Re: utf8 vs string handling vs virtcol
Dnia czwartek, 31 sierpnia 2006 13:09, Thomas napisał:
> > This is wrong. You need:
> > let col = col(".")
> > let line = strpart(getline("."), col - 1)
>
> Unfortunately, IIRC this doesn't work with wrapped lines which is why I
> chose virtcol() ... But, well can't reproduce what I did (or thought
> that I did) 10 minutes ago. Anyway, it doesn't work with enc=utf8 and
> when there are malformed characters (not valid utf8) that are displayed
> as . Interestingly, virtcol() doesn't work in this situation either.
Solution is in Vim7::
let linearray = split(getline('.'), '.\zs')
Now you have all characters in line in separate positions in array. This
method plays nice with utf-8 characters.
m.
Re: Omnicompletion top window
Dnia czwartek, 10 sierpnia 2006 21:41, Panos Laganakos napisał: > Hello, > > I'd like to know if there's a way to get rid of the top horizontal > window that appears while we're using omnicompletion. > > Right now, after I Ctrl_X Ctrl_O and find the one I want I just type > it. While the balloon list disappears the horizontal window with the > info stays, so I have to > > Ctr_W k > > :q > > to get rid of it. Is there a faster way to make it go away once I'm > done with completion? Slightly faster (but with obvious drawbacks) is Ctrl-W_O. You could probably do some magic with pumvisible() function and some common mapping. Eg. map it to space end make window vanish as quick as you hit . m.
Re: Paragraph formatting options
Dnia sobota, 19 sierpnia 2006 05:36, cga2000 napisał: > > Is there any way I can tell Vim that when line 1 starts with a number > followed by a dot '.' .. the following lines should be indented so that > all the text is aligned. > > Not simple .. I guess .. since this could move into double digits (or > more..) -- there could be more than nine numbered paragraphs and text > should start in column 5 (or 6..). Vim7 option 'formatlistpat':: set formatlistpat=^\\s*\\(\\d\\+\\\|[A-Za-z]\\\|ps\\)[\\]:.)}]\\s\\+ will format digit and alpha/Alpha lists plus postscripts in mails. m.
Re: how to check if we are inside phpRegion
Dnia sobota, 5 sierpnia 2006 21:53, Yakov Lerner napisał: > Let's say I want to check if we are inside phpRegion > (). You will be better with searchpos() and comparing of cursor position. m.
Re: cterm256?
Dnia piątek, 4 sierpnia 2006 23:28, A.J.Mechelynck napisał: > cga2000 wrote: > > On Fri, Aug 04, 2006 at 09:12:46AM EDT, Mikolaj Machowski wrote: > >> Hello, > >> > >> Since Konsole in KDE 3.5.4 supports 256 colors it could be nice if > >> Vim could use them. Is any way to convince Vim to use guibg/guifg > >> from syntax files in console? > > > > If I understand correctly one problem is to map the 256 available > > colors to the 64K or 16M colors available in the gui. > > > > So just changing the keywords in the color scheme is not enough. > > > > Thanks > > > > cga > > I notice that in vim (7.0.42, Huge version with GTK2-GNOME GUI) run in > console mode in "Konsole 1.5 (Using kde 3.4.0 Level "b" SUSE 9.3)", > 'term' and $TERM are set to xterm, t_Co is set to 8, which means that > Vim believes that only 8 colors are available. ":runtime > syntax/colortest.vim" shows, however, 8 background colours but 16 > foreground colours. > > Under ":help xfree-xterm" there is (28 lines lower) a paragraph starting > "For 256 colors this has been reported to work:". Have you tried that? > (You would of course have to set t_Co to 256 and make sure that your > particular version of konsole can really display 256 different colours > at the same time.) > > I suppose that in these settings, is actually one character, not > five (hit Ctrl-V followed by Esc, it should appear as ^[ in the typed > text). Setting of t_AB and t_AF isn't necessary (for Konsole at least, not sure about xterm). > > Then you would have to use ctermfg= ctermbg= with *numbers* between 0 > and 255 inclusive. You might want to make a test file to highlight > itself with all those colours, just as syntax/colortest.vim does with > the 16 usual RGBI colours. You might also want to set X resources for > all of Xterm*color0 to Xterm*color255 as shown (for 16 colors) at the > above-mentioned place in the help. These X resources will then (if your > konsole uses them) establish the mapping from the 256 numbers 0-255 to > 256 of the 16M (2^12) colors theoretically mappable in the #xx > notation (where each x is a hex digit). Are you sure it will make reduction? In xterm man nothing mentions this functionality. Also it doesn't help much in my question: ctermfg/ctermbg will not take #xx number as argument - and automatic conversion of colorschemes from guifg/guibg isn't possible. Use of ctermfg with numbers is very nice and snippet:: se t_Co=256 syn clear for i in range(255) exe 'syn match E'.i.' /\l'.i.'%.*/' exe 'hi E'.i.' ctermfg='.i endfor Is giving great visual effects (especially on dense text) but no immediate reward for regular use. m.
cterm256?
Hello, Since Konsole in KDE 3.5.4 supports 256 colors it could be nice if Vim could use them. Is any way to convince Vim to use guibg/guifg from syntax files in console? m.
Re: Other European languages on a US keyboard
> Schleswig-Holstein to the plain of the Po. I suspect that most of > Central Europe would have adopted a German-derived (or maybe > French-derived) keyboard regardless of whether the majority language was > Czech, Slovak, Italian, Hungarian, Croatian... In fact Polish traditional keyboard is modelled after German layout (with addition of Polish diacritics on separate keys). Only very fast spreading of computers in the beginning of '90 connected with lack of production of those keyboards lead to wide adoption of Polish programmer keyboard (US 101 with diacritics by AltGr not separate keys). m.
ANN: VST 1.1 Wedel
Hello, Hello, Vim7 required. VST is script which makes possible to export text files with simple markup to HTML, LaTeX or HTML S5 presentation format to create even complex documents. Script doesn't require any external dependency and will work on any platform Vim7 is available. VST is Vim only implementation of reStructuredText. Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip ChangeLog ' - 1 Jul 2006 - **1.0** announcement - ADD: support for ltrim, rtrim, trim for regular replacement - CHG: `including commands`_ are working recursively now - FIX: wrong indentation of included files - FIX: problems with backslash as last character in line - FIX: minor fixes in docs - FIX: [pdf] incorrect call of cursor function List of changes with working links to documentation: http://skawina.eu.org/mikolaj/vst.html#lchangelog Supported elements of inline markup: - emphasised text (italic) - strongly emphasised text (bold) - hyperlinks (in various syntax forms) - custom decorations (among them: sub, sup, big, small) Elements of documents structure: - paragraphs - block quotes - ordered lists - unordered lists - option lists - footnotes - citations - images - preformatted text - colorized preformatted text (HTML export only) - tables - admonitions - table of contents Also bunch of auxiliary commands which should ease writing of document and navigating (folding, text table of contents, lists or declared links, replacements) Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip To install, place archive in ~/.vim directory and unpack it there. Documentation will be in ~/.vim/doc2 directory. Following versions of help file was produced without any modifications to HTML or LaTeX source: HTML: http://skawina.eu.org/mikolaj/vst.html LaTeX file exported from vst.txt: http://skawina.eu.org/mikolaj/vst.tex PDF file produced from vst.tex: http://skawina.eu.org/mikolaj/vst.pdf m.
Re: Generic xml omnicomplete
Dnia wtorek, 18 lipca 2006 19:39, A.J.Mechelynck napisał: > IMHO, inoremapping might be included as a vim-online > tip but definitely not as part of the standard XML/HTML filetype > plugins. This is NOT part of xmlcomplete.vim . Just standard response for autoclosing questions. m.
Re: A card game for Vim
Dnia środa, 19 lipca 2006 04:54, Hari Krishna Dara napisał: > First of all, thanks a lot for trying it, you are the only who showed > enthusism until now :) Most people probably pretend they are above small game of solitaire ;) > 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. One problem: all of them are leaving small artefacts (two or three pixels) after removing cards. :redraw! fixes that. Also when removing last card from free cards area (top left corner) whole column is highlighted like stack. > > 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). Sure, more is better :) m. -- Show time!
Re: A card game for Vim
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. > 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). > 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. Thanks, much fun :) m. ps. Any plans for final animation? ;)
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 > > to use F12 instead of Ctrl-X plus Ctrl-O I have swapped CapsLock and left Control and use: imap Exteremely handy :) m.
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 ' 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: ANN: VST 1.0 Finally
Dnia czwartek, 13 lipca 2006 13:00, sgp napisał: > I installed per provided instructions (WinXP) but when I type :Vst I get > a bunch of error messages, mostly undefined variables: > > g:plinen_rez > g:paras_rez > g:ptype_rez > etc. > > all of which are initialized in $VIM\vimfiles\autoload\vst\vst.vim but > don't seem to be picked up when :Vst is executed. > > :Vstm and :Vstfold work OK, it's just :Vst that doesn't. > > What do I need to do to make it work? TIA Cannot reproduce but you can help with: 1. Send me *exactly* what is in first two or three error messages (the rest is usually only consequence of them without real meaning). 2. Example of document where generation fails. 3. Such thing may happen when you try to generate several different documents in one Vim session. Global variables may clash in such situation. m.
Re: script installation from remote url
Dnia czwartek, 13 lipca 2006 11:26, Yakov Lerner napisał: > If not, then what's the closest existing thing to such :InstallScript > functionality ? You have also GetLatestVimScripts. But this is targeted directly to vim-online. m.
Re: Summarising all TODO / FIXMEs
Dnia sobota, 8 lipca 2006 23:58, Preben Randhol napisał: > Hi > > Is there any script for vim which can extract all TODOs, FIXMEs or > BUGs from a set of source code files and display them in a window. If > one could click on a FIXME/TODO and then jump to the right source code > file and line would be great. > > Thanks in advance > :vimgrep /TODO\|FIXME\|BUG/ % :copen :help vimgrep :help quickfix.txt m.
Re: Troubles with cursor()
Dnia wtorek, 4 lipca 2006 04:01, Peter Hodge napisał: > > Is this a feature or a bug? Looks like a bug. eval.txt explicitly mentions List with *2* or three items. m.
ANN: VST 1.0 Finally
Hello, Vim7 required. VST is script which makes possible to export text files with simple markup to HTML, LaTeX or HTML S5 presentation format to create even complex documents. Script doesn't require any external dependency and will work on any platform Vim7 is available. VST is Vim only implementation of reStructuredText. Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip ChangeLog ' - 12 Mar 2006 - **1.0-beta22** announcement - ADD: S5 document by George V. Reilly to show how it should be done - ADD: UTF-8 BULLET characters (without math symbols) are recognized as unordered lists bullets - ADD: support for "stacked" links_ - ADD: [LaTeX] support for `custom roles`_ - ADD: support for non-breaking space character - FIX: mangled URLs with excessive underscores - FIX: use 'fileencoding' when exists instead of 'encoding' - FIX: start processing only when format was properly declared - FIX: fix :Vst rep auxiliary command - FIX: show first line of paragraphs when folding by paragraph - FIX: various fixes List of changes with working links to documentation: http://skawina.eu.org/mikolaj/vst.html#lchangelog Supported elements of inline markup: - emphasised text (italic) - strongly emphasised text (bold) - hyperlinks (in various syntax forms) - custom decorations (among them: sub, sup, big, small) Elements of documents structure: - paragraphs - block quotes - ordered lists - unordered lists - option lists - footnotes - citations - images - preformatted text - colorized preformatted text (HTML export only) - tables - admonitions - table of contents Also bunch of auxiliary commands which should ease writing of document and navigating (folding, text table of contents, lists or declared links, replacements) Latest version of script files and documentation in text form: http://skawina.eu.org/mikolaj/vst.zip To install, place archive in ~/.vim directory and unpack it there. Following versions of help file was produced without any modifications to HTML or LaTeX source: HTML: http://skawina.eu.org/mikolaj/vst.html LaTeX file exported from vst.txt: http://skawina.eu.org/mikolaj/vst.tex PDF file produced from vst.tex: http://skawina.eu.org/mikolaj/vst.pdf m.
Re: Comments/Additional Notes for scripts
Dnia niedziela, 18 czerwca 2006 22:26, A.J.Mechelynck napisał: > > The "comments" section for vimtips is not very reliable (who goes back > every day to see if his tips have got a new comment added to them?). > Since vim-online scripts (unlike tips) require logging in, if you have a > comment you can email the maintainer. Maintainer could get notification by e-mail. Common feature in www forums. m.
Re: feature request: \s in [] in regexp
Dnia niedziela, 18 czerwca 2006 12:00, Yakov Lerner napisał: > vim unserstands \t and \n in [] in regexp (as tab and as newline). > > But \s is not treated as blanks in []. Can you please add > treatment of \s as blanks in [] in regexp. I mean, \s is sort of > space and Tab, no more complex than that, no ? \t and \n are single characters. Vim doesn't understand classes in []. But you can use [[:space:]] (but [:space:] is only and ). m.
Re: Bug with gU and German sharp s?
Dnia piątek, 16 czerwca 2006 13:34, Bram Moolenaar napisał: > > I see the problem. I'll put it in the todo list. Sub-problem with ß. In latin2 'encoding' (where ß also exists) it isn't changed to SS. I think behaviour should be the same for all encodings. m.
Re: Bug with gU and German sharp s?
Dnia piątek, 16 czerwca 2006 16:47, martin kraegeloh napisał: > hmm, well ... this is as buggy as the java String.toUpperCase() method > ;-) > > oracle for example does it right and leaves the sharp s as it is - > because there is no upper case variant of it. I was thought that capital version of ß is SS... m.
Re: omni completion, calling different types
Dnia środa, 14 czerwca 2006 17:37, David Fishburn napisał: > > It is triggered (while in insert mode) using followed by a key. > The key is what allows you to filter what is displayed in popup window. > The key can be many things: > t - table list > p - procedure list > v - view list > a - all syntax items > k - keywords (for the SQL syntax language) > And so on. > > > Perhaps Mikolaj could extend the PHP completion plugin in the same > manner. I'd prefer this functionality should be builtin into Vim completion system as submenus. m.
Re: Vim: Reading from stdin
Dnia wtorek, 13 czerwca 2006 17:22, John Love-Jensen napisał: > date | /usr/bin/vim -u NONE - Still the same. Vim7.017 m.
Re: omni completion, calling different types
Dnia poniedziałek, 12 czerwca 2006 19:39, Silent1 napisał: > I'm using the omni completion so far on my php scripts and i'm > wondering if there are ways i can call different sets of data with > different key strokes. You can use 'completefunc' to call different completion script. > ctrl-x+ctrl+o will bring up everything and display everything and will > open up a preview window that has info if a function is called with > parameters. How do i get the menu that comes up to display the > parameters as well? They come up in the preview window just fine just > wondering if i can see them in the drop down menu. No. For many (most?) built in functins popup menu would be too wide. > Also, everytime i start omni completion with ctrl-x+ctrl+o does it > research the file again and display everything including the new stuff > i may have typed? Part of it. > If so is there a quicker way to see functions with the parameters > without reloading the file? ctrl+n will bring up functions but will > not update the preview window. No. > Also is there a way that i can just call php functions with parameters > and not see functions/classes/variables in the file i'm editing? Also > the reverse say i would like to only see functions/classes/variables > in the current file or say just the variables? No. m.
Re: Vim: Reading from stdin
Dnia wtorek, 13 czerwca 2006 10:21, Yakov Lerner napisał: > On 6/13/06, Jorge Almeida <[EMAIL PROTECTED]> wrote: > > Is there some way to get rid of this _really annoying_ message we get > > after reading from STDIN? > > Which message ? I don't get any message: > date | vim - I get: Vim: Reading from stdin m.
Re: Bug with gU and German sharp s?
Dnia niedziela, 11 czerwca 2006 15:57, Bertram Scharpf napisał: > Is there any way to tell Vim to leave the `ß' as it was? Change encoding? In latin2 (where ß also exists) it is not changed into SS but IMO this is bug. m.
Re: Updated PHP syntax file
Dnia czwartek, 8 czerwca 2006 03:38, Peter Hodge napisał: > the file on my own web server. Stefano mentioned I should email the > updated file to Bram, should I also add it to vim.org/scripts/ as a > syntax script? (So that I can include a URL in the file for people to > find updates.) Both. m.
Re: how to fold lines not containing a pattern ?
Dnia poniedziałek, 5 czerwca 2006 13:51, Christian MICHON napisał: > > any help/hint appreciated. thanks in advance Tim already gave folding solution but you may be also interested in: :vimgrep /warning/ % m. ps. Vim7 required.
Re: spellcheck, and other spell checkers.
Dnia piątek, 26 maja 2006 15:19, Samuel Wright napisał: > How compatible is the new vim 7 spellcheck with other spellcheckers > (ispell, aspell, gtkspell, enchant)? Is it as simple as linking the > spellfile to the good word list already in use by the other checker? No. You have to create binary data file from aspell compatible word list. m.
Re: Deleting lines from L1 to L2 in Vim script
Dnia wtorek, 30 maja 2006 11:43, Baha-Eddine MOKADEM napisał: > Hi, > > > I would like to to delete line from L1 to L2, I try to script that but > obviously commands are different for a script. Why? Just place something like:: 5,10d in script and it will work. If you want to use variables:: let l1 = 5 let l2 = 10 exe l1.','.l2.'d' Checking if range exists may be tricky but not impossible. m.
Re: Need to Add 6 lines to many files
Dnia czwartek, 25 maja 2006 20:46, Mike Blonder napisał: > Thanks for the tips. > > the put command does NOT seem to work. The problem is that the line > number will change, from file to file, while the pattern will not. When > I try :argdo $put a m.
Re: spell checking with html doesn't work
Dnia piątek, 26 maja 2006 03:28, David Purton napisał: > > Any suggestions? It kind of looks like a bug, but maybe I'm missing > something obvious. Maybe you have some custom highlighting definitions for HTML? Remove them and check once more. m.
Re: Perl Support in Debian
Dnia czwartek, 25 maja 2006 18:02, William O'Higgins Witteman napisał: > I'm hoping someone has a quick fix for this. I have installed vim-perl > on Debian (from unstable) but when I look at :ver I see that Perl is > listed as "-perl". As I understand it, I should see "+perl". Is there > a way to fix this at run-time, or do I have to compile this in? Thanks. Only compilation option. --enable-perlinterp m.
Re: How do I make html autocompletion work?
Dnia poniedziałek, 22 maja 2006 09:56, victor NOAGBODJI napisał: > Hi, > There is a current post about the subject. > But the OP doesn't tell how to activate this feature. > > The autocompletion I need is either for tags, or for attributes... It should be activated automatically as soon as filetype is recognized. m.
Re: html auto completion
Dnia sobota, 20 maja 2006 07:11, Vu The Cuong napisał: > I'm new to vim and I tried a couple of hours to make html auto - > completion feature to work. > But had no result. Could anyone tell me how to config vim to turn on > html auto - completion? What system? If MS-Windows get rid of:: :so $VIMRUNTIME/mswin.vim Line in configuration scripts (it is remapping required for omni-completion). If it is no MS-Windows tell exactly what you are doing, error messages, example of file. m.
Re: HTML omni completion not working
Dnia piątek, 19 maja 2006 20:28, Adam Young napisał: > I am having trouble making the html autocomplete thing work in my vim > 7. This is the error that I receive: "undefined variable b:html_omni" > . Autocompletion for other languages (javascript, ruby, etc.) is > working fine. Anyone have any tips? What version of htmlcomplete.vim (Date field in header) ? And *full* error message please. m.
Re: Extending Vim7 with plugins
Dnia piątek, 19 maja 2006 19:07, Meino Christian Cramer napisał: > > IMHO the help files are only for those, who are know already, what > they are searching for. A newbie gets hopelessly lost. Not exactly. Newbie has to read whole Users Manual from the beginning to the end. There is no way to jump directly to usr_41 and understand everything. m.
Re: HTML editing with vim: where to start ?
> my guess is :source $VIMRUNTIME/mswin.vim -- the script that cripples > Vim in a not-very-successful attempt to make it more Windows-like. WTF, > if you want a Windows-like editor, don't use Vim, use Notepad! IMHO > mswin.vim is better done without. Hey, it is not *that* bad :) m.
Re: HTML editing with vim: where to start ?
Dnia środa, 17 maja 2006 22:27, Ivan Vecerina napisał: > "Mikolaj Machowski" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > : Dnia wtorek, 16 maja 2006 14:17, Ivan Vecerina napisał: > : > - get vim to automatically close/complete the innermost previously > : > opened tag. > : > : What do you mean automatically?. You can do: > : > : inoremap > > That's a great step forward, and I was able to make this work in a .html > file. > But it would not work in a PHP file Works for me. > Where can I find documentation for this feature (seems to be part of the > vim70 new enhancements), with which help keyword/tag ? :help ft-html-omni :help ft-php-omni :help ft-css-omni :help ft-javascript-omni > > [ I would never have fould this by chance, c-x does "cut" by default on > my install... ] :behave mswin? > How do I do an s/.../.../ on the current visual block? > [ I guess I can find out, but maybe you could answer this by the way ] For operation on visual blocks you need special plugins. Don't remember names (never need them). m.
