Re: accessing vim's clipboard from java

[A.J.Mechelynck]

Ernie Rael wrote:

Hi all,
I've just joined this list. I'm not a vim developer per se. However, I 
put together jVi, http://jvi.sourceforge.net , whose core is a port of 
some of vim to java. It runs on NetBeans ( and JBuilder, but not 
supported any more). jVi is based on vim-5.6.


A jVi user has added visual char/line and is now tackling block. So now 
I want to setup access to the *real* vim clipboard, so blockmode paste 
works between vim and jVi. So I'm learning how to access "native" data 
formats in clipboard from java.


I couldn't get anything to work, so I looked at the vim7 source, 
couldn't find windows source (I run cygwin, but not cygwin's vim, at 
home). I downloaded extras. I now see that the clipboard name has 
changed to VimClipboard2, and there's a whole lot more... So I changed 
the name, but still no luck. I thought I'd ping this list in case anyone 
has accessed the vim clipboard from java or has some clues.


As an experiment I'm doing
 public static final String VIM_CLIPBOARD2 = "VimClipboard2";
 SystemFlavorMap.addFlavorForUnencodedNative(
 ViManager.VIM_CLIPBOARD2, Misc.VimClipboardDataFlavor.get());
and the other way around. But after a paste into jVi from vim the 
DataFlavor I've defined is not available.


Any clues?

In os_mswin.c it looks like VimClipboard2 is always made available, so 
it should be there somewhere.


Once I get something working, I'll look at doing all the various 
encodings... based on VimClipboard2. Or maybe, I'll use VimClipboard2 
just to find out if it is MCHAR/MLINE/MBLOCK. Then  go to the regular  
DataFlavors to pick the string type I'm looking for.


-ernie



IIUC, there is no specific interface between Vim and java, so java will have 
to do whatever any other application may do, without special knowledge about Vim.


Whatever gvim writes to the + register is available in the system clipboard, 
just as if you'd used "Edit => Copy" in just about any application. There's 
nothing Vim-specific there.



Best regards,
Tony.
--
You know you have a small apartment when Rice Krispies echo.
-- S. Rickly Christian

Re: feedkeys() allowed in sandbox

[A.J.Mechelynck]

John Beckett wrote:
[...]

Is folding really needed in a default modeline?

John



Folding may be useful in a modeline. (Don't know what you call a "default" 
modeline.) Depending on how the particular file is written, you may want to 
set foldmethod=marker (and which marker), foldmethod=syntax, 
foldmethod=indent, or default it to whatever (if anything) is set by the 
filetype-plugin.



Best regards,
Tony.
--
Some of these fortunes are dated: I have an ADSL connection and a 96 gig HD, 
and I don't feel it's any special kind of achievement.

--
hundred-and-one symptoms of being an internet addict:
208. Your goals for the future are obtaining an ISDN connection and
 a 6 gig hard drive.

Vim binaries for Linux

[A.J.Mechelynck]

Announcement: I've tentatively uploaded my current vim binary. Here are the 
details and caveats:


- ":version" output is at 
http://users.skynet.be/antoine.mechelynck/vim/version.txt -- check this first 
before you attempt to download the executable.
- executable is at http://users.skynet.be/antoine.mechelynck/vim/vim -- to 
download it, you will probably have to click right on this link, then "Save 
Link Target As..." or whatever your mailer calls it.
- This is a "huge" Linux/i86 version with GTK2/Gnome GUI and support for perl, 
python, ruby and tcl, compiled on openSUSE 10.2. If you think it's overly 
bloated (and you quite well may), well, compile your own then: see e.g. my 
"how-to" page http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
- I compiled it about one and a half hours ago to the latest patchlevel 
(7.0.235), plus one additional (unnumbered) patch by Bram Moolenaar to fix the 
'maxmemtot' default value.
- This is a "naked" executable with no runtime files, no message translations 
and no ancillary programs (such as xxd). You will have to get all that from a 
different source such as ftp.vim.org, and keep them up-to-date yourself. This 
executable expects to find its runtime files starting at the default location, 
/usr/local/share/vim/vim70
- GNOME support, which is included, is *not* recommended by Bram. Warnings in 
the compilation of gui_gtk_x11.c seem to indicate that there "might" be 
problems with message translations, especially if you change the 'encoding' 
setting in your vimrc.
- It works on my machine with the software I have installed. I don't know if 
it will work on yours, so:
  - you may want to keep (under another name or path) a backup Vim executable 
