Re: Dynamic folding in 2html.vim output
Ben Fritz wrote: I just realize my patch doesn't handle the g:html_no_pre option. I'll make another patch in the next day or two to also handle this option (I notice I'll need to get the latest from FTP again). Bram, once I fix the handling of g:html_no_pre, is there a reason not to include this in the official script? I haven't looked in detail at the changes yet. I'm first awaiting comments. If the change looks like it won't break anything when folding is off it should be OK to include. -- hundred-and-one symptoms of being an internet addict: 69. Yahoo welcomes you with your own start page /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Create vimballs from the command-line
Hi folks, Maybe somebody has some use for this. I wrote a small ruby script that allows the creation of vimballs (plain text or gzipped) from the command line. It's still young and fresh and experimental. I ran it over my own plugins and the generated vimballs are identical to those created by vimball.vim. Tested with ruby 1.8 (cygwin). Raison d'être: I wanted something that can run from a makefile and that doesn't care about the runtimepath. Download: http://github.com/tomtom/vimtlib/blob/a2f709d195f708147db51e79274155e51f7b7b47/ruby/vimball.rb Please tell me if the script doesn't work with your recipes/vimballs. Regards, Thomas. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Tue, Feb 10, 2009 at 12:53:15PM -0800, Tom Link wrote: Maybe somebody has some use for this. I wrote a small ruby script that allows the creation of vimballs (plain text or gzipped) from the command line. I'm still curious what purpose vimballs serve over a standard archive format like zip or tar.gz. From a distribution perspective, all they've done is made my work harder when trying to include vim scripts in a package for a Linux distribution. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com signature.asc Description: Digital signature
Re: Create vimballs from the command-line
On Tue, Feb 10, 2009 at 4:35 PM, Charles Campbell wrote: James Vega wrote: I'm still curious what purpose vimballs serve over a standard archive format like zip or tar.gz. From a distribution perspective, all they've done is made my work harder when trying to include vim scripts in a package for a Linux distribution. * they automatically enable help for any enclosed help files * files go where they need to; they're not dependent on the user changing to the appropriate directory first. * one may uninstall the files extracted by a vimball (:RmVimball vimballname) * the vimball itself requires no addtional tools beyond vim itself (compression/decompression is another matter) But let's not forget that they have significant disadvantages, too... Vimballs made with new versions of the plugin don't work on older vims. Considering that those writing and distributing scripts are much more likely to be at the bleeding edge than the users who download those scripts, they're quite likely to wind up distributing something that many of their users can't use. It's also not possible to include binary files in a vimball, or fines with different encodings, or even files with different line endings. IMHO, this makes them significantly less useful than zip files, since we could add those 3 nice features (automatic :helptags, extracted to first writable directory, uninstallable) to zip files without having to tolerate the disadvantages that vimball doesn't seem to be able to overcome... Really, it seems that depending on an unzip program being on the computer is far better than implementing our own barely-featured interface-unstable self-extracting-archive-that-wants-to-be-a-zipfile. I think that an effort to nicely encapsulate the platform differences and such of handling zipfiles, or possibly even one day writing a vimscript unzipper, would be a better use of our resources than continuing to maintain vimball. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: help for a git newbie -- no merge candidate found
Hi and thanks for giving the git repo a try. _sc_, 06.02.2009: FIVE line 139 git mergetool showed nothing that needed to be fixed This is only needed, if merge conflicts arise. You will notice it, if it's the case. lines 147-232 of the README detail a merge of runtime files that looked both confusing and unnecessary -- we got the runtime when we chose vim-with-runtime back in step three -- so far no gaps in the runtime have presented themselves lines 235-254 also has to do with runtime, but, as above, we already have it -- this section appears to be if you want a git branch of just runtime lines 257-275 show how to use rsync to update the runtime into git's origin/stuff branch, No, the runtime files are updated in the currently checked out branch. I use the branch 'vim-runtime' therefor, of course. whatever that is, The stuff branch contains the git repo specific files (docs and scripts). but again we already have the runtime, and I *think* future 'git pull's will retrieve updates to the runtime as well as the source Yes, all your assumptions above are correct. I think I should move the custom branch part to Basic use since it definetly is something that most people will use. Then the Advanced use will only contain uninteresting stuff. Probably these two categories should be renamed to For users and For developers or so, since it was mainly used to document what I did to setup and do to maintain the branches. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: help for a git newbie -- no merge candidate found
_sc_, 07.02.2009: On Friday 06 February 2009 4:09 pm, Matt Wozniski wrote: and my .git/config contains: Somehow, you're missing this: [branch custom] remote = origin merge = refs/heads/vim-with-runtime and adding that in should make things work just fine... indeed it does 06 Feb 2009 16:52 Fri Already up-to-date. thank you a lot Matt, that made all the difference markus: i don't know what i did different than matt -- Maybe you have an old git version installed, where the automatic setup of .git/config for the remote tracking branches (during the command git checkout -b custom origin/vim-with-runtime) was not yet the default. If this is the case, either set branch.autosetupmerge to true or update git, which is of course recommended. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: need new relative number patch
_sc_, 05.02.2009: since the patch no longer works i'd recommend an update to vim's patch page: http://groups.google.com/group/vim_dev/web/vim-patches which still contains a link to http://groups.google.com/group/vim_dev/browse_thread/thread/a6dd45468531f4e#msg_10fa0944a8b643b4 Sure. John, please replace the link with http://repo.or.cz/w/vim_extended.git Thanks. ...just when i was getting comfortable with svn... Oh, you are new to svn? Then it makes even more sense to directly begin with another VCS :) Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim_extended/vim_mainline git repos independent of svn repo
Christian MICHON, 06.02.2009: On Thu, Feb 5, 2009 at 10:23 PM, Markus Heidelberg markus.heidelb...@web.de wrote: What do you think about the commit message format, is it ok? I searched for a git-like message, without losing information. The duplicated first line of the problem description is unavoidable I think, because it should be fully automated and the first line shouldn't merely contain the patch number. you're facing the same problem I faced in July. I noticed (example 7.2.102) the commit message is truncated. so we're even here: I've the same issue and this requires somehow manual intervention. :( James does manual intervention in his Debian repo, but for me it absolutely has to run automated. These truncated sentences aren't nice, but one can live with that. overall, I like the [7.2.102] header ;-) Idea from the Debian repo :) Normally you wouldn't even have to worry about the updates from the repo later: if you pull, you will simply be already up to date, since the commits you created have the same SHA1s than mine. no, this is wrong: if commits created from different people would be having the same SHA1s, we'd be in deep trouble. Please re-phrase, it's unclear. No, it's correct indeed, if you use vim-update.sh from the stuff branch. I shouldn't have added an empty line between the text you quoted and the following from my previous mail, note the text same script: But if you think no, I'm too slow, that's too late, you can use the same script I'm using and comfortably fetch and apply the patches yourself. It's available in the stuff branch. Author/committer name/email/date have the same values, regardless whether you or I update the repo with the vim-update.sh script. The patch is the same anyway, so the blobs and trees are equal. So the whole content is equal and leads to the same commit id (SHA1). Test it! OK, this should be the desired case, but it's currently not true, the SHA1s can differ dependent on the time zone. This will be fixed, I just don't know exactly, how. Should I just assume UTC offset +, which is wrong? The time zone information is not included in the patch file. My current time zone is the same as Bram's :) I solved this issue by using info from the patch directly: version.c is always modified and is a good indication to when the patch was made. No, you didn't get me. I use the date from src/version.c as well. But this date doesn't contain an UTC offset and hence the offset of my timezone is used for creating the commit. A new branch is online: fix/fast-join It contains the patches for the improved :join algorithm from Milan Vancura. It is not yet included in the monster 'master' branch due to lack of time. I have to pack for FOSDEM, have to get up at 4 AM. Anybody else there? nope, won't be there: have fun! Had fun. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim_extended/vim_mainline git repos independent of svn repo
James Vega, 06.02.2009: On Thu, Feb 05, 2009 at 10:23:33PM +0100, Markus Heidelberg wrote: What do you think about the commit message format, is it ok? I searched for a git-like message, without losing information. The duplicated first line of the problem description is unavoidable I think, because it should be fully automated and the first line shouldn't merely contain the patch number. Using 7.2.093 as an example, here's what I use for the upstream branch of the Debian repo: [7.2.093] (extra) dialogs can't always handle multi-byte text I decided to discard the (extra) or (after 7.2.xxx) comments in the summary. But to not lose information, I put this Patch 7.2.093 (extra) at the last line. This isn't very nice, but the summary line will stay below 80 chars with the automated extraction of the complete first Problem line. But why this extra and the distinction between Unix and non-Unix at all? Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Matt Wozniski wrote: But let's not forget that they have significant disadvantages, too... Vimballs made with new versions of the plugin don't work on older vims. There's been one problem with that -- 7.0 vimball doesn't handle the later vimball versions. 7.1 and has been compatible; newer vimballs have largely fixed small problems, not introduced incompatibilities. Vimball was done by request, consequently it didn't have much feedback before it went into 7.0. Considering that those writing and distributing scripts are much more likely to be at the bleeding edge than the users who download those scripts, they're quite likely to wind up distributing something that many of their users can't use. It's also not possible to include binary files in a vimball, or fines with different encodings, or even files with different line endings. I think that I could get vimball to handle binary files, which would mean that zip files could be embedded. However, most plugins don't need binary files (those with icons for signs would be an exception). IMHO, this makes them significantly less useful than zip files, since we could add those 3 nice features (automatic :helptags, extracted to first writable directory, uninstallable) to zip files without having to tolerate the disadvantages that vimball doesn't seem to be able to overcome... Really, it seems that depending on an unzip program being on the computer is far better than implementing our own barely-featured interface-unstable self-extracting-archive-that-wants-to-be-a-zipfile. I think that an effort to nicely encapsulate the platform differences and such of handling zipfiles, or possibly even one day writing a vimscript unzipper, would be a better use of our resources than continuing to maintain vimball. And putting these vim-specific features into zip files would be real popular with the rest of the zip community, I'm sure. At the very least, it'd be bloat for most such users. Then some other applications would want to chime in with their own application specific features. It'd be better to have a plugin that acted as a wrapper around zip to support the additional features that vimball provides. Probably could be a modification to the current zip handling plugin. The same sort of mods could be done with tar and the tar handling plugin, too. I'll consider doing it (after taxes and fafsas). Chip --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 2/11/09, Tom Link micat...@gmail.com wrote: Hi folks, Maybe somebody has some use for this. I wrote a small ruby script that allows the creation of vimballs (plain text or gzipped) from the command line. It's still young and fresh and experimental. I ran it over my own plugins and the generated vimballs are identical to those created by vimball.vim. Tested with ruby 1.8 (cygwin). Raison d'être: I wanted something that can run from a makefile and that doesn't care about the runtimepath. You can specify the base path with the final arg to MkVimball. snip Regards, Doug --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
You can specify the base path with the final arg to MkVimball. If you wanted to create vimballs from cygwin bash by calling Windows gvim (you could of course use cygwin's vim but ...), you'd have to convert the path which works most of the time but can be cumbersome. But thanks for reminding me of that extra argument. Regards, Thomas. --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
