Re: vim 7.1?
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. I first thought to fix them all before making a 7.1, but since the list only appears to get longer I might drop that idea. -- How To Keep A Healthy Level Of Insanity: 9. As often as possible, skip rather than walk. /// 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 wrote: That's pretty nasty. I'll make a patch right away. Thanks. However, perhaps the modeline concept needs more safety - defence in depth. Perhaps modelines should only allow a VERY limited set of operations by default (even more restricted than now). Googling for 'vim feedkeys joke' shows April 1 joke with the following (I've replaced vim with vvv): vvv: foldmethod=expr:foldexpr=feedkeys( \\esc\\x3a%!cat\\x20-n\\CR\\esc\\x3a%s/./\:)/g\\CR \\esc\\x3aq!\\CR): I'm too lazy to unobfuscate this, but one glance tells you that modelines should not be fixed - going down that path is likely to give a new vulnerability every year. Instead, modelines should be SEVERELY limited by default. Examples: Total length 100 bytes. No expressions; no function calls; no execution. Treat a double-quoted string as if in single quotes. Is folding really needed in a default modeline? John
Re: feedkeys() allowed in sandbox
Tomas Golembiovsky wrote: today somebody came to #vim, and pasted some modeline (containig joke or such). Thanks for raising that issue. I found the April 1 joke with Google. I actually noticed that posting (seeing Vim while browsing a security list caught my attention), but there's so much waffle out there that I didn't pay any attention to the point of the message. John
Re: feedkeys() allowed in sandbox
Bram Moolenaar wrote: Perhaps modelines should only allow a VERY limited set of operations by default (even more restricted than now). Sure, simply use :set nomodeline. I'm suggesting defence in depth. My vimrc might have ':set nomodeline', but what if I make a mistake? What if I'm using some other machine where I'm not sure what's in vimrc? What if I use the -u option? And there are probably other scenarios where a simple oversight could cause me to execute a modeline in an untrusted file. What if I want modelines (but never to do more than set a few options like tabs). Even setting 'textwidth' to 2 may already be considered harmful, or at least annoying. I don't mind being occasionally irritated with a stupid modeline. But I really don't want an editor to execute code when I open a file. Change volatile settings - no problem. Execute - no thanks. Perhaps we can add yet-another-option to completely disable setting some options from the modeline. Modelines should default to be safe (safe by design, AND safe because of defence in depth). If another option were added, it should be to allow expressions or other features that are potentially unsafe (not disallow unsafe features). 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. It's better to make sure the sandbox works as it should. Of course, but bitter experience shows that defence in depth is the best strategy. Vim has a lot of very clever features that are too complex to ever be secure, when executing a modeline from an untrusted source. John
Re: [PATCH] new ex command :lscscope
Hello,
--- Yegappan Lakshmanan [EMAIL PROTECTED] wrote:
Hi Gary,
On 4/27/07, Gary Johnson [EMAIL PROTECTED] wrote:
On 2007-04-27, Gary Johnson [EMAIL PROTECTED] wrote:
On 2007-04-26, 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. 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 Index: runtime/doc/if_cscop.txt
===
--- runtime/doc/if_cscop.txt (revision 252)
+++ runtime/doc/if_cscop.txt (working copy)
@@ -213,6 +213,11 @@
'cscopequickfix' option is set, the location list for the current window is
used instead of the quickfix list to show the cscope results.
+ *:lscscope* *:lsc*
+This command is same as the :scscope command, except when the
+'cscopequickfix' option is set, the location list for the current window is
+used instead of the quickfix list to show the cscope results.
+
*:cstag* *E257* *E562*
If you use cscope as well as ctags, |:cstag| allows you to search one or
the other before making a jump. For example, you can choose to first
Index: runtime/doc/index.txt
===
--- runtime/doc/index.txt (revision 252)
+++ runtime/doc/index.txt (working copy)
@@ -1276,6 +1276,7 @@
|:lpfile| :lpf[ile] go to last location in previous file
|:lrewind| :lr[ewind] go to the specified location, default first one
|:ls| :ls list all buffers
+|:lscscope| :lsc[scope] like :scscope but uses location list
|:ltag| :lt[ag] jump to tag and add matching tags to the
location list
|:lunmap| :lu[nmap] like :unmap! but includes Lang-Arg mode
Index: src/ex_cmds.h
===
--- src/ex_cmds.h (revision 252)
+++ src/ex_cmds.h (working copy)
@@ -581,6 +581,8 @@
RANGE|NOTADR|COUNT|TRLBAR),
EX(CMD_ls, ls, buflist_list,
BANG|TRLBAR|CMDWIN),
+EX(CMD_lscscope, lscscope, do_scscope,
+ EXTRA|NOTRLCOM|SBOXOK),
EX(CMD_move, move, ex_copymove,
RANGE|WHOLEFOLD|EXTRA|TRLBAR|CMDWIN|MODIFY),
EX(CMD_mark, mark, ex_mark,
Index: src/if_cscope.c
===
--- src/if_cscope.c (revision 252)
+++ src/if_cscope.c (working copy)
@@ -973,7 +973,7 @@
}
return cs_find_common(opt, pat, eap-forceit, TRUE,
- eap-cmdidx == CMD_lcscope);
+ eap-cmdidx == CMD_lcscope || eap-cmdidx == CMD_lscscope);
} /* cs_find */
@@ -1115,23 +1115,23 @@
{
cs_file_results(f, nummatches);
fclose(f);
+# ifdef FEAT_WINDOWS
+ if (postponed_split != 0)
+ {
+ win_split(postponed_split 0 ? postponed_split : 0,
+ postponed_split_flags);
+# ifdef FEAT_SCROLLBIND
+ curwin-w_p_scb = FALSE;
+# endif
+ postponed_split = 0;
+ }
+# endif
if (use_ll) /* Use location list */
wp =
accessing vim's clipboard from java
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
