Posted by
chrisd
on from the vim-is-the-one-true-editor dept.
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 !')"
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.
Interesting bits from the page
by
f00zbll
·
· Score: 5, Interesting
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!
My latest spot of Vim-magic
by
DeadVulcan
·
· Score: 5, Interesting
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!:-)
-- Accountability on the heads of the powerful.
Power in the hands of the accountable.
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.
by
DunbarTheInept
·
· Score: 3, Interesting
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.
--
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
We need more documents like these
by
tavon79
·
· Score: 4, Interesting
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.
Slashdot Mirror
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.
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!
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! :-)
Accountability on the heads of the powerful.
Power in the hands of the accountable.
What is your opinion about VIM6 folding?
.vimrc file.
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
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.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
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