Re: Start Working Today
On Mon, Mar 26, 2012 at 16:30, Marc Weber marco-owe...@gmx.de wrote: [...] So does anybody have an idea whether this is a (badly written) real job offer by Bram or whether it is what it looks like: spam? It is SPAM. Just Google for jobdayseu.com and you'll see many similar job offer letters in many different mailing lists. And why is the sending email something @vim.org? I would love to see a job site for vimmers :) But we should create a dedicated mailinglist then. -- 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
Please help remove Vim from SVN from vim.org
Hi Bram, A few years ago, we created Subversion mirror of Vim repository because CVS lacks some important features, such as changeset management, atomic commit, etc. Nowadays, as we have already switched to Mercurial, which is a very advanced distributed version control system as powerful as Git and as simple to use as Subversion, I think it makes no sense to continue maintaining a Subversion mirror any longer. So could you please remove all the pages and links to Subversion mirror from vim.org web site? Many thanks for your hard work during the releasing phase of Vim 7.3! Regards, - Edward -- 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] Fix the E329 error under Japanese locale
Problem: after 7.2.432, Vim shows E329 error during start up. Reason: Japanese translation adds a few Japanese-specific menu items using Japanese paths. Those Japanese paths prevent the correct English paths from being inserted. Solution: modify the root menu name back to English when inserting those Japanese-specific menu items. Author: Bezetek James beze...@gmail.com -- 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 diff.patch Description: Binary data
Re: Patch: make emenu accept the unlocalized menu names
On Mon, May 03, 2010 at 04:51:27PM +0200, Tony Mechelynck wrote: On 03/05/10 07:50, Edward L. Fox wrote: [...] This patch makes both localized and unlocalized menu items appear in the wild menu. I think it's reasonable because both of them works. What do you think? If they are selectable separately, I think it's comparable to what happens when localized help is installed, where helptag completion brings up tags for both @en help and help in every installed help language. For the menus, I suppose that if v:lang is C, POSIX, en, or, let's say, en_US.UTF-8 or English_United-States.1252, only English menus will come up (and that only once for each menu or menuitem)? The language of the menu could be specified by set langmenu=... statement in .vimrc. If your menu language is not English, this patch will make both localized menu items and original ones appear in the wild menu. If your menu language is already English, it will *not* display each menu item twice. Best regards, Tony. -- MORTICIAN:Bring out your dead! [clang] Bring out your dead! [clang] Bring out your dead! CUSTOMER: Here's one -- nine pence. DEAD PERSON: I'm not dead! The Quest for the Holy Grail (Monty Python) -- 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: Patch: make emenu accept the unlocalized menu names
On Fri, May 07, 2010 at 04:17:36PM +0200, Bram Moolenaar wrote: Edward L. Fox wrote: Here's a small patch provided by Liang Peng, alias Bezetek James. He has fixed the problem in menu/unmenu/emenu series commands. As my understanding, emenu is designed for scripts to access some menu items. However, emenu only accepts the localized menu names. For example, you can use your script to add a new menu item by calling amenu File.Test :echo 'hello'CR, but you can't execute the same menu item by calling emenu File.Test if you are not running Vim in English mode. Instead, you have to use localized menu name for File. However, we don't have any interface to access the menu translation table via script. So emenu command is nearly useless for script writers. Bezetek's patch makes menu/unmenu/emenu useful again. He modified the menu structure to store the original strings before the localization, and accepts the unlocalized strings for all the menu series commands when calling all menu related command. To keep the compatibility, localized menu names are also accepted, just like the behavior before. This is his first patch to Vim, and he's quite eager to participate in open source projects. Please help review his patch and include it in the next release of Vim. Many thanks! This is very useful. There was an old patch that I never got around looking into, from Bjorn Winckler. It dates 2008 March 30. http://www.mail-archive.com/vim_dev@googlegroups.com/msg02561.html Perhaps you can compare the patches and find out what works best? I reviewed both of them. The patch from Bjorn only fixed the emenu problem. Liang's patch actually did much more, for example, it also adjust the wild menu for all menu related commands as well. Moreover, he slightly modified the structure of menu.c to make the code a little bit more readable, which was also suggested by Bjorn in his post. I think his patch is already in very good quality, and is almost ready to be included. Can anyone else also help with a more strict review? -- How To Keep A Healthy Level Of Insanity: 3. Every time someone asks you to do something, ask if they want fries with that. /// Bram Moolenaar -- b...@moolenaar.net -- 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. 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: make emenu accept the unlocalized menu names
Hi Bram, Here's a small patch provided by Liang Peng, alias Bezetek James. He has fixed the problem in menu/unmenu/emenu series commands. As my understanding, emenu is designed for scripts to access some menu items. However, emenu only accepts the localized menu names. For example, you can use your script to add a new menu item by calling amenu File.Test :echo 'hello'CR, but you can't execute the same menu item by calling emenu File.Test if you are not running Vim in English mode. Instead, you have to use localized menu name for File. However, we don't have any interface to access the menu translation table via script. So emenu command is nearly useless for script writers. Bezetek's patch makes menu/unmenu/emenu useful again. He modified the menu structure to store the original strings before the localization, and accepts the unlocalized strings for all the menu series commands when calling all menu related command. To keep the compatibility, localized menu names are also accepted, just like the behavior before. This is his first patch to Vim, and he's quite eager to participate in open source projects. Please help review his patch and include it in the next release of Vim. Many thanks! Regards, Edward Fox -- 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 emenu.patch Description: Binary data
Re: Patch: make emenu accept the unlocalized menu names
On Mon, May 3, 2010 at 13:43, Tony Mechelynck
antoine.mechely...@gmail.com wrote:
On 03/05/10 05:55, Edward L. Fox wrote:
Hi Bram,
Here's a small patch provided by Liang Peng, alias Bezetek James. He
has fixed the problem in menu/unmenu/emenu series commands.
As my understanding, emenu is designed for scripts to access some
menu items. However, emenu only accepts the localized menu names.
For example, you can use your script to add a new menu item by calling
amenu File.Test :echo 'hello'CR, but you can't execute the same
menu item by calling emenu File.Test if you are not running Vim in
English mode. Instead, you have to use localized menu name for
File. However, we don't have any interface to access the menu
translation table via script. So emenu command is nearly useless
for script writers.
[...]
The :emenu command is also useful to access the Vim menus in console mode,
for instance as follows:
if has(wildmenu)
set wildmenu wildmode=longest:full,full
else
set wildmode=longest,list:longest,full
endif
if has('menu')
if !has('gui_running')
runtime menu.vim
endif
set wildcharm=C-T or anything not needed in cmdline mode
map C-Z :emenuC-T
imap C-Z C-O:emenuC-T
we can still suspend Vim with :sus[pend] or :st[op]
endif
This patch makes both localized and unlocalized menu items appear in
the wild menu. I think it's reasonable because both of them works.
What do you think?
Best regards,
Tony.
--
And what will you do when you grow up to be as big as me?
asked the father of his little son.
Diet.
--
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: Planning Vim 7.3: Python3 support?
On Thu, Apr 29, 2010 at 20:27, Bram Moolenaar b...@moolenaar.net wrote: Roland Puntaier wrote: since I had to set up windows I updated the patch for the python3 support to vim trunk 7.2.411. It is attached. Thanks. I didn't hear about anybody using the patch. That might mean it works without problems. Or that nobody uses it... Who tested the Python 3 support? Does it still build with Python 2.x? Do old scripts still work? No, Python 3.x is considered as another language. So most Python 2.x scripts will not work under Python 3.x. -- It's totally unfair to suggest - as many have - that engineers are socially inept. Engineers simply have different objectives when it comes to social interaction. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- b...@moolenaar.net -- 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. 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: Patch 7.2.330
SVN repo will catch up with CVS next Wednesday. Sorry for the delay. 在 2010-1-18 上午5:17，Hisashi T Fujinaka ht...@twofifty.com编写： Anyone know why svn hasn't caught up to this patch (or 328 or 329) yet? Thanks. On Tue, 12 Jan 2010, Bram Moolenaar wrote: Patch 7.2.330 Problem: Tables for Unicode cas... Hisashi T Fujinaka - ht...@twofifty.com BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -- You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.148
On Fri, Mar 20, 2009 at 12:33:25PM +0100, Bram Moolenaar wrote: Tony Mechelynck wrote: On 18/03/09 19:07, Bram Moolenaar wrote: Patch 7.2.148 Problem:When searching for $ while 'hlsearch' is set, highlighting the character after the line does not work in the cursor column. Also highlighting for Visual mode after the line end when this isn't needed. (Markus Heidelberg) Solution: Only compare the cursor column in the cursor line. Only highlight for Visual selection after the last character when it's needed to see where the Visual selection ends. Files:src/screen.c Bram, it's more than a day later and (unlike the foregoing ones) this patch hasn't yet made it to the FTP server. Happily your mail is in 8bit Content-Transfer-Encoding so I can use that, but I suspect the MD* and README files in the patches/7.2 directory on the FTP server haven't been updated either. I just forgot to do this. Thanks for the reminder. Bram, I can't access the FTP server. It told me that the directory containing Vim patches is not accessible. Please help fix that. Thanks! -- hundred-and-one symptoms of being an internet addict: 249. You've forgotten what the outside looks like. /// Bram Moolenaar -- b...@moolenaar.net -- 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 -~--~~~~--~~--~--~---
Re: Patch 7.2.148
On Wed, Mar 25, 2009 at 12:33:51AM +0100, Tony Mechelynck wrote: On 25/03/09 00:23, Hisashi T Fujinaka wrote: I hate to ask dumb questions, but is there some reason this isn't in the svn repository yet? Is my checkout hosed up somehow? Thanks. The SVN repository may lag by up to a week. If this lag is unacceptable to you, you may download the patch from ftp://ftp.vim.org/pub/vim/patches/7.2/7.2.148 or maybe from the CVS repository. It may lag behind up to two days, but not quite probable to reach as high as one week. This time the patch 7.2.148 doesn't appear on time is because some problem of the upstream FTP site. Thanks for the reminder. If the lag goes significantly higher, maybe the SVN repository's maintainer (who isn't Bram) will chime in. Best regards, Tony. -- CART DRIVER: Bring out your dead! We follow the cart through a wretched, impoverished plague-ridden village. A few starved mongrels run about in the mud scavenging. In the open doorway of one house perhaps we jug glimpse a pair of legs dangling from the ceiling. In another doorway an OLD WOMAN is beating a cat against a wall rather like one does with a mat. The cart passes round a dead donkey or cow in the mud. And a MAN tied to a cart is being hammered to death by four NUNS with huge mallets. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.148
On Wed, Mar 25, 2009 at 09:59:27AM +0100, Tony Mechelynck wrote: On 25/03/09 08:35, Edward L. Fox wrote: [...] Looks like the problem is similar to what happened before: ftp://ftp.vim.org/vol/2 (which is on the chain of softlinked directories to ftp://ftp.vim.org/pub/vim/) has drwx-- permissions, i.e., not even readable except by its owner (which happens to be user 0 i.e. root). Yes, I just got the permission denied error from the server side. Edward, I'm including the patch (as attachment, not inline), so you may use that if you like. I'm also attaching the corresponding MD* and README files which I downloaded while they were accessible. I had already downloaded Bram's mail from the mailing list and patched it against my local repository. Anyway, thank you all the same. Best regards, Tony. -- No one can make you feel inferior without your consent. -- Eleanor Roosevelt --~--~-~--~~~---~--~~ 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 Sun, Nov 16, 2008 at 17:56, Markus Heidelberg [EMAIL PROTECTED] wrote: björn, 15.11.2008: [...] Avoiding these conflicts is more important than having nice commit logs. But there should be a way to get both. Edward, do you know why the trunk branch doesn't have nice commit logs and is there a way to get them in? Was this the lack of merge tracking before svn version 1.5? Because Bram doesn't like the idea of testing the most bleeding-edge features on the trunk. So currently, honestly speaking, trunk has no use at all. [...] You fetch from the trunk branch, right? What kind of conflicts did arise? I suspect mostly from the runtime files!? Any conflicts are possible. I'm not feeling surprised to that. Because there's no much relationship in technical layer between the trunk and the branches. The branches are not copied from the trunk. I'm not quite satisfied with the Subversion repository. However, I don't know what I can do to improve the current situation. [...] --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: List of Vim patches
Why not simply create a certain number of branches in the Subversion repository for those semi-official patches? That'll be easier for the end users to check out the patched code or merge the changes from multiple branches. The patches' developers will also benefit because we can easily use some scripts to sync your official changes from the mainstream and keep their patches always up-to-date. On 2008-09-20, Bram Moolenaar [EMAIL PROTECTED] wrote: There are several patches available for Vim. Some are mature, some unfinished. Until now there was no central place that lists these patches, like we have for Scripts. Adding patches to the scripts database doesn't look right. So I created a page that can be edited: http://groups.google.com/group/vim_dev/web/vim-patches I have added the 2008 Google Summer of Code entries as an example. If you want people to know your Vim patch, please add it here! This should be an overview, with links to where more information can be found. Add just enough information for people to know if this is an interesting patch for them. To make the page editable I had to enable adding and editing pages for group members. That probably means we will get some spam. Please remove it when you see it. -- How many light bulbs does it take to change a person? /// 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/// -- Sent from Gmail for mobile | mobile.google.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim 7.2a in CVS
On Wed, Jun 25, 2008 at 1:51 PM, Christian MICHON [EMAIL PROTECTED] wrote: [...] this is the exact reason why I started using git and dropped cvs/svn... now that you're putting the focus on releasing a collection of files and not tracking them individually so much anymore (you're tracking a queue of patches with a naming convention), you want to check in a tree content. use git or mercurial or bzr to get this wish come true. if you need help setting up git, I can provide support. :) Well, switching to git will definitely be a great pain for Bram. We had tried all kinds of efforts to persuade him to switch to Subversion but failed. He said that he invented a bunch of scripts collaborating with CVS so switching to any other version control system would cause a lot of trouble to him. And solving such problem doesn't require any advanced distributed version control system. The only thing we need to do is just persuading Bram to submit some not-well-tested-yet code to the repository timely, marking that branch (or simply trunk in svn) as experimental. But Bram seems not quite like the idea of release earlier, release often. -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim version 7.2a ready for BETA testing
Hi Vimmers, On Wed, Jun 25, 2008 at 4:38 AM, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] Vim 7.2a is also available from CVS (as soon as it finishes uploading). Subversion will follow later. http://www.vim.org/cvs.php http://www.vim.org/subversion.php The 7.2a BETA is already in Subversion repository. Please check it out by: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.2/ If you had already checked out Vim 7.1 from the Subversion repository, please run: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.2/ In the top level of your checking-out directory to switch to 7.2 branch. Note: https://vim.svn.sourceforge.net/svnroot/vim/vim7 will still point to the 7.1 branch until 7.2 is finally release. [...] Happy Vimming! Subversion mirror maintainer, Edward L. Fox --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim version 7.2a ready for BETA testing
On Wed, Jun 25, 2008 at 11:26 PM, Bill McCarthy [EMAIL PROTECTED] wrote: On Wed 25-Jun-08 2:05am -0600, Edward L. Fox wrote: [...] svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.2/ In the top level of your checking-out directory to switch to 7.2 branch. Note: https://vim.svn.sourceforge.net/svnroot/vim/vim7 will still point to the 7.1 branch until 7.2 is finally release. Edward, I'm a little confused with your terminology - top level of your checking out directory. Sorry, my bad... I was a bit tired at that time and I wrote a wrong command in my mail... There should be: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.2/ I'm running on WinXP. The top level of my vim directory is: Directory of C:\vim\* 6/24/2008 22:59 DIR backup 6/22/2008 23:39 DIR vim-fp 7/31/2007 11:18 DIR vim70 6/22/2008 22:34 DIR vim71 5/11/2008 23:25 DIR vim71_svn 6/24/2008 22:53 DIR vim72a 6/24/2008 21:45 DIR vimfiles The top level of my vim svn directory is: Directory of C:\vim\vim71_svn\* 9/09/2007 12:03 DIR farsi 9/09/2007 12:03 DIR libs 9/09/2007 12:03 DIR nsis 9/09/2007 12:01 DIR pixmaps 6/06/2008 8:45 DIR runtime 6/21/2008 23:28 DIR src I believe I initially obtained my current SVN download by: cdd c:\vim svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1/ vim71_svn I think I would do about the same thing for 7.2: cdd c:\vim svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.2/ vim72_svn Does that appear correct? Yes, it's correct. But you just checked out a brand new directory. I meant to provide the method to simply switch the existing local directory to the latest branch rather than check out another directory. Running the command above will do that. Also I have an alias to update my files. My current alias, say sv71, does: pushd c:\vim\vim71_svn svn up svn log --limit 1 popd I should now create another alias, say sv72, that does: pushd c:\vim\vim72_svn svn up svn log --limit 1 popd This way, I should be able to update vim71_svn with 'sv71' and update vim72_svn with 'sv72'. Does that also appear correct? Vim71 will no longer be updated. So you don't need to keep the alias for it. -- Best regards, Bill --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.298
Hi Bram, On Sun, May 11, 2008 at 4:16 AM, Bram Moolenaar [EMAIL PROTECTED] wrote: Patch 7.1.298 (after 7.1.295) Problem:src/gvimtutor is not distributed. Solution: Add it to the list of distributed files. Files: Filelist Please re-upload this patch to the FTP. I don't find it. [...] Regards, L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: test42 failure
Hi all, On Fri, Mar 28, 2008 at 6:16 AM, Markus Heidelberg [EMAIL PROTECTED] wrote: Edward L. Fox, 27.03.2008: [...] The repository seems not to be updated. svn status -u doesn't indicate a new revision. It's still r916 from patch 7.1.263. Oh, I just updated the trunk and the vim7.1 branch but forgot to copy the latest branch to $svnroot/vim. I did the required operation just now and please re-check whether it works now. By the way, personally I just don't like the idea of copying latest branch to $svnroot/vim. But Bram insisted that. Markus Regards, L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: test42 failure
Hi all, On Thu, Mar 27, 2008 at 3:49 AM, Bram Moolenaar [EMAIL PROTECTED] wrote: Edward, can you please verify that the src/test42.in file is correct in SVN? It was corrupt in CVS, because the patch command failed to handle the binary stuff in the diff. You may have had the same problem. Oh yes, it did corrupt. I just copied the corresponding file from CVS and re-submitted it. Any one please help me verify whether it is OK now? [...] Regards, L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: GSoC : Make Vim work as a plugin with Eclipse
Hi Adrien, On Thu, Mar 27, 2008 at 3:49 AM, Bram Moolenaar [EMAIL PROTECTED] wrote: Adrien Lemaire wrote: Hi Bram, I'm student in second year in SUPINFO, French informatic engineer school in 5 years. It's You can see more details about this school herehttp://www.supinfo.com/en/Default.aspx, and I can give you more informations about it if you want ! I discovered yesterday the GSoC, and after looking the differents organisations, I found Vim, which have immediately excited me. Effectively, I work with Vim for 1 year, and for 4 months in enterprise (coding PHP, Ajax, Perl, SVG). I use Vim on Debian and Mac Os X for coding in many procedural languages and in web development. For OOP languages like java, I prefer use Eclipse. So, when I saw your task make Vim work as a plugin with Eclipse, I immediately wanted to work about this subject. Asking on the irc channel, someone give me your email, saying you were *the* mentor. So could you give me more details about existing solutions ? What are the languages used in develop these solutions ? Don't hesitate to ask any questions ! I prefer wait your answer and be sure you agree with me before submit this task on GSoP Applications Student. Be sure I'm really motivated and serious. Hope to work with Vim. Bests regards, Adrien LEMAIRE, Student of SUPINFO More info at these links: http://vimplugin.sourceforge.net/wiki/pmwiki.php Last years project: http://code.google.com/p/eeedit/ I am one of the members of that project, although I in fact did no contributions to it. Well, I will probably have no permission to participate in GSoC this summer. However, if this project successfully obtained the GSoC approval, I'd like to be the co-mentor informally, giggling. I'm familiar with Java the language and I'm good at software architecture designing and refactoring. -- [...] Regards, L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to save a UTF-8 file on Windows using a non-ASCII name
Hi Fan, 2008/1/21 Fan Decheng [EMAIL PROTECTED]: [...] Here is a snippet from the Vim's reference: NOTE: Changing this option will not change the encoding of the existing text in Vim. It may cause non-ASCII text to become invalid. It should normally be kept at its default value, or set when Vim starts up. See |multibyte|. To reload the menus see |:menutrans|. Thanks. It seems that setting `encoding' before opening the file works. Yes, it works fine for this case. But it doesn't necessary means that it's also OK for all the functions in Vim. So as a practical suggestion, never modify the encoding as long as you've already launched Vim. Only change this option *ONCE* in your .vimrc. L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to save a UTF-8 file on Windows using a non-ASCII name
Hi Fan, On Jan 20, 2008 3:03 PM, Fan Decheng [EMAIL PROTECTED] wrote: Here I mean on the Windows platform, using Vim 6.4 or 7.1. I've encountered this problem several times, but don't know whether there is a solution: 1. Use gvim to open a file with Chinese characters in its name. For example: 测 试.txt . 2. Type :set enc=utf-8 (without quotes). Here is a snippet from the Vim's reference: NOTE: Changing this option will not change the encoding of the existing text in Vim. It may cause non-ASCII text to become invalid. It should normally be kept at its default value, or set when Vim starts up. See |multibyte|. To reload the menus see |:menutrans|. Personally I think this should be a bug of Vim. However, as it had already been well-documented, I think you should follow the principles. 3. Type :e to make the file content displayed using utf-8. 4. Type :wq to save the file. After these steps, the file is saved in the name ²âÊÔ.txt rather than the original name. Another thing that went wrong is 测试.txt.swp is left undeleted. I looked for any file name encoding options in vim but failed to find anything. Please carefully read the documentations of the following options: fencs fenc encoding termencoding Any ideas? -- Fan Decheng (Robbie Mosaic) [EMAIL PROTECTED] Regards, L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to save a UTF-8 file on Windows using a non-ASCII name
Hi Tony, On Jan 21, 2008 11:41 AM, Tony Mechelynck [EMAIL PROTECTED] wrote: Linxiao wrote: [...] Tt, tt, tt... If 'encoding' is other than UTF-8 (or GB18030), Vim cannot represent all Unicode codepoints in memory; therefore, if you try to edit a UTF-8 file you run the risk of losing part of the data. (If you set 'enc' to UTF-16, UCS-2 or UCS-4 aka UTF-32, with any endianness, what Vim will use is actually UTF-8.) I'm familiar with different shapes of malformed characters. In fact the *thread-host*'s problem was not caused by the code points losing. ²âÊÔ was generated by the following steps: 1. At first, the thread-host represents 测试 in GBK encoding. 2. Then he re-sets the encoding to UTF-8. So the filename information in Vim gets lost. Vim re-interprets the filename as Latin-1. 3. Vim converts the latin-1 string to UTF-8. 4. Vim saves the file to the disk with the new name. Windows will convert the UTF-8 string to UCS, of course. Now the new filename is exactly ²âÊÔ. Here is the illustration (my system charset is UTF-8): [EMAIL PROTECTED] ~]$ echo 测试 | iconv -f utf-8 -t gbk | iconv -f latin1 -t utf-8 ²âÊÔ To edit UTF-8 data you should have both 'encoding' (= memory representation of the data) and 'fileencoding (= disk representation of the data) set to UTF-8. [...] Best regards, Tony. -- During a grouse hunt in North Carolina two intrepid sportsmen were blasting away at a clump of trees near a stone wall. Suddenly a red-faced country squire popped his head over the wall and shouted, Hey, you almost hit my wife. Did I? cried the hunter, aghast. Terribly sorry. Have a shot at mine, over there. Regards, L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
When will 7.2 come out?
Hi Bram, There are already more than 200 patches. When will 7.2 come out? Any plans? Regards, Edward Leap Fox --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.177
Hi Bram, On Jan 1, 2008 9:17 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: Patch 7.1.177 Problem:Freeing memory twice when in debug mode while reading a script. Solution: Ignore script input while in debug mode. Files: src/ex_cmds2.c, src/getchar.c, src/globals.h I didn't see this patch on the FTP site. Could you please re-upload it? Thanks a lot! [...] Regards, Edward L. Fox --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: About patch 7.1.130
On 10/2/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Patch 7.1.130 Problem:Crash with specific order of undo and redo. (A.Politz) Solution: Clear and adjust pointers properly. Add u_check() for debugging. Files:src/undo.c, src/structs.h I shouldn't send out patches late at night... The title should be without About! Could you please tell me that which titles should be with About and which shouldn't? It seems that many patches these days are all with About prefix. Any way, good night and sleep tight~ -- CART DRIVER: Bring out your dead! We follow the cart through a wretched, impoverished plague-ridden village. A few starved mongrels run about in the mud scavenging. In the open doorway of one house perhaps we jug glimpse a pair of legs dangling from the ceiling. In another doorway an OLD WOMAN is beating a cat against a wall rather like one does with a mat. The cart passes round a dead donkey or cow in the mud. And a MAN tied to a cart is being hammered to death by four NUNS with huge mallets. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// 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/// L. F. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: patch 7.1.108
Hi Vimmers, On 9/15/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Patch 7.1.108 (after 7.1.100) Problem:Win32: Compilation problems in Cscope code. (Jeff Lanzarotta) Solution: Use (long) instead of (intptr_t) when it's not defined. Files: src/if_cscope.c [...] I'm sorry to inform that I have to pending this patch from submitting it to the SVN repository until next Monday due to the power failure last night. Everything will be OK since then so just don't panic. Regards, Edward L. Fox --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Handling Unicode codepoints outside the BMP
Hi Bram, On 9/11/07, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] Ehm, are you just guessing here? You better find a way to test it. I don't want to include this without testing. I doubt X11 uses UTF-16, that is something that MS-Windows uses. GTK uses utf-8 in most places. Other X11 toolkits probably differ, since they are older. I just tested the X11 and Gtk1 in my Debian box. X11 front-end failed to compile. Gtk1 front-end compiled OK, but doesn't work properly. I'm afraid I'll not be able to make these two so old front-ends work properly. Could you just send out the first patch for screen.c first? Then all the other front-ends, including GTK2, GNOME2, Windows, will work fine. -- DEAD PERSON: I'm getting better! CUSTOMER: No, you're not -- you'll be stone dead in a moment. MORTICIAN:Oh, I can't take him like that -- it's against regulations. The Quest for the Holy Grail (Monty Python) /// 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/// Regards, Edward L. Fox --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Handling Unicode codepoints outside the BMP
Hi Bram,
On 9/11/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
[...]
Only two bytes are put in buf[], thus more needs to be changed here to
make it work.
[...]
Here too.
[...]
I don't know how to deal with the characters outside BMP for XChar2b.
I just assume that it is UTF-16. Please help me check this patch:
Index: gui_x11.c
===
--- gui_x11.c (revision 513)
+++ gui_x11.c (working copy)
@@ -2562,17 +2562,39 @@
# ifdef FEAT_XFONTSET
if (current_fontset != NULL)
{
- if (c = 0x1 sizeof(wchar_t) = 2)
+#ifdef UNICODE16
+ if (c = 0x1)
c = 0xbf; /* show chars 0x as ? */
+#endif
((wchar_t *)buf)[wlen] = c;
}
else
# endif
{
+#ifdef UNICODE16
if (c = 0x1)
c = 0xbf; /* show chars 0x as ? */
((XChar2b *)buf)[wlen].byte1 = (unsigned)c 8;
((XChar2b *)buf)[wlen].byte2 = c;
+#else
+ if (c 0x1)
+{
+((XChar2b *)buf)[wlen].byte1 = (unsigned)c 8;
+((XChar2b *)buf)[wlen].byte2 = c;
+}
+else
+{
+unsigned short first, second;
+c -= 0x1;
+first = c 10 + 0xD800;
+second = c 0x3FFUL + 0xDC00;
+((XChar2b *)buf)[wlen].byte1 = first 8;
+((XChar2b *)buf)[wlen].byte2 = first;
+++wlen;
+((XChar2b *)buf)[wlen].byte1 = second 8;
+((XChar2b *)buf)[wlen].byte2 = second;
+}
+#endif
}
++wlen;
cells += utf_char2cells(c);
Index: gui_gtk_x11.c
===
--- gui_gtk_x11.c (revision 513)
+++ gui_gtk_x11.c (working copy)
@@ -6057,7 +6057,8 @@
if (buflen len)
{
XtFree((char *)buf);
- buf = (XChar2b *)XtMalloc(len * sizeof(XChar2b));
+ buf = (XChar2b *)XtMalloc(len * (sizeof(XChar2b) sizeof(wchar_t)
+ ? sizeof(wchar_t) : sizeof(XChar2b)));
buflen = len;
}
@@ -6070,10 +6071,30 @@
if (enc_utf8)
{
c = utf_ptr2char(p);
+#ifdef UNICODE16
if (c = 0x1) /* show chars 0x as ? */
c = 0xbf;
buf[textlen].byte1 = c 8;
buf[textlen].byte2 = c;
+#else
+ if (c 0x1)
+{
+buf[textlen].byte1 = c 8;
+buf[textlen].byte2 = c;
+}
+else
+{
+unsigned short first, second;
+c -= 0x1;
+first = c 10 + 0xD800;
+second = c 0x3FFUL + 0xDC00;
+buf[textlen].byte1 = first 8;
+buf[textlen].byte2 = first;
+++textlen;
+buf[textlen].byte1 = second 8;
+buf[textlen].byte2 = second;
+}
+#endif
p += utf_ptr2len(p);
width += utf_char2cells(c);
}
Regards,
Edward L. Fox
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Handling Unicode codepoints outside the BMP
Hi Tony, thanks for your reply! But we are not talking about the coverage of UTF-16, we just want to make sure whether X11 uses UTF-16, or only UCS-16, which only supports BMP. I'm afraid I'll have no time to test that until this Thursday, so I hope any one could help. Best regards, Edward Fox On 9/11/07, Tony Mechelynck [EMAIL PROTECTED] wrote: Bram Moolenaar wrote: [...] I doubt X11 uses UTF-16, that is something that MS-Windows uses. GTK uses utf-8 in most places. Other X11 toolkits probably differ, since they are older. Even with UTF-16, it is possible to display codepoints outside the BMP (up to U+10 IIRC, and the current Unicode guidelines say that there will never be any valid codepoints higher than that) by means of surrogate pairs. IIRC, that's what the W32 GUI already does. Best regards, Tony. -- Dealing with failure is easy: work hard to improve. Success is also easy to handle: you've solved the wrong problem. Work hard to improve. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Errors unreadable with cursorline in default color scheme
On 9/10/07, Ingo Karkat [EMAIL PROTECTED] wrote: [...] Okay, but how often (and with how many colorschemes) does this actually occur? I personally would rather encounter an occasional weird line (a mere nuisance, but still fully readable) than barely readable text (as reported with the Error group in the default color scheme). I think It's the colorscheme's author's responsibility to keep the colorscheme readable in any circumstances. So I think the only thing we need to do to this issue is just a simple one-line patch to the default colorscheme. In fact, I have already modified my personal colorscheme (with mixed results) because I encountered bad readability with the highlighting + cursorline combination (but didn't want to miss the improved readability of cursorline). If your modified colorscheme is included in the official colorschemes, I think you should post your patches to the mailing list. Thanks~ -- ingo --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Errors unreadable with cursorline in default color scheme
On 9/10/07, Tony Mechelynck [EMAIL PROTECTED] wrote: [...] The default.vim colorscheme simply invokes the Vim or gvim defaults, whatever they may be in the Vim version currently running; it has no :highlight statements: so the patch won't go into the default colorscheme ($VIMRUNTIME/colors/default.vim) which is not even sourced when you run Vim without a colorscheme, but in the internal default values. I knew that. But in fact modifying the internal default values are also as easy as modifying the external ones. There are two ways for working around this problem, the first way is making the Error highlight darker, the other way is making the CursorLine and CursorColumn darker. But the first way will probably failed in many situations because so many syntax files contain guifg=White. So I think I'll use the second method: Index: src/syntax.c === --- src/syntax.c(revision 513) +++ src/syntax.c(working copy) @@ -6267,9 +6267,9 @@ #endif #ifdef FEAT_SYN_HL CENT(CursorColumn term=reverse ctermbg=LightGrey, -CursorColumn term=reverse ctermbg=LightGrey guibg=Grey90), +CursorColumn term=reverse ctermbg=LightGrey guibg=Grey), CENT(CursorLine term=underline cterm=underline, -CursorLine term=underline cterm=underline guibg=Grey90), +CursorLine term=underline cterm=underline guibg=Grey), #endif #ifdef FEAT_AUTOCMD CENT(MatchParen term=reverse ctermbg=Cyan, In fact, I have already modified my personal colorscheme (with mixed results) because I encountered bad readability with the highlighting + cursorline combination (but didn't want to miss the improved readability of cursorline). If your modified colorscheme is included in the official colorschemes, I think you should post your patches to the mailing list. Thanks~ -- ingo Writing a personal colorscheme is easy: I have my own ~/.vim/colors/almost-default.vim. Changing the highlighting defaults in the C or C++ code is a different cup of tea. We say a plate of vegetable and the Americans say a piece of cake. Best regards, Tony. -- The nice thing about standards is that there are so many of them to choose from. -- Andrew S. Tanenbaum --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Errors unreadable with cursorline in default color scheme
I'll fix it 9 hours later. Sorry for top-posting because WAP only support this. On 9/10/07, Nico Weber [EMAIL PROTECTED] wrote: Hi, `set cursorline` seems to override the background colors even for characters that are in group Error. With the default color scheme, this makes Errors unreadable: They are displayed with red background and white text, and the default cursorline color is a light grey. If the cursor is in the same line as the error, Errors are displayed with a light grey background and white text -- barely readable (tested on gvim/ubuntu and carbon vim/osx). Any ideas what could be done about this? Thanks, Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Errors unreadable with cursorline in default color scheme
I'll fix it 9 hours later. Sorry for top-posting because WAP only supports this. On 9/10/07, Nico Weber [EMAIL PROTECTED] wrote: Hi, `set cursorline` seems to override the background colors even for characters that are in group Error. With the default color scheme, this makes Errors unreadable: They are displayed with red background and white text, and the default cursorline color is a light grey. If the cursor is in the same line as the error, Errors are displayed with a light grey background and white text -- barely readable (tested on gvim/ubuntu and carbon vim/osx). Any ideas what could be done about this? Thanks, Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Announcing Eeedit - Vim plug-in for Eclipse.
On 8/31/07, David Anthony Terei [EMAIL PROTECTED] wrote:
Hi Adam,
Thanks for the feedback, just fixed the bug you mentioned then, Ill try to
get a new release out soon.
As for embedding, by default the plugin launches Vim externally, you need to
go into the preferences page ('Eeedit Preferences') and enable embedded
mode.
I've enabled the embedding mode but it also failed to embedding GVim
into my Eclipse but opened another detached window. My system:
Debian Lenny, default Eclipse (3.2), default GVim (7.1.058).
Best Regards,
David
On 8/30/07, Adam Gołębiowski [EMAIL PROTECTED] wrote:
On Wed, Aug 29, 2007 at 01:37:08AM +1000, David Terei wrote:
This project is in its very early stages, so far Vim functions pretty
much
as an external editor (although there's more then this going on behind
the
scenes). You can however if you're lucky enough to be on Linux and using
a
GTK2 build of Vim embed it into Eclipse. There is a patch under review
by
Bram for enabling support for this under Windows.
Hi.
I tried to use this plugin, but what I get is externally launched vim
(not embedded into eclipse), with an unhandled exception being thrown:
-
Trying to start vim
Server started and listening
Started vim
Connection established
AUTH changeme
0:version=0 2.4
0:startupDone=0
Exception in thread Thread-2 java.lang.NullPointerException
at
org.eeedit.vimplugin.VimConnection$6.handleEvent
(VimConnection.java:217)
at
org.eeedit.vimplugin.VimConnection.run(VimConnection.java:119)
at java.lang.Thread.run(Thread.java:619)
dispose()
close( true );
-
This is a `huge' gtk2 vim 7.0.241, built with +netbeans_ing feature
enabled. I am using eclipse-3.2.2 here.
Best regards,
Adam
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: patch 7.1.094
On 8/31/07, Georg Dahn [EMAIL PROTECTED] wrote: Do as I did: grab Bram's email, save as in EML format, and remove the headers. If (like me) you got it in 8bit Content-Transfer-Encoding, it's usable as is for input to the patch program. Or fetch it from CVS, as I always do. This is much more comfortable than patching. No, fetching patches from CVS is just a nightmare because CVS doesn't support changelist and every file is committed separately. :-) Best regards, Georg --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: patch 7.1.094
Hi Bram On 8/31/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Patch 7.1.094 Problem:When checking if syntax highlighting is present, looking in the current buffer instead of the specified one. Solution: Use buf instead of curbuf. Files: src/syntax.c [...] When will this patch be uploaded to the ftp? I'm waiting for it. Regards, Edward --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: patch 7.1.094
On 8/31/07, Tony Mechelynck [EMAIL PROTECTED] wrote: Edward L. Fox wrote: Hi Bram On 8/31/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Patch 7.1.094 Problem:When checking if syntax highlighting is present, looking in the current buffer instead of the specified one. Solution: Use buf instead of curbuf. Files: src/syntax.c [...] When will this patch be uploaded to the ftp? I'm waiting for it. Regards, Edward Do as I did: grab Bram's email, save as in EML format, and remove the headers. If (like me) you got it in 8bit Content-Transfer-Encoding, it's usable as is for input to the patch program. Yes I know I could grab it from this E-mail. But I'm afraid this may confuse my script a bit. So if it won't delay for too long, I'd rather wait for a while. :-) Best regards, Tony. -- ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of Camelot. King of all Britons, defeator of the Saxons, sovereign of all England! [Pause] SOLDIER: Get away! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug report: '%' jumps problem
Reporter id: chenkw
Community: newsmth
Hi developers,
Steps to reproduce:
Vim 7.0 has a problem jumping between matching brackets in the following case:
Foo()
{
// {
}
The % command jumps between the close bracket and the open one in the comment
rather than at the right beginning of function body.
Expect behavior:
The % command should jump between semantically matching brackets, such as the
pair around the function body in the above case.
Notice the correct matching is hilighted when cursor is on a bracket.
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 28 2006 23:02:04)
Included patches: 1, 3-4, 7-9, 11, 13-17, 19-26, 29-31, 34-44, 47, 50-56, 58-64,
66-73, 75, 77-92, 94-107, 109
Modified by [EMAIL PROTECTED]
Compiled by [EMAIL PROTECTED]
Huge version without GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist
+keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
+mksession +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm
-mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
-netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile
+python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
-sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static
-tag_any_white -tcl +terminfo +termresponse +textobjects +title -toolbar
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace
+wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
-xterm_clipboard -xterm_save
system vimrc file: /etc/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
fall-back for $VIM: /usr/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -pipe -Wall -Wp,
-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2-D_REENTRANT -D_GNU_SOURCE
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
-I/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -I/usr/include/python2.4
-pthread
Linking: gcc -Wl,-E -Wl,-rpath,
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -L/usr/local/lib -o vim
-ltermcap -lselinux -lacl -lgpm -Wl,-E -Wl,-rpath,
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -L/usr/local/lib
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE -lperl -lresolv -lutil -lc
-L/usr/lib/python2.4/config -lpython2.4 -lutil -lm -Xlinker -export-dynamic
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Make clean does not remove if_perl.c
On 8/25/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Suresh Govindachar wrote: make -f Make_ming.mak clean does not remove if_perl.c You are supposed to use: make -f Make_ming.mak -D PERL clean You also need to add the choices for GUI or not and debugging or not, otherwise the object files are not deleted or the wrong ones are deleted. It's a bit confusing. I think we should support off-directory build. It's really a pain for me. By the way, do we have any plan of switching to CMake? -- hundred-and-one symptoms of being an internet addict: 244. You use more than 20 passwords. /// 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 -~--~~~~--~~--~--~---
Re: vim-cocoa source code for GSoC final evaluation
Incredible! I'll borrow a Mac to try out your amazing work tomorrow. Thanks very much for your hard work this summer, Jiang! I think I should be ashamed that I've done nothing that I had promised for Vim this summer. How long will it take for this patch merging into the official version? On 8/21/07, Jjgod Jiang [EMAIL PROTECTED] wrote: Hi Bram, As stated by Google Summer of Code 2007 Final Evaluation Period Information, Monday, August 20th at 19:00 UTC is student Pencils down time. So I've created the following source code snapshot for you to check: http://vim-cocoa.googlecode.com/files/vim-cocoa-r94.patch This patch can be applied to vim 7.1.83. For complete build instructions, see: http://code.google.com/p/vim-cocoa/wiki/BuildInstructions There is also a compressed archive of Vim.app (including all binaries and runtime files): http://vim-cocoa.googlecode.com/files/vim-cocoa-r94.tar.bz2 I also created a tag in subversion: http://vim-cocoa.googlecode.com/svn/tags/gsoc-final-evaluation/ Code in http://vim-cocoa.googlecode.com/svn/trunk will be continue updated. At present, vim-cocoa has implemented most features the original vim on mac has with Cocoa framework. But it still lacks major features like toolbar and tabline. A lot of code came from Björn Winckler's MacVim implementation. Though in some low level details, me and Björn experimented different solutions, but his work definitely made my job much easier. Thanks a lot, Björn! - Jiang [1] http://groups.google.com/group/google-summer-of-code-announce/web/midterm-survey-information-2 --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: test64?
On 8/16/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Xiaozhou Liu wrote: Patch 7.1.071 adds test64 into src/testdir/. But it is not there as I browse the subversion repository below. Is there any problem or am I wrong? https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1/src/testdir/ Subversion always lags behind, between a few hours to a few days. Use CVS or patches if you need a bleeding edge version. Not always behind. As I remember, once, yes, only once, but it really did so, the SVN repository ran before the CVS repository. I admit that such situation rarely happens, but it really exists. -- Hit any key to continue does _not_ mean you can hit the on/off button! /// 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 -~--~~~~--~~--~--~---
Re: patch 7.1.066
On 8/12/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
Patch 7.1.066
Problem:When 'bomb' is set or reset the file should be considered
modified. (Tony Mechelynck)
Solution: Handle like 'endofline'. (Martin Toft)
Wow! Thanks very much for your wonderful work, Martin! I'm waiting for
this for months! Incredible fixing!
Files: src/buffer.c, src/fileio.c, src/option.c, src/structs.h
*** ../vim-7.1.065/src/buffer.c Mon Aug 6 22:27:12 2007
--- src/buffer.cSat Aug 11 16:56:57 2007
***
*** 502,507
--- 502,508
buf-b_start_eol = TRUE;
#ifdef FEAT_MBYTE
buf-b_p_bomb = FALSE;
+ buf-b_start_bomb = FALSE;
#endif
buf-b_ml.ml_mfp = NULL;
buf-b_ml.ml_flags = ML_EMPTY;/* empty buffer */
*** ../vim-7.1.065/src/fileio.c Tue Jul 10 17:09:51 2007
--- src/fileio.cSat Aug 11 16:56:57 2007
***
*** 654,659
--- 654,660
curbuf-b_start_eol = TRUE;
#ifdef FEAT_MBYTE
curbuf-b_p_bomb = FALSE;
+ curbuf-b_start_bomb = FALSE;
#endif
}
***
*** 912,918
--- 913,922
file_rewind = FALSE;
#ifdef FEAT_MBYTE
if (set_options)
+ {
curbuf-b_p_bomb = FALSE;
+ curbuf-b_start_bomb = FALSE;
+ }
conv_error = 0;
#endif
}
***
*** 1361,1367
--- 1365,1374
size -= blen;
mch_memmove(ptr, ptr + blen, (size_t)size);
if (set_options)
+ {
curbuf-b_p_bomb = TRUE;
+ curbuf-b_start_bomb = TRUE;
+ }
}
if (fio_flags == FIO_UCSBOM)
*** ../vim-7.1.065/src/option.c Tue Jul 24 14:57:16 2007
--- src/option.cSat Aug 11 16:56:57 2007
***
*** 7118,7123
--- 7118,7128
/* when 'endofline' is changed, redraw the window title */
else if ((int *)varp == curbuf-b_p_eol)
need_maketitle = TRUE;
+ #ifdef FEAT_MBYTE
+ /* when 'bomb' is changed, redraw the window title */
+ else if ((int *)varp == curbuf-b_p_bomb)
+ need_maketitle = TRUE;
+ #endif
#endif
/* when 'bin' is set also set some other options */
***
*** 10604,10609
--- 10609,10616
buf-b_start_ffc = *buf-b_p_ff;
buf-b_start_eol = buf-b_p_eol;
#ifdef FEAT_MBYTE
+ buf-b_start_bomb = buf-b_p_bomb;
+
/* Only use free/alloc when necessary, they take time. */
if (buf-b_start_fenc == NULL
|| STRCMP(buf-b_start_fenc, buf-b_p_fenc) != 0)
***
*** 10617,10623
/*
* Return TRUE if 'fileformat' and/or 'fileencoding' has a different value
* from when editing started (save_file_ff() called).
! * Also when 'endofline' was changed and 'binary' is set.
* Don't consider a new, empty buffer to be changed.
*/
int
--- 10624,10631
/*
* Return TRUE if 'fileformat' and/or 'fileencoding' has a different value
* from when editing started (save_file_ff() called).
! * Also when 'endofline' was changed and 'binary' is set, or when 'bomb' was
! * changed and 'binary' is not set.
* Don't consider a new, empty buffer to be changed.
*/
int
***
*** 10636,10641
--- 10644,10651
if (buf-b_p_bin buf-b_start_eol != buf-b_p_eol)
return TRUE;
#ifdef FEAT_MBYTE
+ if (!buf-b_p_bin buf-b_start_bomb != buf-b_p_bomb)
+ return TRUE;
if (buf-b_start_fenc == NULL)
return (*buf-b_p_fenc != NUL);
return (STRCMP(buf-b_start_fenc, buf-b_p_fenc) != 0);
*** ../vim-7.1.065/src/structs.hThu Jul 26 22:55:11 2007
--- src/structs.h Sat Aug 11 16:56:57 2007
***
*** 1453,1458
--- 1453,1459
#ifdef FEAT_MBYTE
char_u*b_start_fenc; /* 'fileencoding' when edit started or NULL */
int b_bad_char; /* ++bad= argument when edit
started or 0 */
+ int b_start_bomb; /* 'bomb' when it was read */
#endif
#ifdef FEAT_EVAL
*** ../vim-7.1.065/src/version.cSun Aug 12 15:24:05 2007
--- src/version.c Sun Aug 12 15:48:34 2007
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 66,
/**/
--
hundred-and-one symptoms of being an internet addict:
127. You bring your laptop and cellular phone to church.
/// 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
Re: Fixing bugs in Vim
Hi Martin and Bram, On 8/4/07, Martin Toft [EMAIL PROTECTED] wrote: Hi, I'm participating in Google's Summer of Code (GSoC) program, where my mission is to fix bugs in Vim. I have written a huge post about my work so far on my GSoC-blog: Do you think the trunk of the Svn repository will be a good place for storing those *bleeding edge* code? If anyone geeky or nurdy enough would like to try out the latest bugs fixing or would like to help doing some testing, they could check them out from the trunk. While the branches/vim7.1 will still be the latest stable version for average users. Sometimes (almost always, hehe) Bram tells me that he has changed something before committing a patch, and I don't backport those changes to the files on this site. I can do the backports for you, if you like. I will be a good IT supporter. :-) http://gsoc.martintoft.dk/ Enjoy :-) Best regards, Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGs6agEtBnr8BYnZ4RAhfQAKDqnkTzdOprjBHlJm52x7g+jFdYIACggDip f0+bVpeBWfMWw6en+vgDUFY= =DGJa -END PGP SIGNATURE- Regards, Edward L. Fox --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Fixing bugs in Vim
Hi Bram, On 8/4/07, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] In my opinion the Vim SVN repository is for the official version of Vim only. Adding things there that are experiments or patches that will later become official causes confusion. At first, the SVN repository contained only one top-level directory named vim7. Because the development of Vim is in pure linear mode, that is, without any branches. So I didn't add any trunk, tags or branches, as most of the other SVN repositories do at that time. But when Vim 7.1 began to Beta, many people complained for the none-standard directory structure so I added trunk, branches and tags. So far till now, the all operations I did to the trunk is just Merged from the latest developing branch. It's quite boring and makes no good to any one at all. I keep doing such useless job only because I'm still in hope that one day the trunk directory will be used by some intelligent developer. If such dream will never come true, do you think we should remove the trunk directory now? Waiting for your response... There are plenty of other places where you can make your experimental code available to others, in various forms. www.sourceforge.net and code.google.com are two examples. You can setup your own project for yourself or work together with a group. Well, I don't think I need to branch out into a new project. Firstly, I don't consider myself a competent developer to maintain such a big project. Secondly, I don't have enough time to do such a heavy job. Thirdly, if I had enough time and ability, I would rather join the Yzis team than branch out because the former is much more exciting. OK, I admit that I don't have such ability so I would just continue doing my own work here - supporting the intelligent developers without any more complaint. [...] Be In Peace, Edward L. Fox --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
