This discussion has been archived.
No new comments can be posted.
Vim's Bram Moolenaar On Open Source And Vim 6.0
Related Links Top of the: day, week, month.
"If it ain't broke, don't fix it." - Bert Lantz
"If it ain't broke, don't fix it." - Bert Lantz
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:2, Funny)
Re:Not Irony (Score:1)
Re:Not Irony (Score:3, Funny)
I do. It means "Made or consisting of iron; partaking of iron; iron; as, irony chains; irony particles", 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? I for one would have expected to see a "Powered by VIM" button or whatever it says rather than an emacs logo.
Both the above definitions are cut and pasted from dictionary.com [dictionary.com] before you follow up.
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.
Re:Not Irony (Score:1)
In any case, the example you give hints at a greater story, which will probably result in more irony (whether the funny or tragic type).
Re:Not Irony (Score:3, Insightful)
One case of a definition isn't great because it isn't the same as another case?
Since English isn't your native language, how about a university where it is:
The definition at Princeton's Wordnet page [princeton.edu].
Do a little searching for "dramatic irony" and "tragic irony". BTW, most places I've seen the "humor" definition, it relies on the other definitions. For example, Merriam-Webster Collegiate defines the usage you're championing as:
"2 a : the use of words to express something other than and especially the opposite of the literal meaning b : a usually humorous or sardonic literary style or form characterized by irony c : an ironic expression or utterance"
Note that in order for humor to be ironic in this sense, it must be ironic in one of the other senses.
In general, if a person for whom English isn't their native language says something about English, and dictionaries produced by a bunch of English-speaking scholars say something different and largely agree on it, I'm afraid I'm going to have to go with the scholars.
Re:Not Irony (Score:2)
Oh, and yes, I do recognize the irony in the commonly-made grammatical error in that sentence.
Re:Not Irony (Score:1)
The important point here is that ironic doesn't mean much, because the question that jumps to every one's mind is whether to take the statement of "powered by emacs" at face value.
Since I don't, I think the more useful description is to say the text is facetious, i.e.,
intentionally humourous.
Re:Not Irony (Score:2)
Do people even know what irony is nowadays?
Nah, I take my shirts to the cleaners.
- The Boss from Dilbert
Re:Not Irony (Score:2)
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!
Re:Interesting bits from the page (Score:2)
Why not just store each line in a file named with the line's number and let the filesystem do all that ugly work for you? Oh, wait, I guess reiserfs [namesys.com] isn't that ubiquitous yet.
Seriously, there are good filesystems that do all of this balanced block tree work for you, and you should take advantage of them. IMHO, all filesystems should efficiently handle gigantic directories and tons of small files.
Re:Interesting bits from the page (Score:2)
I get your point, but it's VIM ferchrissakes!
yeah, that would . . . (Score:2)
hawk, who really hope he's being sarcastic and not accurate in suggesting that emacs has file systems . . .
Re:Interesting bits from the page (Score:2)
And when someone rm's line 213?
I'm all for integrating things into the filesystem, but this is more useful in the case of enabling interaction between the user and the program, or between that program and other programs. There's nothing wrong with a program-specific single-file format for internal state data. This makes it easier to design intelligent caching algorithms, because it can be assumed that if a file is being accessed, more of that file will probably be wanted. If a directory is accessed, in the common case it is unlikely that most of the files will be accessed, so no caching algorithm could ever predictively load data.
Re:Interesting bits from the page (Score:2)
Wow, you think a lightweight text editor should be bound to a specific filesystem?
While you're at it, how about if he re-writes it in hand-optimized Alpha assembly code, so it only runs on one processor too?
Re:Interesting bits from the page (Score:2)
I'm not suggesting that vim be made reiserfs specific, but that all filesystems change to be more like reiserfs. Filesystems should all make having large numbers of files in a single directory efficient, and should also make having lots of small files efficient. So far, reiserfs is the only filesystem I know of that's realized what a virtue this is.
Read The Naming System Venture [namesys.com] for several good reasons why all filesystems should make these things efficient. The basic idea is that having lots of different object naming systems that don't seemlessly integrate with eachother is bad.
Re:Interesting bits from the page (Score:1, Interesting)
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
Re:Interesting bits from the page (Score:2)
Re:Interesting bits from the page (Score:2)
You should write a very short memo about this and pass it along. If enough people did this your FTP should open up. If no one bitches then it stays the same for sure.
JOhn
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!
Re:The Key to Vim (Score:2)
In fact, the less I have to reach for my mouse to perform common tasks in a GUI, the better, I say. Don't you Alt-Tab between windows, use some key combo to switch desktops, etc? Why should it be different within your text editor? Providing menus for the editor's functions while leaving the keyboard controls in place makes sense, and that's what Vim does.
I agree that there's room for improvement, GUI-wise, but my thoughts are more along the lines of triggering mode switches with mouse input, not getting rid of mode switches. %-)
God's keyboards (Score:2)
hawk, who just realized to his horror that his fingers, too, have known vi since before the average slashdotter was born . . .
Re:The Key to Vim (Score:2)
I love vim. I find myself with jjjjjjjj's and kkkkkkk's all over the place when I'm not in vim.
I just wish my esc key wasn't way up there. It needs to be in the caps lock position.
Re:The Key to Vim (Score:2)
I just wish my esc key wasn't way up there. It needs to be in the caps lock position.
I have solved this problem. I remapped my keyboard to swap the Control and Caps Lock keys. Now, I can just hit Control-[, the equivalent of Escape and easy on the fingers. The reason I didn't switch the Caps Lock with the Escape key is because I use Control for a lot of other things and I occasionally like to fire up emacs.
Re:The Key to Vim (Score:2)
These [pfuca.com] are nice...
Re:The Key to Vim (Score:2)
For truly nasty consequences, try hitting Caps lock instead of (as well as) shift. This has happened to me more than once. Thank god we have multi-level undo!
Who's the newbie? (Score:2)
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
Re:noooooooo! vi has been overrun by newbies . . . (Score:2, Insightful)
Now, by the same token, an "i" entered in Emacs will do something slightly different depending on what kind of buffer you're viewing in the current window. So Emacs is not completely modeless either (very few programs are, if they have any significant user interactivity). However, in Emacs, it is always obvious what mode you're in, because the mode line shows you; and Emacs is less modal than vi, because basic editing activities like entering text, deleting text, and cursor navigation can all take place in the same mode, which is not true in vi.
The problem with the original vi, which has a lot to do with its awful reputation among UI designers, was that it gave no visual indication whatsoever what the current mode was. So if you stepped away from your terminal for a bit, and when you came back, you couldn't remember whether you'd left the program in command mode or insert mode, there was no way to know what would happen if you pressed a key! The safe thing to do, IIRC (I haven't used vi in over ten years), was to hit ESC, which in insert mode would switch to command mode, and in command mode would do nothing -- so you had a reliable way to get to a known state, regardless of the current state.
Newer vi clones, such as vim, use the bottom line of the window to display the current mode. This is a simple but very important improvement, and increases vi's usability markedly.
Newbie? (Score:2)
Re:Newbie? (Score:2)
also, that's not the original man page; it refers to coming from nvi/nex.
besides, man page entries from that era which refer to modes within vi rather than vi being a mode of ex are just plain wrong
hawk
Ancient Emacs (Score:2)
You'll find copies of the EMACS command set all over the place, though nowadays most users don't even know about them. Delphi has them, FrameMaker has them, god knows who else.
Re:The Key to Vim (Score:2)
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! :-)
Re:My latest spot of Vim-magic (Score:2, Offtopic)
WOW! That's amazing... you REALLY need ADSL.
-Russ
Re:My latest spot of Vim-magic (Score:2)
Re:My latest spot of Vim-magic (Score:2)
You need to learn about :map and tail recursion.
I'm not sure I follow. Care to elaborate?
Re:My latest spot of Vim-magic (Score:2, Interesting)
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.
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.
Re:I'm curious (Score:1, Funny)
Re:I'm curious (Score:1)
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:I'm curious (Score:1)
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, too, am curious (Score:1)
Okay, that was flamebait =P
Re:I, too, am curious (Score:1)
completely avoiding reinventing the wheel or even relearning the basics, if you will.
If it works, stick with it.
B) My "learning" curve, as you refer to it, does not always hit a brick wall. Sometimes it does, which puts me in a situation where i choose to either:
1) continue using that piece of software, forcing myself to learn it, even tho i'd rather spend my time doing something that i enjoy.
or;
2) spend my time doing something that i enjoy.
Hope that sorts things out for ya!
Re:I, too, am curious (Score:2, Interesting)
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..
BIG VI HINT (Score:1)
I have changed my capslock key to be control on both windows and unix. So, I never have to leave the home row to enter an escape character.
BTW in a similar manner ctrl-h is the key sequence for backspace. A lot of the keys on your standard keyboard are "convenience" duplicates.
Re:BIG VI HINT (Score:2)
I have changed my capslock key to be control on both windows and unix. So, I never have to leave the home row to enter an escape character.
Having started computing on a similar keyboard to what you must have, I've also been tempted to remap my keyboards to switch control and caps-lock. As blasphemous as it sounds, I think I like it better the way it is on PC keyboards. I have fairly large hands, so to hit ctrl I just have to "mash" down with the edge of my left palm. Since the ctrl key is right on the corner of the keyboard, I can hit it consistently and accurately.
The most useful remapping I've done on my keyboard, though, is switching [ to { and ] to }. This speeds things up quite nicely in C-syntax based languages.
Re:BIG VI HINT (Score:2)
As a consultant, I spend a lot of time sitting on different machines. While it may make sense to remap your keys to what you find usable, it makes it very hard when confronted with a new box every day. That's why I've chosen not to make any changes to my keyboard layout. It's kind of constant, like having vi(m) around.
My favorite vi tagline, stolen from somewhere:
"vi is like masturbation. It's not as good as the alternative, but it's always there."
Now when are they going to let me use vi inside of textarea boxes on Mozilla?
.
Re:I, too, am curious (Score:1)
Re:I'm curious (Score:2)
Don't call it a horrid piece of software before you've learned how to use it.
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:I'm curious (Score:1)
Re:I'm curious (Score:1)
Mouse wheel (Score:1)
Re:Mouse wheel (Score:1)
Bollix. I give up, just have to remember not to use the scroll wheel.
Win32 Mouse wheel problem (Solution) (Score:2, Informative)
intellimouse wheel problems:
When using the Intellimouse mouse wheel causes Vim to stop accepting input, go to:
ControlPanel
Mouse
Wheel
UniversalScrolling
Exceptions
And add gvim to the list of applications. This problem only appears to happen with the Intellimouse driver 2.2 and when "Universal Scrolling" is turned on.
---
btw: what the hell is the 'lameness filter'?
besides a pain in the ass when cutting/pasting...
Re:Win32 Mouse wheel problem (Solution) (Score:1)
So what exactly have I turned off? It still scrolls...
Re:I'm curious (Score:1)
I use the Windows version, and have the MS IntelliMouse Explorer. In version 5.6 gvim would do what you described, but in 6.0 I have had no prolems using the scrollwheel.
Re:I'm curious (Score:2)
On Putty, you can get by using ^[ for esc (I do this anyway) and ^I for tab.
Cheers,
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)
When someone is polite enough to use my title, I'm compelled to reply. You don't have to be a rocket scientist to learn vim. It takes a little effort upfront, then some time practising what you've learned, preferably by using it in day to day life.
And fuckin' calculus is too hard too,
Doesn't strike me as hard now, but I remember it being very hard when I was learning it. Learning vim is much easier than learning calc.
Re:I'm curious (Score:1)
Anyway, I normally use
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...
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.
Re:I'm curious (Score:2)
To be honest, I don't know. I have contributed a spec file to vim, and I might have contributed colors, but that would have been a while ago.
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.
notepad, bloat, and unix philosophies (Score:2)
As for the unix "philosophy"-- well, it's been dead for some time. IMHO, Perl is much preferable to awk, sed, etc... However, who am I to criticize your (obviously well thought out) decision to use traditional posix/unix tools in a MS Windows environment.
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: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:2, Funny)
Re:ViM Author has seen the light (Score:2)
If you are only concerned about the innards, and are willing to forgoe the frosting, you can probably get away with it...if you can figure out how to scoop out the innards without A) Destroying the beatiful icing and B) causing the cake to collapse due the removal of all structural integrity.
There is an analogy here some where....oh, sorry
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:ViM Author has seen the light (Score:1)
Whereas, in the real world...
Re:ViM Author reperesents darkness (Score:2, Insightful)
Re:ViM Author reperesents darkness (Score:2)
How come FSF people constantly assume that anybody who doesn't agree with the GPL doesn't understand it?
I thought the "scientific inevitability" of the dialectic was a fad that had safely passed.
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:1)
Anyways, emacs rulz.
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:ViM Author has seen the light (Score:2, Flamebait)
Alas, he does not; nor, apparently, do you.
He already has that power, by virtue of being the copyright holder. No license is needed to give him that power, and no license can take it away from him.
This is a category error. The GPL is a decision on the part of the copyright holder. If Bram licenses Vim to person X under the GPL, that is a decision by Bram that person X should not be allowed to distribute binaries without distributing sources. If Bram believes that person Y should be allowed to distribute binaries without distributing sources, he can effect that decision by licensing Vim to person Y under some other license which specifically grants that permission. You appear to be asserting that the GPL can somehow deny Bram his authority as copyright holder to do this.
See, this is why (to answer an earlier assertion by someone else) we claim that GPL opponents simply don't understand the GPL: all the objections to the GPL that I've seen demonstrate a misunderstanding of the GPL.
Re:ViM Author has seen the light (Score:2)
When someone resorts to personal attacks when making an argument, this usually indicates that their arguments are not strong enough to stand on their own merits.
he can effect that decision by licensing Vim to person Y under some other license which specifically grants that permission.
However, keep in mind that VIM is, like a lot of open-source software, an internet collaberative project. If VIM was GPL, Bram would need to get the permission of every single person who has ever made a patch for VIM available before releasing a non-GPL version of VIM.
This is why the GPL is a "viral" license. Once an author adds third-party patches to his GPL software, the author in effect gives up his right to release a non-GPL version of his software.
- Sam
Re:ViM Author has seen the light (Score:2, Insightful)
Since the above-quoted is not, in fact, a personal attack, your observation, while true, is a non sequitur.
(shrug) Bram would need permission to redistribute third-party patches no matter what license he used. What's your point?
Re:ViM Author has seen the light (Score:2)
To recap: The original discussion was saying that the VIM license has the "advantage" over the GPL of allowing people to distribute a modified binary-only release, after giving a copy of the source code of this release to Bram.
The rebuttal presented was that, well, one can do the same with GPL software: Simply re-release the same code base under a different license, such as what Tuc Racer; Sourceforge; Openoffice; and the QT developers have done.
My rebuttal was that, unless the original license holder accepts no third party patches, or has everyone that sends a third party patch dual-license their patch, or hands the copyright of the patch over to the original devloper, the original author gives up their right to distribute a non-GPL version of their program.
In other words, if Bram GPL'd his code, and was not extremely careful with how he accepted patches, he would essentially give up his right to give someone a non-GPL version of VIM.
This is what GPL opponents refer to as the "viral" nature of the GPL: Once a significant number of people have developed a GPL piece of software, it is impossible to de-GPL it.
- Sam
Re:ViM Author has seen the light (Score:2)
In some ways, it might, as it could be argued that the reverse license of contributors to the original source are likewise covered by the GPL, effectively taking the work out of the original author's hands by virtue of having accepted patches. Unraveling this would be nightmarish.
However, this colicensing thing has never been tested in court that I know of, and IIRC has fairly weak legal precendent. The original author holds quite a bit of power.
Moreover, as a matter of practice if voluntary contributors don't actually write up some kind of _license_, it could be easily argued that the submissions were a gift. This would be especially problematic if the overall original work _registered_ their copyright, but the contributor never registered theirs. Unraveling that would be a near legal impossibility.
Fortunately the free software movement is filled up with friendly people who avoid predatory behavior like this.
C//
Re:ViM Author has seen the light (Score:2)
Re:ViM Author has seen the light (Score:2)
Yes, but he should have just used the BSD license, of course. "This software is free; do what you want with it, anything at all." GPL software is _not_ free.
C//
Re:ViM Author has seen the light (Score:2)
Re:ViM Author has seen the light (Score:2)
C//
Re:ViM Author has seen the light (Score:2)
Ah... it's just that the context of the discussion up to that point had been his goals, not yours. Hence the confusion.
It's not really "open source" either, I don't think.
How do you figure? If you get Vim, you get the source and the right to modify it and redistribute those modifications. In fact, you're encouraged to distribute those modifications in source form, as distributing them solely as binaries requires that you negotiate with him and, presumably, make some form of "payment". So of course it's "open source"... it's just "open source" with the option to close, at the sole discretion of the original project's maintainer.
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.
Re:What about the Hit By A Bus scenario. (Score:2)