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 !')"
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 before you follow up.
-- UNIX? They're not even circumcised! Savages!
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:Not Irony
by
Guillermito
·
· Score: 0, Offtopic
I have heard many people complaining about this song, and I think it is misundrestood.
The ironic part aren't the examples. The irony is implied in the chorus part:
"Well life has a funny way of sneaking up on you
When you think everything's okay and everything's going right
And life has a funny way of helping you out when
You think evertyhing's gone wrong and everything blows up
In your face"
Basicaly it says that sometimes when you expect things to go right, they go awfully wrong, and vice versa. That's exactly the definition of irony
I actually think it is ironic just not very descriptive. The various meanings of ironic leave room for (as I read the dictionary) room for both intentional and unintentional occurences or utterances of a incongruous nature.
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.
-- It is by coff... er, will, alone I set my mind in motion...
Regarding your example, I can interpret it as ironic--particularly if you're not the one being punched or doing the punching. In this case, it might be an example of dramatic or maybe tragic irony.
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).
The one about the man who was afraid to fly and when he finally did his plane crashed was ironic.
Re:Not Irony
by
Anonymous Coward
·
· Score: 0
ok well you have the definition of irony, but your looking for dramatic irony:
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
punching someone as ou described it most certainly irony, just not the dramatic irony you would see in a book or film. but the emacs button is dramatic irony only if he put it there as a joke and really did the site with Vim, as it is humorous and sardonic in that case, otherwise its ironic, but not intentionally so.
Usage Note: The words ironic, irony, and ironically are sometimes used of events and circumstances that might better be described as simply "coincidental" or "improbable," in that they suggest no particular lessons about human vanity or folly. Thus 78 percent of the Usage Panel rejects the use of ironically in the sentence "In 1969 Susie moved from Ithaca to California where she met her husband-to-be, who, ironically, also came from upstate New York." Some Panelists noted that this particular usage might be acceptable if Susie had in fact moved to California in order to find a husband, in which case the story could be taken as exemplifying the folly of supposing that we can know what fate has in store for us. By contrast, 73 percent accepted the sentence "Ironically, even as the government was fulminating against American policy, American jeans and videocassettes were the hottest items in the stalls of the market," where the incongruity can be seen as an example of human inconsistency.
Re:Not Irony
by
Anonymous Coward
·
· Score: 0
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.
Sounds funny to me.
Re:Not Irony
by
Syberghost
·
· Score: 3, 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).
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:
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.
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.
Oh, and yes, I do recognize the irony in the commonly-made grammatical error in that sentence.
Re:Not Irony
by
Anonymous Coward
·
· Score: 0
You mean sad in the way that this group of people have been working for years to include features in Vim that have been available in Emacs for ages?
Oh well, at least the children in Africa get helped by it.
The "powered by emacs" thing at the bottom is NOT irony. Do people even know what irony is nowadays?
Do you? Lets just check this out, shall we?
irony - 3 a (1) : incongruity between the actual result of a sequence of events and the normal or expected result.
See, the irony of it is, one would expect a web site that boasts 'vi' to use vi, but, in fact, the contray is true - they use emacs. Hence, it is ironic. Thank you for your time.
Oh, and the song Ironic is also ironic. See, one would expect a song called "Ironic" to contain lots of irony. It contains none, and hence is ironic for that reason. *wuvin!*
--
karma is for the weak >)
Re:Not Irony
by
Anonymous Coward
·
· Score: 0
What is the error, if I may ask?
Re:Not Irony
by
Anonymous Coward
·
· Score: 0
Looks like a pronoun-antecedent pluralization conflict, as "a person" normally takes a singular pronoun.
Re:Not Irony
by
Anonymous Coward
·
· Score: 0
AKA the ubiquitious PHB. Don't you read the Register?
I don't consider the definition as stated by dictionary great because it lacks an essential part of the concept of irony. The fact that princeton uses the same definition does not change that (and this does not say anything about princeton since I am sure that they did not write that definition themselves).
Have you tried completing vimtutor? I know the basics of wim because I can get by on that for now. When time permits I play to use more of vim's advanced features.
Not many. I think coders just keep adding useless stuff to these editors because its fun for them,
not because anyone actually needs or uses it. If vim was *really* VI iMproved then they'd have
given it logical command keys. I mean 'x' for
delete character?? Control-ZZ to exit?? Come on!
i used to hat vim, still do, no different from vi that i notice, but vi is just so quick for me, i still have to use pico to paste text.
-- If you ignore ACs because they are anonymous - you're an idiot.
Re:VIm is dog shit!
by
Anonymous Coward
·
· Score: 2, Insightful
Your opinion of VIM and Emacs is correct.
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.
It's "Vi IMproved" because it's a vi clone with extra features. Not with incompatible commands.
Anyway, I normally use:q! or:wq to quit. Didn't even know about Ctrl+ ZZ. And I also don't usually use x to delete a character also, I use the Delete key (and Backspace if I'm in the edit mode).
Or if you don't have the cash just read the help files on vim6, where most of the book's content has been re-intergrated.
--
*shrug*
My favorite editor: Hear me out...
by
Anonymous Coward
·
· Score: 0
OK, this is not flamebait, nor am I trolling:
An easy to use editor, which I use daily, is a Pico clone, which is open-sourced. It's called Nano, Linkage here (http://www.nano-editor.org). It operates as simply as Pine, and it has a smaller footprint than Pico. (Yes, I do mean it's simplicity is like Pine, and Pico is the Pine editor, if you did not know.) Try NANO!!! Get the source, and do./configure, make, make install. Easy!
Well, I'm doing all my coding under Vim, and I've also written my PhD dissertation under Vim.
I still discover some cool commands from time to time, but you figure out the most important ones rather fast. Vimtutor is a pretty good start.
Re:ViM Author has seen the light
by
Ace+Rimmer
·
· Score: 2, Interesting
About GNU GPL: I don't understand this fully. If you are an author of some code you can always dual-licence it and negotate with a commercial company to pay you for software you had developed (if they want keep it closed). The problem might be a larger number of contributors - you'd have to ask them if they agree with dual-licencing their contributions and pay them off (or exclude/reimplement their code). But I don't see how this changes with BM's licence (source must be available to me) - he might have the source but it'd be unfair to sell someone else's work anyway.
Note that what I said above sais nothing about his decision. Charityware is a nice idea!
--
:wq
Re:I'm curious
by
CProgrammer98
·
· Score: 2, Interesting
I have used Vi for years - I dodn't want to invest time in emacs because I'm a short term contractor and move from site to site a lot. You can always gurantee that vi or vim will be installed, but not many sites I've worked at have emacs - and were not willing to install emacs.
Vi is very very powerful, but it does have a steep learning curve. However, if you're willing to invest the time to become proficient, you probably will use it as editor of choice on unix systems. There's stuff you can do in vi that is very hard to do in other editors (with the possible exception of emacs:) )
Oh, and it'a actually SHIFT ZZ (or:wq ) to save and exit...
-- And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
A) I choose to use what i like. Vi is not exactly intuitive with it's cryptic keycombos. I'd rather use my creativity and learningskills to learn something that i actually am i able to grok. This particular software was one of my first encounters when starting to learn linux. I quickly learned that pico was much more intuitive, so i stuck with that for a while, as it supported all my needs at that point. Now, after groking linux to some extent I moved on to learning about FreeBSD, and i always had the opportunity of cd'ing into/usr/ports/editors/pico/;make;make install;
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.
Re:I, too, am curious
by
Anonymous Coward
·
· Score: 0
Most of us quickly come to realize that pico is a toy program, neither worthy of consideration nor capable of accomplishing anything of significance.
Re:I, too, am curious
by
roguerez
·
· Score: 2, Interesting
I too once hated vi as much as you. In fact, I advocated the viewpoint that the original creator of vi should be hanged for what he did.
After having used pico for about a year it really started to annoy me. It's even less powerful than MS-EDIT (which it resembles). I started to use vi. I learned it the hard way: changed all my editor environment variables to point to vi and forced myself only to use vi. I had a vi mug standing next to me for reference (a vi mug is a coffee mug with the most often used commands printed on it, as if it were a reference card). After about a week of usage I was proficient enough to be faster in vi than in any other editor.
Surprisingly, the most irritating thing of vi when you don't know it (the command mode), turns out to be you're biggest friend in the editor after you've mastered is. It's so much more relaxed to keep your hands in same position the keyboard. You just don't need to move your hands, not to move the cursor, not the do commands. The hands stay in the same position with you're eyes on the screen (I think you really need to be a touch typist to get the best of this editor), and this is as relaxed as it can be. The only movement which changes your hands position is regularly pressing ESC to enter command mode. But this is so much easier than doing CTRL-BLA etc..
By not spending the time now learning how to use a real programmer's editor (emacs, vim, whatever) you are actually wasting your time because these editors speed up common program-editing chores. If you don't program, then by all means stick to pico. (and if you don't touch-type, go with emacs)
It does take a while to learn, but once you've learned it, it's the most powerful tool there can be.
Don't call it a horrid piece of software before you've learned how to use it.
-- This message is provided under the terms outlined at http://www.bero.org/terms.html
A slicker site
by
dimator
·
· Score: 4, Informative
www.vim.org is cool and all, but check out vim.sf.net for a site with all kinds of Vim resources and docs.
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:Interesting bits from the page
by
Omnifarious
·
· 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 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
by
Anonymous Coward
·
· Score: 1, Interesting
I found this particular paragraph interesting and shows Bram took a lot of care designing VIM.
Thats one of the more interesting parts i found in that article too. In fact ive written a text editor by myself (on the Atari ST) and used a very similar approach. I used also blocks of fixed size which could contain an arbitrary number of lines, where each block info contained the number of lines in this block and the offsets to each line in this block (and of course the number of used bytes). These blocks were organized in a linked list. This scheme was fast and efficient when storing and reading, and it would have allowed swapping out the blocks to disk (which i didn't do). Because i used a linked list inserting a block was also easy because only a few pointers needed to be changed.
But it surely wasn't as efficient as what Bram has done in vim, since i had a hard limit on line length (mainly because the current line was copied for editing in a second buffer), and search and replace was awfully slow sometimes. Searching was fast, but replacing cost a lot of time (because it was done on the line buffer and not in the main buffer which resulted in a lot of copy and memmove operations when writing back the current line). And since i didn't swap the blocks to disk my editor was limited in the editable file size by the free memory. So kudos to Bram for his well planned design! If i ever write an editor again (and who knows, maybe i will) i will be inspired by his memory organization scheme.
Dirk
--
(who doesn't care enough about/. to get an account so im still an AC)
Are you going to port The One True Filesystem to every OS that is supprted by your editor? Can you enforce its universal adoption?
I get your point, but it's VIM ferchrissakes!
-- "Flyin' in just a sweet place,
Never been known to fail..."
Re:Interesting bits from the page
by
zCyl
·
· 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.
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
by
Syberghost
·
· 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.
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
by
Anonymous Coward
·
· Score: 0
Sorry dude, but you only show what a pathetic sack of shit you really are. Pretending to be the parent poster with childish replies. It just shows that you have even less style than your mother's brothel.
Re:Interesting bits from the page
by
Anonymous Coward
·
· Score: 1, Insightful
"There are several text/html editors and IDE's that would benefit from this type of swap file."
One word: bloat.
If you are writing code , any editor that can handle megabyte sized files is more than enough.
If you want to load log files and such use tools that were designed for that.
All I want from my IDE editor is to help my write code, anything above that is pure bloat and should be left to editors covering other domains.
Re:Interesting bits from the page
by
elflord
·
· Score: 1
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?
Because the editor is designed to work efficiently on all filesystems, on a number of platforms. So it's necessary to write an implementation that works independently of the filesystem. And once it works well on any filesystem, there's not much point in using the system you suggest.
Re:Interesting bits from the page
by
Omnifarious
·
· 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 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
by
Anonymous Coward
·
· Score: 0
Amiga AFS and SFS also did Reiser-like small-file-efficiency way back in the day.
Re:Interesting bits from the page
by
Zathrus
·
· Score: 1
So learn a different command set for every utility I want to view text files with?
No thanks. I'm pretty damn happy that I can use vi-like commands for most of the stuff I do - whether it be at the command line (ksh in vi mode), using vile (shrug, used it before vim), using less, or whatever.
Frankly, I very often have to muck around with data files that are hundreds of megabytes in size. And sometimes they get bad data in them. Like nulls. This immediately trashes most of the unix text based tools, all of which were written with the idea of a null terminated string. That nukes the data I was trying to get to. I generally end up having to beat the file into submission with a perl script and load the resulting file into vi(le).
It's a helluva lot easier when I can skip the rigamarole and just load the file into the editor. I'm probably going to look at switching from vile to vim based on the hope that vim is more efficient at loading large files, both in Unix and NT.
Of course, this means I'm going to have to go home, download the source and binaries there, burn them to a CD or copy to a floppy, and bring it to work. Why the hell doesn't vim have any mirrors with http download? ftp is blocked by our proxy at work, so I can't download files via ftp. No problems with http. But after poking around a good bit I couldn't find a single download site that offered anything but ftp.
Yes, I know. Our proxy sucks. Our admins are freaking overzealous. And ftp is the proper way to download files. Doesn't help me a bit.
Re:Interesting bits from the page
by
Anonymous Coward
·
· Score: 1
shut the fuck up you nigger dike kaq spic
Re:Interesting bits from the page
by
Anonymous Coward
·
· Score: 0
You're still a loser..
Re:Interesting bits from the page
by
Milican
·
· Score: 2
Yes, I know. Our proxy sucks. Our admins are freaking overzealous. And ftp is the proper way to download files. Doesn't help me a bit.
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.
Re:Interesting bits from the page
by
Anonymous Coward
·
· Score: 0
well to stay in your problem domains, when debugging compile error or runtime error in C/C++ with heavy use of macros or #define it happens (not to often but it does) that you need to open files which are run through the preprocessor but not yet compiled, those routinely (at least on big projects) exceed the megabyte.
This is also true when reading code generated by an automatic tool.
Re:Interesting bits from the page
by
f00zbll
·
· Score: 2
I'd agree with you 100% if I didn't see humungous ASP and Perl scripts that are like thousands of lines and over 4 megs. Sure most html editors will eventually open it, but it runs damn slow. No one in their right mind should write long grotesque HTML or scripts that are more 200 lines, but that's in an ideal world. One person maintaining a huge script might find it easier to have just one file, but having to fix/change/update that kind of files drove me nuts in the past using other file/text editors. So like everyone else, I go download VIM and move right along.
Re:ViM Author has seen the light
by
r0ckflite
·
· Score: 1
It seems to me that everybody who likes 'most' of the GPL do so because they want to distribute source but they want the option of making money off it at the same time. Kinda having your cake and eating it too.
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.
--
Push the button Max!!!!
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.
I've used vim and gvim for ages and never had a problem except the odd time using vim on a putty (tm) terminal...
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.
-- -Never argue with an idiot. They drag you down to their level, then beat you with experience-
VILE!
by
Anonymous Coward
·
· Score: 0
Theres a version of vi called VILE
Describes it perfectly!
How come people constantly fail to "get" the GPL? It is designed to give users maximum amount of freedom, it does not take any special steps to give the author a special status. I like this, but I can see how people who don't really care about free software, but rather does it so they can take away users freedom once thay have people locked in don't like it.
Re:ViM Author has seen the light
by
ichimunki
·
· Score: 2, Insightful
A recent thread on the debian-legal list indicates to me that Bram doesn't quite get the whole idea behind free software. A number of Debian users are questioning whether the VIM license is in fact free-- it has a fairly noxious clause about making changes available to the original author. This sort of thing just may not be appropriate in some circumstances. I also think that Bram is a generous, giving, intelligent person who wouldn't go apeshit over infractions that had good reason or were not of true import.
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.
I'm using gvim6.0 and my scrollwheel works just fine. Running a X server on Windows.
fundamental....
by
vvikram
·
· Score: 2, Insightful
we seldom realize how many people use editors [like vim] day in and out and how integral its become......
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
Re:ViM Author has seen the light
by
uchian
·
· Score: 0, Offtopic
Charityware is a nice idea!
Only trouble is, I've got this image in my head now that won't go away - all those orphans in Uganda, each with their very own copy of Vim on floppy disk, looking around for a computer to install it on...
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:donate your AIDS do Africa
by
Anonymous Coward
·
· Score: 0
I can tell based on your unbelievably uneducated writing style that all the "nigger" posts belong to one person.
And by the way, who the fuck marked MY post a flamebait? Off-topic, sure, but flamebait?
Works perfectly over here, win32 native on several 6.0 betas as well as the real thing, all installed from the all-in-one executable. You've got a configuration problem, I'd say.
Argh. Probably. Whenever I use the scroll wheel on the win32 version (version 5.8, 6 beta and 6 actual), the cursor turns hollow and I become utterly unable to enter text. Tried every menu option and vi command I can think of but nothing works. I have to click on another window and then back on the vim window. Bloody wierd. Got the microsoft driver installed for the mouse, standard setup on win98.
Bollix. I give up, just have to remember not to use the scroll wheel.
-- -Never argue with an idiot. They drag you down to their level, then beat you with experience-
Totally ON topic
by
Anonymous Coward
·
· Score: 0
I was installing vim for dos 16, had some problems, and thought "damnit, let me relax a bit with slashdot". And what do I find?
Anyway, does anyone know why syntax highlighting doesn't work with vim for dos 16 (I have my reason for using this version) and is it supposed to work at all with that version of vim?
Re:Totally ON topic
by
Anonymous Coward
·
· Score: 0
It might be that you need to type
:syntax on
Or, what happened to me one time is that I hastily installed the vim executable and forgot to install all the supporting files. Maybe you have done the same.
Re:Totally ON topic
by
Anonymous Coward
·
· Score: 0
There are so much restrictions on DOS-16 programs that syntax highlighting (and lots of other "standard" Vim features) are disabled for that version. It is unlikely someone manages to compile a DOS-16 version with syntax highlighting.
Re:Totally ON topic
by
Anonymous Coward
·
· Score: 0
I know what you mean, but no, I carefully installed all the stuff, and ran install. I even had to rename one of the config files (vimrc_example.vim to vimrc_ex.vim) because the DOS-16 version could not access long filenames, and the VIM guys might have forgotten this. So, now when I start VIM, it correctly accesses the vimrc_ex.vim file, but still no syntax higlighting. I suspect the other poster might be right, the DOS 16 version might be crippled.
I wrote a Ph.D. dissertation using vi and nroff/troff way back in the early 80s. When I got my first PC, I abandoned vi for WordStar and eventually WYSIWIG word processors, and thought I'd never go back to "mainframe editors" again. But here I am two decades later using Vim running under both Linux/Unix and Windows every working day (and most vacation days) of my life. It's just plain the most flexible and powerful tool for working with text documents there is.
I'm still surprised how many people (even long-time unix users) don't know this: ctrl-[ is the key-sequence for generating escape. Look at any ascii table.
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.
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.
Hey, that hitting ctrl with your palm is a great idea! I don't know why that never occured to me. No more moving my hands to do an escape!
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?
.
--
load "linux",8,1
notepad, bloat, and unix philosophies
by
Jeremy+Erwin
·
· Score: 2
MS notepad also follows the not so commendable philosophy of limiting file sizes to 64KB. (I suppose that this might be useful in encouraging code readability-- as long source code files might be harder to maintain, but this restraint seems analogous to bondage and domination languages (Pascal, etc).)
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:notepad, bloat, and unix philosophies
by
Anonymous Coward
·
· Score: 0
Of course Notepad has a filesize limit of 32KiB because that is the limit contained in an edit control on Win95/98 and maybe ME. NT/2000/XP does not have such a limit.
However, it is dog slow as it tries to read an entire file into memory in one go.
Re:notepad, bloat, and unix philosophies
by
Anonymous Coward
·
· Score: 0
The limit doesn't apply on NT.
Re:notepad, bloat, and unix philosophies
by
Anonymous Coward
·
· Score: 0
Perl is more preferable to awk and sed, but at the same time it borrowed a lot from these applications. I think vim has the same philosophy of taking the best features of other editors and integrating them.
Its just a higher level editor.
For the guy who likes notepad, why don't you just go back to dos edit or even better edlin.
Lates
You suck.
by
Anonymous Coward
·
· Score: 0
No fucking text.
Re:LotE - Lord of the Editors
by
Anonymous Coward
·
· Score: 0
SHUTUP! Shutup, shutup, shutup!
Re:$ rm /usr/bin/vi
by
Anonymous Coward
·
· Score: 0
OK, Vim is a solid, impressive piece of work. I use it every day. And Moolenaar rocks, both for his software work and the way he's used it to bring attention to his work in Uganda.
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!
Funny, one of the things I really like about Vim is the modal editing. I do want to keep my hands on the keyboard... reaching for a mouse drives me nuts in "GUI editors". Keep in mind that the whole point of a text editor is text input, and that's what God made keyboards for.
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. %-)
Re:The Key to Vim
by
Anonymous Coward
·
· Score: 0
"There's lots of wanabees, but only two serious contenders: EMACS and Vim. "
Nedit, TextEdit, SlickEdit or even MS IDE editor are just as good if not better.
Frankly,as far as I am concerned, both Vi and Emacs are relics from 20 years ago.
Re:The Key to Vim
by
Anonymous Coward
·
· Score: 0
I was surprised a couple of years ago to run across an Osbourne-CP/M fanatic at the Vintage Computer Fair in Silicon Valley. He showed the running of a few CP/M commands. In one case he had started a game (that was impressive) and to break out of it he mentioned that one uses Ctrl-x Ctrl-c to do what SIGINT normally does on non CP/M OSes. That is the same key sequence to get out of GNU Emacs (assuming you haven't used elisp to redefine the exit sequence), hence I can only presume that Stallman was inspired in part by CP/M in coming up with the (admittedly somewhat unusual) key sequences for GNU Emacs. Perhaps it was any terminal that could support CP/M would be the answer to the question (including the Osbourne line, the original IBM PC, etc.).
Re:The Key to Vim
by
Anonymous Coward
·
· Score: 0
Actually, emacs is worse in that respect. Just try sitting at a (windows) pc and xhosting emacs off a solaris box. What's the Meta key? That black diamond on the sun keyboard, but there is none on the PC keyboard. Thus you must press ESC to simulate meta. Now what is the average number of times Meta is used?:-)
I don't intend to start a flamewar. I've used both emacs and vi and vim, and vim is my favorite. This argument just holds little weight in the editor war. Indeed, though, I have Canceled by Visual Source Safe checkins enough times just because I wanted to edit the comment I typed (and I pressed ESC!).
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!
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!
No, you need not press ESC to simulate META if your system is sensibly configured (and in most EMACS environments, the default is sensible). The ALT key on a standard "IBM Enhanced" style keyboard usually maps to META.
A client of mine once commented on how fast I was able to navigate in Windows. His followup was very insightful. He said, "It seems that in order to navigate in a graphical environment quickly, you have to forget that you have a mouse available to you."
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.
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.
-- You had me at "dicks fuck assholes".
Re:The Key to Vim
by
Anonymous Coward
·
· Score: 0
IIRC, SUN machines have the escape key in the place where the ~ key is on the standard keyboards. That, the swapping of caps-lock and ctrl and some other misc differences make those keyboards difficult to get used to but much easier to vim(or emacs, for that matter) on.
Re:ViM Author has seen the light
by
Tom7
·
· Score: 1
Yes, you are right. There are a couple of reasonable criticisms that one can make of the GPL, depending on one's selfishness and other factors, but this definitely isn't one of them. Someone needs to straighten this feller out!
Anyways, emacs rulz.;)
Win32 Mouse wheel problem (Solution)
by
YetAnotherDave
·
· Score: 2, Informative
From the help file (I've tried this, it works)
intellimouse wheel problems:
When using the Intellimouse mouse wheel causes Vim to stop accepting input, go to:
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)
by
CrazyBusError
·
· Score: 1
Cheers, dunno why, but my logical assumption was that if I turned it off for that program then I wouldn't have been able to use the scroll wheel. (I did look at the option previously but didn't try it). But I suppose that would have been too obvious.
So what exactly have I turned off? It still scrolls...
-- -Never argue with an idiot. They drag you down to their level, then beat you with experience-
Re:ViM Author has seen the light
by
Syberghost
·
· Score: 1
With the GPL everybody is equal.
Whereas, in the real world...
Re:ViM Author reperesents darkness
by
Syberghost
·
· Score: 2
How come people constantly fail to "get" the GPL?
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
by
Stinking+Pig
·
· Score: 1
The license clearly delineates a maintainer role and specifies that Bram is currently that maintainer. When he gets tired of it, last responsibility is to hand off to another. Sounds familiar, doesn't it? And the model has grown this way because:
a) rule by committee typically doesn't work as well as having a leader or two. A well-chosen committee is great for bringing out all the angles to an issue so that the leader can make an informed decision, but making all the decisions by vote slows down the process and can create dissension among the members who 'lost' the vote. Having one person act as the decision gatekeeper with a "the buck stops here" responsibility level seems to work well for software projects./. readers welcome to insert all sorts of inappropriate analogies here.
and b), there aren't typically a lot of people who care enough about a project to take full responsibility for it. There may be a lot of people interested in patching it to scratch their own itch, but who wants to own or co-own the source tree? Patch integration, commenting, mailing-list moderation, evaluating the latest whiz-bang proposal to rewrite everything from scratch so you can support some buzzword?
"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."
I don't believe that's what the license says...
"If you distribute a modified version of Vim, you are encouraged to send the
maintainer a copy, including the source code. Or make it available to the
maintainer through ftp; let him know where it can be found. If the number of
changes is small (e.g., a modified Makefile) e-mailing the diffs will do.
When the maintainer asks for it (in any way) you must make your changes,
including source code, available to him.
The maintainer reserves the right to include any changes in the official
version of Vim. This is negotiable. You are not allowed to distribute a
modified version of Vim when you are not willing to make the source code
available to the maintainer."
-- "Nothing was broken, and it's been fixed." -- Jon Carroll
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.
Did any one notice ... ?
by
flk
·
· Score: 0, Redundant
after reading the article... I saw on the bottom a "POWERED BY GNU EMACS" icon!
-- [...]
Re:Did any one notice ... ?
by
Anonymous Coward
·
· Score: 0
OMG OMG THese are the fuckers who own vim.org
kill them you emacs and pico using d00dz!!!!!
person: Sven Guckes
nic-hdl: SG83-GANDI
address: Pariser Str. 52
address: D-10719
address: Berlin
address: Germany
phone: +49-30-8838884
fax: +49-30-88629362
e-mail: guckes@vim.org
Most people do not understand it, some do.
Most of the ones that do understand it (and do not agree with it) uses a BSD like license and do not
create a new bad one.
Vi is very very powerful, but it does have a steep learning curve.
I think you mean it has a long learning curve, not a steep learning curve. Most learning curves measure learning over time. The longer the time it takes to learn something, the longer -- and shallower -- the learning curve.
A steep learning curve would be a short learning curve, which is desireable.
There is a point on the learning curve called the operational threshhold, which is the point at which you know enough to do useful work. This point comes reasonably early on the VI learning curve. After that point, the more you learn, the more efficiently you can use the program. Since productivity increases roughly in proportion to learning, the long learning curve is tolerable.
If the operational threshhold were further along the learning curve, that is, you needed to learn a lot to do a little, the trade-off would not be so worthwhile.
Also, the implication of "steep" seems to be that learning VI is hard. I suspect the main impediment to learning VI is that the operations don't resemble the operations of other programs in common use. Almost nothing you already know applies to VI.
To my mind, learning VI resembles learning touch typing except the operational threshhold arrives much earlier.
hawk, who really hope he's being sarcastic and not accurate in suggesting that emacs has file systems . . .
Re:I'm curious (using vim with putty)
by
Anonymous Coward
·
· Score: 0
Just configure putty to use the right keybindings and it works just fine. I've used vim _lots_ from putty and never had any problems (well, except that the termcap/terminfo on solaris sucks and gives no color).
It took me several years to actually learn to use Vi(m).
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.
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.
Re:My latest spot of Vim-magic
by
rbeattie
·
· Score: 2, Offtopic
Re:My latest spot of Vim-magic
by
DeadVulcan
·
· Score: 1, Offtopic
But... then, I wouldn't have anything to boast about!
Oh... God...
That's just SO pathetic.
;-)
-- Accountability on the heads of the powerful.
Power in the hands of the accountable.
Re:My latest spot of Vim-magic
by
Khalid
·
· Score: 2
Well its seems you need to lear sed:)
Re:My latest spot of Vim-magic
by
wfaulk
·
· Score: 1
Just holding down @...
You need to learn about:map and tail recursion.
--
Fuck 'im up, Tim! His views are invalid! -Pirate Corp$
Re:My latest spot of Vim-magic
by
DeadVulcan
·
· Score: 2
You need to learn about:map and tail recursion.
I'm not sure I follow. Care to elaborate?
-- Accountability on the heads of the powerful.
Power in the hands of the accountable.
Re:My latest spot of Vim-magic
by
wfaulk
·
· Score: 2, Interesting
First off, using ``q'' to record commands is not a macro. The:map stuff are macros.
To use your example of repeating a register execution, instead of continually typing ``@@'' or ``@a'', you could, for example, try using ``:map q @aq'', which tells vim to execute ``@aq'' whenever you type ``q''. This puts vim in a loop, right? But vim has been intelligent enough in pretty much every case I've used to stop when its commands are no longer feasible. I feel certain, in reality, that I could manage to do everything past your setup in one macro. But, then again, I haven't tried.
I also get the impression that you were using external commands to perform greps and whatnot. You might want to take a look at vi's builtin ex support.
--
Fuck 'im up, Tim! His views are invalid! -Pirate Corp$
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 . . .
Not many. I think coders just keep adding useless stuff to these editors because its fun for them,
not because anyone actually needs or uses it.
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:ViM Author has seen the light
by
Anonymous Coward
·
· Score: 0
He clearly does not, and neither do you. Two words: Copyright holder.
Or put another way... he who owns the code can put it under whatever license he likes. He can release the code under the GPL, and if he wants to license the source to a company for inclusion into its product, he can. Which is exactly what he wants, without yet another bullshit license.
Re:ViM Author has seen the light
by
adamy
·
· Score: 2
The quote means to continue to have your cake, in its uncut form. In other words, to keep your cake whole due to the aesthetic beauty of it, and to eat it due to it's tastyness.
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.
Yes, but His keyboards have the control key where He Meant it to be, not off in exile . . .
hawk, who just realized to his horror that his fingers, too, have known vi since before the average slashdotter was born . . .
Re:noooooooo! vi has been overrun by newbies . . .
by
elflord
·
· Score: 1
OK, so the newer versions in which you can use arrow keys to manuever during an insertion make this a bit odd ..
Using the arrow keys is a terrible habit, and a hard one to kick. I eventually used:map <left> <Nop>, and I'm glad I did.
Re:VIm is dog shit!
by
Anonymous Coward
·
· Score: 0
When did you last see ed display a file?
Re:ViM Author has seen the light
by
then,+it+was+nigh
·
· Score: 2, Flamebait
No, he knows exactly what he's doing.
Alas, he does not; nor, apparently, do you.
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.
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.
The GPL does not allow him to decide...
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.
-- sed 's/In Soviet Russia/In NSA America/g' < yakov-smirnoff-jokes.txt
Re:noooooooo! vi has been overrun by newbies . . .
by
Mendax+Veritas
·
· Score: 2, Insightful
"i" in vi is a command that switches modes. It is perfectly obvious that you're in a different mode, because the program now behaves differently in response to your actions. If you hit "i" in command mode, you switch to insert mode; if you hit "i" in insert mode, an "i" appears in your document. These are obviously different modes.
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.
Re:donate your AIDS do Africa
by
Anonymous Coward
·
· Score: 0
you are a retarded son of a smelly shitty bitch...
why does nigger stink like shit ?....
.... so even bling people can hate them...
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.
Re:ViM Author has seen the light
by
Kiwi
·
· Score: 2
Alas, he does not; nor, apparently, do you.
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
--
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Actually, EMACS goes back to the mid 70s, though it wasn't always called that. Grew out of efforts to create macros for the TECO command-line editor. One package was called "TEMACS" short for "TECO Macros". RMS wrote a version he called EMACS, which became widely used on the Arpanet. He later re-implemented everything in his own Lisp dialect. Interesting history here.
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:ViM Author has seen the light
by
then,+it+was+nigh
·
· Score: 2, Insightful
>Alas, he does not; nor, apparently, do you.
When someone resorts to personal attacks when making an argument,
[...]
Since the above-quoted is not, in fact, a personal attack, your observation,
while true, is a non sequitur.
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.
(shrug) Bram would need permission to redistribute third-party patches no
matter what license he used. What's your point?
-- sed 's/In Soviet Russia/In NSA America/g' < yakov-smirnoff-jokes.txt
ok, so you've got me by 5 years, but it was folks who have you that browbeat me:)
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
What about the Hit By A Bus scenario.
by
DunbarTheInept
·
· Score: 3, Interesting
So what happens if Bram gets run over by a bus? The way he wrote his license, Vim becomes frozen and that's that. No more development because the license says you have to show him your changes if you want to make them public.
The theory behind GPL is that once the software is put under GPL, then ALL authors who contribute to it get equal say in what they do with it. The original author doesn't get any more say than anyone else just because he's the one that started it. It takes on a life of its own and can't be stopped or repealed. Yes, the decision of an author to put something under GPL should definately not be taken lightly. It's a decision that once made, can never be undone.
Now, that's not always what you want, as in the case of Bram's charityware license. And Bram's decision not to use GPL makes perfect sense. (But not for the reason he cites, which is based on a false premise.) But he really should add a "will" clause for what happens if he is no longer alive, or decides he no longer wants to be the maintainer of Vim.
--
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Re:What about the Hit By A Bus scenario.
by
Z4rd0Z
·
· Score: 2
You didn't read what he said. He said if the maintainer of vim cannot be reached then you no longer have to show your changes.
-- You had me at "dicks fuck assholes".
Re:What about the Hit By A Bus scenario.
by
Meleneth
·
· Score: 1
so, you didn't read the part about needing to contact the maintainer dropping off after a reasonable time?
-- remote access CLI with tools is the only friend you'll ever need.
Re:I'm curious
by
Anonymous Coward
·
· Score: 0
Stupid question. Is there any connection between you and the color scheme of the same name?
BTW, I am a programmer. VIM 6.0 is now the editor of choice in my workplace ( I compiled and installed it the day it was released.) I have to write a lot of documentation, plans, and proposals. I find many GVIM features exctreemly usefull when editing any structured document.
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.
John Hwang
-- goes here
Re:We need more documents like these
by
Anonymous Coward
·
· Score: 0
What you describe is part of any good software documentation. Sadly, we don't live in a perfect world, and the documentation is known to be on the rather low-end of the priorities. Most programmers (myself included) don't take all the time they should to write the documentation.
Bram particularly impressed me with his motto (somewhere in the source) "write the documentation, then code what you just described". The fact that he actually manages to enforce this in Vim amazed me a lot, and made me like the program even more.
Now that Vim 6 ships with a user manual, I think it has one the best documentations I ever saw in a software.
Re:VIm is dog shit!
by
Anonymous Coward
·
· Score: 0
Hurray for ed!
After all, ed is the standard text editor.
Re:noooooooo! vi has been overrun by newbies . . .
by
Anonymous Coward
·
· Score: 0
I actually use the arrow keys, why? I type using
ten fingers, and I always expect my right pointing
finger to be at the 'j' key. Vi expects that you put
it on the 'h' key to make efficient cursor movements,
but this means that when I want to type I have to move
again (or type tge wribg wirds)
So I use the arrow keys. Anyone any suggestions?
WDTOBUHTDS???
by
Anonymous Coward
·
· Score: 0
Why did they only blow up half the Deathstar?
Re:ViM Author has seen the light
by
Courageous
·
· Score: 2
You appear to be asserting that the GPL can somehow deny Bram his authority as copyright holder to do this..
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:noooooooo! vi has been overrun by newbies . . .
by
Anonymous Coward
·
· Score: 0
What finger would you normally use to type an h? Do you have to switch positions after typing each h (or g)? Does typing an h or g cause all your output to be scrambled until you remember to switch back?
You're weird.
Re:noooooooo! vi has been overrun by newbies . . .
by
Anonymous Coward
·
· Score: 0
Thank you Captain Obvious.
Re:I'm curious
by
Anonymous Coward
·
· Score: 0
Yeah that's easy for you to say, doctor, but what about us stupid people?
And fuckin' calculus is too hard too, why do you assholes always insist on using it?
Re:ViM Author has seen the light
by
dangermouse
·
· Score: 2
Thanks... this was one of the points I should have made explicitly. The other is that even if he is the sole copyright holder, using the GPL hardly encourages others to come to him and negotiate a different license, whereas his license explicitly invites others to do so. The License is The Message, in effect.
Re:VIm is dog shit!
by
Anonymous Coward
·
· Score: 0
sorry, that is a feature and will only increase the bloat of the editor. Just be glad you don't have to use edlin.
Re:noooooooo! vi has been overrun by newbies . . .
by
Anonymous Coward
·
· Score: 0
Pay attention to context, dumbass. It makes sense to point out that 'i' changes modes when you're replying to someone who stupidly claimed that vi has no modes.
Re:ViM Author has seen the light
by
SLi
·
· Score: 1
Plus the fact that Vim seems to violate GPL. Well, at least the Debian binaries are linked with libgpm which is GPL'd and therefore requires that all software linked with it be also distributed under the GPL.
About learning strange vim commands
by
labradore
·
· Score: 2
Speaking as someone who uses vim often but not to the total exclusion of other editors I have to say that learning to use it was one of the defining experiences for me as someone entering the unix world by way of (GNU/)Linux. Let's remember back to a time and frame-of-mind that was probably a shared experience for many Slashdotters.
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:
It had a C compiler and source code for everything. I could read and learn from the sources for useful, full-featured real-world programs. This was something I had only dreamed of doing if I ever somehow got a job working with programmers or at a university.
It had all come from The Internet. At the time, to me, the net was almost a complete unknown quantity and I had no idea what one could use it for, how extensive it was, or most importantly how it worked. Linux, in my mind, was evidence that the Internet--whatever it was--had to be wonderful.
It was all free! Several years passed before I truely understood that it was really Free and not just free beer. It pains me that so many others learn about the Freedom part so relatively late.
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.
Thanks for taking the time to write, I'd never thought of the expression "steep learning curve" in a mathematical sense before, I used it as most people seem to - steep implying "hard to climb". You're right though!
I do think that you have to be motivated to learn the intricasies of vi, as you say, the operational threshold is low and a lot of coders I've come across get by with the basic dozen commands they learn in the first couple of days in using vi and never invest the time in learning the more powerful commands. I had a spell where I determined to learn one new vi command a day. It's not often I have to "man vi" these days!
-- And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
and finally VIM is Free Software
by
roozbeh
·
· Score: 1
For a long time, RMS did not accept Vim's license as Free Software. But just recently, he accepted it. You can find it here:
"After further consideration, and discussions with some people whose
advice I rely on, I concluded that the Vim license does qualify as a
free software license. Its requirements don't go as far as the ones
that we rejected many years ago."
Re:ViM Author has seen the light
by
Courageous
·
· 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
by
dangermouse
·
· Score: 2
Well no, that's not what he wanted, either. He wanted to be able to pick and choose who gets to keep their changes closed and who has to make their changes' source available (likely in the form of a merge into the main Vim tree). The BSD license doesn't give him that power over modifications.
Re:ViM Author has seen the light
by
Courageous
·
· Score: 2
I know that's not what he wanted, I'm saying he should have just given it away, unadulterated. Of course he can do whatever he pleases, I just don't see that his current licensing scheme is all that helpful to anyone. It's not really "open source" either, I don't think.
C//
Re:ViM Author has seen the light
by
Kiwi
·
· Score: 2
What's your point?
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
--
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Re:ViM Author has seen the light
by
dangermouse
·
· Score: 2
I know that's not what he wanted, I'm saying he should have just given it away, unadulterated. Of course he can do whatever he pleases, I just don't see that his current licensing scheme is all that helpful to anyone.
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.
Yeah that's easy for you to say, doctor, but what about us stupid people?
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:VIm is dog shit!
by
Anonymous Coward
·
· Score: 0
One reason having small, simple tools is such an advantage is that you have the ability to link these tools together. I can type ''cat filename | sort | fmt -w 75 | lpr'' rather than wade through some dialog box hell to achieve the same effect. I can sort the contents of my file (%!sort), or format it (%!fmt), etc. I can even dump a list of my directory or the output of many commands into the file I am editing (e.g. r!ls). No doubt more experienced vi users can think of better examples; you are limited only by your imagination.
True, Notepad gives you the simplicity of a small tool, but it doesn't give you any of the power that small tools can give you, because Notepad is closed off from all other programs. Whenever I find a new text utility I have also made vi more useful; I can't say that about Notepad.
Slashdot Mirror
The "powered by emacs" thing at the bottom is NOT irony.
Do people even know what irony is nowadays?
Bringing irony to the Slash-masses
i know more than these few things.... but hey. god gave me a brain... and i use it.
Have you tried completing vimtutor? I know the basics of wim because I can get by on that for now. When time permits I play to use more of vim's advanced features.
Not many. I think coders just keep adding useless stuff to these editors because its fun for them,
not because anyone actually needs or uses it. If vim was *really* VI iMproved then they'd have
given it logical command keys. I mean 'x' for
delete character?? Control-ZZ to exit?? Come on!
i used to hat vim, still do, no different from vi that i notice, but vi is just so quick for me, i still have to use pico to paste text.
If you ignore ACs because they are anonymous - you're an idiot.
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.
It's "Vi IMproved" because it's a vi clone with extra features. Not with incompatible commands.
:q! or :wq to quit. Didn't even know about Ctrl+ ZZ. And I also don't usually use x to delete a character also, I use the Delete key (and Backspace if I'm in the edit mode).
Anyway, I normally use
Vi Improved by Steve Oualline is an excellent book if you want to discover Vim (as opposed to vi)
OK, this is not flamebait, nor am I trolling: ./configure, make, make install. Easy!
An easy to use editor, which I use daily, is a Pico clone, which is open-sourced. It's called Nano, Linkage here (http://www.nano-editor.org). It operates as simply as Pine, and it has a smaller footprint than Pico. (Yes, I do mean it's simplicity is like Pine, and Pico is the Pine editor, if you did not know.) Try NANO!!! Get the source, and do
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.
About GNU GPL: I don't understand this fully. If you are an author of some code you can always dual-licence it and negotate with a commercial company to pay you for software you had developed (if they want keep it closed). The problem might be a larger number of contributors - you'd have to ask them if they agree with dual-licencing their contributions and pay them off (or exclude/reimplement their code). But I don't see how this changes with BM's licence (source must be available to me) - he might have the source but it'd be unfair to sell someone else's work anyway.
Note that what I said above sais nothing about his decision. Charityware is a nice idea!
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...
And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
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))"
It does take a while to learn, but once you've learned it, it's the most powerful tool there can be.
Don't call it a horrid piece of software before you've learned how to use it.
This message is provided under the terms outlined at http://www.bero.org/terms.html
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!
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.
Push the button Max!!!!
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.
I've used vim and gvim for ages and never had a problem except the odd time using vim on a putty (tm) terminal...
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.
-Never argue with an idiot. They drag you down to their level, then beat you with experience-
Theres a version of vi called VILE
Describes it perfectly!
How come people constantly fail to "get" the GPL? It is designed to give users maximum amount of freedom, it does not take any special steps to give the author a special status. I like this, but I can see how people who don't really care about free software, but rather does it so they can take away users freedom once thay have people locked in don't like it.
A recent thread on the debian-legal list indicates to me that Bram doesn't quite get the whole idea behind free software. A number of Debian users are questioning whether the VIM license is in fact free-- it has a fairly noxious clause about making changes available to the original author. This sort of thing just may not be appropriate in some circumstances. I also think that Bram is a generous, giving, intelligent person who wouldn't go apeshit over infractions that had good reason or were not of true import.
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.
I do not have a signature
I'm using gvim6.0 and my scrollwheel works just fine. Running a X server on Windows.
we seldom realize how many people use editors [like vim] day in and out and how integral its become......
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
Charityware is a nice idea!
Only trouble is, I've got this image in my head now that won't go away - all those orphans in Uganda, each with their very own copy of Vim on floppy disk, looking around for a computer to install it on...
I'm using the win32 version... Not out of choice, you understand...
-Never argue with an idiot. They drag you down to their level, then beat you with experience-
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.
I can tell based on your unbelievably uneducated writing style that all the "nigger" posts belong to one person.
And by the way, who the fuck marked MY post a flamebait? Off-topic, sure, but flamebait?
Works perfectly over here, win32 native on several 6.0 betas as well as the real thing, all installed from the all-in-one executable. You've got a configuration problem, I'd say.
I was installing vim for dos 16, had some problems, and thought "damnit, let me relax a bit with slashdot". And what do I find?
Anyway, does anyone know why syntax highlighting doesn't work with vim for dos 16 (I have my reason for using this version) and is it supposed to work at all with that version of vim?
I wrote a Ph.D. dissertation using vi and nroff/troff way back in the early 80s. When I got my first PC, I abandoned vi for WordStar and eventually WYSIWIG word processors, and thought I'd never go back to "mainframe editors" again. But here I am two decades later using Vim running under both Linux/Unix and Windows every working day (and most vacation days) of my life. It's just plain the most flexible and powerful tool for working with text documents there is.
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.
My other Slashdot ID is much lower.
MS notepad also follows the not so commendable philosophy of limiting file sizes to 64KB. (I suppose that this might be useful in encouraging code readability-- as long source code files might be harder to maintain, but this restraint seems analogous to bondage and domination languages (Pascal, etc).)
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.
No fucking text.
SHUTUP! Shutup, shutup, shutup!
Friends don't let friends use joe.
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!
Yes, you are right. There are a couple of reasonable criticisms that one can make of the GPL, depending on one's selfishness and other factors, but this definitely isn't one of them. Someone needs to straighten this feller out!
;)
Anyways, emacs rulz.
From the help file (I've tried this, it works)
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...
With the GPL everybody is equal.
Whereas, in the real world...
How come people constantly fail to "get" the GPL?
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.
The license clearly delineates a maintainer role and specifies that Bram is currently that maintainer. When he gets tired of it, last responsibility is to hand off to another. Sounds familiar, doesn't it? And the model has grown this way because:
/. readers welcome to insert all sorts of inappropriate analogies here.
a) rule by committee typically doesn't work as well as having a leader or two. A well-chosen committee is great for bringing out all the angles to an issue so that the leader can make an informed decision, but making all the decisions by vote slows down the process and can create dissension among the members who 'lost' the vote. Having one person act as the decision gatekeeper with a "the buck stops here" responsibility level seems to work well for software projects.
and b), there aren't typically a lot of people who care enough about a project to take full responsibility for it. There may be a lot of people interested in patching it to scratch their own itch, but who wants to own or co-own the source tree? Patch integration, commenting, mailing-list moderation, evaluating the latest whiz-bang proposal to rewrite everything from scratch so you can support some buzzword?
"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."
I don't believe that's what the license says...
"If you distribute a modified version of Vim, you are encouraged to send the
maintainer a copy, including the source code. Or make it available to the
maintainer through ftp; let him know where it can be found. If the number of
changes is small (e.g., a modified Makefile) e-mailing the diffs will do.
When the maintainer asks for it (in any way) you must make your changes,
including source code, available to him.
The maintainer reserves the right to include any changes in the official
version of Vim. This is negotiable. You are not allowed to distribute a
modified version of Vim when you are not willing to make the source code
available to the maintainer."
"Nothing was broken, and it's been fixed." -- Jon Carroll
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.
after reading the article ... I saw on the bottom a "POWERED BY GNU EMACS" icon!
[...]
Blame Canada, that's where she's from.
only MS Notepad seems to follow the Unix philosophy.
I'm sure somewhere in the Unix philosophy handbook there must be something about text editors knowing how to display Unix textfiles...
no emacs is for jewish niggers
What the point in having a cake if you can't eat it too?
Je ne parle pas francais.
Most people do not understand it, some do.
Most of the ones that do understand it (and do not agree with it) uses a BSD like license and do not
create a new bad one.
Vi is very very powerful, but it does have a steep learning curve.
I think you mean it has a long learning curve, not a steep learning curve. Most learning curves measure learning over time. The longer the time it takes to learn something, the longer -- and shallower -- the learning curve.
A steep learning curve would be a short learning curve, which is desireable.
There is a point on the learning curve called the operational threshhold, which is the point at which you know enough to do useful work. This point comes reasonably early on the VI learning curve. After that point, the more you learn, the more efficiently you can use the program. Since productivity increases roughly in proportion to learning, the long learning curve is tolerable.
If the operational threshhold were further along the learning curve, that is, you needed to learn a lot to do a little, the trade-off would not be so worthwhile.
Also, the implication of "steep" seems to be that learning VI is hard. I suspect the main impediment to learning VI is that the operations don't resemble the operations of other programs in common use. Almost nothing you already know applies to VI.
To my mind, learning VI resembles learning touch typing except the operational threshhold arrives much earlier.
On Putty, you can get by using ^[ for esc (I do this anyway) and ^I for tab.
Cheers,
hawk, who really hope he's being sarcastic and not accurate in suggesting that emacs has file systems . . .
Just configure putty to use the right keybindings and it works just fine. I've used vim _lots_ from putty and never had any problems (well, except that the termcap/terminfo on solaris sucks and gives no color).
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.
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
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.
He clearly does not, and neither do you. Two words: Copyright holder.
Or put another way... he who owns the code can put it under whatever license he likes. He can release the code under the GPL, and if he wants to license the source to a company for inclusion into its product, he can. Which is exactly what he wants, without yet another bullshit license.
The quote means to continue to have your cake, in its uncut form. In other words, to keep your cake whole due to the aesthetic beauty of it, and to eat it due to it's tastyness.
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
Open Source Identity Management: FreeIPA.org
hawk, who just realized to his horror that his fingers, too, have known vi since before the average slashdotter was born . . .
Using the arrow keys is a terrible habit, and a hard one to kick. I eventually used :map <left> <Nop>, and I'm glad I did.
When did you last see ed display a file?
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.
sed 's/In Soviet Russia/In NSA America/g' < yakov-smirnoff-jokes.txt
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.
you are a retarded son of a smelly shitty bitch...
why does nigger stink like shit ?....
.... so even bling people can hate them...
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
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
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Who's the newbie here? I've been using Vi since 1979. Even Bill Joy's original man page refers to modes. Hey, "vi" originally meant "visual mode".
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.
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?
sed 's/In Soviet Russia/In NSA America/g' < yakov-smirnoff-jokes.txt
Who's the newbie here? I've been using Vi since 1979. Even the original man page refers to modes. Hey, "vi" originally meant "visual mode".
The theory behind GPL is that once the software is put under GPL, then ALL authors who contribute to it get equal say in what they do with it. The original author doesn't get any more say than anyone else just because he's the one that started it. It takes on a life of its own and can't be stopped or repealed. Yes, the decision of an author to put something under GPL should definately not be taken lightly. It's a decision that once made, can never be undone.
Now, that's not always what you want, as in the case of Bram's charityware license. And Bram's decision not to use GPL makes perfect sense. (But not for the reason he cites, which is based on a false premise.) But he really should add a "will" clause for what happens if he is no longer alive, or decides he no longer wants to be the maintainer of Vim.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Stupid question. Is there any connection between you and the color scheme of the same name?
BTW, I am a programmer. VIM 6.0 is now the editor of choice in my workplace ( I compiled and installed it the day it was released.) I have to write a lot of documentation, plans, and proposals. I find many GVIM features exctreemly usefull when editing any structured document.
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
After all, ed is the standard text editor.
So I use the arrow keys. Anyone any suggestions?
Why did they only blow up half the Deathstar?
You appear to be asserting that the GPL can somehow deny Bram his authority as copyright holder to do this..
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//
What finger would you normally use to type an h? Do you have to switch positions after typing each h (or g)? Does typing an h or g cause all your output to be scrambled until you remember to switch back?
You're weird.
Thank you Captain Obvious.
Yeah that's easy for you to say, doctor, but what about us stupid people?
And fuckin' calculus is too hard too, why do you assholes always insist on using it?
Thanks... this was one of the points I should have made explicitly. The other is that even if he is the sole copyright holder, using the GPL hardly encourages others to come to him and negotiate a different license, whereas his license explicitly invites others to do so. The License is The Message, in effect.
sorry, that is a feature and will only increase the bloat of the editor. Just be glad you don't have to use edlin.
Pay attention to context, dumbass. It makes sense to point out that 'i' changes modes when you're replying to someone who stupidly claimed that vi has no modes.
Plus the fact that Vim seems to violate GPL. Well, at least the Debian binaries are linked with libgpm which is GPL'd and therefore requires that all software linked with it be also distributed under the GPL.
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.
I do think that you have to be motivated to learn the intricasies of vi, as you say, the operational threshold is low and a lot of coders I've come across get by with the basic dozen commands they learn in the first couple of days in using vi and never invest the time in learning the more powerful commands. I had a spell where I determined to learn one new vi command a day. It's not often I have to "man vi" these days!
And the people shall be oppressed, every one by another, and every one by his neighbour Isaiah 3:5
--
A member of the first GPL-ed software project in my country
"ed" and "bfs" ;o)
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//
Well no, that's not what he wanted, either. He wanted to be able to pick and choose who gets to keep their changes closed and who has to make their changes' source available (likely in the form of a merge into the main Vim tree). The BSD license doesn't give him that power over modifications.
I know that's not what he wanted, I'm saying he should have just given it away, unadulterated. Of course he can do whatever he pleases, I just don't see that his current licensing scheme is all that helpful to anyone. It's not really "open source" either, I don't think.
C//
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
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
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.
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.
That should say "syntax file", it's the spec.vim file.
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.
One reason having small, simple tools is such an advantage is that you have the ability to link these tools together. I can type ''cat filename | sort | fmt -w 75 | lpr'' rather than wade through some dialog box hell to achieve the same effect. I can sort the contents of my file (%!sort), or format it (%!fmt), etc. I can even dump a list of my directory or the output of many commands into the file I am editing (e.g. r!ls). No doubt more experienced vi users can think of better examples; you are limited only by your imagination.
True, Notepad gives you the simplicity of a small tool, but it doesn't give you any of the power that small tools can give you, because Notepad is closed off from all other programs. Whenever I find a new text utility I have also made vi more useful; I can't say that about Notepad.