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 !')"
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.
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
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..
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.
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
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
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
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
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.
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.
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: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 do not have a signature
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: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.
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.
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. %-)
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!
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.
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: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
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.
Re:ViM Author has seen the light
by
Dionysus
·
· Score: 2, Funny
What the point in having a cake if you can't eat it too?
hawk, who really hope he's being sarcastic and not accurate in suggesting that emacs has file systems . . .
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.
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.
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.
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
Khalid
·
· Score: 2
Well its seems you need to lear sed:)
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
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: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.
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
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.
--
It's only software!
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".
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.
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
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: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.
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.
It's more coppery - doesn't look like iron at all.
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.
Slashdot Mirror
I blame Alanis Morrisette.
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.
Vi Improved by Steve Oualline is an excellent book if you want to discover Vim (as opposed to vi)
Well, I'm doing all my coding under Vim, and I've also written my PhD dissertation under Vim.
I still discover some cool commands from time to time, but you figure out the most important ones rather fast. Vimtutor is a pretty good start.
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!
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.
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.
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!
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
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
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.
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.
Do people even know what irony is nowadays?
Nah, I take my shirts to the cleaners.
- The Boss from Dilbert
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!
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...
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 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.
What the point in having a cake if you can't eat it too?
Je ne parle pas francais.
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 . . .
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:
The definition at Princeton's Wordnet page.
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.
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.
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.
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.
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 . . .
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.
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".
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.
It's only software!
The theory behind GPL is that once the software is put under GPL, then ALL authors who contribute to it get equal say in what they do with it. The original author doesn't get any more say than anyone else just because he's the one that started it. It takes on a life of its own and can't be stopped or repealed. Yes, the decision of an author to put something under GPL should definately not be taken lightly. It's a decision that once made, can never be undone.
Now, that's not always what you want, as in the case of Bram's charityware license. And Bram's decision not to use GPL makes perfect sense. (But not for the reason he cites, which is based on a false premise.) But he really should add a "will" clause for what happens if he is no longer alive, or decides he no longer wants to be the maintainer of Vim.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
One thing I really like about Bram Moolenaar's document is that he took that time to explain the internals of vim and how each file/source code functions.
For a beginning programmer and someone who wishes to participate in open source projects, it is really helpful to have someone/creator/maintainer to sit down and explain the internals of the whole program. Not to mention the nice part about charity license which shows some of the philosophies and vision of the project as well. Most project just say "take a look at the cvs" but it would be nice to have a central document that explains the different files/source code for someone to get started and jump in and help out.
I know that you may be thinking that if I can't look at the source code and not understand it then don't even bother helping out, but the truth is I'm just concerned about efficiency/error prevention. It would seem alot more efficent for me not to have to figure out what's going on by myself but get help to see the big picture and an overview of the project. I'm not saying comment/write about every detail but a general overview goes along way to understand and make sure that anyone new doesn't misunderstand the functions.
Anyway, I think it would serve the open source community better if every project would list all the files and describe what each file handles. It would be better if unclear parts be explained and documented as well.
John Hwang
-- goes here
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
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//
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.
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.
It's more coppery - doesn't look like iron at all.
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.
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.