Vim's Bram Moolenaar On Open Source And Vim 6.0

vimbigot writes "A nice summary of where Vim 6.0 has come from, with some insights into Bram Moolenaar's thoughts on Open Source, Charityware and large cooperative software projects. (a bit of irony in the `powered by emacs logo at the bottom !')"

Re:I'm curious

[JPS]

Well, I'm doing all my coding under Vim, and I've also written my PhD dissertation under Vim.
I still discover some cool commands from time to time, but you figure out the most important ones rather fast. Vimtutor is a pretty good start.

Re:ViM Author has seen the light

[Ace Rimmer]

About GNU GPL: I don't understand this fully. If you are an author of some code you can always dual-licence it and negotate with a commercial company to pay you for software you had developed (if they want keep it closed). The problem might be a larger number of contributors - you'd have to ask them if they agree with dual-licencing their contributions and pay them off (or exclude/reimplement their code). But I don't see how this changes with BM's licence (source must be available to me) - he might have the source but it'd be unfair to sell someone else's work anyway.

Note that what I said above sais nothing about his decision. Charityware is a nice idea!

Re:I'm curious

[CProgrammer98]

I have used Vi for years - I dodn't want to invest time in emacs because I'm a short term contractor and move from site to site a lot. You can always gurantee that vi or vim will be installed, but not many sites I've worked at have emacs - and were not willing to install emacs.

Vi is very very powerful, but it does have a steep learning curve. However, if you're willing to invest the time to become proficient, you probably will use it as editor of choice on unix systems. There's stuff you can do in vi that is very hard to do in other editors (with the possible exception of emacs :) )

Oh, and it'a actually SHIFT ZZ (or :wq ) to save and exit...

Interesting bits from the page

[f00zbll]

I found this particular paragraph interesting and shows Bram took a lot of care designing VIM.

The blocks with text lines are stored in the swap file without a specific ordering. If the blocks were ordered, inserting a block halfway into the file would require all remaining blocks to be shifted, which is very slow. To be able to find a line by its number, index blocks are used. An index block contains a list that tells which line is in which block. If a file is big, this list doesn't fit in a single block. It is then split over several blocks, and another index block is made to refer to these index blocks. This forms a balanced tree of index blocks, with the text blocks as the leaves. This construction has proven to be very reliable and efficient.

There are several text/html editors and IDE's that would benefit from this type of swap file. I'm sure everyone could list atleast 2-4 programs that have a difficult time handling large files. It's no wonder VIM is able to handle really large files and still respond quickly.

Hats off to bram!

Re:I, too, am curious

[roguerez]

I too once hated vi as much as you. In fact, I advocated the viewpoint that the original creator of vi should be hanged for what he did.

After having used pico for about a year it really started to annoy me. It's even less powerful than MS-EDIT (which it resembles). I started to use vi. I learned it the hard way: changed all my editor environment variables to point to vi and forced myself only to use vi. I had a vi mug standing next to me for reference (a vi mug is a coffee mug with the most often used commands printed on it, as if it were a reference card). After about a week of usage I was proficient enough to be faster in vi than in any other editor.

Surprisingly, the most irritating thing of vi when you don't know it (the command mode), turns out to be you're biggest friend in the editor after you've mastered is. It's so much more relaxed to keep your hands in same position the keyboard. You just don't need to move your hands, not to move the cursor, not the do commands. The hands stay in the same position with you're eyes on the screen (I think you really need to be a touch typist to get the best of this editor), and this is as relaxed as it can be. The only movement which changes your hands position is regularly pressing ESC to enter command mode. But this is so much easier than doing CTRL-BLA etc..

Re:Interesting bits from the page

[Anonymous Coward]

I found this particular paragraph interesting and shows Bram took a lot of care designing VIM.

