Mercurial > vim
view runtime/doc/develop.txt @ 32936:c517845bd10e v9.0.1776
patch 9.0.1776: No support for stable Python 3 ABI
Commit: https://github.com/vim/vim/commit/c13b3d1350b60b94fe87f0761ea31c0e7fb6ebf3
Author: Yee Cheng Chin <ychin.git@gmail.com>
Date: Sun Aug 20 21:18:38 2023 +0200
patch 9.0.1776: No support for stable Python 3 ABI
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
author | Christian Brabandt <cb@256bit.org> |
---|---|
date | Sun, 20 Aug 2023 21:30:04 +0200 |
parents | 1e91e26ceebf |
children | 4635e43f2c6f |
line wrap: on
line source
*develop.txt* For Vim version 9.0. Last change: 2022 Sep 20 VIM REFERENCE MANUAL by Bram Moolenaar Development of Vim. *development* This text is important for those who want to be involved in further developing Vim. 1. Design goals |design-goals| 2. Coding style |coding-style| 3. Design decisions |design-decisions| 4. Assumptions |design-assumptions| See the file README.txt in the "src" directory for an overview of the source code. Vim is open source software. Everybody is encouraged to contribute to help improving Vim. For sending patches a unified diff "diff -u" is preferred. You can create a pull request on github, but it's not required. Also see http://vim.wikia.com/wiki/How_to_make_and_submit_a_patch. ============================================================================== 1. Design goals *design-goals* Most important things come first (roughly). Note that quite a few items are contradicting. This is intentional. A balance must be found between them. VIM IS... VI COMPATIBLE *design-compatible* First of all, it should be possible to use Vim as a drop-in replacement for Vi. When the user wants to, Vim can be used in compatible mode and hardly any differences with the original Vi will be noticed. Exceptions: - We don't reproduce obvious Vi bugs in Vim. - There are different versions of Vi. I am using Version 3.7 (6/7/85) as a reference. But support for other versions is also included when possible. The Vi part of POSIX is not considered a definitive source. - Vim adds new commands, you cannot rely on some command to fail because it didn't exist in Vi. - Vim will have a lot of features that Vi doesn't have. Going back from Vim to Vi will be a problem, this cannot be avoided. - Some things are hardly ever used (open mode, sending an e-mail when crashing, etc.). Those will only be included when someone has a good reason why it should be included and it's not too much work. - For some items it is debatable whether Vi compatibility should be maintained. There will be an option flag for these. VIM IS... IMPROVED *design-improved* The IMproved bits of Vim should make it a better Vi, without becoming a completely different editor. Extensions are done with a "Vi spirit". - Use the keyboard as much as feasible. The mouse requires a third hand, which we don't have. Many terminals don't have a mouse. - When the mouse is used anyway, avoid the need to switch back to the keyboard. Avoid mixing mouse and keyboard handling. - Add commands and options in a consistent way. Otherwise people will have a hard time finding and remembering them. Keep in mind that more commands and options will be added later. - A feature that people do not know about is a useless feature. Don't add obscure features, or at least add hints in documentation that they exist. - Minimize using CTRL and other modifiers, they are more difficult to type. - There are many first-time and inexperienced Vim users. Make it easy for them to start using Vim and learn more over time. - There is no limit to the features that can be added. Selecting new features is one based on (1) what users ask for, (2) how much effort it takes to implement and (3) someone actually implementing it. VIM IS... MULTI PLATFORM *design-multi-platform* Vim tries to help as many users on as many platforms as possible. - Support many kinds of terminals. The minimal demands are cursor positioning and clear-screen. Commands should only use key strokes that most keyboards have. Support all the keys on the keyboard for mapping. - Support many platforms. A condition is that there is someone willing to do Vim development on that platform, and it doesn't mean messing up the code. - Support many compilers and libraries. Not everybody is able or allowed to install another compiler or GUI library. - People switch from one platform to another, and from GUI to terminal version. Features should be present in all versions, or at least in as many as possible with a reasonable effort. Try to avoid that users must switch between platforms to accomplish their work efficiently. - That a feature is not possible on some platforms, or only possible on one platform, does not mean it cannot be implemented. [This intentionally contradicts the previous item, these two must be balanced.] VIM IS... WELL DOCUMENTED *design-documented* - A feature that isn't documented is a useless feature. A patch for a new feature must include the documentation. - Documentation should be comprehensive and understandable. Using examples is recommended. - Don't make the text unnecessarily long. Less documentation means that an item is easier to find. VIM IS... HIGH SPEED AND SMALL IN SIZE *design-speed-size* Using Vim must not be a big attack on system resources. Keep it small and fast. - Computers are becoming faster and bigger each year. Vim can grow too, but no faster than computers are growing. Keep Vim usable on older systems. - Many users start Vim from a shell very often. Startup time must be short. - Commands must work efficiently. The time they consume must be as small as possible. Useful commands may take longer. - Don't forget that some people use Vim over a slow connection. Minimize the communication overhead. - Items that add considerably to the size and are not used by many people should be a feature that can be disabled. - Vim is a component among other components. Don't turn it into a massive application, but have it work well together with other programs. VIM IS... MAINTAINABLE *design-maintain* - The source code should not become a mess. It should be reliable code. - Use the same layout in all files to make it easy to read |coding-style|. - Use comments in a useful way! Quoting the function name and argument names is NOT useful. Do explain what they are for. - Porting to another platform should be made easy, without having to change too much platform-independent code. - Use the object-oriented spirit: Put data and code together. Minimize the knowledge spread to other parts of the code. VIM IS... FLEXIBLE *design-flexible* Vim should make it easy for users to work in their preferred styles rather than coercing its users into particular patterns of work. This can be for items with a large impact (e.g., the 'compatible' option) or for details. The defaults are carefully chosen such that most users will enjoy using Vim as it is. Commands and options can be used to adjust Vim to the desire of the user and its environment. VIM IS... NOT *design-not* - Vim is not a shell or an Operating System. It does provide a terminal window, in which you can run a shell or debugger. E.g. to be able to do this over an ssh connection. But if you don't need a text editor with that it is out of scope (use something like screen or tmux instead). A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)" To use Vim with gdb see |terminal-debugger|. Other (older) tools can be found at http://www.agide.org and http://clewn.sf.net. - Vim is not a fancy GUI editor that tries to look nice at the cost of being less consistent over all platforms. But functional GUI features are welcomed. ============================================================================== 2. Coding style *coding-style* These are the rules to use when making changes to the Vim source code. Please stick to these rules, to keep the sources readable and maintainable. This list is not complete. Look in the source code for more examples. MAKING CHANGES *style-changes* The basic steps to make changes to the code: 1. Get the code from github. That makes it easier to keep your changed version in sync with the main code base (it may be a while before your changes will be included). You do need to spend some time learning git, it's not the most user friendly tool. 2. Adjust the documentation. Doing this first gives you an impression of how your changes affect the user. 3. Make the source code changes. 4. Check ../doc/todo.txt if the change affects any listed item. 5. Make a patch with "git diff". You can also create a pull request on github, but it's the diff that matters. 6. Make a note about what changed, preferably mentioning the problem and the solution. Send an email to the |vim-dev| maillist with an explanation and include the diff. Or create a pull request on github. C COMPILER *style-compiler* *ANSI-C* *C89* *C99* The minimal C compiler version supported is C89, also known as ANSI C. Later standards, such as C99, are not widely supported, or at least not 100% supported. Therefore we use only some of the C99 features and explicitly disallow some (this will gradually be adjusted over time). Please don't make changes everywhere to use the C99 features, it causes merge problems for existing patches. Only use them for new and changed code. Comments ~ Traditionally Vim uses /* comments */. We intend to keep it that way for file and function headers and larger blocks of code, E.g.: /* * The "foo" argument does something useful. * Return OK or FAIL. */ For new code or lines of code that change, it is preferred to use // comments. Especially when it comes after code: int some_var; // single line comment useful here Enums ~ The last item in an enum may have a trailing comma. C89 didn't allow this. Types ~ "long long" is allowed and can be expected to be 64 bits. Use %lld in printf formats. Also "long long unsigned" with %llu. Declarations ~ Now that the minimal supported compiler is MSVC 2015 declarations do not need to be at the start of a block. However, it is often a good idea to do this anyway. Declaration of the for loop variable inside the loop is recommended: for (int i = 0; i < len; ++i) Since this is clearly an advantage we'll use this more often. Not to be used ~ These C99 features are not to be used, because not enough compilers support them: - Variable length arrays (even in C11 this is an optional feature). - _Bool and _Complex types. - "inline" (it's hardly ever needed, let the optimizer do its work) - flexible array members: Not supported by HP-UX C compiler (John Marriott) USE OF COMMON FUNCTIONS *style-functions* Some functions that are common to use, have a special Vim version. Always consider using the Vim version, because they were introduced with a reason. NORMAL NAME VIM NAME DIFFERENCE OF VIM VERSION free() vim_free() Checks for freeing NULL malloc() alloc() Checks for out of memory situation malloc() lalloc() Like alloc(), but has long argument strcpy() STRCPY() Includes cast to (char *), for char_u * args strchr() vim_strchr() Accepts special characters strrchr() vim_strrchr() Accepts special characters isspace() vim_isspace() Can handle characters > 128 iswhite() vim_iswhite() Only TRUE for tab and space memcpy() mch_memmove() Handles overlapped copies bcopy() mch_memmove() Handles overlapped copies memset() vim_memset() Uniform for all systems NAMES *style-names* Function names can not be more than 31 characters long (because of VMS). Don't use "delete" or "this" as a variable name, C++ doesn't like it. Because of the requirement that Vim runs on as many systems as possible, we need to avoid using names that are already defined by the system. This is a list of names that are known to cause trouble. The name is given as a regexp pattern. is.*() POSIX, ctype.h to.*() POSIX, ctype.h d_.* POSIX, dirent.h l_.* POSIX, fcntl.h gr_.* POSIX, grp.h pw_.* POSIX, pwd.h sa_.* POSIX, signal.h mem.* POSIX, string.h str.* POSIX, string.h wcs.* POSIX, string.h st_.* POSIX, stat.h tms_.* POSIX, times.h tm_.* POSIX, time.h c_.* POSIX, termios.h MAX.* POSIX, limits.h __.* POSIX, system _[A-Z].* POSIX, system E[A-Z0-9]* POSIX, errno.h .*_t POSIX, for typedefs. Use .*_T instead. wait don't use as argument to a function, conflicts with types.h index shadows global declaration time shadows global declaration new C++ reserved keyword clear Mac curses.h echo Mac curses.h instr Mac curses.h meta Mac curses.h newwin Mac curses.h nl Mac curses.h overwrite Mac curses.h refresh Mac curses.h scroll Mac curses.h typeahead Mac curses.h basename() GNU string function dirname() GNU string function get_env_value() Linux system function VARIOUS *style-various* Typedef'ed names should end in "_T": > typedef int some_T; Define'ed names should be uppercase: > #define SOME_THING Features always start with "FEAT_": > #define FEAT_FOO Don't use '\"', some compilers can't handle it. '"' works fine. Don't use: #if HAVE_SOME Some compilers can't handle that and complain that "HAVE_SOME" is not defined. Use #ifdef HAVE_SOME or #if defined(HAVE_SOME) STYLE *style-examples* General rule: One statement per line. Wrong: if (cond) a = 1; OK: if (cond) a = 1; Wrong: while (cond); OK: while (cond) ; Wrong: do a = 1; while (cond); OK: do a = 1; while (cond); Wrong: if (cond) { cmd; cmd; } else { cmd; cmd; } OK: if (cond) { cmd; cmd; } else { cmd; cmd; } When a block has one line the braces can be left out. When an if/else has braces on one block, it usually looks better when the other block also has braces: OK: if (cond) cmd; else cmd; OK: if (cond) { cmd; } else { cmd; cmd; } Use ANSI (new style) function declarations with the return type on a separate indented line. Wrong: int function_name(int arg1, int arg2) OK: /* * Explanation of what this function is used for. * * Return value explanation. */ int function_name( int arg1, // short comment about arg1 int arg2) // short comment about arg2 { int local; // comment about local local = arg1 * arg2; SPACES AND PUNCTUATION *style-spaces* No space between a function name and the bracket: Wrong: func (arg); OK: func(arg); Do use a space after if, while, switch, etc. Wrong: if(arg) for(;;) OK: if (arg) for (;;) Use a space after a comma and semicolon: Wrong: func(arg1,arg2); for (i = 0;i < 2;++i) OK: func(arg1, arg2); for (i = 0; i < 2; ++i) Use a space before and after '=', '+', '/', etc. Wrong: var=a*5; OK: var = a * 5; In general: Use empty lines to group lines of code together. Put a comment just above the group of lines. This makes it easier to quickly see what is being done. OK: /* Prepare for building the table. */ get_first_item(); table_idx = 0; /* Build the table */ while (has_item()) table[table_idx++] = next_item(); /* Finish up. */ cleanup_items(); generate_hash(table); ============================================================================== 3. Design decisions *design-decisions* Folding Several forms of folding should be possible for the same buffer. For example, have one window that shows the text with function bodies folded, another window that shows a function body. Folding is a way to display the text. It should not change the text itself. Therefore the folding has been implemented as a filter between the text stored in a buffer (buffer lines) and the text displayed in a window (logical lines). Naming the window The word "window" is commonly used for several things: A window on the screen, the xterm window, a window inside Vim to view a buffer. To avoid confusion, other items that are sometimes called window have been given another name. Here is an overview of the related items: screen The whole display. For the GUI it's something like 1024x768 pixels. The Vim shell can use the whole screen or part of it. shell The Vim application. This can cover the whole screen (e.g., when running in a console) or part of it (xterm or GUI). window View on a buffer. There can be several windows in Vim, together with the command line, menubar, toolbar, etc. they fit in the shell. Spell checking *develop-spell* When spell checking was going to be added to Vim a survey was done over the available spell checking libraries and programs. Unfortunately, the result was that none of them provided sufficient capabilities to be used as the spell checking engine in Vim, for various reasons: - Missing support for multibyte encodings. At least UTF-8 must be supported, so that more than one language can be used in the same file. Doing on-the-fly conversion is not always possible (would require iconv support). - For the programs and libraries: Using them as-is would require installing them separately from Vim. That's mostly not impossible, but a drawback. - Performance: A few tests showed that it's possible to check spelling on the fly (while redrawing), just like syntax highlighting. But the mechanisms used by other code are much slower. Myspell uses a hashtable, for example. The affix compression that most spell checkers use makes it slower too. - For using an external program like aspell a communication mechanism would have to be setup. That's complicated to do in a portable way (Unix-only would be relatively simple, but that's not good enough). And performance will become a problem (lots of process switching involved). - Missing support for words with non-word characters, such as "Etten-Leur" and "et al.", would require marking the pieces of them OK, lowering the reliability. - Missing support for regions or dialects. Makes it difficult to accept all English words and highlight non-Canadian words differently. - Missing support for rare words. Many words are correct but hardly ever used and could be a misspelled often-used word. - For making suggestions the speed is less important and requiring to install another program or library would be acceptable. But the word lists probably differ, the suggestions may be wrong words. Spelling suggestions *develop-spell-suggestions* For making suggestions there are two basic mechanisms: 1. Try changing the bad word a little bit and check for a match with a good word. Or go through the list of good words, change them a little bit and check for a match with the bad word. The changes are deleting a character, inserting a character, swapping two characters, etc. 2. Perform soundfolding on both the bad word and the good words and then find matches, possibly with a few changes like with the first mechanism. The first is good for finding typing mistakes. After experimenting with hashtables and looking at solutions from other spell checkers the conclusion was that a trie (a kind of tree structure) is ideal for this. Both for reducing memory use and being able to try sensible changes. For example, when inserting a character only characters that lead to good words need to be tried. Other mechanisms (with hashtables) need to try all possible letters at every position in the word. Also, a hashtable has the requirement that word boundaries are identified separately, while a trie does not require this. That makes the mechanism a lot simpler. Soundfolding is useful when someone knows how the words sounds but doesn't know how it is spelled. For example, the word "dictionary" might be written as "daktonerie". The number of changes that the first method would need to try is very big, it's hard to find the good word that way. After soundfolding the words become "tktnr" and "tkxnry", these differ by only two letters. To find words by their soundfolded equivalent (soundalike word) we need a list of all soundfolded words. A few experiments have been done to find out what the best method is. Alternatives: 1. Do the sound folding on the fly when looking for suggestions. This means walking through the trie of good words, soundfolding each word and checking how different it is from the bad word. This is very efficient for memory use, but takes a long time. On a fast PC it takes a couple of seconds for English, which can be acceptable for interactive use. But for some languages it takes more than ten seconds (e.g., German, Catalan), which is unacceptably slow. For batch processing (automatic corrections) it's too slow for all languages. 2. Use a trie for the soundfolded words, so that searching can be done just like how it works without soundfolding. This requires remembering a list of good words for each soundfolded word. This makes finding matches very fast but requires quite a lot of memory, in the order of 1 to 10 Mbyte. For some languages more than the original word list. 3. Like the second alternative, but reduce the amount of memory by using affix compression and store only the soundfolded basic word. This is what Aspell does. Disadvantage is that affixes need to be stripped from the bad word before soundfolding it, which means that mistakes at the start and/or end of the word will cause the mechanism to fail. Also, this becomes slow when the bad word is quite different from the good word. The choice made is to use the second mechanism and use a separate file. This way a user with sufficient memory can get very good suggestions while a user who is short of memory or just wants the spell checking and no suggestions doesn't use so much memory. Word frequency For sorting suggestions it helps to know which words are common. In theory we could store a word frequency with the word in the dictionary. However, this requires storing a count per word. That degrades word tree compression a lot. And maintaining the word frequency for all languages will be a heavy task. Also, it would be nice to prefer words that are already in the text. This way the words that appear in the specific text are preferred for suggestions. What has been implemented is to count words that have been seen during displaying. A hashtable is used to quickly find the word count. The count is initialized from words listed in COMMON items in the affix file, so that it also works when starting a new file. This isn't ideal, because the longer Vim is running the higher the counts become. But in practice it is a noticeable improvement over not using the word count. ============================================================================== 4. Assumptions *design-assumptions* Size of variables: char 8 bit signed char_u 8 bit unsigned int 32 or 64 bit signed (16 might be possible with limited features) unsigned 32 or 64 bit unsigned (16 as with ints) long 32 or 64 bit signed, can hold a pointer Note that some compilers cannot handle long lines or strings. The C89 standard specifies a limit of 509 characters. vim:tw=78:ts=8:noet:ft=help:norl: