Forgot your password?
typodupeerror
News

Vim's Bram Moolenaar On Open Source And Vim 6.0 214

Posted by chrisd
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 !')"
This discussion has been archived. No new comments can be posted.

Vim's Bram Moolenaar On Open Source And Vim 6.0

Comments Filter:
  • Not Irony (Score:1, Offtopic)

    by irony nazi (197301)
    Take it from the irony nazi:

    The "powered by emacs" thing at the bottom is NOT irony.

    Do people even know what irony is nowadays?

    • by RatFink100 (189508)
      I blame Alanis Morrisette.
    • by Zocalo (252965)
      Do people even know what irony is nowadays?

      I do. It means "Made or consisting of iron; partaking of iron; iron; as, irony chains; irony particles", but I think the definintion people need to understand is "Incongruity between what might be expected and what actually occurs", which is actually what is happening, isn't it? I for one would have expected to see a "Powered by VIM" button or whatever it says rather than an emacs logo.

      Both the above definitions are cut and pasted from dictionary.com [dictionary.com] before you follow up.

      • Re:Not Irony (Score:4, Insightful)

        by smaughster (227985) on Wednesday January 02, 2002 @10:01AM (#2773478)
        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.
        • 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).
        • Re:Not Irony (Score:3, Insightful)

          by Syberghost (10557)
          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 [princeton.edu].

          Do a little searching for "dramatic irony" and "tragic irony". BTW, most places I've seen the "humor" definition, it relies on the other definitions. For example, Merriam-Webster Collegiate defines the usage you're championing as:

          "2 a : the use of words to express something other than and especially the opposite of the literal meaning b : a usually humorous or sardonic literary style or form characterized by irony c : an ironic expression or utterance"

          Note that in order for humor to be ironic in this sense, it must be ironic in one of the other senses.

          In general, if a person for whom English isn't their native language says something about English, and dictionaries produced by a bunch of English-speaking scholars say something different and largely agree on it, I'm afraid I'm going to have to go with the scholars.
          • 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.
    • 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.
    • Do people even know what irony is nowadays?

      Nah, I take my shirts to the cleaners.
      - The Boss from Dilbert

    • It's more coppery - doesn't look like iron at all.
  • Vi Improved (Score:4, Informative)

    by oops (41598) on Wednesday January 02, 2002 @08:38AM (#2773314) Homepage
    Vi Improved [amazon.com] by Steve Oualline is an excellent book if you want to discover Vim (as opposed to vi)
  • Wow (Score:5, Funny)

    by dimator (71399) on Wednesday January 02, 2002 @08:49AM (#2773339) Homepage Journal
    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?
  • A slicker site (Score:4, Informative)

    by dimator (71399) on Wednesday January 02, 2002 @08:54AM (#2773349) Homepage Journal
    www.vim.org [vim.org] is cool and all, but check out vim.sf.net [sf.net] for a site with all kinds of Vim resources and docs.
  • by f00zbll (526151) on Wednesday January 02, 2002 @08:55AM (#2773351)
    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!

    • Why not just store each line in a file named with the line's number and let the filesystem do all that ugly work for you? Oh, wait, I guess reiserfs [namesys.com] isn't that ubiquitous yet.

      Seriously, there are good filesystems that do all of this balanced block tree work for you, and you should take advantage of them. IMHO, all filesystems should efficiently handle gigantic directories and tons of small files.

      • 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!

        • . . . make it EMACS, rather than VIM :)


          hawk, who really hope he's being sarcastic and not accurate in suggesting that emacs has file systems . . .

      • 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.
      • 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?
    • by Anonymous Coward
      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)
  • fundamental.... (Score:2, Insightful)

    by vvikram (260064)
    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
  • The Key to Vim (Score:2, Flamebait)

    by fm6 (162816)
    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. %-)

      • 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 . . .

      • 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.

        • These [pfuca.com] are nice...

    • 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!

    • by hawk (1151) <hawk@eyry.org> on Wednesday January 02, 2002 @02:10PM (#2774419) Journal
      *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 . . .


      hawk, in curmudgeon mode

      • "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.

      • by fm6 (162816)
        Who's the newbie here? I've been using Vi since 1979. Even the original man page [bsdi.com] refers to modes. Hey, "vi" originally meant "visual mode".
        • by hawk (1151)
          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

  • by DeadVulcan (182139) <{dead.vulcan} {at} {pobox.com}> on Wednesday January 02, 2002 @02:07PM (#2774400)

    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! :-)


    • WOW! That's amazing... you REALLY need ADSL.

      -Russ
    • Well its seems you need to lear sed :)
  • Folding (Score:4, Interesting)

    by lvv (303530) on Wednesday January 02, 2002 @03:46PM (#2774964) Homepage
    What is your opinion about VIM6 folding?

    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.
  • by tavon79 (163246) on Wednesday January 02, 2002 @06:41PM (#2775985) Homepage
    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
  • 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:

    1. 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.
    2. 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.
    3. 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.

If this is timesharing, give me my share right now.

Working...