On Thu, Aug 21, 2008 at 1:56 AM, Ben Schmidt wrote:
>
place your cursor on 'pwnme', and press K. xclock appears.
>>> Yeah, this is the kind of exploit where you have to tell the user to do
>>> something stupid and them blame Vim that the user is stupid.
>
> Yes. Still...that seems to be the
Hi,
Tony Mechelynck wrote:
> On 20/08/08 10:56, Jürgen Krämer wrote:
>> Hi,
>>
>> I have a lot of color schemes below ~/.vim/colors and ~ expands to
>> C:\Dokumente und Einstellungen\jkr.HABEL, so the execution of
>>
>>let s:n = globpath(&runtimepath, "colors/*.vim")
>>
>> in $VIMRUNTIME/men
>>> place your cursor on 'pwnme', and press K. xclock appears.
>> Yeah, this is the kind of exploit where you have to tell the user to do
>> something stupid and them blame Vim that the user is stupid.
Yes. Still...that seems to be the current trend...
>> The command executed can be an shell al
On Thu, Aug 21, 2008 at 12:55 AM, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Matt Wozniski wrote:
>
>> Jan got the exploit right, but formatted his modeline wrong. Try this
>> document:
>> /* We use an obscure glibc function -- check out the man page! */
>> clockface = &(xclock)&pwnme (a, b,
Matt Wozniski wrote:
> On Wed, Aug 20, 2008 at 4:33 AM, Tony Mechelynck wrote:
> >
> > On 20/08/08 09:47, Jan Minář wrote:
> >>
> >> The above will of course not work. The following will:
> >>
> >> /* We use an obscure glibc function -- check out the man page! */
> >> clockface =&(xcl
Tony Mechelynck wrote:
> >> E670: Mix of help file encodings within a language:
> >> /usr/local/share/vim/vimfiles/doc/hicolors.txt
> >>
> >> The error is given by the :helptags command.
> >>
> >> After investigation, it appears that all the *.txt files in
> >> $VIM/vimfiles/doc are in UTF-8 (or
> Ingo Karkat wrote:
> Use ":silent ! start %"; the 'silent' will close the DOS
> window immediately. I use this
> map x :silent ! start "1" "%:p" to execute
> the current file. ':p' makes this independent from the CWD,
> the surrounding "" make it handle spaces. The "1" is the
> optional "ti
Ya, looking at it again, I think you are right. Sounds good.
- Ian Kelling
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
On Wed, Aug 20, 2008 at 03:04:47PM -0400, James Vega wrote:
> On Wed, Aug 20, 2008 at 09:41:36AM -0700, Ian Kelling wrote:
> > I submitted a patch for this issue to Bram a while ago. I should have
> > posted it here too. Here are the differences in mine:
> > I found the issue was also already in to
On Wed, Aug 20, 2008 at 09:41:36AM -0700, Ian Kelling wrote:
> I submitted a patch for this issue to Bram a while ago. I should have
> posted it here too. Here are the differences in mine:
> I found the issue was also already in todo.txt so I included a patch.
I'm not sure if Gautam's issue is the
I submitted a patch for this issue to Bram a while ago. I should have
posted it here too. Here are the differences in mine:
I found the issue was also already in todo.txt so I included a patch.
I changed the scope of resolve_symlink slightly different. This seems
like a trivial difference.
I origi
On Thu, Aug 21, at 12:26 Robert Webb wrote:
>
> I could also use readfile(), which would probably suffice, but is this
> more or less efficient than loading a file into a vim buffer. I will
> still need to read the whole file either way since I don't know how
> far through the file I will need t
On Wed, Aug 06, 2008 at 01:11:30PM +0200, Bram Moolenaar wrote:
> Matt Wozniski wrote:
>
> > Try this:
> >
> > In terminal 1:
> > touch a
> > ln -s a b
> > vim b
> >
> > In terminal 2:
> > vim b
> >
> > We get:
> >
> > E325: ATTENTION
> > Found a swap file by the name "/tmp/vimtest/.a.swp"
> >
Robert Webb wrote:
> Hi,
>
> In a vim script, what's the best way to load a file (to search for
> some info), then get rid of it again without any side-effects.
> Eg, it shouldn't change the alternative buffer, it should no longer
> be loaded in a hidden buffer, and it should work even when there
I wrote:
> What's the best way (on Windows) to open a file from vim in whatever
> Windows normally uses to open that file? For example, :!% will open
> the current file, but it leaves a DOS window handing around while the
> file is open, which requires a hit-enter to get rid of after closing
> t
Robert Webb schrieb:
> Hi,
>
> What's the best way (on Windows) to open a file from vim in whatever
> Windows normally uses to open that file? For example, :!% will open
> the current file, but it leaves a DOS window handing around while the
> file is open, which requires a hit-enter to get rid
On 20-Aug-08 16:16, Robert Webb wrote:
> Hi,
>
> What's the best way (on Windows) to open a file from vim in whatever
> Windows normally uses to open that file? For example, :!% will open
> the current file, but it leaves a DOS window handing around while the
> file is open, which requires a hit
Hi,
In a vim script, what's the best way to load a file (to search for
some info), then get rid of it again without any side-effects.
Eg, it shouldn't change the alternative buffer, it should no longer
be loaded in a hidden buffer, and it should work even when there's not
enough room to split the
Hi,
What's the best way (on Windows) to open a file from vim in whatever
Windows normally uses to open that file? For example, :!% will open
the current file, but it leaves a DOS window handing around while the
file is open, which requires a hit-enter to get rid of after closing
the file.
You a
> This time Vim says ":!seamonkey www.example.com&xclock& which apparently
> doesn't do anything. Pasting the URL into the Location bar gives
I bet you're in gvim, right, Tony? I expect you're encountering the
"can't run processes in the background" problem that a number of users
have commented
On Wed, Aug 20, 2008 at 4:33 AM, Tony Mechelynck wrote:
>
> On 20/08/08 09:47, Jan Minář wrote:
>>
>> The above will of course not work. The following will:
>>
>> /* We use an obscure glibc function -- check out the man page! */
>> clockface =&(xclock)&pwnme (a, b, x + y);
>> /* :vi
On 20/08/08 10:56, Jürgen Krämer wrote:
> Hi,
>
> I have a lot of color schemes below ~/.vim/colors and ~ expands to
> C:\Dokumente und Einstellungen\jkr.HABEL, so the execution of
>
>let s:n = globpath(&runtimepath, "colors/*.vim")
>
> in $VIMRUNTIME/menu.vim returns a really long string (228
Hi,
I have a lot of color schemes below ~/.vim/colors and ~ expands to
C:\Dokumente und Einstellungen\jkr.HABEL, so the execution of
let s:n = globpath(&runtimepath, "colors/*.vim")
in $VIMRUNTIME/menu.vim returns a really long string (22881 chars, to be
exact). Currenty the loop which constr
On 20/08/08 09:47, Jan Minář wrote:
> On Wed, Aug 20, 2008 at 8:18 AM, Tony Mechelynck
> <[EMAIL PROTECTED]> wrote:
>> On 20/08/08 06:51, Jan Minář wrote:
>> [...]
>>> Opening the following URL using the K command will launch the
>>> xclock(1x) program:
>>>
>>> http://www.google.co.uk/searc
On Wed, Aug 20, 2008 at 8:18 AM, Tony Mechelynck
<[EMAIL PROTECTED]> wrote:
>
> On 20/08/08 06:51, Jan Minář wrote:
> [...]
>> Opening the following URL using the K command will launch the
>> xclock(1x) program:
>>
>> http://www.google.co.uk/search?q=&xclock&;
>
> Pasting this into the SeaMonk
On 20/08/08 06:51, Jan Minář wrote:
[...]
> Opening the following URL using the K command will launch the
> xclock(1x) program:
>
> http://www.google.co.uk/search?q=&xclock&;
Pasting this into the SeaMonkey location bar opens a Google page.
Hitting K on it in gvim with 'keywordprg' set to "
26 matches
Mail list logo
