RE: Moving cursor to start of current word
Tony Mechelynck wrote: > > What's the simplest way to move the cursor to the start of > > the word under it? > > "Under it" includes the word after the cursor if there's no > > identifier under it. > ... > viw`< Won't work if cursor is in the space before the word. Weird actually how all those motion commands like iw work differently from every other vim command that uses a word under the cursor. The vim commands all use the next word if there isn't one under the cursor, which is what I want to do. > yiw Same problem as above. If it wasn't for the space under the cursor I could just use wb which works very well provided the cursor is already on the actual word. Thanks, Rob. -- Robert Webb <[EMAIL PROTECTED]>, MineSweeper3D - Take Minesweeper to a whole new dimension! http://www.software3d.com/Mines3D --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Moving cursor to start of current word
On 24/08/08 06:56, Robert Webb wrote: > Here's what seems like a really stupid question: > > What's the simplest way to move the cursor to the start of the word under > it? > "Under it" includes the word after the cursor if there's no identifier under > it. > > None of these quite work: > > b - The obvious choice, but won't work if the cursor is already on the first > character or before it. > > wb - My usual method. Won't work if the cursor is in the space before the > word though (nor on a single-character word at the end of the file, although > I could live with that). > > eb - Won't work on last character of word. > > *# - OK, I guess this should work, but seems inefficient to do a search. > > I'm trying to avoid a more complicated piece of script for such a simple > operation. > > Thanks, and sorry if it is a stupid question with an obvious answer :-) > Rob. Here are a few other possibilities, which may or may not be inefficient too, depending on what you want to do after you're on that first letter: viw`< viw = character-wise visual inner word = go back to Normal mode `< = go to start of former Visual area yiw yank inner word (but clobbers the default register) "_yiw yank inner word to blackhole register. This moves the cursor and does not actually yank. It may also depend what you want to do: if you want to yank the word under the cursor you'll use yiw (possibly with some register other than the black hole) Best regards, Tony. -- What this country needs is a dime that will buy a good five-cent bagel. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: :args reorders arguments
Bjorn Winckler wrote:
> 2008/8/22 Gary Johnson <[EMAIL PROTECTED]>:
> >
> > On 2008-08-22, bjrn <[EMAIL PROTECTED]> wrote:
> >>
> >> This may not be the right place for this post, but it seems like I've
> >> come across a bug so I am posting here.
> >>
> >> If I type
> >>
> >> :args file1.m file1.h file2.m
> >>
> >> then I expect the arglist to have the file appear in the order I
> >> specified, but instead the arglist is in this order:
> >>
> >> file1.m file2.m file1.h
> >>
> >> For some reason the arglist groups files with the same extension
> >> together and thus completely breaks the order I so carefully specified
> >> to :args.
> >>
> >> Is this a "feature" or a bug? It feels like I must have overlooked
> >> something, but what?
> >
> > I don't have the complete answer, but it appears to be a "feature".
> > ":help {arglist}" says, in part,
> >
> > The wildcards in the argument list are expanded and the file
> > names are sorted.
> >
> > Nowhere, however, can I find where "sorted" is defined.
>
> Thanks for that clue. It still kind of confused me since I was
> actually passing the files in a (lexicographically) sorted order so
> why Vim would "re-sort" an already sorted list seemed weird. It turns
> out that the 'suffixes' option is the cause of this; if I "set su="
> then my sorted list of files will not get rearranged.
>
> Still, this behaviour of :args is very counterintuitive: if I start
> Vim with "gvim file1.m file1.h file2.m" then the arglist will be the
> order I specified, whereas if I start Vim, then type ":args file1.m
> file1.h file2.m" the arglist will be in a different order (unless I
> ":set su=" first).
>
> So this still makes me wonder if there isn't a way force :args _not_
> to rearrange the filenames you pass to it? What is the rationale
> behind making :args perform this kind of "sorting"?
":args" works like giving the arguments on the Vim command line, where
the shell does the wildcard expansion. Then Vim handles 'suffixes' to
move less important files to the end. But the list isn't sorted, only
the matches from expanded arguments are sorted.
It has always been this way and changing it may go against the
expectations of long time users.
--
An alien life briefly visits earth. Just before departing it leaves a
message in the dust on the back of a white van. The world is shocked
and wants to know what it means. After months of studies the worlds
best linguistic scientists are able to decipher the message: "Wash me!".
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Moving cursor to start of current word
Here's what seems like a really stupid question: What's the simplest way to move the cursor to the start of the word under it? "Under it" includes the word after the cursor if there's no identifier under it. None of these quite work: b - The obvious choice, but won't work if the cursor is already on the first character or before it. wb - My usual method. Won't work if the cursor is in the space before the word though (nor on a single-character word at the end of the file, although I could live with that). eb - Won't work on last character of word. *# - OK, I guess this should work, but seems inefficient to do a search. I'm trying to avoid a more complicated piece of script for such a simple operation. Thanks, and sorry if it is a stupid question with an obvious answer :-) Rob. -- Robert Webb <[EMAIL PROTECTED]>, Want to make polyhedra? http://www.software3d.com/Stella.php --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: out of memory bug on win32 platforms
2008/8/23 Jelle Geerts <[EMAIL PROTECTED]>: > Hello, > > When allocating memory, lalloc() is called, which uses mch_avail_mem(). But > mch_avail_mem() sometimes fails. It returns the available physical memory + > available page file memory, which can sometimes wrap around 32-bits. > > Also, mch_avail_mem() uses GlobalMemoryStatus() which isn't working properly > on > computers with more than 4 GiB of memory installed. There is an extension > available on NT platforms 0x0500, called GlobalMemoryStatusEx(). As opposed to > GlobalMemoryStatus(), the extension works reliably with systems that have more > than 4 GiB of memory installed. > > Please see the attachment for the diff file for my patch. If the comments I > have added are too wordy or someone does not like them, just remove them ;) > > Thanks, > Jelle Geerts It looks to me like your patch will fail if ms.dwAvailPhys is more than 4GiB, due to underflow of (0xff00 - ms.dwAvailPhys). This is a DWORDLONG, which is always an unsigned 64-bit int. Also, shouldn't that be msex.ullAvailPhys, not ms.dwAvailPhys in the (_WIN32_WINNT >= 0x0500) && !defined(_WIN64) case? Better, I think, to return (long_u) min(0xFF00, msex.ullAvailPhys + msex.ullAvailPageFile). Or for Bram to widen this signature to a 64-bit int for all platforms. Linux and Mac boxes with >4GiB are going to be common soon. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog http://blogs.cozi.com/tech --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A small patch for gui_mac.c to let ATSUI support NON-antialias.
Hi, On Sun, Aug 24, 2008 at 12:24 AM, LC Mi <[EMAIL PROTECTED]> wrote: > New to submitting a patch. Please let me know how to submit if folks agree > with this patch. :-) Thanks! As the last one touching the Carbon vim GUI code, I'd say this patch looks fine for me. However you may want to check out [EMAIL PROTECTED] since most Mac vim users have move on to use Cocoa based vim GUI. Just in case you haven't noticed that. - Jiang --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug with v_K and potentially K command
Hi, After applying this patch to Vim 7.2, I got following errors while trying to use K command (and shell also freezes after getting the errors). I tried to reproduce them with a stable scenario, but couldn't find a reasonable one. And also, K command sometimes works as expected, too. I don't know if they're Vim-related or am I missing something, though. I'd be happy if you can give me one or two clues. No manual entry for xml version="1.0" ?> shell returned 16 Press ENTER or type command to continueVim: Caught deadly signal SEGV and another one: No manual entry for appName = "Kaptan Wallpaper" shell returned 16 Press ENTER or type command to continueVim: Caught deadly signal ABRT Vim: preserving files... Cheers, -- Pınar Yanardağ (a.k.a PINguAR) http://pinguar.org _ I am rarely happier than when spending entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand. Douglas Adams On Aug 23, 9:26 am, "Jan Minář" <[EMAIL PROTECTED]> wrote: > > was not checked, so I fixed that as well. The updated patch (version > > 2) is attached. > > It is now. > > Cheers, > Jan. > > K-arbitrary-command-execution.patch.v2 > 5KViewDownload --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to match a Chinese character in VIM?
On 24/08/08 01:58, .幻想之诚 wrote: > Is that a bug, Tony? I think so; but I suppose Bram would know better than I what causes it. A little trial and error seems to indicate that if the lower and upper bounds differ by 256 or less (i.e. if there are at most 257 values in range) the search proceeds OK, but if they differ by more than that we get E16: Invalid range. For instance: /[一-伀] (4E00 to 4F00) OK /[一-企] (4E00 to 4F01) error /[丐-伐] (4E10 to 4F10) OK /[丐-休] (4E10 to 4F11) error I'm (trying to) redirect this thread to the vim_dev list. Best regards, Tony. > > On Sun, Aug 24, 2008 at 12:06 AM, Tony Mechelynck< > [EMAIL PROTECTED]> wrote: > >> On 23/08/08 11:24, Anton Sharonov wrote: >>> I can reproduce this as well (vim 7.2 patches 1-2, Linux OpenSUSE >>> 10.2, big version with gtk2, +multi_byte +multi_lang, >>> fenc=enc=utf8), neither of both patterns works: >>> >>>/[\u4e00-\u9fa5] >>>/[不-限] >>> >>> But what is interesting, for characters which are belongs to >>> russian unicode area it seems to be ok, so following is working >>> properly: >>> >>>/[\u0430-\u044f] >>>/[а-я] >>> >>> Normal search for Chinese characters, single or in group, seems >>> as well to be ok, so following working properly as well: >>> >>>/不 >>>/限 >>>/不局限 >>> >>> >>> Sample text: >>> >> >>> русский текст >>> вим - это класс >>> 算法并不局限于计算机和网络 >>> >> >>> Anton. >> I confirm the above, but what puzzles me even more is that with a >> smaller range, such as >> >> /[一-丅] >> >> i.e. U+4E00 to U+4E05, the search works correctly, with no error. >> >> >> Best regards, >> Tony. >> -- >> The basic idea behind malls is that they are more convenient than >> cities. Cities contain streets, which are dangerous and crowded and >> difficult to park in. Malls, on the other hand, have parking lots, >> which are also dangerous and crowded and difficult to park in, but -- >> here is the big difference -- in mall parking lots, THERE ARE NO >> RULES. You're allowed to do anything. You can drive as fast as you >> want in any direction you want. I was once driving in a mall parking >> lot when my car was struck by a pickup truck being driven backward by a >> squat man with a tattoo that said "Charlie" on his forearm, who got out >> and explained to me, in great detail, why the accident was my fault, >> his reasoning being that he was violent and muscular, whereas I was >> neither. This kind of reasoning is legally valid in mall parking >> lots. >> -- Dave Barry, "Christmas Shopping: A Survivor's Guide" >> > > > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
A small patch for gui_mac.c to let ATSUI support NON-antialias.
New to submitting a patch. Please let me know how to submit if folks agree
with this patch. :-) Thanks!
Attach the diff:
Index: src/gui_mac.c
===
--- src/gui_mac.c (revision 1164)
+++ src/gui_mac.c (working copy)
@@ -173,6 +173,7 @@
ATSUStyle gWideFontStyle;
# endif
BooleangIsFontFallbackSet;
+UInt32 useAntialias_cache = 0x0;
#endif
/* Colors Macros */
@@ -4123,6 +4124,24 @@
ATSUSetAttributes(gFontStyle, 1, attribTags, attribSizes, attribValues);
}
+UInt32 useAntialias = p_antialias ? kATSStyleApplyAntiAliasing
+ : kATSStyleNoAntiAliasing;
+if (useAntialias != useAntialias_cache)
+{
+
+ATSUAttributeTag attribTags[] = { kATSUStyleRenderingOptionsTag
};
+ByteCount attribSizes[] = { sizeof(UInt32) };
+ATSUAttributeValuePtr attribValues[] = { &useAntialias };
+
+if (gFontStyle)
+ATSUSetAttributes(gFontStyle, 1, attribTags, attribSizes,
attribValues);
+
+if (gWideFontStyle)
+ATSUSetAttributes(gWideFontStyle, 1, attribTags,
attribSizes, attribValues);
+
+useAntialias_cache = useAntialias;
+}
+
#ifdef FEAT_MBYTE
if (has_mbyte)
{
--
cicicici
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
On 23/08/08 18:09, Markus Heidelberg wrote: > sc, 23.08.2008: >>> In view of that, I wonder if the enthusiastic users of this plugin have ever >>> tested my patch, which is a lot more usable at this time. >> a lot more useable than what? > > than the plugin > >> you are asking me to patch no >> fewer than 22 modules: >> [...] >> >> rebuild and re-install the app, as opposed to installing a >> plugin that's been vimballed? > > Well, you are on the vim developers list. I don't force you to do it, but I > think if you like the feature, you should probably try it once for comparison > with the plugin. > >> so, no, i haven't tried your patch, sorry, call me lazy > > That's the problem with an external patch. It will never get the same > attention as if it was included in mainline. And you can't simply install a > new Vim version without worrying about the patch in contrast to a plugin. > > The point is that if you find it useful, you would probably like to have it in > mainline without the problems of the plugin. > > Markus Unlike sc, I could easily install it if I wanted -- running the "patch" program is no problem, and while Vim gets compiled in one terminal I can do something else -- even use Vim, an earlier build of course -- in other X-windows and/or virtual consoles. It's just that I don't feel like I'm going to use it (or Dr.Chip's relative-numbering plugin); and I daresay that the risk of a patch which affects so many different sources might get bit-rotten in the future (in contrast with Bill McCarthy's float functions patch, which affects only one source module) is also deterring me somewhat. OTOH, I would have nothing against both above-mentioned patches being incorporated into the mainline sources, Bill's patch as part of the +float feature, and your relative-numbers patch either as standard or as another optional feature (I suppose the latter would imply bracketing all its changes in #ifdef directives but it might be the better choice). But of course Bram has the final say on this matter. Best regards, Tony. -- Syntactic sugar causes cancer of the semicolon. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Markus Heidelberg wrote: > Charles E. Campbell, Jr., 19.08.2008: > >> Tony Mechelynck wrote: >> >>> On 18/08/08 22:15, Charles Campbell wrote: >>> >>> I've issued a new plugin on my website: http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses the signs capability of "huge" vim to give relative numbering. After some comment period I expect to release it on vim.sf.net. I'd like to mention the relative numbering patch in my document -- would someone please tell me where that patch is again? >>> It's been sent to the vim_dev and vim_use lists as an attachment to a >>> mail titled "Re: 'relativenumber' patch updated for Vim 7.2", by Markus >>> Heidelberg, dated 2008-08-11 23:27:07 +0200. (Beware: The same thread >>> has an earlier 7.2 version of the same patch.) >>> >>> >> Thank you, Tony -- I found the post & attachment, and I now have a link >> to it in my document. >> > > The link refers to the earlier version as Tony mentioned. This one is newer: > http://groups.google.com/group/vim_dev/attach/10fa0944a8b643b4/vim-7.2-relativenumber-02.patch?part=2 > > It seems as if the interest in this feature is not as small as supposed by > Bram. Well, it's an exotic feature, and maybe its strangeness is it's destiny. > > However, there are several drawbacks to your plugin, where the numbers aren't > shown correctly. These are just the major issues: > - folding isn't handled (I wonder what the bugfix log "Aug 18, 2008 * Fixed > some bugs associated with folding" is all about) > - scrolling without cursor movement (zz Ctrl-E ...) > And last but not least the performance problem. > > In view of that, I wonder if the enthusiastic users of this plugin have ever > tested my patch, which is a lot more usable at this time. > Hello! The folding issue that was addressed: text1 fold text2 fold and with the cursor somewhere in the text2 block, the relative numbering was missing for text1. Relative numbering shows now, so long as its within +-99 lines. There are a number of things that I'd mention as drawbacks to my plugin: * it uses signs, and only about 200 signs are available (hence that +-99 constraint) (and, of course, that means that they're not available for something else) * in addition to scrolling w/o cursor movement (ctrl-y, also), there's redraw which doesn't re-do the signs. Should be a RedrawEvent or something. * signs are attached to buffers. Hence multiple windows on the same buffer only shows one set of relative numbers; try :RN with multiple windows on a buffer showing different parts of the buffer and you'll see what I mean. I'll update the link to your patch (when I get a chance -- I'm still updating vim on this machine+o/s). I hope you don't consider my plugin a competitor, I thought of it as more of a step towards your patch (whet folks' appetites, as it were) -- and maybe even as justification for your patch given enough interest. Anyway, that's why I included the link to your patch. Regards, and thanks for the patch! Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
sc, 23.08.2008: > > > In view of that, I wonder if the enthusiastic users of this plugin have ever > > tested my patch, which is a lot more usable at this time. > > a lot more useable than what? than the plugin > you are asking me to patch no > fewer than 22 modules: > [...] > > rebuild and re-install the app, as opposed to installing a > plugin that's been vimballed? Well, you are on the vim developers list. I don't force you to do it, but I think if you like the feature, you should probably try it once for comparison with the plugin. > so, no, i haven't tried your patch, sorry, call me lazy That's the problem with an external patch. It will never get the same attention as if it was included in mainline. And you can't simply install a new Vim version without worrying about the patch in contrast to a plugin. The point is that if you find it useful, you would probably like to have it in mainline without the problems of the plugin. Markus --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
ft_sql.txt not mentioned in help.txt
Moin, I wounder why noone noticed before: ft_sql.txt is not mentioned in help.txt. Already reported to Bram. BTW: I noticed this, while I updated vimhelp-de to the 72 release. As usual available from http://www.florianrehnisch.de/vimhelp/. Now in ZIP format as well. Thanks, flori --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
On Saturday 23 August 2008 07:24, Markus Heidelberg wrote: > > Charles E. Campbell, Jr., 19.08.2008: > > > > Tony Mechelynck wrote: > > > On 18/08/08 22:15, Charles Campbell wrote: > > > > > >> I've issued a new plugin on my website: > > >> http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses > > >> the signs capability of "huge" vim to give relative numbering. After > > >> some comment period I expect to release it on vim.sf.net. I'd like to > > >> mention the relative numbering patch in my document -- would someone > > >> please tell me where that patch is again? > > > > > > It's been sent to the vim_dev and vim_use lists as an attachment to a > > > mail titled "Re: 'relativenumber' patch updated for Vim 7.2", by Markus > > > Heidelberg, dated 2008-08-11 23:27:07 +0200. (Beware: The same thread > > > has an earlier 7.2 version of the same patch.) > > > > > Thank you, Tony -- I found the post & attachment, and I now have a link > > to it in my document. > > The link refers to the earlier version as Tony mentioned. This one is newer: > http://groups.google.com/group/vim_dev/attach/10fa0944a8b643b4/vim-7.2-relativenumber-02.patch?part=2 > > It seems as if the interest in this feature is not as small as supposed by > Bram. Well, it's an exotic feature, and maybe its strangeness is it's destiny. > > However, there are several drawbacks to your plugin, where the numbers aren't > shown correctly. These are just the major issues: > - folding isn't handled (I wonder what the bugfix log "Aug 18, 2008 * Fixed > some bugs associated with folding" is all about) > - scrolling without cursor movement (zz Ctrl-E ...) > And last but not least the performance problem. > > In view of that, I wonder if the enthusiastic users of this plugin have ever > tested my patch, which is a lot more usable at this time. > > Markus a lot more useable than what? you are asking me to patch no fewer than 22 modules: [Sat Aug 23 10:17] ~/temp> grep '^Index' vim-7.2-relativenumber-02.patch | nl 1 Index: runtime/doc/quickref.txt 2 Index: runtime/doc/version7.txt 3 Index: runtime/doc/options.txt 4 Index: runtime/doc/syntax.txt 5 Index: runtime/doc/tags 6 Index: runtime/lang/menu_de_de.latin1.vim 7 Index: runtime/syntax/vim.vim 8 Index: runtime/menu.vim 9 Index: runtime/optwin.vim 10 Index: src/proto/misc2.pro 11 Index: src/edit.c 12 Index: src/ex_cmds.c 13 Index: src/gui.c 14 Index: src/misc1.c 15 Index: src/misc2.c 16 Index: src/move.c 17 Index: src/netbeans.c 18 Index: src/normal.c 19 Index: src/option.c 20 Index: src/option.h 21 Index: src/screen.c 22 Index: src/structs.h rebuild and re-install the app, as opposed to installing a plugin that's been vimballed? so, no, i haven't tried your patch, sorry, call me lazy sc --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
Charles E. Campbell, Jr., 19.08.2008: > > Tony Mechelynck wrote: > > On 18/08/08 22:15, Charles Campbell wrote: > > > >> I've issued a new plugin on my website: > >> http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses > >> the signs capability of "huge" vim to give relative numbering. After > >> some comment period I expect to release it on vim.sf.net. I'd like to > >> mention the relative numbering patch in my document -- would someone > >> please tell me where that patch is again? > > > > It's been sent to the vim_dev and vim_use lists as an attachment to a > > mail titled "Re: 'relativenumber' patch updated for Vim 7.2", by Markus > > Heidelberg, dated 2008-08-11 23:27:07 +0200. (Beware: The same thread > > has an earlier 7.2 version of the same patch.) > > > Thank you, Tony -- I found the post & attachment, and I now have a link > to it in my document. The link refers to the earlier version as Tony mentioned. This one is newer: http://groups.google.com/group/vim_dev/attach/10fa0944a8b643b4/vim-7.2-relativenumber-02.patch?part=2 It seems as if the interest in this feature is not as small as supposed by Bram. Well, it's an exotic feature, and maybe its strangeness is it's destiny. However, there are several drawbacks to your plugin, where the numbers aren't shown correctly. These are just the major issues: - folding isn't handled (I wonder what the bugfix log "Aug 18, 2008 * Fixed some bugs associated with folding" is all about) - scrolling without cursor movement (zz Ctrl-E ...) And last but not least the performance problem. In view of that, I wonder if the enthusiastic users of this plugin have ever tested my patch, which is a lot more usable at this time. Markus --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug with v_K and potentially K command
On Sat, Aug 23, 2008 at 8:59 AM, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
>
> John Becket wrote:
>
>> Tony Mechelynck wrote:
>> > Maybe you should set a config-time option (or create one) to
>> > avoid any interaction with the shell?
>> >
>> > Even better: If you don't want ever to become the victim of
>> > any exploit, turn your computer off at the wall switch and
>> > leave it off.
>> >
>> > :-b
>>
>> I haven't studied this example, but as I understand it, the suggestion is
>> that I
>> could send you a file with a message like "What's the deal with this weird
>> message
>> that Vim gives? Open file xxx and search for yyy then press K."
>>
>> Jan is saying (I think) that following those instructions could execute
>> malware.
>>
>> Sure, it will never happen to me or you, but if we were discussing Microsoft
>> Word,
>> most people would have no hesitation in declaring that such a vulnerability
>> (press a
>> key in a document to get owned) is just NOT acceptable.
>>
>> We aren't talking about mapping K to execute "system('dodgyfile')". K is
>> performing
>> its default function, but that function could exploit you if executed on
>> certain
>> text, with a certain file present.
>>
>> If my understanding is correct, I don't think it's reasonable to write this
>> off with
>> the "switch power off" joke (if I've got this wrong, please correct me).
>
> It's more like the "execute this attachment to see a movie of xyz nude". Or
> the signature virus:
Please! It's an editor. What kind of vulnerabilities would you
expect? You have to open a file, have a reasonable feature set
enabled, and do something. The real question is, why does the impact
always have to be arbitrary Ex/shell commands execution? And why are
there so many?
But it's a feature really: We all know it can take a long time for a
package maintainer to include a patch. Or perhaps, said package
maintainer thinks our patch sucks. Pperhaps he's even right! Not to
worry. With all these vulnerabilities, as long as they're is using
Vim, we can have all our patches included _as soon as they view them_.
We can even have the packages built and uploaded at the same time!
Cheers,
Jan.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Bug in clipboard handling on X11
On Fri, Aug 22, 2008 at 3:32 AM, Matt Wozniski wrote:
> Not sure what's going on here, but I've found a crash that's easy to
> reproduce. First, open two X11 enabled vim (not gvim) processes. In
> the first, do:
> :let @+ = repeat('a', 1024*1024)
> in order to store 1MB of data to the clipboard. The exact amount is
> irrelevant, but the larger the size, the more often it will lead to a
> segfault.
>
> Then, in the second vim instance, repeatedly do ":reg +" and see what
> gets displayed. Depending upon the amount of data that you put on the
> clipboard, as well as upon some other factor I'm not seeing, this will
> either a) show a bunch of a's in register +, b) not show any
> registers, as though register + didn't exist, or c) cause the vim in
> which you copied to segfault, and the vim in which you're trying to
> display the register to enter a tight loop wasting a lot of CPU and
> only dying for kill -9. Just try the command 5 or so times and you
> should see a segfault - as well as the missing-register behavior. If
> you don't get the segfault at all, try upping the amount of data
> stored to the clipboard. If you get the segfault, but not the
> missing-register behavior, try lowering the amount of data stored to
> the clipboard. And if you can't reproduce either, that might help to
> pin down what exactly causes this.
>
> I can reproduce this on both a vim linked with the GTK2-Gnome gui, and
> one linked with the X11-Motif gui, so it doesn't seem to be something
> gnome-specific, either. This is vim 7.2.
>
> Let me know if we need more details.
>
> ~Matt
It does not seem easy to debug. I think there might
be 2 distinct issues.
1/ The first thing I notice and which seems to be 100% reproducible
on my machine):
In #1 instance of vim: :let @+ = repeat('a', 262033)
In #2 instance of vim::reg+(works fine all the time)
In #1 instance of vim: :let @+ = repeat('b', 262034)
In #2 instance of vim::reg+(fails all the time, it shows empty content)
clip_x11_request_selection_cb() fails in #2 instance of vim
because parameter value is NULL and parameter *length is null.
Somehow it happens when number of characters in clipboard
is >= 262034 (close to 256K).
I change the letter ('a' -> 'b') in the clipboard every time to make
sure ":reg +" does not show an old value of the clipboard (which
I have observed sometimes, see below)
2/ The second thing I notice, if I put far more characters in the
clipboard (say 100) then if fails differently:
In #1 instance of vim: :let @+ = repeat('c', 1000*1000)
In #2 instance of vim::reg+(fails, it shows some incorrect
content, something which I happened copy earlier "3"?!)
So with such a big clipboard content, it fails differently:
In instance #2 of vim, function clip_x11_request_selection()
retries 5 times until it falls back to calling clip_yank_selection(),
but somehow that does not work either.
If both instances are gvim rather than vim, then I do not see
any problem.
I have not been able to come up with a fix yet.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
RE: Bug with v_K and potentially K command
John Becket wrote:
> Tony Mechelynck wrote:
> > Maybe you should set a config-time option (or create one) to
> > avoid any interaction with the shell?
> >
> > Even better: If you don't want ever to become the victim of
> > any exploit, turn your computer off at the wall switch and
> > leave it off.
> >
> > :-b
>
> I haven't studied this example, but as I understand it, the suggestion is
> that I
> could send you a file with a message like "What's the deal with this weird
> message
> that Vim gives? Open file xxx and search for yyy then press K."
>
> Jan is saying (I think) that following those instructions could execute
> malware.
>
> Sure, it will never happen to me or you, but if we were discussing Microsoft
> Word,
> most people would have no hesitation in declaring that such a vulnerability
> (press a
> key in a document to get owned) is just NOT acceptable.
>
> We aren't talking about mapping K to execute "system('dodgyfile')". K is
> performing
> its default function, but that function could exploit you if executed on
> certain
> text, with a certain file present.
>
> If my understanding is correct, I don't think it's reasonable to write this
> off with
> the "switch power off" joke (if I've got this wrong, please correct me).
It's more like the "execute this attachment to see a movie of xyz nude". Or
the signature virus:
Hi! I'm a signature virus. Please add me to your signature and help me
spread!
Or this one:
This is the polymorph virus! Follow these instructions carefully:
1. Send this message to everybody you know.
2. Format your harddisk.
Thank you for your cooperation in spreading the most powerful virus ever!
The problem with K might have less success...
There even is a wikipedia article on it:
http://en.wikipedia.org/wiki/Honor_system_virus
--
The fastest way to get an engineer to solve a problem is to declare that the
problem is unsolvable. No engineer can walk away from an unsolvable problem
until it's solved.
(Scott Adams - The Dilbert principle)
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