which you got somewhere else, at least until you've verified that you can use 
this one.
  - I don't know exactly how much your system must resemble mine in order to 
be able to run this executable. I think the GUI won't run without GTK2 and 
Gnome2, and I don't know if this editor version will load without perl, 
python, ruby and tcl. You may want to check the bottom part of my ":version" 
text for other library names.
  - if it doesn't work for you, and you cannot make it work by (for instance) 
installing missing libraries, you may want to discuss symptoms with me, either 
on the vim-dev list if you think it's on-topic for the list, or by private 
mail. In the latter case, please use an explicit "Subject" line because if I 
don't recognise an email's Subject I treat it as spam; and I get a lot of spam.



Happy Vimming!
Tony.
--
For years a secret shame destroyed my peace --
I'd not read Eliot, Auden or MacNiece.
But now I think a thought that brings me hope:
Neither had Chaucer, Shakespeare, Milton, Pope.
-- Justin Richardson.

Re: vim 7.1?

[A.J.Mechelynck]

Ian Tegebo wrote:
[...]

Is the most updated TODO list for bug fixes and features "vim -c
':help todo.txt'" on a fresh build?



The most updated TODO list is the latest 
http://ftp.vim.org/pub/vim/runtime/doc/todo.txt


It is one of the most frequently modified helpfiles, and, like all runtime 
files, its changes are usually _not_ reflected in the patches. You've got to 
update your runtimes separately via ftp, rsync, cvs, svn or aap.



Best regards,
Tony.
--
USER, n.:
The word computer professionals use when they mean "idiot."
-- Dave Barry, "Claw Your Way to the Top"

Re: vim 7.1?

[Ian Tegebo]

On 4/28/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Ian Tegebo wrote:

> On 4/27/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> >
> > Jonathan Smith wrote:
> >
> > > With the insane number of patches collecting against 7.0, and
> > > presumably the new features accumulating in the devel tree, is anyone
> > > thinking about when a 7.1 release might be made?
> >
> > Yeah, it's about time for Vim 7.1.  Unfortunately I haven't found a good
> > moment to make a new release.  And I don't see it happening in the
> > coming weeks either...
>
> Would it be possible for people to help make new releases?

You can certainly help fixing bugs.  There is about a hundred of them at
the top of the todo list.

Is the most updated TODO list for bug fixes and features "vim -c
':help todo.txt'" on a fresh build?

--
Ian Tegebo

Re: [PATCH] new ex command :lscscope

[Navdeep Parhar]

Hello,

--- Yegappan Lakshmanan <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> On 4/28/07, Navdeep Parhar <[EMAIL PROTECTED]> wrote:
> > >
> > > > > > Hello,
> > > > > >
> > > > > > Currently :cscope has a variant :lcscope that allows the use of
> > > > > > the location list instead of the quickfix list.  However, :scscope
> > > > > > has no equivalent that uses the location list.  Please note that
> > > > > > :scs splits only if cscope returns some results, so :scs is not
> > > > > > the same as ":split cs".  Due to this reason ":split lcscope" can
> > > > > > not be used to get the same behaviour as the proposed :lscscope.
> > > > > >
> > > >
> > > > I'm confused.  I tried exercising this patch and I'm not getting the
> > > > results I expect, but I don't know if it's the patch, the behavior
> > > > of location lists, or me.
> > > >
> > >
> > > This problem is caused by the patch for the ":lscs" command.
> > >
> > > When the ":lcs" command is executed, a new location list is
> > > created for the current window and then the cursor is moved to the
> > > first entry in the location list.
> > >
> > > The ":lscs" command splits the window after the location list is
> > > created. This results in the problem.
> > >
> > > In your case,  when you executed the ":lscs" command in the
> > > first window, the new location list is added to the first window
> > > and then the window is split.
> > >
> > > When you invoked the second "lscs" command, a new location
> > > list is added to the second window and then the window is split.
> > >
> >
> > This is correct.  The problem both times is that the split takes
> > place after the error list has been constructed.
> >
> > I have reworked the patch a bit.  Now it splits the window
> > before constructing the error list.  I'd like to point out
> > that with this modification the behaviour if qf_init fails
> > will be different from what it is today.  The split will
> > have taken place by the time qf_init gets called.
> >
> 
> This may not be desirable. This will break backwards
> compatibility. When the ":lscscope" command fails, the
> current window should not be split and also the location
> list for the current window should not be modified.
> 

