Re: Vim Lib [Was: List Questions]
> So for a start, I am proposing a "VimLib" project, maintainable by the Vim > community, written entirely in VimL and except from one function (see > below) it will independent from the vim official distribution. > It's based on personal experiments and from the work > of Marc Weber and Luc Hermitte. How does your proposal differ from Marc Weber's approach[1] that is IIRC meant as a community project too. [1] http://github.com/MarcWeber/theonevimlib/tree/master --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: when you do ':bnext' syntax-highlighting does not work in some states.
On 07/02/09 07:27, Dewr wrote: > it keeps its filetype even if you didn't give ":setlocal bufhidden=hide". > anyway! Vim keeps syntax-highlighting when I've used ":setlocal > bufhidden=hide" before I use "bnext"|"bprevious". > Then I think it's working as it should (though it may surprise you). If you "hide" the buffer, it keeps everything. If you "unload" it, some of the information (including, maybe, the buffer-local 'syntax' set by hand) gets lost. Another way to keep everything is to use split-windows or tab pages. When not in use, it is possible to reduce a split-window to only a status line and nooothing else (if 'winminheight' is zero) and a tab page to even less than that. Best regards, Tony. -- Five is a sufficiently close approximation to infinity. -- Robert Firth --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: when you do ':bnext' syntax-highlighting does not work in some states.
it keeps its filetype even if you didn't give ":setlocal bufhidden=hide". anyway! Vim keeps syntax-highlighting when I've used ":setlocal bufhidden=hide" before I use "bnext"|"bprevious". 2009/2/6 Tony Mechelynck > 듀르、 if you use > ":setlocal bufhidden=hide" on the first buffer (before using ":bnext"), > does it keep its filetype then? > > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Lib [Was: List Questions]
> Luc, which unit testing framework are you talking about? A vim.sf.net search points to http://www.vim.org/scripts/script.php?script_id=1125 I once wrote http://www.vim.org/scripts/script.php?script_id=1730 that is supposed to solve a similar purpose although it's still quite minimalist. Regards, Thomas. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Visual Block + cursorcolumn highlighting
On 07/02/09 05:19, James Vega wrote: > On Sat, Feb 07, 2009 at 04:48:16AM +0100, Tony Mechelynck wrote: >> On 07/02/09 04:10, Brian Carper wrote: >>> When you have cursorcolumn set and you go into Visual Block mode, the >>> background highlighting for cursorcolumn overrides the background >>> highlighting for visual mode. This makes it difficult to see what's >>> selected in the column containing the cursor (especially if you move >>> the cursor up/down before moving it left/right). >>> >>> It seems like entering Visual mode should disable the highlighting for >>> cursorcolumn, similarly to how it disables the highlighting for >>> cursorline. >>> >>> e.g. something vaguely similar to (but probably not exactly) this: >> I think it's a feature. In Block Visual mode, the cursor is always at >> one corner of the block, and its row and column are included in the >> block (or rather, the part which is along the sides of the block-visual >> area). So there is no ambiguity in having the coc highlight overlay the >> block visual highlight, unless maybe the block is only one column wide. > > Whether it's a feature or a bug, the behavior is inconsistent. It would > seem that either both 'cuc' and 'cul' should be enabled or neither > should. > I think I remember Bram telling me some months ago that it's intentional and a kind of compromise. I don't remember the details out of my head but you might want to google the list archives. Best regards, Tony. -- "When I die, I want a tombstone that says "GAME OVER" - Ton Richters --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Visual Block + cursorcolumn highlighting
On Sat, Feb 07, 2009 at 04:48:16AM +0100, Tony Mechelynck wrote: > > On 07/02/09 04:10, Brian Carper wrote: > > When you have cursorcolumn set and you go into Visual Block mode, the > > background highlighting for cursorcolumn overrides the background > > highlighting for visual mode. This makes it difficult to see what's > > selected in the column containing the cursor (especially if you move > > the cursor up/down before moving it left/right). > > > > It seems like entering Visual mode should disable the highlighting for > > cursorcolumn, similarly to how it disables the highlighting for > > cursorline. > > > > e.g. something vaguely similar to (but probably not exactly) this: > > I think it's a feature. In Block Visual mode, the cursor is always at > one corner of the block, and its row and column are included in the > block (or rather, the part which is along the sides of the block-visual > area). So there is no ambiguity in having the coc highlight overlay the > block visual highlight, unless maybe the block is only one column wide. Whether it's a feature or a bug, the behavior is inconsistent. It would seem that either both 'cuc' and 'cul' should be enabled or neither should. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: Visual Block + cursorcolumn highlighting
On 07/02/09 04:10, Brian Carper wrote: > When you have cursorcolumn set and you go into Visual Block mode, the > background highlighting for cursorcolumn overrides the background > highlighting for visual mode. This makes it difficult to see what's > selected in the column containing the cursor (especially if you move > the cursor up/down before moving it left/right). > > It seems like entering Visual mode should disable the highlighting for > cursorcolumn, similarly to how it disables the highlighting for > cursorline. > > e.g. something vaguely similar to (but probably not exactly) this: I think it's a feature. In Block Visual mode, the cursor is always at one corner of the block, and its row and column are included in the block (or rather, the part which is along the sides of the block-visual area). So there is no ambiguity in having the coc highlight overlay the block visual highlight, unless maybe the block is only one column wide. In the latter case, temporarily moving the cursor left or right will widen the block and tell you where it is. Or you could hit oOoO in succession to see the four corners of the block (o moves to the diagonally opposite corner, O to the horizontally adjacent corner). Best regards, Tony. -- After an instrument has been assembled, extra components will be found on the bench. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Visual Block + cursorcolumn highlighting
When you have cursorcolumn set and you go into Visual Block mode, the
background highlighting for cursorcolumn overrides the background
highlighting for visual mode. This makes it difficult to see what's
selected in the column containing the cursor (especially if you move
the cursor up/down before moving it left/right).
It seems like entering Visual mode should disable the highlighting for
cursorcolumn, similarly to how it disables the highlighting for
cursorline.
e.g. something vaguely similar to (but probably not exactly) this:
Index: src/screen.c
===
--- src/screen.c(revision 1356)
+++ src/screen.c(working copy)
@@ -4557,7 +4557,8 @@
* highlight the cursor position itself. */
if (wp->w_p_cuc && vcol == (long)wp->w_virtcol
&& lnum != wp->w_cursor.lnum
- && draw_state == WL_LINE)
+ && draw_state == WL_LINE
+ && !VIsual_active)
{
vcol_save_attr = char_attr;
char_attr = hl_combine_attr(char_attr, hl_attr(HLF_CUC));
--~--~-~--~~~---~--~~
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
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 -- although i do remember being surprised when i realized i had done most of the heavy lifting while d out of a midnight_commander window, but i can't imagine how that might have hurt anything i hope you have fun at FOSDEM, and thank you too -- this git repository represents a lot of good work sc --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Lib
On Fri, Feb 6, 2009 at 1:50 PM, Larson, DavidX S wrote: > > ... > > H... rings a bell. Are you modeling this after the Perl CPAN module > structure (search.cpan.org)? That setup is obviously very successful. > Looking at the differences of perl and vim, I have a few thoughts: > > 1.) The "use lib..." structure in perl is built into the language, and vim > does not have an equivalent. Perhaps this would be a good, straightforward > feature to add to the next version of vim? Do you have to wait for the next version? I would think it's a simple command you would define in autoload(unless you really, really want it to start lowercase). And if the goal(as was stated) is to keep this *seperate*from the vim distribution then you don't want it added to the next version of vim at all. > 2.) "The purpose of this project is to create stable functions to return > values or to execute actions." That leaves out much of the valuable > brainwork on vim.org, since many of the scripts in vim are meant to be > self-contained, the user only needs a macro (usually) to start the script. > Can we think of a way to include those as well? > Not really, if you want to model CPAN. Self contained scripts are exactly what you should be writing if you have no idea of the env it will be run in. If you're building a framework then scripts should use the framework, otherwise you duplicate a huge amount of work and get some crazy inconsistencies. The repository would use them in that the code would be refactored to use other functions and be used by other functions, but stand alone functions in general would be poor practice. Note, however, that a versioning repository gives a lot of flexability. There's no reason you couldn't put stand alone scripts in there with a note that they need to be refactored later. > That pretty much leave us with just one option, because I don't think that > there is someone with sane mind that will volunteer to take the lonely > first path. Besides that, a scratch project is always refreshing and almost > guaranteed to give energy (Note: this is not an excuse to leave your > marriage!). It's not really starting over. It's setting up a singular place for current scripts to be re-factored to. I think very little in the way of new intellectual capitol will be needed(good thing, I'm broke). I would throw a few suggestions in there: 1. This highlights the other part of my original post, that VimL development and Vim development are separate and should have thier own mail lists/groups/bathrooms. 2. It makes much more sense to me for a simple subversion repository under vim.org as opposed to having it hosted by google code or some other third party. While it makes sense for an individual when you already have a site I don't like being sent to the far corners of the internet to get code. Also, I'd like to have access to older version of scripts or be able to diff the latest with my modfied version. 3. I would suggest 2 more categories: 1. *autoload/lang* Since Vim is, first and foremost, an editor it would make sense to have a separate area to support each language. It would hold things like code beautifiers, debugger/profiler integration and the like. 2. *autoload/opt* This would house optional, aplication-like scripts. For example the functionality to do curses like menu's might be under autoload/util/curses.vim and my erotic text game which utilizes that but wouldn't be used by any other scripts(can we start calling them modules at this point?) would be at autoloat/opt/CupidAches.vim A final thought, will a move like this necessitate stronger data structures? There isn't much you can't represent with dictionaries and lists but I could see passing data between disparate functions getting nightmarish. Would a simple "named dictionary" with pre-defined keys and default values(a struct) make life a lot easier? --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Tabbing in VisVim
Hi all, I just put together a small patch to add tab support to VisVim. Enjoy! -- Adam Slater --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- VisVim.diff Description: Binary data
Re: help for a git newbie -- no merge candidate found
On Fri, Feb 6, 2009 at 4:12 PM, _sc_ wrote: > > forgive me if this post is long winded but i find myself > unable to perform a 'git pull' and i don't know where along > the line i did the wrong thing That's a good question. Your steps should work. > also my steps and mis-steps may provide guideposts for > others wanting to test the git waters > > starting from markus' now famous url >git clone git://repo.or.cz/vim_extended.git Initialized empty Git repository in /tmp/vim_extended/.git/ remote: Counting objects: 11141, done. remote: Compressing objects: 100% (2748/2748), done. remote: Total 11141 (delta 8372), reused 11129 (delta 8360) Receiving objects: 100% (11141/11141), 12.92 MiB | 1145 KiB/s, done. Resolving deltas: 100% (8372/8372), done. >cd vim_extended $ git config branch.custom.merge # Here, this returns 1 - pulling into branch custom would give the error you get. >git checkout -b custom origin/vim-with-runtime Branch custom set up to track remote branch refs/remotes/origin/vim-with-runtime. Switched to a new branch "custom" $ git config branch.custom.merge refs/heads/vim-with-runtime # And now, you should no longer get that error. $ git pull Already up-to-date. # sure enough... >git merge origin/feat/rel-line-numbers 22 files changed, 207 insertions(+), 60 deletions(-) >git mergetool No files need merging > lines 257-275 show how to use rsync to update the runtime into git's > origin/stuff branch, whatever that is, 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 AFAIK, they should - since you based the branch off vim-with-runtime and not just vim. > from here it was a matter of first forgetting, then remembering to > update src/feature.h to remove some code bloat i know i will never > want -- then a typical make and make install -- all went > well, vim 7.2.102 was successfully built and installed with > the relative number patch, and i went to bed happy Something you did in here must have been relevant, because... > on day two it was time to test our installation and perform > our first 'git pull' > > #!/bin/bash > tail ~/.build/vim/vim72/vim_extended/update.log > dttm | tee -a ~/.build/vim/vim72/vim_extended/update.log > git pull 2>&1 | tee -a ~/.build/vim/vim72/vim_extended/update.log > dsh 60 | tee -a ~/.build/vim/vim72/vim_extended/update.log $ git pull Already up-to-date. > this did not go well -- it yielded: > > Warning: No merge candidate found because value of config option > "branch.custom.merge" does not match any remote branch fetched. $ git config branch.custom.merge refs/heads/vim-with-runtime > for me, git branch -a shows: I see the same... > 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... > so now you see how someone new to git might go astray trying > to follow the README -- or maybe if markus is too busy at > FOSDEM someone else can help before he gets back... Strange, though... following the same steps as you, it worked fine for me. Wonder what the difference was. ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Vim Lib
> The purpose of this project is to create stable functions to return values > or to execute actions. > A sample directory structure could be: > > autoload/lib > autoload/util > autoload/buffer > autoload/cmdline > autoload/time > ... > > Sample functions/scripts: > > autoload/lib/filelist > autoload/util/scratch > autoload/buffer/bufferlist > autoload/cmdline/removelastpathcomponent > autoload/time/weekday > ... > > A developer that wants to utilize such a function, should include on the > top of the implementation, a standard code block to request the function. ... H... rings a bell. Are you modeling this after the Perl CPAN module structure (search.cpan.org)? That setup is obviously very successful. Looking at the differences of perl and vim, I have a few thoughts: 1.) The "use lib..." structure in perl is built into the language, and vim does not have an equivalent. Perhaps this would be a good, straightforward feature to add to the next version of vim? 2.) "The purpose of this project is to create stable functions to return values or to execute actions." That leaves out much of the valuable brainwork on vim.org, since many of the scripts in vim are meant to be self-contained, the user only needs a macro (usually) to start the script. Can we think of a way to include those as well? 3.) Chip Campbell's GetLatestVimScripts plugin should be leveraged. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Lib [Was: List Questions]
On 06-Feb-09 22:17, Luc Hermitte wrote: > BTW, a good Unit Testing framework is most welcomed. There is > already one, but it lacks quickfix integration, and a > simple :command-like syntax. Luc, which unit testing framework are you talking about? I'm currently building one for testing my own scripts, as manual regression testing soon becomes too tedious. (I plan to publish my framework in a few weeks, right now the test runner only works on Windows.) -- regards, ingo -- -- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ -- -- A lie can be half round the world before the truth has its boots on. -- BBC --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim Lib [Was: List Questions]
Hello, "Agathoklis D. Hatzimanikas" : > So for a start, I am proposing a "VimLib" project, maintainable by the > Vim community, written entirely in VimL and except from one function (see > below) it will independent from the vim official distribution. So far there are two such projects I'm aware of. I'm maintaining one [see my signature], and Marc Weber another one. We have already considered merging parts of what we have written so far. Unfortunately I don't much time for vim right now, and I'd like to finish my boost::bind-like autoload plugin first. BTW, a good Unit Testing framework is most welcomed. There is already one, but it lacks quickfix integration, and a simple :command-like syntax. > A developer that wants to utilize such a function, should include on > the top of the implementation, a standard code block to request the > function. I totally agree with the approach. The NIH syndrom is nice but quite tiring on the long run. > Problems that have to be resolved, or things that have to be done: > >- a mailing list; a vim_plugin perhaps >- a host for the project (code google?) That's where I'm hosting all my scripts. The hosting is nice so far, however I'm not happy with the wiki which is quite limited. >- a version control system (svn, mercurial or git are popular and > portable solutions (there is a git port for windows I think)) Marc had a git or mercurial solution in mind. I don't remember exactly. > Possible system enhancements or things that need decisions: > > - a function database May be we can just start small with what we currently have. > - separation of the implementation and the configuration > - a quoting from Bram: > "If there is one thing I would like to work on, given enough > time, is > to compile Vim script into some kind of byte code." > that will give a boost to the plugin performance Marc had interesting thoughts on versionning that should be addressed in the earliest stages preferably (is it English?). > That was just a first draft, that can be serve for inspiration or > just to be the first brick of a stable, flexible and viable 'plugin' > system/foundation. It's based on personal experiments and from the > work of Marc Weber and Luc Hermitte. Ah! You were already aware of our work. :) As far as I'm concerned, I'd be glad to contribute with my core library plugins (lh-vim-lib, and may be lh-map-tool (even if people seems to like reimplementing placeholder related functions and mappings)) > But it's really up to the community to create something exciting, > practical and useful, for the benefit of the current user base and > for the next generation of vim users. Indeed. -- Luc Hermitte http://lh-vim.googlecode.com/ http://hermitte.free.fr/vim/ --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
help for a git newbie -- no merge candidate found
forgive me if this post is long winded but i find myself unable to perform a 'git pull' and i don't know where along the line i did the wrong thing also my steps and mis-steps may provide guideposts for others wanting to test the git waters starting from markus' now famous url http://repo.or.cz/w/vim_extended.git i found a README (with line numbers!) at a Documentation link and tried to pick out what i needed i created a new path for the experiment: ~/.build/vim/vim72 (when using svn the path wanted to be ...vim7.2, so this is cleaner) < ONE > from line 85 of the README git clone git://repo.or.cz/vim_extended.git < TWO > from line 92 cd vim_extended < THREE > line 121 git checkout -b custom origin/vim-with-runtime < FOUR > line 125 git merge origin/feat/rel-line-numbers < FIVE > line 139 git mergetool showed nothing that needed to be fixed 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, whatever that is, 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 from here it was a matter of first forgetting, then remembering to update src/feature.h to remove some code bloat i know i will never want -- then a typical make and make install -- all went well, vim 7.2.102 was successfully built and installed with the relative number patch, and i went to bed happy on day two it was time to test our installation and perform our first 'git pull' #!/bin/bash tail ~/.build/vim/vim72/vim_extended/update.log dttm | tee -a ~/.build/vim/vim72/vim_extended/update.log git pull 2>&1 | tee -a ~/.build/vim/vim72/vim_extended/update.log dsh 60 | tee -a ~/.build/vim/vim72/vim_extended/update.log this did not go well -- it yielded: Warning: No merge candidate found because value of config option "branch.custom.merge" does not match any remote branch fetched. for me, git branch -a shows: ~/.build/vim/vim72/vim_extended $ git branch -a * custom master origin/HEAD origin/feat/code-check origin/feat/emb-common-lisp origin/feat/float-point-ext origin/feat/lua origin/feat/rel-line-numbers origin/feat/var-tabstops origin/fix/fast-join origin/master origin/stuff origin/vim origin/vim-runtime origin/vim-with-runtime and my .git/config contains: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = git://repo.or.cz/vim_extended.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master so now you see how someone new to git might go astray trying to follow the README -- or maybe if markus is too busy at FOSDEM someone else can help before he gets back... sc --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Vim Lib [Was: List Questions]
Hi John, On Fri, Feb 06, at 10:44 John Beckett wrote: > > Garrett Whelan wrote: > > 3) Is there a central repository of vim scripts/extentions? > > It seems rather haphazard to me. I often find 4-5 scripts > > that solve my problem with little documentation for any and > > none of them have been updated for years. > > www.vim.org and click scripts is the central repository. Yes, it is > haphazard. Ideally a team of 10 full time experts would weed out 95% of > the scripts (delete them), and enhance the remaining 5%. An exaggeration (in my opinion) but again not far from the truth. But this is a quite interesting topic, and is a problem that (we) will face it and (we) will have to deal with it, soon or later. Some facts: - (most) plugins don't take advantage of the 'autoload' mechanism - (many) plugins overlap functionality with others - too much evaporated code or functions that solve same or similar problems (few plugins share some code) - no bug tracker or no mailing list, so no review, no feedback and no bug tracking - no revision control so no logs and history - pure categorization - unmaintainable or poor quality plugins It seems that we have two paths that we can take: a. Enhance, fix and reorganize the existing infrastructure. b. Start from the scratch That pretty much leave us with just one option, because I don't think that there is someone with sane mind that will volunteer to take the lonely first path. Besides that, a scratch project is always refreshing and almost guaranteed to give energy (Note: this is not an excuse to leave your marriage!). So here are some thoughts: The whole (new) system should (should as in http://www.ietf.org/rfc/rfc2119.txt ) be based in the 'autoload' mechanism. The main advantages of the autoload functions are: - fast vim startup - less memory consumed, since they just loaded when you really need them (when you call them via a mapping, a command or another function) - the directory and file/plugin structure can be organized with absolutely no limits - it's perfect for sharing code between the various implementations So for a start, I am proposing a "VimLib" project, maintainable by the Vim community, written entirely in VimL and except from one function (see below) it will independent from the vim official distribution. The purpose of this project is to create stable functions to return values or to execute actions. A sample directory structure could be: autoload/lib autoload/util autoload/buffer autoload/cmdline autoload/time ... Sample functions/scripts: autoload/lib/filelist autoload/util/scratch autoload/buffer/bufferlist autoload/cmdline/removelastpathcomponent autoload/time/weekday ... A developer that wants to utilize such a function, should include on the top of the implementation, a standard code block to request the function. If it's not available then a similar to the "spellfile.vim" plugin, can make the request to the web repository to download and install the required file. This is the only required plugin that should be included to the official vim distribution. The functions should return *expected* values and data types and though obviously the implementation can be under development, the developer doesn't have to care about (the implementation). This is a concept similar or known as "encapsulation" in the object oriented languages. Problems that have to be resolved, or things that have to be done: - a mailing list; a vim_plugin perhaps - a host for the project (code google?) - a version control system (svn, mercurial or git are popular and portable solutions (there is a git port for windows I think)) Possible system enhancements or things that need decisions: - a function database - separation of the implementation and the configuration - a quoting from Bram: "If there is one thing I would like to work on, given enough time, is to compile Vim script into some kind of byte code." that will give a boost to the plugin performance That was just a first draft, that can be serve for inspiration or just to be the first brick of a stable, flexible and viable 'plugin' system/foundation. It's based on personal experiments and from the work of Marc Weber and Luc Hermitte. But it's really up to the community to create something exciting, practical and useful, for the benefit of the current user base and for the next generation of vim users. > John Regards, Ag. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Google summer of code
Hello Bram and all, I was one of the previous students. This summer I was planning to finish what I had started (the code checking extension, since I am a graduate student, working on it during the semesters is extremely hard). I am totally flexible about how to do this: 1. I can re-apply as a student. I would not need as much help from a mentor as a brand new student would. 2. I can apply as a mentor if you think I am qualified to. The student can work on CodeCheck.c or some other thing. 3. I can do this without actually getting associated with GSOC in an informal way. Take care, On Fri, Feb 06, 2009 at 08:04:30PM +0100, Bram Moolenaar wrote: > > > The past few years Vim was a project in the Google summer of code (SoC). > This means a few students get paid for working on the Vim source code. > This varied from fixing bugs to implementing new regular expression > code. > > This year I will be on a holiday halfway the months that the SoC is > running. It's unacceptable for the students to be without guidance. > Thus I'm wondering if there are a few people who feel that they will be > able to help mentoring a student. > > Since there probably isn't a person who dares to do this by himself, the > preferable way would be to make teams of at least two mentors per > student. This can be mixed, e.g., being the main mentor for one student > and the backup mentor for another. > > The main work will be: > - Judging student applications before the SoC begins. > - Keeping in touch with the student. Check that he is actually doing > something useful. Help him make choices. > > I'll be around to help out, except for the three weeks I'm away. But it > would be good for me to be the administrator, and assign a mentor to > each student. Mentors can of course also help each other. > > If we can have a few volunteers that want to help out I can again apply > Vim for the SoC. Otherwise we will have to skip a year. > > More information about the SoC: http://code.google.com/soc/2008/ > > -- > ERROR 047: Keyboard not found. Press RETURN to continue. > > /// 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/// > > > -- Birgi --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Google summer of code
The past few years Vim was a project in the Google summer of code (SoC). This means a few students get paid for working on the Vim source code. This varied from fixing bugs to implementing new regular expression code. This year I will be on a holiday halfway the months that the SoC is running. It's unacceptable for the students to be without guidance. Thus I'm wondering if there are a few people who feel that they will be able to help mentoring a student. Since there probably isn't a person who dares to do this by himself, the preferable way would be to make teams of at least two mentors per student. This can be mixed, e.g., being the main mentor for one student and the backup mentor for another. The main work will be: - Judging student applications before the SoC begins. - Keeping in touch with the student. Check that he is actually doing something useful. Help him make choices. I'll be around to help out, except for the three weeks I'm away. But it would be good for me to be the administrator, and assign a mentor to each student. Mentors can of course also help each other. If we can have a few volunteers that want to help out I can again apply Vim for the SoC. Otherwise we will have to skip a year. More information about the SoC: http://code.google.com/soc/2008/ -- ERROR 047: Keyboard not found. Press RETURN to continue. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: PATCH: avoid unnecessary copying of location list when creating a quickfix/location list window
Lech Lorens wrote: > When splitting a window, all the location lists of the original window > are copied to the newly created one. If the newly created window is a > quickfix window or a location list window, the copied locations lists > are immediately destroyed. The attached patch prevents the copying if it > is unnecessary. This can shorten the execution time of the :copen, > :lopen, :cwindow, :lwindow commands significantly, particularly for > large location lists. > > The speedup I measured varied between 4 and 50 times, depending on the > size of input. This might not be very meaningful, but my (very > subjective) feeling is that the comfort of getting a quickfix window > instantly is much greater than that of having to wait for 1.5 seconds. Thanks. I'll look into it later. -- "I simultaneously try to keep my head in the clouds and my feet on the ground. Sometimes it's a stretch, though." -- Larry Wall /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: vim_extended/vim_mainline git repos independent of svn repo
On Thu, Feb 5, 2009 at 10:23 PM, Markus Heidelberg wrote: > > Hi, > > I've finally written a basic script (without any error handling so far) > for automatically fetching the patch files, applying, formatting the > commit message and committing to the vim_extended/vim_mainline git > repositories. So from now on these repositories are no longer based on > the official subversion repo. Of course it still contains all the older > commits in the history from svn, this is not the planned rewrite of the > repository. good news at least for the future: we won't see those svn merge commits anymore :) > > 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. :( overall, I like the [7.2.102] header ;-) > 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. > 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. > > 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! -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: List Questions
On Feb 6, 12:07 am, Tony Mechelynck wrote: > > Also, Dr. Charles "Chip" Campbell maintains quite a number of Vim > scripts on his personal site, athttp://mysite.verizon.net/astronaut/vim > -- Some of these scripts, but by no means all of them, are now > distributed as "official" plugins together with Vim; others, or > sometimes the same ones, are also uploaded at vim.org. > Speaking of the "official" plugins, THOSE are quite often discussed on this list. Bugs in or patches for syntax files, help file deficiencies, etc. find their way into discussions here. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: when you do ':bnext' syntax-highlighting does not work in some states.
On 06/02/09 11:14, Lech Lorens wrote: > 2009/2/6 Dewr: >> Thank you, Tony. but my Vim works well when it is working with _vimrc or >> blahblah.vim. >> I just wanted Vim to keep the syntax-highlighting made by ':setlocal >> filetype=vim'. but Vim loses syntax-highlighting when ':bnext'|':bprevious' >> command is given. >> I thought it's a bug. isn't it a bug? > > It is not. :help 'ft' states that 'ft' is local to a buffer. When you > do :bnext, you change the buffer, so the value of 'ft' changes as > well. Seems logical to me. > yes, but when he does :bnext _followed by :bprev_, doesn't he go back to the former buffer? Or has that buffer been unloaded in the meantime and its filetype lost? Hm, that could be a possibility. 듀르、 if you use ":setlocal bufhidden=hide" on the first buffer (before using ":bnext"), does it keep its filetype then? Best regards, Tony. -- It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons. Curiously enough, the dolphins had long known of the impending destruction of the of the planet Earth and had made many attempts to alert mankind to the danger; but most of their communications were misinterpreted ... -- Douglas Admas "The Hitch-Hikers' Guide To The Galaxy" --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: when you do ':bnext' syntax-highlighting does not work in some states.
On 06/02/09 10:54, Dewr wrote: > Thank you, Tony. but my Vim works well when it is working with _vimrc or > blahblah.vim. > I just wanted Vim to keep the syntax-highlighting made by ':setlocal > filetype=vim'. but Vim loses syntax-highlighting when > ':bnext'|':bprevious' command is given. > I thought it's a bug. isn't it a bug? Hm, I'm not sure. > be happy. > > p.s. execuse me for my poor english speaking skill. :q No need -- if you were not constantly mentioning it, no one here would notice that you find it hard to write English. Best regards, Tony. -- If a putt passes over the hole without dropping, it is deemed to have dropped. The law of gravity holds that any object attempting to maintain a position in the atmosphere without something to support it must drop. The law of gravity supercedes the law of golf. -- Donald A. Metz --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: when you do ':bnext' syntax-highlighting does not work in some states.
On 06-Feb-09 11:14, Lech Lorens wrote: > 2009/2/6 Dewr : >> Thank you, Tony. but my Vim works well when it is working with _vimrc or >> blahblah.vim. >> I just wanted Vim to keep the syntax-highlighting made by ':setlocal >> filetype=vim'. but Vim loses syntax-highlighting when ':bnext'|':bprevious' >> command is given. >> I thought it's a bug. isn't it a bug? > > It is not. :help 'ft' states that 'ft' is local to a buffer. When you > do :bnext, you change the buffer, so the value of 'ft' changes as > well. Seems logical to me. Right, but Dewr is doing :bnext followed by :bprev, so he's back at the original buffer! I can reproduce this, and for me, too, this behavior is unexpected. When I manually :set filetype=vim, the buffer's filetype changes and is highlighted as vimscript. After :bnext|bprevious, the buffer's filetype is still 'vim' (okay), but the highlighting is gone. I have to do :syntax enable to let the highlighting show up again. -- regards, ingo --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: when you do ':bnext' syntax-highlighting does not work in some states.
2009/2/6 Dewr : > Thank you, Tony. but my Vim works well when it is working with _vimrc or > blahblah.vim. > I just wanted Vim to keep the syntax-highlighting made by ':setlocal > filetype=vim'. but Vim loses syntax-highlighting when ':bnext'|':bprevious' > command is given. > I thought it's a bug. isn't it a bug? It is not. :help 'ft' states that 'ft' is local to a buffer. When you do :bnext, you change the buffer, so the value of 'ft' changes as well. Seems logical to me. -- Cheers, Lech --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: when you do ':bnext' syntax-highlighting does not work in some states.
Thank you, Tony. but my Vim works well when it is working with _vimrc or blahblah.vim. I just wanted Vim to keep the syntax-highlighting made by ':setlocal filetype=vim'. but Vim loses syntax-highlighting when ':bnext'|':bprevious' command is given. I thought it's a bug. isn't it a bug? be happy. p.s. execuse me for my poor english speaking skill. :q 2009/2/6 Tony Mechelynck > > On 06/02/09 07:53, 듀르 wrote: > > I loaded a file in which some vim-scripts are and I did ':setlocal > > filetype=vim' then I saw beautiful syntax-highlighting. :) > > but win32-gvim didn't keep it up. I did ':bnext' and ':bprevious' > > several times and i found that win32-gvim didn't keep syntax- > > highlighting up. win32-gvim just regards the filename not filetype > > (option value) when it's doing :bnext and :bprevious. > > Check whether your vimrc includes either > >runtime vimrc_example.vim > > (or "source $VIMRUNTIME/vimrc_example.vim", without the quotes, which > amounts to the same thing), or at least > >syntax on > > ; to the latter I recommend to add > >filetype plugin on > > or, depending on your indenting preferences, > >filetype plugin indent on > > Also, check that each of your scripts has either the .vim extension or > one of the names vimrc .vimrc _vimrc gvimrc .gvimrc _gvimrc .exrc _exrc > > With the above, any file which Vim knows how to highlight will be > highlighted. > > > Best regards, > Tony. > -- > How long a minute is depends on which side of the bathroom door you're > on. > > > > --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
