Loading ...
Sorry, an error occurred while loading the content.
Advanced Search
Author
Subject
Message
Special notice only

2,514 results from messages in vimdev

Advanced Search
  • On 20/05/13 12:17, tooth pik wrote: > I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is > getting bombed with a deadly signal ABRT when I try to edit my > index.html module > > my first instinct was to disable the runtime/plugin/tohtml.vim, but I > still get the deadly signal when I try to edit that file > > anybody else? > > tp > Patch 7.3.975 fixes a crash...
    Tony Mechelynck May 20, 2013
  • On 20/05/13 13:44, Bram Moolenaar wrote: > > Patch 7.3.975 > Problem: Crash in regexp parsing. > Solution: Correctly compute the end of allocated memory. > Files: src/regexp_nfa.c I had a crash when opening css files (not js or text files) with 're' set to 0 but this patch fixes it. :-) Best regards, Tony. -- "I've been teaching myself to play the piano for about 5 years and now...
    Tony Mechelynck May 20, 2013
  • On 20/05/13 05:53, Ben Fritz wrote: > On Sunday, May 19, 2013 10:18:48 PM UTC-5, mattn wrote: >> On Monday, May 20, 2013 11:50:08 AM UTC+9, Ben Fritz wrote: >>>> >>>> I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit. >>>> >>>> And cmd.exe really does stop responding when I pass gvim the -f flag. >>>> No prompt appears until Vim closes. Any typing done...
    Tony Mechelynck May 20, 2013
  • Fetching Sponsored Content...
  • On 19/05/13 22:08, Bram Moolenaar wrote: > > Tony Mechelynck wtote: > >> On 19/05/13 19:44, Bram Moolenaar wrote: >>> >>> I wrote: >>> >>>> Patch 7.3.970 >>> >>> All the tests I could do with the new engine pass. However, it is >>> noticeable slower than the old engine. If this bothers you, set the >>> 'regexpengine' option to one. >>> >>> If you spot a mistake in regexp pattern...
    Tony Mechelynck May 19, 2013
  • On 19/05/13 22:01, Ron Aaron wrote: > Don't know if it makes a difference, but I compile "big" version, for GTK2 with CFLAGS of > > -O3 -s -march=native -msse4.2 > > Only patch 970 causes the crash. > I get the crash in both huge (GTK2/Gnome) and tiny (no GUI) builds, at patchlevels 7.3.920 and later. (I haven't yet tried backing out patch 920 in a new unnamed branch of my...
    Tony Mechelynck May 19, 2013
  • On 19/05/13 21:52, Ron Aaron wrote: > Crashes for me: > > (gdb) bt > #0 0xb7fdd424 in __kernel_vsyscall () > #1 0xb75391df in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0xb753c825 in __GI_abort () at abort.c:91 > #3 0xb757639a in __libc_message (do_abort=2, fmt=0xb766e6c7 "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201 > #4...
    Tony Mechelynck May 19, 2013
  • On 19/05/13 20:02, Tony Mechelynck wrote: > On 19/05/13 19:44, Bram Moolenaar wrote: >> >> I wrote: >> >>> Patch 7.3.970 >> >> All the tests I could do with the new engine pass. However, it is >> noticeable slower than the old engine. If this bothers you, set the >> 'regexpengine' option to one. >> >> If you spot a mistake in regexp pattern matching, please send a >> reproducible...
    Tony Mechelynck May 19, 2013
  • On 19/05/13 19:44, Bram Moolenaar wrote: > > I wrote: > >> Patch 7.3.970 > > All the tests I could do with the new engine pass. However, it is > noticeable slower than the old engine. If this bothers you, set the > 'regexpengine' option to one. > > If you spot a mistake in regexp pattern matching, please send a > reproducible example, so that we can add it to the tests. > Compiling...
    Tony Mechelynck May 19, 2013
  • On 18/05/13 20:27, meh. wrote: > I'm writing a fairly complex statusline and using %!Func() as > statusline, everything was good until I started using my new shiny > statusline and I realized the context it's run in is the current > window and not the context %{} would use, so the one the statusline > belongs to. > > Is this intended? Because it makes doing what I want to do...
    Tony Mechelynck May 19, 2013
  • On 18/05/13 14:52, Xavier de Gaye wrote: > On Sat, May 18, 2013 at 2:07 PM, Bram Moolenaar wrote: >> >> Xavier de Gaye wrote: >> >>> runtime/doc/tags is under Mercurial control: >>> >>> $ hg locate runtime/doc/tags >>> runtime/doc/tags >>> >>> This file is automatically generated during vim build. >>> It is annoying to have it appear sometimes in the output of 'hg status' >>> or...
    Tony Mechelynck May 18, 2013