BRAM MOOLENAAR: Wow.
Is it working?
OK.
It's amazing to see so many people show up for this talk.
I've done a few talks before, and conferences, and mostly
people have to choose between two rooms and they never
choose mine.
So this is very good.
I hope you enjoyed some of the food.
I'm afraid it's not enough.
We didn't really expect so many people to show up.
So let me try to make it up by giving you a good
presentation.
It's called 2.0 because I did this presentation in a
different form some years ago in Holland.
And I think none of you were there, so it's all new to you.
But I did update it with some new stuff, so hopefully it
will be interesting.
There's a big crowd now, so I'll try to answer questions
near the end.
But if there's something that you don't understand on the
slides or something like that, just shout.
OK, let's get started.
So text editing, that's what we're talking about.
I think we all know the problem that we're working
with text the whole day, with email, or whatever you're
working on with log files, HTML, documentation, et
cetera, et cetera.
If I look at myself, I spend most of my day editing text,
if I'm not working on Vim, then it's email or something
else, and it takes an awful lot of time.
So if we can improve our text editing skills a little bit,
that helps a lot.
We can get more work done.
Mostly when I'm not working on text editing, then mostly I'm
doing meetings or stuff like that.
So maybe somebody can do a presentation on how to do
effective meetings.
That would help.
So I'm going to try to explain to you how to get more work
done in less time.
So if you're paid by the hour, you can leave now.
Of course, I'm using Vim for all the examples.
That doesn't mean that I think that Vim is the only text
editor that you can use or should use.
As a basic rule, if you have a text editor that's good, that
can do everything you need, has enough features, it does
the work, and you can still expound it to do the work you
expect it to do, than just stick to it.
I mean why learn another editor when you already have
all the skills in the one you're using?
So if you're using index, you're happy with it, I'm not
going to tell you to leave it alone, unless, maybe, you
think it's not good.
Also, I sometimes see people, even software developers,
using Notepad or a similar editor.
I mean, that's terrible.
I mean, you're wasting a lot of time.
So basically, you either use the editor that you have, that
you're happy with, or you switched to Vim.
There's no other rule.
So otherwise, I'm not going to discuss which editor is best.
That's another discussion, and not very interesting.
I think most of the people here are using Vim, anyway.
Oh, let me ask that.
How many people of you are actually mostly using Emacs?
OK, OK.
We'll try to convert some people today.
I won't ask how many people are using Vim, because then
it's all hands up, so let's don't do this.
OK, how are we going to explain these habits that I
was talking about in the title?
The first step, a very important step--
well, all three are important, so.
The first step is how to know that you're doing something
inefficiently.
Mostly, that's when you are repeating the same thing over,
and over, and over again, and you think, well, there must be
a quicker way to do this.
Must be a smarter way to do this.
For example, what I do myself quite often is you have a
function name, somebody refuse your change says, this is a
terrible function name.
Use another name.
So you have to go all over your code and change one name
into another.
Well obviously, if you're going to find the name, type
the same name over and over again, then not only is it not
efficient, you're also going to make mistakes that you have
to fix later.
And it's even getting more complicated, like if you have
five names that you have to change into
five different names.
And there's a pattern in how you change them, and
obviously, you don't want to type that.
You want to find some way to do it quickly.
The trick here is that you have to do this
while you are working.
So every time you're working on something, you have to kind
of look back, like what did I do the last five minutes?
Did I repeat myself?
Can I do this in a quicker way?
So you have to detect your inefficiency.
That's actually quite tricky, but I'm going to give
examples, of course.
Well, find a quicker way.
Well, every good editor has ways to do things quickly.
The trick is, how do you find them?
You don't want to spend the whole day to
find a better solution.
You want to find it in five minutes.
So I'm going to give you some ideas of how to find better
ways, quicker ways.
And the last, and also important, is how
to make it a habit?
You can read the whole reference manual of Vim, but
that doesn't mean you know the commands.
You don't really use them.
So you have to make it a habit to actually use them,
otherwise you'll have to think about every key that you type.
You really want to get the commands in your fingers, done
automatically.
So it must be a habit.
So basically, what you need to do is you have to see the
problem, you have to find a solution, and make it a habit.
That's quite simple, isn't it?
Let's go on.
About the title, I mean, why seven habits?
Why not three, or why not 42?
Well actually, 42 will be a different book.
I saw this book and I read it, and I think it's quite an
interesting book and gives you a lot of tips about work, and
life, and family, and all kinds of things, and I can
recommend it for normal reading, and I
also liked the title.
So I made the title for this presentation a
variant on this title.
Of course, there's also another variant on this title:
seven years of highly defective people.
I just love Dilbert.
This is really a great book that explains a bit about the
characters around Dilbert, and why they are drawn the way
they are drawn, and how they developed over
the first seven years.
It's really a nice book, especially if you like
Dilbert, of course.
OK, let's get on with the first habit.
This is something simple to start with.
So you have these codes, and you're wondering, where is
this variable used?
I used rsc, for example.
So what do you do?
You search for the name.
And you keep pressing n, n, n, n, to find all occurrences of
that variable.
And then you search for another variable, and do the
same thing again, you browse through the whole code.
And then you type a long n.
But if you look closely, you can see there's a typo in
there, so you don't find anything.
Well, this is what happens a lot if you don't know the
commands of your editor.
So you keep typing a lot of text, typing a lot of
commands, and wasting a lot of time, obviously.
So what's a quicker way?
Well, what's important here, how do you find a quicker way?
In this example, I will say that you just search in the
Help for Vim, and you find something about Search
Highlighting.
And you think, well, I'm searching, I want to see
what's going on, so highlighting will help.
And so you turn on the Highlight Search option.
Of course, you need to search a little bit in
Help to find this.
And especially the Star command.
Well, I think most people that actually use Vim know about
the Star command, especially if you looked on the website.
I think it's actually the first step, one
of the first steps.
Well obviously, what you then get is that you get all the
things you were looking for highlighted, and it gives you
a great overview of where a variable's used.
Of course, this is just a small screen.
If you have one of the bigger screens, you have a much
bigger overview, and that works really great.
Of course, the Star command you use when the
cursor is on a word.
So you type Star, and it looks for other
occurrences of that word.
So how do you make this a habit?
Well, the easiest is to switch on Highlight Search in your
Vim RC, file, in your start-up file, so it's always on.
I do that.
I always have the Highlight Search option on.
That does mean that for every search you do,
you see all the matches.
That sometimes means you have a whole yellow screen.
That happens.
And so I added the hint here that you can switch it off for
a moment, and then it's switched on automatically
again when you search for something.
Again, you have to to make it a habit, so just repeat that
Star command.
You have the option switched on, so that works.
You have to use it again and again.
And after a little while, you don't even think of it.
You just look at a variable, you automatically press Star.
There's, of course, many other ways to move around quickly.
Just to mention one, folding was added in Vim 6.
Some people like it, some people don't.
So you'll have to find out yourself if
you like it or not.
Maybe I can switch and give a life--
oh, that's working.
So what I have here is just a source file.
How does this work?
Here you see a marker in the source file with three
brackets, and that actually marks an area in the code that
can be folded away.
So I can just click on the Minus sign.
If I click right.
OK, then it's closed.
Now if we just move around to some of the other folds, I can
move in just by moving the cursor, and it opens so you
can see the code.
It's quite convenient.
So there's a few commands that you can use with folds to move
around, so you have a nice overview of the
functions in your file.
And you can move around, and then move the cursor, and it's
open, so you can then see the code.
Just one of the many ways to quickly move around.
OK, second example.
You know, if you're working with XWindows, you have these
terrible function names that you have to use all the time.
I mean, it's just impossible to type right in at once
unless you are perfect, but nobody's perfect.
And there is small print, there is capital print, and
there's everything.
You type it wrong all the time.
But one solution that people I have seen using is to Copy,
Paste the name.
So you have a list of names, you Copy, Paste them.
That's a little bit quicker, but still, it's a bit slow.
There's a much quicker way.
So how do you find this method?
Well, what I often recommend is just ask around.
Ask somebody, a colleague or a friend, how do you do this?
And that's actually one of the best ways to
find a better way.
Of course, you have to do it.
Don't be shy.
Ask a question.
This colleague of yours that, of course, is much better in
Vim, then tells you to use the Control N command, or the Next
Insert Mode Completion command.
And what that does is you type some of the letters.
So what happens here is you type like five letters, which
is the start of one of the function names.
Then you'll hit Control N, and Vim will complete the whole
word for you.
Well, if you're lucky.
I mean, if you look closely you see here there's like 16
function names that start with the same five letters, so you
might have to hit Control N a few times to get
to the right one.
But at least that's a lot less typing and a lot less mistakes
than when you would try to type it directly.
This doesn't only work for strange function names.
It also works for the name of people you're
replying to in an email.
I mean, if you reply to somebody and you type his name
wrong, that's also not very good.
That's not very nice.
So I use Completion a lot, especially for people from
strange countries that have these names that are really
hard to type sometimes.
I mean, no offense, but not everybody has English name or
Dutch names, so it looks very strange.
In Vim 7, I discovered that often, you want an overview of
all the matches that exist. So I made this fantastic,
high-tech menu.
And I mean, doesn't it look great?
And you can actually get an overview of all the matches
that have been found.
And you can use the cursor keys to scroll through them.
So that's also for dummies who don't know exactly
how Vim does this.
And also, what this shows is it's actually omni-completion,
and omni is a term that we invented to
avoid a very long name.
What this does is actually, it looks at the context.
So it doesn't just look at the words before the cursor.
It looks for a bit further back, and in this case, it
finds this pointer.
It looks up the type of the pointer, finds out that it's a
structure and the structure has members, and then the
members are obtained, and these are the alternatives
that you get.
So you don't even have to type anything here.
The cursor could have pointed the silver arrow there, and
you just type Control N, and you get all the possible names
that can be valid there, hopefully.
But omni-completion is a complicated thing.
It currently has been implemented for a few
languages like C, Python, I don't think Java really works.
But it's still under development, and we
could use some help.
So if you know a language very well, maybe you can help
developing it.
It's all written in Vim script.
You don't have to program C or anything, but I have to admit,
it's not really easy.
But with a little bit of effort, we can get it done.
And sorry about the ugly menu.
OK, next habit.
I'm not a native English speaker.
I do know English quite well, I think. but I still make lots
of mistakes, especially when typing.
Vim now has a spell checker, which is very nice.
Actually, I think the next slide shows that.
The spell checker, you can switch it
on, and it will highlight.
In this case I was using the GUI version, G Vim.
So it will just underline the mistakes with a nice, wobbly
line, and then you can go there and either use the mouse
or use keyboard commands to see the alternatives for
fixing that.
So in this case, it's just that the
first letter was wrong.
This works.
It works quite well, especially if you have only a
few mistakes in your text.
And if you don't know the language very well so you
don't know the correction, this works really well.
It's supported for about 30 languages, so
that's quite good.
But still, if you have common typing mistakes, you have to
fix every one of them in this way, that's still
taking a lot of time.
So you think, there must be a better way, and there is.
This example I'm using a way to find the solution using the
maillist archives.
You know, the Vim maillist archive is really a treasure
of all kinds of tips and suggestions,
and answers to questions.
So if you use the right keywords, just search in the
archives, and mostly you will find a solution.
Actually, this one is somewhere in the archives, if
you can find it.
But of course, now it's on the screen, so
that's a lot easier.
What does this do?
You basically take the words that you misspell--
so you wanted to type the, but you typed teh--
and you make an abbreviation for it, and insert that
abbreviation.
So that's really simple.
That's one of the basic things in Vim.
You just have to think about actually doing it.
And then you can also, as an extra,
highlight the typing mistakes.
So when the correction doesn't happen for some reason,
because abbreviations don't always kick in, you can also
highlight them so you can have an overview.
So then you get this.
So you have some text, and this is something I typed and
typed wrong.
Actually, I had a hard time typing this, because the
corrections kept kicking him and correcting me, so I had to
switch that off.
So these are just a few examples of common typos.
So you type lonux instead of Linux, and you
type an extra c in.
Of course, these are words that are really wrong.
You would never have them in your text, so then you can
make an abbreviation.
Some words are just--
you still type them wrong, but they're also valid words, so
then you'll have to decide yourself if you want to
correct them or not.
The nice thing about this is it's really fast. I mean, you
can just continue typing all your mistakes, and it corrects
them for you automatically.
The only thing is you have to make a list. I have made a
list for myself because I always make the same mistakes
over and over again, and you probably make different
mistakes depending on your keyboard and
what you're used to.
So you have to make your own list.
And if you want to make this a habit, one thing you need to
do is if you've noticed you make certain typing mistakes,
you have to add that word to the list and find a
correction.
And of course for more advanced users, you could make
a mapping to actually do that, so you don't have to manually
edit that list but you can do it automatically.
OK, well when I started working for Google, I found
this whole pack of codes that's fantastic, but quite
difficult to understand.
So you have to somehow find a way to maneuver between all
the files, find out how it works, and that's quite
difficult if it's a lot of codes.
Of course, this inefficiency is very easy to detect.
You just can't find your way.
The solution is a bit more difficult.
In this case, I give the example of you looking in Vim
quick reference.
Of course, there's also the user manual,
which is very useful.
You just search around in some of the pages on Vim help.
And the quick reference is very good
because it's compact.
You just have some keywords, so if you look for the right
keywords, you can find a hint about what you're looking for.
So for moving around in files, I have two examples here.
One of them is using the Ctags program.
I'm wondering how many of you know Ctags?
OK, quite a few, but not everybody.
Of course, Ctags generate a Tags file.
What I mostly do is if I find new code, I generate a Tags
file, and I do it like this, with the Dash R, which means
recursive, and with the dots, which
means the current directory.
So basically, you have to move to the right directory and
say, generate a Tags file for everything below this, the
whole directory tree.
Don't do that for a big tree, because it will take too long,
but normally, for libraries and stuff like that,
it works just fine.
Then you can use the Tag command to jump to a tag, and
you use T Next if you [UNINTELLIGIBLE]
multiple matches, which especially happens
in C Plus Plus code.
There must be lots of matches for the same word.
You can move around, or use T Select, which is
another tags one.
There's lots of Tags commands.
You can just look it up in the Help file.
The important thing is that Tags only finds where things
are defined.
So where a variable is defined, or where a function
is defined, or a few other things, but it doesn't find
where they are used.
So if you have like a function, and you want to
know, where is this function invoked from, you have to do
something else.
There is C Scope.
That's not a very well-known tool.
Within Google, we have other things that know where matches
are to be found.
But a very common way is to use Grip.
And if you look closely, you can see there's no
exclamation mark here.
So this is not the external Grip, this is
the internal Grip.
It was added in Vim 7.
The trick here is that Vim knows about compressed files.
It accepts this wild card, which means searching a whole
directory tree.
So there's a few tricks that it can do better than the
normal Grip command, but it's slower.
So if you have a lot of files, you might still want to use
the original Grip, and like [UNINTELLIGIBLE], it will just
invoke it, get the lists, and then use that.
So that's up to you.
Anyway, you got a long list of matches, and then you have to
move through the matches.
If there's few matches, you can just use C Next, and C
List, and other C commands to manipulate the list. And
there's one nice thing, though, that if you have a lot
of matches, or you want to get an overview, you have the
Quick Fix window.
So you use the Colon C Open Command, you get
the Quick Fix window.
And there you can actually search around.
It's just a normal text window, except that when you
hit Enter, you jump to the position
that's mentioned there.
Well, of course there's many other ways to move around, and
since it's quite important, I thought I'd make
another slide about it.
Well, Goto File, GF.
You can just type that on any file name and it will jump to
that file if it can find it, of course.
The nice thing, it even works on hypertext links.
We have the net R [UNINTELLIGIBLE]
RW plug-in that does that for you.
And most people don't know that, but it actually works.
Of course, you'd see the HTML SHTML.
You don't see it rendered, but still it's very nice.
An important thing is that the Path option should be set
correctly, because that's how Vim knows where
to find your files.
And they could be anywhere, so you have to make
sure it's set OK.
There's a few more commands.
Actually the square brackets I--
that's a capital I--
searches in Include files.
So that's very useful if you have a lot of library
functions that you're using and you don't know exactly how
they're defined, or you can't find the documentation.
You can search in the Header files, the Include files, and
again, if the path is set correctly.
I quite often just use the square brackets tab, and just
jump to the first match, basically, and hopefully
that's the right one.
And that's very quick, unless you have a lot of Include
files, then it's slow.
I think I forgot making that into a habit.
Anyway, you can do that yourself.
Let's work together.
There's a lot of programs, especially about layout,
email, lots of stuff, that basically you work with text
but add something to it, like layout, or some format like in
a spreadsheet.
The problem is that those editors are OK, but it's
sometimes so difficult do type a lot of text, and the WQ
appearing in your text is not very nice.
So that's one of the inefficient things, and
sometimes when I have to write a document with mark-up and it
has to look nice, than what I mostly do is something that
you have to find out about.
Of course, the trick is, how do you find
out how to do this?
Well in this case, I give the example, ask on the Vim
maillist. There's lots of people on the Vim maillist
that are excellent in giving very nice answers to your
questions, and very patiently and understanding that you
don't know everything.
And it's actually amazing that there's a few people that seem
to be doing nothing the whole day but answering questions on
the Vim maillist. And I'm so glad, because otherwise I
would have to do that, and I just simply
don't have the time.
So let me thank all the people on the Vim maillist that
answer the questions there.
That's just great.
So you ask a question, and then somebody says, oh just
type your text in Vim as you like it, move
it with just a trick.
You switch off automatic text wrapping--
if it was on anyway--
you switch on the wrap, so the lines wrap, and you switch on
Line Break.
This is, of course, the essential part of it.
That means that the lines are wrapped at blank spaces or
special characters, so the words are not broken halfway,
so it's much more easy to read.
It's just a simple trick, but actually if you do this, you
can have paragraphs of one line that you can Copy, Paste
between your Word or Open Office or whatever, and Vim.
So you can edit them in Vim, and copy them back, and that
works quite well.
Of course, it's still work to do the copying back and forth,
but it's at least a lot better than trying to type
your text in Word.
Of course, there's one catch.
You can't Copy, Paste the formatting.
So if you have Bold stuff, and underlining,
that will be gone.
It's not perfect.
Yeah, there's other ways to do this like removing the--
it doesn't say that.
There's another way is that when you Copy and Paste text,
you can actually insert line breaks and remove them again,
but I'll leave that to you to find out how to do that.
Yeah, that's a problem that still exists.
Actually have to scan documents that I write if I
don't leave something in there.
OK, just one more example that I was thinking of.
This is actually something I do when I release a new
version of Vim or make a few patches, is I have to check if
there's nothing wrong on some kind of system, and the
compiler does one for every arrow.
So what I do is I run the Vim source code through Lint, it
still exists.
And I do that actually with like 20 different combinations
of features.
What I get is an awfully long list with
all kinds of warnings.
And most of these warnings are for Header files,
so I can't fix them.
i mean, well, I could perhaps edit the Header file to fix
the problem there, but that's a lot of work.
And then if you go from GTK 2.1.3 to the next version,
then it's all gone again.
They're mostly GTK warnings, I'm afraid.
So you have this long list of warnings, and it's very
difficult to find arrows that you were actually looking for.
So how do you do that?
Well, quite simple, actually.
This time, you just think, OK, I can do it myself.
So you don't ask anyone.
You don't look on the maillist. You just do it.
And you write this simple function, which is nothing but
a global command that searches for the things you don't want
to see and deletes them.
Of course, the trick is to make the pattern match the
lines you want to delete and not match any
lines you want to keep.
So you have to think about that yourself.
In this case, I do things like look for GTK, and
[UNINTELLIGIBLE]
something, and then I don't have that in my code, so it
must be in a Header file.
And the Perl stuff gives errors that match this, so
they're all gone, and it cleans up.
Then I'll make a mapping for this Underscore, C L. I have a
lot of mappings that start with an underscore, because
underscore actually is an original VI command.
It's not properly documented, but it is a command, but don't
ever use it.
So you can actually use it for mappings without interfering
with blocking one of the Vim commands.
So that's a very good thing for more advanced mappings.
So you call your function.
Of course, this is to signal the answering the function
call, and this part you put in your Vim RC file or somewhere
else, just so that it gets sourced when you start up.
And so you run Lint, you get the output, you clean up the
output, and then you use the C File command to load the file
as a list of errors so you can actually jump to the errors
very quickly.
And this is what I use.
It's not much more-- well actually, of course the
patterns, I have a lot more of them.
I can probably show that.
Let's see.
Ah, there we are.
So there's a few more of them if you really
want to do it properly.
And I keep updating this list. For example, if you upgrade
GTK, then it will produce different errors.
And it's quite a long list as you can see.
But this is real.
This is what I use.
And again, you have to make this a habit, so just do it.
Well, I do it quite regularly.
The only thing is that Lint runs a bit slow, so I don't do
it every day.
Of course, what I said, you have to keep
updating those patterns.
That's very important, and especially watch out for
things that you remove that should not be removed.
OK, Habit Seven is actually a different kind of habit.
It's not really an example by itself.
It's a meta example, a meta habit, which is a habit to do
these things.
I mean, I talked about the three steps, and the seven
habits, and you know explained how you do it, and now you
have to do it.
Somehow, when you're using the editor, you have to look back,
what did I do in the last five minutes, or even longer?
Is there something I can improve?
It's very important that every day, you take a few minutes to
think about that and not just keep typing, because it's so
easy to just forget about, just keep going, and then
you'll never learn.
I like to compare that with driving a car.
When you are first in a car, and your driving instructor
tells you what to do, and move the wheel, you know how it
works, but still actually doing it without hitting
anything is quite difficult.
So you learn one thing at the time.
You learn to use the driving wheel.
You learn to use the gears.
Well, you use automatic here.
Well, you learn all the parts that you need to know, even
the wipers and indicators, and all the other knobs, and turn
on the lights, and everything.
It goes one step at a time.
The same for an editor.
You have to learn one thing at a time and keep learning.
The difference between a car and an editor is, a car has
only so many features.
An editor has like 100 times as many features, so there's a
lot more to learn.
So once you have learned to drive a car, you can learn to
drive your editor.
I can skip that.
OK, how does Vim help you with this?
Of course, lots and lots of features.
I think by now in Vim 7, we have most of the things that
people use actually in there.
I can't think of really big things to add that people
would use daily.
Of course, there's still a long list of feature requests,
but most of the things are just for a few people that
would use them, or they're very difficult to implement.
I'm not going to go through the list, you probably know
about that.
Well, I want to say one thing about automatic indenting.
I don't know if you're using it.
If you don't using it, you're probably missing out a lot.
It's just a matter of switching it on, and mostly it
works, especially for Seagull and a few other languages that
are structured enough, it's easy to figure out indenting.
Python, of course, is an exception, because there, the
indention defines what it means and not the other way
around, so that's a bit tricky.
But otherwise, it's a really good feature and saves you a
lot of time.
And why is my [UNINTELLIGIBLE]?
Oh well.
Doesn't work.
Just doesn't work.
OK, so a summary of the three steps.
And somehow it sounds so simple, and it is simple.
You just have to do it.
So you have to detect what you're doing inefficiently.
As I said, look back at the five minutes that you've been
working and think of, what could you improve in those
commands that you've done?
Find a quicker way.
Well, there's many ways to find out the commands that you
need to do it quicker.
Read online help, ask the maillist, ask friends, search
on the internet.
And you can even do it yourself.
Write your own scripts.
I know the Vim scripting language is very specific.
It's not like any other language.
But if you use examples, for example--
most importantly, if you go to the Vim website, there's lots
and lots of useful scripts.
And if you look in there, you will probably find some
examples that you can use, and Copy, Paste, change a little
bit, and that will do what you want.
And of course, the third step, make it a habit.
Make sure that you actually use it, and get it in the top
of your finger so it's almost automatic.
And I think one important thing to add here is that you
have to do one thing at the time.
I don't think you can just sit down one day and in that one
day, do all of this for everything you do, and then
the next day you're going to use them.
No.
It's more like you do a little bit of it every day.
That works much better.
A few counter examples, how not to be effective.
One of the major problems is that your boss tells you that
it has to be done today, or yesterday, you just don't have
the time to look into the Help files or how somebody how to
do something quicker, and it's an obvious mistake that a lot
of people make.
So just take your time to do it right, and in the end you
will be more effective and more efficient, and then your
boss will be happy, too.
The counter example--
I know a lot of people that just start reading reference
manual and want to learn every single command.
You can imagine, not only to they take an awful lot of time
to learn everything, but they're also wasting time,
because most of it, they're never going to use.
And especially, it's not going to be a habit.
So every time they want to do something, they have to think,
how did I do it?
And carefully type their commands, and they end up
being very slow, actually.
So don't try to learn everything.
Just learn the things that you need.
OK, a few more tips.
Read the user manual.
Since Vim 7, I've added quite a bit of text that was based
on the book by Steve Oualline.
He wrote a very nice book for beginners, basically,
how to learn Vim.
And especially the first 20 chapters or so are quite good.
So I took that text, and fortunately, they allowed me
to do that, to copy the text.
And then I fixed some mistakes.
I had to take out the pictures, unfortunately.
And I added all the new things from Vim 6 and Vim 7,
so it's quite big.
And it's really set up so you can read it from start to end.
And you'll have some idea, at least, about all the commands,
and from there, you can actually jump to more detailed
help, so that's very good.
As I said, the Vim user maillist works really well.
Don't be afraid to ask a question there.
Just try to formulate your question properly.
If you ask something like, this doesn't work.
How do I do that?
Then nobody can actually answer your question.
They'll just come back with more questions, because they
don't understand you.
But if you formulate it properly, then I'm quite sure
that within a few hours, you'll get like a dozen
answers, hopefully.
And as I said, thanks to a lot of people that actually answer
those questions.
That's really great.
OK, that's the end of the slides, so
let's have a few questions.
Let's start with questions about what I was talking
about, about the habits.
Anybody, question about the habits at all?
Nobody?
Was it so clear?
OK, there's a hand.
AUDIENCE: I have a question about the [INAUDIBLE]
BRAM MOOLENAAR: Yes?
AUDIENCE: [INAUDIBLE] two ways of doing it?
[INAUDIBLE]
BRAM MOOLENAAR: I can scroll back to that, hopefully.
This one.
OK?
AUDIENCE: [INAUDIBLE]
like a pointer tool [INAUDIBLE]
basically remember who all the members are.
[INAUDIBLE] break this up [INAUDIBLE]
BRAM MOOLENAAR: Yeah.
AUDIENCE: Oh, can it also, if you have a, say within that
structure, you have, say, a pointer to another structure.
Can you follow it?
BRAM MOOLENAAR: Yes, actually if you look closely at what's
shown here.
So for the people watching the video, this is a question
about omni-completion and how it works.
So what happens is Vim takes the first word, so it
basically looks back for the start of something, and mostly
that ends by white space, or a parent, or
something like that.
So in this case, it will find this variable, this name, it
doesn't really know what it is.
So the first thing what it does is actually looks back in
the code if it can find out something about its type.
You can't see it here, but this is actually a variable
local to the function.
So it looks at the declaration to the variable, finds out
it's a pointer to a structure, and then that matches with the
arrow that's there.
So if you complete that, than it knows it's a
pointer to a structure.
It fetches the information about the structure--
which are these fields--
and then completes that for you.
So suppose you take one of the fields of the structure, you
can actually already see here that this field has another
arrow after it.
So that means Vim knows that this is another pointer.
And actually, you can see it's a pointer to this type.
So if you would accept this one, and then type Control N
again to do more completion, it will actually find the
contents of this pref type and then continue.
And it actually goes down as far as you like.
And it also knows about Erase, so that's why the square
bracket is there.
But of course, if you have an int, or a character, then it
stops there, because you can't do any further
completion on that.
Does that answer your question?
AUDIENCE: Yes it does.
BRAM MOOLENAAR: OK.
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: That's exactly what this is for.
So you don't really have to know what this type is or what
it points to, the omni-completion will
find out for you.
And it's quite nice that it's mostly correct.
I cannot guarantee it's always correct, because it's based on
some guessing.
It especially gets confused by prepossessors, like if you
have a Hash If structure there, then of course it gets
lost because it doesn't understand that.
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: Yes.
AUDIENCE: Help Omni?
BRAM MOOLENAAR: Yeah, I think if you just do Help Omni--
actually, you can try that.
There you are.
Well, from there, of course you have to look further down.
Let's see.
Control brackets.
OK, there's actually a lot of help about this.
So we can close it again.
OK.
AUDIENCE: [INAUDIBLE] you need tags for that to work,
[INAUDIBLE]?
BRAM MOOLENAAR: Sorry, can you repeat the question?
AUDIENCE: So if you're completing structures
[INAUDIBLE]
Header file, will Vim actually look at the Header file,
[INAUDIBLE] tags set up?
BRAM MOOLENAAR: For C code, what omni-completion does, it
uses Tag files mostly.
You could use the header files.
The problem is, there's so many of them, so that
would be very slow.
And also you need to parse them, and parsing the Header
files is quite complicated, especially for C, because you
have the three-processor stuff, and the
syntax is not that easy.
And C Plus Plus is terrible.
I mean, who can parse C Plus Plus
without knowing the context?
So the C Tags program actually does that beforehand, creates
a big list, the Tags file, with some extra information
about what is a class, what is a member, what
is it a member of?
And the result of that is stored in a Tags file in a
sorted order, so you can do a binary search on that.
Except that if you are searching for all the members
of a certain structure, it has to scan through the whole
file, because there's currently no
way to cache them.
So that can be a bit slow, especially if you
have a big Tags file.
And like the example of the Linux kernel, with lots of
lots of structures, you could put them all in the Tags file.
That will work.
But then scanning that Tags file will be slow, so I'm not
sure how well that will work out.
I haven't tried.
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: Yeah.
The Tags program is actually quite fast. It has been
optimized to do that.
But it may generate really big Tags files.
AUDIENCE: Yes it does.
BRAM MOOLENAAR: It does, OK.
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: Yeah, and of course of the binary search,
if you're just looking for a specific identifier, it's
still quite fast. But if you have to scan it from start to
end to find all the members of a certain structure, and then,
since they're sorted on the name of the member, and not on
the name of the structure, that can be a bit difficult.
There's, of course, way to improve this.
And also, if you use C Scope, then I think it would be a lot
quicker, because C Scope also stores the back references.
OK, so we're back online, and we're
ready for another question.
OK?
AUDIENCE: Is your vimrc online?
BRAM MOOLENAAR: No.
It's a big secret.
My vimrc is a big mess, I have to confess.
What I mostly do is people send me bug reports, and then
I have to try out to reproduce it, and I end up with all
kinds of mess in my vimrc because
somebody reports a bug.
I try it out, think, OK, this is the way to reproduce it.
So I make a remark in my to do list to look into it.
So I leave the stuff in my dot vimrc file,
because I need it later.
But then, of course, I forget to delete it.
And I have stuff in there for all the versions of Vim, that
sometimes I have to look into.
Well, actually I never do in practice, but it's a big mess.
So I'm not going to publish it.
I think Sven Guckes has actually published his vimrc,
so if you want a good example maybe you can use that one.
I'm not sure if there's other ones.
You should be able to look for that with some search engine
that you might have heard of, and I'm not sure if it
understands the dots, but vimrc it should understand.
No, but I'm not giving you my vimrc, sorry.
AUDIENCE: Vim makes me happy, and the fact that it's charity
work makes me even happier every time I use it.
BRAM MOOLENAAR: Very good.
AUDIENCE: But I have a somewhat political question.
I noticed that you use a Mac, and [UNINTELLIGIBLE] uses a
Mac, but Vim is open source.
And like for nutcases like me, I wondered if you could talk
about open source, but sometimes using closed source
stuff, and just your thoughts.
BRAM MOOLENAAR: So your question is, what do I think
about closed source versus open source?
Is that correct?
AUDIENCE: Yeah.
BRAM MOOLENAAR: Well of course, I very much enjoy
using open source.
I very much enjoy writing open source.
It's just a lot of fun.
I think Linus used as his main remark on what he thinks about
Linux, it's a lot of fun.
And I think most people agree that open source is a lot of
fun for everybody.
The problem is, people have to make money.
If you make something open source, then making money from
it is difficult.
It's not impossible, it's just difficult.
I actually had another presentation on that a couple
of years ago, how to make money
with open source software.
And if you see the overview, you realize that there's just
small parts of open source that you can make money with.
So the result is, yes, we have closed source because people
want to make money with software.
And I think the Mac is another example of where Apple
thought, well, we'd like to give it away, but we also have
to make money somehow.
So they have to close some parts, but they actually have
given away a lot of their stuff.
But there's a gray area somewhere about what you can
give away and what you can't give away.
Google has the same problem.
I mean, most people in Google think, let's
just give it away.
I mean, we make such great software.
Let's just give it to everybody.
But our shareholders don't agree.
And we have a whole open source team within Google who
are actively looking into all the parts of software that we
have, and find out, can we publish this, can we give this
away, or do we need to keep it a secret, because that's the
choice that we have to make.
That's tough.
For me, I think it's OK to use closed source software, but I
keep promoting open source.
I think that's the best way to approach this.
OK?
Another question?
AUDIENCE: How is the integration with various
[INAUDIBLE]
BRAM MOOLENAAR: Yes.
Plug-ins for GUI editors kind of things?
AUDIENCE: Yes.
[INAUDIBLE] use Vim instead of [INAUDIBLE]
BRAM MOOLENAAR: Yeah.
As I said in one of the examples is Copy, Paste works,
but it's not very nice.
Eclipse is, I think, the application where it's asked
most often.
Eclipse has its own editor, and it's quite good,
but it's not Vim.
So people that are used to all the Vim commands have their
bit set of all the functions and scripts that are written,
they can't use them inside Eclipse, so that's a problem.
The main problem with Eclipse is that it defines an editor
interface, so you can actually plug in another editor.
But that interface is so complicated, it's actually
just made for their own editor, that nobody so far has
actually made a good editor to plug in to that.
There are a few solutions.
Somebody has made an Eclipse editor plug-in.
I've never tried it.
I don't know--
you're raising your hand.
You know how good it this?
AUDIENCE: It was actually about the plug-in issue.
Hopefully people here know about Mozex, something that
use Gmail, with Firefox [INAUDIBLE].
But has anyone made some kind of window layering program
that will hijack an editor window in Windows or MacOS,
and plug in [INAUDIBLE] something
else, Mozex on Firefox.
BRAM MOOLENAAR: Yes, you were talking about Mozex for the
[UNINTELLIGIBLE]?
I don't know how it works exactly.
I do know that the KDE people have worked on this, so that
you could use the G Vim with the QT stuff, and plug it in
into basically any KDE application.
But it had issues, mostly with the keyboard focus and stuff
like that, and somehow they have given up on that and
started their own editor, so nobody is working on using Vim
as a plug-in.
They're making a Vim-alike editor for KDE.
So unfortunately, that was a dead end unless
somebody picks it up.
Yeah, it would be really nice if we have a universal
solution to that problem, like ideally, you would have an
editor interface that all applications use.
But it doesn't exist, and I think it will be really,
really difficult to convince everybody to use it.
So yeah, hijacking a window, you can do that.
But then, how are you going synchronize the text, how are
you going to handle keyboard focus, and stuff like that?
AUDIENCE: Actually, what Mozex does, it doesn't try to go
into Firefox, it just [UNINTELLIGIBLE] beside.
And when you save it, it just pushes everything
[UNINTELLIGIBLE].
BRAM MOOLENAAR: OK, yeah, that's that
out-of-window solution.
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: Actually, I've tried using it, but somehow I
didn't set it up correctly to use Vim.
Maybe that's the problem.
But yeah, it's actually a variant of the Copy, Paste
solution, where you copy the text that's there into Vim,
you edit it, and a moment you save it, it's automatically
put back into the original text.
AUDIENCE: Can it work both ways?
BRAM MOOLENAAR: It sounds very simple.
I don't know why nobody has made it yet.
Maybe an idea for someone?
20% project?
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: I'm sorry, I didn't hear the first word.
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: Yes.
Microsoft's Visual Studio, the older version actually had a
possibility that you could add a few buttons inside, and if
you click on them, then the text would appear in Vim, and
you could send it back to Visual Studio.
As far as I know, it doesn't work with the later version of
Visual Studio.
And also, I don't know if somebody's working on it, but
I've not heard of a solution.
I think it must be possible, because I know some other
companies, mostly commercial companies, actually do
something like that.
So I think it's possible.
And again, you must have somebody who actually into the
problem and solves it.
At this moment, I'm mostly busy just with fixing the bugs
in the existing features.
I don't really have time to work on new features, unless
they are really small, or quick to do.
So I'm afraid that most of the feature requests are currently
on hold until I find some more time, or somebody bright steps
up and says, oh, I know how to do that.
Actually, [UNINTELLIGIBLE]
was here.
I can't pronounce his name properly.
[UNINTELLIGIBLE]?
Did I say that right?
OK, and he's actually helping me now with some of the
features that are on the to-do list. So that's really good.
I really appreciate it.
So I wish we had more people like that.
OK, one more question?
AUDIENCE: In regards to text editor productivity, would you
consider using the mouse a productivity [UNINTELLIGIBLE]?
BRAM MOOLENAAR: That depends.
The mouse can be very productive.
For example if you take scrolling--
oh, we have a scroll bar there.
Suppose I would like to move this scroll bar
without using the mouse.
Then I have to use Control E or Control D,
something like that.
How do you say that?
The connection between typing that and what you're seeing in
the scrolling is not very direct and
it can be very slow.
Well, if I just pick up the bubble of the scroll bar,
that's so much more convenient.
Of course, the problem is you have to pick up, so you can
also use the Scroll button.
You can't see that, but I have a Scroll button on this mouse.
And quite often, that's very convenient
for scrolling through.
And I am showing my vimrc.
I wasn't supposed to do that.
So yes, sometimes the mouse is very convenient, so I think
it's up to you.
It's just that, if you're using the mouse a lot, you
have to think, isn't there a keyboard shortcut that's
faster to do this?
In Vim, of course there is.
In other applications, you often end up using the mouse.
I mean, graphical applications are meant to be
used with the mouse.
That's very difficult to use keyboard shortcuts to move
between fields in a forum, for example, than just to click
and it's so much easier.
AUDIENCE: I've never used gVim proper, but I'm assuming that
all functionality has a correct command.
There's no mouse holding.
BRAM MOOLENAAR: Yeah, gVim is basically a graphical layer
around the console Vim.
It's more like a very special kind of terminal.
There's a few more connections to make it work better, but if
I look at myself, I always use Vim in xterm.
The xterm supports the mouse, it supports coloring, it
supports everything that I want to use.
And it's so much more quick in doing things than starting
gVim, and then you have to grab the mouse to point to the
right window, and things like that.
And also, if you want to use external commands, like Grip,
or just use a Copy command or whatever, that works better in
the terminal than it does in gVim.
So for Vim, I would recommend using the console version in a
good terminal.
I mostly use xterm because if there's something in xterm I
don't like, I just ask Thomas Dickey to change
it, and that works.
OK, another question?
AUDIENCE: Is it possible to do completion
based on Google look-ups?
[INAUDIBLE]
BRAM MOOLENAAR: No, you'll have to make that.
AUDIENCE: I tried making it [INAUDIBLE]
BRAM MOOLENAAR: OK, the question actually was, can we
do completion based on Google look-ups?
AUDIENCE: Or anything, like wiki, [INAUDIBLE]
BRAM MOOLENAAR: Yes, some clever way of doing
completion.
Well, if you look into the completion methods, there's
actually a function you can define to do your own kind of
completion, and so you can use that basically to fetch the
matches you want to find anywhere.
The only tricky thing is speed.
Of course, if you want to use Google to look up some
matches, I don't know how fast it will be depending on your
connection, how fast Google is, stuff like that.
AUDIENCE: But it's possible?
BRAM MOOLENAAR: But there are certainly
possibilities there, yeah.
I saw a question over there?
AUDIENCE: For the older [INAUDIBLE]
in the audience, about 10 or 15 years ago, [INAUDIBLE] a
half dozen [INAUDIBLE].
What do you think you did right?
BRAM MOOLENAAR: What did I do right to make Vim the winner
among all competitors?
I think the main thing was that I just
kept working on it.
All the others have disappeared.
I know Elvis was very good, and I liked it a lot.
There are some ideas that I didn't like, but
overall it was good.
But what's his name, the person making it, he actually
decided at one point that he had to do a complete redesign
of the source code.
So then for two years, nothing happened except that he was
working somewhere on the new version, and then when the new
version appeared, it didn't do much more than
the previous version.
The source code was probably great, but nobody looks at
that when you're using it.
So that kind of was the end of Elvis.
Steve has not been worked on for a long time, I
haven't seen it.
One of the other good competitors is nvi, new vi,
which is actually the reincarnation of
the original vi.
Keith Bostic worked on that.
He did a really fantastic job.
I mean, I don't know how he did it, but in just under a
year, he created a whole new editing editor that not only
was completely vi-compatible, because he really figured out
every little bug that vi did that you could call a feature,
and he reproduced it in nvi.
And he also added a lot of new things like multi-windows,
multi-buffers, multi-level, and all kinds of fancy things.
So that was great.
And actually, at that moment when he introduced it, I was
thinking, well, I might as well stop working on Vim,
because that one's better.
But I didn't.
I actually added windows, and buffers, and stuff to Vim, so
I thought, well, I can still compete with that one.
But the same thing happened.
Keith just stopped working on it.
If he would have continued, I think nvi would have been
much, much better, but he didn't work on it.
So now you're stuck with Vim.
OK, one more question.
AUDIENCE: [INAUDIBLE]
GPL license, do you think Vim [INAUDIBLE]
GPL?
[INAUDIBLE]
BRAM MOOLENAAR: About the license, actually the Vim
licenses is GPL compatible, but it's not GPL.
You want to know why, or--?
AUDIENCE: I'm asking is it true that GPL software
survives longer than non-GPL software?
BRAM MOOLENAAR: Does GPL software survive longer than
non-GPL software?
I don't think so, because the license doesn't really change
your software, but there's tricks there.
Using a GPL license sometimes means it's GNU software, so
part of the GNU project, and that means there's like a big
group of people that will take over the maintenance when the
original author disappears or just gives up.
And I don't know exactly how they do it, but they have some
kind of system to keep things going.
But that's different from the licence.
GPL is a license, and GNU is a project.
So it's not the same thing, although I think every project
in GNU has to use the GPL.
I think so.
I'm not sure, actually.
The license for Vim, I wrote a long time ago and I thought,
well, let's just make some kind of license.
And no one was actually actively discussing about
licenses at that time, so I just made one that
I thought was nice.
Just give it away, but you can actually change it, but you
have to give the changes to me.
So I can decide if I want to include them or not.
Very basic, but over time, you have to add certain
exceptions, because people think, hey, but if I do this,
then your license doesn't cover it.
OK, I'll change it.
At one point of time, some people found out that people
compiled Vim with the GPL library.
I think it was the mouse library that's used on the
Linux console, that's actually a GPL library,
not L-GPL, but GPL.
And then, if you compile Vim like that, you can't give it
to somebody else, because the Vim license was
incompatible with GPL.
If you compile it with a GPL library, you can't pass it on
to anybody.
So then people asked me to make the license GPL
compatible, and I did that.
And actually, Rich [? Stormond ?] himself looked
into the license and gave me a few hints until he was
satisfied with it, meant in a very nice way, so no
complaints about it.
So now the Vim license is GPL compatible as far as I know.
I mean, we don't hire lawyers to do this, so we just have a
fresh look at it and think, well, it should be OK.
And I've never had a license problem, so I
don't worry about it.
But basically, you can use Vim, you can use the source
code, and just be happy with it.
Let's take one or two more questions.
In the very back there.
AUDIENCE: Do you have any plans to make it easier to
integrate Vim and GDB?
BRAM MOOLENAAR: And what?
AUDIENCE: GDB, [INAUDIBLE]
BRAM MOOLENAAR: Oh, GDB.
Are there plans to integrate Vim and GDB?
Actually, that's been done.
It's called [? Arida, ?]
and that was actually a project I worked
on a few years ago.
AUDIENCE: But that's really hard to [INAUDIBLE]
BRAM MOOLENAAR: Yeah, the problem is it uses--
the remark is that it's difficult to install.
The problem is it uses WX Python, and that's a nice
graphical library.
It really has a nice interface, but it can be
difficult to install.
it's like hit or miss.
Sometimes it works, but then they make some changes in GTK,
or some of the lower layers, and then it doesn't work.
Then they fix it, and it works again.
Actually, the last time I upgraded my OS, it worked
properly, so I can run it.
But yeah, it's tricky.
And also, I made that as a start, as an example of how it
could work.
And to explain a little bit more about it, it's a Python
application that is a connection
between GDB and Vim.
So it runs GDB, it runs Vim, and then connects the two.
So if you, in GDB list the source code, it will show in
Vim, and in Vim you can set a break point, and that break
point goes back to GDB.
And actually, what I did is I just added enough so I could
use it, and I actually use it to debug Vim, but the problem
is, I made it myself, so I know how it works.
And for other people, they probably use different
commands and say, oh, it doesn't do what I like.
And they give up and throw it away.
So it exists.
It could do with a little bit of work, so if somebody's
interested, it's all on the web.
It's all in download.
It's actually--
oh, we don't need it.
I actually have a screen saver that picks a random one, so I
was wondering if it would pick some of my pictures.
So anyway.
AUDIENCE: What was the name again of the Vim and GDP
integration?
BRAM MOOLENAAR: The name is Arrida.
Maybe I can look it up.
Let's see.
No, that's wrong, sorry.
I have to take a new window, that works better.
OK, that's how it's spelled, and it doesn't work because
I'm not connected.
AUDIENCE: [INAUDIBLE]
BRAM MOOLENAAR: I'm not sure if this works.
Let's try.
I don't think so.
Well, anyway, you can see how it's spelled.
Oh, it works.
AUDIENCE: What's the best way to connect to the [INAUDIBLE]
project?
Because I'm trying to code [INAUDIBLE], quite a few
options, and which is the most effective [INAUDIBLE]
BRAM MOOLENAAR: I don't quite get the question.
You have lots of options, of course, yeah?
AUDIENCE: To donate money to the Vim project?
BRAM MOOLENAAR: Oh, to donate.
That's a good question.
Thanks for asking.
Well actually, when I was working on Vim 7, you may have
notice that at that time, I quit my job, basically, and I
started working on Vim full time.
So at that time, I asked people to please give me some
money to survive, and that worked
quite well, and I survived.
But then Vim 7 was ready, and I thought, well, let's get a
real job again.
So I decided to work for Google.
And at that moment, I thought, well, I don't need that money
anymore, but people kept sending it.
So that money is actually now all going to the same Uganda
project that I've always been talking about as a
charityware for Vim.
So that kind of doubled the donations that are going to
Uganda, so that's very good.
And people just keep donating to Vim.
I think most people do that as a sort of thank you for this
nice editor that they're using the whole day.
And they think, well, I would like to give something back.
And OK, give me some money, and I'll give it to the needy
children in Uganda, and they can really need that money.
I should show you at least what I'm talking about.
Oh, that's not what I wanted, but actually, this is the
right website but the wrong page.
This is actually, if you're interested in the books I was
talking about, the highly effective people book by
Stephen Covey, and the highly defective people book by--
what's his name, the writer of Dilbert.
And if you want to buy them, I can recommend that they're
really nice books and they're not that expensive.
If you use this web page, and click on the links and order
them from Amazon, and there's actually several Amazon places
where you can get them.
So if you're not in the US but somewhere else, in Canada, or
UK, or Germany, you can use one of the links, then
actually a percentage of the sales also goes to the
children in Uganda.
So doesn't cost you anything extra.
What can I say about the project?
Well, this is not really a talk about the project itself,
so I'll just--
that's the wrong one--
I'll just mention it.
There's a website here with
information, and a nice picture.
There's more pictures.
Yeah basically, I've always been trying to promote this
project in Uganda that's very good to help
the children there.
Most of them are orphans.
They really need our help, and the project concentrates
around education.
These people are poor, you would think, well, just feed
them, and that's it.
No, we want to educate them, so that eventually, hopefully
after several years, they can take care of themselves.
That's the goal of the project.
But we are not there yet.
It's going to take a long time.
We have a big school.
We have about 700 children in school.
Every year, about 20 to 50 children finish school, and
hopefully they will do something useful.
And we already see some of the students coming back to the
center as a teacher, or as a help in the clinic, and we can
see it starting to run itself, and that's very promising.
But we are not there yet.
We need a lot of money to keep it running.
So if you feel you need to give something to someone,
think about this one.
AUDIENCE: How did you get involved?
BRAM MOOLENAAR: I think we're going too far off track here
of Vim, because it's totally unrelated to Vim.
So maybe we can talk about this afterwards.
I'll hang around so we can talk about it.
But I've been there for more than a year, so I know quite a
few things about the project.
So that's why I can recommend it, and not
all the other ones.
There's many of them, but this one is really good.
OK, that's a very short summary.
OK, maybe one or two more questions?
OK, there's one.
AUDIENCE: So you mentioned multiple windows or tabs.
Do you have any tips on using those effectively?
BRAM MOOLENAAR: Using tabs effectively.
AUDIENCE: Or multiple windows, [INAUDIBLE]
BRAM MOOLENAAR: Yeah of course, you can use lots of
windows, as many as you like.
Mostly it depends on your screen size, actually.
If you have a big screen, you can use lots of windows.
If you have a small screen, like this small laptop that
I'm using, you can't really fit more than two windows on
there without having the problem that you have to
scroll a lot.
I think that's the main problem if your windows get
too small, you have to scroll to see where you are.
And for me, what I'm mostly doing, I start multiple
xterms, like four or even more.
And it's very easy to switch between xterms. So inside Vim,
I don't use many windows, mostly two, maximum.
And then if I need to work on something else, I just go to
another xterm, start Vim there, and continue.
And of course, you can Copy, Paste file names, and marks,
and whatever, so that works good for me.
Tab pages, they're very nice, and you can actually have
multiple windows on one Tab page, so it's like you have
multiple Vim sessions just next to each other.
Organize them as you like.
I don't really use them myself very much, but that's probably
mainly because I'm an old time Vim user, and they weren't
there, so I have the habit of doing it one way.
And now we have Tab pages, and I don't really need them.
So obviously, you can sort of sort your work in different
Tab pages, especially if you don't have an xterm, but you
have to use, gVim, for example, on Windows.
Then they are very useful, because you don't want to
start many copies of gVim there, perhaps.
Depends on what you're doing.
And of course, it's a quick way to switch between
different pages with Windows, and so if you organize them in
different work groups, or different things you're
working on.
You have to be careful not to get too many of them.
If you have like 20 different Tab pages, you're probably
doing something wrong.
That's not the right way to do that.
There's other ways to organize lots of files.
OK, does that answer the question hopefully?
OK.
I think I'll take one more question and
then we can just socialize.
OK, final question.
who's up for it?
OK.
AUDIENCE: So I use the [INAUDIBLE]
BRAM MOOLENAAR: Yeah, how to use the Vim info.
AUDIENCE: [INAUDIBLE] multiple sessions, [INAUDIBLE]
BRAM MOOLENAAR: Well, if you talk about sessions or Vim
info, those are two different things.
Vim info just stores the last information or the last Vim
you exited, because that's when it stores it
automatically.
You can also store it manually.
At one point in time, you can say, OK, store what I have now
in my Vim Info file, or even create another Vim Info file,
but that's not very comfortable.
If you talk about sessions, like what we were talking
about a session with multiple windows.
So you're working on some project, and you have multiple
source files that you're working on.
You say, OK, now I have to go home.
I want to start this again tomorrow.
The best thing to do is then to make a session from it,
with the Make Session, MK Session command.
You can store it somewhere and recall it later.
You can also use it to store a fuse on a file with all your
Options settings and stuff.
But I think the main thing is store session as a session
under a name, and you can reload it.
It doesn't store everything.
There's actually an option that specifies what you can
store in your session, and that you can
switch on and off.
The default is pretty good, I think, but again, it depends
on what you're doing.
The Vim Info is completely automatic.
I use it an awful lot.
For example, if you edit a file, you exit Vim, you open
it again, and you type Colon E, and just use going back in
the command line history, you find what's been stored in the
Vim Info file.
Same for search patterns, marks, and stuff like that.
Quite often, you don't really think ahead, and think, I have
to get back here.
So you don't remember to put a mark there, you just exit Vim,
and then a few hours later, think, oh, I
have to go back there.
Where was I?
And then, the numbered marks are very useful.
So you can use quote one, quote two, quote three, and
you go back to all the positions where you exited Vim
the last nine times.
So that's not really a session, but in
the Vim Info file.
OK, I think that's it.
Thank you very much for coming.
I'm so happy that so many of you showed up.
I really enjoyed talking to you.
Thank you.
[APPLAUSE]