Re: BUG: wrong recognition of words in Vim7.1b on Windows
Dnia poniedziałek 21 maj 2007, Bram Moolenaar napisał: That @ means that Vim uses the library function isalpha(). Apparently your environment is not setup properly for isalpha() to work with your encoding cp1250. Thus that is a problem with your library/system/environment. Well, I installed Vim on three MS-Windows XP machines coming from different vendors and everywhere was that bug. Looks like classic example of: 1. MS-Windows is always right 2. If MS-Windows is wrong see 1. m. -- The world really isn't any worse. It's just that the news coverage is so much better.
Re: google summer of code
Dnia czwartek 15 marzec 2007, Josh napisał: I am interested in creating a kde or other window manager interface for vim, While I'd like to see kvim resurrection with complete KDE integration it is pointless at the moment: KDE3 is near its end, KDE4 isn't ready yet for serious coding. However: Qt4 GUI interface with the same GUI code for all major platforms (Linux, Windows, MOX, and several others), would be great thing. m.
Re: Google Summer of Code 2007 : Improve regexp performance
Dnia piątek 16 marzec 2007, Asiri Rathnayake napisał: A multithreaded matcher might be useful to vim but do we have a need for fuzzy matching ? For main regexp engine I think not. But it could be useful for command line completions (think zsh). m.
Re: .xht and .xhtml file extensions for xhtml filetype detection
Dnia poniedziałek 26 luty 2007, Bram Moolenaar napisał: Apparently nobody noticed them. Are *.xht and *.xhtml widely used for XHTML? Spotted .xhtml several times, never saw .xht . m.
Re: Vim crashing while starting nibbles game
Dnia czwartek 15 luty 2007, Hari Krishna Dara napisał: After I updated the nibbles game, a user reported that his gvim crashes Cannot start Nibble at all: Error in function SNR29_Nibble..nibble#Nibble: line 50: E416: cleared latest genutils and nibble. m.
Re: Vim 7 performance notes
Dnia środa 07 luty 2007, Alexei Alexandrov napisał: Hi Mikolaj Machowski, you wrote: Nice work. Could you send or place somewhere patches? I'd like to test them on more complex regexps. Here it is. Note that the biggest speed-up is observed when regexp is matched a lot of times. The regexp mechanism itself is not affected at all here - so if you have one regexp which runs very long you won't probably notice any major difference. When testing it with VST it gave 3.4% speed improvements (the same metodology - 3 tests before and after, choose the best results). m.
Re: Konsole: lost focus of window or tab
Dnia czwartek 18 styczeń 2007, Matthew Woehlke napisał: ...I am not a Vim hacker, but if you can rig Vim to handle some escape sequence, I may be able to help make Konsole understand/send them. A start might be to write a simple application that sends the sequence to turn on the function and then listens for them and takes some action (like beeping and/or printing a message with a time stamp) when it receives a notification. You could use that to test Konsole. (Read: if you write that, it will make me much more motivated to help you with hacking on Konsole :-).) I am not Vim hacker, not even programmer. The only I am able to do is simple shell thingy: #!/bin/bash read key if [ `echo $key | grep '24' ` ]; then echo -e 'you got it' fi 24 should be replaced by escape code, if code is coming from terminal maybe it should be ``read -e``, not just ``read``. In addition you have to manually press enter to go further :( Works with codes of function keys. m.
Re: Konsole: lost focus of window or tab
Dnia czwartek 18 styczeń 2007, Bram Moolenaar napisał: Note that we also need one to enable/disable getting these events. A program should only get the events when asked for. Are you talking here about Vim part or Konsole part? m.
Re: Konsole: lost focus of window or tab
Dnia piątek 19 styczeń 2007, Matthew Woehlke napisał: So, just to make sure I am following, Vim does or does not currently understand any escape sequences for focus events? It sounds like no, but then what about A.J.'s comment about reacting to [focus] events for 'the GUI and a few console versions where this can be detected'? From placement of focus related functions in Vim source looks like currently such events are supported only in GUI and Win32 console. There is no general code. m.
Re: Konsole: lost focus of window or tab
Dnia środa 17 styczeń 2007, Matthew Woehlke napisał: Matthew Woehlke wrote: Mikolaj Machowski wrote: Is it possible to recognize if window or tab of Konsole lost focus through termcap/terminfo sequence? Or is it at least possible with dcop or any other way? I am investigating ways to support Vim FocusGain/FocusLost autoevents. [snip long answer] [...and short answer, too] Robert Knight says we should be able to add escape sequences to Konsole to support this. I might be able to help with the patching (although it is KDE4 that will really get the fix, anything for KDE3 does not seem likely to be accepted, so you would be patching your own local version), I was waiting 2 years for Lists in VimL so I can wait several months for KDE 4 ;) but someone Vim-side needs to tell us what Konsole needs to provide... Looks like it should be similar communication like with mouse events. Proper escape codes - I suppose there is no standard at the moment. If Konsole would be first to do it there is chance that will become standard. Does Vim already support notifications for some terminal emulators? If so, how do we go about adding Konsole to that list? Comment in :ui.c:3010: says: /* * Called when focus changed. Used for the GUI or for systems where this can * be done in the console (Win32). */ m.
Re: Konsole: lost focus of window or tab
Dnia środa 17 styczeń 2007, Matthew Woehlke napisał: I'm willing to (try to, at least) help get this working in 3.5.x if you can dig up what the needed escapes are (it sounds like there are already existing examples?)... it probably won't be accepted but you could use it locally, and of course submit it for porting to KDE4. On kde-devel R. Knight said he can accept it to 3.5.7 release and later maintain it for KDE 4. Now, some start. I don't know much about term internals. I read something yesterday and today so forgive me if I wrote something stupid. Just seed for further discussion: Base info according to man terminfo: Variable String: focus_lost Cap name:flo TCapcode:fL Description: terminal lost focus Escape sequence: \E[1fl Variable String: focus_gained Cap name:fga TCapcode:fG Description: terminal gained focus Escape sequence: \E[1fg These sequences and names don't conflict with any other entry defined in my /etc/termcap or /usr/share/terminfo/** . m.
Re: [PATCH] count for CR in quickfix window
Dnia pon sty 1 2007, AOYAMA Shotaro napisał: Hi, Here is a small patch for specifying a window in which vim opens an error when you hit ENTER in a quickfix window. With this patch, you may hit 3CR in the quickfix window, then the selected error is displayed in the window #3. Often I face a situation that I want to display an error, but don't want to hide a buffer in the above window or open a new window and break window layout. I think this feature would be helpful in such time. What do you people think about this? Feature is definitely useful, I was very often missing such functionality. But way to open it... 3cr usually means go 3 lines down - even when it doesn't work in quickfix window. IMO better way would be to make C-WCR to accept count, eg.: 3C-WCR Note: decision belongs to Bram who is on his usual December/January holidays/visit to Uganda. m.
Re: correction in user manual (21.6 Modelines)
Dnia nie lis 26 2006, [EMAIL PROTECTED] napisał: I'm confused, because this is the latest version in SVN. See: https://svn.sourceforge.net/svnroot/vim/vim7/runtime/doc/usr_21.txt Doesn't HEAD in svn contain the latest version? CVS/SVN don't have runtime updates :( m.
Re: escape() and '
Dnia poniedziałek, 23 października 2006 16:25, Nikolai Weibull napisał:
On 10/23/06, Mikolaj Machowski [EMAIL PROTECTED] wrote:
Hello,
I understand that escape() was primarily designed to escape strings
when passing to system functions, but personally I never used that and
in didn't noticed such use in various scripts but very often it is
used to escape various charaters in Vim's own regexp matching or
passing one string to some other Vim command.
Hence is the problem: when escaping ' with escape(), character is
prepended with \ which doesn't make sense when passing it to other Vim
command because proper way to escape it in Vim is doubling it with
another '. Example::
:echo escape('as''df', )
There should really be a third, optional, parameter to escape() where
you can specify what character to use for escaping.
That wouldn't be real solution because to escape ' you still (in most
situations) would need two escape() calls. One for escape ' with ' and
second for rest of characters with \. The best solution is providing
info about context.
Yakov: why so much contexts? for single and double quotes there is only
difference in number of backslashes. Escaping in command line is rather
problem of which character should be escaped (most notably space), not
system of escaping.
I'd like to see only one flag additional and one default:
s - [default - for backward compatibility] system escaping with \
v - Vim escaping, ' for ' and possibly some other (future?) differences
m.
Re: escape() and '
Dnia wtorek, 24 października 2006 11:10, Nikolai Weibull napisał: Oh, I see. You're thinking of creating a string for passing to substitute() inside an :execute, or something like that. Ah, true, then you'd need to escape the single-quotes for the string, and, e.g., . with \.. Escaping is a lot more difficult than one often thinks, I suppose. Plus eg. matching string with string()'ed list. m.
Re: Patch 7.0.134
Dnia niedziela, 15 października 2006 15:10, Bram Moolenaar napisał: Patch 7.0.134 Problem:Crash when comparing a recursively looped List or Dictionary. Solution: Limit recursiveness for comparing to 1000. Is hardcoding any value like that good thing? It could use 'maxfuncdepth' - default value is only 100 but user can always adjust it to his liking. m.
Re: Why not commit runtime files?
I don't know exactly; but I think the various repositories (rsync, FTP, CVS, SVN) are not maintained by the same people. I think CVS and SVN use the FTP site as a master with automated updates (but not every day), so that the FTP updates trickle down to the CVS/SVN repositories after a delay of a few days or weeks. Only source files and some runtime files maintained directly by Bram. Updates send by other authors are rarely or never committed to CVS. SVN is synchronised only with CVS. Yes, it is a pity runtime files are not updated in CVS :( Theoretically I (and probably other people) could rsync directory according to your tip but it would wreak havoc in CVS structure... m.
Re: Vim 7.0 (1-109 patches) completion bug.
Dnia czwartek, 5 października 2006 05:16, Igor Prischepoff napisał: Hi, i think i have found a bug in vim 7.0 Patch level 1-109. Windows version +perl +python (i don't think this matters in this case) here is how to reproduce: gvim -u NONE -U NONE :set complete-=t don't want complete from tags file - it's not important, just to switch off message :set complete+=longest that's important i now we in insert mode one two oC-N:tC-Nnow trying to complete second time - no completion, nothing i.e. i've got resulting text in buffer like this: one two one:t and no 'two' on second C-N when trying to complete 'two' and message Back at original (First completion works as expected, but second didn't shown and not complete at all) if remove 'longest' from 'complete' then everything works as expected. Can you reproduce that bug? Confirming it for 7.0.110 (Linux, GTK2). Or it's intended behaviour? I don't think so. Note, when you press space and later return to the end of one:t it works. m.
Re: Python/Ruby completion requires language interface ?
Dnia środa, 27 września 2006 11:35, A.J.Mechelynck napisał: I notice that the scripts autoload/pythoncomplete.vim and autoload/rubycomplete.vim terminate early and with error if the corresponding interface is not compiled-in. Is that intentional? I would expect to be able to _edit_ (for instance) a python script even on a Vim version which cannot _run_ python commands. I don't agree with that. If interface is required for good completion it should be done using that interface. But even in such situation good degrading of script behaviour is required. Crashing IMO is unacceptable. m.
Re: Python/Ruby completion requires language interface ?
Dnia środa, 27 września 2006 14:27, Stefan Walk napisał:
The script terminates, not vim...
if !has('python')
echo Error: Required vim compiled with +python
finish
endif
is right at the start.
It could at least degrade to syntax highlighting completion.
m.
Re: No way to color-region(s) of text -- highlighter mode.
Dnia piątek, 4 sierpnia 2006 22:39, François Pinard napisał: [Mikolaj Machowski] [Mohsin]: Vim only has syntax coloring with regexps. Emacs has functions to apply properties to text blocks, and I was hoping vim has something comparable. Of course it is possible: :help /\%l :help /\%c Humph, not really! OP asked for highlighting. Text properties in Emacs span text regions, which move, expand or shrink while text is being edited outside or within them. Besides highlighting, text properties may also be used for making regions invisible (fully collapsed, not using any estate on the display), intangible (the cursor skips over them as if they were a single character), and many other things as well. Full collapsing was discussed some time ago and dismissed because there is no good way to show theirs existence when collapsed. m.
Re: Vim-Runtime
Dnia sobota, 5 sierpnia 2006 15:03, Martin Krischik napisał: - Many runtime files, and in particular most of the help files, have been reissued with new or updated contents for version 7.0. You should find them, for instance, under vim70/runtime/ in http://ftp.vim.org/pub/vim/unix/vim-7.0.tar.bz2 Many - but not all. Quite a few maintainers have updated there runtime after the release of vim 7.0 - The selectbuf/genutils pligin combo comes to my mind. They even produced errors. They are no part of standard distro. They have no right to be there. I fear the original maintainers of the **/ada.vim have files moved on - probably to the GNAT Programming Studio or a different programming language - who knows... So the question is indeed: how to become a maintainer? 1. Write directly to former maintainers about their stance. 2. Write publicly on vim-dev and vim lists about your intentions 3. Send improved files to Bram. m.
Re: findfile() results are inconsistent
Dnia wtorek, 25 lipca 2006 02:14, Eric Van Dewoestine napisał: 1. We are in /home/mikolaj:: echo findifile(b, 1;) 1/b You are giving findfile() a relative path to search, so it is returning a relative result. Result is the same regardless to path in second argument. m.
Re: findfile() results are inconsistent
Dnia wtorek, 25 lipca 2006 07:11, A.J.Mechelynck napisał: I don't see any inconsistency. According to the help, findfile() is Just like |finddir()|, but find a file instead of a directory. and finddir() has: When the found directory is below the current directory a relative path is returned. Otherwise a full path is returned. Isn't that what you got? OK. But even when described it is inconsistency. Is the semicolon really obligatory? :lcd $VIMRUNTIME/doc :echo findfile(help.txt,.) (without a colon), returns help.txt, which is the expected result. Try it from directory below $VIMRUNTIME/doc. Without ; it doesn't look up. m.
Re: findfile() results are inconsistent
Dnia wtorek, 25 lipca 2006 16:50, Eric Van Dewoestine napisał: So, the results are still consistent with the documented behavior. But not internally consistent. But OK - it is documented behaviour. Regarding ';', the docs imply that it forces a search upwards, but should probably state that explicitly. Maybe link to file-searching? Thanks Yakov. m.
findfile() results are inconsistent
Hello, Results of findfile() are inconsistent: /home/mikolaj/a /home/mikolaj/1/b /home/mikolaj/2/c /home/mikolaj/3/d /home/mikolaj/3/4/e 1. We are in /home/mikolaj:: echo findifile(b, 1;) 1/b 2. We are in /home/mikolaj/2:: echo findifile(b, /home/mikolaj/1;) /home/mikolaj/1/b 3. We are in /home/mikolaj/3/4:: echo findifile(d, /home/mikolaj/3/4;) /home/mikolaj/3/d Why this inconsistence? Also mention of ; as obligatory element would be good addition to docs. m.
Re: poll?
Dnia sobota, 22 lipca 2006 00:38, Kyle Wheeler napisał: Isn?t that the entire purpose of http://www.vim.org/sponsor/vote_results.php ? This is very fragmented. m.
Re: poll?
Dnia czwartek, 20 lipca 2006 23:55, Bram Moolenaar napisał: Yakov Lerner wrote: Bram, How about posting a poll on www.vim.org site ? Two polls ! (1) Do you you vim6 or vim 7 ? (2) Do you use console-mode-vim or gvim ? What would we do with the outcome? While I don't understood reason for first poll second should give insight what todo items should get bigger priority. Although console/gvim choice mostly depends on system. To get more significant results it should be more like: - console version on MS-Windows - GUI version on MS-Windows - console version on all other systems - GUI version on all other systems m.
Re: Gvim for KDE
Dnia środa, 19 lipca 2006 10:01, Vince Negri napisał: I recall that the merging of kvim patches into the Vim tree went further than that - the KDE gui is mentioned in the help files. I even seem to remember that at one point the gui_kde files appeared in CVS, It was working. I have compiled KDE version of Vim7 in that period. There was discussion few years ago about problems with KDE version. Major problem is incompatibility between glib event loop used by Vim and Qt event loop. But from various reports looks like Qt4.2 will be able to use glib event loop. It should a) remove some major hacks from kvim implementation b) remove unpleasant delay when using kvim. But to really test this we have to wait for official release of Qt4.2 and someone to write that port (I am not programmer) :/ But it would require to write completely new port - qvim because kdelibs won't be ready for third party things until fall (apart from some really adventurous programmers/users). Another possible approach would be to do a pure QT port rather than a KDE port (much of the old KDE code could be reused) as then the resulting GUI Vim would be cross-platform (now that QT4 is dual-licensed for Windows as well as Un*x) Probably good idea. Although KDE offers nice possibilities: kio-slaves, mox style menu bar. m.
Re: Gvim for KDE
Dnia poniedziałek, 17 lipca 2006 17:09, Charles E Campbell Jr napisał: As I recall, the vim7 kde port was dropped because there was no maintainer for the port. I'm not a KDE user myself, so I'm not a candidate, but perhaps if you volunteered to do KDE port+maintenance, you might be able to get it back in. I am not programmer but use KDE. IMO come back to KDE should wait until release of Qt4.2 . It should support glib event loop. Conflicts between glib and Qt event loops were major reasons for unresponsiveness of kvim. m.
Re: minor feature request: let!
Dnia niedziela, 2 lipca 2006 12:06, Nikolai Weibull napisał: On 7/1/06, justin constantino [EMAIL PROTECTED] wrote: E706: Variable type mismatch As a minor improvement, I think it would be nice if you could do: let foo = one,two,three let! foo = split(foo, ',') I think we should just remove the whole restriction. Definitely not. I was thinking about suggestion of :let! few times before and each time I was throwing it away. For example :let allows to change settings. Silently dropping changing of option value or setting it to some absurd setting would be Bad Thing(tm). m.
Matchparen highlight bug?
Hello,
Create empty file, enter {}, :new, cursor is in new window but parens
are still highlighted.
This example isn't extreme but when returning to previous window in many
colorschemes it makes hard to notice where cursor is.
This chunk fixes that:
function RmMH()
if exists('w:paren_hl_on') w:paren_hl_on
3match none
let w:paren_hl_on = 0
endif
endfunction
au WinLeave * call RmMH()
m.
Re: Proposal: New command/feature for quickfix
Dnia środa, 28 czerwca 2006 22:07, Jochen Baier napisał: i think a command like cbefore or croot could be usefull. using this command after a quickfix trip (vimgrep, Doesn't c-o fulfill your request? m.
Re: [BUG] Crash when modifying a:000
Dnia środa, 21 czerwca 2006 11:17, Nikolai Weibull napisał:
Something I found some time ago but for some reason forgot to report:
function A(...)
echo remove(a:000, 0)
endfunction
call A('a')
Confirming for 7.020
gdb output:
*** glibc detected *** free(): invalid pointer: 0xbfc099e8 ***
Program received signal SIGBART, Aborted.
[Switching to Thread -1219942176 (LWP 21002)]
0xe410 in __kernel_vsyscall ()
m.
writefile() in map-expr
Hello,
What was the biggest nuisance for me with ctags was operating only on
saved files. It made working on big files and updating them always a bit
tedious. Here is workaround - with possible big side effects:
Quick and dirty version - note expand() should take care about proper
place of saved file.
function! Semicolon()
call writefile(getline(1,'$'), expand('%'))
call system('ctags -R .')
return ';'
endfunction
inoremap expr silent ; Semicolon()
m.
Re: chk_menu_tran.pl: Quick and dirty perl utility to check for missing menu translations
Dnia czwartek, 4 maja 2006 01:16, Wojciech Pilorz napisał: I have just finished a perl script to test menu translation completeness; It reads menu.vim, attempts to extract menu definitions and compare with menu definitions in specified files from runtime/lang. synmenu.vim is not read, so for the languages for which syntax menu entries are translated there will be a lot of false 'Extra translation' messages; Please be aware that the script is a quick hack; it does NOT understand vim scripts syntax and semantics; Just a couple of regexes and hashed thrown together. So treat the messages with a good grain of salt. Anyway, I hope translation maintainers might find it useful - it detects a number of not translated menu entries, as well as some spelling problems You could rule out false positives as menu -separators-. Also format of messages is strange, info is split in two parts. How to write compiler for that? I've wrote that one: if exists(current_compiler) finish endif let current_compiler = menutrans let s:cpo_save = cpo set cpo-=C setlocal mp=chk_menu_tran.pl\ % setlocal errorformat= \%-GINFO%.%#, \%m\ at\ %f:%l%.%#, \%m\ in\ file\ %f:%l, \%m\ in\ %f:%l let cpo = s:cpo_save unlet s:cpo_save m.
Re: Bug: CursorLine highlighting wrong after search
Dnia czwartek, 4 maja 2006 16:30, Georg Dahn napisał: I am running gVim 7.0g02 on Windows XP. Confirming for gtk2 version. Last character is always highlighted and whole line becomes yellow (default color). BTW - also true for console version. VIM - Vi IMproved 7.0g02 BETA (2006 May 3, compiled May 4 2006 20:22:58) Skompilowany przez [EMAIL PROTECTED] Olbrzymia wersja z GTK2 GUI. Opcje włączone (+) lub nie (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile +python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save vimrc systemu: $VIM/vimrc vimrc użytkownika: $HOME/.vimrc exrc użytkownika: $HOME/.exrc gvimrc systemu: $VIM/gvimrc gvimrc użytkownika: $HOME/.gvimrc systemowy plik menu: $VIMRUNTIME/menu.vim odwet dla $VIM-a: /usr/local/share/vim Kompilacja: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O -I/usr/X11R6/include -I/usr/include/python2.4 -pthread Konsolidacja: gcc -L/usr/X11R6/lib -L/usr/X11R6/lib -L/usr/local/lib -o vim -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lfreetype -lfontconfig -lXrender -lXext -lpng12 -lz -lXt -lncurses -lacl -lgpm-L/usr/lib/python2.4/config -lpython2.4 -lutil -lm -Xlinker -export-dynamic m.
Re: mrxvtrc filetype and syntax files
Dnia czwartek, 27 kwietnia 2006 21:40, Nikolai Weibull napisał: Hi Nicolai, Hi. I'm curious, why did you spell my name with a 'c'? During the last couple of days, people have called me Nicholas, Niklas, and twice Nicolai. I see a conspiracy forming... Hello Mikolaj, It is popular name but in each language is spelled differently :) m.
Re: RFC: (x)html completion support in Vim7
Dnia poniedziałek, 24 kwietnia 2006 15:00, Benji Fisher napisał: I have not looked at the structure of the completion scripts, but isn't there a way for one script to include another? Under $VIMRUNTIME/ftplugin/ the file tex.vim (for LaTeX) :source's plaintex.vim , which :source's initex.vim . You should be able to do something similar with XHTML 1.0 Frameset/Transitional/Strict. Yes it is possible but because data files are generated automatically seeking a way to compress them is hard. Also, unification was done on level of engine between XML and HTML. This strategy no only reduces file size, it also makes maintenance easier. Actually no. Version with including had to be maintained manually and so far the only (reported) bug in data files was in file created manually. Also similarities between Frameset/Transitional/Strict are misleading and could lead to hard to spot errors. Add functions for detection of DOCTYPE to ftplugins for xhtml and html. Still there is usability problem for creation of new files. Maybe some general completion for insertion of DOCTYPE and setting appropriately completion. Right, and allow users to set a variable (g:html_omni_version or something) that the ftplugins can check to use as a default for new files. This will be done by insertion of DOCTYPE. m.
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 13:04, Bram Moolenaar napisał: Aaron Griffin wrote: Just a heads up: Using an omni-completion dictionary, a single completion entry (for which no menu is displayed) does not update the info preview window. Yes, filling the preview window is part of the code for the popup menu. If there is only one alternative you don't really need more info to make a choice, right? But old 'info' stays which may lead to misunderstandings. m.
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał: On a related note, an 'info' dict entry of '' does not change and/or remove the preview information. Using a single space blanks the window, but an empty string does not. And this is Good Thing :) m.
RFC: (x)html completion support in Vim7
Hello, I am author of (x)html completion scripts and related (php, css, javascript). I'd like to ask what you think it should like. At the beginning I was pushing for one default: XHTML 1.0 Strict. Bram didn't like it and now there are two: fot ft='html' HTML 4.01 Transitional and for ft=='xhtml' XHTML 1.0 Strict (user can still choose another version with b:html_omni_flavor variable - this improvement may be not yet in snapshot/cvs/svn). Bram still doesn't like it. According for him completion should be more flexible and not limited to some standard. For me it defies whole idea of omni-completion - completion suggestions should be precise. Problem with (X)HTML is there are many standards but creation of messy compilation from them has no sense. Vim is superb program and should support writing of good code - according to standards. To make this support full it could look: - provide data files for most of (X)HTML standards: - HTML 3.2 Strict (for legacy pages) - HTML 4.0 Transitional - HTML 4.0 Strict - HTML 4.0 Frameset - HTML 4.01 Transitional - HTML 4.01 Strict - HTML 4.01 Frameset - XHTML 1.0 Transitional - XHTML 1.0 Strict - XHTML 1.0 Frameset - XHTML 1.1 That is 11 data files, ca. 45kB each (5kB packed) - total 500 kB (55kB) Add functions for detection of DOCTYPE to ftplugins for xhtml and html. Still there is usability problem for creation of new files. Maybe some general completion for insertion of DOCTYPE and setting appropriately completion. TIA for comments. m.
Re: omni-completion: info bug
Dnia czwartek, 20 kwietnia 2006 21:59, Aaron Griffin napisał:
Is there any possiblity to get the preview window to pop up for single
completions? If not, I can always force a single empty entry like
{'word':'', 'abbr':'[Cancel]'} or some such oddity...
:help completeopt
menuone flag
m.
Re: omni-completion: info bug
Dnia piątek, 21 kwietnia 2006 00:20, Aaron Griffin napisał: Ack, sorry - that was supposed to go to the list On 4/20/06, Mikolaj Machowski [EMAIL PROTECTED] wrote: Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał: On a related note, an 'info' dict entry of '' does not change and/or remove the preview information. Using a single space blanks the window, but an empty string does not. And this is Good Thing :) Well here's the way I see it. If I have completions like so (format word:info): abc : 'this is info for abc' def : '' ghi : 'this is info for ghi' Starting on 'abc', you move down to 'def', and the info for 'abc' is left in the window. Fine, that may be intentional. Moving down to 'ghi' will switch the info, then moving back up to 'def' will give you the wrong info, assuming the 'correct' info was the entry for 'abc'. Buf if:: def : ' ' Window will be cleared. And that is Good Thing. m.
