Vim, an open source text editor

vim,http://linux.21ds.net/2002/03/13/0268dc26fd9c725c23dae68d797935f3/

Author: Bram Moolenaar
Translation: Slimzhao

The creator of the open source free software-vim In this article describes the development of vim in the insider and the direction of development. It also presents the concept of charitable software and explains why Bram this concept to vim. This article also delves into the functions and data structures within the program, and the author describes how the complex program of VIM works, and discusses new features in Vim's latest version 6.0.

Introduced
It is unlikely that you have ever heard of vim. It exists as a standard VI editor in almost every release of Linux. In many systems such as FreeBSD and Sun Solaris 8 it is available as a standalone package for easy installation, source code on other systems (Ms-windows, Macintosh, OS/2, etc.) and compiled executable programs can be downloaded in many places on the internet

Vim is a kind of vi-like text editor, but on the basis of VI added a lot of new features, Vim is generally respected as the best of the Class VI editor, in fact, the real enemy from the different variants of Emacs. 1999 Emacs was selected as the winner of the LinuxWorld text editing category, Vim was second, but in February 2000 Vim won the Slashdot Beanie Best Open Source Text Editor award, and the Emacs was pushed to the next line, overall, Vim and Emacs are also very good text editors.

One of the biggest advantages of Vim (and VI) is that its most commonly used commands are simple characters, which is much faster than using complex control combinations, and also frees up a lot of work on the fingers, and the time to learn to use these commands can quickly be rewarded by the efficiency that this brings to you. In addition, unlike VI, Vim also supports the use of up and DOWN ARROW keys in insert mode, which makes it easy for beginners to get started.

Vim has many features compared to its Class VI editor: Syntax highlighting for more than 180 languages, automatic indentation of C, and a powerful built-in scripting language. For everyone, Vim always has something to make them like.

Vim development is still ongoing, writing this article, the Vim6.0 version of the work has been completed in September (2001), after that, the main goal of Vim is more stable, more practical, rather than to add more new features, to improve the existing functions and modify the bug work has enough people busy. Compared to Vim, the original version of VI has not changed much since 1985.

is a GTK version of Vim a snapshot, the image shows the C source code is being edited, the different parts of the code are highlighted in the corresponding syntax, the searched character mode "Msg_didany" is highlighted in yellow background. The figure also shows a visual selection (gray background), and a green blinking cursor highlights this pattern. The bottom line "–visual–" indicates the current working mode, and to the right is the position of the current cursor in the file.

VIM history
I had an Amiga computer on my own a long time ago. Because I used to use VI, I wanted to find an Amiga version of the vi-like editor. I found some versions called "clones". But not a favorite. So I picked out one of the best to improve it. The initial goal is to achieve all VI functions. Later I gradually added some of the additional features that VI did not have, such as multilevel Undo.

