Re: matchparen bug?
On Wed, Jun 07, 2006 at 03:07:49PM -0700, Gary Johnson wrote: > On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > > On 06/07/2006 15:10, Gary Johnson wrote: > > > On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > > > I haven't been following this discussion very closely, but I just > > > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP > > > with vim 7.0, no patches, and the cursor always goes to the 'o' in > > > the third line. Is that what you were looking for? > > > > Which test case are you using? My original snippet: > > > > let g:loaded_autoit_completion = 1 > > let s:cache_name = [] > > " This function is used for the 'omnifunc' option. > > > > Or Benji's: > > > > long line > > () > > another > > > > Reason I'm asking is because if you're using mine, then you do NOT see the > > bug. If you're using Benji's then you do see the bug. It's an unfortunate > > coincidence that 'o' signifies a success in one case but a failure in the > > other. > > I was using Benji's. ... I call that reproducing the bug. That makes three of us who see the bug, one who does not. Looking at the plugin, I think I understand what causes it. I explained that a few posts back, didn't I? HTH --Benji Fisher
Re: matchparen bug?
On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > On 06/07/2006 15:10, Gary Johnson wrote: > > On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > > I haven't been following this discussion very closely, but I just > > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP > > with vim 7.0, no patches, and the cursor always goes to the 'o' in > > the third line. Is that what you were looking for? > > Which test case are you using? My original snippet: > > let g:loaded_autoit_completion = 1 > let s:cache_name = [] > " This function is used for the 'omnifunc' option. > > Or Benji's: > > long line > () > another > > Reason I'm asking is because if you're using mine, then you do NOT see the > bug. If you're using Benji's then you do see the bug. It's an unfortunate > coincidence that 'o' signifies a success in one case but a failure in the > other. I was using Benji's. To be precise, I started vim at the shell prompt in Unix and at the Command Prompt in Windows as vim -u NONE Then I executed :set nocp Then I either typed or pasted long line () another and deleted the empty line 4, if present, so that the buffer contained only those three lines. Then I executed :runtime plugin/matchparen.vim And finally, I moved the cursor to the first line, typed $i and the cursor went to the 'o' in 'another' in all three cases. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: matchparen bug?
On 06/07/2006 15:10, Gary Johnson wrote: > On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > I haven't been following this discussion very closely, but I just > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP > with vim 7.0, no patches, and the cursor always goes to the 'o' in > the third line. Is that what you were looking for? Which test case are you using? My original snippet: let g:loaded_autoit_completion = 1 let s:cache_name = [] " This function is used for the 'omnifunc' option. Or Benji's: long line () another Reason I'm asking is because if you're using mine, then you do NOT see the bug. If you're using Benji's then you do see the bug. It's an unfortunate coincidence that 'o' signifies a success in one case but a failure in the other. Thanks. -- Jared
Re: gvim crash using mouse with mousefocus set on opensuse 10.1
William S Fulton wrote: [...] Just need spare time mate, but the SUSE guys have beat me to it already! There is a buffer overrun, all the gory details here: https://bugzilla.novell.com/show_bug.cgi?id=182212 It was reported as affecting vim 7 too. William Interesting... Notice the SuSE guys wrote a patch for it? If I were Bram, I'd have a look at that... Best regards, Tony.
Re: gvim crash using mouse with mousefocus set on opensuse 10.1
Benji Fisher wrote: > On Tue, Jun 06, 2006 at 10:27:12PM +0100, William S Fulton wrote: >> The version of gvim shipped with Suse 10.1 crashes when using the mouse. >> I've filed a bug: https://bugzilla.novell.com/show_bug.cgi?id=182212, >> but here is the stack trace again (below). Any suggestions on fixing >> this would be welcome. >> >> William >> > [stack trace snipped] >> [EMAIL PROTECTED]:~> gvim --version >> VIM - Vi IMproved 6.4 (2005 Oct 15, compiled May 2 2006 09:49:20) > > I could suggest upgrading to the current version (vim 7.0) but I > actually think that 6.4 is a little more stable. > >> Included patches: 1-6 >> Compiled by [EMAIL PROTECTED] >> Big version with GTK2 GUI. Features included (+) or not (-): > [snip] >> +path_extra +perl +postscript +printer +python +quickfix +rightleft -ruby > [snipp >> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK >> -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/X11R6/include >> -I/usr/include/libpng12 -I/opt/gnome/include/gtk-2.0 >> -I/opt/gnome/lib/gtk-2.0/include -I/opt/gnome/include/atk-1.0 >> -I/opt/gnome/include/pango-1.0 -I/opt/gnome/include/glib-2.0 >> -I/opt/gnome/lib/glib-2.0/include -O2 -march=i586 -mtune=i686 >> -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wall -pipe >> -fno-strict-aliasing -fstack-protector-all -I/usr/X11R6/include >> -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -pipe >> -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 >> -I/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE >> -I/usr/include/python2.4 -pthread >> Linking: gcc -L/usr/X11R6/lib -Wl,-E >> -Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE >> -L/usr/local/lib -o gvim -L/usr/X11R6/lib -L/opt/gnome/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 -lglitz -lXt -lncurses -lacl >> -lgpm -Wl,-E >> -Wl,-rpath,/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE >> /usr/lib/perl5/5.8.8/i586-linux-thread-multi/auto/DynaLoader/DynaLoader.a >> -L/usr/lib/perl5/5.8.8/i586-linux-thread-multi/CORE -lperl -lutil -lc >> -L/usr/lib/python2.4/config -lpython2.4 -lutil -lm -Xlinker -export-dynamic > > Bram often mentions that there are known problems with python and > multiple threads. It might be worth compiling yourself with big > features and -python to see whether that helps. If you have not > compiled vim before, read the instructions in the comments of > src/Makefile . > Just need spare time mate, but the SUSE guys have beat me to it already! There is a buffer overrun, all the gory details here: https://bugzilla.novell.com/show_bug.cgi?id=182212 It was reported as affecting vim 7 too. William
Re: matchparen bug?
On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > On 06/06/2006 23:47, Benji Fisher wrote: > > I am stumped. I tried it with > > > > $ vim -u NONE > > :set nocp > > :runtime plugin/matchparen.vim > > > > and I still get the cursor on the "o" in the third line. > > Benji, Ilya, > > I appreciate both of you taking the time to investigate. I'm a little > puzzled why Benji and I are seeing this issue, but Ilya is not. > > Can anyone else either confirm or refute this? Is it perhaps a > Windows-specific bug? I only currently have access to Vim 7 on a Windows > system, so I'm unable to test it under Linux. I haven't been following this discussion very closely, but I just tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP with vim 7.0, no patches, and the cursor always goes to the 'o' in the third line. Is that what you were looking for? HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Tony >> But if I invoke the Taskmanager by pressing Ctrl-Alt_Delete, >> then I observe a gvim zombie hanging around within the task >> list. >> > If it doesn't happen when you build with Big features (and an > otherwise identical configuration), then the only difference > between Big and Hige is that the latter has +profile > Thanks for that hint! I am doing some researches about this issue and am glad about such tips. Sincerely Mathias
Re: All mails lost
Yakov > ... That's why re-sending helps. > Thanks again! Yes, I experienced that once or twice too. But this time, waiting one night didn't help, so I thought it stays like that for ever: I am receiving mails, can't reply nor unsubscribe nor influence in any way what's going on. This is why I was a little bit in panic. Excuse me! Sincerely Mathias
Re: All mails lost
On 6/7/06, Mathias Michaelis <[EMAIL PROTECTED]> wrote: Thanks for reply -- I appreciate that also those nasty problems are discussed seriously. But anyway: I don't write HTML emails, I turn this (un-)feature off where ever it is possible. So this explanation can be excluded. Thinking about it again, I remember vaguely that I had at least 1 case when list ignored my message. What I did, I re-sent it next day and it got into the list. The truth is, email is not 100% reliable, neither is mailing list software. I do get outgoing email loss every now and then. Part of life. "Just re-send it next day" is my empirical rule that seems to work me. Not to talk about this case several months back when mailing list was totally dead for 3 days. Now, think about it, if mailing list can ignore all messages for 3 days, do you have a proof it can't ignore some random single message ? That's why re-sending helps. Yakov
Re: All mails lost
Tony > > I found that emails that are written on my Thunderbird Email > > Client AND where addressed to vim-dev@vim.org ... were filtered > > away, ... > > > There may be an explanation to that: Thunderbird writes its mail in HTML > by default, ... > Thanks for reply -- I appreciate that also those nasty problems are discussed seriously. But anyway: I don't write HTML emails, I turn this (un-)feature off where ever it is possible. So this explanation can be excluded. Sincerely Mathias Webmail TcNet GmbH http://www.tcnet.ch
Re: gvim crash after closing: gvim hanging in Windows XP Taskmanager
Mathias Michaelis wrote: Dear developers I observe the following strange behaviour of gvim 7.0 on Windows XP built with HUGE features by my own: I open gvim.exe, work with it or leave it without touching it for half an hour. Then, within gvim.exe, I type ":q" or ":wq". gvim saves the text, remove the .swp file and closes its window -- all as expected. But if I invoke the Taskmanager by pressing Ctrl-Alt_Delete, then I observe a gvim zombie hanging around within the task list. I have tried all to make this phenomena more reproducible, but nothing helps: You may open and close gvim hundred times, or may open and close with gvim a hundred files, you may do heavy work with it or can leave it alone, all that does not matter. The only thing that matters is the time you keep gvim open: On my (old) machine, gvim closes properly if I quit it after five minutes, but if I quit it only after 30 minutes, it keeps hanging around in the task list. There is a second parameter that matters: The features you include into your built of gvim. Alas, I could not yet found clearly, which features this strange behaviour depends on. Has anybody similar effects? Or do I do something wrong? See below how I built my version of gvim. Thanks very much for any help, hints, proposals or anything that could help to trace down this effect. With kind regards Mathias If it doesn't happen when you build with Big features (and an otherwise identical configuration), then the only difference between Big and Hige is that the latter has +profile Best regards, Tony.
Re: All mails lost
On 6/7/06, Mathias Michaelis <[EMAIL PROTECTED]> wrote: >> My emails are systematically filtered out. Find the 'plaintext' option in your Thunderbird client, and use it when you send to mailing list. I thought mailinglist filter was supposed to bounce back to you the html-formatted message in case this was the reason it ignored the message. In case the filter found your message spam-like or virus-like (always a possibility, depending on your writing style :-) , I think the filter might or might not indicate back to you why it discarded the message. If you're already experimenting with testmessages to the list, you potentially *could* (I mean, police would not stop you) do this: 1) send html-formatted "test, please ignore" message to the list and see what happens 2) *caution, violent material ahead* take copy of some spam message you received in the past, and send it (plaintext!) to the list with subject "test, please ignore" and see what happens. If you never received spam messages in the past, try this 1 liner: "Buy cheap." At this point, I'm starting to doubt whether this message of mine is going to make it into the list .. Hope this helps. Yakov P.S. The moral is: although you cannot know what happened in one single case, you can seek parameters and experiment to find connection between parameters and outcome.
Re: All mails lost
Mathias Michaelis wrote: [...] But: You don't see no of my mails written yesterday, and also not all from this morning. The testmail written at 09:03:28 +0200 is not from me, but from my Email-Provider. I found that emails that are written on my Thunderbird Email Client AND where addressed to vim-dev@vim.org or an address to unsubscribe from the list where filtered away, BUT emails written on the web interface of my ISP reached the list. [...] There may be an explanation to that: Thunderbird writes its mail in HTML by default, and the vim-list robot silently discards all HTML mail as an anti-spam measure. I use Thunderbird myself with no problems, even when writing to the Vim lists, but whenever I compose an email, I click Options -> Format -> Plain Text Only. (As a side-effect, this makes the toolbar disappear from below the "Subject" line, since fonts, bold, italic, etc., are for HTML only.) HTH, Tony.
Re: All mails lost
Hello Matthew, dear developers >> My emails are systematically filtered out. >> > I'm seeing your messages on the list. > First: Thanks for replying so fast! But: You don't see no of my mails written yesterday, and also not all from this morning. The testmail written at 09:03:28 +0200 is not from me, but from my Email-Provider. I found that emails that are written on my Thunderbird Email Client AND where addressed to vim-dev@vim.org or an address to unsubscribe from the list where filtered away, BUT emails written on the web interface of my ISP reached the list. I can verify that on the mail archive http://groups.yahoo.com/group/vimdev Although I have unsubscribed my self, I yet receive emails from the list and - suddenly - I can send emails again to the list. Very curious! > There have been situations in the past where the list has > silently discarded messages because they don't match some > arbitrary unpublished criterion, but that doesn't appear to be > the case here. > First I thought emails must not be written on Thunderbird, but that apparently isn't true any more. > [cc'd to poster to be certain the message gets through] > Thanks again for your reply! Best regards Mathias
Re: I just updated my Vim site
James Vega wrote: [...] I was more pointing this out for informational purposes instead of trying to push you to continue producing win32 versions of Vim. :) James Ah, that lifts a great weight off my heart. ;-) Especially now that I heard from Steve Hall that the reason he had stopped producing self-installers has now gone away. Best regards, Tony.
Re: All mails lost
On Wed, Jun 07, 2006 at 11:33:09AM +0200, Mathias Michaelis wrote: > My emails are systematically filtered out. I can't even unsubscribe > (why be on a list where own, very carefully composed contributions > aren't desired?). I already have phoned to my ISP, and he's innocent. I'm seeing your messages on the list. There have been situations in the past where the list has silently discarded messages because they don't match some arbitrary unpublished criterion, but that doesn't appear to be the case here. [cc'd to poster to be certain the message gets through] -- Matthew Winn ([EMAIL PROTECTED])
gvim crash after closing: gvim hanging in Windows XP Taskmanager
Dear developers I observe the following strange behaviour of gvim 7.0 on Windows XP built with HUGE features by my own: I open gvim.exe, work with it or leave it without touching it for half an hour. Then, within gvim.exe, I type ":q" or ":wq". gvim saves the text, remove the .swp file and closes its window -- all as expected. But if I invoke the Taskmanager by pressing Ctrl-Alt_Delete, then I observe a gvim zombie hanging around within the task list. I have tried all to make this phenomena more reproducible, but nothing helps: You may open and close gvim hundred times, or may open and close with gvim a hundred files, you may do heavy work with it or can leave it alone, all that does not matter. The only thing that matters is the time you keep gvim open: On my (old) machine, gvim closes properly if I quit it after five minutes, but if I quit it only after 30 minutes, it keeps hanging around in the task list. There is a second parameter that matters: The features you include into your built of gvim. Alas, I could not yet found clearly, which features this strange behaviour depends on. Has anybody similar effects? Or do I do something wrong? See below how I built my version of gvim. Thanks very much for any help, hints, proposals or anything that could help to trace down this effect. With kind regards Mathias -- How I built my version of gvim: I used the sources I found under ftp://ftp.vim.org/pub/vim/pc/vim70src.zip ftp://ftp.vim.org/pub/vim/pc/vim70rt.zip ftp://ftp.vim.org/pub/vim/pc/vim70lang.zip and used also if_sniff.c from ftp://ftp.vim.org/pub/vim/extra/vim-7.0-extra.tar.gz I applied all 17 patches I've grabbed from ftp://ftp.vim.org/pub/vim/patches/7.0 and also applied my own patches I sent to this list: http://groups.yahoo.com/group/vimdev/message/43765 http://groups.yahoo.com/group/vimdev/message/43821 http://groups.yahoo.com/group/vimdev/message/43825 http://groups.yahoo.com/group/vimdev/message/43850 To build gvim.exe, I used Microsoft Visual Studio 2005 Express Edition (VSEE) and issued the commands call "%VC8_DIR%\bin\vcvars32.bat" call "%SDK_DIR%\setenv" /XP32 /RETAIL nmake -f Make_mvc.mak FEATURES=HUGE GUI=yes OLE=yes \ MBYTE=yes IME=yes GIME=yes SNIFF=yes CSCOPE=yes \ ICONV=yes GETTEXT=yes POSTSCRIPT=no CPUNR=i686 \ WINVER=0x0500 PERL="%ProgramFiles%\ActivePerl" \ DYNAMIC_PERL=yes PERL_VER=58 Then I installed gvim by copying the .exe and .dlls as well as the runtime files to %ProgramFiles%\Vim\vim70 and by running install.exe. All worked great!
testmail
testmail
All mails lost
Dear developers My emails are systematically filtered out. I can't even unsubscribe (why be on a list where own, very carefully composed contributions aren't desired?). I already have phoned to my ISP, and he's innocent. Now I am really helpless. If this email reaches the list, I will once more try to logout myself. Best regards Mathias Webmail TcNet GmbH http://www.tcnet.ch
testmail
testmail Webmail TcNet GmbH http://www.tcnet.ch
testmail
testmail
