Re: Can we still edit the patches list on google groups?
John Beckett wrote: Ben Schmidt wrote: I gave up on SVN ages ago--I would have loved to use it, but it's just too messy. Now I apply patches. Below is the script Eventually I'd like to have a tip (http://vim.wikia.com/) on building Vim, with probably one overview article, and separate articles for downloading, patching, configuring, building, installing (and possibly separate pages for different platforms). Like you, I decided to do my own get patches script. In my case, a command like 'getpatch.py 1 18' will download patches 1..18 into a single file named 'patch-7.2.001-018'. Any thoughts? Should I put your script and my script on a page as a starting point? Might as well. It's easier to delete stuff than recreate it. I think in the end we'll want something simple that will work on as many systems as possible (which I think probably means using shell script and standard utilities without GNU extensions to cover Unix and Mac, and some batch script for Windows if it's even possible without extra software on that OS...). Perhaps an alternative would be suggesting and creating a make target that could handle the downloading and patching (again, in a very platform-independent way) and ask Bram to consider it. If Vim building could be ./configure; make patch; make; make install or something like that, it could be nice and accessible. Another issue that should be included is keeping runtime files up-to-date. Another make target? A vim plugin that calls the shell to do it? I don't know. But that's another thing worthy of a tip. Ben. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: slick way to keep patches?
sc wrote: On Sunday 16 November 2008 2:34 pm, Markus Heidelberg wrote: sc, 15.11.2008: I finally bit the bullet and applied Markus Heidelberg's relative number patch to my source -- I love it so much I added Nice to hear. With subversion you don't have to reapply the patch. When working on this feature, svn update auto-merged my local changes. With rsync I'm not sure. Searching the man page for merge shows several matches, so it seems to be possible, too. But I don't have experience with it. I learned this myself today -- svn updated to 7.2.42 and on the modules affected by both the .42 update and relative number patch, svn performed a merge, not a replace. I am beginning to suspect rsync is equally intelligent, but I have yet to prove it. Ok -- I took a deep breath and did an rsync -- it replaces. The good news is the modules it replaced are the same as the last rsync (as far as what was in the relative number patch) so I can use the same patch extract as last time: Index: runtime/menu.vim Index: runtime/optwin.vim Index: runtime/doc/options.txt Index: runtime/doc/quickref.txt Index: runtime/doc/syntax.txt Index: runtime/doc/version7.txt Index: runtime/lang/menu_de_de.latin1.vim Index: runtime/syntax/vim.vim You could also use the vim_extended git repository, of course. I'll try to add a runtime branch. When this would work with correct merging, then it would be even easier, you could get your patches and runtime updates with one command. For now at least, svn/rsync are doing the job for me, but who knows what the future holds. And thanx again for a great patch. It is worlds above Charles' relative number plugin (no offense, Charles) and really should be part of mainstream vim. No problem -- Bram had mentioned that relative numbering should be do-able via a plugin, so I chose to try to do so. I think the plugin does it as much as a plugin can, and thus reveals the limitations of that approach. An alternative plugin-approach would involve opening a thin non-file buffer next to the original file. That would have the benefit of maintaining separate relative number listings for each buffer, but would suffer due to having the usual window separator in-between (and possibly even an unwanted scrollbar). The only criticism I could make of MH's patch, and perhaps I'm just ignorant of how to do it -- but I rather like the plugin's different colorization of previous vs future relative numbers, and would like it if the relative numbering patch would provide something similar. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: slick way to keep patches?
On Monday 17 November 2008 9:22 am, Charles Campbell wrote: [bigsnip] The only criticism I could make of MH's patch, and perhaps I'm just ignorant of how to do it -- but I rather like the plugin's different colorization of previous vs future relative numbers, and would like it if the relative numbering patch would provide something similar. Amazing -- that was what I did not like about it -- I found the different colors and the italicized font to be gaudy and distracting -- certainly not useful. If Markus' patch starts doing that I'll either find a way to turn it off or stop using it. oldsong Which is what makes vim such a great editor -- we all have different tastes, and can customize our environment to suit ourselves. Just look at the plethora of available color schemes -- it's hard to believe some of them (tomatosoup?) have a real fan base, but most represent a view of the way different people like to work. /oldsong sc --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: slick way to keep patches?
sc wrote: On Monday 17 November 2008 9:22 am, Charles Campbell wrote: [bigsnip] The only criticism I could make of MH's patch, and perhaps I'm just ignorant of how to do it -- but I rather like the plugin's different colorization of previous vs future relative numbers, and would like it if the relative numbering patch would provide something similar. Amazing -- that was what I did not like about it -- I found the different colors and the italicized font to be gaudy and distracting -- certainly not useful. If Markus' patch starts doing that I'll either find a way to turn it off or stop using it. [snip] Well, the plugin has a section in the docs about how to change that, under the subtitle Modifying The Relative Numbering Highlighting; you can change both the colorization to whatever you like and remove the italicization, too. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
crash when pasting clipboard from mouse
Hi I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). Steps to reproduce: 1/ start Vim in a terminal (xterm or gnome-terminal) with: vim -u NONE 2/ enter INSERT mode with:i 3/ select (into clipboard) a few lines of text with the mouse from another terminal 4/ paste those selected lines with the mouse into Vim (middle click) 5/ visual select all text with and reformat with: Esc1GVGgq 6/ delete everything with::%d 7/ enter insert mode again with:i 8/ paste same again text still in clipboard with the mouse (middle click) Observe that after pasting test in step 8/, Vim either crashes with: Vim: Caught deadly signal ABRT Vim: preserving files... .. or sometimes Vim just misbehaves (hangs or not longer accepts all keystrokes for example). Sometimes the text is not inserted at all when pasting the second time at step 8/. Running the same test with Valgrind, I see errors 100% of the times but so far I did not find how to fix them: ==11904== Conditional jump or move depends on uninitialised value(s) ==11904==at 0x47D8548: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47D891A: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C23E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C2D87: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C1CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x81415D6: xterm_update (os_unix.c:6513) ==11904==by 0x813F8A1: RealWaitForChar (os_unix.c:4969) ==11904==by 0x813F50E: WaitForChar (os_unix.c:4640) ==11904==by 0x813B53B: mch_inchar (os_unix.c:366) ==11904==by 0x81A4706: ui_inchar (ui.c:193) ==11904==by 0x80D274A: inchar (getchar.c:2959) ==11904==by 0x80D237D: vgetorpeek (getchar.c:2735) ==11904==by 0x80D0919: vgetc (getchar.c:1552) ==11904==by 0x80D0E94: safe_vgetc (getchar.c:1757) ==11904==by 0x806368A: edit (edit.c:711) ==11904==by 0x81233CC: invoke_edit (normal.c:8885) ==11904==by 0x8123372: nv_edit (normal.c:8858) ==11904==by 0x8116C54: normal_cmd (normal.c:1184) ==11904==by 0x80DE8DA: main_loop (main.c:1180) ==11904==by 0x80DE427: main (main.c:939) (more errors after that) Does anybody else see that bug too? -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
2008/11/17 Dominique Pelle [EMAIL PROTECTED]: Hi I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). Steps to reproduce: 1/ start Vim in a terminal (xterm or gnome-terminal) with: vim -u NONE 2/ enter INSERT mode with:i 3/ select (into clipboard) a few lines of text with the mouse from another terminal 4/ paste those selected lines with the mouse into Vim (middle click) 5/ visual select all text with and reformat with: Esc1GVGgq 6/ delete everything with::%d 7/ enter insert mode again with:i 8/ paste same again text still in clipboard with the mouse (middle click) Observe that after pasting test in step 8/, Vim either crashes with: Vim: Caught deadly signal ABRT Vim: preserving files... .. or sometimes Vim just misbehaves (hangs or not longer accepts all keystrokes for example). Sometimes the text is not inserted at all when pasting the second time at step 8/. Running the same test with Valgrind, I see errors 100% of the times but so far I did not find how to fix them: ==11904== Conditional jump or move depends on uninitialised value(s) ==11904==at 0x47D8548: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47D891A: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C23E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C2D87: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C1CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x81415D6: xterm_update (os_unix.c:6513) ==11904==by 0x813F8A1: RealWaitForChar (os_unix.c:4969) ==11904==by 0x813F50E: WaitForChar (os_unix.c:4640) ==11904==by 0x813B53B: mch_inchar (os_unix.c:366) ==11904==by 0x81A4706: ui_inchar (ui.c:193) ==11904==by 0x80D274A: inchar (getchar.c:2959) ==11904==by 0x80D237D: vgetorpeek (getchar.c:2735) ==11904==by 0x80D0919: vgetc (getchar.c:1552) ==11904==by 0x80D0E94: safe_vgetc (getchar.c:1757) ==11904==by 0x806368A: edit (edit.c:711) ==11904==by 0x81233CC: invoke_edit (normal.c:8885) ==11904==by 0x8123372: nv_edit (normal.c:8858) ==11904==by 0x8116C54: normal_cmd (normal.c:1184) ==11904==by 0x80DE8DA: main_loop (main.c:1180) ==11904==by 0x80DE427: main (main.c:939) (more errors after that) Does anybody else see that bug too? -- Dominique I see that: - vim 'small' is not affected by the bug - vim 'normal' has the bug. Tweaking feature.h manually, I got 2 version of them, which only differ by the FEAT_XCLIPBOARD feature: - the one with FEAT_XCLIPBOARD is affected by the bug - the one without FEAT_XCLIPBOARD is not affected by the bug. So +xterm_clipboard is the feature that is triggering the bug. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On Mon, Nov 17, 2008 at 6:02 PM, Dominique Pelle wrote: 2008/11/17 Dominique Pelle: Hi I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). Steps to reproduce: ... Observe that after pasting test in step 8/, Vim either crashes with: Vim: Caught deadly signal ABRT Vim: preserving files... .. or sometimes Vim just misbehaves (hangs or not longer accepts all keystrokes for example). Sometimes the text is not inserted at all when pasting the second time at step 8/. Running the same test with Valgrind, I see errors 100% of the times but so far I did not find how to fix them: ... Does anybody else see that bug too? I see that: - vim 'small' is not affected by the bug - vim 'normal' has the bug. Tweaking feature.h manually, I got 2 version of them, which only differ by the FEAT_XCLIPBOARD feature: - the one with FEAT_XCLIPBOARD is affected by the bug - the one without FEAT_XCLIPBOARD is not affected by the bug. So +xterm_clipboard is the feature that is triggering the bug. I'm not having any luck at all reproducing this, with 7.2.025 and +xterm_clipboard... ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
Hi Does anybody else see that bug too? No. Ubuntu 8.04, x86_64, vim 7.2.042, huge including +xterm_clipboard. Regards, John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Mon, Nov 17, 2008 at 02:44, John Beckett [EMAIL PROTECTED] wrote: Any thoughts? Should I put your script and my script on a page as a starting point? Can't hurt, all for it. Do you want to include the git howto I sent to the user's list, as well? I can do it myself, just need to know :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Mon, Nov 17, 2008 at 08:38, Markus Heidelberg [EMAIL PROTECTED] wrote: Ben Schmidt, 17.11.2008: I gave up on SVN ages ago--I would have loved to use it, but it's just too messy. Now I apply patches. Below is the script I use to do it with Mercurial, which may serve as a starting point for doing the same with Git (or whatever); do what you like with it. Thanks. Apparently there are several unhappinesses with the official repo. I still have to decide whether to go this way, but it really seems so. Let's see when I have time during this week to get started. I seem to remember encoding issues with the patch emails that did not occur in the svn repo. Just something to keep in mind. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Can we still edit the patches list on google groups?
Richard Hartmann wrote: Can't hurt, all for it. Do you want to include the git howto I sent to the user's list, as well? I can do it myself, just need to know :) Despite the fact that this thread is about the unofficial patches, I was responding to Ben's script that relates to the official patches. I've thought that the wiki should have some articles on building Vim, including the official patches. That's quite ambitious and I don't think it's going to be achieved soon (although I probably will make a stub to park Ben's script). So, documenting how to build with the unofficial patches is a long way off, although I suppose it's easy to make a stub for that as well. In conclusion, please wait. I'll announce the stubs in a week or two. John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On Mon, 17 Nov 2008 22:18:23 +0100 Dominique Pelle [EMAIL PROTECTED] wrote: I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). [...] Does anybody else see that bug too? Could NOT reproduce with Vim 7.2.42 with HUGE and +xterm_clipboard on OpenBSD 4.4 (i386). Complete version info attached; hope this helps. -- Taylor Christopher Venable http://real.metasyntax.net:2357/ How many shells could Shell sort sort if Shell sort could sort shells? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- vim-version.txt Description: Binary data
Re: Can we still edit the patches list on google groups?
On Tue, Nov 18, 2008 at 04:06, John Beckett [EMAIL PROTECTED] wrote: Despite the fact that this thread is about the unofficial patches, I was responding to Ben's script that relates to the official patches. Oh, sorry! In conclusion, please wait. I'll announce the stubs in a week or two. Will do :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
On Mon, Nov 17, 2008 at 22:18, Dominique Pelle [EMAIL PROTECTED] wrote: Does anybody else see that bug too? Works fine for me. VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 17 2008 08:42:16) Included patches: 1-42 Normal version with GTK2 GUI --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