When it looked like it was working well, I released a vim (meaning VI imitation[) VI, which was placed on a public disk by Fred Fish. Then someone sent me some patches, and some tried to transplant vim onto other platforms, such as MS-dos and UNIX. I've added a few more features to make it look better. At this time, vim can be rightfully called "VI improved" ([to] add version VI). Later the entire source code was redesigned and expanded a lot, and almost no trace of the original "clone" source code was found.

At first my work at Vim was purely for the convenience of myself. Later I realized that Vim was also convenient for others, so I put it to the public. Since then, I have been constantly working to make it a better tool to serve a large number of users. It is interesting to create something that is useful to others. At the same time, there are many excellent cooperation groups and users to inspire my work.

The following is the development vitae of vim:

————————————————————————-
1991 2-vim 1.14: First edition (on Fred Fish's number No. 591 disk).
1992-vim 1.22: Porting to UNIX. Vim begins to challenge VI
1994 12-vim 3.0: Multi-window multi-buffer support
1996 May 29-vim 4.0: Support GUI (graphical user interface) (mainly Robert Webb's efforts).
1998 FEB 19-vim 5.0: Color support and syntax highlighting
2001 SEP 26-vim 6.0: Fold line, plug-in, vertical window divider
————————————————————————-

What does the improved (enhancement) in Vim mean?
The 1.22 version of Vim has a lot more features than VI. I decided to change "VI imitation" to "VI improved". Over time the gap between the two is growing, and now there is little reason to use VI instead of VIM. I recommend that all VI users use VIM instead. Here is a partial excerpt of its many advantages:

-There is no limit to the length of the line of text, allowing the ASCII code to be 0 characters; Can edit any type of file
, including binary files.
-Multi-level undo and redo features: When your switch-case keyboard lamp lights up, you don't need to
Heart error operation will ruin your file.
-Multiple windows and multiple buffers: You can edit multiple files at the same time, and you can copy content between them.
-Syntax highlighting: Allows you to quickly grasp the structure of the entire document, quickly find out where the error.
-Command line History and command completion: Correct typing mistakes, quickly repeat history commands, and quickly type
Long file name.
-You can delete and add a rectangular text area: for editing tables
-Error message parsing: Running the compiler in vim and can quickly locate the error message generated by the compilation
Where errors occur in the source code (especially useful for programmers)
-Online help with hyperlinks that are similar to the links in a Web browser, but feature like: let
You quickly find detailed help on any of the commands and read related Help topics.
-A powerful scripting language: You can add your own extended functionality.

Development of VIM
After a few years of hard work after the Vim6.0 version finally finished, the core of the work by me personally, and a lot of people also joined the work, sometimes they add a feature and then send me a patch, so that I add their new features, but most of the time the patch will do some integration work, Few people are able to grasp how the various parts of vim work together. Because the whole code is too complicated. For example, someone sent a patch to search for character patterns across lines. This shows how the feature can be implemented and what changes in the source code are needed. Unfortunately, the author of the patch uses pointers to manipulate each line of text, and he is unaware that these pointers may be illegal. I have to go over the whole new code to correct it. Although it's a hassle to fuse these patches, it does help me get the right direction.

The user's problem with the VIM mailing list is often to indicate which problems are most frequently encountered. Sometimes someone just patches me or asks for some new features. I think this interaction with users and the development of cooperation is the main advantage of vim. Users and developers can communicate directly and openly. That's why open source software is better than commercial software.

Issue
Vim is free to distribute, but there are a few limitations. The following text is released with VIM:

————————————————————————-
Summary
Vim is a welfare software. You are free to use and copy, but we would like you to take a look at Uganda's
Orphans. See the |iccf| section below.
If you are releasing Vim on a CD-ROM, I am happy to receive a copy of it. Just want to know that there are people in the world
Release Vim in this way (you can also show:-) to my friends).
Body
There are no limitations on Vim's unmodified copy and distribution, and vim can be partially distributed, but this text
Must be included. You can also include yourself in the release version from an unmodified source code that compiles
Executable file, or your own use of examples, scripts.
If you are releasing a modified version of Vim, we (maintainers) would like to receive a copy of your included source code
Revised version of the. or let the maintainer can be downloaded via FTP; If the changes made are small, such as just
Changed makefile) It is possible to simply email the difference to the current maintainer, but anyway if the dimension
You must provide the source code to him if the nurse asks for it.
Vim maintainers reserve the right to include these improvements in the VIM release. But there is still room for discussion, but
You are not allowed to issue your revised version of VIM when you are not ready to give your source code to a maintenance person.
The current maintainer is Bram Moolenaar ([email protected]), which, if any, will be publicly stated in the appropriate place (mainly
such as www.vim.org on the website or comp.editors). If you really can't contact the maintainer,
Of course you are no longer obliged to send your revised source code to him.
This article is not allowed to be removed from the vim source code release or part of the release, and this statement also applies to VIM
In lieu of the current version statement.
————————————————————————-

I would prefer to give users greater freedom to use the source code, the reason is to avoid Elvis (a clone of VI) in the past encountered things: Someone got the Elvis source code, add some things such as Windows GUI features, and then began to sell money. After the modified Elvis and the core code of the entire software is still the original Elvis, this is really unfair. Not only because someone else's work to make money, but more importantly, he is unfair open source code, and thus refused to others on the software for further improvement. That's why I added the above restrictions to ensure that other people make changes to the source code must let me know. While these limitations remain, such as a company making a vim revision and then negotiating with me whether or not to make the changes they have made public, I have retained the right to decide on the software I have created.

Why not use the GNU GPL (GNU Public License)?
The GNU Public License is more restrictive, although it declares that it protects software freedom, but actually limits the changes you can make. You can make changes, but if you want to issue a revision, you have to make all of your changes public so that people lose their right to own the source code that they have modified, and I think it actually limits your freedom. On the other hand, it is not fair to allow anyone to modify and then act as their own possession, or even to benefit from a part of vim without making any changes, so I decided to add this condition: All changes to the source code must let me know. I can then decide which of these changes are really good for people and add it to vim. And which only has a small number of user groups, so allow a company to make some money, after all, if a software source code is public, it is difficult to ask users to pay for this.

And I don't think all of the software should be free or open source, and all the people I know working for open-source software are working for business software, or full-time workers, or just looking for, if there's no commercial software, how can people in the software industry make a living? I think that free software, open source software and commercial software will coexist, and many commercial software cannot disclose the source code because the company loses its competitive edge. The creation of software source code is expensive, so business software companies don't want others to be able to get away with it. Due to the fact that software patents and copyright protections are actually weak, it is still the best protection in many cases to withhold disclosure. One unfortunate consequence is that you can't learn how these business software is implemented, or modify the bugs in the software you've bought, and the solution can be to expose most of the source code for a piece of software, but keep the core part of it.

The future of open source software
What software would be an open source project and what software would not be an open source project? There is no answer to the question of whether someone is willing to spend a lot of effort to create and maintain a software for a particular application, largely dependent on a personal motivation: no money, and a lot of labor. This is beyond control, and the consequences are unpredictable. Not long ago people thought that only small software projects could be open source, while large software projects due to project cycle and funding issues must be borne by a commercial software company, but the development of Linux broke the idea, and Linux is not an individual exception, Many other large open source software projects have also been successful, such as KDE.

In reality I find that most people are only interested in the software they want to use. That's what vim was about: I use it every day. This is almost a constraint, as more and more people begin to learn to write programs. This does limit the number of people committed to a particular program, and in theory you can calculate how many of you might be working with open source software as follows:

Number = number of people interested X ability x Motive

which

Number of people working on an open source project
Number of interested persons interested in using the program
The percentage of people who have the ability to write programs
The rate at which a person is motivated to engage in this project

It is worth noting that the number of people interested in using a program also depends on the availability of existing programs, and if there are not enough alternative programs or too expensive, the number will rise if there is already a cheap and good program. The number will fall.

It's not that a person can write software, and the skills required to write different programs are very varied. If the target program is software engineering, there may be a lot of people involved, many of whom do have enough programming skills, if the program is to deal with the data of rare birds, there may be few interested people.

The motivation in the equation is one of the most elusive factors, and how many people are willing to write about it in the ability to write programs? The question sounds interesting to see if this factor can be estimated as well.

An amendment to this formula introduces another factor: how many people are willing to write programs for others. Especially for the disabled people. However, I think the number is very small.

Assuming that the number is finally counted, the big question remains: Is there actually someone who will do it? Or the situation is better: even if, what time? As long as there is enough time, I believe that every program needs someone to do it. There should be a formula to figure out whether a program will be written this year. This is left to the reader to consider ...

In general, there are so many uncertainties in this formula that it is difficult to predict how many open source software will be available in the future.

Welfare software
Since Vim is an open source software and is released free of charge, the user does not need to pay for the use of it. Even so, there are people who often use vim to say that they want to give a compliment to the work I've done. I don't really need extra money myself, and I don't like people paying me for using a free software. At that time I began to consider the concept of "welfare software". The main idea is that people who use vim will donate to the welfare service. It's free to use VIM, but you can pay for a better reason if you think it's worth it.

How could I have chosen welfare? Yes, I have worked as a volunteer for a project in southern Uganda for a year. The area is seriously violated by AIDS. An estimated 10% to 30% of adults are infected with HIV. Many of the parents were dead, leaving their children alone. This project helps these starving children in several ways. Find a new home for them, make sure they can go to school, or give them medical care, and so on.

I was still thinking about it when I got back from Uganda. I decided that at least I could continue to support the project by giving them some money. It's a logical thing to relate to VIM. So now I'm asking vim users to consider donating to the orphans in Uganda. You can adopt a child financially, which will help him to get long-term stability, which is best for the child. Since we are only working with volunteers and the money is delivered directly to the project, the vast majority of the money can really be used in Uganda.

You can find more relevant information in http://iccf-holland.org.

Nabasagi Morine is one of the children sponsored by the Dutch ICCF.

Does the benefit software really work?
Through the welfare software, I did receive a lot of donations to Ugandan orphans. The situation is uncertain, sometimes for one months, and sometimes several donations at a time. Some numbers are very small and some are very large. I am not sure of the exact number because not all donations are made by me, and it is unclear whether it is because of vim. A total of $2000 was received in 1997 and $4000 in 1998. Quite a bit of it comes from Germany.

It's not just about money, it's about welfare software that makes people aware of other people's needs. If I do not, there will not be so many people who know this project in Uganda, and it is hard for many to imagine that there are many other worthwhile things in life besides earning money and caring for themselves. I have also come into contact with people who are unable to donate, but are deeply touched by this concept. In some ways welfare software can really change people.

Is the benefit software also available for other projects?
Check the following points to determine if it applies to your project:

You don't need the money yourself. If you spend your money on a car bigger than your neighbour's, it's not for you.
You're doing a shareware, but not much, because people don't want to give you the money.
The software you currently offer is completely free, but you think it's worth what people pay for it.
When will you decide to do welfare software and what reason will you use? The best one is through this you can personally contact some people. Users will be better able to understand your motives, and find an organization you can trust that requires money and attention. I do not advocate supporting large organizations, especially those that have a way of contacting sponsors.

Variants of the Benefits software
I do not force users of vim to donate to projects in Uganda. There is no limit to the number, the greatest freedom for the user himself, he can read the Ugandan AIDS and then forget it.

Alternatively, users are told they must donate, and also specify a minimum limit. The declaration must be placed in a place that cannot be ignored by the user. Hopefully this will lead to more donations, but be careful not to annoy the user. You must set a minimum limit, otherwise this compulsion will be meaningless. However, it is difficult to determine how much this minimum limit is.

Another more compelling practice is to limit some or all of the functionality until a user's donation is received. This is not a good way, because it does not conform to benevolence; So the poor will not be able to use your program!

VIM Insider
Vim has become a very large project. Here is an overview of the main parts of the program and the distribution of the source code. I also count the size of each file (for version 5.6) so that you know exactly how much code is needed for each part of the program.

Program startup code, main command loop MAIN.C 43538
command handling for normal command mode NORMAL.C 140320
Execute command-line command OPS.C 109742
Display text on the screen screen.c 165136
Multi-window processing window.c 52168
Multi-buffer processing buffer.c 63743
Command pre-modifiers, key mappings, and abbreviations getchar.c 76964
Terminal input/Output TERM.C 109869
File read/write fileio.c 122685
Exchange File Management memfile.c 31516
Buffer Row Management memline.c 114193
Undo and Redo Undo.c 29014
Insert mode edit.c 142302
Keep tags in files mark.c 25582
Command line edit Ex_getln.c 89509
Execute ex Command EX_DOCMD.C 176724
Combined ex Command EX_CMDS.C 100549
Quick Change Error Command quickfix.c 31760
Regular expression matching regexp.c 73771
Search Command SEARCH.C 93721
Flag Command TAG.C 69337
Option Settings Option.c 148884
Vim script command, expression evaluation EVAL.C 122346
Specific system-related code os_*.c up to 94640
Common GUI Code gui.c 73468
GUI code for motif GUI_MOTIF.C 26963
GUI code for Athena GUI_ATHENA.C 25220
General motif and Athena GUI code gui_x11.c 62913
GTK GUI Code gui_gtk*.c 158289
GUI code for ms-windows gui_w32.c 141809
Macintosh GUI code gui_mac.c 82600
Menu Handling MENU.C 36164
Perl Interface If_perl.c 21246
Python interface if_python.c 51814
Sniff interface If_sniff.c 25035

Each file is generally very large, because I like to put the functional related program segments together, you can also use a number of small files, for a version control system This is especially true, but for me at present this is fine, there seems no reason to change it to other appearance. All files are placed in the same directory, and the greatest benefit is that a simple grep command can easily find an identifier.

Several of the above lists are worth noting. The "undo" feature has a relatively small amount of code, mainly because it uses a ' well thought-out ' mechanism, which is simple and powerful. On the other hand, you can also see that the GUI-related files are generally very large, and the GUI coding is really laborious.

Professor Michael Godfrey has done some research on the system structure and development of vim, and you can find the relevant discussion in http://plg.uwaterloo.ca/~migod/. (I didn't find it, if you find it, please give me an accurate URL)

Here are some special questions you might be interested in.

Portability
Vim is designed to work on different operating systems, and it's not easy to do that. The amount of work that supports most mainstream UNIX versions is already quite large. Additional support for MS-DOS and Ms-windows raises additional questions, such as the use of backslashes in file names. Machines like the Amiga and the Macintosh have their own set of operating systems, and they need a different approach.

One of the first choices is to use the well-known "old" K&r C in Vim's entire code. This allows the code to compile on almost any system. Using ANSI C plus a preprocessor can also receive the same effect. For example, a function prototype like this:

void Ml_open_file __args ((BUF *buf));

The compiler "__args (())" section of the non-ANSI standard is processed as "()". These prototypes are generated by the Cproto program. Auto-generation using tools is not just about eliminating the manual typing of these prototypes, but also avoiding the possibility of errors. Using the __args structure brings some extra work, but it allows vim to be compiled on some antiquated systems, and modern compilers can check prototypes to avoid a lot of hassle.

In order for VIM to compile successfully on different systems, there is a system-related file for each system, such as "os_unix.c" or "OS_AMIGA.C". These files contain a lot of system-related code. However, this does not solve all the problems, in the general file there is a large number of "#ifdef" such as the pre-compiler control options to solve different compilers, different operating systems, different architectures related issues. Sometimes I will clear these things to avoid the confusion of the code. It is necessary to build a function such as "mch_xxx ()" In each system-related file and invoke it from each generic source file. Because I can't have all of these different systems, it's up to the co-developers to test the changes.

For UNIX, the "autoconf" command can be used to test different things in a system. It will find out where each "include" header file is, where the library files are, and so on. It uses a description file called "configure.in" to list what needs to be "probed". The autoconf command processes this file and generates a shell script called "Configure" that autoconf will take care of in place so that the script can be eaten in every UNIX. Although it's not easy to use autoconf, I recommend it to everyone. If you're going to make your program go all the ways on different UNIX, autoconf is the one that cares.

The standard practice for users is to run the "Configure" command, which generates a file named "Makefile". For VIM, the situation is different, because before this, there is a "Makefile", the first time you run "make", it will automatically call "Configure" for you, using the default parameters, which leads to the generation of a file called "Config.mk", One of the main benefits of this slightly different approach to the file being included in Makefile is that the makefile file can contain some examples of configure parameters that you can comment out. Alternatively you can find all of these available parameters by running "Configure–help", check the output of this command, find the parameters you want to handle carefully, and for vim, you can manually edit the makefile file, read its explanatory notes, or delete or insert some "#" characters, It's good to do. Traditional running configure is also possible, so this extra approach does not bring negative effects.

Storing text
Text storage
A text editor's main job is to read a file, modify it, and then write the file. There are several factors to consider in the form of how text is stored inside the editor:

-Read and write files quickly.
-There is no limit to the file size, character set, and length of text lines.
-The code to process the file cannot be too many.
-Allows the undo operation to be undone.
-When the system crashes, you must be able to recover unsaved changes.

There is no easy way to meet all of these requirements easily. First, it's impossible to put all the text in memory, some systems don't have much memory at all, and it's very inefficient to use a lot of memory for other systems, which is why I use a swap file. File access is slow, so there is a need for some text to be placed in memory through a caching mechanism. Because file I/O operations are fast with a fixed-size block of gigabytes of data, it is best not to write individual lines of text back into the swap file. After considering several alternatives, I decided to use a structure to hold a certain number of lines of text in the data block. These blocks are manipulated in a manner similar to the "DB" function on a BSD system, but are clipped according to the way Vim uses text.

You can find code in the file "memfile.c" that handles data blocks that hold text lines. It reduces the burden of disk I/O by maintaining a buffer. Works like all caching systems: chunks write to swap files when they use too much memory, or they save changes made by the user. This also makes it possible to recover unsaved content from a swap file when the system unexpectedly crashes.

The code that packages the lines of text into chunks is in the "memline.c" file. Because the chunk size is fixed, the number of lines of text that can be placed is different. This requires a lot of code to handle, how to be able to insert, delete, and modify lines of text. The complexity comes from the fact that when a line of text is inserted, the block of data that holds it does not fit, which results in a chunk that must be divided into two. In addition, there is a special case: a text line to a whole block of data even if it does not fit. This requires creating an unconventional chunk of data that is large enough to hold the contents of the line. This makes it possible to limit the length of lines of text without affecting the efficiency of processing short lines of text.

The data blocks stored in the swap file are not in a particular order, and if you want to sort them, inserting a block of data into the center requires that all the blocks behind it will go backwards, which is too slow. To find a line of text by line number, you need to use a block index. The block index contains a list of lines of text in a block of data, and if the file is too large, the list may not fit in a single block of data. It also needs to be partitioned into chunks of data, which requires another index block to "index" the chunks of data that are required to be separated by data growth. (This is a bit like a pointer in C language). This makes up a balanced tree of index blocks, and the text blocks are leaf nodes. The practice proves that this structure is stable and efficient.

Syntax highlighting
Analyzing the structure of a file is complex enough. It is also necessary to consider that this parsing may take place in a file as a starting point, two problems together, will certainly die. Fortunately, the design of vim divides the entire task into two parts: the core grammar engine, implemented in C, and specifies the syntax of the different languages by the character pattern. This allows VIM to support a new syntax without recompiling.

The basic idea is to use a regular expression to specify a grammar term for a language. Vim attempts to match this pattern in each row. If it matches, the corresponding highlight color highlights the matching string. This is easy to do for syntax items that are in one line. But it's a lot more complicated for cross-line syntax items, and in vim you need to specify a character pattern that specifies how a grammar item will start and end. For example, for comments in C, the word "/*" ends with "*/". But what happens when vim touches a half-commented line? There is no "/*" in this line, so it has no way to determine if it is a comment. This requires vim to go back and do some searching to determine whether the current line is part of a comment. This is called synchronization.

The other structure is nested. This happens when you want to display the "TODO" contained in the note in a different color definition than the annotation. So there is also a subkey for the "TODO" syntax item in the comment syntax item. Also, if a "/*" string is found in a string, it is clear that it does not mark the beginning of a comment, which makes the string syntax entries more than one mind, preventing "/*" or "* *" from confusing. All of these conditions are categorized as "can contain syntax items", and for each syntax item the user can specify which sub-grammar items it can contain. This processing applies to the structure of most languages.

The code that handles the syntax item maintains a stack of nested syntax items. For any location in the file, Vim looks for sub-grammar items that can be included in the current syntax item, so the stack of this syntax item also represents the current state of the syntax highlighting engine. To speed up the processing of syntax highlighting, this state is saved and reused when the same line of content needs to be displayed. The syntax state that is saved when the content distribution of a text line changes is also invalidated. A row change can also cause the syntax state of its subsequent lines to change, such as inserting a "/*" in a row to comment out a portion of the code until a matching "*/" is found, and all subsequent text is treated as comments. The program knows that the syntax state after "* *" is the same as the previous state, so all the syntax states are still valid, and the re-shuffling of the grammatical state stops at "*/".

Data
Vim uses different data structures to store different content. Compromise on a common data structure and special specific data structures tailored to the problem. For example, a string can be stored in a fixed-size array of characters in a stack, or in a dynamically allocated, fixed-size memory area, or in a dynamically allocated, variable-sized memory area, depending on the type of string to be stored.

For a string that has an upper limit known to its length, using a character array in the stack eliminates the need for malloc () and free () calls. This is typically used to handle file names, but Vim avoids restrictions on the user. Other strings can be of any length, so the stack does not apply to other cases where the string length is undefined.
Allocating a fixed-size memory area is available to memory requirements that do not change frequently. For example, for option values, this does not waste memory, and the overhead of malloc ()/free () is not a problem.
For frequently changing strings, it takes a lot of time to call malloc ()/free (). This is especially true for cases where the size of strings and lists is often increased, and in vim a dynamic memory allocation structure called a "structured growth array" is specifically designed to deal with this situation. The memory allocation has a large stride size, so you can accommodate larger data without having to redistribute it.
Creating these data structures in vim really kills me. The downside is that it takes too much time, adds complexity, and is more difficult to maintain. The advantage is that it gives vim a higher efficiency. For Emacs, the user's biggest complaint is that it is too slow to consume resources. My impression is that Emacs uses regular data structures and hopes for faster hardware. In my opinion, my choice is correct. A text editor is used by many people every day, and it's worth giving the author time and effort to make it more efficient.

Feature List
In November 1998 A survey of Vim users was launched to decide what changes vim would make. The survey results best describe what users want most, and here are the top 6 on the leaderboard:

1. Fold line function (show only selected parts of text in a text line)
2. Vertical Divider Window
3. Added configurable auto indent for many languages
4. Modify the bugs of large and small to make it more robust.
5. Added Perl-compatible search mode
6. Cross-line search mode characters

The first 3 and 6th have been implemented in Vim6.0, and the bug has been modified as usual, never stopped! The search for pattern characters has been extended to encompass all the relevant features of Perl, but it is not directly compatible with Perl, as this brings backward incompatibility with vim.

Fold line
The first attribute added to Vim6.0 is a wrap. This is a mechanism for hiding part of a line of text, allowing the structure of the entire text to be highlighted. It looks like folded paper. This is a big change. It also affects other code-it's not known how users will use these features with different files. I spent a lot of time researching how to make the user interface with a broken line more friendly and different users have different needs. I have set up the following modes of wrapping:

Manually select which lines to fold up by hand.
Based on the indentation of the indented text line as to which lines are to be collapsed, for example, all indents are super
Lines that are over 8 spaces are collapsed.
The expression is based on an expression, as if it were indented, but based on it.
Syntax highlighting items determines the collapsed area
Tags are used to indicate where and where in the text to collapse.

Many wrapping methods do not require a change of file. This is necessary for those who only need to view the contents of the file, or those who share files with others. However, these methods do not allow arbitrary specifying how a collapse should begin to end. Therefore, a "tagging" method is added. This method allows you to insert a marker where you want to start collapsing, for example, if you have comment lines before the function definition, you can put the comment markers on top of the comment lines so that they are either collapsed with the function, or you can specify some extra text to describe the collapsed content, such as "local Declarations "or the function name comes with a short description. The disadvantage of such a break definition is that the file itself is modified because of these inserted tags.

This image shows the C source code using the Wrap function. The ' foldlevel ' option is set to display one row for each function. These lines are also defined as "{{{1″, with a brief description of the collapsed content." The collapse of the function "linefolded ()" is opened to view the function.

Multi-line search pattern characters
As mentioned earlier, I added the ability to cross-line search mode characters, a new feature that is very brief in the document, because it's easy to say that a new pattern can be matched to a line end. However, this feature has a large impact on the entire source code, mainly because the problem is that the minimum limit in one buffer is to keep a line of content in memory, and the space occupied by the previous row may have been freed up for other rows to use. This limits the use of memory. But the code that calls pattern matching always assumes that its pointers are all available. But now it wants to take the other rows in the buffer to check if a pattern match is met, so its assumptions are not always true, and the solution is to use the position of the line number and column instead of the pointer.

It took me a day to add a patch that matched the cross-line pattern to the code, but it took a whole week to make the changes. It is easy to underestimate its impact. The real results are only clear when you implement it and test the new functionality. If this happens in the development of commercial software you will miss the final delivery period, the budget has become tense, in short, the trouble is big, fortunately, for the development of free software This is not the top priority, you have to spend more time, software release a few, so it is usually not worth the delay caused by the plan. This is a huge advantage of free software.

UTF-8
Another add to version 6.0 is internationalization support. Vim already supports double-byte files. This is called multi-byte support, but actually it doesn't work for a lot of double bytes because everyone is turning to Unicode, that's what I'm adding. Historically, Vim uses bytes internally, so it is natural to use UTF-8 encoding (Unicode character set encoding as a 8-byte sequence). Another option is to use wide characters, but this requires changing all of the text processing code, since most characters are still 7-bit ASCII, so this can be an efficiency issue.

There are a few things to be sure when adding support for UTF-8: is the text that vim handles encoded in UTF-8, or does it use an option to switch between ASCII and UTF-8 or even double bytes? It's a good thing to have everything pressed UTF-8. The code is simple because it only needs to handle one type of encoding. However, typing characters, displaying text and copying and pasting to and from other applications uses another encoding, which requires conversion between UTF-8 and other specifications, which can cause overhead and change the text. The latter is absolutely unacceptable and must be avoided. If you read a file with vim and write it back without making any changes, it should give you exactly the same file.

So the main question is whether the file is read into Vim to convert it to UTF-8 encoding or to keep its original encoding:

Saves all text internally with UTF-8.
When the file is read, it is converted to UTF-8, the file is written back to the original mode of the file, the type of text needs to be converted, if the input method does not support the UTF-8 format, or the screen display using another format, you also need to convert.

Keep the original encoding of the file.
The text you type and the characters you send to the screen only need to be converted if they use another format. So the function that handles the text must know all the possible formats. It is also necessary to convert the text in one window to another window that uses a different encoding format.

Both approaches have pros and cons. After a few thoughts, I decided to use a mixture of the two. The internal format can be selected, either ASCII, UTF-8, or double-byte encoding or even any other encoding. In general, this should match the environment (the current locale setting). If possible, a conversion occurs between the file format and the internal presentation format. Jumps over when the conversion is not possible (unavailable or illegal characters). This may cause the text to be displayed incorrectly, but at least the text is written back without errors

Conclusion
Vim has grown into a large open source project. It is not only a useful popular software, but also a successful example of open source software development. I hope vim can inspire and help other open source software authors.

If you want to use VIM, you can find it in many places: if you have a Linux, FreeBSD, or Solaris 8 release, find a VIM package that you can install, install it easily, and for Linux, the VI command launches a lite version of Vim, If you want to use more features you need to install the VIM package yourself.

For more information on how to download vim, see the url:http://vim.sf.net/download.php below.

A large amount of information about vim can be obtained from http://www.vim.org. Luckily Sven Guckes is maintaining this site so that I can focus on the development of vim. Vim tips and plugins can be found on the http://vim.sf.net. This content is created and uploaded by vim users.

If you have any questions, bug reports, or want to help with VIM's development, you can join VIM's mailing list. Refer to Http;//www.vim.org/mail.html

Bram Moolenaar

——————————————————————————–

Bram Moolenaar, who studied electronic engineering at Delft University, was working on a UNIX dual-processor structure when he graduated in 1985, and now he works mainly on software, but he remembers how to use a soldering iron, which he was born in Holland. A place full of tulips, now he lives in Venlo, east of Holland, who worked for OCE for years, designing the company's first digital image copier. He is currently engaged in freelance work and spends a lot of time on the free Open Source software project VIM (http://www.vim.org/), which is the main author of Vim. Do the job to handle a lot of mail, contact users and other collaborators, modify bugs and add new features. Bram established the ICCF Foundation in the Netherlands. To support the child Care Centre in Uganda (Kibaale Children's Centre), this project, through education, medical AIDS victims, his homepage in http://www.moolenaar.net/, email address is:%[email Protected

Vim, an open source text editor (GO)