Re: The future of the Vim project
Thanks for taking this on Christian. I can't help much but let me know if there is something I might be able to handle. I advise making things as simple as possible and dumping "nice to have" features. I think you've got the Mercurial repo running on automatic, but while I love Mercurial, it's just one more thing to think about and I would dump it. Similarly, sorry but FTP should go. Surely Sourceforge is no longer needed? Currently https://vim.sourceforge.io/ tells me "The Vim website has moved, go to www.vim.org" which is all that's needed. It seems to be trying to do a redirect which is not needed. The Vim Tips wiki is inactive and obsolete but I put the news about Bram on the main page. https://vim.fandom.com/wiki/Vim_Tips_Wiki Re github procedures, please be very conservative and skip good ideas and anything else that adds to complexity. Instead, focus on small and almost-guaranteed-not-to-break changes with at least two trusted people checking each before going live. I think you suggested that. Perhaps in a few months after things have settled down, more adventurous changes could be considered. John Beckett > > -- -- 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 because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CALAuFy_cyMuEizfgxRhMthFfeA%2Bs3%3Du5Set39ZA4sBhdJEeLwA%40mail.gmail.com.
Problem using cgn to change a search hit when replacement includes hit
Thanks Christian for the excellent gn added in 7.3.610. However,
using Vim 7.4.972 I'm seeing this problem with cgn after search.
Put the cursor at beginning of line:
abc x def x ghi x jkl
Type /x and press Enter to find first x.
Type cgn"x" and press Esc to replace search hit with "x" (three
characters).
Press n to find next x then press . to repeat change.
Expected result:
abc "x" def "x" ghi x jkl
Actual result:
abc "x" def "x" jkl
The problem occurs when the search is for a single character,
and the replacement text ("x" above) includes the search.
The problem can also be seen by simply trying cgn on the
second x.
John
--
--
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 because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
RE: Google summer of code
Bram wrote: The Summer of Code is here again this year. If we want Vim to participate we need a few mentors and someone to organise the application. To be realistic, I won't have much time for this. I can help out where needed, but the bulk of the work will have to be done by you! Information can be found here: http://www.google-melange.com/gsoc/homepage/google/gsoc2015 The deadline for organizations to apply is February 20. I'm not sure I'm up to it but I could be an administrator. Christian has signed up as a mentor, and I think we would need at least one other. A mentor has to commit to follow at least one student, to encourage them, provide ideas, answer questions. Most importantly, a mentor has to check the student is sticking to a reasonable timetable of submitting work. The dev mailing list can be used for questions/discussion, but the mentor has to be available for more personal contact. The issue is serious: Google pays US$5500 to the student (if the mentor passes the student), and Google pays US$500 to the mentoring organisation for each passed student. ICCF? For a non-US organisation, Google needs a completed IRS form W8-BEN. I hope Bram can deal with that. The big problem is our ideas list: http://www.vim.org/soc/ideas.php Google does NOT want a bug list -- they want interesting and achievable projects that a good student could reasonably be expected to undertake. Vim was rejected for GSOC2012 probably because the ideas page was not sufficiently interesting. The following is probably a good model: https://www.mediawiki.org/wiki/Google_Summer_of_Code_2015 Any suggestions for the ideas page? John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: fixes to vim.org
Kartik Agaram wrote: He's referring to the link Plain text (by Yegappan Lakshmanan and Gavin Sinclair), which should probably be deleted. Bram: It looks like a few documentation changes are needed. *** http://vimdoc.sourceforge.net/ The first (Plain text) and third (Vim Help format) lines should be deleted from the following (and replace FAQs with FAQ). FAQs Plain text (by Yegappan Lakshmanan and Gavin Sinclair) HTML Vim Help format Perhaps grep geocities and remove anywhere else that occurs. Also, shouldn't the HTML link be changed to the page maintained by Christian Brabandt: http://vimhelp.appspot.com/vim_faq.txt.html In fact, the following should be replaced with a link to the above, or it should at least start with a prominent note that the above is the current FAQ. http://vimdoc.sourceforge.net/htmldoc/vimfaq.html *** http://www.vim.org/docs.php The FAQ should refer to Christian's page above? The vim.org tips archive... should be removed because the link is to a page which just says to see the wiki. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: New digraph
Christian Brabandt wrote: With the release of the Unicode version 7.0 yesterday, the rouble sign has been assigned U+20BD. It probably makes sense to update all the generated unicode data in the Vim source however. Can I hijack this to ask about U+2022 which is a nice bullet. One way to insert that in Vim is to execute the following (using :put=\u2022 fails because the quote is a comment): :let s = \u2022 :put =s Why is U+2022 not available as a digraph? I guess the answer is that it is not in RFC1345, but can we add it anyway? And rouble? The only bullets mentioned at :help digraph-table are U+2219 (^K Sb) and U+25D8 (^K Sn). John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: global command slow when clipboard=unnamed
It's a bit hard to see the excellent advice in that last post, so here it is: To delete (not cut) all lines matching pattern use: :g/pattern/d_ John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: Is Vim Applying for the 2014 Google Summer of Code? (was Is Vim Applying for the 2013 Google Summer of Code?)
Lech Lorens wrote: Would anyone else volunteer as a mentor? For GSOC2012, Bram needed another person to register with Google, and I was that person. I would be happy to do that again if wanted. I could act as a coordinator to check that things are ok for student(s) and mentor(s), and raise problems on the mailing list or with Bram if needed. However, while I have done some very minor fiddling with Vim's source, I would not be suitable as a mentor. Mentors do not need to register with Google, but they do need to be able to respond to queries from the student, and do a review of the work. Our application for GSOC2012 was not accepted, probably because the ideas page was too much like a bug list: the GSOC docs say bug lists are not acceptable. From memory, Google want to see an interesting ideas page that gives an impression that the student will do something worthwhile and will be looked after. http://www.vim.org/soc/ideas.php An anonymous user created these pages in March 2011: http://vim.wikia.com/wiki/Vim_GSoC_Application_Template http://vim.wikia.com/wiki/Vim_GSoC_2011_Ideas If anyone wanted, the above could be used to draft ideas (don't worry about it saying 2011; we'll rename it if necessary). However, the final ideas page should be at vim.org as above. An example of MediaWiki planning: https://www.mediawiki.org/wiki/Summer_of_Code_2014 John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Rgrep not working on vim 64-bit, win7
It looks like the wiki has had the answer since March 2013: http://vim.wikia.com/wiki/Script:311 That is linked in the top line at: http://www.vim.org/scripts/script.php?script_id=311 I have not used the plugin, but what is written at the above looks exactly what is needed to fix the error quoted earlier. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Rgrep not working on vim 64-bit, win7
lazureus wrote: I'm encountering some similar problems as Dariusz have seen however on the 64-bit Ubuntu. Trying to run :Rgrep from VIM I get following error message : Error detected while processing function SNR19_RunGrepRecursive..SNR19_RunGrepCmd: line 20: E484: Can't open file /tmp/vAgZSwX/0 You said it's a new version, but check the comments at the top of the .vim file. Does it say 1.11 as per Yegappan's advice? The above error can happen when a file name is not properly escaped. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Plugin manager
Ben Fritz wrote: Because my workplace's IT somehow blocks access to github and other places when using git tools but not when using a browser. I can download an archive from github when I point my browser to the project webpage but git clone/fetch/pull all fail. You know about $http_proxy (or some other method of telling the tool about your proxy server)? John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Plugin manager
Ben Fritz wrote: You know about $http_proxy (or some other method of telling the tool about your proxy server)? Nope, never heard of such a thing. But I actually never use git except for getting Vim plugins. At one point I could access Hg and git repositories just fine, but not SVN. Sure, and it's not worth spending time on complex networking issues when you don't ned to. However, you are almost certainly behind a proxy server, and you might like to bear in mind that each application wanting to access the outside world needs to be configured with knowledge of the proxy. Many applications with roots in the Unix world use an environment variable like the above for that, but each application has its own procedure. For example, TortoiseSVN probably has a Settings option on the File menu, and proxy info can be set there. On a company network, most people do not need to configure their web browser because company wizardry has either configured it, or has set up a mechanism whereby the browser can discover the proxy. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Problem with Corel copyright
Bram Moolenaar wrote: I got pointed at a copyright notice in the $VIMRUNTIME/vimlogo.eps file. That's because the file was generated by Corel Draw and includes some stuff apparently written by Corel. To avoid a discussion about whether distribution is OK, perhaps someone can take the Vim logo and generate an .eps file with another tool, which does not have this problem? If not I'll delete the file. What is the source? The following looks good, but I think it is slightly different: http://commons.wikimedia.org/wiki/File:Vimlogo.svg It's easy to open an svg in Inkscape and save as eps, but I don't know whether that has any unfortunate side effects. Someone who knows a bit about Inkscape and eps might comment. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: setpos() and up = wrong position
Dimitar DIMITROV wrote:
Now try :ec getpos('.') - [0, 4, 17, 0]
Move away and :call setpos('.',[0,4,17,0])
If you use up down k or j you will not move just
above/below the char but in some weird location
Say the cursor is in column 20, then setpos() is used to jump
to [d], then k is pressed.
The result is that the cursor goes to column 20. That is
possibly not very helpful, but it's compatible with :help k:
The first two commands [k and j] put the cursor in the
same column (if possible) as it was after the
last command that changed the column
In other words, calling setpos() is not regarded as a command.
John
--
--
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 because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Glitch in msvc2010.bat
I wanted to update our tip[1] on building Vim in Windows with Visual Studio to use VS 2012 Express, as well as VSE2010. While doing that I noticed that there is a double percent (%%) in two batch files, and I'm pretty sure it is wrong. The extra percent is ignored, so nothing bad happens, but if someone would confirm my conclusion, Bram may want to replace %% with % in src/msvc2008.bat src/msvc2010.bat For msvc2010.bat, the line is: call %VS100COMNTOOLS%%vsvars32.bat but it should be: call %VS100COMNTOOLS%vsvars32.bat I have temporarily abandoned my plan to update the tip because VSE2012 does not include Win32.mak, and after following some advice about getting that file with the SDK, I now have warnings about conflicting definitions in the Windows headers (nothing to do with Vim, and harmless, but very irritating). I'll try to sort that out another time (I'm wondering if I have a mixture of x86 and x64 headers, and whether the problem is due to that). [1] http://vim.wikia.com/wiki/Build_Vim_in_Windows_with_Visual_Studio John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: www.vim.org is down
Bram Moolenaar wrote: Yes, the database appears to be down. They upgraded the project recently, but I have no reason to assume this is related. Please check the sourceforge site for any known problems. Or file a support ticket. I'm afraid I don't have time right now to look into it. The database is still there because I'm currently looking at it through the phpMyAdmin web interface (admin only access). I can connect to the database and see the tables as normal, and can run a SQL query to see an individual script. Standard web browser access to a script like: http://www.vim.org/scripts/script.php?script_id=231 shows error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) Bram reported this same error in February 2011: https://sourceforge.net/apps/trac/sourceforge/ticket/17514 and the solution was to change $DB_HOST to mysql-v. However, that was done two years ago, and I cannot see any indication on Sourceforge that a change to MySQL has occurred, and I can't find anything relevant in Google. I'll poke around some more. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: www.vim.org is down
Bram Moolenaar wrote: Please check the sourceforge site for any known problems. Or file a support ticket. I've poked around and can't find anything, so I have filed a support ticket: https://sourceforge.net/p/forge/site-support/3872/ John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: www.vim.org is down
The vim.org problem has been fixed by Sourceforge. However, my checking of some recent changes to the vim.org database shows that vim.org was scanned by someone with Acunetix Web Vulnerability Scanner. That was used to generate at least 124 user accounts, including text fields intended to probe for bugs that might be exploited to break in to the system. It will take me a few days to think about what to do. After talking with Bram, I'll delete the junk accounts. To save people the nuisance of downloading junk scripts, I have deleted scripts 4555 to 4566 inclusive, and the user who created them, and the script downloads. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: [patch] Move base Windows support to WinXP
Bram Moolenaar So how about this: 7.4.000 will be released with MS-Windows binaries that still support the old systems. Once it's out and it looks OK we drop support for older systems. That way 7.4 is what needs to be used for old systems. It includes a lot of bug fixes since the last binary release. And then 7.4.001 and further can add stuff that is not possible when building for the older systems. That's fine for experts, but very confusing for everyone else. It would be far better to have 7.3.999 (or whatever the final number is) be the last version that runs on older Windows. The official binaries normally are not updated, but why not make an exception in this case and issue executables for 7.3.999 with a note that it is the last version that runs on Windows older than XP. People would find it a lot easier to understand that 7.4.x is the new system, and that 7.3.x was the last that supported old systems. I haven't upgraded Vim for a while, but I assume Vim still displays 7.3 for :version, with the included patches on a separate line. Standard users would not understand what is meant by 7.3.0 versus 7.3.1. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: [patch] Move base Windows support to WinXP
Roland Eggner wrote: Prior to dropping support for w2k please consider: (1) w2k is known to be the least faulty OS version released by its vendor so far, because the phrase based on NT was a lot more than just an advertising, the development history of this OS version differed significantly from all other OS versions of this vendor (2) when running as kvm or qemu guest, w2k yields best performance among all OS versions of this vendor For this two reasons IMHO support for w2k remains useful, even more than a decade after release of w2k. Bram (I assume) would prefer to support everything, and not drop Windows 2000 or anything else. However, the proposal is to start using certain features that are only available in Windows XP and later. Supporting an older system would require complex compile options and a bunch of testing. All that makes developing Vim harder and more fragile. Why would someone who does not want to upgrade their operating system want to upgrade their editor? W2k is not safe to use on the Internet, unless in a very restricted mode, and the current Vim has few bugs that matter, and has plenty of features, so upgrades should be strictly optional. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: [patch] new cpo setting to make n/N search in the same direction
Bram Moolenaar wrote: This is what the attached patch enables, by adding the new flag 'N' to the 'cpo' setting. Well, instead of adding an option, what about: :noremap n /CR :noremap N ?CR The option would be much better! I sometimes map n and N to add zz so the hit is in the middle line, or for various other things, and while I suppose one could add workarounds, I repeatedly find myself cursing the confusing n/N behaviour after using # to search backwards. I have used it a thousand times, and I still find myself going the wrong way, and that breaks my train of thought in the middle of a complex piece of code. Also, when I do press the right key, it takes extra brain power (now let's see, is it n or N this time?), which again is distracting. Another irritation about the unexpected n/N behaviour is that it is impossible to easily restore the screen to how it was if the unexpected search scrolls the window. I can press Ctrl-O, or search the right direction, but I can't restore the window to how I had carefully arranged it (so the piece of code under consideration is visible). I don't bother with many customisations, but this one would be permanently on for me. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: [patch] new cpo setting to make n/N search in the same direction
Gary Johnson wrote: Won't that break any plugins that use 'n' or 'N' after a reverse search? I agree that the proposed behavior would be less confusing than the current behavior, but changing it in any way that would break existing scripts seems like a non-starter. There are times when moving forward requires breaks from the past. While various scripts might fail, the people who choose to switch on this option can deal with that. Vim should not default to setting a new option that would break scripts, but people can choose to turn it on. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: [patch] new cpo setting to make n/N search in the same direction
Michael Henry wrote: I've always been confused by the behavior of n and N after backward searches. The only work-around my brain can handle is to simply avoid backward searches entirely; instead, I search forward and press N. Agreed. That's usually how I resolve the problem as well. However, sometimes I take the trouble to scroll everything to just how it is needed (so some critical portion of code is visible). Pressing * to search forwards, and then N followed by another N to go backwards might scroll the window, and that would be a great distraction. Worse is when I stop to think if I press * will the window scroll?, because by the time I've pondered that, and whether some tweaks to my setup might overcome my difficulty, I have forgotten what I needed to do in the code I was looking at. John -- -- 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 because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Any spam from ad...@139.com at vim_dev?
Gary Johnson wrote: Does anyone posting to vim_dev receive similar spam? I used to get this but I don't any longer. I still have two of them in my inbox, probably the last two I received. They're dated August 1 and 2, 2012. Thanks, but I need to know if you are sure the spam was as a result of you posting to vim_dev. The spam email arrives 24 hours after you posted, and the body of the message quotes the subject of your message (it's about the only English text in the message, and is visible even when viewing the message as text, and not in html). Since you post in both vim_dev and vim_use, it's possible the spam you received is due to vim_use. John -- 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: Vim patches page link is broken
Bram Moolenaar wrote: Bram: Do you want me to remove the Other Vim patches section from [1] (and email you when done)? I don't think the list was established elsewhere, so it needs to be removed? I thought we copied the patches to somewhere... If we don't have this list somewhere I think we should delete that section. Let me know if you have an update for the file. You and I exchanged a couple of emails in April 2011 around the time the Google Groups page with the patches was closed down. I suggested putting the patch list on the Vim Tips wiki (which is maintained so junk edits are removed, and which would allow people to update the information without requiring a vim.org manager to edit the html at vim.org). You did not seem to favour that idea, and said that we should add any information that was on the removed pages to vim.org, unless it's already there. I'm not aware of anything being done at vim.org. The chain of links a reader of the mailing list might follow is: At the first of these, About this group goes to the second: http://groups.google.com/group/vim_use http://groups.google.com/group/vim_use/about Which says See http://www.vim.org/maillist.php for information on this group. The sidebar download link on each vim.org page goes to: http://www.vim.org/download.php Patches Include the latest improvements has link to: http://www.vim.org/patches.php That page has a section on Other Vim patches with a link to the vim_dev page that no longer exists. Please say what you prefer now: 1. Put the patch list on the wiki; link to that from vim.org/patches.php 2. Replace the Other Vim patches section at vim.org/patches.php with the list of patches. 3. Put the patch list on some other vim.org page such as vim.org/unofficial.php Link to that from vim.org/patches.php I'll do any of the above, or something else, if wanted (and would post an update here, and directly email Bram if he does not notice the post). John -- 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: Vim patches page link is broken
So8res wrote: On the vim patches page [1] the link to vim_dev mailinglist patches [2] is broken. More generally, where should such website bugs be reported and how are they fixed? [1] http://www.vim.org/patches.php [2] https://groups.google.com/group/vim_dev/web/vim-patches Thanks, reporting vim.org problems here is good, or direct to Bram, or direct to me and I will arrange with Bram. Bram: Do you want me to remove the Other Vim patches section from [1] (and email you when done)? I don't think the list was established elsewhere, so it needs to be removed? John -- 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: Suggestion to take more advantage of GUI elements
Hans Tovetjärn wrote: My knowledge is rather limited when it comes to C so it's difficult for me to estimate how much effort introducing something like this would take (which is part of the reason for me asking - curiosity). As Ingo mentioned, any GUI feature is likely to be resisted because there are so many issues with higher priority, and Vim (and gvim) is primarily used by people interested in doing things with text (people who are not focused on good looks except in whatever it is they are producing). Whenever I asked more experienced people about whether I should use GVim or Vim the majority suggested the latter, mostly because using a “proper” terminal would provide much of the same functionality found in GVim. I was once like that, and there is no doubt that one of Vim's greatest strengths is that you can use it to do clever things via a remote shell that only supports a terminal. However, for use on a local computer, gvim is the way to go IMHO. I’m not saying GVim is bad, I’m asking - could Vim allow for taking more advantage of graphical toolkits? Note that I’m not asking for “fancy GUI” features (directly). I’m asking if Vim could allow for others like the MacVim and vim-qt developers to create a “fancier” GUI. Vim is written and managed by Bram Moolenaar (with many other excellent contributions). Björn Winckler manages MacVim. Anyone can create a patch to add a feature, but for that feature to be accepted into the main distribution, there would need to be a really good reason related to fixing a problem, or adding something important. Even 10 new lines of code presents a problem in added complexity and testing requirements, particularly given the wide variety of systems that Vim runs on. You are correct that a design where customisable skins are available would be nice, but it's not going to happen. John -- 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: Suggestion to take more advantage of GUI elements
Andy Wokula wrote: If it's just about the size of the LineNr font, you can have it changed: :hi LineNr font=XXX where XXX is a 'guifont' argument, :set gfn? Amazing! That works, although in a quick test it appears that the line number characters occupy the same width and height as normal text characters (that's understandable as it is how Vim works, I think). One way to determine the required XXX value is to use the Edit menu to select a wanted font (for normal text), then use the following to insert the name into the current buffer (it is XXX): :put =gfn John -- 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: does .= have advantage?
Bee wrote: These do the same thing: let @/ = @/ . pad[c] let @/ .= pad[c] Is there an advantage (speed? resources?) to use one rather the other? Things like += and .= are mainly a convenience for comprehension. Using += the LHS is mentioned only once (LHS += RHS rather than LHS = LHS + RHS), and mentioning something once only is easier to understand (if the programmer is familiar with the operator). There may be some theoretical efficiency advantage of one over the other, but that is inconsequential. John -- 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: GVim for Windows: Save / :w operates in non-standard way?
sfosparky wrote: + IF one uses one of Flare's internal GUI editors, AND one also uses GVim for Windows to simultaneously edit the same file, THEN Flare gets confused I am not at all surprised by that! One BIG problem is that the user (you) is also sure to get confused at some critical time (when editing under stress), and you will do something that ends up losing work. The others are probably working because they overwrite the file in place. Vim defaults to a more robust strategy: it renames the original file, then writes to the name of the original file, then renames everything, then decides what to do with the old file (there is an option to keep it as backup). Flare would be looking in the original file, and not in the file that now has the same name. It's a long time since I have looked at the options for this, and I can't find a quick reference. Someone will add details. John -- 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: inputdialog() should use cancel value parameter
I don't know, but a short problem description follows.
In gvim, the following shows cancel if press Esc to cancel.
:set guioptions
:echo ''.inputdialog('Enter text ', 'default', 'cancel').''
But the following shows if press Esc to cancel.
:set guioptions+=c
:echo ''.inputdialog('Enter text ', 'default', 'cancel').''
According to ':help inputdialog()' both should give cancel.
Why is there a difference?
John
--
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: histdel() and .viminfo
Bee wrote:
I tried to delete all search history using:
:call histdel('/')
This is a duplicate of your message in vim_use.
Please do not post about the same topic here, as that just
causes confusion. Any replies should be at vim_use.
John
--
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: Advice on debugging a crash?
Jonathon Merz wrote: (I don't have access to Visual Studio unfortunately) It's pretty easy to install the free Express version, see: http://vim.wikia.com/wiki/Build_Vim_in_Windows_with_Visual_Studio Debugging would require using the GUI which requires registration (if used after the first 30 days). I haven't worked out exactly how to use it to debug properly, but I did get it going by building with: nmake -f Make_mvc.mak debug=yes gui=no and using VCExpress to open vimd.exe (then File, Open to open source files and set breakpoints etc). John -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Here are some thoughts for a group-managed repo. It must be simple for the group managers, and for file maintainers, and for Bram. It must also be simple for anyone to report a problem or make a suggestion. It should be similar to the existing Vim repo, and Mercurial should be available just as for the Vim repo. It should not alienate an original maintainer who is responsive to requests but who might not want to participate in a utopian group-managed scheme. Flexibility is required. For example, Chip Campbell might maintain the master copy of his plugins, and change requests would be by email request direct to Chip, and he would send updates to the group (not sure how). Anyone might send a comment or update to Bram, and he could handle that by sending it to the group for standard processing. The Vim repo is (first URL is a 301 redirect to second): http://vim.googlecode.com/ http://code.google.com/p/vim/ How about setting up an independent repo (not a clone) at http://vim-runtime.googlecode.com/ Code license: GNU GPL v2 The repo would contain directories like: vim-runtime +--plugin +--syntax Using 'vim-runtime' for the root might help reduce confusion with the 'runtime' directory in the Vim distribution. Subject to what the original file maintainer wants, the email address in a file would be vim-...@vim.org (that could be instead of the original maintainer, or in front of, or after, or not present -- as wanted by the original file maintainer). I assume the above scheme would allow approved members to use Mercurial to push commits. Has anyone tested that to see what happens? Each member needs a Google account? Ben Fritz has pointed out that a second independent repo could be created (vim-runtime-dev?) where any maintainer or other interested party could be given access for hg push. Then reviewers could pull changes into the stable vim-runtime repo. Ben mentioned that if a Google code repo is a clone of another, the clone cannot have a second committer. So, each repo would have to be fully independent. A second repo could happen later, when there was a demonstrated need. John -- 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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
What directories should the group manage? A possibility is below, although it may be too ambitious. It shows all first-level directories under runtime, with some to be managed by a group, and the remainder run directly by Bram. The files in 'runtime' would NOT be part of the group repo, but all files in each listed directory (and subdirectories) would be part of the group repo. runtime (group) +--autoload +--colors +--compiler +--ftplugin +--indent +--keymap +--lang +--plugin +--syntax runtime (Bram) +--doc +--icons +--macros +--print +--spell +--tools +--tutor John -- 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: home_replace() does not work with short path name on windows.
Bram Moolenaar wrote: What sign of modifier do you want against :8 ? :l ? Or new function? Currently :p turns any path into a full path, so that when two names are expanded with :p they can be compared to find out if they are equal. Except for symlinks, that requires using resolve(). So we could change :p to also expand 8.3 names to their full name, and add a new modifier that does not do that. How about :f, for Full name. Is that needed? If :p (on Windows) always produced the expanded long name, then :p:8 could be used if someone wanted the short full path. I can't see a reason someone would need an 8.3 name expanded to anything other than its full long path (with :p), or its full short path (with :p:8). At any rate, :f does not sound a good mnemonic for short. John -- 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: home_replace() does not work with short path name on windows.
mattn wrote:
If :p (on Windows) always produced the expanded long name, then
:p:8 could be used if someone wanted the short full path.
No.
:echo fnamemodify('C:\Program Files', ':8:p')
C:\PROGRA~1
If there is a problem, please spell it out as the above is
correct.
I can't see a reason someone would need an 8.3 name expanded to
anything other than its full long path (with :p), or its full short
path (with :p:8).
What we want is full long path. Currentl, :p don't return
long full long path.
That's why I said *if* :p always produced the expanded long
name, then :p:8 would be all that was needed to produce the
equivalent short name.
If :p produced the expanded long path, would there be a need for
any further changes? Why?
John
--
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: Does it still make sense to have per-file/-type maintainers? [Was: Re: Added support for spell checking in runtime/syntax/ocaml.vim]
Kazunobu Kuriyama wrote: As a maintainer of a few runtime files, I have something to make sure of: Are there any changes for the current maintainers in what they observe--policy, obligations, or something similar to those, to maintain the runtime files they are in charge of? Nothing is definite, but I don't think so. What would be different (I think) is that a maintainer would send updates to someone or something other than Bram. The group maintainers would review the change and periodically notify Bram that updates were available. He would then incorporate them into the Vim distribution, presumably after his own review. John -- 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: Added support for spell checking in runtime/syntax/ocaml.vim
Dominique Pellé wrote: Yes. Maintainers were in CC of the emails. But perhaps I should write to the maintainers only to avoid sending too many emails to vim_dev (still more of those simple patches to come...) There is no good way to do this except to email the maintainers only ... wait, try again ... repeat. If get a positive response, good. Otherwise, find a volunteer to take over maintenance! That's too much work for what you are doing, but Bram cannot take patches like these because the maintainer might later send an update to Bram, but the maintainer failed to receive, or failed to process, your email. So the later update could easily remove your patch. John -- 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: Remote Motif X11 gvim on windows using Xming ( copy cut ) ClipBoard
Bovy, Stephen wrote: I have tried using this source $VIMRUNTIME/mswin.vim But I cannot get the copy and cut to put anything on the clipboard First step is to check output of :version to see if you have +clipboard (feature supported) or -clipboard (not enabled during build). I do not know anything about your environment but simple checks would be, in another application, to copy something and to select something (leaving it selected). Then in Vim use commands like: +p *p John -- 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: Remote Motif X11 gvim on windows using Xming ( copy cut ) ClipBoard
Bovy, Stephen wrote: When I use a Different X-Window Server this strange esoteric problem completely disappears I'm glad you have fixed the issue but for the future please use the customs of this mailing list. Your last message includes five copies of the standard email footer which includes: Do not top-post! The procedure should be: - Quote a small (relevant) part of the message you are replying to. - That is, DELETE unimportant stuff. - Put your text underneath. John -- 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: incorrect description on how to subscribe to lists on http://vim.org
Žroutík wrote: I was trying to subscribe to the vim-dev list by email. Therefore, I sent an email to vim-dev-subscr...@vim.org (see below in the header of the original message) -- as requested at http://www.vim.org/community.php My email was delivered, but the subscription was unsuccessful (due to Joining via email is disabled for this group). Strange. I don't see any settings that control the above in the management area for vim_dev. However, using Google to search for the Joining via email is disabled for this group error shows that the same problem is being discussed (with no resolution that I could see) on other groups. Has anyone joined one of the Vim lists recently by email? When? What address did you email? John -- 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: Request to link Japanese translation
Taro MURAOKA wrote: We holds translated Vim's documentation in Japanese at here. http://vim-jp.org/vimdoc-ja/ Please add a link for it to http://www.vim.org/translations.php Or who are best to ask it? I added the information. You may need to reload the page in your browser (flush cache) to see the change. Two pages listed at the translations link above fail to load: Italian http://it.tldp.org/vimhelp-it The connection to the server was reset while the page was loading. Polish http://skawina.eu.org/mikolaj/podrecznik.html Forbidden You don't have permission to access /mikolaj/podrecznik.html on this server. John -- 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: setting refresh: 'always' in a completion function breaks the dot ('.') register
Val Markovic wrote: Any help, advice or guidance would be greatly appreciated. Someone needs to spend quality time: 1. Working out the problem is. 2. Fixing problem. You could help point 1 by giving a brief indication of what the problem is. Yes, the subject line tried to do that, but a few lines with a simple demo and a description (what does break mean?) may help. John -- 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: set hlsearch not running from function
smu johnson wrote: In case anyone is curious, I'm trying to simulate the regular searching slash key to be used to only search and highlight, but _not_ jump to the next match. Some good ideas are here: http://vim.wikia.com/wiki/Highlight_all_search_pattern_matches John -- 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: copy/mkdir/rmdir under windows
Charles Campbell wrote:
I think it would be best to NOT test when under Windows
because there is no reasonable way to do so. If there were a
reasonable way for a script to store persistent data, you
could consider displaying a message the first time one of the
commands is invoked, letting the user know that netrw will
use 'move', 'mkdir', 'rmdir' as a default (lot of hassle and
potentially fragile code!).
I suppose that I could test for executable(cmd), and assume
that move/rmdir/mkdir will work if cmd is on the path. Is
that right?
It is correct that if Vim uses cmd (which would run cmd.exe) to
execute a command, then cmd would perform the following commands
itself: start move copy md mkdir rd rmdir (on a standard Windows
after Win9x, there is no executable with these names).
Win9x used command.com and not cmd.exe as the shell, while I
believe all Windows systems in the NT family (to present day)
provide cmd.exe. I do not know if the newer shells in recent
Windows replace or extend cmd.exe.
The problem is that (I think) Vim uses the 'shell' option to
determine what shell to use to run :! commands, and some users
would change that to some quirky shell like 4NT or a host of
others. If netrw checks for 'cmd', it could conceivably fail the
check but 'move' and 'copy' and so on _would_ actually work
because the user's shell does support those commands.
I think the best thing would be to just run the command (like
'move') and on the first error display a comprehensive error
indicating that the move failed and things the user might do.
All you can do is hope that v:shell_error will be nonzero when
an error occurs.
I wrote the following to check executable():
function! CheckExec()
for c in split('cmd start move copy md mkdir rd rmdir')
echo c . ' : ' . executable(c)
endfor
endfunction
call CheckExec()
The results on Windows XP are:
cmd : 1
start : 0
move : 0
copy : 0
md : 0
mkdir : 0
rd : 0
rmdir : 0
Each of the above is a valid command executed by cmd.exe.
However, when Vim sees :!start xxx, Vim executes xxx
asynchronously (Vim does not run 'start').
Re your other message: I noticed the extra 'endif' in netrw.vim
when using the 'gx' command (it failed with a syntax error).
Warning to anyone who tries that: save your buffers first
because the resulting error messages are REALLY confusing.
John
--
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: copy/mkdir/rmdir under windows
Charles Campbell wrote: So, how best to make this work? I was thinking if has(win32) || has(win95) || has(win64) || has(win16) if executable(cmd) let g:netrw_localmovecmd= cmd move endif endif No, as Ben said it would have to be cmd /c move and that's just going to cause trouble somewhere. Someone could have another shell which is very likely to implement those basic commands, and then there would be unnecessary confusion. I think it would be best to NOT test when under Windows because there is no reasonable way to do so. If there were a reasonable way for a script to store persistent data, you could consider displaying a message the first time one of the commands is invoked, letting the user know that netrw will use 'move', 'mkdir', 'rmdir' as a default (lot of hassle and potentially fragile code!). I wouldn't bother doing anything about it, but FYI line 3837: if executable(start) is not needed because on Windows, :!start xxx means that Vim should run xxx asynchronously (Vim does not try to run start, it starts another process to run xxx). You probably saw the other message that the current Mercurial Vim source has a broken autoload/netrw.vim (duplicate endif at line 327). I didn't mention that because I saw it is fixed at http://www.drchip.org/astronaut/vim/index.html#NETRW and guessed that Easter had delayed a fix to the repo. but I haven't had any luck compiling a windows-style vim there lately (so its a cygwin-based version). This tip works: http://vim.wikia.com/wiki/Build_Vim_in_Windows_with_Visual_Studio John -- 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: copy/mkdir/rmdir under windows
John Beckett wrote:
letting the user know that netrw will
use 'move', 'mkdir', 'rmdir' as a default
I mean 'copy', not 'move'.
I wouldn't bother doing anything about it, but FYI line 3837:
if executable(start)
I just thought about this and checked. There is no executable
'start', and Vim's executable('start') returns 0.
Like copy, start is implemented by cmd.exe, so I would recommend
omitting the test and assuming start is available on Windows
(but actually, it will not be used, as mentioned in my last
message).
John
--
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: Vim compilation with --enable-pythoninterp on Ubuntu
Senthil Kumaran wrote: I am trying to compile vim from source with python interpreter on Ubuntu. I have installed the dependencies for vim, installed python2.7-devel and python2.7-dbg packages on Ubuntu and do the configure step like this ./configure --enable-pythoninterp --with-python-config-dir=/usr/lib/python2.7/config The config directory does contain the config.c file. The make step fails with the following error. objects/py_config.o:(.data+0xcc): undefined reference to `initcStringIO' objects/py_config.o:(.data+0xd4): undefined reference to `initcPickle' objects/py_config.o:(.data+0xdc): undefined reference to `initzlib' I am experimenting with this at the moment so the following is based on floundering around, not actual knowledge, however I have recently built Vim 7.3.494 on Fedora 16 with Python 2.7. I used following, then make: ./configure --with-features=huge --prefix=$HOME/opt \ --enable-pythoninterp \ --with-python-config-dir=/usr/lib/python2.7/config src/Makefile includes: objects/py_config.o: $(PYTHON_CONFDIR)/config.c The file /usr/lib/python2.7/config/config.c does not contain any of the identifiers that give the errors above, so my guess is that you have a mixture of files from Python 2.7 and some earlier version. John -- 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: Start Working Today
Marc Weber 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? Of course it's spam. I have already notified Bram and deleted the original post from the Google Groups archive. I don't think there is anything useful that can be said in public. I doubt if spammers bother to read this list, but there would be no value from a public discussion about possible counter measures. John -- 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: Start Working Today
Marc Weber wrote: It does not talk about the kind of employee they are looking for (coder, artist, ..) I had better warn any naive readers: Never believe anything you read on the Internet, including emails that appear to come from Bram. Spam can be spam (it is genuinely promoting something). Spam can be meaningless (someone is just trying a demo). Spam can be phishing (to get suckers to take the bait in the spam and perform some action based on its content). Spam can be MALWARE. It might contain a link which, if clicked, would exploit vulnerabilities in your browser, and install a virus on your computer. Spam can be subtle. It might not contain a link, but might provide sufficient information so that you put something like example.com into the address bar of your browser, and that is the site which delivers the malware. No doubt there are lots of other things bad things that spammers can dream up as well. John -- 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: DrChip's website is back!
Charles Campbell wrote: You may find it at: http://www.drchip.org/ Thanks Chip. I have updated all the pages at the Vim Tips wiki which used to refer to the old website (if anyone looks for that in 'Recent changes'), click 'Show bots'). John -- 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: Google summer of code mentor
Ben Schmidt wrote: I need a backup administrator, it's mandatory for applying. I can act as a backup if necessary, too. I've been a bit quiet recently, but if direct questions or a direct task were in front of me I'd be able to help out. Thanks Ben. If Bram is not around and I have some problem put to me where I don't feel confident providing an answer, I will email you directly, or possibly the mailing list if it's a more general issue. John -- 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: Google summer of code mentor
Bram wrote: 1. Write tests for the regexp engine, so that we can finally use NFA. 2. Fix bugs and review patches 3. Fix bugs and review patches 2. and 3. should be able to work together, so that the mentor (me) does not have to spend too much time on reviewing patches. To be able to apply I need a backup admin. That is someone who can take care of the SoC when I am not available. Any volunteers? I would not be much use with tricky technical issues as I have only scratched the surface of the source. However, if it's any use I could handle generic issues, or could prod a SoC person regarding progress, or guide them to formulate a specific question to put to others if help were needed. John -- 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: EasyVim on windows
Robert Melton wrote: Wow. You can not be seriously linking a two our old executable and claiming it contains a lot of plugins. The only thing on that github is 3 executables and a blank README. Not to mention you have no other github activity, at all. Thanks Robert, you are right of course. If I had noticed the message waiting for moderation I would have removed it. I have put the user back on moderation (so a manager has to review their next post before it is sent to the list). The Vim mailing list is a gentle place where naive readers might imagine that it would be a good idea to click a link to a random executable, but we should not encourage such behaviour. John -- 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.3.443
Edwin Steiner wrote:
I found it most reliable for testing to write a simple C
program that prints its argv[] array.
I did that a few years ago, and in case anyone is interested,
here is what I used.
/* Echo arguments in one line.
* John Beckett 2007/05/25
* This is to see what is passed to program by Vim system().
*
* If name of program contains echoarg, program runs
* and terminates.
* Otherwise, program prompts user to press Enter so the window
* can be seen, for example, if invoked with Vim system().
*/
#include stdio.h
#include string.h
#include windows.h
#define MAXLN 2000
int main(int argc, char *argv[])
{
char buf[MAXLN+10+1] = ;
char *p = buf;
int j;
int wait = (strstr(argv[0], echoarg) == NULL);
printf(Raw command line:\n%s\n\n, GetCommandLine());
printf(Arguments passed to argv:\n);
for ( j = 0; j argc; ++j ) {
if ( (p + strlen(argv[j])) (buf + MAXLN) )
break;
p += sprintf(p, [%d %s], j, argv[j]);
}
printf(%s\n, buf);
if ( wait ) {
printf(\nEchoarg will terminate when you press Enter\n);
getchar();
}
return 0;
}
John
--
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: Vim cannot see several *.com files in system directory
Ben Fritz wrote: :r !dir C:\WINDOWS\system32\*.com Volume in drive C is Local Disk Volume Serial Number is EA9A-15F2 Directory of C:\WINDOWS\system32 02/18/2007 06:00 AM29,696 format.com 02/18/2007 06:00 AM16,384 more.com 2 File(s) 46,080 bytes 0 Dir(s) 181,772,042,240 bytes free I stopped following Windows a few years ago so I do not know what is going on, but that looks like it's part of the privilege escalation security procedures in Windows. I suspect that since gvim.exe is not signed, Windows runs it with some reduced privilege and a fake view of certain directories (even if the user is in Administrators). John -- 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: XTerm Mouse Support on z/OS ??
Bovy, Stephen wrote: When I use the mouse with vim and putty on z/OS the left mouse-click scrolls the buffer down The term type is xterm Please bottom post on this mailing list. Quote a small (relevant) part of the message you are replying to, and put your text underneath. Delete text that is not needed to understand your reply Note the footer below each message (Do not top-post!). The current threads should stay here, but the vim_dev mailing list is for issues relating to the development of Vim. Please post any future general questions at: http://groups.google.com/group/vim_use John -- 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: Where did the unofficial patches go?
Peter Valdemar Mørch wrote: I'm looking for patch #15: Correctly indent wrapped lines in particular. Google closed the ability for groups to have web pages or files. That is, they deleted the patches list. I had a discussion with Bram about whether we should put the list somewhere like the wiki, but there did not seem to be a pressing need and nothing occurred. I took a copy of the pages before they were deleted. The text for patch #15 was as follows (I do not know if the following URLs are still accurate): Correctly indent wrapped lines Author: Václav Šmilauer Status: Almost complete, needs more testing Site: http://marc.info/?l=vim-devm=118053273403321 patch for Vim 7.0 (tested with 7.2) See also: http://groups.google.com/group/vim_use/browse_frm/thread/68310d1b7d0bba0b/ http://marc.info/?l=vim-devm=117916431219780 Display soft-wrapped lines flush left at the proper indentation level if 'linebreak' is set. John -- 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: Update for the ssh_config syntax file
Leonard Ehrenfried wrote: I have already emailed the original author/maintainer (according to the file David Necas) but have not received a reply from him. What would be the best way to get the file into the vim distribution? (I have search but not found a contributors guide). Should David be uncontactable or unavailable, I would volunteer to be the maintainer of the syntax file. My guess from observing past practice: Send at least two emails to maintainer, spaced a few days apart. Wait a month, and send again. If no reply within a few days, email directly to Bram with your new file attached, and a brief outline of how the maintainer seems to be uncontactable, and volunteer to become the maintainer (and include your details in the file, to replace the old contact info). If changes are significant, should get feedback here (you have covered that by making your post). John -- 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: How can I patch vim 7.3 version updated with mercurial
niva wrote: Following the instructions to get vim 7.3 last version with MErcurial, I am trying to patch this version with the latest patch under windows but... What Hong said. However, you may find this tip helpful: http://vim.wikia.com/wiki/Build_Vim_in_Windows_with_Visual_Studio John -- 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: [Bug][w32] Completion for filetype doesn't work on windows
Dominique Pellé wrote:
It works for me on Linux too. I don't have Windows to test.
I don't see why it would not work on Windows at first sight.
I have just performed some tests on Windows XP:
These work (pressing Tab provides argument completion):
:command! -nargs=* -complete=file Xfil :echo q-args
:command! -nargs=* -complete=syntax Xsyn :echo q-args
:command! -nargs=* -complete=environment Xenv :echo q-args
This fails (pressing Tab for completion does nothing):
:command! -nargs=* -complete=filetype Xft :echo q-args
The reason filetype completion fails on Windows is that
dos_expandpath() in misc1.c is asked to expand text like
C:\.../vimfiles/{syntax,indent,ftplugin}/*.vim.
The {dir1,dir2} syntax is handled by the operating system on
Unix based systems, but not on Windows.
John
--
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: [Bug][w32] Completion for filetype doesn't work on windows
Bram Moolenaar wrote:
Dominique Pellé wrote:
Thanks John. You're probably right about the {dir1,dir2} glob
expression not being portable.
Attached patch avoids such glob expression and should thus be
more portable. I can only test it on Linux so I would
appreciate if someone else can confirm that it fixes the bug
on Windows.
Thats looks better than my workaround. But it should be tested.
I tested Dominique's patch and it applied and ran cleanly.
Each completion in my previous email worked fine (i.e. the patch
makes filetype completion work on Windows).
The 'make test' equivalent on Windows runs all tests successfully.
Dominque's patch has a typo in a comment (repeated word):
dirnames may contain multiple multiple directories.
In case it is not known (I am not complaining), note that
compiling gvim on Windows with the old MSVC 6.0 gives an error
for gui_w32.c since 'HandleToLong' is undefined. HandleToLong
was introduced in patch 7.3.206.
John
--
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: reproducing 'daw' on last word in a file
Jean-Rene David wrote: Sent: Monday, 2 May 2011 12:09 PM To: vim_dev Subject: reproducing 'daw' on last word in a file I would like to fix this item from todo.txt but can't reproduce it: 7 When using daw on the last word in a file and this is a single letter, nothing is deleted. Should delete the letter and preceding white space. Both current Vim and an old Vim (7.2.18) work correctly for me, so I agree with SC that the item should be removed from the todo list. Bram: If you see this, please acknowledge. Otherwise, I suggest that Jean-Rene should add this to the next done patch. Thanks very much Jean-Rene, it's great to see the list go down! John -- 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: vim.org is down
Ben Schmidt wrote: Turns out you're right, John, though I couldn't find any actual evidence in your mail or the thread you cited to prove it. :-) However, this page does prove it: http://sourceforge.net/apps/trac/sourceforge/wiki/Custom%20VHOSTs Interesting docs, thanks. BTW while in general defining an A record for vim.org would not be sufficient when several websites are hosted at the one IP address, the fact that putting the entry that I showed in your hosts file works does prove that adding the DNS A record would work (although of course it is ideal to know that Sourceforge support that, and it will work in the future). I suggest you try Bram, and see if he wants to ask for the change. I'm still in let sleeping dogs lie camp. John -- 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: vim.org is down
Ben Schmidt wrote: Just to clarify, I don't mean that it's working for end users; I just mean it looks to me like the server is responding correctly, so if our DNS admin agrees to make the change outlined above, things should go smoothly. Here is a rehash from the August 2010 thread: http://groups.google.com/group/vim_dev/browse_thread/thread/36b81acf60548c20 I pointed out that it is a simple DNS issue, and gave some examples of Sourceforge sites that have chosen to add an A record for the domain (vim.org for us) in their DNS. Also, anyone can browse http://vim.org/ ok if they put the following in their hosts file: 216.34.181.97 vim.org Searching the above thread for This is by design shows the response from the vim.org DNS manager. Unless we double their pay, I don't think we should expect a change of mind. My purpose for posting is to say that no web redirect service is needed, and I still think that it is not advisable to disturb a very reliable DNS service. John -- 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: vim crash
Hoss wrote:
$ find . -mindepth 1 -maxdepth 1 -name '*.pm' | xargs sh -c
'/usr/ local/bin/vim -p $@ /dev/tty'
The find command has 60 hits. Now, if I just run this
command, it works fine, and I get 10 tabpages. I want each in
their own tabpage, so I put this in my .vimrc file
set tpm=60
With that change, when I run the command, I get the following:
Vim: Caught deadly signal SEGV
Vim: Finished
Segmentation fault
Please try a simpler test. Does the following lead to a crash?
In Vim, source this code to make some test files.
function! MakeFiles(quantity)
for i in range(1, a:quantity)
let content = [printf('File #%02d content', i)]
let fname = printf('test%02d.tmp', i)
call writefile(content, fname)
endfor
endfunction
Make 60 test files (do this in a junk directory).
:call MakeFiles(60)
Exit Vim and enter a command like:
vim -N -u NONE -i NONE -p --cmd set tpm=60 *.tmp
My gvim (7.3.3) runs the above ok (no crash).
John
--
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: windows bug: filewritable() returns 0 if we use it on the current script being read
Craig Barkhouse wrote: Assuming you don't want permissive sharing when doing actual I/O (I argue above that you don't), I question the value of changing mch_access() in the proposed way. The point of mch_access() is to give you a predictor of what types of access will likely work. If the access check tells you that opening the file for write will work, but then when you actually open it for write (using realistic sharing values) it fails, isn't this worse than what we have now? Although I haven't followed exactly what the OP is proposing, what Craig says is correct. Allowing multiple writers to the same file is only desirable under very planned circumstances which do NOT include a text editor writing to a file. John -- 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: Dynamically changing the GVim icon
Axel wrote: is there any possibility - from within gvim - to change the Windows icon that is displayed for the application in the Windows shell (aka Windows Explorer ;-). As explained, no. If the icon really bothers you, I believe it is possible to easily hack an exe file. I rarely see icons so have never tried this, but Google for the following: change icon resource editor John -- 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: Two Typos in the Vim FAQ ( http://vimdoc.sourceforge.net/htmldoc/vimfaq.html )
Yegappan Lakshmanan wrote: If you wanted somewhere to host the download, perhaps the Files section shown at the following could be used: http://groups.google.com/group/vim_use This sounds good. I can upload the text version to this location. You would need to email me (or another manager) the file, and I would upload it. Or, if the current file is available online, I could download it. And/or, the Pages section could hold the html version. Can this conversion be done automatically? Previously this conversion used to be performed by a script running on the SourceForge server. No, there is nothing automatic. The Files section is to hold files that people can download, and the Pages section is for web pages. It has a rather klunky interface, but I can paste simple html into it. I imagine that css is out of the question, so we are stuck with whatever style Google has made available. Again, I would have to get the html from somewhere and upload it. Is there anything wrong with sourceforge.net/htmldoc apart from your desire to get other people involved in maintenance of the FAQ? John -- 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: Two Typos in the Vim FAQ (http://vimdoc.sourceforge.net/htmldoc/vimfaq.html )
Christian Brabandt wrote: Major problems of putting the FAQ on the wiki include: - The size, and working out how to split it up (doable). Please don't split it. How about submitting the FAQ to Bram for inclusion into the Vim runtime files? I already got: ~$ ls ~/.vim/doc/*faq* vim_faq.txt but don't know when I got it, ah here: Last updated on: 17 October 2004 Pretty old. I'd like an updated version. Hmmm. That's an interesting idea. The FAQ is 229K and while that's a small file by contemporary standards, it may be a bit big for Bram to want to include? The FAQ is not updated much; I have a 2 January 2005 version. John -- 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: Two Typos in the Vim FAQ ( http://vimdoc.sourceforge.net/htmldoc/vimfaq.html )
Yegappan Lakshmanan wrote: Last year I thought about moving the FAQ pages to the Vim Wiki site. But that didn't happen. As the FAQ is a big document, we need to split it into multiple wiki pages (one per section?). Sorry that I abandoned that project (well, technically, it is still on my TODO list so it is not actually abandoned). Major problems of putting the FAQ on the wiki include: - The size, and working out how to split it up (doable). - The formatting (very hard to convert to wikitext). - The duplication with some tips (awkward maintenance). In the end, I could not think of any improvement on the current situation of having a single text file that a keen person can download (as pure text) and view/search within Vim. If you wanted somewhere to host the download, perhaps the Files section shown at the following could be used: http://groups.google.com/group/vim_use And/or, the Pages section could hold the html version. Due to spam problems, we had to restrict file changes to managers only, but there is sure to be a way to accommodate that if you wanted. John -- 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] Add tabpage index in tabline
Nicholas wrote: I am used to work with tab pages in vim in console mode. One of the most commonly used actions is to jump from one tab page to another. There are several ways: 1) using :tabnext or :tabprevious command repeatedly until target tab page is arrived. 2) count the target tab page's index, then use :tabnext n to get to it. Type 12gt to go to tab number 12. Here is the diff file for src/screen.c for latest vim 7.3 release. ... I rarely use tabs in console Vim, but I think you can customise tab labels even when non-GUI, to show the tab number. Have a look at the following (mainly the comments): http://vim.wikia.com/wiki/Show_tab_number_in_your_tab_line John -- 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] Re: 7.3 unable to load ruby 1.9.2?
Jon wrote: any feedback from a core committer as to whether this patch is acceptable to be merged into default? Bram (see :help credits) is the Vim developer. It's an awkward time currently because Bram was super busy preparing the Vim 7.3 release over the last few weeks, so if there is no response now, I think it would be best to raise the matter again, starting from scratch, in say two weeks. John -- 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: [Suggestion]: Use different colors to make :dig output more readable
Axel wrote: I often use the :digraph command to find foreign language characters. But looking for a certain character sometines is like finding a needle in the haystack. Would it be possible to color-code the three colums of :dig's output? Finding a character is hard. I suppose some clever highlighting would help. I wondered about this and have come up with a script to show the :dig output in a scratch buffer. I got lazy and have not implemented a proper syntax highlighting scheme, but instead took the opportunity to experiment with the new 'colorcolumn' feature of Vim 7.3. Put the following in a file, for example, dig.vim. In Vim, enter this command to source the file: :so dig.vim Create a scratch buffer with :dig output, highlighted. function! s:Dig() set nomore redir = output silent dig redir END set more new setlocal buftype=nofile bufhidden=hide noswapfile setlocal colorcolumn=4,16,28,40,52,64,76 put =output g/^$/d endfunction command! Dig call s:Dig() When you want to see the :dig output, enter this command: :Dig A command like this can set the colours: :hi ColorColumn guifg=snow guibg=seagreen The column highlighting goes a little weird with some of the characters, but it seems reasonably ok. John -- 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] (win32) extremely slow opening files on network shares
David Anderson wrote: Subject: [patch] (win32) extremely slow opening files on network shares This is a very important patch because we have had many Windows users report extremely slow access to files over a network. I have edited David's patch by including a comment about its purpose, and to use Vim source style. See attached file which I believe is equivalent to David's patch. I have compiled and given a VERY quick test (really no testing at all because I have to go and I wanted to post this). David Anderson's explanation is: MSDN states (edited): You cannot use root directories as the lpFileName input string for FindFirstFile -- with or without a trailing backslash. If you want to see files or get the attributes of a root directory, do the following: - To see files in a root directory, you can use C:\* and step through the directory by using FindNextFile. - To get the attributes of a root directory, use GetFileAttributes. On network shares, you can use an lpFileName like: \\server\service\* but you cannot use an lpFileName that points to the share itself, for example, \\server\service. David's patch appends '\*' to the search string if searching a directory, server, or network share. John -- 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 slow-network.diff Description: Binary data
RE: [BUG] Being provided some equal recursive structures, equality operator never stops comparison
ZyX wrote:
Attached script, being sourced causes vim to hang up forever.
Test command:
vim -u NONE -c 'so bug.vim'
To clarify the problem, start Vim 7.3.3 and enter the following
(this is the essence of the script mentioned above, and will
cause Vim to hang, so close all files first):
:let l=[]
:call add(l, l)
:let dict4={l: l}
:call add(dict4.l, dict4)
:echo (dict4 ==# deepcopy(dict4))
The last line causes Vim to hang (CPU goes to 100%, memory is
not consumed).
Starting an investigation:
:let l=[]
:call add(l, l)
:echo 'l=' l
:let k=[]
:call add(k, deepcopy(k))
:echo 'k=' k
The above displays:
l= [[...]]
k= [[]]
I do not know what the ... means but it is probably a bad
sign. Further investigation confirms this:
:redir @a
:let exp = 'l'
:for i in range(1, 10)
: execute 'let val = ' . exp
: echo exp '=' val
: unlet val
: let exp .= '[0]'
:endfor
:redir END
:$put a
---Output---
l = [[...]]
l[0] = [[...]]
l[0][0] = [[...]]
l[0][0][0] = [[...]]
l[0][0][0][0] = [[...]]
l[0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0][0][0] = [[...]]
Also, the output from:
:echo string(l)
is
E724: variable nested too deep for displaying
John
--
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: Removing vim-patches included in Vim 7.3
Xavier de Gaye wrote: As there won't be a vimGdb patch for vim73, can you please also remove: 6. vimGdb I have updated the patches list: http://groups.google.com/group/vim_dev/web/vim-patches I added a brief intro to say that some patches are no longer listed because they are in Vim 7.3. These patches were removed (source code is now in Vim 7.3): Persistent undo Lua Interface vimGdb Additional floating-point functions Relative line numbers Conceal (in-line folding), ownsyntax and cursorbind John -- 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: vim.org without www
John Beckett wrote: Do you know why vim website doesn't respond to 'http://vim.org'? and responds only 'http://www.vim.org' Apart from the possibility as Tony mentioned that a browser may attempt to use www.vim.org if vim.org fails to resolve, the reason vim.org might work is because the DNS name servers responsible for vim.org would include an A address record for vim.org as well as for www.vim.org. This issue is due to DNS server config. Sourceforge has multiple websites on the same IP address. For example, each of these is at 216.34.181.97: http://www.vim.org/ http://www.jedit.org/ http://www.7-zip.org/ The web browser specifies which website it wants when it sends a GET request to the IP address, and Sourceforge delivers the correct web page based on that URL. It appears that Sourceforge does not care whether www. is included or not; these work: http://jedit.org/ http://7-zip.org/ Currently, http://vim.org/ does not work. However, that is because the DNS servers for vim.org do not include a suitable entry for 'vim.org'. With the following in your hosts file: 216.34.181.97 vim.org you can browse http://vim.org/ ok. There is also a problem with the vim.org DNS servers, and I will communicate with Bram about that (the secondary DNS server has been dead or unreachable for at least a day, and the primary sometimes does not respond). John -- 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
Removing vim-patches included in Vim 7.3
At Bram's suggestion, I will remove some patches listed at: http://groups.google.com/group/vim_dev/web/vim-patches Descriptions for the following items will be removed to simplify the list of patches by omitting those that are included in the newly released Vim 7.3: 4. Persistent undo 5. Lua Interface 7. Additional floating-point functions 9. Relative line numbers 14. Conceal (in-line folding), ownsyntax and cursorbind I will renumber the list, but keep the items in their current order. Please reply if there are any problems with this plan, or if any other changes should occur. I'll do this in two days. The vim-patches page does not say that the Lua interface is included in Vim 7.3, but I think that it is, and so I plan to remove it. John -- 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: vim.org without www
Sergey Avseyev wrote: Do you know why vim website doesn't respond to 'http://vim.org'? and responds only 'http://www.vim.org' Apart from the possibility as Tony mentioned that a browser may attempt to use www.vim.org if vim.org fails to resolve, the reason vim.org might work is because the DNS name servers responsible for vim.org would include an A address record for vim.org as well as for www.vim.org. Currently, the vim.org name servers appear to be not responding to DNS queries, although ns.42.org responds to ping and traceroute, while ns2.42.org does not. Therefore, I can't check whether there is an address record for vim.org (www.vim.org is still cached in other DNS servers I tried, but vim.org is not). John -- 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: Mouse control in a Quick Edit mode Windows console
Jean Johner wrote: Mouse control is lost in Windows console Vim when Quick Edit mode is activated (see vim_use: Is there a way to have mouse control in a Quick Edit mode Windows console?). You have had some probably not replies, so let me be more definite. You are talking about Windows command prompt, where you can right-click a command prompt title bar and choose Properties, Options tab, QuickEdit Mode. The whole point of QuickEdit Mode is that the operating system will handle mouse events, and will NOT pass them to the application runnning in the command prompt window. There is NOTHING an application like Vim can do to use the mouse under those conditions. You can make a Windows shortcut that opens command prompt with QuickEdit mode off, and makes the window the size you want, and uses something like Ctrl-Alt-V to open, then do all your editing there (other command prompts can have QuickEdit mode on). BTW using gvim is better once you choose a suitable color scheme and get used to it. John -- 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
Testdir use of rmdir /Q /S for DOS/Windows
src/testdir/Make_dos.mak runs for every test on DOS/Windows (I think), and it includes: rmdir /s /q Xfind Isn't that redundant, because it is only needed for test73.in which performs the above operation? test73.in includes: : if has(win16) || has(win32) || has(win64) || has(dos16) || has(dos32) : exec silent !rmdir /Q /S . a:dir I guess the list of has(...) items is what you have to do to say DOS or Windows, but not cygwin, however there was no /q /s in rmdir for DOS or win16 (they had deltree /y). I would not worry about about that (i.e. accept that test73 is not going to work on DOS or win16). John -- 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: Vim 7.3f: :r file fails when 'compatible'
Gary Johnson wrote: In a directory containing a simple text file named 'mary', execute the following: $ vim -u NONE -i NONE :r mary The result is the following two error messages: E812: Autocommands changed buffer or buffer name E484: Can't open file mary This bug also occurs in 7.2.323 but not in 7.2.18. Adding -N to the command line causes the bug to not occur. In the current 7.3f (rev 84ba6293f9d7), when executing the :r, the error message is displayed at src/fileio.c, line 733. John -- 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: ex program inserts null char for newline upon insert/append of backslash newline
Frush wrote: We tracked down the issue to a change in the file src/ex_getln.c. Vimboss is Bram Moolenaar, the author of Vim. I noticed your first post and reproduced the issue, but have no idea what the correct behaviour should be. The thread is: http://groups.google.com/group/vim_dev/browse_thread/thread/57baa4b3995d1e81 The issue concerns the result from this ex input: a X \\ Y . The ex command 'a' (which is :a in Vim) appends the following lines (starting with 'X' and 'Y'), stopping at the '.' line. In Vim (entering :a) you get two lines appended: X \\ Y When fed via stdin to 'ex' by the shell, the result is one line: X \...@y When you do this, you get a NULL byte where ^@ is shown above. Clearly some tricky quoting is going on, and the newline ends up in its internal representation (a zero byte). The above summary might prompt someone to look at the issue, but people are distracted by the impending release of Vim 7.3. If you get no answer, I suggest trying again in a month. John -- 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: Vim hangs on pasting a large amount into command line
Sometimes I paste some text into the Vim command line (example: type ':echo ' then Ctrl-R a to paste register a). If I accidentally paste a large amount (kilobytes), I have to wait a very long time (several minutes) while Vim struggles to handle the text. Pressing Ctrl-C has no discernible effect. Some investigating shows that removing the following call to redrawcmd() fixes the problem (this is not a solution, just a preliminary observation): In function getcmdline() (file ex_getln.c line 1840) we find: /* Always redraw the whole command line to fix shaping and * right-left typing. Not efficient, but it works. */ redrawcmd(); Removing that redrawcmd() makes accidental pastes of 8000 bytes into the command line occur in a second or so. With an unpatched Vim, that same paste sometimes seem to complete in a minute, and sometimes seems to take forever (I killed it after several minutes). I have set encoding=utf-8, and I think you need that for the above redrawcmd() to be executed. While I should not be pasting junk into the command line, Vim should not effectively hang if I accidentally do. John -- 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: Vim hangs on pasting a large amount into command line
Bram wrote:
In function getcmdline() (file ex_getln.c line 1840) we find:
/* Always redraw the whole command line to fix shaping and
* right-left typing. Not efficient, but it works. */
redrawcmd();
Removing that redrawcmd() makes accidental pastes of 8000
bytes into the command line occur in a second or so.
...
The intention of this call to redrawcmd() was to only do this
when the text has characters that are difficult to get right,
such as Hebrew and Arabic. Unfortunately the option settings
are now the default.
I see two possible solutions:
1. Don't redraw when there is text pending, using
char_avail(). Need to set a flag then and redraw later,
before waiting for any character to be typed.
2. Don't redraw when the command line contains only normal
characters.
Either ASCII or perhaps only redraw when there are
composing characters. Checking for Arabic is probably a bit
too specific.
While it would best to eliminate the redundant redraws
altogether (and I'll perhaps have a chance to look at that after
7.3 is released), I was wondering what happens once echoing of
the command fills the screen. There seems to be a flag which
tells Vim to only redraw the last line once the screen fills,
and I thought that at least the paste problem might be avoided
if that flag were used to not redraw once the screen fills. The
redraw fails anyway; the last line is garbled, which you can see
if you run the following code to generate some consistent text,
then copy and paste that text into the command line (caution:
you may have to kill Vim to recover).
:new
:for i in range(1, 500)
: call append(line('$'), printf('%04d-abcdefghijklmn', i))
:endfor
The stress of all those redraws when pasting 10k characters
sometimes makes Vim crash. If Dominique notices this, perhaps he
could use some valgrind magic to see if something obvious needs
to be fixed.
John
--
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: Vim hangs on pasting a large amount into command line
Ingo Karkat wrote:
There's no need to modify the source code to avoid the
redraw; just turn off Arabic shaping. There was a discussion
about this on this list two years ago (I was involved, that's
why I remember ;-):
http://tech.groups.yahoo.com/group/vimdev/message/51944
http://tech.groups.yahoo.com/group/vimdev/message/51952
Because I don't need Arabic shaping, I have this in my .vimrc:
Avoid command-line redraw on every entered character by
turning off Arabic
shaping (which is implemented poorly).
if has('arabic')
set noarabicshape
endif
Thanks, I'll use that. Of course I was only removing stuff from
the source while buried in a debugger trying to work out where
the code got lost when pasting into the command line.
John
--
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: Vim hangs on pasting a large amount into command line
Andy Block wrote: Are you by any chance using MacVim? I had this problem with MacVim and raised it in the MacVim list. No, but I mentioned your post earlier, see: http://groups.google.com/group/vim_dev/browse_thread/thread/40e590a3b0ca1b43 I had experienced this frustration a couple of times before seeing your thread in mac_vim, and it was that with the impending release of Vim 7.3 which made me want to investigate. Notice the workaround in this thread posted by Ingo Karkat. John -- 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
Vim hangs on pasting a large amount into command line
Sometimes I paste some text into the Vim command line (example: type ':echo ' then Ctrl-R a to paste register a). If I accidentally paste a large amount (kilobytes), I have to wait a very long time (several minutes) while Vim struggles to handle the text. Pressing Ctrl-C has no discernible effect. Last July, someone complained about this at vim_mac: http://groups.google.com/group/vim_mac/browse_thread/thread/7b520681cfc3a464 I see that cmdline_paste() (in src/ops.c) uses ui_breakcheck() in anticipation of this problem, but it does not seem to work on console or gui Vim on Linux or Windows (Vim 7.3e). Does anyone have evidence that Ctrl-C will interrupt a command line paste on some system? John -- 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 for src/testdir/test11.in
Attached is a minor patch to src/testdir/test11.in based on current Vim 7.3e (rev a88237afdb20). The patch uses executable(gzip) to test whether a gzip is available. If not, test11 quits, simulating success. The result is that all tests (except those documented as being excluded from Make_dos.mak) now work on a default Windows install. This is rather trivial, but it might be worth including. John -- 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 johnb-test11.diff Description: Binary data
RE: E315: ml_get: invalid lnum
Here is a simpler way to reproduce the error. I have done the following on a Linux and a Windows build of current 7.3e (rev 3c51864309bc). I have also used Vim 7.2.18 with the same result. gvim +set nocp ve=all nosol -u NONE :h show :help Y yank first line Ctrl-^ switch back to empty buffer P paste line before cursor fV jump to 'V' in pasted line j move cursor down to blank line, under 'V' dd delete blank line u undo deletion Ctrl-R redo deletion ---Result--- E315: ml_get: invalid lnum: 2 E315: ml_get: invalid lnum: 2 Press ENTER or type command to continue John -- 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 for src/testdir
Attached is a minor patch to three tests in src/testdir: src/testdir/test1.in Wrap comments consistently. src/testdir/test17.ok src/testdir/test17a.in Fix typo. src/testdir/test30.in Use 'copy /b' instead of 'cat' for win32. Test now works on Windows. John -- 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 johnb-testdir.diff Description: Binary data
RE: uninstal.c RegDeleteKeyEx unresolved
Bram wrote: Build stops at: uninstal.obj : error LNK2001: unresolved external symbol _RegDeleteKeyEx I think RegDeleteKeyEx requires Vista or later, or XP x64. I don't need uninstal, but it breaks the build. I don't think this depends on the OS but on the compiler. I'm building Vim fine on Windows XP. That is with MSVC 2010. We could solve this with a few #ifdefs, I suppose. But it will mean that the binary you build with older MSVC won't install/uninstall properly on 64 bit systems. We should somehow give a warning about this and suggest using a newer compiler. For that #ifdef we need to know which compiler supports the new function. Hmmm. But if installing a newer compiler fixed the problem, that would simply mean that I had installed some library with RegDeleteKeyEx, so the link would be ok. However, the resulting uninstal.exe would not run on other systems without that special library. Googling for 'RegDeleteKeyEx win32' (no quotes) finds lots of hits, including: http://msdn.microsoft.com/en-us/library/ms724847%28VS.85%29.aspx http://stackoverflow.com/questions/1476749/how-do-i-delete-a-registry-entry-in-windows-x64-in-the-64-bit-tree-without-using The first seems to be the official docs, and it says that RegDeleteKeyEx requires Vista or later, or XP x64. The second is a question on exactly the uninstal.c problem: how can an executable run on Windows XP or later, including 64 bit systems, and remove certain registry entries. The ugly suggestion is to load the function dynamically, after determining the runtime environment. Perhaps you could make a macro in uninstal.c: #ifdef _WIN64 then use RegDeleteKeyEx, otherwise user RegDeleteKey. As you say, an exe built on 32 bit would run only on 32 bit. John -- 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: syntax/r.vim
Jakson A. Aquino wrote: I tried to contact the maintainer of syntax/r.vim I can't help you with that, but by the way... We have a page on the wiki intended to list scripts relating to R (because they are impossible to search for): http://vim.wikia.com/wiki/Script:List_of_R_Project_scripts John -- 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
tarPlugin.vim needs to be updated to handle xz files
In runtime file plugin/tarPlugin.vim, there are no lines for *.txz *.tar.xz which are needed to edit xz compressed tar archives. File plugin/gzip.vim handles *.xz, but tarPlugin.vim needs to be updated. The above is from Richard David Sherman who asked me to send it to vim_dev. Richard has limited computer access at the moment, so has not expanded on the above. Can someone please fill in the details and update the runtime for the 7.3 release. John -- 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: new trends in vim development (SPAM?)
Tony Mechelynck wrote: This looks like spam to me; I don't click links when I have no idea what the link will do. As Marc said, it is spam and probably MALWARE. Please do not click links like this! I noticed a similar attempt at vim_use a day or two ago and flagged it as spam (thus banning the sender) without a second thought (thus, the message never appeared at vim_use). Someone must have approved this message to vim_dev, but when I went to the vim_dev member list to ban the user (after noticing the spam here), I could not find the user. Possibly they unsubscribed. Strangely, when I went to delete the message from the Google Groups archive, I could not find it there. Possibly another manager already deleted it, or possibly Google decided it was spam and did not archive it? I have just deleted Tony's message from the archive because there is no reason to leave a malware link active in the archive. John -- 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: On extending motions and matches
Adrien Pied Piérard wrote: it looks like motions like i or a' that work with quotations are hard-coded. As I happen to write a lot of math in latex, I have many $ signs everywhere that I would like to treat as quotations so that I can do da$ or yi$. I guess this could be implemented with vimscript, though this does not explain why the aforementioned motions are hard-coded. I don't have an opinion atm on the issue you raise, but in case it is of interest, we have a relevant new tip sitting in the to be processed queue at the wiki: http://vim.wikia.com/wiki/Text_object_for_formulas_in_Latex If a Latex person would like to comment on the tip (does anything need fixing?), please do so on the wiki or here. John -- 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: Improved integration between Vim and its environment (full-screen, open URL, background execute())
Peter Odding wrote: I've asked myself why Vim's system() function on Windows uses vimrun.exe and shows a command prompt window. The only reason I can think of is so that the user has a chance to quit the external command using Ctrl-C. Sorry if the following is not relevant (I have not followed this thread). If you do not have to use system() to get results, you can use :!start which is different from :! on Windows. I believe that :!start does not use vimrun.exe. There is some info in the following: http://vim.wikia.com/wiki/Execute_external_programs_asynchronously_under_Windows John -- 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
Claimed memory leak in :match
A recent edit to a tip includes a claim that having :match in autocmd events leads to severe slow downs due to a memory leak. The tip has a variety of methods to highlight unwanted spaces, including the following extreme version which attempts to highlight dubious spaces as you type, but NOT highlight a trailing space at the end of a line as you are typing it: highlight ExtraWhitespace ctermbg=red guibg=red match ExtraWhitespace /\s\+$/ autocmd BufWinEnter * match ExtraWhitespace /\s\+$/ autocmd InsertEnter * match ExtraWhitespace /\s\+\%#\@!$/ autocmd InsertLeave * match ExtraWhitespace /\s\+$/ autocmd BufWinLeave * call clearmatches() The last line was just added with the claim that it is necessary to avoid severe slow downs. I probably won't have an opportunity to check this claim, and there is no indication of what version of Vim was used, but I thought I would mention this in case someone wants to investigate. The tip is: http://vim.wikia.com/wiki/Highlight_unwanted_spaces The difference showing the two recent edits is: http://vim.wikia.com/index.php?title=Highlight_unwanted_spacesdiff=27609oldid=27103 John -- 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: Fix for wrong indentation of JavaScript code by cindent
Hari Kumar G wrote:
Vim uses cindent for JS files which works in general nicely.
There are a few cases where this does not work correctly. F.e.
var a = {
b: 1,
c: hello
}
cindent would align b: 1 to col 0 and indent c: hello by
shiftwidth. This is because of how it treats labels in C.
The attached fix avoids this by using another 'cindentoption'
value 'J' so that such lines could be treated differently if
the file is a JS file.
Please review this recently-added tip:
http://vim.wikia.com/wiki/Improved_Javascript_Indent_script_for_Vim
It would be great if you were to determine what works best
(combining your script with the above) and take Bram's
suggestion to become the maintainer for the Javascript indent
file distributed with Vim. If you make a decision, whether 'yes'
or 'no', I would like to hear about it because we would not want
to keep a tip that was simply an indent script distributed with
Vim.
John
--
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