Thats one of the more interesting parts i found in that article too. In fact ive written a text editor by myself (on the Atari ST) and used a very similar approach. I used also blocks of fixed size which could contain an arbitrary number of lines, where each block info contained the number of lines in this block and the offsets to each line in this block (and of course the number of used bytes). These blocks were organized in a linked list. This scheme was fast and efficient when storing and reading, and it would have allowed swapping out the blocks to disk (which i didn't do). Because i used a linked list inserting a block was also easy because only a few pointers needed to be changed.

But it surely wasn't as efficient as what Bram has done in vim, since i had a hard limit on line length (mainly because the current line was copied for editing in a second buffer), and search and replace was awfully slow sometimes. Searching was fast, but replacing cost a lot of time (because it was done on the line buffer and not in the main buffer which resulted in a lot of copy and memmove operations when writing back the current line). And since i didn't swap the blocks to disk my editor was limited in the editable file size by the free memory. So kudos to Bram for his well planned design! If i ever write an editor again (and who knows, maybe i will) i will be inspired by his memory organization scheme.

Dirk
--
(who doesn't care enough about /. to get an account so im still an AC)

My latest spot of Vim-magic

[DeadVulcan]

This would only be of interest to a select few Vim-geeks, but what the hey. (I've been using Vim since v1.2, and I want to have a chance to boast. Humour me. :-)

This morning, I checked on the progress of a nightly script I have, downloading the Debian tree over a modem. I wanted to see how much more I had left to go. The difficulty in this stemmed from the fact that not all directories were being downloaded, and not all files in those directories were being downloaded, either.

But with Vim, I was able to grab the ls-lR.gz file, and massage it to produce a du-like table of directories and sizes from which I was able to assess how much remainded of my download.

First, I removed most of the extraneous information; my region of interest was a subdirectory called pool, so I did some searching (/) and deleted everything before and after this subdirectory.

Then, among these directories, there was only a subset targeted for downloading. I pulled that list from a separate file, into the top of the buffer (:r).

Then came some cool magic. First, in preparation, I replaced all the slashes in the directory list with backslash-slash (ggV}:g/\//s//\\\//g). With that done, I put the cursor at the beginning of the first directory name, and started recording a macro (qa). I yanked the directory name with the escaped slashes (y$), searched for the other occurance of that string in this file (/^<Ctrl-r>"$<CR>), yanked the block of text that followed (V}y), returned to the point where I was before the search (''), and pasted the block of text after the directory name (p). Finally, I cursored down (}j), to position the cursor at the beginning of the next directory name, and finished off the macro (q).

Then I could invoke my macro with @a, and continue to re-invoke it with @@. Just holding down @ had the effect of slowly working through the list of directories, and inserting the list of files within each directory after it. Very cool to watch.

I then removed the rest of the file, since it didn't interest me (dG).

Then (without exiting Vim, mind) I used grep to filter out certain files from my list (ggVG!grep -v <pattern>).

Now I wanted to reduce the listings of files to a size summary for each directory. I made another macro that used the visual commands (<Ctrl-v>) to eliminate all but the file size column. Used the column-insert (<Ctrl-v>I) to add a "+" before all the numbers except the first. Packed them all together onto one line (V}J) and added the numbers together by invoking bc on it (V!bc<CR>). Cursor down to the next directory entry, and finished off the macro.

Again, I held @, and this time, it worked its way through the file listing, condensing each group of files to a single number: the total occupied space in that directory.

A bit of tweaking, and I had a nice neat table containing directory names and sizes.

Admittedly, it's taken me almost ten years to reach this level of proficiency, but I wouldn't trade it for anything. (Not even Emacs! :-)

Folding

[lvv]

What is your opinion about VIM6 folding?

Folding, also known as "condensed mode", "compressed mode" or "document map" in other editors is used to make long file look like table of contents. For example if you are in C file with 50 functions, you hit key for condensed mode and only functions first line is shown (lines that match some regex). You can quickly understand structure of this file. You don't need to go to header file to see functions signatures. You go to the line with function that you are intrested, press enter, editor switches to normal mode and you are in your function. It is like menu of 50 items. Using it extensively to navigating long source files with other editors, I will put it on the same level of usefullness as unlimited undo or sintax highlighting. You can only understand how usefull it is after you will use it for some time.

Unfortunately Bram misunderstood this consept and probably didn't used it before. In VIM6 folding is not make-table-of-contents from this file but hide-part-of-the-file consept. Did anyone found this useful? All folding modes in VIM are designed to hide block of text, not to select line to be a title for block of text (and not mix table of contents with normal text).

It is possible to cajole fold-expr to make table of content. But with pain and it still don't work exactly right. If lameness filter allow me, I will post VIM macro - my attempt to "fix" VIM folding in next messate. By default title line selected based on indentation. Change by editing "set foldexpr=Foldexpr_fun('^\\i')" line. Should be in .vimrc file.

What about the Hit By A Bus scenario.

[DunbarTheInept]

So what happens if Bram gets run over by a bus? The way he wrote his license, Vim becomes frozen and that's that. No more development because the license says you have to show him your changes if you want to make them public.

The theory behind GPL is that once the software is put under GPL, then ALL authors who contribute to it get equal say in what they do with it. The original author doesn't get any more say than anyone else just because he's the one that started it. It takes on a life of its own and can't be stopped or repealed. Yes, the decision of an author to put something under GPL should definately not be taken lightly. It's a decision that once made, can never be undone.

Now, that's not always what you want, as in the case of Bram's charityware license. And Bram's decision not to use GPL makes perfect sense. (But not for the reason he cites, which is based on a false premise.) But he really should add a "will" clause for what happens if he is no longer alive, or decides he no longer wants to be the maintainer of Vim.

We need more documents like these

[tavon79]

One thing I really like about Bram Moolenaar's document is that he took that time to explain the internals of vim and how each file/source code functions.

For a beginning programmer and someone who wishes to participate in open source projects, it is really helpful to have someone/creator/maintainer to sit down and explain the internals of the whole program. Not to mention the nice part about charity license which shows some of the philosophies and vision of the project as well. Most project just say "take a look at the cvs" but it would be nice to have a central document that explains the different files/source code for someone to get started and jump in and help out.

I know that you may be thinking that if I can't look at the source code and not understand it then don't even bother helping out, but the truth is I'm just concerned about efficiency/error prevention. It would seem alot more efficent for me not to have to figure out what's going on by myself but get help to see the big picture and an overview of the project. I'm not saying comment/write about every detail but a general overview goes along way to understand and make sure that anyone new doesn't misunderstand the functions.

Anyway, I think it would serve the open source community better if every project would list all the files and describe what each file handles. It would be better if unclear parts be explained and documented as well.

John Hwang
-- goes here

Re:My latest spot of Vim-magic

[wfaulk]

First off, using ``q'' to record commands is not a macro. The :map stuff are macros.

To use your example of repeating a register execution, instead of continually typing ``@@'' or ``@a'', you could, for example, try using ``:map q @aq'', which tells vim to execute ``@aq'' whenever you type ``q''. This puts vim in a loop, right? But vim has been intelligent enough in pretty much every case I've used to stop when its commands are no longer feasible. I feel certain, in reality, that I could manage to do everything past your setup in one macro. But, then again, I haven't tried.

I also get the impression that you were using external commands to perform greps and whatnot. You might want to take a look at vi's builtin ex support.