Mercurial > vim
annotate runtime/doc/develop.txt @ 14543:e716a0dc84f2
Added tag v8.1.0284 for changeset 116a01c73fd81f7054aeb99a7bc6798a3a368444
author | Christian Brabandt <cb@256bit.org> |
---|---|
date | Tue, 14 Aug 2018 18:30:06 +0200 |
parents | 2f7e67dd088c |
children | 314694a2e74a |
rev | line source |
---|---|
13963 | 1 *develop.txt* For Vim version 8.1. Last change: 2018 May 02 |
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 | |
13857 | 21 improving Vim. For sending patches a unified diff "diff -u" is preferred. |
22 You can create a pull request on github, but it's not required. | |
4358 | 23 Also see http://vim.wikia.com/wiki/How_to_make_and_submit_a_patch. |
7 | 24 |
25 ============================================================================== | |
26 1. Design goals *design-goals* | |
27 | |
28 Most important things come first (roughly). | |
29 | |
30 Note that quite a few items are contradicting. This is intentional. A | |
31 balance must be found between them. | |
32 | |
33 | |
34 VIM IS... VI COMPATIBLE *design-compatible* | |
35 | |
36 First of all, it should be possible to use Vim as a drop-in replacement for | |
37 Vi. When the user wants to, he can use Vim in compatible mode and hardly | |
38 notice any difference with the original Vi. | |
39 | |
40 Exceptions: | |
41 - We don't reproduce obvious Vi bugs in Vim. | |
42 - There are different versions of Vi. I am using Version 3.7 (6/7/85) as a | |
43 reference. But support for other versions is also included when possible. | |
44 The Vi part of POSIX is not considered a definitive source. | |
45 - Vim adds new commands, you cannot rely on some command to fail because it | |
46 didn't exist in Vi. | |
47 - Vim will have a lot of features that Vi doesn't have. Going back from Vim | |
48 to Vi will be a problem, this cannot be avoided. | |
49 - Some things are hardly ever used (open mode, sending an e-mail when | |
50 crashing, etc.). Those will only be included when someone has a good reason | |
51 why it should be included and it's not too much work. | |
52 - For some items it is debatable whether Vi compatibility should be | |
53 maintained. There will be an option flag for these. | |
54 | |
55 | |
56 VIM IS... IMPROVED *design-improved* | |
57 | |
58 The IMproved bits of Vim should make it a better Vi, without becoming a | |
59 completely different editor. Extensions are done with a "Vi spirit". | |
60 - Use the keyboard as much as feasible. The mouse requires a third hand, | |
61 which we don't have. Many terminals don't have a mouse. | |
62 - When the mouse is used anyway, avoid the need to switch back to the | |
63 keyboard. Avoid mixing mouse and keyboard handling. | |
64 - Add commands and options in a consistent way. Otherwise people will have a | |
65 hard time finding and remembering them. Keep in mind that more commands and | |
66 options will be added later. | |
67 - A feature that people do not know about is a useless feature. Don't add | |
2033
de5a43c5eedc
Update documentation files.
Bram Moolenaar <bram@zimbu.org>
parents:
1702
diff
changeset
|
68 obscure features, or at least add hints in documentation that they exist. |
7 | 69 - Minimize using CTRL and other modifiers, they are more difficult to type. |
70 - There are many first-time and inexperienced Vim users. Make it easy for | |
71 them to start using Vim and learn more over time. | |
72 - There is no limit to the features that can be added. Selecting new features | |
73 is one based on (1) what users ask for, (2) how much effort it takes to | |
74 implement and (3) someone actually implementing it. | |
75 | |
76 | |
77 VIM IS... MULTI PLATFORM *design-multi-platform* | |
78 | |
79 Vim tries to help as many users on as many platforms as possible. | |
80 - Support many kinds of terminals. The minimal demands are cursor positioning | |
81 and clear-screen. Commands should only use key strokes that most keyboards | |
82 have. Support all the keys on the keyboard for mapping. | |
83 - Support many platforms. A condition is that there is someone willing to do | |
84 Vim development on that platform, and it doesn't mean messing up the code. | |
85 - Support many compilers and libraries. Not everybody is able or allowed to | |
86 install another compiler or GUI library. | |
87 - People switch from one platform to another, and from GUI to terminal | |
88 version. Features should be present in all versions, or at least in as many | |
89 as possible with a reasonable effort. Try to avoid that users must switch | |
90 between platforms to accomplish their work efficiently. | |
91 - That a feature is not possible on some platforms, or only possible on one | |
92 platform, does not mean it cannot be implemented. [This intentionally | |
93 contradicts the previous item, these two must be balanced.] | |
94 | |
95 | |
96 VIM IS... WELL DOCUMENTED *design-documented* | |
97 | |
98 - A feature that isn't documented is a useless feature. A patch for a new | |
99 feature must include the documentation. | |
100 - Documentation should be comprehensive and understandable. Using examples is | |
101 recommended. | |
102 - Don't make the text unnecessarily long. Less documentation means that an | |
103 item is easier to find. | |
104 | |
105 | |
106 VIM IS... HIGH SPEED AND SMALL IN SIZE *design-speed-size* | |
107 | |
108 Using Vim must not be a big attack on system resources. Keep it small and | |
109 fast. | |
110 - Computers are becoming faster and bigger each year. Vim can grow too, but | |
111 no faster than computers are growing. Keep Vim usable on older systems. | |
112 - Many users start Vim from a shell very often. Startup time must be short. | |
113 - Commands must work efficiently. The time they consume must be as small as | |
114 possible. Useful commands may take longer. | |
115 - Don't forget that some people use Vim over a slow connection. Minimize the | |
116 communication overhead. | |
117 - Items that add considerably to the size and are not used by many people | |
118 should be a feature that can be disabled. | |
119 - Vim is a component among other components. Don't turn it into a massive | |
120 application, but have it work well together with other programs. | |
121 | |
122 | |
123 VIM IS... MAINTAINABLE *design-maintain* | |
124 | |
125 - The source code should not become a mess. It should be reliable code. | |
126 - Use the same layout in all files to make it easy to read |coding-style|. | |
481 | 127 - Use comments in a useful way! Quoting the function name and argument names |
128 is NOT useful. Do explain what they are for. | |
7 | 129 - Porting to another platform should be made easy, without having to change |
130 too much platform-independent code. | |
131 - Use the object-oriented spirit: Put data and code together. Minimize the | |
132 knowledge spread to other parts of the code. | |
133 | |
134 | |
135 VIM IS... FLEXIBLE *design-flexible* | |
136 | |
137 Vim should make it easy for users to work in their preferred styles rather | |
138 than coercing its users into particular patterns of work. This can be for | |
139 items with a large impact (e.g., the 'compatible' option) or for details. The | |
140 defaults are carefully chosen such that most users will enjoy using Vim as it | |
141 is. Commands and options can be used to adjust Vim to the desire of the user | |
142 and its environment. | |
143 | |
144 | |
145 VIM IS... NOT *design-not* | |
146 | |
11914 | 147 - Vim is not a shell or an Operating System. It does provide a terminal |
148 window, in which you can run a shell or debugger. E.g. to be able to do | |
149 this over an ssh connection. But if you don't need a text editor with that | |
150 it is out of scope (use something like screen or tmux instead). | |
7 | 151 A satirical way to say this: "Unlike Emacs, Vim does not attempt to include |
152 everything but the kitchen sink, but some people say that you can clean one | |
153 with it. ;-)" | |
722 | 154 To use Vim with gdb see: http://www.agide.org and http://clewn.sf.net. |
7 | 155 - Vim is not a fancy GUI editor that tries to look nice at the cost of |
156 being less consistent over all platforms. But functional GUI features are | |
157 welcomed. | |
158 | |
159 ============================================================================== | |
160 2. Coding style *coding-style* | |
161 | |
162 These are the rules to use when making changes to the Vim source code. Please | |
163 stick to these rules, to keep the sources readable and maintainable. | |
164 | |
165 This list is not complete. Look in the source code for more examples. | |
166 | |
167 | |
168 MAKING CHANGES *style-changes* | |
169 | |
170 The basic steps to make changes to the code: | |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
171 1. Get the code from github. That makes it easier to keep your changed |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
172 version in sync with the main code base (it may be a while before your |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
173 changes will be included). You do need to spend some time learning git, |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
174 it's not the most user friendly tool. |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
175 2. Adjust the documentation. Doing this first gives you an impression of how |
7 | 176 your changes affect the user. |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
177 3. Make the source code changes. |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
178 4. Check ../doc/todo.txt if the change affects any listed item. |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
179 5. Make a patch with "git diff". You can also create a pull request on |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
180 github, but it's the diff that matters. |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
181 6. Make a note about what changed, preferably mentioning the problem and the |
10548
74effdaa369e
Updated runtime files.
Christian Brabandt <cb@256bit.org>
parents:
10198
diff
changeset
|
182 solution. Send an email to the |vim-dev| maillist with an explanation and |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
183 include the diff. Or create a pull request on github. |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
184 |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
185 |
13818
28ac7914b2b6
Update runtime files and translations
Christian Brabandt <cb@256bit.org>
parents:
13735
diff
changeset
|
186 C COMPILER *style-compiler* *ANSI-C* *C89* *C99* |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
187 |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
188 The minimal C compiler version supported is C89, also known as ANSI C. |
13716
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
189 Later standards, such as C99, are not widely supported, or at least not 100% |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
190 supported. Therefore we use only some of the C99 features and disallow some |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
191 (at least for now). |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
192 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
193 Please don't make changes everywhere to use the C99 features, it causes merge |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
194 problems for existing patches. Only use them for new and changed code. |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
195 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
196 Comments ~ |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
197 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
198 Traditionally Vim uses /* comments */. We intend to keep it that way, |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
199 especially for file and function headers. For new code or lines of code that |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
200 change, it is allowed to use // comments. Especially when it comes after |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
201 code: |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
202 int some_var; // single line comment useful here |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
203 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
204 Enums ~ |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
205 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
206 The last item in an enum may have a trailing comma. C89 didn't allow this. |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
207 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
208 Types ~ |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
209 |
13716
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
210 "long long" is allowed and can be expected to be 64 bits. Use %lld in printf |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
211 formats. Also "long long unsigned" with %llu. |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
212 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
213 Not to be used ~ |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
214 |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
215 These C99 features are not to be used, because not enough compilers support |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
216 them: |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
217 - Declaration after Statements (MSVC 2012 does not support it). All |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
218 declarations need to be at the start of the block. |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
219 - Variable length arrays (even in C11 this is an optional feature). |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
220 - _Bool and _Complex types. |
30f9ebe3e602
patch 8.0.1730: no configure check for the used C99 features
Christian Brabandt <cb@256bit.org>
parents:
11914
diff
changeset
|
221 - "inline" (it's hardly ever needed, let the optimizer do its work) |
13726
d35b1702a1da
patch 8.0.1735: flexible array member feature not supported by HP-UX
Christian Brabandt <cb@256bit.org>
parents:
13716
diff
changeset
|
222 - flexible array members: Not supported by HP-UX C compiler (John Marriott) |
7 | 223 |
224 | |
225 USE OF COMMON FUNCTIONS *style-functions* | |
226 | |
227 Some functions that are common to use, have a special Vim version. Always | |
228 consider using the Vim version, because they were introduced with a reason. | |
229 | |
230 NORMAL NAME VIM NAME DIFFERENCE OF VIM VERSION | |
231 free() vim_free() Checks for freeing NULL | |
232 malloc() alloc() Checks for out of memory situation | |
233 malloc() lalloc() Like alloc(), but has long argument | |
234 strcpy() STRCPY() Includes cast to (char *), for char_u * args | |
235 strchr() vim_strchr() Accepts special characters | |
236 strrchr() vim_strrchr() Accepts special characters | |
237 isspace() vim_isspace() Can handle characters > 128 | |
1240 | 238 iswhite() vim_iswhite() Only TRUE for tab and space |
711 | 239 memcpy() mch_memmove() Handles overlapped copies |
240 bcopy() mch_memmove() Handles overlapped copies | |
7 | 241 memset() vim_memset() Uniform for all systems |
242 | |
243 | |
244 NAMES *style-names* | |
245 | |
246 Function names can not be more than 31 characters long (because of VMS). | |
247 | |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
248 Don't use "delete" or "this" as a variable name, C++ doesn't like it. |
7 | 249 |
250 Because of the requirement that Vim runs on as many systems as possible, we | |
251 need to avoid using names that are already defined by the system. This is a | |
252 list of names that are known to cause trouble. The name is given as a regexp | |
253 pattern. | |
254 | |
255 is.*() POSIX, ctype.h | |
256 to.*() POSIX, ctype.h | |
257 | |
258 d_.* POSIX, dirent.h | |
259 l_.* POSIX, fcntl.h | |
260 gr_.* POSIX, grp.h | |
261 pw_.* POSIX, pwd.h | |
262 sa_.* POSIX, signal.h | |
263 mem.* POSIX, string.h | |
264 str.* POSIX, string.h | |
265 wcs.* POSIX, string.h | |
266 st_.* POSIX, stat.h | |
267 tms_.* POSIX, times.h | |
268 tm_.* POSIX, time.h | |
269 c_.* POSIX, termios.h | |
270 MAX.* POSIX, limits.h | |
271 __.* POSIX, system | |
272 _[A-Z].* POSIX, system | |
273 E[A-Z0-9]* POSIX, errno.h | |
274 | |
1121 | 275 .*_t POSIX, for typedefs. Use .*_T instead. |
7 | 276 |
277 wait don't use as argument to a function, conflicts with types.h | |
278 index shadows global declaration | |
279 time shadows global declaration | |
280 new C++ reserved keyword | |
281 try Borland C++ doesn't like it to be used as a variable. | |
282 | |
3281 | 283 clear Mac curses.h |
284 echo Mac curses.h | |
285 instr Mac curses.h | |
286 meta Mac curses.h | |
287 newwin Mac curses.h | |
288 nl Mac curses.h | |
289 overwrite Mac curses.h | |
290 refresh Mac curses.h | |
291 scroll Mac curses.h | |
292 typeahead Mac curses.h | |
293 | |
7 | 294 basename() GNU string function |
295 dirname() GNU string function | |
296 get_env_value() Linux system function | |
297 | |
298 | |
299 VARIOUS *style-various* | |
300 | |
502 | 301 Typedef'ed names should end in "_T": > |
302 typedef int some_T; | |
7 | 303 Define'ed names should be uppercase: > |
304 #define SOME_THING | |
305 Features always start with "FEAT_": > | |
306 #define FEAT_FOO | |
307 | |
308 Don't use '\"', some compilers can't handle it. '"' works fine. | |
309 | |
310 Don't use: | |
311 #if HAVE_SOME | |
312 Some compilers can't handle that and complain that "HAVE_SOME" is not defined. | |
313 Use | |
314 #ifdef HAVE_SOME | |
315 or | |
316 #if defined(HAVE_SOME) | |
317 | |
318 | |
319 STYLE *style-examples* | |
320 | |
321 General rule: One statement per line. | |
322 | |
323 Wrong: if (cond) a = 1; | |
324 | |
325 OK: if (cond) | |
326 a = 1; | |
327 | |
328 Wrong: while (cond); | |
329 | |
330 OK: while (cond) | |
331 ; | |
332 | |
333 Wrong: do a = 1; while (cond); | |
334 | |
335 OK: do | |
336 a = 1; | |
337 while (cond); | |
338 | |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
339 Wrong: if (cond) { |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
340 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
341 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
342 } else { |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
343 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
344 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
345 } |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
346 |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
347 OK: if (cond) |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
348 { |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
349 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
350 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
351 } |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
352 else |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
353 { |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
354 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
355 cmd; |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
356 } |
7 | 357 |
7876
93f747af7b58
commit https://github.com/vim/vim/commit/5e9b2fa9bb0e6061cf18457c173cd141a5dc9c92
Christian Brabandt <cb@256bit.org>
parents:
7707
diff
changeset
|
358 Use ANSI (new style) function declarations with the return type on a separate |
93f747af7b58
commit https://github.com/vim/vim/commit/5e9b2fa9bb0e6061cf18457c173cd141a5dc9c92
Christian Brabandt <cb@256bit.org>
parents:
7707
diff
changeset
|
359 indented line. |
7 | 360 |
361 Wrong: int function_name(int arg1, int arg2) | |
362 | |
363 OK: /* | |
364 * Explanation of what this function is used for. | |
365 * | |
366 * Return value explanation. | |
367 */ | |
368 int | |
7707
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
369 function_name( |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
370 int arg1, /* short comment about arg1 */ |
41768bcebc9b
commit https://github.com/vim/vim/commit/13d5aeef56e3140a8eb8f40c7062aa1c5700f76e
Christian Brabandt <cb@256bit.org>
parents:
5763
diff
changeset
|
371 int arg2) /* short comment about arg2 */ |
7 | 372 { |
373 int local; /* comment about local */ | |
374 | |
375 local = arg1 * arg2; | |
376 | |
377 | |
378 | |
379 SPACES AND PUNCTUATION *style-spaces* | |
380 | |
381 No space between a function name and the bracket: | |
382 | |
383 Wrong: func (arg); | |
384 OK: func(arg); | |
385 | |
386 Do use a space after if, while, switch, etc. | |
387 | |
388 Wrong: if(arg) for(;;) | |
389 OK: if (arg) for (;;) | |
390 | |
391 Use a space after a comma and semicolon: | |
392 | |
393 Wrong: func(arg1,arg2); for (i = 0;i < 2;++i) | |
394 OK: func(arg1, arg2); for (i = 0; i < 2; ++i) | |
395 | |
396 Use a space before and after '=', '+', '/', etc. | |
397 | |
398 Wrong: var=a*5; | |
399 OK: var = a * 5; | |
400 | |
401 In general: Use empty lines to group lines of code together. Put a comment | |
2033
de5a43c5eedc
Update documentation files.
Bram Moolenaar <bram@zimbu.org>
parents:
1702
diff
changeset
|
402 just above the group of lines. This makes it easier to quickly see what is |
7 | 403 being done. |
404 | |
405 OK: /* Prepare for building the table. */ | |
406 get_first_item(); | |
407 table_idx = 0; | |
408 | |
409 /* Build the table */ | |
410 while (has_item()) | |
411 table[table_idx++] = next_item(); | |
412 | |
413 /* Finish up. */ | |
414 cleanup_items(); | |
415 generate_hash(table); | |
416 | |
417 ============================================================================== | |
418 3. Design decisions *design-decisions* | |
419 | |
420 Folding | |
421 | |
422 Several forms of folding should be possible for the same buffer. For example, | |
423 have one window that shows the text with function bodies folded, another | |
424 window that shows a function body. | |
425 | |
426 Folding is a way to display the text. It should not change the text itself. | |
427 Therefore the folding has been implemented as a filter between the text stored | |
428 in a buffer (buffer lines) and the text displayed in a window (logical lines). | |
429 | |
430 | |
431 Naming the window | |
432 | |
433 The word "window" is commonly used for several things: A window on the screen, | |
434 the xterm window, a window inside Vim to view a buffer. | |
435 To avoid confusion, other items that are sometimes called window have been | |
436 given another name. Here is an overview of the related items: | |
437 | |
438 screen The whole display. For the GUI it's something like 1024x768 | |
439 pixels. The Vim shell can use the whole screen or part of it. | |
440 shell The Vim application. This can cover the whole screen (e.g., | |
441 when running in a console) or part of it (xterm or GUI). | |
442 window View on a buffer. There can be several windows in Vim, | |
443 together with the command line, menubar, toolbar, etc. they | |
444 fit in the shell. | |
445 | |
446 | |
236 | 447 Spell checking *develop-spell* |
448 | |
449 When spell checking was going to be added to Vim a survey was done over the | |
450 available spell checking libraries and programs. Unfortunately, the result | |
451 was that none of them provided sufficient capabilities to be used as the spell | |
452 checking engine in Vim, for various reasons: | |
453 | |
454 - Missing support for multi-byte encodings. At least UTF-8 must be supported, | |
455 so that more than one language can be used in the same file. | |
323 | 456 Doing on-the-fly conversion is not always possible (would require iconv |
457 support). | |
236 | 458 - For the programs and libraries: Using them as-is would require installing |
323 | 459 them separately from Vim. That's mostly not impossible, but a drawback. |
236 | 460 - Performance: A few tests showed that it's possible to check spelling on the |
461 fly (while redrawing), just like syntax highlighting. But the mechanisms | |
625 | 462 used by other code are much slower. Myspell uses a hashtable, for example. |
463 The affix compression that most spell checkers use makes it slower too. | |
300 | 464 - For using an external program like aspell a communication mechanism would |
465 have to be setup. That's complicated to do in a portable way (Unix-only | |
466 would be relatively simple, but that's not good enough). And performance | |
467 will become a problem (lots of process switching involved). | |
236 | 468 - Missing support for words with non-word characters, such as "Etten-Leur" and |
469 "et al.", would require marking the pieces of them OK, lowering the | |
470 reliability. | |
471 - Missing support for regions or dialects. Makes it difficult to accept | |
472 all English words and highlight non-Canadian words differently. | |
473 - Missing support for rare words. Many words are correct but hardly ever used | |
474 and could be a misspelled often-used word. | |
323 | 475 - For making suggestions the speed is less important and requiring to install |
476 another program or library would be acceptable. But the word lists probably | |
477 differ, the suggestions may be wrong words. | |
7 | 478 |
625 | 479 |
480 Spelling suggestions *develop-spell-suggestions* | |
481 | |
482 For making suggestions there are two basic mechanisms: | |
483 1. Try changing the bad word a little bit and check for a match with a good | |
484 word. Or go through the list of good words, change them a little bit and | |
485 check for a match with the bad word. The changes are deleting a character, | |
486 inserting a character, swapping two characters, etc. | |
487 2. Perform soundfolding on both the bad word and the good words and then find | |
488 matches, possibly with a few changes like with the first mechanism. | |
489 | |
490 The first is good for finding typing mistakes. After experimenting with | |
491 hashtables and looking at solutions from other spell checkers the conclusion | |
492 was that a trie (a kind of tree structure) is ideal for this. Both for | |
493 reducing memory use and being able to try sensible changes. For example, when | |
494 inserting a character only characters that lead to good words need to be | |
495 tried. Other mechanisms (with hashtables) need to try all possible letters at | |
496 every position in the word. Also, a hashtable has the requirement that word | |
497 boundaries are identified separately, while a trie does not require this. | |
498 That makes the mechanism a lot simpler. | |
499 | |
500 Soundfolding is useful when someone knows how the words sounds but doesn't | |
501 know how it is spelled. For example, the word "dictionary" might be written | |
502 as "daktonerie". The number of changes that the first method would need to | |
503 try is very big, it's hard to find the good word that way. After soundfolding | |
504 the words become "tktnr" and "tkxnry", these differ by only two letters. | |
505 | |
506 To find words by their soundfolded equivalent (soundalike word) we need a list | |
507 of all soundfolded words. A few experiments have been done to find out what | |
508 the best method is. Alternatives: | |
509 1. Do the sound folding on the fly when looking for suggestions. This means | |
510 walking through the trie of good words, soundfolding each word and | |
511 checking how different it is from the bad word. This is very efficient for | |
512 memory use, but takes a long time. On a fast PC it takes a couple of | |
513 seconds for English, which can be acceptable for interactive use. But for | |
514 some languages it takes more than ten seconds (e.g., German, Catalan), | |
515 which is unacceptable slow. For batch processing (automatic corrections) | |
1197 | 516 it's too slow for all languages. |
625 | 517 2. Use a trie for the soundfolded words, so that searching can be done just |
518 like how it works without soundfolding. This requires remembering a list | |
519 of good words for each soundfolded word. This makes finding matches very | |
520 fast but requires quite a lot of memory, in the order of 1 to 10 Mbyte. | |
521 For some languages more than the original word list. | |
522 3. Like the second alternative, but reduce the amount of memory by using affix | |
523 compression and store only the soundfolded basic word. This is what Aspell | |
524 does. Disadvantage is that affixes need to be stripped from the bad word | |
525 before soundfolding it, which means that mistakes at the start and/or end | |
526 of the word will cause the mechanism to fail. Also, this becomes slow when | |
527 the bad word is quite different from the good word. | |
528 | |
529 The choice made is to use the second mechanism and use a separate file. This | |
530 way a user with sufficient memory can get very good suggestions while a user | |
531 who is short of memory or just wants the spell checking and no suggestions | |
532 doesn't use so much memory. | |
533 | |
534 | |
535 Word frequency | |
536 | |
537 For sorting suggestions it helps to know which words are common. In theory we | |
538 could store a word frequency with the word in the dictionary. However, this | |
539 requires storing a count per word. That degrades word tree compression a lot. | |
540 And maintaining the word frequency for all languages will be a heavy task. | |
541 Also, it would be nice to prefer words that are already in the text. This way | |
542 the words that appear in the specific text are preferred for suggestions. | |
543 | |
544 What has been implemented is to count words that have been seen during | |
545 displaying. A hashtable is used to quickly find the word count. The count is | |
546 initialized from words listed in COMMON items in the affix file, so that it | |
547 also works when starting a new file. | |
548 | |
549 This isn't ideal, because the longer Vim is running the higher the counts | |
1197 | 550 become. But in practice it is a noticeable improvement over not using the word |
625 | 551 count. |
552 | |
7 | 553 ============================================================================== |
554 4. Assumptions *design-assumptions* | |
555 | |
556 Size of variables: | |
557 char 8 bit signed | |
558 char_u 8 bit unsigned | |
625 | 559 int 32 or 64 bit signed (16 might be possible with limited features) |
560 unsigned 32 or 64 bit unsigned (16 as with ints) | |
7 | 561 long 32 or 64 bit signed, can hold a pointer |
562 | |
563 Note that some compilers cannot handle long lines or strings. The C89 | |
564 standard specifies a limit of 509 characters. | |
565 | |
14421 | 566 vim:tw=78:ts=8:noet:ft=help:norl: |