From 933143ea574e5e2cee140e4e4d724f7bb86cce41 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Mon, 5 Aug 2024 16:24:35 +0000 Subject: [PATCH] chore(build): auto-generate docs --- docs/config.md | 163 ++++++++++++----------- docs/design.md | 182 +++++++++++--------------- docs/dev/code_style.md | 42 ++++++ docs/dev/context.md | 59 ++++++--- docs/dev/core.md | 70 ++++++---- docs/dev/index.md | 27 ++++ docs/dev/menu.md | 65 +++++---- docs/{index.md => getting_started.md} | 0 8 files changed, 345 insertions(+), 263 deletions(-) create mode 100644 docs/dev/code_style.md create mode 100644 docs/dev/index.md rename docs/{index.md => getting_started.md} (100%) diff --git a/docs/config.md b/docs/config.md index d3ce8e0..df264d4 100644 --- a/docs/config.md +++ b/docs/config.md @@ -4,102 +4,61 @@ description: Configuration for care.nvim sidebar_position: 2 --- -# General +# Config The config of care is used to configure the ui and care itself. -There are two main parts to the config. The first one is the `ui` field and the second on is the -rest of the configuration which is for configuring care itself. +There are two main parts to the config. The first one is the `ui` field and the +second on is the rest of the configuration which is for configuring the general +behavior of care. ## UI -In the ui field the completion menu, the docs view and the format of the entries are configured. -There is also a field for configuring type icons. +The ui configuration is used to configure the whole ui of care. One of the main +goals of this is to be as extensible as possible. This is especially important +for the completion entries. Read more about that under +[Configuraton of item display](../design#configuraton-of-item-display). -## Snippet expansion - -Here a function for expanding snippets is defined. By default this is the builtin -`vim.snippet.expand()`. You can also use a plugin like luasnip for this like this: - -```lua -snippet_expansion = function(body) - require("luasnip").lsp_expand(body) -end -``` - -## Selection behavior - -With the selection behavior the user can determine what happens when selecting an entry. This can -either be `"select"` or `"insert"`. Selecting will just select the entry and do nothing else. Insert -will actually insert the text of the entry (this is not necessarily the whole text). - -## Keyword pattern - -Pattern used to determine keywords, used to determine what to use for filtering and what to -remove if insert text is used. - -## Completion events - -The `completion_events` table is used to set events for completion. By default it just contains -`"TextChangedI"`. You can set it to an empty table (`{}`) to disable autocompletion. - -## Sources - -TODO - -## Preselect - -Whether items should be preselected or not - -## Enabled - -This function can be used to disable care in certain contexts. By default this disables -care in prompts. - -# UI - -The ui configuration is used to configure the whole ui of care. One of the main goals of -this is to be as extensible as possible. This is especially important for the completion entries. -Read more about that under [Configuraton of item display](./design.md#configuraton-of-item-display). - -The most important part for many users will be the `menu` field. It's used to configure the -completion menu. +The most important part for many users will be the `menu` field. It's used to +configure the completion menu. You can also configure the documentation view just like the main menu. -Lastly the users can also configure the icons which will be used for the different items. +Lastly the users can also configure the icons which will be used for the +different items. ## Ghost text -with this option the user can determine if ghost text should be displayed. Ghost text is just -virtual text which shows a preview of the entry. +### Enabled -You can use the `enabled` field to determine whether the ghost text should be enabled or not. -The `position` can either be `"inline"` or `"overlay"`. Inline will add the text inline right -where the cursor is. With the overlay position the text will overlap with existing text after the -cursor. +You can use the `enabled` field to determine whether the ghost text should be +enabled or not. The `position` can either be `"inline"` or `"overlay"`. Inline +will add the text inline right where the cursor is. With the overlay position +the text will overlap with existing text after the cursor. ## Menu -This configuration should allow you to completely adapt the completion menu to your likings. +This configuration should allow you to completely adapt the completion menu to +your likings. -It includes some basic window properties like the border and the maximum height of the window. It -also has a field to define the character used for the scrollbar. -Set `scrollbar` to `nil` value to disable the scrollbar. +It includes some basic window properties like the border and the maximum height +of the window. It also has a field to define the character used for the +scrollbar. Set `scrollbar` to `nil` value to disable the scrollbar. ## Position If the menu should be displayed on top, bottom or automatically -Another field is `format_entry`. This is a function which recieves an entry of the completion -menu and determines how it's formatted. For that a table with text-highlight chunks like -`:h nvim_buf_set_extmarks()` is used. You can create sections which are represented by tables -and can have a different alignment each. This is specified with another field which takes a table -with the alignment of each section. +Another field is `format_entry`. This is a function which recieves an entry of +the completion menu and determines how it's formatted. For that a table with +text-highlight chunks like `:h nvim_buf_set_extmarks()` is used. You can create +sections which are represented by tables and can have a different alignment +each. This is specified with another field which takes a table with the +alignment of each section. -For example you want to have the label of an entry in a red highlight and an icon in a entry-kind -specific color left aligned first and then the source of the entry right aligned in blue. -You could do that like this: +For example you want to have the label of an entry in a red highlight and an +icon in a entry-kind specific color left aligned first and then the source of +the entry right aligned in blue. You could do that like this: ```lua format_entry = function(entry) @@ -113,18 +72,62 @@ end, alignment = { "left", "right" } ``` -Notice that there are multiple differences between having one table containing the chunks for the -label and kind and having them separately. The latter would require another entry in the `alignment` -table. It would also change the style of the menu because the left sides of the icons would be -aligned at the same column and not be next to the labels. In the example there also was some -spacing added in between the two. +Notice that there are multiple differences between having one table containing +the chunks for the label and kind and having them separately. The latter would +require another entry in the `alignment` table. It would also change the style +of the menu because the left sides of the icons would be aligned at the same +column and not be next to the labels. In the example there also was some spacing +added in between the two. ## Documentation view -This configuration allows you to configure the documentation view. -It consists of some basic window properties like the border and the maximum height of the window. -It also has a field to define the character used for the scrollbar. +This configuration allows you to configure the documentation view. It consists +of some basic window properties like the border and the maximum height of the +window. It also has a field to define the character used for the scrollbar. ## Type Icons This is a table which defines the different icons. + +## Snippet expansion + +Here a function for expanding snippets is defined. By default this is the +builtin `vim.snippet.expand()`. You can also use a plugin like luasnip for this +like this: + +```lua +snippet_expansion = function(body) + require("luasnip").lsp_expand(body) +end +``` + +## Selection behavior + +With the selection behavior the user can determine what happens when selecting +an entry. This can either be `"select"` or `"insert"`. Selecting will just +select the entry and do nothing else. Insert will actually insert the text of +the entry (this is not necessarily the whole text). + +## Keyword pattern + +Pattern used to determine keywords, used to determine what to use for filtering +and what to remove if insert text is used. + +## Completion events + +The `completion_events` table is used to set events for completion. By default +it just contains `"TextChangedI"`. You can set it to an empty table (`{}`) to +disable autocompletion. + +## Sources + +TODO + +## Preselect + +Whether items should be preselected or not + +## Enabled + +This function can be used to disable care in certain contexts. By default this +disables care in prompts. diff --git a/docs/design.md b/docs/design.md index 3069358..e27deef 100644 --- a/docs/design.md +++ b/docs/design.md @@ -10,20 +10,21 @@ categories: # General There is the [care.nvim](https://github.com/max397574/care.nvim) plugin. This is -the main module of the whole completion architecture. Then there are also sources, which is where -the core gets it's completions from. +the main module of the whole completion architecture. Then there are also +sources, which is where the core gets it's completions from. ## Care.nvim -This is the core of the autocompletion. From here the sources are used to get completions which -are then displayed in the [Completion Menu](#completion-menu) +This is the core of the autocompletion. From here the sources are used to get +completions which are then displayed in the [Completion Menu](#completion-menu) ### Completion Menu -The completion menu displays the current completions. -Features that it should have: +The completion menu displays the current completions. Features that it should +have: -- Completely customizable display for every entry (with **text-highlight chunks** like extmark-api) +- Completely customizable display for every entry (with **text-highlight + chunks** like extmark-api) - Customizable scrollbar - Customizable window properties - Border @@ -37,8 +38,8 @@ Features that it should have: ## Offset -Offset always describes the distance between e.g. the start of an entry from the beginning of the -line. +Offset always describes the distance between e.g. the start of an entry from the +beginning of the line. # Architecture @@ -49,12 +50,14 @@ autocompletion: 1. `TextChangedI` or `CursorMovedI` 2. get the context (line before, cursor position etc) 3. Check if context changed -4. Check if character was a trigger character or completion was triggered manually +4. Check if character was a trigger character or completion was triggered + manually 5. Depending on ^^ decide what to do _for every source_: - Get new completions 1. get completions from source based on context - sort completions - 1. Use characters found with `keyword_pattern` to fuzzy match and sort completions + 1. Use characters found with `keyword_pattern` to fuzzy match and sort + completions 6. Collect all the completions 7. Open menu to display thing 1. if there is a selected one: @@ -76,135 +79,108 @@ When completing (e.g. ``): ## Nvim-cmp -These days nvim-cmp is the most popular completion-engine for neovim. There are some mayor issues -me and also other people in the community have with cmp. +These days nvim-cmp is the most popular completion-engine for neovim. There are +some mayor issues me and also other people in the community have with cmp. ### Bad code/Documentation -The code of nvim-cmp is often quite unreadable. Sometimes this might be due to optimizations -and surely some of it has just grown historically. Also there are nearly no docs on how the -whole completion engine works. The api for new sources is quite unclear and far from optimal. -While this doesn't really matter to a user it definitely does to a potential contributor and -developers of sources. +The code of nvim-cmp is often quite unreadable. Sometimes this might be due to +optimizations and surely some of it has just grown historically. Also there are +nearly no docs on how the whole completion engine works. The api for new sources +is quite unclear and far from optimal. While this doesn't really matter to a +user it definitely does to a potential contributor and developers of sources. ### Legacy code/features -There are a lot of things which grew just historically. The author of nvim-cmp is -(understandable to a certain degree) afraid of making breaking changes and fixing them or just -doesn't think changes are necessary. +There are a lot of things which grew just historically. The author of nvim-cmp +is (understandable to a certain degree) afraid of making breaking changes and +fixing them or just doesn't think changes are necessary. #### Configuration of item display -One such example is the configuration of how items are displayed in the menu. This works with -a function `formatting` which takes a completion item and is allowed to return an item where -the three fields `menu`, `kind` and `abbr` and three more fields for highlights for those can -be set. So apart from the background and border color of the menu you're limited to have three -different fields and colors in your menu E.g. source name, kind name, kind icon and text isn't -possible. It's also not possible to have round or half blocks around icons because you don't -have enough colors. An example of an issue can be found [here](https://github.com/hrsh7th/nvim-cmp/issues/1599). -You also can't add padding wherever you want and you can't align the fields as you want. +One such example is the configuration of how items are displayed in the menu. +This works with a function `formatting` which takes a completion item and is +allowed to return an item where the three fields `menu`, `kind` and `abbr` and +three more fields for highlights for those can be set. So apart from the +background and border color of the menu you're limited to have three different +fields and colors in your menu E.g. source name, kind name, kind icon and text +isn't possible. It's also not possible to have round or half blocks around icons +because you don't have enough colors. An example of an issue can be found +[here](https://github.com/hrsh7th/nvim-cmp/issues/1599). You also can't add +padding wherever you want and you can't align the fields as you want. #### Legacy code -There is e.g. the whole "native menu" thing laying around in the codebase. Nowadays this isn't -really needed anymore. Everything of it can be accomplished with the "custom menu". There is a -lot of duplicate code because of that. +There is e.g. the whole "native menu" thing laying around in the codebase. +Nowadays this isn't really needed anymore. Everything of it can be accomplished +with the "custom menu". There is a lot of duplicate code because of that. ### Mapping system -The mapping system is quite confusing. It's a table in the config with keys to be mapped as keys -and a call to `cmp.mapping()` with a callback to the actual functionality as value. -Users should able to just use normal mappings or functions with `vim.keymap.set`. +The mapping system is quite confusing. It's a table in the config with keys to +be mapped as keys and a call to `cmp.mapping()` with a callback to the actual +functionality as value. Users should able to just use normal mappings or +functions with `vim.keymap.set`. ### Custom solutions for builtin functionality -An example for this is the [Mapping system](#mapping-system). Another example would be the `cmp.event.on` -which could just be done with User autocmds. +An example for this is the [Mapping system](#mapping-system). Another example +would be the `cmp.event.on` which could just be done with User autocmds. ### Why not contribute? -The maintainer is in general quite conservative. There were pull-requests for many features open -which were liked by the community (seen by reactions and comments). But they were abandoned -because the maintainer saw no reason to add it. There was for example a pull-request to fix the -issue with the limited fields in the configuration [here](https://github.com/hrsh7th/nvim-cmp/pull/1238). -This pull request was closed because _No specific use cases have emerged at this stage._ -according to the author. Even though there was clearly a problem described and what the pr would -allow (this pr allowed custom fields which still isn't nice but fixed the obvious problems). -There were also some features (in particular the custom scrollbars) removed because there were -some issues with it which apparently weren't worth fixing for the feature. -So it's not really motivating to try to contribute new things. It's also quite hard because of -the messy code with lots of legacy code. +The maintainer is in general quite conservative. There were pull-requests for +many features open which were liked by the community (seen by reactions and +comments). But they were abandoned because the maintainer saw no reason to add +it. There was for example a pull-request to fix the issue with the limited +fields in the configuration +[here](https://github.com/hrsh7th/nvim-cmp/pull/1238). This pull request was +closed because _No specific use cases have emerged at this stage._ according to +the author. Even though there was clearly a problem described and what the pr +would allow (this pr allowed custom fields which still isn't nice but fixed the +obvious problems). There were also some features (in particular the custom +scrollbars) removed because there were some issues with it which apparently +weren't worth fixing for the feature. So it's not really motivating to try to +contribute new things. It's also quite hard because of the messy code with lots +of legacy code. # Goals ## Use nvim-cmp sources -We should be able to use nvim-cmp sources. This should be possible by adding a `package.loaders` -where we can redirect calls to `cmp.register_source` (which happens in most sources auto- -matically) to our own plugin. We **don't want to adapt to cmp's apis** for this though. We won't -extend our own formats e.g. for entries or sources to match cmps. Even when it's complicated we -will just convert between the different formats. +We should be able to use nvim-cmp sources. This should be possible by adding a +`package.loaders` where we can redirect calls to `cmp.register_source` (which +happens in most sources auto- matically) to our own plugin. We **don't want to +adapt to cmp's apis** for this though. We won't extend our own formats e.g. for +entries or sources to match cmps. Even when it's complicated we will just +convert between the different formats. ## Native things -Use as many native things as possible. This includes setting mappings with `vim.keymap.set` or -add events as user autocmd events. +Use as many native things as possible. This includes setting mappings with +`vim.keymap.set` or add events as user autocmd events. # Non-Goals ## Different views -Nvim-cmp has different views. At the moment wild-menu, native menu and custom menu. There is a -lot of code duplication because of this. We'd like to avoid having multiple views. The native -one isn't needed anyway (it likely is just in cmp for historical reasons). -In the future we'd like to allow injecting custom views via config where you just get the -entries and do things with them yourself. This is mostly to avoid code duplication in core. +Nvim-cmp has different views. At the moment wild-menu, native menu and custom +menu. There is a lot of code duplication because of this. We'd like to avoid +having multiple views. The native one isn't needed anyway (it likely is just in +cmp for historical reasons). In the future we'd like to allow injecting custom +views via config where you just get the entries and do things with them +yourself. This is mostly to avoid code duplication in core. ## Commandline completion -At the moment no command line completion is planned. This is because the author thinks it's not -really needed because builtin completion is already quite good and there is little value added -by adding commandline completion. Also it doesn't really make sense in my opinion to combine -commandline completion and autocompletion for buffer contents in the same plugin. Especially if -you try to share things in between like nvim-cmp does. +At the moment no command line completion is planned. This is because the author +thinks it's not really needed because builtin completion is already quite good +and there is little value added by adding commandline completion. Also it +doesn't really make sense in my opinion to combine commandline completion and +autocompletion for buffer contents in the same plugin. Especially if you try to +share things in between like nvim-cmp does. # Types used -The types should minimally be the lsp things (for the context passed to source, for response and -for entries). Everything additionally is mostly optional. - -# Code style - -## Object-Orientation - -Most of the modules are written object oriented. This decision was made because it's way easier -to create new instances of the things and associate data with them. - -## Functions - -You should always write functions in the form of `[local] function ()` as -opposed to `[local = function()`. The first notation provides the advantage -that you can directly jump to it's definition and you won't get multiple results (the name and -the anonymous function). - -## Comments and annotations - -Add annotations to **every** public function of a module (e.g. with neogen) and add comments -explaining what the code does. We'd like to have code which would be understandable for outsiders. -Also try to add annotations and descriptions to local functions but this isn't as important as -public ones - -### Format - -For The annotations we use [LuaCATS](https://luals.github.io/wiki/annotations/) style. For types -don't use a space after the `---` marker. For comments you should. Check the annotations in -`lua/care/types/` for examples. - -## Types - -We have files for types which are tangled from a norg file (this one?) using lua-ls annotations. -They are prefixed with `care.`. -As often as possible we should try to use the `lsp.*` types which are in neovim core. - -The types are documented in the `docs/` folder and are tangled to lua type files with [neorg](https://github.com/nvim-neorg/neorg). -So if you want to change a type annotation you should change the `.norg` file and tangle it again. +The types should minimally be the lsp things (for the context passed to source, +for response and for entries). Everything additionally is mostly optional. diff --git a/docs/dev/code_style.md b/docs/dev/code_style.md new file mode 100644 index 0000000..959d3da --- /dev/null +++ b/docs/dev/code_style.md @@ -0,0 +1,42 @@ +# Code style + +## Object-Orientation + +Most of the modules are written object oriented. This decision was made because +it's way easier to create new instances of the things and associate data with +them. + +The tables of which the modules consist should be named with uppercase letters +(e.g. `Menu`). This should be done in the definition and when using them. +Instances should use lowercase letters. + +## Functions + +You should always write functions in the form of +`[local] function ()` as opposed to +`[local = function()`. The first notation provides the +advantage that you can directly jump to it's definition and you won't get +multiple results (the name and the anonymous function). + +## Comments and annotations + +Add annotations to **every** public function of a module (e.g. with neogen) and +add comments explaining what the code does. We'd like to have code which would +be understandable for outsiders. Also try to add annotations and descriptions to +local functions but this isn't as important as public ones + +### Format + +For The annotations we use [LuaCATS](https://luals.github.io/wiki/annotations/) +style. For types don't use a space after the `---` marker. For comments you +should. Check the annotations in `lua/care/types/` for examples. + +## Types + +We have files for types which are tangled from a norg file (this one?) using +lua-ls annotations. They are prefixed with `care.`. As often as possible we +should try to use the `lsp.*` types which are in neovim core. + +The types are documented in the `docs/` folder and are tangled to lua type files +with [neorg](https://github.com/nvim-neorg/neorg). So if you want to change a +type annotation you should change the `.norg` file and tangle it again. diff --git a/docs/dev/context.md b/docs/dev/context.md index 804eb1c..df01ebe 100644 --- a/docs/dev/context.md +++ b/docs/dev/context.md @@ -1,52 +1,71 @@ --- -title: Index -description: Type description of context -author: - - max397574 -categories: - - docs, - - types +title: Context +description: The context type in care.nvim --- -This is a class representing the current state. It includes buffer number and cursor position. It -is passed to completion sources to get completions. +# Context + +This is a class representing the current state. It includes buffer number and +cursor position. It is passed to completion sources to get completions. # Methods ## Changed -Whether the context changed in comparison to the previous one. This is used to check whether to -get new completions or not. +`context:changed(): boolean` + +Whether the context changed in comparison to the previous one. This is used to +check whether to get new completions or not when using autocompletion. ## New -Create a new context. This takes the previous one as argument. This one is stored to determine if -the context changed or not when completing. -The previous context of the previous one is deleted so this data structure doesn't grow really -large. +`Context.new(): care.context` + +Create a new context. This takes a previous context as argument. This one is +stored to determine if the context changed or not when completing. The previous +context of the previous one is deleted so this data structure doesn't grow +really large. # Fields ## Previous -The previous context which is used to determine whether the context changed or not. +`context.previous: care.context` + +The previous context which is used to determine whether the context changed or +not. The `previous` field of the previous context should always be `nil` so the +data structure doesn't grow infinitely. ## Cursor -The cursor positon. +`context.cursor: {row: integer, col: integer}` + +The cursor position. This will have a `col` and a `row` field and has 1-based +line and 0-based column indexes. This is the same as in +`nvim_win_{get, set}_cursor()` (`:h api-indexing`). ## Bufnr +`context.bufnr: integer` + Number of the buffer. ## Reason -Reason for triggering completion. +`context.reason: 1|2` + +Reason for triggering completion. This is a `completionReason` so either 1 for +automatic triggering and 2 for manual triggering. ## Current line -The current line. +`context.current_line: string` + +The complete line on which the cursor was when the context was created. ## Line before cursor -Part of the current line which is before the cursor. +`context.line_before_cursor: string` + +The line before the cursor. This is mostly important to be correct in insert +mode. In normal mode the character on which the cursor is is not included. diff --git a/docs/dev/core.md b/docs/dev/core.md index bc74668..cb28f13 100644 --- a/docs/dev/core.md +++ b/docs/dev/core.md @@ -1,63 +1,79 @@ --- title: Core -description: Type description of care.nvim source -author: - - max397574 -categories: - - docs, - - types +description: The core module in care.nvim --- -# General +# Core -This module is for the core of care. There all comes together with the menu being opened -and the completion triggered. +This module is for the core of care. Here everything comes together with the +most important things being the menu being opened and the completion triggered. + +# Methods ## New -Use this function to create a new instance. +`Core.new(): care.core` -# Methods +Use this function to create a new instance. It takes no arguments and should be +called only once when the plugin is first set up. ## Complete -This function starts the completion. It goes through all the sources, triggers them (completion -or sorting) and opens the menu with the result. +`core:complete(reason): nil` + +This function starts the completion. It goes through all the sources, triggers +them (completion and sorting) and opens the menu with the result. ## On Change -This function is invoked on every text change. It updates the context field and triggers -completion if it changed. +`core:on_change(): nil` + +This function is invoked on every text change (by default, see +`completion_events` in config). It updates the context field and triggers +completion if the context changed. ## Block -The `block` method can be used to temporarily disable care. It returns a function which is -used to unblock it again. -This is used for the `insert` selection behavior where you don't want to get new completions when -changing the text. +`core:block(): function` + +The `block` method can be used to temporarily disable care. It returns a +function which is used to unblock it again. This is used for the `insert` +selection behavior where you don't want to get new completions when changing the +text. ## Setup -The setup function is used to setup care so it will actually provide autocompletion when -typing by setting up an autocommand. +`core:setup(): nil` + +The setup function is used to setup care so it will actually provide +autocompletion when typing by setting up an autocommand with the +`completion_events` from the configuration. # Fields ## Context -This is used to store the current context. There is always a new one created in `on_change` and -compared to see if it changed. +`core.context: care.context` + +This is used to store the current context. There is always a new one created in +`on_change` and compared to see if it changed. ## Menu +`core.menu: care.menu` + In this field a menu instance which is used in core is stored. ## Blocked -This field is used by the [Block](#block) method. It just completely disables autocompletion when set -to true. +`core.blocked: boolean` + +This field is used by the [block()](#block) method. It just completely disables +autocompletion when set to true. ## Last opened at -This variable is used to determine where a new completion window was opened for the last time. -This is used to determine when to reopen the completion window. +`core.last_opened_at: integer` + +This variable is used to determine where a new completion window was opened for +the last time. This is used to determine when to reopen the completion window. diff --git a/docs/dev/index.md b/docs/dev/index.md new file mode 100644 index 0000000..923fb99 --- /dev/null +++ b/docs/dev/index.md @@ -0,0 +1,27 @@ +--- +title: Developers +description: Ressources to devlop care.nvim or sources for it +--- + +# Developer documentation + +This is the internal documentation of the care.nvim code base. It also includes +documentation for developing sources for care.nvim. + +If you want to contribute you should read the +[code style documentation](./code_style). + +## Conventions used + +For describing classes there is always a section for methods (functions) and one +for fields. The name and how to use the method/function is normally written +directly after the respective heading. Capital letters are used for accessing +the classes as lua modules (e.g. `Context.new`) and lowercase letters for +instances (e.g. `context.previous`). This should also be done in the codebase +like this. + +A `.` or `:` indicates if the function is a method or a function. It also has to +be used this way. + +After the `:` the return type of functions or the type of fields is indicated +(e.g. `context:changed(): bool`). diff --git a/docs/dev/menu.md b/docs/dev/menu.md index c9daa58..0779e11 100644 --- a/docs/dev/menu.md +++ b/docs/dev/menu.md @@ -1,25 +1,21 @@ --- title: Menu description: Type description of care.nvim menu -author: - - max397574 -categories: - - docs, - - types --- # General -This is the main class of the care completion menu. The menu is used to display completion -entries and also contains the logic for selecting and inserting the completions. +This is the main class of the care completion menu. The menu is used to display +completion entries and also contains the logic for selecting and inserting the +completions. # Internals ## Index -The index is used to determine the selected entry. It is used to get this entry when confirming -the completion. -The function to select the next and previous entries simply change this index. +The index is used to determine the selected entry. It is used to get this entry +when confirming the completion. The function to select the next and previous +entries simply change this index. # Methods @@ -29,28 +25,30 @@ Creates a new instance of the completion menu. ## Draw -Draws the menu. This includes formatting the entries with the function from the config and -setting the virtual text used to display the labels. It also adds the highlights for the selected -entry and for the matched chars. +Draws the menu. This includes formatting the entries with the function from the +config and setting the virtual text used to display the labels. It also adds the +highlights for the selected entry and for the matched chars. ## Is open -This is a function which can be used to determine whether the completion menu is open or not. -This is especially useful for mappings which have a fallback action when the menu isn't visible. +This is a function which can be used to determine whether the completion menu is +open or not. This is especially useful for mappings which have a fallback action +when the menu isn't visible. ## Select next -This function can be used to select the next entry. It accepts a count to skip over some entries. -It automatically wraps at the bottom and jumps up again. +This function can be used to select the next entry. It accepts a count to skip +over some entries. It automatically wraps at the bottom and jumps up again. ## Select prev -This function is used to select the previous entry analogous to [Select next](#select-next) +This function is used to select the previous entry analogous to +[Select next](#select-next) ## Open -The `open` function is used to open the completion menu with a specified set of entries. This -includes opening the window and displaying the text. +The `open` function is used to open the completion menu with a specified set of +entries. This includes opening the window and displaying the text. ## Close @@ -58,19 +56,20 @@ This function closes the menu and resets some internal things. ## Get active entry -With this function you can get the currently selected entry. This can be used for the docs view -or some other api functions. It is also used when the selection is confirmed. +With this function you can get the currently selected entry. This can be used +for the docs view or some other api functions. It is also used when the +selection is confirmed. ## Confirm -This is the function to trigger the completion with a selected entry. It gets the selected entry -closes the menu and completes. +This is the function to trigger the completion with a selected entry. It gets +the selected entry closes the menu and completes. ## Complete -This function completes with a given entry. That means it removes text used for filtering -(if necessary), expands snippet with the configured function, applies text edits and lsp -commands. +This function completes with a given entry. That means it removes text used for +filtering (if necessary), expands snippet with the configured function, applies +text edits and lsp commands. ## Readjust window @@ -108,18 +107,18 @@ In this field the user config is stored for easier access. ## Buffer -This is the buffer used for the menu. It's just created once when initially creating a new -instance. +This is the buffer used for the menu. It's just created once when initially +creating a new instance. ## Window -Window number of the window used to display the menu. This is always newly created when the menu -gets opened and is only set if the menu is open. +Window number of the window used to display the menu. This is always newly +created when the menu gets opened and is only set if the menu is open. ## Index -The index is used to get and track the currently selected item. It gets modified by the functions -to select next and previous entry. +The index is used to get and track the currently selected item. It gets modified +by the functions to select next and previous entry. ## Scrollbar Buffer diff --git a/docs/index.md b/docs/getting_started.md similarity index 100% rename from docs/index.md rename to docs/getting_started.md