The location list of the current window is not modified by
":lsc".  Only the list of the new window (opened as a
result of the split) is affected.  So this leaves one
issue - what to do if the current window has already been
split and then there is a problem creating the error list.

qf_init wants a valid wp in order to work with llist.  This
wp must be of the new window or else we'll modify the
location list of the current window.  wp of the new window
can only be obtained once it exists.  This appears to be
a circular problem.  Any suggestions to get around this?

Is it acceptable to just close the newly opened window
in case an error occurs after the split?  Note that this
may cause some "flicker" like effects where a window/tab
is created and then disappears soon after.

-Navdeep

> - Yegappan
> 
> >
> >  Other than this everything should mostly work as advertised.
> >
> >
> > New patch is attached to this email.
> >
> > Regards,
> > Navdeep
> >
> > > Also, when jumping to the match from the location list, the
> > > location list for the window before the split is used. This results
> > > in the second problem you saw after closing the windows.
> > >
> > > When the location list support was added to Vim7, as the ":lscscope"
> > > command was not supported, this condition was not taken into
> > > account.
> > >
> > > - Yegappan
> > >
> >
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH] new ex command :lscscope

[Yegappan Lakshmanan]

Hi,

On 4/28/07, Navdeep Parhar <[EMAIL PROTECTED]> wrote:

>
> > > > Hello,
> > > >
> > > > Currently :cscope has a variant :lcscope that allows the use of
> > > > the location list instead of the quickfix list.  However, :scscope
> > > > has no equivalent that uses the location list.  Please note that
> > > > :scs splits only if cscope returns some results, so :scs is not
> > > > the same as ":split cs".  Due to this reason ":split lcscope" can
> > > > not be used to get the same behaviour as the proposed :lscscope.
> > > >
> >
> > I'm confused.  I tried exercising this patch and I'm not getting the
> > results I expect, but I don't know if it's the patch, the behavior
> > of location lists, or me.
> >
>
> This problem is caused by the patch for the ":lscs" command.
>
> When the ":lcs" command is executed, a new location list is
> created for the current window and then the cursor is moved to the
> first entry in the location list.
>
> The ":lscs" command splits the window after the location list is
> created. This results in the problem.
>
> In your case,  when you executed the ":lscs" command in the
> first window, the new location list is added to the first window
> and then the window is split.
>
> When you invoked the second "lscs" command, a new location
> list is added to the second window and then the window is split.
>

This is correct.  The problem both times is that the split takes
place after the error list has been constructed.

I have reworked the patch a bit.  Now it splits the window
before constructing the error list.  I'd like to point out
that with this modification the behaviour if qf_init fails
will be different from what it is today.  The split will
have taken place by the time qf_init gets called.



This may not be desirable. This will break backwards
compatibility. When the ":lscscope" command fails, the
current window should not be split and also the location
list for the current window should not be modified.

- Yegappan



 Other than this everything should mostly work as advertised.


New patch is attached to this email.

Regards,
Navdeep

> Also, when jumping to the match from the location list, the
> location list for the window before the split is used. This results
> in the second problem you saw after closing the windows.
>
> When the location list support was added to Vim7, as the ":lscscope"
> command was not supported, this condition was not taken into
> account.
>
> - Yegappan
>

Re: wish: collaboration of N vim instances editing same file

[Gregory Seidman]

