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!
Re:ViM Author has seen the light
by
Carl
·
· Score: 5, Insightful
The charity-ware is a nice idea. It does build awareness. Very, very, nice.
But he doesn't seem to get the real idea behind Free Software and the GPL.
The GNU General Public Licence (GPL) is more restrictive. Although it claims to ascertain the freedom of software, it restricts the changes you can make. That is, you can make changes, but when you distribute the modified software, you must make the modified sources available as well. Thus people are not free to keep these changes to themselves. I would say this in fact restricts your freedom. On the other hand, allowing anybody to make changes and keep those changes a secret, even though they profit from the part of the program that wasn't changed, also doesn't sound fair. That's why I decided to add the condition that the changes must be made available to me. I can then decide that these changes are useful for most people, and include them in Vim. Or decide that these changes have only a very small audience, and allow a company to make a bit of money from their work. After all, if the source code of a program must be freely available, it is quite difficult to require users to pay money and make a living out of your work.
With the GPL everybody is equal. If you make a little modification to a GPLed program and distribute that to your friends your friends can ask you for the source of the program and your modifications. But that does not mean anybody else can come in and demand all your modifications to their program. But with his license he gets far more power then anybody else that works on VIM. That might seem fair now since he has done a lot (a very lot) of work on it. But this may come back and hunt you after 20 years when someone else is maintaining (a fork) of the program, since for example Bram doesn't like to maintain it anymore, and he suddenly demands that all changes are handed over to him again.
Although respecting peoples privacy is not a very strong requirement for free software it does seem strange that a license that gives the original author more rights then any other authors can be considered Free Software. I really like the fact that the GPL gives alll contributors equal powers and the fact that it only forces you to play nice with people you actually distribute copies to. Having some god like person that can always demand all source code that I changed doesn't sound very free.
I do appreciate his idea that it is unfair that someone can close down the source code and profit from the fact that most the code was free and not sharing improvements is unsocial. But appointing one person to make the "right" decissions what parts of "my" code should be handed over to him doesn't sound fair either. IMHO making everybody equal by using the GPL and giving everybody (including the original maintainer) the same rights or by using the simple MIT/Modern BSD license and risking that someone/everyone closes down the source seems more fair.
Re:Not Irony
by
smaughster
·
· Score: 4, Insightful
but I think the definintion people need to understand is "Incongruity between what might be expected and what actually occurs", which is actually what is happening, isn't it?
That is indeed one of the definitions of dictionary.com, but it isn't a great one since it lacks a part about the incongruity containing a somewhat "humorous/sad" taste which is present in a real ironic case (pardon me for not being able to eloquently explain it, english isn't my native language). For example, if you tell a funny joke and in reaction I punch you in the face, that that is an incongruity between what might be expected and what actually happens but isn't irony.
-- I intend to live forever, so far so good.
Re:ViM Author has seen the light
by
dangermouse
·
· Score: 5, Insightful
No, he knows exactly what he's doing. He said specifically that he wants to have the power to decide whether or not someone who's made modifications (and intends to distribute the resulting binaries) has to release the source for their modifications or not.
The GPL does not allow him to decide... if the program is GPLed and someone modifies it and releases binaries, they have to give out source as well.
He doesn't think that's always reasonable, so he came up with a license that allows him to decide on a case-by-case basis whether it's fair for someone to profit by keeping their changes to themselves or the changes should be made public.
Whether it's well-implemented or not is perhaps debatable, but don't go away with the impression that he doesn't understand the GPL. He clearly does.
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.
noooooooo! vi has been overrun by newbies . . .
by
hawk
·
· Score: 4, Informative
*sigh*
There was a time when every right-thinking vi user would thump those who claimed that vi had modes, because it just isn't true. But the heresy is spreading, and has even gotten into some documentation.
There is *not* an insert mode in vi. Instead, insertion is a command. "i" does not change modes, but instead, is the command "at this point, insert everything until I end this command with escape."
OK, so the newer versions in which you can use arrow keys to manuever during an insertion make this a bit odd . . .
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.
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
Vi Improved by Steve Oualline is an excellent book if you want to discover Vim (as opposed to vi)
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.
You call vim this horrid piece of software but earlier you said It took me several years to actually learn to use Vi(m).
A) Do you always spend "years" learning software you don't like?
B) Does your "learning" curve always hit a brick wall at the very first few commands that anyone else acquires in minutes?
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Bram Moolenaar studied electrical engineering at the Technical University of Delft and graduated in 1985 on a multi-processor Unix architecture.
Could the school not afford a proper stage for the ceremony?
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
www.vim.org is cool and all, but check out vim.sf.net for a site with all kinds of Vim resources and docs.
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
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!
But he doesn't seem to get the real idea behind Free Software and the GPL.
The GNU General Public Licence (GPL) is more restrictive. Although it claims to ascertain the freedom of software, it restricts the changes you can make. That is, you can make changes, but when you distribute the modified software, you must make the modified sources available as well. Thus people are not free to keep these changes to themselves. I would say this in fact restricts your freedom. On the other hand, allowing anybody to make changes and keep those changes a secret, even though they profit from the part of the program that wasn't changed, also doesn't sound fair. That's why I decided to add the condition that the changes must be made available to me. I can then decide that these changes are useful for most people, and include them in Vim. Or decide that these changes have only a very small audience, and allow a company to make a bit of money from their work. After all, if the source code of a program must be freely available, it is quite difficult to require users to pay money and make a living out of your work.
With the GPL everybody is equal. If you make a little modification to a GPLed program and distribute that to your friends your friends can ask you for the source of the program and your modifications. But that does not mean anybody else can come in and demand all your modifications to their program. But with his license he gets far more power then anybody else that works on VIM. That might seem fair now since he has done a lot (a very lot) of work on it. But this may come back and hunt you after 20 years when someone else is maintaining (a fork) of the program, since for example Bram doesn't like to maintain it anymore, and he suddenly demands that all changes are handed over to him again.
Although respecting peoples privacy is not a very strong requirement for free software it does seem strange that a license that gives the original author more rights then any other authors can be considered Free Software. I really like the fact that the GPL gives alll contributors equal powers and the fact that it only forces you to play nice with people you actually distribute copies to. Having some god like person that can always demand all source code that I changed doesn't sound very free.
I do appreciate his idea that it is unfair that someone can close down the source code and profit from the fact that most the code was free and not sharing improvements is unsocial. But appointing one person to make the "right" decissions what parts of "my" code should be handed over to him doesn't sound fair either. IMHO making everybody equal by using the GPL and giving everybody (including the original maintainer) the same rights or by using the simple MIT/Modern BSD license and risking that someone/everyone closes down the source seems more fair.
but I think the definintion people need to understand is "Incongruity between what might be expected and what actually occurs", which is actually what is happening, isn't it?
That is indeed one of the definitions of dictionary.com, but it isn't a great one since it lacks a part about the incongruity containing a somewhat "humorous/sad" taste which is present in a real ironic case (pardon me for not being able to eloquently explain it, english isn't my native language). For example, if you tell a funny joke and in reaction I punch you in the face, that that is an incongruity between what might be expected and what actually happens but isn't irony.
I intend to live forever, so far so good.
The GPL does not allow him to decide... if the program is GPLed and someone modifies it and releases binaries, they have to give out source as well.
He doesn't think that's always reasonable, so he came up with a license that allows him to decide on a case-by-case basis whether it's fair for someone to profit by keeping their changes to themselves or the changes should be made public.
Whether it's well-implemented or not is perhaps debatable, but don't go away with the impression that he doesn't understand the GPL. He clearly does.
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.
There was a time when every right-thinking vi user would thump those who claimed that vi had modes, because it just isn't true. But the heresy is spreading, and has even gotten into some documentation.
There is *not* an insert mode in vi. Instead, insertion is a command. "i" does not change modes, but instead, is the command "at this point, insert everything until I end this command with escape."
OK, so the newer versions in which you can use arrow keys to manuever during an insertion make this a bit odd . . .
hawk, in curmudgeon mode
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
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