Re: Fix for crash in eval.c
On 22.05.2009, at 11:20, Bram Moolenaar wrote: Here is a new patch that hopefully fixes both the crash and the leaks. It's a bit tricky, but I think this catches all situations. Please verify. Note that with your script one needs to wait a few moments before exiting to give the garbage collector a chance. LGTM. Thanks for taking a look at this. I ran the offending script with and without this patch under valgrind, the patch seems to remove the double free without introducing a memory leak. Should there be a testcase for this in the test files? Nit: garbage_collect() now contains a single step labeled 1. -- perhaps get rid of the number? Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fix for crash in eval.c
Hi Bram On 05.05.2009, at 03:41, Bram Moolenaar wrote: Nico Weber wrote: Valgrind memory checker finds several errors in vim-7.2 (patches 1-148) with the reproduction steps described at http://groups.google.com/group/vim_mac/browse_thread/thread/4e0149ff4f84e3d3 : ==33469== Invalid read of size 4 ==33469==at 0x2D451: dict_unref (eval.c:6709) ==33469==by 0x3E4E7: clear_tv (eval.c:18558) ==33469==by 0x3F09B: vars_clear_ext (eval.c:18994) ==33469==by 0x4382B: free_funccal (eval.c:21466) ==33469==by 0x2D240: garbage_collect (eval.c:6595) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469== Address 0x7c290f0 is 0 bytes inside a block of size 176 free'd ==33469==at 0x25661B: free (vg_replace_malloc.c:322) ==33469==by 0xCDBDC: vim_free (misc2.c:1638) ==33469==by 0x2D59B: dict_free (eval.c:6753) ==33469==by 0x2D176: garbage_collect (eval.c:6559) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) ==33469== ==33469== Invalid write of size 4 ==33469==at 0x2D459: dict_unref (eval.c:6709) ==33469==by 0x3E4E7: clear_tv (eval.c:18558) ==33469==by 0x3F09B: vars_clear_ext (eval.c:18994) ==33469==by 0x4382B: free_funccal (eval.c:21466) ==33469==by 0x2D240: garbage_collect (eval.c:6595) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469== Address 0x7c290f0 is 0 bytes inside a block of size 176 free'd ==33469==at 0x25661B: free (vg_replace_malloc.c:322) ==33469==by 0xCDBDC: vim_free (misc2.c:1638) ==33469==by 0x2D59B: dict_free (eval.c:6753) ==33469==by 0x2D176: garbage_collect (eval.c:6559) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) I'm very glad you managed to pinpoint the problem and fix it. I'll check the details and include the patch. Thanks! as Dominique pointed out, while this patch fixes a double free(), it introduces a memory leak. The leak is smaller in the improved patch, but it's still there. Now, a leak is arguably better than a crash, but I wouldn't include this patch yet :-/ If you happen to know why the dicts copied by foo.vim are not freed with the second version of my patch, that would be great. Else, I will take another look next weekend. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fix for crash in eval.c
Hi, On 03.05.2009, at 00:03, Dominique Pellé wrote: After applying your patch, there are no such errors anymore. However, when exiting, I see that those blocks are not being freed: ==16990== 217 bytes in 10 blocks are possibly lost in loss record 36 of 57 ==16990==at 0x402603E: malloc (vg_replace_malloc.c:207) ==16990==by 0x81142FA: lalloc (misc2.c:866) ==16990==by 0x8114216: alloc (misc2.c:765) ==16990==by 0x807AD1D: dictitem_alloc (eval.c:6775) ==16990==by 0x8074FFD: set_var_lval (eval.c:2856) ==16990==by 0x80742F4: ex_let_one (eval.c:2414) ==16990==by 0x807329F: ex_let_vars (eval.c:1869) ==16990==by 0x8073250: ex_let (eval.c:1834) ==16990==by 0x80A6AA3: do_one_cmd (ex_docmd.c:2622) ==16990==by 0x80A4323: do_cmdline (ex_docmd.c:1096) ==16990==by 0x8090328: call_user_func (eval.c:21301) ==16990==by 0x807C4FE: call_func (eval.c:8079) ==16990==by 0x807C142: get_func_tv (eval.c:7925) ==16990==by 0x8075B83: ex_call (eval.c:) ==16990==by 0x80A6AA3: do_one_cmd (ex_docmd.c:2622) ==16990==by 0x80A4323: do_cmdline (ex_docmd.c:1096) ==16990==by 0x812A758: nv_colon (normal.c:5227) ==16990==by 0x8123DA2: normal_cmd (normal.c:1189) ==16990==by 0x80E6D49: main_loop (main.c:1180) ==16990==by 0x80E6896: main (main.c:939) I built Vim with -DEXITFREE (i.e. uncommented line PROFILE_CFLAGS = -DEXITFREE in src/Makefile) so normally all blocks should be freed when exiting. Thanks for checking. I've attached an updated version of the patch that fixes some of the leaks. The copy()d dicts in the script don't get freed, but I don't (yet?) understand why. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- eval_crash2.patch Description: Binary data
Fix for crash in eval.c
Hi, Valgrind memory checker finds several errors in vim-7.2 (patches 1-148) with the reproduction steps described at http://groups.google.com/group/vim_mac/browse_thread/thread/4e0149ff4f84e3d3 : ==33469== Conditional jump or move depends on uninitialised value(s) ==33469==at 0x437EA: can_free_funccal (eval.c:21449) ==33469==by 0x2D213: garbage_collect (eval.c:6591) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) ==33469==by 0x9F674: main_loop (main.c:1255) ==33469==by 0x9F167: main (main.c:1002) ==33469== ==33469== Conditional jump or move depends on uninitialised value(s) ==33469==at 0x437F8: can_free_funccal (eval.c:21449) ==33469==by 0x2D213: garbage_collect (eval.c:6591) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) ==33469==by 0x9F674: main_loop (main.c:1255) ==33469==by 0x9F167: main (main.c:1002) ==33469== ==33469== Invalid read of size 4 ==33469==at 0x2D451: dict_unref (eval.c:6709) ==33469==by 0x3E4E7: clear_tv (eval.c:18558) ==33469==by 0x3F09B: vars_clear_ext (eval.c:18994) ==33469==by 0x4382B: free_funccal (eval.c:21466) ==33469==by 0x2D240: garbage_collect (eval.c:6595) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469== Address 0x7c290f0 is 0 bytes inside a block of size 176 free'd ==33469==at 0x25661B: free (vg_replace_malloc.c:322) ==33469==by 0xCDBDC: vim_free (misc2.c:1638) ==33469==by 0x2D59B: dict_free (eval.c:6753) ==33469==by 0x2D176: garbage_collect (eval.c:6559) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) ==33469== ==33469== Invalid write of size 4 ==33469==at 0x2D459: dict_unref (eval.c:6709) ==33469==by 0x3E4E7: clear_tv (eval.c:18558) ==33469==by 0x3F09B: vars_clear_ext (eval.c:18994) ==33469==by 0x4382B: free_funccal (eval.c:21466) ==33469==by 0x2D240: garbage_collect (eval.c:6595) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469== Address 0x7c290f0 is 0 bytes inside a block of size 176 free'd ==33469==at 0x25661B: free (vg_replace_malloc.c:322) ==33469==by 0xCDBDC: vim_free (misc2.c:1638) ==33469==by 0x2D59B: dict_free (eval.c:6753) ==33469==by 0x2D176: garbage_collect (eval.c:6559) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) ==33469== ==33469== Invalid read of size 4 ==33469==at 0x2D45E: dict_unref (eval.c:6709) ==33469==by 0x3E4E7: clear_tv (eval.c:18558) ==33469==by 0x3F09B: vars_clear_ext (eval.c:18994) ==33469==by 0x4382B: free_funccal (eval.c:21466) ==33469==by 0x2D240: garbage_collect (eval.c:6595) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==
Re: Scrollbind when scrolling unfocussed window
This patch is completely rewritten, with very little in common with the previous one. Again, some review is much needed. I didn't adjust the documentation; is it customary for me to do that, or to have Bram do it? That's your job. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: need help, writting a new gui interface
Hi, On 20.12.2008, at 22:27, Wang.Hoi wrote: I'm trying to writing a KDE4 gui interface for vim. Is there any development hints/tips/documentations, especially for gui_mch_* functions. I only find src/README and source code comments. you can take a look at MacVim's source at http://repo.or.cz/w/MacVim.git?a=tree . All gui-specific functions are in src/MacVim/gui_macvim.m . MacVim has an interesting architecture to support several vim windows in one GUI process: Each window is backed by its own headless vim process, and each of theses processes belongs to an object in the GUI frontend. Even if you're not interested in following this approach, gui_macvim.m lists all the functions you need to implement (and a few that are optional). gui_macvim.m forwards requests to MMBackend.m which does RPC with MMVimControllers (which live in the GUI frontend process). The mapping from vim processes to MMVimController objects is done by MMAppController (connectBackend:...). Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed crash in vim-7.2.40 when compiling with gcc -O3
This code looks OK to me. Maybe it's a bug in gcc or maybe this construction is just not portable. I suspect it's a bug in gcc but I'm not 100% sure. Isn't it better to file this as a bug with gcc? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
The problem with all the $Id$ conflicts come from the runtime files updates Brörn does. He has committed the runtime updates into his vim branch and merges it into the master branch. I would suggest to use separate branches for macvim and the runtime updates. Wouldn't that make checking out, building and updating the macvim repo more complicated? Yes, a rebase does make more sense. But as I would separate macvim from runtime, I wouldn't just rebase macvim/master on vim_extended/vim. I just tried git format-patch macvim/vim..macvim/master. Then you have the bare macvim patches, as the runtime files are committed to macvim/vim, which you can apply with git am. But keep care, I found a patch with runtime file updates, commit ef6776890f3f3d324d7d32cb17fc1cefb0c61bd2 was committed to macvim/master instead of macvim/vim. Maybe there are some more? Anyway, I tried it for interest and the first conflict where git am failed was at patch 290 out of 672. As far as I know, macvim/vim contains the official runtime patches, and macvim/master also gets MacVim-specific runtime patches) Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: mac-osx and open
Hi Charles, On 09.11.2008, at 16:32, Charles E. Campbell, Jr. wrote: I was browsing the wiki -- and I noticed the tip Preview current HTML in browser on Mac OS X (well, a comment to it does): let g:netrw_browsex_viewer = 'open' so that the viewer triggered by x in the netrw browser will work on a mac. I'm not a mac user (yet), so for you mac user types: Would it be a good idea to use open if has(gui_mac) is true? This is probably better discussed on vim_mac, but: Yes, it's a good idea to use open, but as far as I understand, that's what's already happening. From the netrw.vim that ships with the latest MacVim snapshot: elseif has(macunix) executable(open) call Decho(exe silent !open .shellescape(fname,1). .redir) exe silent !open .shellescape(fname,1). .redir If I remember correctly, you added that about a year ago after I sent you a patch. So I guess the wiki is just outdated. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] Add Load/Ignore All buttons to File changed dialog
The patch doesn't apply because the = signs are encoded quoted-
printable
(=3D), even though they are in the ASCII charset.
Markus
To translate the quoted-printable, create the patch file by
cut-and-paste from your mail client (the message display, not the
view source display, of course).
Do you know how to work with KMail? It mangles whitespace when
copying from
the message window. What I can do is starting the editor window and
copy from
there. And I don't copy paste from the source window, I just save
the mail
as mbox, of course. Inline patches shouldn't contain quoted-
printable. Maybe
it wouldn't have been encoded without the umlaut in his name.
As the quoted-printed problem happens more often than it should, I
have the following in my .vimrc (all one line):
command QPd %!python -c 'import fileinput, quopri; print
quopri.decodestring(.join(list(fileinput.input('
It converts the current buffer from quoted-printable to normal text.
Nico
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Highlight a particular line
Hi, On 18.09.2008, at 07:00, [EMAIL PROTECTED] wrote: Hi everyone, I want to implement something like Flymake in Emacs. So I want to highlight the lines that has syntax errors. Can anyone provide any guidance on how to do that given the line number? Thanks! to highlight line 444, you could use :match Error /\%444l/ Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A small patch for gui_mac.c to let ATSUI support NON-antialias.
Hi, On 24.08.2008, at 20:09, LC Mi wrote: Thank you! How to submit the patch though? You've submitted it now. In my experience, Bram will add it to his TODO list and, if there are no reports about any problems, will merge it in a few months. I tried mac vim, looks great, but I didn't feel I had to do the switching for now... :-) Fair enough. If you submit a patch to MacVim, it's usually merged in a few days instead of a few months, though. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: opening huge files, a little slow
Hi, but that is not true. Reading the same file with a command like grep, takes 567msecs. is it faster if you do `set swapsync=` and `set nofsync` before reading the file? If so, ext3 is to blame: http://taint.org/2008/03/12/122601a.html Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Floating point syntax
Yes, but most people appear to be OK with the 123.456 syntax. Thus if you want something else, you need to come up with good arguments. I still haven't seen any good arguments why an editor needs floating point numbers at all, other than hey, it can be done without breaking old scripts with just slightly awkward syntax :-) Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [Patch] Nicer notebook tabs with GTK2
I would not say it's useless in the sense that icons make notebook tabs a bit nicer to look at. I actually never liked notebook tabs in GVim because they are too narrow and that makes difficult to spot the one I need (the main reason I wrote this small patch). Also, in this perspective, the toolbar is useless as it takes too much space for commands that can already easily be typed. But it's there because it's the GUI version and that's the way GUIs generally look like. The same goes for icons in notebook tabs: Almost all the GUI applications I can think of display such an icon although the label would be sufficient. It's just a bit nicer to look at. FWIW, I think this is a nice change. If I edit more than, say, 5 files, I can't use a tab for each file anyways. For just two to three tabs, the icons give the tabs a much nicer look (at least on GTK, where most tabs include file icons. In OS X, tabs usually don't have file icons, so I wouldn't want it in the OS X version). Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How many windows? tabs?
Hi, How can I find out (programmatically, of course) - how many windows do I have open in a split window - how many tabs do I have open in each of the split windows? I'm not quite sure what you're asking (tabs contain windows, not the other way round), but `:h tabpagebuflist()` should get you started. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC Application
Using eclipse, I believe it has a compilation system so that it compiles while you write the code, while compiling it checks for errors in the syntax, if there are any syntactical errors it will underline them and make it known to the user and won't let the user run the application until all of the errors are fixed. eclipse also does type-checking, method lookup and all the other stuff a compiler frontend does. Implementing a similar system in vim, I believe the hardest problems to deal with would be getting the compiler to compile often enough so that the user could see the errors and correct them quickly, but not so often as to affect the performance of the system. So updating of the compilation would need to occur asynchronously, depenedant on how much code is being written by the programmer and such. I believe this to be the crucial part of the project, because if the plugin is to be a feasible part of Vim, it needs to be so fast that the programmer doesn't want to turn it off. http://steve-yegge.blogspot.com/2008/03/js2-mode-new-javascript-mode-for-emacs.html has some (lengthy, rambling ;-) ) discussion on asynchronous parsing. I believe this could be accomplished with help from other projects such as GCC, G++, who would know good ways to rapidly update the compilation without affecting performance too greatly. A nice feature would be to have a gradual compilation, where the project is compiled as the programmer writes it, and so there is no big compilation at the end. Such a system is evident in eclipse, and VS has this as well. Any feedback on this is appreciated. As mentioned before, the clang project ( clang.llvm.org ) is an open- source frontend for C, C++ and ObjC. As far as I understand, Apple wants to use it in future XCode releases to do syntax highlighting, eclipse-like error highlighting, and refactoring. It is under active development by Apple employees and other contributors. It uses a library-based design, so you could run only the parser and not the type analysis for example. Writing your own frontend is madness :-) The real challenge is to come up with a general interface between vim and the language checking modules; writing a module for C with clang should be doable. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
There are yacc grammars available for several languages, including C, Matlab, and Lisp. The advantage of this approach is similar to the advantage of the syntax highlighting engine; its not particularly tied to any language. I mostly program in C/Matlab myself, but I know there's plenty of other languages and users out there (python, perl, sh/csh/ksh/zsh/tcsh/..., java, lisp, scheme, ada, matlab, ... apologies to those folks for whom I've missed mentioning their favorites) and tying a major feature of vim to one or two languages is probably not going to be universally appreciated. What I was advocating was the ability to use LALR grammars (read: yacc/bison) so that vim isn't tied to a particular language and, in fact, can be extended to cover future languages. A language checker has to do more than just grammar checking, you also need type checking, checks if a variable is defined before use, etc. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSOC: On-the-fly Code Checking for Vim - Challenges
Using a *built-in parser* is solution emphasized by Charles E. Campbell Jr in a related post. A parser would be perfect for syntax- checking, but I think the code checker should also detect errors like a misspelled library name. At least for C, you could use the clang C frontend ( clang.llvm.org ). It's a C frontend that uses a library design, so you should be able to use it in this project. As far as I understand, it can serialize its bytecode, so when the code is compiled for real, the parsing wouldn't have to be redone. If you could manage to create a flexible on-the-fly code checking system with an example code-checker for C based on clang (that'll also provide C++ and Obj-C support), that'd be quite useful. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (patch) new regexp
Benchmark result using ext-js.vim (507 849 Bytes javascript file) Try1: Gvim.exe: 11.1533138743 Gvim-re.exe: 39.4426857432 Have compiled both versions yourself or is gvim.exe the official build? Try3 is just running gvim.exe -c wq! ext-all.js How are the results if you just do `gvim[-re].exe -u NONE -U NONE -c wq!`? Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (patch) new regexp
Hi,
The patch does not work with Visual C++ 9.0 2008. The main problem is
this macros
+#define PUSH(s) { \
+ if (stackp = stack_end)\
+ return NULL;\
+ *stackp++ = s; \
+ }
+
+#define POP()({ \
+ if (stackp = stack)\
+ return NULL;\
+ *--stackp; \
+ })
But even though I have changed those macros to
#define PUSH(s) if (stackp = stack_end) return NULL; *stackp =
s; ++stackp;
#define POP(var) if (stackp = stack) return NULL; --stackp; var
= *stackp;
the resulting gvim executable seems to be losing its regex capability,
for example typing abc and then searching for a does not work.
({ ... }) is a gcc extension that converts statements to expressions.
The expression has the value of the last statement in the block (
http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC62
). That is, the macro can be used as
a = PUSH(s);
or in other places where an expression is expected. If you convert the
macro to a function, it should work on all compilers (and I guess it
won't even be slower since the compiler will inline the function call
automatically).
Nico
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: regexp: does anyone really need ordered alternation?
Interesting selection of languages to try ;-) You may have picked the
ones with a common regex code base. Russ Cox's article certainly
shows
similar performance/behaviour (See section and graph on Performance at
http://swtch.com/~rsc/regexp/regexp1.html) I wonder what Tcl and
awk do?
That's looks like an interesting article, thanks.
It doesn't really matter if all those languages share implementation
code. I just wanted to say that leftmost-longest is not what many
popular languages do. Java doesn't offer a repl, so I can't be
bothered to check that ;-)
Tcl does do a longest match, Javascript does the same as Python, Ruby
and Perl (at least the Spidermonkey implementation; the spec suggests
that this is correct (
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
, 15.10.2.3)).
nico$ tclsh
% regexp {ab|abc} abc matched
1
% puts $matched
abc
nico$ ~/src/js/spidermonkey/src/Darwin_DBG.OBJ/js
js abc.match(/ab|abc/)
ab
Nico
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: feature request: help users count lines - display relative line numbers
I have an idea which I think will make Vim much faster and easier to use. I find that over 4 lines or so, it becomes difficult to quickly count the number of lines I want to delete/yank/shift or whatever, and so I usually revert to using linewise Visual mode to select the lines I want to perform the operation on. Obviously it's much faster to (for example) press 23d than to press V followed by down 23 times and finally d to delete, etc. Then instead of visually selecting the lines upon which you want to operate, you can use an ex-command with a range, such as :2435,2457d Most of the time it's even faster to use v/ (and perhaps 'n' a few times) to jump to the line where you want to go in my experience. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Compilation warning
Hi, I get the following warning when compiling vim: ex_getln.c: In function ‘call_user_expand_func’: ex_getln.c:4697: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ That line is sprintf((char *)num, %d, STRLEN(xp-xp_pattern)); Adding an explicit cast makes the warning go away: sprintf((char *)num, %d, (int)STRLEN(xp-xp_pattern)); Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Is this close enough? :command BDP bp | bd # :command BDN bn | bd # Yes. Thanks :-) Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
- add collaborative editing: changes made to a file show up in another Vim in a second Do you mean changes to a file (ie. contents are only synced on file write) or do you mean changes to a buffer (ie collaborative real- time editing over the web)? Thanks, Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
Do you mean changes to a file (ie. contents are only synced on file write) or do you mean changes to a buffer (ie collaborative real- time editing over the web)? You are right, it should be buffer. I'll change it. Not sure about the over the web part. This won't be easy to implement locally anyway. What would this be good for if it works only locally then? Wow, this seems like an enormous can of worms. Do you have a centralized server or a peer-to-peer architecture? Discovery. Authentication. Security. Session management. Server farms. Distributed transactions. Failover. Recovery. Cross-platform. Buzzword bingo. Distributed transactions, failover, recovery, cross-platform and within limits even discovery, authenticaion and security are problems you have to deal with locally as well. (I'm not saying doing this over the web doesn't make it quite a bit harder, but I don't see any value in this feature without web support.) Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Documentation for /ordinary-atom missing \*?
Hi, you can use '\*' to match a literal '*' (with 'magic' set). I can't find this mentioned anywhere in the documentation. User error or missing documentation? Thanks, Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Documentation for $ in pattern
Hi, ^ is documented as: ^ At beginning of pattern or after \|, \(, \%( or \n: matches start-of-line; at other positions, matches literal '^'. |/zero-width| $ on the other hand is documented as: $ At end of pattern or in front of \| or \) (| or ) after \v): matches end-of-line EOL; at other positions, matches literal '$'. I'm having the impression that $ in front of \n and \%( matches EOL as well. Must the documentation be updated? Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: --remote-tab-silent not mentioned in --help
Ted Pavlic mentioned on the vim-mac list that --remote-tab-silent is not mentioned in the --help output and suggests to add it. I think that's a good idea. What do you think? There has been some positive feedback on this, so here's a patch to implement it. Bye, Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- help.patch Description: Binary data
--remote-tab-silent not mentioned in --help
Hi all, Ted Pavlic mentioned on the vim-mac list that --remote-tab-silent is not mentioned in the --help output and suggests to add it. I think that's a good idea. What do you think? Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch to allow ctermfg or bg values as #rrggbb
2) There is no algorithm available to programmatically judge the perceived differences between colors that suits our purposes. We do well with CIE L*a*b*, but not better than the stepping algorithm I proposed first, and in some places drastically worse. Unfortunately, CIE L*a*b* is only good at measuring the perceived differences between relatively similar colors, where the steps on our color cube are far enough apart that the colors are often not similar enough. Do you know about the Munsell color system ( http://en.wikipedia.org/wiki/Munsell_color_system )? It's a (the?) color system based on perceived colors, so perhaps is coul be used for your purpose. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Taglist plugin gives errors when switching tabs
Hi, I'm using the Taglist plugin version 4.5. If I open a taglist window with `:Tlist` in one tab, switch to another tab and back again, I get Error detected while processing function SNR17_Tlist_Refresh_Folds: line 24: E16: invalid range: 67,145fold Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: `match()` with branches [and a patch]
I wonder how often the detection will fail. @interface and @end could appear in a comment of a C or C++ file, at least. Esp. when using something like doxygen. What about '[EMAIL PROTECTED]|[EMAIL PROTECTED]' (and maybe throw in a '\|[EMAIL PROTECTED]' at the end for good measure)? The check could be turned into a one liner: .h files can be C, Ch C++, ObjC or ObjC++. Set c_syntax_for_h if you want C, ch_syntax_for_h if you want Ch. ObjC is detected automatically. au BufNewFile,BufRead *.h call s:FTheader() func! s:FTheader() if match(getline(1, min([line($), 200])), '@interface\|@end') -1 If we add the '^'s and '\|[EMAIL PROTECTED]', this line would be 80 chars. setf objc elseif exists(c_syntax_for_h) setf c elseif exists(ch_syntax_for_h) setf ch else setf cpp endif endfunc Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug with )
[Didn't get any acknowledgement of this; resending. For the to do list perhaps, Bram?] vim -u NONE iA sentence.Esc) The cursor is placed beyond end of line despite virtualedit being blank. I just tried it and saw no problem -- the cursor was atop the . (using either vim or gvim, BTW) as expected. (I'm using FC5 Linux, vim version 7.1 patches 1-162, huge) FWIW, I can reproduce it (vim 7.0.234 and MacVim 7.1.156). Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.160
Patch 7.1.160 Problem:When a focus autocommand is defined, getting or losing focus causes the hit-enter prompt to be redrawn. (Bjorn Winckler) Solution: Overwrite the last line. If you do `:intro` and lose or gain focus, the problem still happens. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.160
not for me, on gvim 7.1.162 for GTK2/Gnome2: I see a single hit- Enter line as soon as I use :intro and I never see a second one, even after losing and regaining focus. (I could see it in versions earlier than 7.1.160.) Is your window large enough so that the hit enter prompt is not in the last line (i have 'lines=50')? Do you have Focus* autocommands set? Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] forking gvim on os x
Hi,
on most systems vim forks when gui mode is entered. On OS X this is
not implemented. As a workaround, gvim is usually launched in the
background ('gvim ') from a separated script, so it can survive if
its spawning shell is closed. This has the undesirable side effect
that you can't pipe stdin to the shell script (at least I couldn't get
it to work):
$ cat test.sh
#!/bin/bash
/Applications/_Nico/Vim.app/Contents/MacOS/Vim -g $*
$ ls | ./test.sh
After that, vim claims that it's reading from stdin, but nothing shows
up in vim. If I remove the '' in the script, piping works fine, but
even after `^Z; bg` vim dies if I close the spawning shell.
Furthermore, in whatever way you tweak the script it's not possible to
make vim's '-f' (don't fork) flag work, which you need for example
if you set gvim as the EDITOR for version control programs.
To summarize:
1. If started with '-g', vim should become independent of its spawning
shell and still support reading from stdin
2. If started with '-f' and '-g', vim should _not_ do fork (but still
support reading from stdin)
Oh, and if started without '-g' and the doing `:gui`, things should
still kind of work.
As far as I see it, the only way to do all this is to add forking
support to vim's code. This is a bit difficult, as OS X doesn't really
support fork() in the way other unices do (see CAVEATS here:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/fork.2.html
All APIs, including global data symbols, in any framework or
library should be assumed to be unsafe after a fork() unless
explicitly documented to be safe or async-signal safe. If you need to
use these frameworks in the child process, you must exec. In this
situation it is reasonable to exec yourself. ), so I didn't add
complete support.
Here's what the attached patch does: If vim is started via '-g', it
forks and exec()s a new (!) vim instance in the child process. But if
the gui is started via `:gui`, no forking is done. I did some basic
testing and it seems to work, but I'm not very proficient in this kind
of code, so I'm thankful for comments.
This should work for all vim guis on OS X, but I tested it only with
MacVim.
If there's a simpler way to achieve the same thing, I'd be happy to
hear about it ;-)
Bye,
Nico
ps: Bjorn: If I do `ls | .../Vim -` followed by `:gui` in vim, and
finally cmd-q, I get a single
2007-11-23 16:33:14.603 MacVim[25537:10b] *** -[NSMachPort
handlePortMessage:]: dropping incoming DO message because the
connection or ports are invalid
message. I get this message only if I start in text mode, let it read
from stdin, and then switch over to gui mode (and close the window).
Any ideas why this is?
pps: This deprecates the '' at the end of most of the gvim and mvim
scripts on OS X out there.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
mac_fork.patch
Description: Binary data
Re: Integration of Vim
Hi Wynand, This is meant to run inside a virtual console (like the quake console) which receive all IO events primarily including mouse and keyboard events. Any help would be greatly appreciated as I have no idea where to start. this is not easily possible, there's no libVim. And even if you're willing to modify vim's source, it will be a lot of work because vim insists on owning the main loop (ie, code execution sits in vim and it just calls its gui parts every now and then). This is not what you want when you're writing a game. One thing you could try would be running vim in a separate process and talk to it via IPC. To do this, you could add a new GUI to vim which does nothing but forward drawing commands etc to your app and receives key input commands from your app. MacVim takes this approach, you can take a look at it's modifications to vim's source for some ideas ( http://code.google.com/p/macvim/ ). Short overview: MacVim/gui_macvim.m implements the gui functions vim is going to call and forwards them to a MMBackend, which uses OS X' IPC mechanism to send them to another process. Apart from that, you only need to look at the required modifications to vim's core (macvim-*-patch.tar.gz in the downloads section). But it's still a lot of work. Sorry for the bad news :-| Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: MacVIM: Right click spelling fix doesn't allow :spellr
Hi, Just throwing out little things I notice as I work with MacVim. Feel free to tell me to quiet down or report differently! If I correct a spelling error with 'z=' then I can use :spellr to fix the same mistake throughout the document. If I use the right-click option (way cool with the cascading list of options!) to fix the spelling, then :spellr reports 'E752: No previous spell replacement' I did some testing, it's like this on windows as well. And on gtk, the click on the corrected word in the context menu was ignored completely. So this is a general vim bug, not a MacVim bug. Another thing I noticed: If I write neccessary and `:set spell`, z= suggests Necessary but the popup menu suggests necessary. Is this intentional? Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Mac clipboard support
1. The snapshot archives contain multiple items at the top level. This is fairly nonstandard IMHO This is the normal way of packaging stuff in OS X because BOMUnarchiver (the program the finder invokes when you double-click a zip) creates a folder with the name of the zip for you. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
vim and git
Hi all, everytime I do some hacking on vim, I put my modified files into a local svn repository -- which is a bit cumbersome. I found this article today: http://live.gnome.org/GitForGnomeDevelopers This sounds as it could be very useful to other people working on vim as well. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim and git
I don't think Bram can migrating to git. We had tried to persuade him to switch to svn but he refused. I just suggest you using svk. It can make your current situation better. By the way, some files within the version control will be modified if you compile Vim in your local working directory. They are always a major trouble to me. Many developers complained for many times, trying to persuade Bram to remove those files out of the version control system, but they did no help at all. That it. I'm not saying vim should use git. The linked article describes how you can build a local git repo from an existing svn repo, how to sync it to svn updates every now and then, and how to use the git repo to create patches that you can email to this list. It doesn't require any changes for Bram (there's a svn repository already), it's just something that might be useful to other people. I'm sure you can tell git to ignore config.h and friends when generating patches too. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Handling Unicode codepoints outside the BMP
(the last screenshot shows that the new character is drawn twice: once at its original position, and once one to the right). The file I used for testing is attached. FWIW, it's in utf8. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: problem with MacVim
Apparently, it happens with plain vim (taken from svn). file-opened- in-another-session is a file which I have open in another Vim[*] window (application). Application just crashes. The official version works for me (I did `gvim ~/_vimrc` twice, worked fine). --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Errors unreadable with cursorline in default color scheme
Hi, `set cursorline` seems to override the background colors even for characters that are in group Error. With the default color scheme, this makes Errors unreadable: They are displayed with red background and white text, and the default cursorline color is a light grey. If the cursor is in the same line as the error, Errors are displayed with a light grey background and white text -- barely readable (tested on gvim/ubuntu and carbon vim/osx). Any ideas what could be done about this? Thanks, Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Errors unreadable with cursorline in default color scheme
Find an appropriate color scheme, or write your own. Either change the Error group (e.g. to _black_ on red), the CursorLine group (e.g. to underlined), or both. I prefer Ingo's suggestion -- cursorline shouldn't override background colors. It doesn't do it for hlsearch either atm. Even if this is not done, the default (!) colorscheme should Just Work. And if we expect each and every colorscheme author to manually take care of this, we can be sure that there are going to be lots of colorschemes that don't work with cursorline set. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Searching for Vim scripts
Try it out on the Vim search page (second box from the top): http://www.vim.org/search.php Very nice. A bit feature-laden perhaps ;-) Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: pum behaviour
Hi, As a result, I understood 1% of the code and had a 'behaving` pum, which only redraws the screen at the start,end and when hiding the pvw. If there is any interest, I can post that patch. I am interested. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: patch 7.1.080 (extra)
Hi, On Aug 18, 2007, at 5:00 PM, Bram Moolenaar wrote: Problem:Compiler warnings for using const char * for char *. Solution: Add type casts. (Chris Sutcliffe) at least in C++. this is a very dangerous patch. If you cast a const char* to a char* and then modify the char*, you get undefined behaviour (I guess this is not a problem now, but if searchpath() is changed to modify its argument array in the future, then this will introduce a bug). I don't know if this is true in C as well, does someone know? Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
