Re: manpageview rating dive
On 01-Sep-2011 17:24, Tony Mechelynck wrote: On 31/08/11 17:49, Charles Campbell wrote: Charles Campbell wrote: Hello! I recently checked my plugins' ratings: 08/09/11 script 677/279/10776: Manpageview.vim 08/31/11 script -133/1094/10866: Manpageview.vim This seems like an odd thing -- is this preparation for a general bombing of plugins' ratings? I should explain this a bit more. The rating for Manpageview on August 9, 2011 was 677, with 279 people having rated it, and 10776 having downloaded it. On August 31, 2011, the rating was -133, 1094 people having rated it, and 10866 having downloaded it. It is odd that Manpageview received -810 in karma when there were only 90 additional downloaders over that time period. Did irc have a anti-Chip attack? Is someone testing a bot to destroy multiple plugins' ratings? Chip I wonder how SourceForge allocates memory for these numbers. It sounds like overflow into the sign bit, except that the next bit above 677 is 1024 (2^10) which is not at a byte or word boundary... Only 90 new downloads but as many as 815 new ratings is also a bit weird to say the least. And almost all of those negative? Some troll must hate Manpageview (and/or you) quite a bit to have gone to the trouble of logging in 810 times to give a negative rating. I have seen a similar drastic downvote for the SmartCase plugin, http://www.vim.org/scripts/script.php?script_id=1359; its rating is -326/355, Downloaded by 488, even though it works perfectly well for me. My best guess is that some bot did this; either by accident or through human evil. In these times, voting probably needs to be protected by captcha, but that would just make the feature even less attractive. As long as these are rare incidents, stick with the current system, and only move to e.g. an invitation to comment on this script on the linked Vim Tips Wiki page if it gets worse. -- regards, ingo -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Lisp/Scheme paren matching
This seems to have petered out without a resolution. I believe I made a valid point below that the documentation and the behavior of matchparen are not in agreement. I would appreciate either acknowledgement that it's a bug and that it's been entered into the official bug db for future repair, or for someone to explain to me why I'm wrong, if you believe that's the case. User-contributed patches are highly appreciated here. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Lisp/Scheme paren matching
On Thu, Sep 1, 2011 at 1:53 PM, Sergey Khorev sergey.kho...@gmail.com wrote: This seems to have petered out without a resolution. I believe I made a valid point below that the documentation and the behavior of matchparen are not in agreement. I would appreciate either acknowledgement that it's a bug and that it's been entered into the official bug db for future repair, or for someone to explain to me why I'm wrong, if you believe that's the case. User-contributed patches are highly appreciated here. I'm happy to help if I can, but I don't want to waste my time trying to fix a non-existent bug, so I would like the question I raised in the above message answered: do you or do you not believe matchparen flashing parens inside strings is a bug? If so, when I have time, I'll try to fix it. It should also get recorded in the bug database, so it doesn't get forgotten. /Don -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: manpageview rating dive
On Wed, 31 Aug 2011, Charles Campbell wrote: Charles Campbell wrote: Hello! I recently checked my plugins' ratings: 08/09/11 script 677/279/10776: Manpageview.vim 08/31/11 script -133/1094/10866: Manpageview.vim This seems like an odd thing -- is this preparation for a general bombing of plugins' ratings? I should explain this a bit more. The rating for Manpageview on August 9, 2011 was 677, with 279 people having rated it, and 10776 having downloaded it. On August 31, 2011, the rating was -133, 1094 people having rated it, and 10866 having downloaded it. It is odd that Manpageview received -810 in karma when there were only 90 additional downloaders over that time period. Did irc have a anti-Chip attack? Is someone testing a bot to destroy multiple plugins' ratings? Can't find it currently, but someone mentioned in the not-so-distant past that some search engine(s) grabbed the down-vote URL when crawling www.vim.org. In this case, googling: site:www.vim.org inurl:unfulfilling (where 'unfulfilling' is the 'rating' value for a down-vote) comes up with exactly one result for me: ManPageView - Viewer for manpages, gnu info, perldoc, and php … With the link: (...'s to prevent clicking) http://.../scripts/script.php?script_id=489rating=unfulfilling And I may have accidentally just downvoted it myself, by hovering over the result (which pops up a preview). Seems like the ratings should only use $_POST (PHP var), but they appear to be using $_GET, too. -- Best, Ben -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: manpageview rating dive
Benjamin R. Haskell wrote: On Wed, 31 Aug 2011, Charles Campbell wrote: Charles Campbell wrote: Hello! I recently checked my plugins' ratings: 08/09/11 script 677/279/10776: Manpageview.vim 08/31/11 script -133/1094/10866: Manpageview.vim This seems like an odd thing -- is this preparation for a general bombing of plugins' ratings? I should explain this a bit more. The rating for Manpageview on August 9, 2011 was 677, with 279 people having rated it, and 10776 having downloaded it. On August 31, 2011, the rating was -133, 1094 people having rated it, and 10866 having downloaded it. It is odd that Manpageview received -810 in karma when there were only 90 additional downloaders over that time period. Did irc have a anti-Chip attack? Is someone testing a bot to destroy multiple plugins' ratings? Can't find it currently, but someone mentioned in the not-so-distant past that some search engine(s) grabbed the down-vote URL when crawling www.vim.org. In this case, googling: site:www.vim.org inurl:unfulfilling (where 'unfulfilling' is the 'rating' value for a down-vote) comes up with exactly one result for me: ManPageView - Viewer for manpages, gnu info, perldoc, and php … With the link: (...'s to prevent clicking) http://.../scripts/script.php?script_id=489rating=unfulfilling And I may have accidentally just downvoted it myself, by hovering over the result (which pops up a preview). Seems like the ratings should only use $_POST (PHP var), but they appear to be using $_GET, too. Nice bit of sleuthing! So perhaps the large downvoting is due to bots such as google, yahoo, bing, etc., and I suppose Manpageview can expect a continuing more-of-the-same. Bram: any chance that this situation can be fixed? Regards, Chip -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
[patch] Crash with EOL visual-block over a fold
Bram,
If one uses C-v$ to start visual-block mode, and then moves the cursor
over a fold, Vim will crash. As a simple test, you can follow the
commands below with this email.
:set fdm=marker
zM
C-v$jG
{{{
screen.c:
2534if (wp-w_old_cursor_lcol + txtcol (colnr_T)W_WIDTH(wp))¶
2535len = wp-w_old_cursor_lcol;¶
2536else¶
2537len = W_WIDTH(wp) - txtcol;¶
2538RL_MEMSET(wp-w_old_cursor_fcol + txtcol, hl_attr(HLF_V),¶
2539len - (int)wp-w_old_cursor_fcol);¶
}}}
This is due to wp-w_old_cursor_lcol being set to MAXCOL, so the sum in
the above comparison overflows and incorrectly causes the comparison to
succeed. So, RL_MEMSET walks off the end of ScreenAttrs.
Attached patch fixes the problem.
Thanks,
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
diff --git a/src/screen.c b/src/screen.c
--- a/src/screen.c
+++ b/src/screen.c
@@ -2531,7 +2531,8 @@
/* Visual block mode: highlight the chars part of the block */
if (wp-w_old_cursor_fcol + txtcol (colnr_T)W_WIDTH(wp))
{
- if (wp-w_old_cursor_lcol + txtcol (colnr_T)W_WIDTH(wp))
+ if (wp-w_old_cursor_lcol != MAXCOL
+ wp-w_old_cursor_lcol + txtcol (colnr_T)W_WIDTH(wp))
len = wp-w_old_cursor_lcol;
else
len = W_WIDTH(wp) - txtcol;
signature.asc
Description: Digital signature
Re: Lisp/Scheme paren matching
I'm happy to help if I can, but I don't want to waste my time trying to fix a non-existent bug, so I would like the question I raised in the above message answered: do you or do you not believe matchparen flashing parens inside strings is a bug? If so, when I have time, I'll try to fix it. It should also get recorded in the bug database, so it doesn't get forgotten. I am by no means a maintainer of Vim so I can only say for myself. I believe it's not a bug but an undocumented feature and I would suggest to update documentation instead and maybe add an alert in matchparen script if syntax highlighting is off. Speaking if the bug database, there are two ones: :help todo inside Vim and http://code.google.com/p/vim/issues/list. Frankly I doubt that adding this to any of the databases will do any good: there are too many real bugs in the todo list. -- Sergey Khorev http://sites.google.com/site/khorser Can anybody think of a good tagline I can steal? -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
