Re: [vim/vim] Defaulting mouse=a in a terminal is incorrect (new as of 7.4.211) (#2841)
As a random data point, I installed three new systems with Debian in the last weeks; the first time I installed new systems for years. As those systems were not intended for personal use, I didn't copy my personal configs which have carried anti-mouse boilerplate for roughly a decade. I was bitten by mouse being enabled on every one of those systems; especially when setting up, it's quite common to copy & paste text, data, and config over. For configs, I usually use Vim. Not being able to paste by pressing middle button and having my cursor jump all over the place was surprising at best. On the other hand, I do get that new users might have an expectation of the mouse working. But I would argue that those could use gVim if they wanted a more mouse-centric UI. Richard -- -- 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: Arbitrary tab stops
On Mon, Jun 7, 2010 at 16:07, Ingo Karkat sw...@ingo-karkat.de wrote: I haven't used it personally, but it surely sounds interesting. If some people try this out now and report back positive news, maybe Bram will still include it in 7.3 or at least consider it for the following release. My personal build of Vim has incorporated this patch for ages and it's really useful. I have not rebuilt it in a while, but my last status is that it applies, builds and helps. Richard -- 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 for encryption, strengthened key with salt.
On Mon, May 31, 2010 at 20:06, Mosh moshah...@gmail.com wrote: http://en.wikipedia.org/wiki/Key_strengthening The salt is a random number concatenated to the password to create a one time key. Everything else being equal, it makes (slightly) more sense to prefix the salt, not to suffix it. Obviously, this is more important with ciphers than with hashes, but the basic point remains. This prevents someone from precomputing keys (dictionary), because the salt is a different in each file. Ideally, the salt would change every time the file is saved. Another trick, especially as there is no integrity control in Vim's encryption, would be to have an ever-changing prefix _within_ the file, perhaps even with unprintable bytecodes. That would make the typical high-speed attacks (only decrypt the first few bytes and go to the next key if you encounter any non-char sequences) a lot harder. On the other hand, this only works for files that are meant for humans and/or that are very liberal when parsing input. Richard -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Patch 7.2.269
2009/11/3 Bram Moolenaar b...@moolenaar.net: Yeah, that's inconsistent. Shall we change it to vim --startuptime file Aye from me. Also, it should default to a reasonable filename if none is given. Personally, I'd suggest vim_startup. Also, wouldn't it make more sense to create a new file instead of appending? Two possible solutions are a counter and a timestamp. So a filename like vim_startup.20091108-113425 might be a good solution. I.e. $filename.$ISO_DATE.$HHMMSS optionally interspersed with dashes and dots to increase legibility. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.269
2009/11/8 Bram Moolenaar b...@moolenaar.net: I rather avoid using a default name, because it's easy to accidentally overwrite an existing file. Not if you append a counter or similar to the filename. And it would require another flag to specify the name when you want to, because you don't know if the argument that follows is a log file name or a file to be edited. There is that. Good point. And the files with the default name would be written in the current directory, which makes this even more tricky. Same problem as with file names you specify. The idea is that you get a log of startups in one file. So you can have Vim startup a dozen times, and then look in the log file what happened. Writing all different files makes this a bit more complicated. Depends on the format you use. Personally, I woud tend to use vimdiff if possible. Appending also avoids that when you accidentally give an existing file name it's overwritten. Arguably, that is worse as it could destroy the syntax of data in an existing file. The problem can be avoided by appending to the filename. Clutter vs data safety, so to speak. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A branch for join_O(n) patches was: Re: [patch] Re: make joining lines O(n)
On Fri, Jan 23, 2009 at 00:29, Markus Heidelberg markus.heidelb...@web.de wrote: And I'm not quite sure how much history to include Imo: As much as possible. While it will most likely not be used in vim_extended, hdd space and bandwidth are laughably cheap and it might help once or twice. Richard PS: Did I send you my comments about README? I am sure I did, but I can't find the email I must have sent..? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: A branch for join_O(n) patches was: Re: [patch] Re: make joining lines O(n)
On Tue, Jan 20, 2009 at 20:03, Markus Heidelberg markus.heidelb...@web.de wrote: When creating this branch, maybe at the same time I'll rename the feature branches to something of the shape feat/relativenumber, because it's getting complex with more feature branches and I want to be able to clearly distinguish these branches from 'vim' 'master' and 'vim-with-runtime'. Good idea. This repo is still under development, so I think renaming is not fatal, or is anybody screaming? However as long as I don't rebase, it should not be a big deal for a user, and I do not yet rebase. Personally, I would not even mind if the repo were to be redone completely if it's cleaner in the longer run, so no screaming from me. I first thought about naming your branch test/join-lines-improved or so, but I think I'll put it in the feat namespace. Any better idea for the name after the feat/? 'feature'? :) Wait, another thought: how do you plan to handle this branch? Should it be stable (in terms of git) or do you want to rebase against the latest 'vim' everytime? For stable branches, we could use the feat namespace, for heavily under development or rebased for other reasons, the test namespace. For getting testers, not rebasing is the better choice, but for sending patches out, it may be easier to rebase. OK, that's your choice, but I'd like to know it. If in feat, then I can ponder to include it in 'master'. That's a pretty good idea. Though I would suggest fix/ feature/ development/ though fix/ prolly will not be needed, ever. Patchset authors could then do both active development and stable releases in the repo. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] Re: make joining lines O(n) was: Re: Vim complexity bug with joining lots of lines
On Wed, Jan 7, 2009 at 16:21, Milan Vancura mi...@ucw.cz wrote: I'm sorry, Bram. I overlooked the problem that all tests are run in compatible mode by default, so test29 went wrong. The fix is attached, shall be applied after 03-test29_improve.patch I suggest you email the list with the full patch, asking to be included in vim_extended -- that way, you get more testing for your patch will be able to polish it even more if needed. Richard :) --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.2.072 (extra)
On Sun, Dec 28, 2008 at 06:44, harpchad chad.h...@gmail.com wrote: On Dec 24, 5:43 am, Bram Moolenaar b...@moolenaar.net wrote: /// Bram Moolenaar -- b...@moolenaar.net --http://www.Moolenaar.net \\\ Are you using GMail as your MUA? If yes, how did you make it obsfuscate email addresses? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: need help, writting a new gui interface
On Sun, Dec 21, 2008 at 18:22, Markus Heidelberg markus.heidelb...@web.de wrote: While searching for related stuff several weeks ago, I found a Qt port. I only tested a bit, but it worked with some resizing problems when changing/adding windows and tabs. I wanted to ask all the time whether somebody knows anything about it: http://www.bitbucket.org/NorwegianRockCat/gvim-qt/ Neat. I will poke him to tell him about this list yzis. Also, I will ask him if he would bewilling to actively react to any problems encountered. Might make a nice addition to, you guessed it, vim_extended :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] bug in completion with i_CTRL-N using arabic or persian keymap
On Thu, Dec 25, 2008 at 18:52, Dominique Pelle dominique.pe...@gmail.com wrote: set completeopt=menuone,longest set tags=tags set keymap=arabic Are you actually seeing those in your daily work with Vim or do you run an automated test suite that set lots of options and does lots of stuff, etc? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
On Mon, Dec 22, 2008 at 14:31, Markus Heidelberg markus.heidelb...@web.de wrote: Richard, I hope you can understand that I haven't yet tackled the Readme file. I haven't forgotten it. Sure, no worries, I know how it is ;) There are a few new interesting patches listed on Josh's site, maybe you could merge them, once you have more free time? I plan on spending a lot of time away from computers over christmas, but after than, if you give me commit access, I can try to help merge new patchsets and the README into vim_extended so you have less work. RIchard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: latest runtime files merged into vim_extended.git
PS: There is a bug on http://repo.or.cz/w/vim_extended.git edit and build as usual vim; make; make install :s_vim_./configure_ --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Status of breakindent patch
On Sun, Dec 21, 2008 at 10:56, Ingo Karkat sw...@ingo-karkat.de wrote: Thomas, thanks for digging up the old link; I'll try to compile and test this patch, too. It would be great to see this on the Vim patch page, so that more people will try it out. Write a short overview in the style you can find on the wiki and send it to the list (I think the wiki is still locked down, atm). Let's hope Markus finds time to add it to the git repo, as well :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch to unify the help files a bit
On Wed, Dec 10, 2008 at 21:21, Bram Moolenaar [EMAIL PROTECTED] wrote: These remarks depend on the features in the normal build. If they are only in a bigger-than-normal version it says only when compiled with... When they are in the normal version it says not available when compiled without. Ah, makes sense. That's why I added the line about ignoring the patch. I suspected it wasn't an oversight, but could not figure out what the reason was. Good reason, too :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On Tue, Dec 9, 2008 at 20:03, Matthew Winn [EMAIL PROTECTED] wrote: I did try that but it's trickier than it sounds. 'vts' allocates memory for a parsed copy of the tabstops, and keeping track of that memory when setting ts was excessively complicated so I opted for a simpler ignore ts if vts is set strategy instead. I'll take another look at it because I'm not happy with the counterintuitive way in which 'ts' suddenly ceases to have any effect when 'vts' is set and I'd rather the two options cooperated. Don't you deallocate the memory when vts is unset? In that case, just run the same code to deallocate when ts is being set. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On Tue, Dec 9, 2008 at 12:35, Markus Heidelberg [EMAIL PROTECTED] wrote: Applied and online. Now it's time to go to work :) Awesome. I am using it already and I love it! Matthew: Is it possible to mark anything that does not fit into the existing vts scheme (i.e. anything which forces you to shift the tabs) as ERROR so it's highlighted? Is there a better way to give a visual hint when this is happening? Also, would a scheme like set vts=auto[/n[/m]] make sense? auto would obviously auto-space the tabs, while the n defines the min spacing after the longest segment and m sets the maximum length of a cell (a cell being text + tabspace). Of course, this should be possible, as well: set vts=10,5,auto The reason I am not choosing a comma, but something else is that this should _also_ be possible :p set vts=10,auto/5,7,auto,10,auto Also, I want a pony. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On Mon, Dec 8, 2008 at 08:23, Markus Heidelberg [EMAIL PROTECTED] wrote: I just tried it again and it seems I had misunderstood some things. The tabstops have a fixed position. If a word is longer than the space for the current tabstop, then this tabstop will be ignored and the next will be taken. So if no new version is available at the moment, I can already include it. If it's not too much work and if Matthew OKs the basic workability, I would be willing to trial the existing patch in my normal build. Richard PS: vim_extended is awesome. It really helps getting those patches more and _persistent_ exposure. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Build failure for vim_extended with Vim 7.2.065
On Mon, Dec 8, 2008 at 01:10, Markus Heidelberg [EMAIL PROTECTED] wrote: Markus, please put the attached file into the git repo. In which branch, master? Yes. That way, everyone will be able to see the README. I already have plans to split the readme part on the gitweb interface into two: one for the most simple use of just the master branch as already done and another for creation of an own branch merging various feature branches as you did in the attached file. Ah, OK. Feel free to merge/discard my version. Or we can work on one together. Whichever you prefer. But I'd like to keep it short, forgoing all the things that aren't special for vim_extended like details in configuring Vim and setting up git. There is already enough documentation out there, a Vim novice won't use vim_extended anyway, a git novice though. Well, a git novice might not know about the color.ui option and it really _does_ make working with git easier. I have no problem dumping it, though. I wonder if it is better to activate the features by default. The Lua interface for example. I think it is, nobody wants to merge the lua branch for not using it, do you agree? Why not offer a mergeall branch or something? Personally, I cherry-pick the interesting (to me) stuff, but others might prefer to just build the whole beast. We would then have three parts in the docs: Vanilla, Cherry All. I also think it would be better to patch src/auto/configure, then make -C src autoconf wouldn't be necessary anymore. This would also be the case, when the patch was integrated into mainline. Agreed. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On Mon, Dec 8, 2008 at 11:54, Tony Mechelynck [EMAIL PROTECTED] wrote: I don't personally use variable tabs so maybe I'm off-target; but for some options (such as 'syntax' and 'filetype', not to mention 'compatible') special actions are taken at the exact moment when their their setting is modified by a :set command. Why not say that a :set ts= or :setlocal ts=, with a value (not :set ts? or equivalent) will, at that instant, set vts to empty in the same range (:set, :setlocal or even :setglobal)? (IIUC, 'ts' is remembered but not acted upon if 'vts' is nonempty, the way, let's say, 'cindent' is remembered but not acted upon when 'indentexpr' is nonempty) Even better, just unset vts if ts is set and vice versa. Or copy all ts settings into vts, basically removing the ts functionality. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Trial patch for variable tabstops
On Sun, Dec 7, 2008 at 18:05, Markus Heidelberg [EMAIL PROTECTED] wrote: It applied, compiled and worked. But with some bugs, if I've understand the expected behaviour correctly. Before including it I'd like to ask whether there is a newer version available. Thanks! If we don't hear back, I can try it myself. Perhaps the bugs are, in fact, intended behaviour. There are still only few patches integrated in vim_extended. Partly it's a lack-of-time problem A reason we can understand all to well. Thanks for the time you are putting into this. partly an outdated-patches problem. Hopefully, this will become better now that there is an easy way and central place to handle patches. Richard PS: The build of relnum, float code checking patches on current Vim failed. I need to do some more testing, but I suspect this is the code checker's fault. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Build failure for vim_extended with Vim 7.2.065
Hi all, building vim_extended with the code checker patch fails: % git checkout -b local/code_checking origin/vim % git merge origin/code_checking % ./configure --with-features=huge --enable-multibyte --enable-cscope \ --enable-perlinterp --enable-pythoninterp --enable-rubyinterp \ --prefix=/usr/local/vim_extended % make Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src make first make[1]: Entering directory `/home/richih/work/git/vim_extended--playground/src' mkdir objects CC=gcc -Iproto -DHAVE_CONFIG_Hsrcdir=. sh ./osdef.sh gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -D_FORTIFY_SOURCE=1 -o objects/buffer.o buffer.c gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -D_FORTIFY_SOURCE=1 -o objects/charset.o charset.c gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -D_FORTIFY_SOURCE=1 -o objects/code_check.o code_check.c code_check.c: In function 'cc_slave_sroutine': code_check.c:315: error: 'gui' undeclared (first use in this function) code_check.c:315: error: (Each undeclared identifier is reported only once code_check.c:315: error: for each function it appears in.) code_check.c: In function 'cc_update_screen': code_check.c:364: error: 'gui' undeclared (first use in this function) code_check.c: In function 'cc_compile_tmp_copy': code_check.c:500: warning: ignoring return value of 'system', declared with attribute warn_unused_result code_check.c: In function 'cc_create_tmp_copy': code_check.c:520: warning: ignoring return value of 'system', declared with attribute warn_unused_result make[1]: *** [objects/code_check.o] Error 1 make[1]: Leaving directory `/home/richih/work/git/vim_extended--playground/src' make: *** [first] Error 2 % Bram, is it OK if we hijack this list for that stuff? I think it makes sense to keep it here, but if you prefer, we can move it off this list. Markus, please put the attached file into the git repo. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- # get the sources, etc. If you are reading this, you will probably already be # past this step git clone git://repo.or.cz/vim_extended.git cd vim_extended # optionally, enable colors git config --global color.ui auto # list all branches, choose the ones you like git branch -a # create your own branch based on stock vim source git checkout -b custom origin/vim # merge the patches you like, for example you could do git merge origin/relativenumber origin/floating_point # if you merged origin/lua, you will need to run this: make -C src autoconf # configure -- in this case with perl, python ruby support ./configure --with-features=huge --enable-multibyte --enable-cscope \ --enable-perlinterp --enable-pythoninterp --enable-rubyinterp \ --prefix=/usr/local/vim_extended # if you merged origin/lua, you will also need to append this # (this assumes lua is installed in /usr/local) --enable-luainterp --with-lua-prefix=/usr/local # build deploy make su - make install Please note that there is no official support for this from Bram. The patches will most likely work and they appear to do so for several people. However, you might get unlucky and stuff breaks. At worst, you could lose iyour data. So please be aware of this before going down this road.
Re: Build failure for vim_extended with Vim 7.2.065
On Sun, Dec 7, 2008 at 21:37, Bram Moolenaar [EMAIL PROTECTED] wrote: It's fine to discuss this here. Thanks. Is this a problem in code_checking or in vim_extended? In the first case you should send a message to Birgi Tamersoy. I'm not sure he reads this list. It's a patch problem. vim_extended itself is just a vanilla copy of Vim. The only difference is that it makes it easy to merge patches on top of vanilla. So if I were to pull vim_extended and /.configure; make; make install, I would have exactly the same binary as if I did it in Vim proper. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Build failure for vim_extended with Vim 7.2.065
On Sun, Dec 7, 2008 at 21:53, Birgi Tamersoy [EMAIL PROTECTED] wrote: I just saw this. I will look into details. This is the first time I see a compilation related problem. Thanks. :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: slick way to keep patches?
On Fri, Nov 21, 2008 at 19:49, Markus Heidelberg [EMAIL PROTECTED] wrote: if exists(rnu) Duh.. Thanks :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: slick way to keep patches?
On Mon, Nov 17, 2008 at 16:22, Charles Campbell [EMAIL PROTECTED] wrote: The only criticism I could make of MH's patch, and perhaps I'm just ignorant of how to do it -- but I rather like the plugin's different colorization of previous vs future relative numbers, and would like it if the relative numbering patch would provide something similar. Can you explain how exactly that works? I never really tried the plugin, only the patch, but I like that, at least. Do I assume correctly that there is no clean way to check for the existance of the patch at run-time, yet? I would love to adopt my keybindings depending on if the patch is applied or not. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Mon, Nov 17, 2008 at 02:44, John Beckett [EMAIL PROTECTED] wrote: Any thoughts? Should I put your script and my script on a page as a starting point? Can't hurt, all for it. Do you want to include the git howto I sent to the user's list, as well? I can do it myself, just need to know :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Mon, Nov 17, 2008 at 08:38, Markus Heidelberg [EMAIL PROTECTED] wrote: Ben Schmidt, 17.11.2008: I gave up on SVN ages ago--I would have loved to use it, but it's just too messy. Now I apply patches. Below is the script I use to do it with Mercurial, which may serve as a starting point for doing the same with Git (or whatever); do what you like with it. Thanks. Apparently there are several unhappinesses with the official repo. I still have to decide whether to go this way, but it really seems so. Let's see when I have time during this week to get started. I seem to remember encoding issues with the patch emails that did not occur in the svn repo. Just something to keep in mind. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Tue, Nov 18, 2008 at 04:06, John Beckett [EMAIL PROTECTED] wrote: Despite the fact that this thread is about the unofficial patches, I was responding to Ben's script that relates to the official patches. Oh, sorry! In conclusion, please wait. I'll announce the stubs in a week or two. Will do :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Fri, Nov 7, 2008 at 00:07, Markus Heidelberg [EMAIL PROTECTED] wrote: Yes, I could, if the repo would be used by some people. I think I have even tried to apply each extension that could be downloaded as a patch file. Thanks to Jason, I am running a version of Vim with relativenumber full floating point support, now. I would like to encourage others to try out those versions so the patches get more exposure. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Sat, Nov 8, 2008 at 14:24, Bram Moolenaar [EMAIL PROTECTED] wrote: These patches are made by anyone who is interested in making a patch. I don't have time to look through them, especially if a patch gets changed a few times. So don't expect a good or bad comment from me. Unless it's something I really want to use myself or have looked at for some reason (e.g., I have been reviewing the Google Summer of Code stuff). Would patches that live in said repo that are in active use and prove stable have a higher chance of being reviewed? Personally, I suspect that such an agreement is what is lacking in order to get more people to test out patches. I know it's the main stopper for myself as I fear most work in that way will be useless, anyway. Some kind of way to add comments to the patches would be nice. But we need another system to be able to do that. I already suggested that someone could take the text and move it to a platform with more flexibility. If gut supports something like trac, that would be a neat way to get comments about the patches going. Otherwise, they could be put onto wiki discussions, into a forum or patches could be integrated in whatever is done with the scripts section. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Fri, Nov 7, 2008 at 00:07, Markus Heidelberg [EMAIL PROTECTED] wrote: But because there was not a single response to my mail from 13.10.2008, I came to the conclusion that nobody was interested in this. That was quite disappointing, especially because several threads on this list let me believe the opposite. Personally, I don't have enough free time to really get into testing the various feature sets. I will try to set apart some time to build the various Vim versions and use them in my daily work, though. One thing that might lead to a _lot_ more exposure would be stealing the build tools from the various distributions to provide pre-built .deb etc files. If you could automate this, it would not be much work for you and I am pretty certain a lot more people would use it. One thing which is lacking imo is some sort of semi-official endorsement by Bram. If everyone agreed that this is a playground with potential breakage, would it be OK for Bram to endorse this? He could even put his own experimental patchsets in there. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Thu, Nov 6, 2008 at 11:38, John Beckett [EMAIL PROTECTED] wrote: On October 11 we had a discussion regarding a spammer who changed all the links on the 'Vim patches' page to a porn site (according to Google Groups forum messages, such links are probably to a site that tries to exploit client vulnerabilities and/or user gullibility to install a malware trojan). Argh, severe case of leaky brain. Sorry! In the following message I advised that while waiting for Bram to return, I had disabled editing of the page (and invited anyone to post to the list with a request if they wanted something done to the page): Can you add the patch to the list, please? :) I've just emailed Bram telling him the above and asking what he wants to do. I still think this should move in the normal wiki. Thanks for poking him. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Can we still edit the patches list on google groups?
Hi all, while searching for something unrelated, I stumbled over Matt's color patch [1], again. It's the patch he wrote for better color support on the CLI. I tried adding it to the vim google groups site [2], but failed to locate any edit button. Can we still edit on this site? I am logged into GMail with the browser I am using and the GMail address is susbscribed, so that should not be a problem. Also, I saw that Markus' git repo [3] does not incorporate all patches listed on said site. Perhaps he could add those, as well? Markus, I also wondered if a head that merges all patch branches would make sense. It would be a single place to check if all the patches play along nicely. Richard [1] http://groups.google.com/group/vim_dev/msg/01b3def9b96e9457 [2] http://groups.google.com/group/vim_dev/web/vim-patches?pli=1 [3] http://repo.or.cz/w/vim_extended.git --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Can we still edit the patches list on google groups?
On Thu, Nov 6, 2008 at 11:55, John Beckett [EMAIL PROTECTED] wrote: Richard Hartmann wrote: Can you add the patch to the list, please? :) Sure but I don't have time to work out what text to put. We need something like the following from http://groups.google.com/group/vim_dev/web/vim-patches 10. Variable tabstops Author: Matthew Winn Status: alpha Site: http://groups.google.com/group/vim_dev/browse_thread/thread/78d3903b4ea24594/ Set different widths for each tab stop. Please suggest something and I'll put it on the page, but it won't be until tomorrow. Unless Matt chips on before you next look at it, I propose what I basically stole adapted from his announcement email: Unified colors across various Terminal emulators to make colorschemes consistent. Supports the xterm-compatible, Eterm and Konsole palettes. Which palette is used for the matching is controlled by a new option, 'termpalette' (short name 'tpal'). If the option is unset, default to xterm palette, but display a warning that color matching might be inaccurate. Richard PS: Matt, did you look at how Konsole in KDE 4 does some things differently? Mainly, it now supports real bold etc instead of mapping them to color changes. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New feature: cursor at the beginning of tab character in normal mode
2008/10/6 Vladimir A. Pavlov [EMAIL PROTECTED]: 1. it would be difficult for a novice who came from another editor to find that place and he/she won't probably find the solution of the problem. Are there better places? Agreed. But havin it _somewhere_ is better than nowhere. 2. is the solution in question correct on all platforms/terminals so that we are allowed to add such a comment to the help file? It works on x86 and x86_64 in xterm and linux terminals but what about others? As this is a UI thing and quite basic, I am willing to bet that it will work everywhere. Bram, would you? He is on holidays, don't expect a quick answer. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Holiday
On Wed, Oct 1, 2008 at 20:50, Bram Moolenaar [EMAIL PROTECTED] wrote: In case you are wondering why I'm not responding: the coming weeks I will be taking a holiday. No internet, no email, a real vacation. Have fun, read books, stuff yourself with food :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: CursorHold continually fires if it calls system()
On Sat, Sep 27, 2008 at 13:29, Bram Moolenaar [EMAIL PROTECTED] wrote: This patch should fix it for the situation that I found had the problem. There might be another situation, depending on the context. I see the same on Debian. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: CursorHold continually fires if it calls system()
Confirmed this behaviour for VIM - Vi IMproved 7.1 (2007 May 12, compiled Jun 24 2008 14:20:15) Included patches: 1-314 Compiled by [EMAIL PROTECTED] Huge version with GTK2-GNOME GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra +perl +postscript +printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: $VIM/vimrc user vimrc file: $HOME/.vimrc user exrc file: $HOME/.exrc system gvimrc file: $VIM/gvimrc user gvimrc file: $HOME/.gvimrc system menu file: $VIMRUNTIME/menu.vim fall-back for $VIM: /usr/share/vim Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/inclu de/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -DORBIT2=1 -pthread -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0 -I/u sr/include/gconf/2 -I/usr/include/gnome-keyring-1 -I/usr/include/libgnome-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libx ml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/pixman- 1 -g -O2 -O2 -g -Wall-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.10/CORE -I/usr/include/python2.5 -pthread -I/ usr/include/tcl8.4 -D_REENTRANT=1 -D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1 -I/usr/lib/ruby/1.8/i486-linux Linking: gcc -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,--as-needed -L/usr/local/lib -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -l gobject-2.0 -lgmodule-2.0 -lglib-2.0 -lgnomeui-2 -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 - latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgconf-2 -lgthread-2.0 -lrt -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lXt -lncurses -lselinux -lacl -lgpm -Wl,-E -L/usr/local/lib -L/usr/lib/perl/5.10/CORE -lperl -L/usr/lib/python2.5/config -lpython2.5 -lutil -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.4 -lieee -lruby1.8 -lm --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: List of Vim patches
On Tue, Sep 23, 2008 at 20:37, Bram Moolenaar [EMAIL PROTECTED] wrote: In my opinion tips deserve their own site. If you start adding more things there it becomes messy. It's already a bit crowded. True. On the other hand, the wiki could, at some point, supercede the 'normal' Vim pages. That approach seems to be rather popular, these days. Preferably, such a wiki would be hosted on vim.org, not on wikia. In case you don't want to do the admin tasks related to such a Vim wiki, I would be willing to take care of the installation, updates etc, as would be a lot of others, I suspect. Of course, I do not know if you want to give up that much control, which would be fully understandable. Patches have a closer relation with scripts. But different enough to still deserve a place of their own. Also true. Another option is to introduce a new section on vim.org. That would not be ideal imo, though. Yet another option would be a common patch repository. This should very likely be distinct from the main Vim repo for a whole lot of reasons. As much as I dislike the current 'Use git for everything' craze, it would be suited just fine for pulling Vim's sources into itself and maintaining several branches. Permissions would, of course, be handed out liberally for new branches and restrictively within existing branches. The recent work to import Vim's history, starting from 5.0(?), into a single git repo might be a great starting point for this. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: List of Vim patches
On Sat, Sep 20, 2008 at 16:33, Bram Moolenaar [EMAIL PROTECTED] wrote: Moving it to a wiki is fine. But I don't think this belongs on the Vim Tips wiki. Unless a new wiki is created, it is the only place to put it, though. Would you actually mind if this made its way onto the tips wiki, even if there was a BIG FAT WARNING on the patch overview site? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: PATCH: new option: alternate whitespace handling in paragraph search
On Sat, Jul 19, 2008 at 18:55, Markus Heidelberg [EMAIL PROTECTED] wrote: While replying to this mail, I noticed that it would be useful to define own paragraph boundaries, not only an option for whitespace. Yes, if this is done, a generic option would be best. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Errors in ZSH syntax highlighting
Hi all, I will try to look at this myself, but my time is extremely short, atm. Thus, this is both a reminder to $self and an invitation for others to look at it. Syntax elements are detected highlighted in the wrong places. Two examples I have known for some time but never got around to do much about them are: for do (foo bar); do; echo $do; done foreach do (foo bar); do; echo $do; done /do/not/highlight In the first case, I assign values to a variable named do, in the second, I am using it in a path. Of course, the same happens for the other usual suspects. functions, case, if, you name it. Thanks, Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Errors in ZSH syntax highlighting
On Thu, Jul 17, 2008 at 14:27, Nikolai Weibull [EMAIL PROTECTED] wrote: Posting sooner rather than later is always better. That almost rhymes. True. I simply always forgot by the time I was finished fiddling with my scripts. However, why would you name a variable do? I wouldn't. I named one variable test, but do was shorter to write in my email :) Also, why are you putting semicolons after do? I am using shortloops 99% of the time and thus always forget where to put the semi-colons. Slobbering the thing with them works, so I adapted that 'style'. This particular case can be solved by matching paths, but how about arguments to commands in general, for example: Indeed. That is (almost) the only situations I saw the issue rear its head, too. In that case it was ~/.zsh/functions, but again, 'do' is faster to read write. The other situation woud be echo yes I do To not highlight keywords in this situation would require us (and by that I mean me) to implement the whole Zsh grammar. Please take a look at Src/parse.c before asking me to do that. I know that this is not feasible or at least not worthwhile in terms of work and gain. I only mailed the list because I knew they would be easy to fix. Overall I think that syntax/zsh.vim does a very good job of highlighting Zsh source files. I can live with a few blemishes if they require substantial complexity to fix. Agreed :) Thanks for your work, Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Wrong placement of X server connection errors?
On Thu, Jun 26, 2008 at 00:05, Bram Moolenaar [EMAIL PROTECTED] wrote: What error messages? Possibly they come from some library. Sorry for taking so long to reply. In light of the recent thread, this 'error' report is probably moot though, anyway. Richard PS: Attached is a 29 kiB PNG. Let's see if that gets through. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- inline: vim X error.png
Re: A git from scratch repository of vim since vim-6.0
On Thu, Jul 3, 2008 at 13:12, Henrik Öhman [EMAIL PROTECTED] wrote: The commit messages seem to be slightly broken in that they have hard line breaks and indentation in text. It could perhaps be solved by removing any line breaks except where the next word is Problem:, Solution: or Files:, but I'm not sure it's worth the effort. Which might be a good opportunity to once again point to RFC 3676 [1]. This would be a worthwhile addition to Vim it would help solve the problem at hand nicely if it had been used, back then. Richard [1] http://www.ietf.org/rfc/rfc3676.txt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: where can I find tar.gz of all vim-dev messages ?
On Mon, Jun 30, 2008 at 23:17, Christian MICHON [EMAIL PROTECTED] wrote: web based format, close to useless unless I write a clever awk script after I individually download each page individually. wget comes to mind. I am sure you will find a script to do what you want. Wanting web archives in a sane format is not too uncommon, after all. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: updated 'relativenumber' patch
On Sun, Jun 29, 2008 at 15:19, Bram Moolenaar [EMAIL PROTECTED] wrote: I don't know. I can see it's somewhat useful, but it's also a yet another option thing. True, yet this option would not impact VIM in any meaningful way. I.e. it is a small, granular patch that does neither introduce too much bloat nor a likelyhood of breaking. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: updated 'relativenumber' patch
PS: Could/should we ask vim_use about their opinion? It might be that no one is interested or lots of people are waiting for this. Would this (voting/comment period) generally help in ways of deciding which patches to accept? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Wrong placement of X server connection errors?
Hi all, something that has irritated me for ages, but which I never thought about in this way, is the fact that when you start vim on a console, vim detects a X server running, vim tries to connect, but can't as it misses the magic cookie, the error messages are spewed into the buffer and do not appear cleanly in the lowest line. Is there any reason which I am not aware of or could this be changed into a normal vim message? Preferably one that could be turned off ;) Thanks, Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.262
On Wed, Feb 20, 2008 at 11:16 PM, Milan Vancura [EMAIL PROTECTED] wrote: Yes, it was Zdenek's original request... Come to think of it, get_ppname could be even more important than get_ppid. Bram: If you agree that this is useful, I can try my hands at a patch, so you don't have to. It is prolly the best junior job I saw since joining the VIM lists. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.262
On Thu, Feb 21, 2008 at 12:21 AM, George V. Reilly [EMAIL PROTECTED] wrote: The same caveats apply on Windows, which wasn't clear in Bram's help text. I assumed Bram counted Windows towards DOS, thus not offering a PID at all? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.262
On Wed, Feb 20, 2008 at 11:17 PM, Ben Schmidt [EMAIL PROTECTED] wrote: But it's unique during the period that the Vim process is running, which is the only time the function can be called, and the only time the concept of a process ID really makes sense! I think 'unique' here didn't mean for all space and time! Of course. But being able to generate/query a value and to reliably use it as a unique value are vastly different. If in doubt, it's better to be precice. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: 2html.vim: hyperlinks on linenumbers
On Feb 17, 2008 10:46 PM, Benedikt Waldvogel [EMAIL PROTECTED] wrote: Am I the first who had this idea or are there counter-arguments for doing this? On a hunch, this is because most people don't need it. It inflates the size and makes manual editing harder, as well. On the other hand, this can have advantages. Maybe make it an option? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: feature request: help users count lines - display relative line numbers
On Feb 13, 2008 7:53 AM, Nick Gravgaard [EMAIL PROTECTED] wrote: I believe this could be easily rectified if Vim could display relative line numbers in the left hand margin (with the current line being 1, the next being 2, and so on). I can see this being useful when refactoring code. I would probably map that to a toggle and use it every once in a while. As a daily-use feature, it would prolly drive me wild. ;) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: VIM server mode?
On Feb 7, 2008 11:18 PM, sc [EMAIL PROTECTED] wrote: gvim -f %f Yes, I know. It's just not the same, though ;) Thanks :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
VIM server mode?
Hi all, I might have my concepts and/or nomenclature wrong, please excuse me if I do. I know there is a VIM plugin for Eclipse and I think I remember hearing that it was implemented with a server mode of VIM, the plugin only relaying information back and forth. I have been talking with a developer of the stagant Yzis editor, who has also developed KVim back in the days of KDE 2. My question is if the technique the Eclipse plugin is using is different from the one KVim was using back then. If yes, Yzis might be abandoned and KVim revived. As I could then finally use VIM for writing emails in KMail once again, my personal interest is huge ;) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: VIM server mode?
Thanks, I will forward this :) RIchard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Add CTP file extension to PHP files?
Hi all, it seems Cake PHP uses .ctp for its template and code files[1]. I can see no major relevant clashes [2], so I would suggest adding .ctp to the PHP file list. Richard [1] http://www.google.com/search?q=site%3Aapi.cakephp.org+ctpie=UTF-8oe=UTF-8 [2] http://filext.com/file-extension/CTP --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Setting guifont from a modeline
On Jan 22, 2008 8:27 AM, John Beckett [EMAIL PROTECTED] wrote:
My preference would be for Vim to be distributed in a locked
down state, where modelines had only very limited functionality
(local tab settings etc), and a user would have to put something
in their vimrc to enable more modeline features.
For your own sites, you can do something like this:
This function will check if VIM finds modelines and, if yes, will let you
choose if you want to execute them. Edit default to enable or disable,
according to your needs. You can use y and n, as well.
function s:CheckForModelines()
'default' may only be set to e, d, y or n
let default = 'y'
if default != 'e' default != 'd' default != 'y' default != 'n'
echoerr Error in function CheckForModelines: Please set
default to 'e', 'd', 'y' or 'n'
endif
if !exists('+modelines') || modelines 1 || ( !modeline
!exists('b:modeline') )
return -1
endif
let m=''
if modelinesline('$')
sil exe '%g/\vim:\|\vi:\|\ex:/let m=m.\n.getline(.)'
else
sil exe '1,'.modelines.'g/\vim:\|\vi:\|\ex:/let
m=m.\n.getline(.)'
sil exe '$-'.(modelines-1).',$g/\vim:\|\vi:\|\ex:/let
m=m.\n.getline(.)'
endif
if strlen(m)
echo m
let j = '-'
while j != 'e' j != 'd' j != 'y' j != 'n' j != ''
if default == 'e' || default == 'y'
let j = input('Modelines found! [E]nable
[d]isable):','','expression')
elseif default == 'd' || default == 'n'
let j = input('Modelines found! [e]nable
[D]isable):','','expression')
endif
endwhile
let l:modeline = (j=='e' || (j=='' default=='e'))
let b:modeline = 1
endif
endfunction
au BufReadPost * call s:CheckForModelines()
If you use a lot of huge files, you might want to add a check to not go through
them.
RIchard
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: can not compile a GUI version vim on OpenSolaris
2008/1/21 noname wind [EMAIL PROTECTED]: but, I got a vim without ,why? I presume you mean you got a version without X. As you seem to have configured it correctly, I suggest you send the whole output of make to this list so people can look at it :) RIchard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (possibly known) bug with visual block and searchreplace
On Jan 17, 2008 6:53 PM, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: 3) It is in the todo list: Ah, OK, thanks :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (possibly known) bug with visual block and searchreplace
On Jan 16, 2008 2:39 PM, Jürgen Krämer [EMAIL PROTECTED] wrote: this is intended and documented behaviour. It's first mentioned below Have a look at the footnotes of this table (especially footnote (1)). Argh, I totally missed that. Sorry for sending this mail in the first place :/ I could not find the actual rationale for this behaviour, though. Not that I am trying to argue it, I am just interested in why this is. Possible explanations would be 1) a good reason that has escaped me 2) a known caveat that is not urgent to handle as Dr Chip has a script, anyway The behaviour you want can be achieved with an additional script by Dr. Chip. You can download it from the following url Thanks a lot :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch 7.1.230
On Jan 15, 2008 11:17 PM, Charles E Campbell Jr [EMAIL PROTECTED] wrote: This one I figured I might be able to check on -- I mean, how often would garlic show up in the lawbooks? As opposed to something like assault. Anyway, doing a search at Indiana University's virtual law library yielded no hits. Many of those were modified to make them more obscure, thus 'funnier'. One of them is that, in Germany, you are not allowed to start a car when someone is lying under it. The actual law says that you need to ensure that no one can be harmed by you operating the vehicle before you drive it. This includes lights, brakes and, of course, human obstacles. The first version is 'funny', the latter is not, it is just basic common sense. Along the same lines, it might be that you are not allowed to enter any of those three crowded places while stinking so bad as to annoy others. Then someone just picked the most obscure example he could come up with while drunk and went with that. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Set mouse=a causes Vim to hang in screen.
On Jan 15, 2008 8:26 PM, Gautam Iyer [EMAIL PROTECTED] wrote: Ok. Tested. Vim-7.1.229 still hangs on Scientific Linux 5: What are your screen settings? Perhaps they have an influence? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
(possibly known) bug with visual block and searchreplace
Hi all, I know there are some issues with visual block behaving like visual lines sometimes, so this might just be somewhere in the future 'for free', but here goes anyway :) vim -u NONE -U NONE type any text over a few lines esc ctrl-v :s/foo/bar/g If foo appears on the same line as, but outside of, the visual block, it is replaced. The expected behaviour is, of course, that only stuff within the visual block is replaced. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New features to vote on and sponsoring
On Jan 15, 2008 9:55 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: - add collaborative editing: changes made to a file show up in another Vim in a second Unless this is done in full, screen -x is probably better suited. I have to agree that this would be great for mentoring people, though. And yes, I know about the downsides of screen -x, i.e. only one cursor, no parallel editing. - add flexible tab stops, can be used for tables Also, it uses the same tabstops over an entire file. An extended idea is to find some way of specifying different tab widths at different parts of the same file, but that means a heap of empty cans and worms all over the place. Yes, yes, yes and yes. I will move my votes accordingly when I get home. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug in syntax highlighting for ft=mail
Hi all, when you start any line in a mail with 'From', you get highlighting as if this was a header line even if there is a newline between the start of the file and the line you write (i.e. when you are in the body of the mail). The same is try for 'To:' and related words. Why 'From' and not 'From:' suffices to highlight a line, I do not know, I am not familiar with the RFCs in question. To reproduce vim -u NONE -U NONE :syntax on :set ft=mail i Foo From me to you You will see the line starting with 'From' being highlighted. Best regards, Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in FAQ at http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl
On Jan 3, 2008 3:58 AM, Yegappan Lakshmanan [EMAIL PROTECTED] wrote: There used to be a cron job that periodically converted the text version of the FAQ to the HTML version and uploaded it to the Vim online site. I think that stopped working a few years ago. Would it make sense to try and export the wiki to that site or, at least, add warnings to the FAQ pages that they are not current any more and a pointer to the wiki? Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug in syntax/mail.vim
Hi all, to reproduce: vim -u NONE -U NONE :set syntax :set ft=mail ithis newline is for readability http://vim.org/(test) The closing bracket will not be highlighted. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug in syntax/mail.vim
On Jan 10, 2008 4:20 PM, Ben Schmidt [EMAIL PROTECTED] wrote: I suspect it is deliberate. URLs rarely contain parentheses, but are often written inside them in sentences, e.g. There is interesting information on the web (for example, at http://vim.org/). That is true. In case there is an opening bracket in the URL, I do think highlighting the closing bracket as well would make sense, though. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug in FAQ at http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl
Sorry if this is the wrong place, but I could not find any better.. In http://vimdoc.sourceforge.net/cgi-bin/vimfaq2html3.pl at 32.1: -$ stty -ixon -xoff +$ stty -ixon -ixoff Richard PS: Not a real patch as I am certain that this is not the source file, anyway --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Bug in syntax/zsh.vim
Hi all,
Problem:
vim zsh syntax file gets confused by curly brackets in single quotes.
Test cases:
A=${foo['A']}
B=${foo['{']}
C=${foo['C']}
A=${foo['A']}
B=${foo['}']}
C=${foo['C']}
Lines 1 and 3 are irrelevant to the outcome, they just provide examples
of correct and broken syntax hilighting. If you put both examples into one
file, you can see that the brackets are not detected as escaped.
Patch:
None, I failed at coming up with a solution.
Richard
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: indent/html.vim (was: ftplugin/html.vim)
On 06/10/2007, ap [EMAIL PROTECTED] wrote: Of course, typo. The keys are like right next to each other.. scnr, Richard PS: Brownie points for whoever gets the reference without abusing google. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Possible bug related to visual mode
On 02/10/2007, Andy Wokula [EMAIL PROTECTED] wrote: Heh, thanks. I am really amazed by the community around vim :) Did you put that script on the Wiki? I suspect others might like it, as well. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Possible bug related to visual mode
Hi, I suspect that this issue relates to the complete removal of the lines in question. No idea how hard this makes a possible fix. As the issue is not critical (unlikely to be scripted, a human will notice), it might not be worth the effort. Also, I might just no be aware of known behaviour. In any case, here goes: Select visual block: ^v Enter replace mode : R Go into command mode : esc Undo latest change : u Reselect latest vblock : gv Expected behaviour: Visual block mode with the block selected Shown behaviour: Visual line mode with all lines that were part of the block selected. Thanks Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Possible bug related to visual mode
On 02/10/2007, Andy Wokula [EMAIL PROTECTED] wrote: R as a side effect changes the selection into line-wise (to replace the lines and not only the block). After gv, press Ctrl-V to get the blockwise selection back. Why would it need to do that? :n,md (literal d, n m are ints) or any number of other delete options would also suffice if you want to kill whole lines. My intention when pressing R was the same as pressing I in block mode, so I would argue that it would actually make sense not to delete any lines at all. In any case, thanks for your explanation, the behaviour makes sense, now :) Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Possible bug related to visual mode
On 02/10/2007, Tony Mechelynck [EMAIL PROTECTED] wrote:
It might be a feature rather than a bug: see
:help v_R
:help v_S
I _did_ check R, but I never knew v_foo existed. Thanks! Sounds to me as
if my expected behaviour is on Bram To{olong}do list, already :)
Richard
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Fwd: Which versiosn of ZSH of WS instead of NUL as result seperator (wrt: Patch: filename with spaces around ~ (tilde))
-- Forwarded message -- From: Bart Schaefer [EMAIL PROTECTED] Date: 23 Sep 2007 20:58 Subject: Re: Which versiosn of ZSH of WS instead of NUL as result seperator To: [EMAIL PROTECTED] On Sep 23, 8:06pm, Richard Hartmann wrote: } } Sorry, should have posted this [1] right away.. } } [1] http://www.google.com/codesearch?hl=enq=+%22Some+versions+of+zsh+use+spaces+instead+of+NULs+to+separate%22+show:7brZGF5oKIU:mnXLpU4y0PU:6p3TOUN40_wsa=Ncd=1ct=rccs_p=http://www.minix3.org/software/vim-6.3.tar.bz2cs_f=vim-6.3/src/os_unix.c#a0 }-- End of excerpt from Richard Hartmann So if I read this correctly, the question is: Which versions of zsh fail to use NUL between words in the output of print -N? As far as I know, the answer is: Versions of zsh so old that they don't support print -N in the first place. I don't know of any circumstances in which that comment in the vim source is meaningful. Either print -N will fail with bad option or it'll output words separated by NULs. My only conjecture is that the comment predates the code earlier in the file, that uses the STYLE_PRINT flag. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Patch: filename with spaces around ~ (tilde)
On 22/09/2007, Dasn [EMAIL PROTECTED] wrote: It seems to me that at least some of the ZSH handling needs to be left in for the versions that use WS instead of NUL to seperate results. Unfortunately, the comment does not mention _which_ versions this would be. If you want me to, I can try to get a list so this can be tested. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Sourceforge et. al.
On 19/09/2007, krischik [EMAIL PROTECTED] wrote: 1) vim-scripts.sourceforge.net 2) vim-scripts.googlecode.net 3) developer.berlios.de/projects/vim-scripts ;) 1) has become a large corporate monolith 2) has increasing troubles with the whole 'do no evil' thing 3) is a relatively new player and as we all know, underdogs are cool ;) I would go for 3) or 1) As for GIT, Bazaar or some such, I suspect most people do not actually need or even want a distributed source code management system. Also, one would hope that there wouldn't be too much forking. Of course, a trac on vim.org itself would be a nice place, as well. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Bundles
On 17/09/2007, thomas [EMAIL PROTECTED] wrote: Well, I'm no vim developer but read this list nevertheless from time to time. Frankly speaking, I do not fully understand what this is about. Why do you want a new name for files distributed in vba format other than vba (or vimball)? The main reason people seemed to agree on when it was discussed is that this way, you will not miss out on useful stuff that you might miss if it is not in a bundle. Besides, I personally prefer the finer granularity of vim's plugins over Emacs's modes. Personally, I think that the perfect bundle is one that will let you choose what you want to enable and what not while keeping reasonable defaults. Also, if you have good, modularized code, it should still be easy to rip out parts you like. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: firefox and vim was: Re: Feature request... non-uniform tab stops
I don't know why, but neither seem to want to work with iceweasel.. Any ideas why that could be? I tried gvim with and without full path, neither worked. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Feature request... non-uniform tab stops
On 31/08/2007, Tony Mechelynck [EMAIL PROTECTED] wrote: IIUC: iiuc? - yzis may be alive but I haven't heard much about it on this list. I used to check their website regularly, but nothing on there :/ - gvim with Gnome2 GUI is standard (the sources are part of Bram's distributions), it works quite well under kde, and (among other goodies) saves and restores its session transparently when you log out of / into the kde winmanager. Bram says it has bugs but none of them has bitten me yet. Problem is that this will not integrate into KDE as an embedded editor. For example, I normally write emails with pine vim. Using Kontact their editor is extremely slow and painful (not as painful as using the GMail interface without fixed width fonts or tw=72 which means I need to guess the formatting..) when replying to more complex mails. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Feature request... non-uniform tab stops
On 28/08/07, Zdenek Sekera [EMAIL PROTECTED] wrote: there has been other attempts in the past to suggest or even to try to implement such a feature, one the most attractive (to me) seemed to be the 'elastic tabstops' suggested in this forum by Nick Gravgaard around Oct last year If I remeber that concept right it might hit the same spot as my suggestion of 'AutoAlign'. Back then, it was proposed as a formatting (not identing) option which is inherently evil (set autoindent; set copyindent anyone?), but for displaying data that just happens to have different lengths, it would be great. That thing could then save back into the expanded tabstop variable, offering the full experience, so to speak. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Proposal: Modes for Vim
On 26/08/07, krischik [EMAIL PROTECTED] wrote: My proposal (if you have not guessed already) is to merge more separate plug ins into modes. What do you think about the idea? While I do not maintain any vim plugins, this suggestion makes sense to me. Richard --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