On Sun, Apr 29, 2007 at 10:43:14PM +0200, Bram Moolenaar wrote:
> 
> Yakov Lerner wrote:
> 
> > Is it possible to add this item to the vim voting list ?:
> > 
> >   "collaboration of N vim instances editing same file"
> >   -- Ability of N instances of vim to absorb, merge and show changes
> >   to the same file made by other running vim instances [ either by reading
> >   other vim's swapfiles, or somehow else ] ?
> 
> It's an interesting idea.  Won't be easy to implement in such a way that
> it works on most platforms.

I think the hard part will mostly have to do with design/policy choices.

How is a session instigated? Does a single instance "own" the file and
other instances join? Or maybe there should be some server that fronts a
repository (e.g. svn, plain filesystem, WebDAV, etc.)? Or does it use svn
(or WebDAV, or other network fileshare) for everything, including
discovery, authentication, and inter-vim communication?

What kind of protocol should be used? It will be at least partially
homegrown, but is there a standard on which it should be based (perhaps
there is a standard for recording document edits beyond just diffs, I don't
know)? Should communication be over a star network of reliable (i.e. TCP)
connections? A mesh? A hypercube? A minimum spanning tree? Should it be,
instead, unreliable (i.e. UDP) multicast (which makes discovery easy and
authentication a separate protocol)?

None of these questions involve platform-specific issues, since they all
assume that communication will be over TCP/IP, but I don't think they have
easy answers. It mostly comes down to what problem you are trying to solve.
Some sample scenarios:

- allow a few (<5) open source developers work on the same source file,
  which has its primary existence in a subversion repository to which they
  all have write access, collaboratively across the net 

- allow developers (<5) in the same company work collaboratively on a
  source file over their company LAN

- allow massive numbers of people collaborate on some literary art project
  (e.g. a collaborative novel, something Wikipedia-like)

- provide a teleconferencing system for a few writers and a large number of
  readers across the net (e.g. teaching aid, "watch Bram code Vim"
  promotion)

- two, and only two, developers working together over a fast network

- allow a small group (<10) collaborators develop the Next Big Thing for
  their startup, despite each developer living in a different city

Each one implies different choices. If it's over the open net,
authentication and security are concerns, at least for writers. If
non-writers are allowed to spectate, you need some sort of permissions
system. Over the open net there needs to be some handling of timeouts and
lag. Smaller numbers of participants lets you cut corners in ways that
larger numbers of participants do not. Editing sensitive data (e.g. the
next Harry Potter, if J.K. Rowling used Vim and collaborated directly with
another author or with her editor) requires encryption over the network,
not to mention strong authentication. Making something that serves all
these needs is a massive undertaking, but since Vim gets used in all sorts
of environments, which scenario(s) do you choose?

> It will probably require a server to make it possible for various Vim
> instances to find each other.  And to take care of authentication.
> Perhaps such a server already exists?
[...]

As far as I know, the first implementation of this sort of idea to gain
real traction among users of text editors (i.e. largely developers) is
SubEthaEdit . It
uses MacOS X's Bonjour (which is an implementation of ZeroConf, see
http://developer.apple.com/opensource/internet/bonjour.html for Apple's
BSD-licensed implementation) for discovery.

I'd be inclined to go with the single instance owning the file and
announcing itself via ZeroConf, but I think even that requires either
requiring a particular ZeroConf implementation on the system or juggling
carefully which vim instance is responding to DNS requests. It also plays
no part in authentication.

Another alternative is to skip discovery and require some out-of-band
communication (e.g. IM, phone call, etc.) to communicate the host and port
to connect to. Of course, that makes authentication easy since the same
out-of-band communication can be used to give a password. No, that isn't
what you'd call strong authentication or good security, but it's probably
good enough for most people. Of course, your communication protocol should
be encrypted...

Authentication is prickly and I'm not sure how you'd choose what
authentication methods should be allowed (and implemented). Again, it falls
under the question of which scenario(s) we intend to serve.

I'll point out that this sort of thing is what first-person shooter network
play has been about since Doom first came out way back when. At the time,
the solution was to broadcast every keystroke 

Re: wish: show search progress on slow searches

[Yakov Lerner]

On 4/29/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:


Yakov Lerner wrote:

> Wish: when search is slow, show the progress line number
> every second on the bottom line (like, 12345 of 9).

What is slow?

To my taste, when something takes longer than 1-2 sec,
I'd prefer some visual feedback on the progress.


Checking if the second passed will make the search even slower.
Checking time is quite slow on some systems (the check for CTRL-C
suffers from this).


Checking for time every several hundred (N) lines will probably not slow
the search perceptibly. N can be configurable, a parameter.
Some value between 10 and 1000 will probaby be reasonable.

Yakov

Re: wish: show search progress on slow searches

[Bram Moolenaar]

Yakov Lerner wrote:

> Wish: when search is slow, show the progress line number
> every second on the bottom line (like, 12345 of 9).

What is slow?

Checking if the second passed will make the search even slower.
Checking time is quite slow on some systems (the check for CTRL-C
suffers from this).

> Maybe this can be done with plugin, I'm not sure.

Probably not without a big performance hit.

