Slashdot Log In
Vim's Bram Moolenaar On Open Source And Vim 6.0
Posted by
chrisd
on Wed Jan 02, 2002 07:15 AM
from the vim-is-the-one-true-editor dept.
from the vim-is-the-one-true-editor dept.
This discussion has been archived.
No new comments can be posted.
Vim's Bram Moolenaar On Open Source And Vim 6.0
|
Log In/Create an Account
| Top
| 214 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Not Irony (Score:1, Offtopic)
The "powered by emacs" thing at the bottom is NOT irony.
Do people even know what irony is nowadays?
Re:Not Irony (Score:4, Insightful)
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.
Vi Improved (Score:4, Informative)
Wow (Score:5, Funny)
Could the school not afford a proper stage for the ceremony?
A slicker site (Score:4, Informative)
Interesting bits from the page (Score:5, Interesting)
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!
fundamental.... (Score:2, Insightful)
i read the article fully and it seems an incredibly complex piece of work , one which seems to function perfectly too . imho, writing a full-fledged editor like that is one p.i.t.a almost comparable to maintaining kernel trees:)
also from the interview at least, what comes across is a serious, single-minded dedication to making _proper_ stable software.
great work bram. vim rulez
vv
The Key to Vim (Score:2, Flamebait)
But let's not misunderstand why Vim is so popular. It has nothing to do with "keeping your hands on the keyboard." Nowadays a hacker needs a robust, reliable, scriptable, GUI-aware text editor, preferably cross-platform. There's lots of wanabees, but only two serious contenders: EMACS and Vim.
Now, neither EMACS nor Vim is really a good GUI program. The original design of both was for text terminals. (Some minor Vi features only make sense on the budget-priced Lear-Siegler ADM3a terminal that was standard at Berkeley when Bill Joy was there; I gather RMS used something rather more baroque.) That means lots of "editing modes" -- exactly the sort of thing you do not want in a GUI environment. I suppose EMACS is rather less modal than vi/vim, but it's still pretty bad.
I can live with it, mainly because I've had the basic Vi command set memorized longer than most slashdotters have been alive. But I still find it hard to change my mental gears every time I go from Vim to a modeless editor -- even the text box I'm using now. Pressing the ESC key in the wrong context can have nasty consequences!
noooooooo! vi has been overrun by newbies . . . (Score:4, Informative)
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
My latest spot of Vim-magic (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! :-)
Folding (Score:4, Interesting)
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
We need more documents like these (Score:4, Interesting)
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
About learning strange vim commands (Score:2)
Sometime in late '94 I was experimenting with running a BBS at home and had made a few friends among the local operators in my town. I met one who curiously had neither DOS, nor Windows on one of his PCs. It was called Linux and he was doing some really interesting stuff with it. It was stuff that I take for granted now but those days it was like a revelation to me. First of all, watching the system boot up was incredible. It not only knew what hardware he had installed but it showed up on screen duing boot. There were virtual consoles! There was a color directory listing. He had all maner of programs at which I marveled; complex and powerful programs that clearly were intended for people with deep knowledge about their machines. The terminal program didn't crash when the line disconnected! The sheer expanse, power and complexity of it all was what drew me in. Even more incredible to me were three things:
So what about VIM? Well, I had downloaded Slackware (via 28.8K modem) and installed it (more-or-less) and I had read --a lot-- to try to get everything working. I needed to do a lot of config file editing and all the literature pointed to Vi as the original programmer's editor and to Emacs as the same but bigger and slower and more like an environment than a simple text editor. To the uninitiated, you can guess which one sounded like the right tool for the job.
So I fired up vi, which turned out to be Vim (which made me nervous about incompatibilities) and to my astonishment, I couldn't figure out how to enter text or save the file or even get out of the damn thing. It was totally non-intuitive and I wasn't even sure it was working correctly! How come this was so hard? I had mastered several DOS editors. I even knew edlin. This seemed worse--almost. More reading on the subject assured me that it was possible to save and quit. But what was the point of installing, learning and using Linux if just using a simple text editor took reading a manual (a manual that was not easy to find for someone who was completely new). Only one thing I knew spurred me to hold my course: this was the editor by and for programmers; this was what the Unix gurus had invented and used and this was what I was going to use, damnit. Since thenn it was all the same sort of adventures for me in Linux land. I have never been the same since. Pity those who don't also learn the hard way.
and finally VIM is Free Software (Score:1)
Re:I'm curious (Score:1, Funny)
Re:I'm curious (Score:1)
Re:VIm is dog shit! (Score:2, Insightful)
Another point worth mentioning is that out of all four of the text editors (yes Emacs is just a text editor), only MS Notepad seems to follow the Unix philosophy. That's right, the Unix philosophy of having just the right tool for the job and keeping each tool small and simple is exactly how MS Notepad can be described. Somewhere along the line, the editors have gained bloat becoming more than they were ever supposed to and losing all simple-elegance that they might have ever had... except for notepad. Although new versions of Notepad have came and gone, none have increased bloat in any way.
I commend MS for taking this unix approach to text editors. They knew all along that people would use it to edit text and only to edit text. They left all the bloated features to programs such as Office where the features are neccessary and improve the product.
Re:I'm curious (Score:1)
Anyway, I normally use
Re:I'm curious (Score:4, Interesting)
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 (Score:2, Interesting)
Note that what I said above sais nothing about his decision. Charityware is a nice idea!
Re:I'm curious (Score:2, Interesting)
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...
I, too, am curious (Score:5, Funny)
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?
Re:I'm curious (Score:2)
Don't call it a horrid piece of software before you've learned how to use it.
Re:ViM Author has seen the light (Score:1)
IMHO, once you accept mods from people who are working for free, then you are morally obligated not to take their code, make other mods and sell it. Sure a company might add some cool new code that they think gives them the right to make money off the code, but if I wrote the 'paste' feature for VIM (I didn't) then paste should be disabled in the version they sell.
Oh well, my 2 cents worth.
Re:ViM Author has seen the light (Score:5, Insightful)
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:I'm curious (Score:1)
There are other editors, but the syntax highlighting is bloody useful at times.
(This is for cobol running on a unix system using windows terminals, so no, there's not a lot of choice)
I don't see the difficulty with learning the keys though, it's no worse than windows shortcut keys and a hell of a lot better than emacs or wordperfect shortcuts (well, that's my opinion anyway).
The only real annoying bug is that it doesn't work with a microsoft mouse with a scrollwheel. If you forget and use the wheel, you have to select another window for a few seconds and then select your gvim window again. Nothing major, but that's the only problem I've ever had with it.
Re:ViM Author reperesents darkness (Score:2, Insightful)
Re:ViM Author has seen the light (Score:2, Insightful)
But, imho, he completely misunderstands the GPL, which applies *only* to distribution to external entities and requires *only* that you distribute source code with executables when you do that. His license is intended to give the original author (and only the original author) some few extra rights-- mostly the ability to harvest changes from forks out in the world. But I think his changes are unnecessary, vague, and the world doesn't need another open-source-ish license-- no matter how well intended.
Re:ViM Author has seen the light (Score:5, Insightful)
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.
Re:I'm curious (Score:2)
If it took "several years", you're either a very slow learner, or you weren't putting in much effort.
How many people actually uses Vim and knows more than how to insert characters delete a line or a character here and there and save the miserable output from this horrid piece of software ?
I've written code, and a PhD thesis in vim. Like most people, I know the features that I have the greatest need for. These include visual mode select, jump to matching bracket, keyword completion, jump to line number, recording macros, search/replace, record/play macro, use of multiple buffer windows, and using tags. I probably aren't using all the features of vim, but I make heavy use of some of the advanced features not available in "classic vi".
I think people will learn what they need to learn. Serious programmers will probably need a larger subset of the features than someone who just edits small files.
Re:I'm curious (Score:2)
That's simply not true. The main thing that drives addition of features to vim is user feedback. Some of the features, like the GUI, multiple buffers (available through GUI) and syntax coloring do not require a lot of expertise to use, they are just there automatically, and they greatly improve the user experience. Other features are more subtle, such as keyword completion, search/replace, and tags. These features are often used by programmers, experienced developers know about these features, and hence are more likely to look for them in an editor. I'd guess that the vim user base includes a lot of programmers, so features that appear useless to someone writing letters to grandma are actually very useful to someone writing a long program.
What about the Hit By A Bus scenario. (Score:3, Interesting)
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.