Re: security problem with ruby code completion in vim
Nikolai Weibull wrote: On 6/6/06, Martin Povolný [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 6/6/06, Martin Povolný [EMAIL PROTECTED] wrote: require 'a' Here's where it happens. It will actually require 'a' so that it knows about the stuff in that file. $SAFE _may_ be a solution. I understand how and why it happends. I report that it is a _security_problem_ and it should be fixed. Oh, excuse me; I feel so silly for trying to clarify the situation for everyone else. What was I thinking? Well I didn't mean to run into you, sorry if I did. I'm not a native speaker so I don't get all information between lines. I think what you have written is obvious and it's even documented in the VIM help. Node ft-ruby-omni says: Notes: - Vim will load/evaluate code in order to provide completions. This may cause some code execution, which may be a concern. I expected people on this list to know more then I about all this and therefor read your message as addressed to me. Anyway no need for irony. Lets focus on the problem. -- Mgr. Martin Povolný, soLNet, s.r.o., +42014458, [EMAIL PROTECTED]
testmail
testmail
testmail
testmail
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])
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
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 v-word here 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: 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: 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
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: 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: 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 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: 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: 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