> Maybe simply status line can be refreshed once in a second,
> temporarily setting line number to the current search position.

That would be confusing.  Need to show it somewhere else (but where?).

> Some regexes take half minute to several minutes time on multimegabyte
> file. It would be nice to see the progress numbers onscreen.

True.  Some of my functions also echo the current line number now and
then.

-- 
"You know, it's at times like this when I'm trapped in a Vogon airlock with
a man from Betelgeuse and about to die of asphyxiation in deep space that I
really wish I'd listened to what my mother told me when I was young!"
"Why, what did she tell you?"
"I don't know, I didn't listen!"
-- Arthur Dent and Ford Prefect in Douglas Adams'
   "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: wish: collaboration of N vim instances editing same file

[Bram Moolenaar]

Yakov Lerner wrote:

> Is it possible to add this item to the vim voting list ?:
> 
>   "collaboration of N vim instances editing same file"
>   -- Ability of N instances of vim to absorb, merge and show changes
>   to the same file made by other running vim instances [ either by reading
>   other vim's swapfiles, or somehow else ] ?

It's an interesting idea.  Won't be easy to implement in such a way that
it works on most platforms.

It will probably require a server to make it possible for various Vim
instances to find each other.  And to take care of authentication.
Perhaps such a server already exists?

> Can this be added to SOC ?

Too late.

-- 
What a wonderfully exciting cough!  Do you mind if I join you?
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: valgrind filetype detection

[Bram Moolenaar]

Rodolfo Borges wrote:

> When opening a valgrind output file, the syntax highlighting was not
> being automatically turned on.
> I found that on scripts.vim it's checking for 'valgrind' on the first
> line, but my version of valgrind (3.2.1 ) prints 'Memcheck' instead.
> So I fixed it adding the second elseif bellow:
> 
>   " Valgrind
>   elseif s:line1 =~ '^==\d\+== valgrind'
> set ft=valgrind
>   elseif s:line1 =~ '^==\d\+== Memcheck'
> set ft=valgrind
> 
> Maybe this should be included on Vim distribution?

Memcheck is not valgrind, right?  Or is the format exactly the same?

One example I found starts with:

==16418== Memcheck, a memory error detector for x86-linux.
==16418== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==16418== Using valgrind-2.1.2, a program supervision framework for x86-linux.
==16418== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==16418== For more details, rerun with: -v
==16418==

So perhaps we should check for "Using valgrind" in the third line?  Or
is it possible that the header looks different?

-- 
'Well, here's something to occupy you and keep your mind off things.'
'It won't work, I have an exceptionally large mind.'
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: feedkeys() allowed in sandbox

[Bram Moolenaar]

Ciaran McCreesh wrote:

> On Sat, 28 Apr 2007 21:52:07 +0200
> Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > I don't like this solution.  Opening some files would be OK in the
> > sandbox, e.g., for reading.  readfile() would be OK in the sandbox,
> > right?
> 
> Probably not. In a multi-user environment it can be used as a
> privilege escalation by inserting the contents of a non-world-readable
> file into a world-readable file when the latter is edited by a user
> with elevated privileges.

In the sandbox you can't insert text into a file or buffer.  Anything
that requires saving text for undo is blocked.

You can also get the text from an already opened file with getbufline().
It's difficult to draw a line, but I think blocking everything that
writes is good enough.

-- 
`The Guide says there is an art to flying,' said Ford, `or at least a
knack. The knack lies in learning how to throw yourself at the ground
and miss.' He smiled weakly.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

A secure, configurable alternative to modelines

[Ciaran McCreesh]

I've written a script that reimplements a restricted form of modelines
as .vim code rather than internals:

http://www.vim.org/scripts/script.php?script_id=1876

It has two options that might be of use:

let g:secure_modelines_allowed_items = [
\ "textwidth",   "tw",
\ "softtabstop", "sts",
\ "tabstop", "ts",
\ "shiftwidth",  "sw",
\ "expandtab",   "et",
\ "filetype","ft",
\ "foldmethod",  "fdm",
\ "readonly","ro",   "noreadonly", "noro"
\ ] 

can be used to restrict which options can be set (the above is the
default value).

let g:secure_modelines_verbose = 0

If set to 1, warnings will be shown when a modeline attempts to set a
different value.

Feedback would be much appreciated.

-- 
Ciaran McCreesh



signature.asc
Description: PGP signature

Re: Syntax error: let a1 = 1 | let b = [1,2,3] | echo b[a1:-1] => Undefined variable a1:

[Thomas]

> Using ":" both for scopes and Sublist is not ideal.  But it's hard to
> think of something that is better.

Ruby uses .. for this (eg a[2..-1]), which has a mathematical touch. 
Putting spaces before and after the colon is perfectly ok for me though 
-- now that I know it.

Re: feedkeys() allowed in sandbox

[Ciaran McCreesh]

On Sat, 28 Apr 2007 21:52:07 +0200
Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> I don't like this solution.  Opening some files would be OK in the
> sandbox, e.g., for reading.  readfile() would be OK in the sandbox,
> right?

Probably not. In a multi-user environment it can be used as a
privilege escalation by inserting the contents of a non-world-readable
file into a world-readable file when the latter is edited by a user
with elevated privileges.

-- 
Ciaran McCreesh



signature.asc
Description: PGP signature

Re: Viminfo & dictionaries

[Thomas]

Only String and Number types are stored.


Okay, okay. I can see it now.

Sorry.

Re: Dictionary functions & function() & Funcrefs & & E120

[Bram Moolenaar]

Thomas wrote:

> And part #3:
> 
> Let's consider the following code in file foo.vim:
> 
> function! s:Foo() dict
>  echo self.data
> endf
> 
> let g:foo = {'data': 'bar', 'Foo': function('s:Foo')}
> 
> Now, when I type:
> 
> :source foo.vim
> :echo g:foo.Foo()
> 
> I get the following error:
> E120: Using  not in a script context: s:Foo
> E15: Invalid expression: g:foo.Foo()
> 
> When I place this in a file bar.vim and do :so bar.vim, I get:
> E117: Unknown function: s:Foo
> E15: Invalid expression: g:foo.Foo()
> 
>  From the help text on function()
> 
> > function({name})*function()* *E700*
> > Return a |Funcref| variable that refers to function {name}.
> > {name} can be a user defined function or an internal function.
> 
> I concluded that this function would do more that just storing the 
> functions name as string. Based on my example, it seems I was wrong. Not 
> being able to refer to script local functions, IMHO makes function() 
> rather pointless, I'd say.

It's very simple: script-local functions can only be used in the script
where they are defined.  If you want a dictionary-local function you
should use ":help numbered-function".

> One can work around the problem by using the trick described in :help 
>  though.
> 
> I also noticed some inconsistency with respect to whether funcrefs can 
> only be assigned to variables beginning with an upper-case letter.
> 
> Vim doesn't complain about
> 
> let g:foo = {'data': 'bar', 'foo': function('s:Foo')}
> call g:foo.foo()
> 
> but it throws E704 when doing:
> 
> let ffoo = function('s:Foo')
> 
>  From my experience with this, I'd say that this is too restrictive as, 
> e.g., call() also accepts a string. So a code like the following is 
> basically correct but won't be accepted by vimscript:
> 
> fun! Example(arg)
>  echo a:arg
> endf
> 
> fun! Caller(fn, args)
>  let afn = a:fn
>  return call(afn, a:args)
> endf
> 
> call Caller(function('Example'), [1])
> call Caller('Example', [1])

It's a matter of name spaces.  Inside a dictionary there is no conflict
with Vim functions.  In the global namespace Vim functions start with a
lower case character, user functions with an upper case character.
That's completely consistent.

-- 
I am also told that there is a logical proof out there somewhere
that demonstrates that there is no task which duct tape cannot handle.
-- Paul Brannan

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: Viminfo & dictionaries

[Bram Moolenaar]

Thomas wrote:

> Part two in this week's installment of unsolicited comment on vimscript:
> 
> I also realized that viminfo doesn't save upper case letter variables
> the values of which are dictionaries. This can be solved by using
> VimEnter & VimLeavePre autocommands and by converting the variable to &
> from strings. If this is intended to be so, I think this should be noted
> in the help -- AFAIK it currently isn't.

It's documented at ":help 'viminfo'":

CHARVALUE   ~
!   When included, save and restore global variables that start
with an uppercase letter, and don't contain a lowercase
letter.  Thus "KEEPTHIS and "K_L_M" are stored, but "KeepThis"
and "_K_L_M" are not.  Only String and Number types are
stored.


-- 
"So this is it," said Arthur, "we are going to die."
"Yes," said Ford, "except...no!  Wait a minute!"  He suddenly lunged across
the chamber at something behind Arthur's line of vision.  "What's this
switch?" he cried.
"What?   Where?" cried Arthur, twisting around.
"No, I was only fooling," said Ford, "we are going to die after all."
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: Syntax error: let a1 = 1 | let b = [1,2,3] | echo b[a1:-1] => Undefined variable a1:

[Bram Moolenaar]

Thomas wrote:

> The following code throws a "Undefined variable a1:" error:
> 
>   let a1 = 1 | let b = [1,2,3] | echo b[a1:-1]
> 
> When one puts a blank after a1, it's ok though:
> 
>   let a1 = 1 | let b = [1,2,3] | echo b[a1 : -1]
> 
> Since "a1" is no valid scope and "a1:" is an illegal variable name, IMHO
> this code shouldn't be considered ambiguous.

We want to keep the possibility open to add more scopes later.  Thus
anything that looks like {scope}:{name} is handled as such.

Using ":" both for scopes and Sublist is not ideal.  But it's hard to
think of something that is better.  Just always put a space before the
":" used for a Sublist.

-- 
I'm not familiar with this proof, but I'm aware of a significant
following of toddlers who believe that peanut butter is the solution
to all of life's problems...-- Tim Hammerquist

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

patch 7.0.235

[Bram Moolenaar]

Patch 7.0.235
Problem:It is possible to use writefile() in the sandbox.
Solution:   Add a few more checks for the sandbox.
Files:  src/eval.c


*** ../vim-7.0.234/src/eval.c   Fri Apr 27 22:17:43 2007
--- src/eval.c  Sat Apr 28 21:36:02 2007
***
*** 15598,15603 
--- 15598,15606 
  int   err = FALSE;
  FILE  *fd;
  
+ if (check_restricted() || check_secure())
+   return;
+ 
  if (argvars[1].v_type != VAR_UNKNOWN)
  {
/*
***
*** 16430,16435 
--- 16433,16441 
  char_u*s;
  int   ret = 0;
  int   c;
+ 
+ if (check_restricted() || check_secure())
+   return;
  
  if (argvars[0].v_type != VAR_LIST)
  {
*** ../vim-7.0.234/src/version.cFri Apr 27 22:17:43 2007
--- src/version.c   Sun Apr 29 13:54:29 2007
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 235,
  /**/

-- 
Now it is such a bizarrely improbable coincidence that anything as
mind-bogglingly useful as the Babel fish could have evolved purely by chance
that some thinkers have chosen to see it as a final and clinching proof of the
NON-existence of God.
The argument goes something like this: 'I refuse to prove that I exist,' says
God, 'for proof denies faith, and without faith I am nothing.'
'But,' says Man, 'the Babel fish is a dead giveaway, isn't it?  It could not
have evolved by chance.  It proves you exist, and so therefore, by your own
arguments, you don't.  QED.'
'Oh dear,' says God, 'I hadn't thought of that,' and promptly vanishes in a
puff of logic.
'Oh, that was easy,' says Man, and for an encore goes on to prove that black
is white and gets himself killed on the next pedestrian crossing.
-- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: feedkeys() allowed in sandbox

[John Beckett]

Matthew Winn wrote:

I don't like the idea of preventing modelines over 100 bytes.


I imagine (haven't looked) that a modeline has no hard limit to
its length. So multi-megabyte modelines are probably handled by
Vim. That's potentially offering attackers extraordinary power.

Would someone who wants a modeline longer than 100 bytes please
show us an example. How about a 200-byte limit?

Modelines are enabled by default, and are very useful for things
like setting tabs. So most people, and all new installs, will
have modelines enabled. It's very poor security practice to
offer a rich auto-execution environment with a single line of
defence (the sandbox).

This discussion reminds me of the days of the Code Red
vulnerability in IIS (Microsoft web server), and of the
years of repeated vulnerabilities in Internet Explorer.

The IIS and IE developers just couldn't bring themselves to
build in limits to what their wonderful software could do.
"But a web site might need a 100KB URL with hundreds of '../'
paths!".


Furthermore, what am I supposed to do if I want a long,
complicated but legitimate modeline?


I would like a default "high security" setting for handling
modelines. If people want modelines that do complex stuff, I
would recommend setting a new "anything goes" option.


I like Perl's approach to untrustworthy data. It's flagged as
tainted at the point it is read, and anything derived from it
is also flagged as tainted.


Perl has to have that system because part of its intended usage
is to handle data entered into web pages. It's pretty complex
and has taken years to get right.

Vim is a text editor - it should not automatically execute code
in any old file that I might accidentally open.

John

Dictionary functions & function() & Funcrefs & & E120

[Thomas]

Hi,

And part #3:

Let's consider the following code in file foo.vim:

function! s:Foo() dict
echo self.data
endf

let g:foo = {'data': 'bar', 'Foo': function('s:Foo')}

Now, when I type:

:source foo.vim
:echo g:foo.Foo()

I get the following error:
E120: Using  not in a script context: s:Foo
E15: Invalid expression: g:foo.Foo()

When I place this in a file bar.vim and do :so bar.vim, I get:
E117: Unknown function: s:Foo
E15: Invalid expression: g:foo.Foo()

From the help text on function()


function({name})*function()* *E700*
Return a |Funcref| variable that refers to function {name}.
{name} can be a user defined function or an internal function.


I concluded that this function would do more that just storing the 
functions name as string. Based on my example, it seems I was wrong. Not 
being able to refer to script local functions, IMHO makes function() 
rather pointless, I'd say.


One can work around the problem by using the trick described in :help 
 though.


I also noticed some inconsistency with respect to whether funcrefs can 
only be assigned to variables beginning with an upper-case letter.


Vim doesn't complain about

let g:foo = {'data': 'bar', 'foo': function('s:Foo')}
call g:foo.foo()

but it throws E704 when doing:

let ffoo = function('s:Foo')

From my experience with this, I'd say that this is too restrictive as, 
e.g., call() also accepts a string. So a code like the following is 
basically correct but won't be accepted by vimscript:


fun! Example(arg)
echo a:arg
endf

fun! Caller(fn, args)
let afn = a:fn
return call(afn, a:args)
endf

call Caller(function('Example'), [1])
call Caller('Example', [1])

Regards,
Thomas.

Viminfo & dictionaries

[Thomas]

Hi,

Part two in this week's installment of unsolicited comment on vimscript:

I also realized that viminfo doesn't save upper case letter variables
the values of which are dictionaries. This can be solved by using
VimEnter & VimLeavePre autocommands and by converting the variable to &
from strings. If this is intended to be so, I think this should be noted
in the help -- AFAIK it currently isn't.

Regards,
Thomas.

Syntax error: let a1 = 1 | let b = [1,2,3] | echo b[a1:-1] => Undefined variable a1:

[Thomas]

Hi,

The following code throws a "Undefined variable a1:" error:

let a1 = 1 | let b = [1,2,3] | echo b[a1:-1]

When one puts a blank after a1, it's ok though:

let a1 = 1 | let b = [1,2,3] | echo b[a1 : -1]

Since "a1" is no valid scope and "a1:" is an illegal variable name, IMHO
this code shouldn't be considered ambiguous.

Regards,
Thomas.

Re: feedkeys() allowed in sandbox

[Matthew Winn]

On Sat, 28 Apr 2007 22:43:23 +1000, "John Beckett"
<[EMAIL PROTECTED]> wrote:

> "Potentially unsafe" means we're pretty sure it IS safe, but
> (for example), it's simply not worthwhile allowing a modeline
> longer than 100 bytes because if another vulnerability were
> ever found, we don't want to make it easy for the attacker.

I don't like the idea of preventing modelines over 100 bytes. To start
with, there's no real logic behind it: it's an arbitrary number pulled
out of thin air, and I put it in the same category as saying "it's OK
to use gets() so long as you use a long enough buffer that it'll never
overflow". A modeline that's long enough to allow useful things to be
done is long enough to allow unpleasant things to be done.

Furthermore, what am I supposed to do if I want a long, complicated
but legitimate modeline?

I like Perl's approach to untrustworthy data. It's flagged as tainted
at the point it is read, and anything derived from it is also flagged
as tainted. Tainted information cannot be used in unsafe operations,
ever. From what I've read in this thread Vim does something similar,
but in a way that's less complete. That's the right way to go about
it. Setting an arbitrary limit and hoping it'll have the effect of
improving security is far too optimistic for my tastes.

-- 
Matthew Winn