A2 初級 6671 分類 收藏
開始影片後,點擊或框選字幕可以立即查詢單字
字庫載入中…
回報字幕錯誤
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]?