|
7
|
1 *develop.txt* For Vim version 7.0aa. Last change: 2004 Jan 17
|
|
|
2
|
|
|
3
|
|
|
4 VIM REFERENCE MANUAL by Bram Moolenaar
|
|
|
5
|
|
|
6
|
|
|
7 Development of Vim. *development*
|
|
|
8
|
|
|
9 This text is important for those who want to be involved in further developing
|
|
|
10 Vim.
|
|
|
11
|
|
|
12 1. Design goals |design-goals|
|
|
|
13 2. Coding style |coding-style|
|
|
|
14 3. Design decisions |design-decisions|
|
|
|
15 4. Assumptions |design-assumptions|
|
|
|
16
|
|
|
17 See the file README.txt in the "src" directory for an overview of the source
|
|
|
18 code.
|
|
|
19
|
|
|
20 Vim is open source software. Everybody is encouraged to contribute to help
|
|
|
21 improving Vim. For sending patches a context diff "diff -c" is preferred.
|
|
|
22 Also see http://www.vim.org/tips/tip.php?tip_id=618.
|
|
|
23
|
|
|
24 ==============================================================================
|
|
|
25 1. Design goals *design-goals*
|
|
|
26
|
|
|
27 Most important things come first (roughly).
|
|
|
28
|
|
|
29 Note that quite a few items are contradicting. This is intentional. A
|
|
|
30 balance must be found between them.
|
|
|
31
|
|
|
32
|
|
|
33 VIM IS... VI COMPATIBLE *design-compatible*
|
|
|
34
|
|
|
35 First of all, it should be possible to use Vim as a drop-in replacement for
|
|
|
36 Vi. When the user wants to, he can use Vim in compatible mode and hardly
|
|
|
37 notice any difference with the original Vi.
|
|
|
38
|
|
|
39 Exceptions:
|
|
|
40 - We don't reproduce obvious Vi bugs in Vim.
|
|
|
41 - There are different versions of Vi. I am using Version 3.7 (6/7/85) as a
|
|
|
42 reference. But support for other versions is also included when possible.
|
|
|
43 The Vi part of POSIX is not considered a definitive source.
|
|
|
44 - Vim adds new commands, you cannot rely on some command to fail because it
|
|
|
45 didn't exist in Vi.
|
|
|
46 - Vim will have a lot of features that Vi doesn't have. Going back from Vim
|
|
|
47 to Vi will be a problem, this cannot be avoided.
|
|
|
48 - Some things are hardly ever used (open mode, sending an e-mail when
|
|
|
49 crashing, etc.). Those will only be included when someone has a good reason
|
|
|
50 why it should be included and it's not too much work.
|
|
|
51 - For some items it is debatable whether Vi compatibility should be
|
|
|
52 maintained. There will be an option flag for these.
|
|
|
53
|
|
|
54
|
|
|
55 VIM IS... IMPROVED *design-improved*
|
|
|
56
|
|
|
57 The IMproved bits of Vim should make it a better Vi, without becoming a
|
|
|
58 completely different editor. Extensions are done with a "Vi spirit".
|
|
|
59 - Use the keyboard as much as feasible. The mouse requires a third hand,
|
|
|
60 which we don't have. Many terminals don't have a mouse.
|
|
|
61 - When the mouse is used anyway, avoid the need to switch back to the
|
|
|
62 keyboard. Avoid mixing mouse and keyboard handling.
|
|
|
63 - Add commands and options in a consistent way. Otherwise people will have a
|
|
|
64 hard time finding and remembering them. Keep in mind that more commands and
|
|
|
65 options will be added later.
|
|
|
66 - A feature that people do not know about is a useless feature. Don't add
|
|
|
67 obscure features, or at least add hints in documentation that they exists.
|
|
|
68 - Minimize using CTRL and other modifiers, they are more difficult to type.
|
|
|
69 - There are many first-time and inexperienced Vim users. Make it easy for
|
|
|
70 them to start using Vim and learn more over time.
|
|
|
71 - There is no limit to the features that can be added. Selecting new features
|
|
|
72 is one based on (1) what users ask for, (2) how much effort it takes to
|
|
|
73 implement and (3) someone actually implementing it.
|
|
|
74
|
|
|
75
|
|
|
76 VIM IS... MULTI PLATFORM *design-multi-platform*
|
|
|
77
|
|
|
78 Vim tries to help as many users on as many platforms as possible.
|
|
|
79 - Support many kinds of terminals. The minimal demands are cursor positioning
|
|
|
80 and clear-screen. Commands should only use key strokes that most keyboards
|
|
|
81 have. Support all the keys on the keyboard for mapping.
|
|
|
82 - Support many platforms. A condition is that there is someone willing to do
|
|
|
83 Vim development on that platform, and it doesn't mean messing up the code.
|
|
|
84 - Support many compilers and libraries. Not everybody is able or allowed to
|
|
|
85 install another compiler or GUI library.
|
|
|
86 - People switch from one platform to another, and from GUI to terminal
|
|
|
87 version. Features should be present in all versions, or at least in as many
|
|
|
88 as possible with a reasonable effort. Try to avoid that users must switch
|
|
|
89 between platforms to accomplish their work efficiently.
|
|
|
90 - That a feature is not possible on some platforms, or only possible on one
|
|
|
91 platform, does not mean it cannot be implemented. [This intentionally
|
|
|
92 contradicts the previous item, these two must be balanced.]
|
|
|
93
|
|
|
94
|
|
|
95 VIM IS... WELL DOCUMENTED *design-documented*
|
|
|
96
|
|
|
97 - A feature that isn't documented is a useless feature. A patch for a new
|
|
|
98 feature must include the documentation.
|
|
|
99 - Documentation should be comprehensive and understandable. Using examples is
|
|
|
100 recommended.
|
|
|
101 - Don't make the text unnecessarily long. Less documentation means that an
|
|
|
102 item is easier to find.
|
|
|
103
|
|
|
104
|
|
|
105 VIM IS... HIGH SPEED AND SMALL IN SIZE *design-speed-size*
|
|
|
106
|
|
|
107 Using Vim must not be a big attack on system resources. Keep it small and
|
|
|
108 fast.
|
|
|
109 - Computers are becoming faster and bigger each year. Vim can grow too, but
|
|
|
110 no faster than computers are growing. Keep Vim usable on older systems.
|
|
|
111 - Many users start Vim from a shell very often. Startup time must be short.
|
|
|
112 - Commands must work efficiently. The time they consume must be as small as
|
|
|
113 possible. Useful commands may take longer.
|
|
|
114 - Don't forget that some people use Vim over a slow connection. Minimize the
|
|
|
115 communication overhead.
|
|
|
116 - Items that add considerably to the size and are not used by many people
|
|
|
117 should be a feature that can be disabled.
|
|
|
118 - Vim is a component among other components. Don't turn it into a massive
|
|
|
119 application, but have it work well together with other programs.
|
|
|
120
|
|
|
121
|
|
|
122 VIM IS... MAINTAINABLE *design-maintain*
|
|
|
123
|
|
|
124 - The source code should not become a mess. It should be reliable code.
|
|
|
125 - Use the same layout in all files to make it easy to read |coding-style|.
|
|
|
126 - Use comments in a useful way!
|
|
|
127 - Porting to another platform should be made easy, without having to change
|
|
|
128 too much platform-independent code.
|
|
|
129 - Use the object-oriented spirit: Put data and code together. Minimize the
|
|
|
130 knowledge spread to other parts of the code.
|
|
|
131
|
|
|
132
|
|
|
133 VIM IS... FLEXIBLE *design-flexible*
|
|
|
134
|
|
|
135 Vim should make it easy for users to work in their preferred styles rather
|
|
|
136 than coercing its users into particular patterns of work. This can be for
|
|
|
137 items with a large impact (e.g., the 'compatible' option) or for details. The
|
|
|
138 defaults are carefully chosen such that most users will enjoy using Vim as it
|
|
|
139 is. Commands and options can be used to adjust Vim to the desire of the user
|
|
|
140 and its environment.
|
|
|
141
|
|
|
142
|
|
|
143 VIM IS... NOT *design-not*
|
|
|
144
|
|
|
145 - Vim is not a shell or an Operating System. You will not be able to run a
|
|
|
146 shell inside Vim or use it to control a debugger. This should work the
|
|
|
147 other way around: Use Vim as a component from a shell or in an IDE.
|
|
|
148 A satirical way to say this: "Unlike Emacs, Vim does not attempt to include
|
|
|
149 everything but the kitchen sink, but some people say that you can clean one
|
|
|
150 with it. ;-)"
|
|
|
151 - Vim is not a fancy GUI editor that tries to look nice at the cost of
|
|
|
152 being less consistent over all platforms. But functional GUI features are
|
|
|
153 welcomed.
|
|
|
154
|
|
|
155 ==============================================================================
|
|
|
156 2. Coding style *coding-style*
|
|
|
157
|
|
|
158 These are the rules to use when making changes to the Vim source code. Please
|
|
|
159 stick to these rules, to keep the sources readable and maintainable.
|
|
|
160
|
|
|
161 This list is not complete. Look in the source code for more examples.
|
|
|
162
|
|
|
163
|
|
|
164 MAKING CHANGES *style-changes*
|
|
|
165
|
|
|
166 The basic steps to make changes to the code:
|
|
|
167 1. Adjust the documentation. Doing this first gives you an impression of how
|
|
|
168 your changes affect the user.
|
|
|
169 2. Make the source code changes.
|
|
|
170 3. Check ../doc/todo.txt if the change affects any listed item.
|
|
|
171 4. Make a patch with "diff -c" against the unmodified code and docs.
|
|
|
172 5. Make a note about what changed and include it with the patch.
|
|
|
173
|
|
|
174
|
|
|
175 USE OF COMMON FUNCTIONS *style-functions*
|
|
|
176
|
|
|
177 Some functions that are common to use, have a special Vim version. Always
|
|
|
178 consider using the Vim version, because they were introduced with a reason.
|
|
|
179
|
|
|
180 NORMAL NAME VIM NAME DIFFERENCE OF VIM VERSION
|
|
|
181 free() vim_free() Checks for freeing NULL
|
|
|
182 malloc() alloc() Checks for out of memory situation
|
|
|
183 malloc() lalloc() Like alloc(), but has long argument
|
|
|
184 strcpy() STRCPY() Includes cast to (char *), for char_u * args
|
|
|
185 strchr() vim_strchr() Accepts special characters
|
|
|
186 strrchr() vim_strrchr() Accepts special characters
|
|
|
187 isspace() vim_isspace() Can handle characters > 128
|
|
|
188 iswhite() vim_iswhite() Only TRUE for Tab and space
|
|
|
189 memcpy() vim_memmove() Handles overlapped copies
|
|
|
190 bcopy() vim_memmove() Handles overlapped copies
|
|
|
191 memset() vim_memset() Uniform for all systems
|
|
|
192
|
|
|
193
|
|
|
194 NAMES *style-names*
|
|
|
195
|
|
|
196 Function names can not be more than 31 characters long (because of VMS).
|
|
|
197
|
|
|
198 Don't use "delete" as a variable name, C++ doesn't like it.
|
|
|
199
|
|
|
200 Because of the requirement that Vim runs on as many systems as possible, we
|
|
|
201 need to avoid using names that are already defined by the system. This is a
|
|
|
202 list of names that are known to cause trouble. The name is given as a regexp
|
|
|
203 pattern.
|
|
|
204
|
|
|
205 is.*() POSIX, ctype.h
|
|
|
206 to.*() POSIX, ctype.h
|
|
|
207
|
|
|
208 d_.* POSIX, dirent.h
|
|
|
209 l_.* POSIX, fcntl.h
|
|
|
210 gr_.* POSIX, grp.h
|
|
|
211 pw_.* POSIX, pwd.h
|
|
|
212 sa_.* POSIX, signal.h
|
|
|
213 mem.* POSIX, string.h
|
|
|
214 str.* POSIX, string.h
|
|
|
215 wcs.* POSIX, string.h
|
|
|
216 st_.* POSIX, stat.h
|
|
|
217 tms_.* POSIX, times.h
|
|
|
218 tm_.* POSIX, time.h
|
|
|
219 c_.* POSIX, termios.h
|
|
|
220 MAX.* POSIX, limits.h
|
|
|
221 __.* POSIX, system
|
|
|
222 _[A-Z].* POSIX, system
|
|
|
223 E[A-Z0-9]* POSIX, errno.h
|
|
|
224
|
|
|
225 *_t POSIX, for typedefs. Use *_T instead.
|
|
|
226
|
|
|
227 wait don't use as argument to a function, conflicts with types.h
|
|
|
228 index shadows global declaration
|
|
|
229 time shadows global declaration
|
|
|
230 new C++ reserved keyword
|
|
|
231 try Borland C++ doesn't like it to be used as a variable.
|
|
|
232
|
|
|
233 basename() GNU string function
|
|
|
234 dirname() GNU string function
|
|
|
235 get_env_value() Linux system function
|
|
|
236
|
|
|
237
|
|
|
238 VARIOUS *style-various*
|
|
|
239
|
|
|
240 Typedef'ed names should end in "_t": >
|
|
|
241 typedef int some_t;
|
|
|
242 Define'ed names should be uppercase: >
|
|
|
243 #define SOME_THING
|
|
|
244 Features always start with "FEAT_": >
|
|
|
245 #define FEAT_FOO
|
|
|
246
|
|
|
247 Don't use '\"', some compilers can't handle it. '"' works fine.
|
|
|
248
|
|
|
249 Don't use:
|
|
|
250 #if HAVE_SOME
|
|
|
251 Some compilers can't handle that and complain that "HAVE_SOME" is not defined.
|
|
|
252 Use
|
|
|
253 #ifdef HAVE_SOME
|
|
|
254 or
|
|
|
255 #if defined(HAVE_SOME)
|
|
|
256
|
|
|
257
|
|
|
258 STYLE *style-examples*
|
|
|
259
|
|
|
260 General rule: One statement per line.
|
|
|
261
|
|
|
262 Wrong: if (cond) a = 1;
|
|
|
263
|
|
|
264 OK: if (cond)
|
|
|
265 a = 1;
|
|
|
266
|
|
|
267 Wrong: while (cond);
|
|
|
268
|
|
|
269 OK: while (cond)
|
|
|
270 ;
|
|
|
271
|
|
|
272 Wrong: do a = 1; while (cond);
|
|
|
273
|
|
|
274 OK: do
|
|
|
275 a = 1;
|
|
|
276 while (cond);
|
|
|
277
|
|
|
278
|
|
|
279 Functions start with:
|
|
|
280
|
|
|
281 Wrong: int function_name(int arg1, int arg2)
|
|
|
282
|
|
|
283 OK: /*
|
|
|
284 * Explanation of what this function is used for.
|
|
|
285 *
|
|
|
286 * Return value explanation.
|
|
|
287 */
|
|
|
288 int
|
|
|
289 function_name(arg1, arg2)
|
|
|
290 int arg1; /* short comment about arg1 */
|
|
|
291 int arg2; /* short comment about arg2 */
|
|
|
292 {
|
|
|
293 int local; /* comment about local */
|
|
|
294
|
|
|
295 local = arg1 * arg2;
|
|
|
296
|
|
|
297 NOTE: Don't use ANSI style function declarations. A few people still have to
|
|
|
298 use a compiler that doesn't support it.
|
|
|
299
|
|
|
300
|
|
|
301 SPACES AND PUNCTUATION *style-spaces*
|
|
|
302
|
|
|
303 No space between a function name and the bracket:
|
|
|
304
|
|
|
305 Wrong: func (arg);
|
|
|
306 OK: func(arg);
|
|
|
307
|
|
|
308 Do use a space after if, while, switch, etc.
|
|
|
309
|
|
|
310 Wrong: if(arg) for(;;)
|
|
|
311 OK: if (arg) for (;;)
|
|
|
312
|
|
|
313 Use a space after a comma and semicolon:
|
|
|
314
|
|
|
315 Wrong: func(arg1,arg2); for (i = 0;i < 2;++i)
|
|
|
316 OK: func(arg1, arg2); for (i = 0; i < 2; ++i)
|
|
|
317
|
|
|
318 Use a space before and after '=', '+', '/', etc.
|
|
|
319
|
|
|
320 Wrong: var=a*5;
|
|
|
321 OK: var = a * 5;
|
|
|
322
|
|
|
323 In general: Use empty lines to group lines of code together. Put a comment
|
|
|
324 just above the group of lines. This makes it more easy to quickly see what is
|
|
|
325 being done.
|
|
|
326
|
|
|
327 OK: /* Prepare for building the table. */
|
|
|
328 get_first_item();
|
|
|
329 table_idx = 0;
|
|
|
330
|
|
|
331 /* Build the table */
|
|
|
332 while (has_item())
|
|
|
333 table[table_idx++] = next_item();
|
|
|
334
|
|
|
335 /* Finish up. */
|
|
|
336 cleanup_items();
|
|
|
337 generate_hash(table);
|
|
|
338
|
|
|
339 ==============================================================================
|
|
|
340 3. Design decisions *design-decisions*
|
|
|
341
|
|
|
342 Folding
|
|
|
343
|
|
|
344 Several forms of folding should be possible for the same buffer. For example,
|
|
|
345 have one window that shows the text with function bodies folded, another
|
|
|
346 window that shows a function body.
|
|
|
347
|
|
|
348 Folding is a way to display the text. It should not change the text itself.
|
|
|
349 Therefore the folding has been implemented as a filter between the text stored
|
|
|
350 in a buffer (buffer lines) and the text displayed in a window (logical lines).
|
|
|
351
|
|
|
352
|
|
|
353 Naming the window
|
|
|
354
|
|
|
355 The word "window" is commonly used for several things: A window on the screen,
|
|
|
356 the xterm window, a window inside Vim to view a buffer.
|
|
|
357 To avoid confusion, other items that are sometimes called window have been
|
|
|
358 given another name. Here is an overview of the related items:
|
|
|
359
|
|
|
360 screen The whole display. For the GUI it's something like 1024x768
|
|
|
361 pixels. The Vim shell can use the whole screen or part of it.
|
|
|
362 shell The Vim application. This can cover the whole screen (e.g.,
|
|
|
363 when running in a console) or part of it (xterm or GUI).
|
|
|
364 window View on a buffer. There can be several windows in Vim,
|
|
|
365 together with the command line, menubar, toolbar, etc. they
|
|
|
366 fit in the shell.
|
|
|
367
|
|
|
368
|
|
|
369 To be continued...
|
|
|
370
|
|
|
371 ==============================================================================
|
|
|
372 4. Assumptions *design-assumptions*
|
|
|
373
|
|
|
374 Size of variables:
|
|
|
375 char 8 bit signed
|
|
|
376 char_u 8 bit unsigned
|
|
|
377 int 16, 32 or 64 bit signed
|
|
|
378 unsigned 16, 32 or 64 bit unsigned
|
|
|
379 long 32 or 64 bit signed, can hold a pointer
|
|
|
380
|
|
|
381 Note that some compilers cannot handle long lines or strings. The C89
|
|
|
382 standard specifies a limit of 509 characters.
|
|
|
383
|
|
|
384 vim:tw=78:ts=8:ft=help:norl:
|
