|
625
|
1 *develop.txt* For Vim version 7.0aa. Last change: 2006 Jan 12
|
|
7
|
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|.
|
|
481
|
126 - Use comments in a useful way! Quoting the function name and argument names
|
|
|
127 is NOT useful. Do explain what they are for.
|
|
7
|
128 - Porting to another platform should be made easy, without having to change
|
|
|
129 too much platform-independent code.
|
|
|
130 - Use the object-oriented spirit: Put data and code together. Minimize the
|
|
|
131 knowledge spread to other parts of the code.
|
|
|
132
|
|
|
133
|
|
|
134 VIM IS... FLEXIBLE *design-flexible*
|
|
|
135
|
|
|
136 Vim should make it easy for users to work in their preferred styles rather
|
|
|
137 than coercing its users into particular patterns of work. This can be for
|
|
|
138 items with a large impact (e.g., the 'compatible' option) or for details. The
|
|
|
139 defaults are carefully chosen such that most users will enjoy using Vim as it
|
|
|
140 is. Commands and options can be used to adjust Vim to the desire of the user
|
|
|
141 and its environment.
|
|
|
142
|
|
|
143
|
|
|
144 VIM IS... NOT *design-not*
|
|
|
145
|
|
|
146 - Vim is not a shell or an Operating System. You will not be able to run a
|
|
|
147 shell inside Vim or use it to control a debugger. This should work the
|
|
|
148 other way around: Use Vim as a component from a shell or in an IDE.
|
|
|
149 A satirical way to say this: "Unlike Emacs, Vim does not attempt to include
|
|
|
150 everything but the kitchen sink, but some people say that you can clean one
|
|
|
151 with it. ;-)"
|
|
|
152 - Vim is not a fancy GUI editor that tries to look nice at the cost of
|
|
|
153 being less consistent over all platforms. But functional GUI features are
|
|
|
154 welcomed.
|
|
|
155
|
|
|
156 ==============================================================================
|
|
|
157 2. Coding style *coding-style*
|
|
|
158
|
|
|
159 These are the rules to use when making changes to the Vim source code. Please
|
|
|
160 stick to these rules, to keep the sources readable and maintainable.
|
|
|
161
|
|
|
162 This list is not complete. Look in the source code for more examples.
|
|
|
163
|
|
|
164
|
|
|
165 MAKING CHANGES *style-changes*
|
|
|
166
|
|
|
167 The basic steps to make changes to the code:
|
|
|
168 1. Adjust the documentation. Doing this first gives you an impression of how
|
|
|
169 your changes affect the user.
|
|
|
170 2. Make the source code changes.
|
|
|
171 3. Check ../doc/todo.txt if the change affects any listed item.
|
|
|
172 4. Make a patch with "diff -c" against the unmodified code and docs.
|
|
|
173 5. Make a note about what changed and include it with the patch.
|
|
|
174
|
|
|
175
|
|
|
176 USE OF COMMON FUNCTIONS *style-functions*
|
|
|
177
|
|
|
178 Some functions that are common to use, have a special Vim version. Always
|
|
|
179 consider using the Vim version, because they were introduced with a reason.
|
|
|
180
|
|
|
181 NORMAL NAME VIM NAME DIFFERENCE OF VIM VERSION
|
|
|
182 free() vim_free() Checks for freeing NULL
|
|
|
183 malloc() alloc() Checks for out of memory situation
|
|
|
184 malloc() lalloc() Like alloc(), but has long argument
|
|
|
185 strcpy() STRCPY() Includes cast to (char *), for char_u * args
|
|
|
186 strchr() vim_strchr() Accepts special characters
|
|
|
187 strrchr() vim_strrchr() Accepts special characters
|
|
|
188 isspace() vim_isspace() Can handle characters > 128
|
|
|
189 iswhite() vim_iswhite() Only TRUE for Tab and space
|
|
|
190 memcpy() vim_memmove() Handles overlapped copies
|
|
|
191 bcopy() vim_memmove() Handles overlapped copies
|
|
|
192 memset() vim_memset() Uniform for all systems
|
|
|
193
|
|
|
194
|
|
|
195 NAMES *style-names*
|
|
|
196
|
|
|
197 Function names can not be more than 31 characters long (because of VMS).
|
|
|
198
|
|
|
199 Don't use "delete" as a variable name, C++ doesn't like it.
|
|
|
200
|
|
|
201 Because of the requirement that Vim runs on as many systems as possible, we
|
|
|
202 need to avoid using names that are already defined by the system. This is a
|
|
|
203 list of names that are known to cause trouble. The name is given as a regexp
|
|
|
204 pattern.
|
|
|
205
|
|
|
206 is.*() POSIX, ctype.h
|
|
|
207 to.*() POSIX, ctype.h
|
|
|
208
|
|
|
209 d_.* POSIX, dirent.h
|
|
|
210 l_.* POSIX, fcntl.h
|
|
|
211 gr_.* POSIX, grp.h
|
|
|
212 pw_.* POSIX, pwd.h
|
|
|
213 sa_.* POSIX, signal.h
|
|
|
214 mem.* POSIX, string.h
|
|
|
215 str.* POSIX, string.h
|
|
|
216 wcs.* POSIX, string.h
|
|
|
217 st_.* POSIX, stat.h
|
|
|
218 tms_.* POSIX, times.h
|
|
|
219 tm_.* POSIX, time.h
|
|
|
220 c_.* POSIX, termios.h
|
|
|
221 MAX.* POSIX, limits.h
|
|
|
222 __.* POSIX, system
|
|
|
223 _[A-Z].* POSIX, system
|
|
|
224 E[A-Z0-9]* POSIX, errno.h
|
|
|
225
|
|
|
226 *_t POSIX, for typedefs. Use *_T instead.
|
|
|
227
|
|
|
228 wait don't use as argument to a function, conflicts with types.h
|
|
|
229 index shadows global declaration
|
|
|
230 time shadows global declaration
|
|
|
231 new C++ reserved keyword
|
|
|
232 try Borland C++ doesn't like it to be used as a variable.
|
|
|
233
|
|
|
234 basename() GNU string function
|
|
|
235 dirname() GNU string function
|
|
|
236 get_env_value() Linux system function
|
|
|
237
|
|
|
238
|
|
|
239 VARIOUS *style-various*
|
|
|
240
|
|
502
|
241 Typedef'ed names should end in "_T": >
|
|
|
242 typedef int some_T;
|
|
7
|
243 Define'ed names should be uppercase: >
|
|
|
244 #define SOME_THING
|
|
|
245 Features always start with "FEAT_": >
|
|
|
246 #define FEAT_FOO
|
|
|
247
|
|
|
248 Don't use '\"', some compilers can't handle it. '"' works fine.
|
|
|
249
|
|
|
250 Don't use:
|
|
|
251 #if HAVE_SOME
|
|
|
252 Some compilers can't handle that and complain that "HAVE_SOME" is not defined.
|
|
|
253 Use
|
|
|
254 #ifdef HAVE_SOME
|
|
|
255 or
|
|
|
256 #if defined(HAVE_SOME)
|
|
|
257
|
|
|
258
|
|
|
259 STYLE *style-examples*
|
|
|
260
|
|
|
261 General rule: One statement per line.
|
|
|
262
|
|
|
263 Wrong: if (cond) a = 1;
|
|
|
264
|
|
|
265 OK: if (cond)
|
|
|
266 a = 1;
|
|
|
267
|
|
|
268 Wrong: while (cond);
|
|
|
269
|
|
|
270 OK: while (cond)
|
|
|
271 ;
|
|
|
272
|
|
|
273 Wrong: do a = 1; while (cond);
|
|
|
274
|
|
|
275 OK: do
|
|
|
276 a = 1;
|
|
|
277 while (cond);
|
|
|
278
|
|
|
279
|
|
|
280 Functions start with:
|
|
|
281
|
|
|
282 Wrong: int function_name(int arg1, int arg2)
|
|
|
283
|
|
|
284 OK: /*
|
|
|
285 * Explanation of what this function is used for.
|
|
|
286 *
|
|
|
287 * Return value explanation.
|
|
|
288 */
|
|
|
289 int
|
|
|
290 function_name(arg1, arg2)
|
|
|
291 int arg1; /* short comment about arg1 */
|
|
|
292 int arg2; /* short comment about arg2 */
|
|
|
293 {
|
|
|
294 int local; /* comment about local */
|
|
|
295
|
|
|
296 local = arg1 * arg2;
|
|
|
297
|
|
|
298 NOTE: Don't use ANSI style function declarations. A few people still have to
|
|
|
299 use a compiler that doesn't support it.
|
|
|
300
|
|
|
301
|
|
|
302 SPACES AND PUNCTUATION *style-spaces*
|
|
|
303
|
|
|
304 No space between a function name and the bracket:
|
|
|
305
|
|
|
306 Wrong: func (arg);
|
|
|
307 OK: func(arg);
|
|
|
308
|
|
|
309 Do use a space after if, while, switch, etc.
|
|
|
310
|
|
|
311 Wrong: if(arg) for(;;)
|
|
|
312 OK: if (arg) for (;;)
|
|
|
313
|
|
|
314 Use a space after a comma and semicolon:
|
|
|
315
|
|
|
316 Wrong: func(arg1,arg2); for (i = 0;i < 2;++i)
|
|
|
317 OK: func(arg1, arg2); for (i = 0; i < 2; ++i)
|
|
|
318
|
|
|
319 Use a space before and after '=', '+', '/', etc.
|
|
|
320
|
|
|
321 Wrong: var=a*5;
|
|
|
322 OK: var = a * 5;
|
|
|
323
|
|
|
324 In general: Use empty lines to group lines of code together. Put a comment
|
|
|
325 just above the group of lines. This makes it more easy to quickly see what is
|
|
|
326 being done.
|
|
|
327
|
|
|
328 OK: /* Prepare for building the table. */
|
|
|
329 get_first_item();
|
|
|
330 table_idx = 0;
|
|
|
331
|
|
|
332 /* Build the table */
|
|
|
333 while (has_item())
|
|
|
334 table[table_idx++] = next_item();
|
|
|
335
|
|
|
336 /* Finish up. */
|
|
|
337 cleanup_items();
|
|
|
338 generate_hash(table);
|
|
|
339
|
|
|
340 ==============================================================================
|
|
|
341 3. Design decisions *design-decisions*
|
|
|
342
|
|
|
343 Folding
|
|
|
344
|
|
|
345 Several forms of folding should be possible for the same buffer. For example,
|
|
|
346 have one window that shows the text with function bodies folded, another
|
|
|
347 window that shows a function body.
|
|
|
348
|
|
|
349 Folding is a way to display the text. It should not change the text itself.
|
|
|
350 Therefore the folding has been implemented as a filter between the text stored
|
|
|
351 in a buffer (buffer lines) and the text displayed in a window (logical lines).
|
|
|
352
|
|
|
353
|
|
|
354 Naming the window
|
|
|
355
|
|
|
356 The word "window" is commonly used for several things: A window on the screen,
|
|
|
357 the xterm window, a window inside Vim to view a buffer.
|
|
|
358 To avoid confusion, other items that are sometimes called window have been
|
|
|
359 given another name. Here is an overview of the related items:
|
|
|
360
|
|
|
361 screen The whole display. For the GUI it's something like 1024x768
|
|
|
362 pixels. The Vim shell can use the whole screen or part of it.
|
|
|
363 shell The Vim application. This can cover the whole screen (e.g.,
|
|
|
364 when running in a console) or part of it (xterm or GUI).
|
|
|
365 window View on a buffer. There can be several windows in Vim,
|
|
|
366 together with the command line, menubar, toolbar, etc. they
|
|
|
367 fit in the shell.
|
|
|
368
|
|
|
369
|
|
236
|
370 Spell checking *develop-spell*
|
|
|
371
|
|
|
372 When spell checking was going to be added to Vim a survey was done over the
|
|
|
373 available spell checking libraries and programs. Unfortunately, the result
|
|
|
374 was that none of them provided sufficient capabilities to be used as the spell
|
|
|
375 checking engine in Vim, for various reasons:
|
|
|
376
|
|
|
377 - Missing support for multi-byte encodings. At least UTF-8 must be supported,
|
|
|
378 so that more than one language can be used in the same file.
|
|
323
|
379 Doing on-the-fly conversion is not always possible (would require iconv
|
|
|
380 support).
|
|
236
|
381 - For the programs and libraries: Using them as-is would require installing
|
|
323
|
382 them separately from Vim. That's mostly not impossible, but a drawback.
|
|
236
|
383 - Performance: A few tests showed that it's possible to check spelling on the
|
|
|
384 fly (while redrawing), just like syntax highlighting. But the mechanisms
|
|
625
|
385 used by other code are much slower. Myspell uses a hashtable, for example.
|
|
|
386 The affix compression that most spell checkers use makes it slower too.
|
|
300
|
387 - For using an external program like aspell a communication mechanism would
|
|
|
388 have to be setup. That's complicated to do in a portable way (Unix-only
|
|
|
389 would be relatively simple, but that's not good enough). And performance
|
|
|
390 will become a problem (lots of process switching involved).
|
|
236
|
391 - Missing support for words with non-word characters, such as "Etten-Leur" and
|
|
|
392 "et al.", would require marking the pieces of them OK, lowering the
|
|
|
393 reliability.
|
|
|
394 - Missing support for regions or dialects. Makes it difficult to accept
|
|
|
395 all English words and highlight non-Canadian words differently.
|
|
|
396 - Missing support for rare words. Many words are correct but hardly ever used
|
|
|
397 and could be a misspelled often-used word.
|
|
323
|
398 - For making suggestions the speed is less important and requiring to install
|
|
|
399 another program or library would be acceptable. But the word lists probably
|
|
|
400 differ, the suggestions may be wrong words.
|
|
7
|
401
|
|
625
|
402
|
|
|
403 Spelling suggestions *develop-spell-suggestions*
|
|
|
404
|
|
|
405 For making suggestions there are two basic mechanisms:
|
|
|
406 1. Try changing the bad word a little bit and check for a match with a good
|
|
|
407 word. Or go through the list of good words, change them a little bit and
|
|
|
408 check for a match with the bad word. The changes are deleting a character,
|
|
|
409 inserting a character, swapping two characters, etc.
|
|
|
410 2. Perform soundfolding on both the bad word and the good words and then find
|
|
|
411 matches, possibly with a few changes like with the first mechanism.
|
|
|
412
|
|
|
413 The first is good for finding typing mistakes. After experimenting with
|
|
|
414 hashtables and looking at solutions from other spell checkers the conclusion
|
|
|
415 was that a trie (a kind of tree structure) is ideal for this. Both for
|
|
|
416 reducing memory use and being able to try sensible changes. For example, when
|
|
|
417 inserting a character only characters that lead to good words need to be
|
|
|
418 tried. Other mechanisms (with hashtables) need to try all possible letters at
|
|
|
419 every position in the word. Also, a hashtable has the requirement that word
|
|
|
420 boundaries are identified separately, while a trie does not require this.
|
|
|
421 That makes the mechanism a lot simpler.
|
|
|
422
|
|
|
423 Soundfolding is useful when someone knows how the words sounds but doesn't
|
|
|
424 know how it is spelled. For example, the word "dictionary" might be written
|
|
|
425 as "daktonerie". The number of changes that the first method would need to
|
|
|
426 try is very big, it's hard to find the good word that way. After soundfolding
|
|
|
427 the words become "tktnr" and "tkxnry", these differ by only two letters.
|
|
|
428
|
|
|
429 To find words by their soundfolded equivalent (soundalike word) we need a list
|
|
|
430 of all soundfolded words. A few experiments have been done to find out what
|
|
|
431 the best method is. Alternatives:
|
|
|
432 1. Do the sound folding on the fly when looking for suggestions. This means
|
|
|
433 walking through the trie of good words, soundfolding each word and
|
|
|
434 checking how different it is from the bad word. This is very efficient for
|
|
|
435 memory use, but takes a long time. On a fast PC it takes a couple of
|
|
|
436 seconds for English, which can be acceptable for interactive use. But for
|
|
|
437 some languages it takes more than ten seconds (e.g., German, Catalan),
|
|
|
438 which is unacceptable slow. For batch processing (automatic corrections)
|
|
|
439 it's to slow for all languages.
|
|
|
440 2. Use a trie for the soundfolded words, so that searching can be done just
|
|
|
441 like how it works without soundfolding. This requires remembering a list
|
|
|
442 of good words for each soundfolded word. This makes finding matches very
|
|
|
443 fast but requires quite a lot of memory, in the order of 1 to 10 Mbyte.
|
|
|
444 For some languages more than the original word list.
|
|
|
445 3. Like the second alternative, but reduce the amount of memory by using affix
|
|
|
446 compression and store only the soundfolded basic word. This is what Aspell
|
|
|
447 does. Disadvantage is that affixes need to be stripped from the bad word
|
|
|
448 before soundfolding it, which means that mistakes at the start and/or end
|
|
|
449 of the word will cause the mechanism to fail. Also, this becomes slow when
|
|
|
450 the bad word is quite different from the good word.
|
|
|
451
|
|
|
452 The choice made is to use the second mechanism and use a separate file. This
|
|
|
453 way a user with sufficient memory can get very good suggestions while a user
|
|
|
454 who is short of memory or just wants the spell checking and no suggestions
|
|
|
455 doesn't use so much memory.
|
|
|
456
|
|
|
457
|
|
|
458 Word frequency
|
|
|
459
|
|
|
460 For sorting suggestions it helps to know which words are common. In theory we
|
|
|
461 could store a word frequency with the word in the dictionary. However, this
|
|
|
462 requires storing a count per word. That degrades word tree compression a lot.
|
|
|
463 And maintaining the word frequency for all languages will be a heavy task.
|
|
|
464 Also, it would be nice to prefer words that are already in the text. This way
|
|
|
465 the words that appear in the specific text are preferred for suggestions.
|
|
|
466
|
|
|
467 What has been implemented is to count words that have been seen during
|
|
|
468 displaying. A hashtable is used to quickly find the word count. The count is
|
|
|
469 initialized from words listed in COMMON items in the affix file, so that it
|
|
|
470 also works when starting a new file.
|
|
|
471
|
|
|
472 This isn't ideal, because the longer Vim is running the higher the counts
|
|
|
473 become. But in practice it is a noticable improvement over not using the word
|
|
|
474 count.
|
|
|
475
|
|
7
|
476 ==============================================================================
|
|
|
477 4. Assumptions *design-assumptions*
|
|
|
478
|
|
|
479 Size of variables:
|
|
|
480 char 8 bit signed
|
|
|
481 char_u 8 bit unsigned
|
|
625
|
482 int 32 or 64 bit signed (16 might be possible with limited features)
|
|
|
483 unsigned 32 or 64 bit unsigned (16 as with ints)
|
|
7
|
484 long 32 or 64 bit signed, can hold a pointer
|
|
|
485
|
|
|
486 Note that some compilers cannot handle long lines or strings. The C89
|
|
|
487 standard specifies a limit of 509 characters.
|
|
|
488
|
|
|
489 vim:tw=78:ts=8:ft=help:norl:
|
