codekingpro/portable-devtools

1*develop.txt*	For Vim version 9.2.  Last change: 2026 Feb 142 3 4		  VIM REFERENCE MANUAL	  by Bram Moolenaar5 6 7Development of Vim.					*development*8 9This text is important for those who want to be involved in further developing10Vim.11 121. Design goals		|design-goals|132. Design decisions	|design-decisions|143. Assumptions		|design-assumptions|154. Coding style		|coding-style|165. Policy		|design-policy|17 18See the file README.txt in the "src" directory for an overview of the source19code.20 21Vim is open source software.  Everybody is encouraged to contribute to help22improving Vim.  For sending patches a unified diff "diff -u" is preferred.23You can create a pull request on github, but it's not required.24Also see http://vim.wikia.com/wiki/How_to_make_and_submit_a_patch.25 26==============================================================================271. Design goals						*design-goals*28 29Most important things come first (roughly).30 31Note that quite a few items are contradicting.  This is intentional.  A32balance must be found between them.33 34 35VIM IS... VI COMPATIBLE					*design-compatible*36 37First of all, it should be possible to use Vim as a drop-in replacement for38Vi.  When the user wants to, Vim can be used in compatible mode and hardly39any differences with the original Vi will be noticed.40 41Exceptions:42- We don't reproduce obvious Vi bugs in Vim.43- There are different versions of Vi.  I am using Version 3.7 (6/7/85) as a44  reference.  But support for other versions is also included when possible.45  The Vi part of POSIX is not considered a definitive source.46- Vim adds new commands, you cannot rely on some command to fail because it47  didn't exist in Vi.48- Vim will have a lot of features that Vi doesn't have.  Going back from Vim49  to Vi will be a problem, this cannot be avoided.50- Some things are hardly ever used (open mode, sending an e-mail when51  crashing, etc.).  Those will only be included when someone has a good reason52  why it should be included and it's not too much work.53- For some items it is debatable whether Vi compatibility should be54  maintained.  There will be an option flag for these.55 56 57VIM IS... IMPROVED					*design-improved*58 59The IMproved bits of Vim should make it a better Vi, without becoming a60completely different editor.  Extensions are done with a "Vi spirit".61- Use the keyboard as much as feasible.  The mouse requires a third hand,62  which we don't have.  Many terminals don't have a mouse.63- When the mouse is used anyway, avoid the need to switch back to the64  keyboard.  Avoid mixing mouse and keyboard handling.65- Add commands and options in a consistent way.  Otherwise people will have a66  hard time finding and remembering them.  Keep in mind that more commands and67  options will be added later.68- A feature that people do not know about is a useless feature.  Don't add69  obscure features, or at least add hints in documentation that they exist.70- Minimize using CTRL and other modifiers, they are more difficult to type.71- There are many first-time and inexperienced Vim users.  Make it easy for72  them to start using Vim and learn more over time.73- There is no limit to the features that can be added.  Selecting new features74  is one based on (1) what users ask for, (2) how much effort it takes to75  implement and (3) someone actually implementing it.76 77 78VIM IS... MULTI PLATFORM				*design-multi-platform*79 80Vim tries to help as many users on as many platforms as possible.81- Support many kinds of terminals.  The minimal demands are cursor positioning82  and clear-screen.  Commands should only use key strokes that most keyboards83  have.  Support all the keys on the keyboard for mapping.84- Support many platforms.  A condition is that there is someone willing to do85  Vim development on that platform, and it doesn't mean messing up the code.86- Support many compilers and libraries.  Not everybody is able or allowed to87  install another compiler or GUI library.88- People switch from one platform to another, and from GUI to terminal89  version.  Features should be present in all versions, or at least in as many90  as possible with a reasonable effort.  Try to avoid that users must switch91  between platforms to accomplish their work efficiently.92- That a feature is not possible on some platforms, or only possible on one93  platform, does not mean it cannot be implemented.  [This intentionally94  contradicts the previous item, these two must be balanced.]95 96 97VIM IS... WELL DOCUMENTED				*design-documented*98 99- A feature that isn't documented is a useless feature.  A patch for a new100  feature must include the documentation.101- Documentation should be comprehensive and understandable.  Using examples is102  recommended.103- Don't make the text unnecessarily long.  Less documentation means that an104  item is easier to find.105 106 107VIM IS... HIGH SPEED AND SMALL IN SIZE			*design-speed-size*108 109Using Vim must not be a big attack on system resources.  Keep it small and110fast.111- Computers are becoming faster and bigger each year.  Vim can grow too, but112  no faster than computers are growing.  Keep Vim usable on older systems.113- Many users start Vim from a shell very often.  Startup time must be short.114- Commands must work efficiently.  The time they consume must be as small as115  possible.  Useful commands may take longer.116- Don't forget that some people use Vim over a slow connection.  Minimize the117  communication overhead.118- Items that add considerably to the size and are not used by many people119  should be a feature that can be disabled.120- Vim is a component among other components.  Don't turn it into a massive121  application, but have it work well together with other programs.122 123 124VIM IS... MAINTAINABLE					*design-maintain*125 126- The source code should not become a mess.  It should be reliable code.127- Use the same layout in all files to make it easy to read |coding-style|.128- Use comments in a useful way!  Quoting the function name and argument names129  is NOT useful.  Do explain what they are for.130- Porting to another platform should be made easy, without having to change131  too much platform-independent code.132- Use the object-oriented spirit: Put data and code together.  Minimize the133  knowledge spread to other parts of the code.134 135 136VIM IS... FLEXIBLE					*design-flexible*137 138Vim should make it easy for users to work in their preferred styles rather139than coercing its users into particular patterns of work.  This can be for140items with a large impact (e.g., the 'compatible' option) or for details.  The141defaults are carefully chosen such that most users will enjoy using Vim as it142is.  Commands and options can be used to adjust Vim to the desire of the user143and its environment.144 145 146VIM IS... NOT						*design-not*147 148- Vim is not a shell or an Operating System.  It does provide a terminal149  window, in which you can run a shell or debugger.  E.g. to be able to do150  this over an ssh connection.  But if you don't need a text editor with that151  it is out of scope (use something like screen or tmux instead).152  A satirical way to say this: "Unlike Emacs, Vim does not attempt to include153  everything but the kitchen sink, but some people say that you can clean one154  with it.  ;-)"155  To use Vim with gdb see |terminal-debugger|.  Other (older) tools can be156  found at http://clewn.sf.net.157- Vim is not a fancy GUI editor that tries to look nice at the cost of158  being less consistent over all platforms.  But functional GUI features are159  welcomed.160 161 162==============================================================================1632. Design decisions					*design-decisions*164 165Folding166 167Several forms of folding should be possible for the same buffer.  For example,168have one window that shows the text with function bodies folded, another169window that shows a function body.170 171Folding is a way to display the text.  It should not change the text itself.172Therefore the folding has been implemented as a filter between the text stored173in a buffer (buffer lines) and the text displayed in a window (logical lines).174 175 176Naming the window177 178The word "window" is commonly used for several things: A window on the screen,179the xterm window, a window inside Vim to view a buffer.180To avoid confusion, other items that are sometimes called window have been181given another name.  Here is an overview of the related items:182 183screen		The whole display.  For the GUI it's something like 1024x768184		pixels.  The Vim shell can use the whole screen or part of it.185shell		The Vim application.  This can cover the whole screen (e.g.,186		when running in a console) or part of it (xterm or GUI).187window		View on a buffer.  There can be several windows in Vim,188		together with the command line, menubar, toolbar, etc. they189		fit in the shell.190 191 192Spell checking						*develop-spell*193 194When spell checking was going to be added to Vim a survey was done over the195available spell checking libraries and programs.  Unfortunately, the result196was that none of them provided sufficient capabilities to be used as the spell197checking engine in Vim, for various reasons:198 199- Missing support for multibyte encodings.  At least UTF-8 must be supported,200  so that more than one language can be used in the same file.201  Doing on-the-fly conversion is not always possible (would require iconv202  support).203- For the programs and libraries: Using them as-is would require installing204  them separately from Vim.  That's mostly not impossible, but a drawback.205- Performance: A few tests showed that it's possible to check spelling on the206  fly (while redrawing), just like syntax highlighting.  But the mechanisms207  used by other code are much slower.  Myspell uses a hashtable, for example.208  The affix compression that most spell checkers use makes it slower too.209- For using an external program like aspell a communication mechanism would210  have to be setup.  That's complicated to do in a portable way (Unix-only211  would be relatively simple, but that's not good enough).  And performance212  will become a problem (lots of process switching involved).213- Missing support for words with non-word characters, such as "Etten-Leur" and214  "et al.", would require marking the pieces of them OK, lowering the215  reliability.216- Missing support for regions or dialects.  Makes it difficult to accept217  all English words and highlight non-Canadian words differently.218- Missing support for rare words.  Many words are correct but hardly ever used219  and could be a misspelled often-used word.220- For making suggestions the speed is less important and requiring to install221  another program or library would be acceptable.  But the word lists probably222  differ, the suggestions may be wrong words.223 224 225Spelling suggestions				*develop-spell-suggestions*226 227For making suggestions there are two basic mechanisms:2281. Try changing the bad word a little bit and check for a match with a good229   word.  Or go through the list of good words, change them a little bit and230   check for a match with the bad word.  The changes are deleting a character,231   inserting a character, swapping two characters, etc.2322. Perform soundfolding on both the bad word and the good words and then find233   matches, possibly with a few changes like with the first mechanism.234 235The first is good for finding typing mistakes.  After experimenting with236hashtables and looking at solutions from other spell checkers the conclusion237was that a trie (a kind of tree structure) is ideal for this.  Both for238reducing memory use and being able to try sensible changes.  For example, when239inserting a character only characters that lead to good words need to be240tried.  Other mechanisms (with hashtables) need to try all possible letters at241every position in the word.  Also, a hashtable has the requirement that word242boundaries are identified separately, while a trie does not require this.243That makes the mechanism a lot simpler.244 245Soundfolding is useful when someone knows how the words sounds but doesn't246know how it is spelled.  For example, the word "dictionary" might be written247as "daktonerie".  The number of changes that the first method would need to248try is very big, it's hard to find the good word that way.  After soundfolding249the words become "tktnr" and "tkxnry", these differ by only two letters.250 251To find words by their soundfolded equivalent (soundalike word) we need a list252of all soundfolded words.  A few experiments have been done to find out what253the best method is.  Alternatives:2541. Do the sound folding on the fly when looking for suggestions.  This means255   walking through the trie of good words, soundfolding each word and256   checking how different it is from the bad word.  This is very efficient for257   memory use, but takes a long time.  On a fast PC it takes a couple of258   seconds for English, which can be acceptable for interactive use.  But for259   some languages it takes more than ten seconds (e.g., German, Catalan),260   which is unacceptably slow.  For batch processing (automatic corrections)261   it's too slow for all languages.2622. Use a trie for the soundfolded words, so that searching can be done just263   like how it works without soundfolding.  This requires remembering a list264   of good words for each soundfolded word.  This makes finding matches very265   fast but requires quite a lot of memory, in the order of 1 to 10 Mbyte.266   For some languages more than the original word list.2673. Like the second alternative, but reduce the amount of memory by using affix268   compression and store only the soundfolded basic word.  This is what Aspell269   does.  Disadvantage is that affixes need to be stripped from the bad word270   before soundfolding it, which means that mistakes at the start and/or end271   of the word will cause the mechanism to fail.  Also, this becomes slow when272   the bad word is quite different from the good word.273 274The choice made is to use the second mechanism and use a separate file.  This275way a user with sufficient memory can get very good suggestions while a user276who is short of memory or just wants the spell checking and no suggestions277doesn't use so much memory.278 279 280Word frequency281 282For sorting suggestions it helps to know which words are common.  In theory we283could store a word frequency with the word in the dictionary.  However, this284requires storing a count per word.  That degrades word tree compression a lot.285And maintaining the word frequency for all languages will be a heavy task.286Also, it would be nice to prefer words that are already in the text.  This way287the words that appear in the specific text are preferred for suggestions.288 289What has been implemented is to count words that have been seen during290displaying.  A hashtable is used to quickly find the word count.  The count is291initialized from words listed in COMMON items in the affix file, so that it292also works when starting a new file.293 294This isn't ideal, because the longer Vim is running the higher the counts295become.  But in practice it is a noticeable improvement over not using the296word count.297 298==============================================================================2993. Assumptions						*design-assumptions*300 301The following sections define the portability and compatibility constraints302that all Vim code and build tools must adhere to.303 304 305MAKEFILES					*assumptions-makefiles*306						*POSIX.1-2001*307 308Vim's main Makefiles target maximum portability, relying solely on features309defined in POSIX.1-2001 `make` and ignoring later POSIX standards or GNU/BSD310extensions.  In practical terms, avoid:311 312	- % pattern rules313	- modern assignment (`:=`, `::=`) outside POSIX.1-2001314	- special targets (`.ONESHELL`, `.NOTPARALLEL`, `.SILENT`, ...)315	- order-only prerequisites (`|`) or automatic directory creation316	- GNU/BSD conditionals (`ifdef`, `ifndef`, `.for`/`.endfor`, ...)317 318Since POSIX.1-2001 supports only traditional suffix rules, every object built319in a separate directory must have an explicit rule.  For example:320 321	objects/evalbuffer.o: evalbuffer.c322		$(CCC) -o $@ evalbuffer.c323 324This verbosity ensures that the same Makefile builds Vim unchanged with the325default `make` on Linux, *BSD, macOS, Solaris, AIX, HP-UX and virtually any326Unix-like OS.327 328Some platform-specific Makefiles (e.g., for Windows, NSIS, or Cygwin) may use329more advanced features when compatibility with basic make is not required.330 331 332C COMPILER					*assumptions-C-compiler*333						*ANSI-C* *C89* *C90* *C95* *C99*334 335Vim strives for maximum portability (see |design-multi-platform|) and must336still build with Compaq C V6.4-005 on OpenVMS VAX V7.3.337 338Therefore, the latest ISO C standard we follow is:339 340	`C95` (ISO/IEC 9899:1990/AMD1:1995)341 342In addition, the following `C99` features are explicitly allowed:343	- `//` comments, as required by |style-comments|;344	- Mixed declarations and statements in a block;345	- Variadic macros `(..., __VA_ARGS__)`;346	- Trailing comma in `enum` lists;347	- `_Bool` type (for `bool`, `true` and `false`);348	- `__func__` predefined identifier;349	- `inline` functions (use `static inline` for portability);350	- Compound literals `(type){ initializer-list }`;351	- Logical source lines up to 4095 characters.352 353Platform-specific code may use any newer compiler features supported on that354platform.355 356 357SIZE OF VARIABLES				*assumptions-variables*358 359We follow POSIX.1-2001 (SUSv3) for type sizes, which in practice means:360 361	char_u	    8-bit unsigned362	int	    32-bit or larger signed363	unsigned    32-bit or larger unsigned364 365 366FUNCTION PROTOTYPES				*assumptions-prototypes*367 368Vim does not use conventional header files (`.h`) for most internal function369prototypes.  Instead, the current architecture uses individual `.pro` files in370the `src/proto/` directory, with one `.pro` file per `.c` file.371 372Unlike traditional self-contained header files, these `.pro` files do not373contain API documentation, struct and enum definitions, or other declarations;374only function prototypes.375 376The `make proto` target in `src/Makefile` automates updating most of the .pro377files using the Python script proto/gen_prototypes.py, which relies on the378python3-clang module.  Note that a few proto files are hand edited.379 380==============================================================================3814. Coding style						*coding-style*382 383These are the rules to use when making changes to the Vim source code.  Please384stick to these rules, to keep the sources readable and maintainable.385 386This list is not complete.  Look in the source code for more examples.387 388The code repository contains an editorconfig file, that can be used together389with the distributed editorconfig plugin |editorconfig-install| to ensure the390recommended style is followed.391 392 393MAKING CHANGES						*style-changes*394 395The basic steps to make changes to the code:3961. Get the code from github.  That makes it easier to keep your changed397   version in sync with the main code base (it may be a while before your398   changes will be included).3992. Adjust the documentation.  Doing this first gives you an impression of how400   your changes affect the user.4013. Make the source code changes.4024. Check ../doc/todo.txt if the change affects any listed item.4035. Add a test to src/testdir to verify the new behaviour and ensure it won't404   regress in the future.4056. Make a patch with "git diff".4067. Make a note about what changed, preferably mentioning the problem and the407   solution.  Send an email to the |vim-dev| maillist with an explanation and408   include the diff.409 410For any non-trivial change, please always create a pull request on github,411since this triggers the test suite.412 413A PR should ideally contain a single commit for a single logical change.414However, you can include several commits if you want to group multiple415logical, atomic changes in one PR.  This can also make longer PRs easier to416review.  Be sure to describe the reasoning for your changes in each commit417message, as this greatly helps with the review process.  In cases where each418commit handles different logical changes, they will also be applied as419separate patches in Vim's repository.420 421							*style-clang-format*422sound.c and sign.c can be (semi-) automatically formatted using the423`clang-format` formatter according to the distributed .clang-format file.424Other source files do not yet correspond to the .clang-format file.  This may425change in the future and they may be reformatted as well.426 427 428COMMENTS						*style-comments*429 430Try to avoid putting multiline comments inside a function body: if the431function is so complex that you need to separately comment parts of it, you432should probably rethink the structure of the function.433 434For file headers and function descriptions use: >435    /*436     * Description437     */438<439For everything else use: >440    // comment441<442 443INDENTATION						*style-indentation*444 445We use 4 space to indent the code.  If you are using Vim to edit the source,446you don't need to do anything due to the |modeline|.447 448For other editors an `.editorconfig` is provided at the root of the repo.449 450For the source files `sign.c` and `sound.c` and any new file use only spaces,451no tabs.  In addition, any new file must include a modeline with `set et` to452pass the indentation test.453 454 455DECLARATIONS						*style-declarations*456 457Declare, when possible, `for` loop variables in the guard:458OK: >459    for (int i = 0; i < len; ++i)460<461Wrong: >462    int i;463    for (i = 0; i < len; ++i)464<465Always declare a variable with a default value:466OK: >467    int n = 0;468    int *ptr = NULL;469<470Wrong: >471    int n;472    int *ptr;473<474 475BRACES							*style-braces*476 477All curly braces must be returned onto a new line:478OK: >479    if (cond)480    {481	cmd;482	cmd;483    }484    else485    {486	cmd;487	cmd;488    }489<490Wrong: >491    if (cond) {492	cmd;493	cmd;494    } else {495	cmd;496	cmd;497    }498<499OK: >500    while (cond)501    {502	cmd;503	cmd;504    }505<506Wrong: >507    while (cond) {508	cmd;509	cmd;510    }511<512OK: >513    do514    {515	cmd;516	cmd;517    } while (cond);518<519or >520    do521    {522	cmd;523	cmd;524    }525    while (cond);526<527Wrong: >528    do {529	cmd;530	cmd;531    } while (cond);532<533 534TYPES							    *style-types*535 536Use descriptive types.  These are defined in src/vim.h, src/structs.h etc.537Note that all custom types are postfixed with "_T"538 539Example: >540    linenr_T541    buf_T542    pos_T543<544 545SPACES AND PUNCTUATION					   *style-spaces*546 547No space between a function name and the bracket:548 549OK:	func(arg);550Wrong:  func (arg);551 552Do use a space after `if`, `while`, `switch`, etc.553 554OK:	if (arg)	for (;;)555Wrong:	if(arg)		for(;;)556 557Use a space after a comma or semicolon:558 559OK:	func(arg1, arg2);	for (i = 0; i < 2; ++i)560Wrong:  func(arg1,arg2);	for (i = 0;i < 2;++i)561 562Use a space before and after '=', '+', '/', etc.563 564OK:	var = a * 5;565Wrong:	var=a*5;566 567Use empty lines to group similar actions together.568 569OK: >570    msg_puts_title(_("\n--- Signs ---"));571    msg_putchar('\n');572 573    if (rbuf == NULL)574	buf = firstbuf;575    else576	buf = rbuf;577 578    while (buf != NULL && !got_int)579<580Wrong: >581    msg_puts_title(_("\n--- Signs ---"));582    msg_putchar('\n');583    if (rbuf == NULL)584	buf = firstbuf;585    else586	buf = rbuf;587    while (buf != NULL && !got_int)588<589 590FUNCTIONS						*style-functions*591 592Use function declarations with the return type on a separate indented line.593 594OK: >595    int596    function_name(int arg1, int arg2)597    {598    }599<600Wrong: >601    int function_name(int arg1, int arg2)602    {603    }604<605 606Give meaningful names to function parameters.607 608 609USE OF COMMON FUNCTIONS				 *style-common-functions*610 611Some functions that are common to use, have a special Vim version.  Always612consider using the Vim version, because they were introduced with a reason.613 614NORMAL NAME	VIM NAME	DIFFERENCE OF VIM VERSION615free()		vim_free()	Checks for freeing NULL616malloc()	alloc()		Checks for out of memory situation617malloc()	lalloc()	Like alloc(), but has long argument618strcpy()	STRCPY()	Includes cast to (char *), for char_u * args619strchr()	vim_strchr()	Accepts special characters620strrchr()	vim_strrchr()	Accepts special characters621isspace()	vim_isspace()	Can handle characters > 128622iswhite()	vim_iswhite()	Only TRUE for tab and space623memcpy()	mch_memmove()	Handles overlapped copies624bcopy()		mch_memmove()	Handles overlapped copies625memset()	vim_memset()	Uniform for all systems626 627 628NAMES							*style-names*629 630Function names can not be more than 31 characters long (because of VMS).631 632Don't use "delete" or "this" as a variable name, C++ doesn't like it.633 634Because of the requirement that Vim runs on as many systems as possible, we635need to avoid using names that are already defined by the system.  This is a636list of names that are known to cause trouble.  The name is given as a regexp637pattern.638 639is.*()		POSIX, ctype.h640to.*()		POSIX, ctype.h641 642d_.*		POSIX, dirent.h643l_.*		POSIX, fcntl.h644gr_.*		POSIX, grp.h645pw_.*		POSIX, pwd.h646sa_.*		POSIX, signal.h647mem.*		POSIX, string.h648str.*		POSIX, string.h649wcs.*		POSIX, string.h650st_.*		POSIX, stat.h651tms_.*		POSIX, times.h652tm_.*		POSIX, time.h653c_.*		POSIX, termios.h654MAX.*		POSIX, limits.h655__.*		POSIX, system656_[A-Z].*	POSIX, system657E[A-Z0-9]*	POSIX, errno.h658 659.*_t		POSIX, for typedefs.  Use .*_T instead.660 661wait		don't use as argument to a function, conflicts with types.h662index		shadows global declaration663time		shadows global declaration664new		C++ reserved keyword665 666clear		Mac curses.h667echo		Mac curses.h668instr		Mac curses.h669meta		Mac curses.h670newwin		Mac curses.h671nl		Mac curses.h672overwrite	Mac curses.h673refresh		Mac curses.h674scroll		Mac curses.h675typeahead	Mac curses.h676 677basename()	GNU string function678dirname()	GNU string function679get_env_value()	Linux system function680 681 682VARIOUS							*style-various*683 684Define'd names should be uppercase: >685    #define SOME_THING686<687 688Features always start with "FEAT_": >689    #define FEAT_FOO690<691 692Don't use '\"', some compilers can't handle it.  '"' works fine.693 694Don't use: >695    #if HAVE_SOME696<697Some compilers can't handle that and complain that "HAVE_SOME" is not defined.698Use >699    #ifdef HAVE_SOME700<701or >702    #if defined(HAVE_SOME)703<704 705STYLE							*style-examples*706 707One statement per line.708 709Wrong:	    if (cond) a = 1;710 711OK:	    if (cond)712		a = 1;713 714Wrong:	    while (cond);715 716OK:	    while (cond)717		;718 719Wrong:	    do a = 1; while (cond);720 721OK:	    do722		a = 1;723	    while (cond);724 725 726==============================================================================7275. Policy	*design-policy* *new-features* *deprecated-features*728 729The time between either a new minor (e.g. 9.2.0) or major (e.g. 10.0) version730is released is called a development cycle.  Within the development cycle each731single change to the C core will receive a new increased human-readable patch732number in order to reference each specific patch release.  A typical733development release cycle may last several years and accumulate about 1500 -7342500 patch numbers.735 736Before a release is made, a stability period will be announced.  During this737time, only clear bug fixes, security fixes, documentation changes, translation738updates and runtime file updates will be accepted (provided they do not739introduce backwards-incompatible changes), concentrating on polishing up the740upcoming release.741 742New features are accepted only within a development cycle, but not within the743stability period.  During the cycle, new features may be developed and are744allowed to change, but they must be settled before the cycle closes.745 746Once a minor release has been made, features included in that release must not747receive any backwards-incompatible changes.  Later patches are expected to748preserve compatibility for the C core of Vim.  Runtime files are handled a bit749more flexibly to give runtime files maintainers a chance to change old750behaviour.751 752Within a development cycle, features may be marked as deprecated.  Deprecated753features can be disabled at compile time through an appropriate switch.  After754a new release, deprecated features may be removed completely in a following755cycle.756 757 vim:tw=78:ts=8:noet:ft=help:norl:758