# Rewriting/reorganising Kakoune's documentation **URL:** \ **Category:** Complaints & Improvements\ **Created:** [January 31, 2019, 7:16am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303 "2019-01-31T07:16:29Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Screwtapello](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/screwtapello/32/12_2.png) [@Screwtapello](https://discuss.kakoune.com/u/Screwtapello)\ **Post date:** [January 31, 2019, 7:16am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/1 "2019-01-31T07:16:29Z")
Kakoune has generally good documentation, and pretty much everything you need to know to use Kakoune interactively and write scripts is in there somewhere, but sometimes it can be hard to _find_ the thing you want to know, or even to discover that it exists in the first place. For example, the `commands` page documents _most_ commands, except for things like `execute-keys`, `evaluate-commands`, `hook`, and `map`, which have their own pages, except for `exec` and `eval` which share a page. None of those pages actually talk about how command arguments work, though - that’s `command-parsing`. `command-parsing` mentions expansions, but doesn’t go into detail since the `expansions` page is all about them, although it mentions parsing in return. Just today somebody made a PR adding a bunch of details to the `expansions` page, and when I pointed out that it duplicated some of the information in the `command-parsing` page, they said: > I didn’t realize the `command-parsing` page contained that (I don’t think I’ve ever actually read it to be honest). The information [in this PR] is what I though was missing from `expansions` (and ended up learning from looking at the source code). It seems to me that Kakoune’s documentation has grown organically, with things being added and amended over time as Kakoune has added and changed features, but without much attention to the larger structure. So: - does anybody else agree that it can be difficult to find things in Kakoune’s documentation? - would anybody else like to see the documentation reorganised? - is anybody willing to contribute _financially_ to reorganising the documentation? If nobody has a problem with the state of Kakoune’s documentation, then fair enough. On the other hand, if there’s consensus that Somebody Should Do Something, I’ll start thinking about what a reorganisation might look like, when I can find the time. After all, I’ve [already contributed to Kakoune’s documentation](https://github.com/mawww/kakoune/commits/master/doc/pages?author=Screwtapello), and I’ve written [long-form documentation](https://higan.readthedocs.io/en/stable/) before. If people are willing to contribute financially, I’m willing to _make_ the time. ---
**Author:** ![JJK96](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/jjk96/32/305_2.png) [@JJK96](https://discuss.kakoune.com/u/JJK96)\ **Post date:** [January 31, 2019, 9:36am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/2 "2019-01-31T09:36:56Z")
When I first started Kakoune I just browsed through all doc pages, so now I know where to find stuff. I usually do that if I find a new tool. Maybe some improvement is needed, but I would say that interconnecting the pages a bit more, like refer to the `execute-keys` , `evaluate-commands` , `hook` , and `map` pages from the `commands` page, would be a simple step to make it clearer. ---
**Author:** ![occivink](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/occivink/32/27_2.png) [@occivink](https://discuss.kakoune.com/u/occivink)\ **Post date:** [January 31, 2019, 12:55pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/3 "2019-01-31T12:55:57Z")
I think the overall organization of the pages is satisfactory, except when it comes to command-parsing, execeval and expansions. The list of values in “expansions” should be moved to a “values” page, similar to options and registers. This page would simply explain the available values and their type “command parsing” should be renamed to “strings” since it’s really what it’s all about. It would document how all the string types work and what are their usecases. Then “expansions” should just explain what the various %…{} expand to and in which context, and link to options/registers/values. Expansion and string could be merged into one page since the two topics are essentially interlinked edit: just saw the part about financial contribution only now, I’m willing to do it ---
**Author:** ![andreyorst](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/andreyorst/32/29_2.png) [@andreyorst](https://discuss.kakoune.com/u/andreyorst)\ **Post date:** [January 31, 2019, 3:02pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/4 "2019-01-31T15:02:31Z")
Same here. But I would like to have ability to search over doc in a way how Vim does it. Vim has best doc system in my opinion. ---
**Author:** ![schickm](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/schickm/32/79_2.png) [@schickm](https://discuss.kakoune.com/u/schickm)\ **Post date:** [February 2, 2019, 5:39pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/5 "2019-02-02T17:39:39Z")
I’ve definitely found myself wondering about the organization of the docs pages. Reorganizing all the docs would be a worthy effort, but maybe an intermediate solution - create an “index” page and have `:docs` with no arguments start there. It would serve as the top level documentation page that lists all of the current documentation pages, and short blurbs about what they cover. Once those blurbs are written, I think it’d become pretty clear where the overlaps are, or what pages need to be merged. I realized I’m talking about creating a documentation page for documentation pages - more things to maintain - but it might be a lower effort means of making the existing docs more accessible to newer user’s who don’t know where to begin. Additionally, while the autocomplete listing of docs are nice, it’s not the most accessible for folks who don’t even know what things like “expansions” means. ---
**Author:** ![Screwtapello](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/screwtapello/32/12_2.png) [@Screwtapello](https://discuss.kakoune.com/u/Screwtapello)\ **Post date:** [February 5, 2019, 5:24am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/6 "2019-02-05T05:24:44Z")
> [@occivink](#): > > The list of values in “expansions” should be moved to a “values” page, similar to options and registers. This page would simply explain the available values and their type > “command parsing” should be renamed to “strings” since it’s really what it’s all about. It would document how all the string types work and what are their usecases. I like this plan. If you don’t have time to try it out in the near future, I might give it a shot. > [@andreyorst](#): > > But I would like to have ability to search over doc in a way how Vim does it. Vim has best doc system in my opinion. Yeah, that’d be great. Of course, one reason Vim’s documentation is great is because they use a custom syntax with different markup for different cross references - so `:foo` is always a command, `'foo'` is always a runtime option, `+foo` is always a compile-time option, and `*foo*` is a generic cross-reference. All that stuff is picked up by Vim’s documentation-indexer. Kakoune uses Asciidoc syntax, which isn’t quite as convenient. As [best I can tell](https://powerman.name/doc/asciidoc#_macros_links_images_amp_include), the syntax for making something a cross-reference anchor is `[[like-this]]`, or even worse, `anchor:like-this[]`. That means Kakoune’s internal AsciiDoc renderer would need to filter out that text, and _that_ means that jumping to a particular anchor gets more complex because you have to load the buffer and do the jump _before_ it gets reformatted. It should be possible, but it feels like it would be a lot of work. > [@schickm](#): > > Reorganizing all the docs would be a worthy effort, but maybe an intermediate solution - create an “index” page and have `:docs` with no arguments start there. That would be rather nice. It’d also be a good place to document features like “you can hit Enter on a cross reference to follow the link”. ---
**Author:** ![andreyorst](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/andreyorst/32/29_2.png) [@andreyorst](https://discuss.kakoune.com/u/andreyorst)\ **Post date:** [February 5, 2019, 6:06am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/7 "2019-02-05T06:06:09Z")
> [@Screwtapello](#): > > Yeah, that’d be great. Of course, one reason Vim’s documentation is great is because they use a custom syntax with different markup for different cross references - so `:foo` is always a command, `'foo'` is always a runtime option, `+foo` is always a compile-time option, and `*foo*` is a generic cross-reference. All that stuff is picked up by Vim’s documentation-indexer. > > Kakoune uses Asciidoc syntax, which isn’t quite as convenient. As [best I can tell](https://powerman.name/doc/asciidoc#_macros_links_images_amp_include), the syntax for making something a cross-reference anchor is `[[like-this]]` , or even worse, `anchor:like-this[]` . That means Kakoune’s internal AsciiDoc renderer would need to filter out that text, and _that_ means that jumping to a particular anchor gets more complex because you have to load the buffer and do the jump _before_ it gets reformatted. Vim uses tags for navigating in documentation. It generates ctags compatible tags per doc file, and later these tags are used in documentation for jumping. What is really cool is that Kakoune uses asciidoc, and ctags can uderstand asciidoc. And Kakoune understands ctags ([ahem](https://github.com/mawww/kakoune/pull/2625)), so I wonder if Kakoune could utilize ctags for better navigation in docs. Basically we have everything we need for that. ---
**Author:** ![Screwtapello](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/screwtapello/32/12_2.png) [@Screwtapello](https://discuss.kakoune.com/u/Screwtapello)\ **Post date:** [February 5, 2019, 8:03am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/8 "2019-02-05T08:03:03Z")
POSIX only requires ctags to support C and Fortran, and even Exuberant Ctags [doesn’t support AsciiDoc](http://ctags.sourceforge.net/languages.html). Universal Ctags [apparently does](https://github.com/universal-ctags/ctags/pull/1838), although it’s [not listed in the docs](http://docs.ctags.io/en/latest/parsers.html). Meanwhile, although Kakoune understands ctags, “[This script requires the readtags command available in ctags source but not installed by default](https://github.com/mawww/kakoune/blob/master/rc/base/ctags.kak#L3)”. While Kakoune depends on these third-party tools for good reasons, I don’t think it’s a good idea to have Kakoune’s built-in documentation system require them. Generally, Kakoune’s basic functionality requires only standard POSIX tools. The ctags format is simple enough that we could probably write our own indexer, and the resulting tags file should be small enough that industrial-strength `readtags` isn’t needed for good performance, but we’d still have the problems of updating Kakoune’s AsciiDoc renderer, and making sure that looking up a tag jumps to the right spot before formatting is applied. ---
**Author:** ![andreyorst](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/andreyorst/32/29_2.png) [@andreyorst](https://discuss.kakoune.com/u/andreyorst)\ **Post date:** [February 5, 2019, 8:31am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/9 "2019-02-05T08:31:08Z")
> [@Screwtapello](#): > > While Kakoune depends on these third-party tools for good reasons, I don’t think it’s a good idea to have Kakoune’s built-in documentation system require them. Generally, Kakoune’s basic functionality requires only standard POSIX tools. Well, ctags support of asciidoc isn’t really needed in this case - tag files can be generated by kakoune itself, and for parsing we basically need a tool that can do regex search over file, such as `awk` or `grep`, which fits POSIX requirements. > [@Screwtapello](#): > > The ctags format is simple enough that we could probably write our own indexer, and the resulting tags file should be small enough that industrial-strength `readtags` isn’t needed for good performance True. I was astonished when I’ve compared readtags with grep performance on 607MiB file (4 million lines) - it is in order of magnitude faster compared to grep. But this difference isn’t so great for small files, and I suppose documentation tags will be relatively small. > [@Screwtapello](#): > > Meanwhile, although Kakoune understands ctags, “[This script requires the readtags command available in ctags source but not installed by default](https://github.com/mawww/kakoune/blob/master/rc/base/ctags.kak#L3)”. I also think that this requirement can be wrapped by using posix tools combination in case `readtags` isn’t installed but that’s another topic. ---
**Author:** ![robertmeta](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/robertmeta/32/833_2.png) [@robertmeta](https://discuss.kakoune.com/u/robertmeta)\ **Post date:** [February 6, 2019, 12:44am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/10 "2019-02-06T00:44:06Z")
> [@Screwtapello](#): > > - does anybody else agree that it can be difficult to find things in Kakoune’s documentation? > - would anybody else like to see the documentation reorganised? > - is anybody willing to contribute _financially_ to reorganising the documentation? > - does anybody else agree that it can be difficult to find things in Kakoune’s documentation? Exceptionally hard, and documentation is the lifeblood of a long-lived editor. > - would anybody else like to see the documentation reorganised? Yes, not even that picky about how – I feel most reworks would be an improvement. > - is anybody willing to contribute _financially_ to reorganising the documentation? If it ended with inline, searchable, referable documentation, absolutely. My question is simply, what would it cost: just to an order of magnitude? You could start a bountysource today if @mawww basically pre-agreed to merge the result (with obviously some information on where it was going). ---
**Author:** ![mawww](https://discuss.kakoune.com/letter_avatar_proxy/v4/letter/m/4bbf92/32.png) [@mawww](https://discuss.kakoune.com/u/mawww)\ **Post date:** [February 6, 2019, 3:43am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/11 "2019-02-06T03:43:11Z")
> [@andreyorst](#): > > True. I was astonished when I’ve compared readtags with grep performance on 607MiB file (4 million lines) - it is in order of magnitude faster compared to grep. But this difference isn’t so great for small files, and I suppose documentation tags will be relatively small. This is because readtags can do a binary search if the tags file is sorted, which is why Kakoune relies on readtags in the first place instead of grep its way through the tags. More generally, we already support cross references in the documention (just hit enter on the links), we also have a rudimentary index system through the `:doc` command auto completion. I guess this could be expanded to support additional syntax, say `:doc :command-name` for prompt commands (with auto completion, as soon as you type `:doc :` the completion shows all commands in the documentation pages, same if you type `:doc ` to get a key documentation, and we just need to find a syntax for options…). I am pretty proud that `doc.kak` provides the current system in only 165 lines of kak script (rendering a subset of asciidoc included), we have a bit of room to improve it before it becomes horribly complex. As to the general organization of the pages, this grew up in an organic fashion, so I am all for a good rationalization of all that. All that to say, I believe we are not that far from a good help system, we need to reorganize and cleanup the pages, and add a few features to the doc command completion system so that we can easily search for a command, key or option. ---
**Author:** ![Screwtapello](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/screwtapello/32/12_2.png) [@Screwtapello](https://discuss.kakoune.com/u/Screwtapello)\ **Post date:** [February 7, 2019, 6:02am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/12 "2019-02-07T06:02:29Z")
> [@andreyorst](#): > > Well, ctags support of asciidoc isn’t really needed in this case - tag files can be generated by kakoune itself, and for parsing we basically need a tool that can do regex search over file, such as `awk` or `grep` , which fits POSIX requirements. Yeah, it should be easy enough to write a ctags-compatible indexer, and a custom lookup tool, but it does mean that Kakoune’s existing ctags support isn’t much help. > [@robertmeta](#): > > My question is simply, what would it cost: just to an order of magnitude? You could start a bountysource today if @mawww basically pre-agreed to merge the result (with obviously some information on where it was going). I originally mentioned financial support because I’ve done documentation writing before and felt pretty confident I could bang something out. Since that time, however, I’ve been convinced by @occivink’s description of how the docs could be reorganised without a full rewrite, and the general tone here seems to be that searchability is a more pressing need. I’m a lot less confident about my ability to build a documentation searching system in Kakoune-script, so I don’t really want to take people’s money when I might not have anything to show for it at the end. ---
**Author:** ![andreyorst](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/andreyorst/32/29_2.png) [@andreyorst](https://discuss.kakoune.com/u/andreyorst)\ **Post date:** [February 7, 2019, 9:59am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/13 "2019-02-07T09:59:22Z")
> [@Screwtapello](#): > > but it does mean that Kakoune’s existing ctags support isn’t much help. Why it is so? The only change needed for current implementation to work with documentation tags (provided by some indexer) is to replace readtags with grep or awk, in case readtags isn’t installed. The rest could be used as is. ---
**Author:** ![duncan](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/duncan/32/95_2.png) [@duncan](https://discuss.kakoune.com/u/duncan)\ **Post date:** [February 23, 2019, 4:11pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/14 "2019-02-23T16:11:43Z")
Hi all, I know this problem not as a programmer but a report writer. Over the past five years I have constructed 47 reports which equates to over 110,000 words using mainly tex/latex to pdf and MSWord/MacTeX/TexWorks as editors. Which are all no longer in the tool chain thanks to your efforts on the Kakoune modal editing, done right. My problems are exactly the same as described in this thread. With multiple documents poor cross-referencing with duplication of attempts to find subject matter dependant on the day/month/year. I am currently believe that my solution lies with scribble not as a racket documentation tool but as a preprocessor for a PMBOK (\<- make mum proud moment). I am still in my first steps of scribble and will be continuing my education this semester with more reports giving greater opportunity to grasp scribble. Thought it was worth mentioning as a tool in this discussion thread and with your programming experience determining if it provides a solution for Kakoune documentation. Whatever the out come is what’s one more report, sign me up. Happy to help on the Kakoune documentation. I am a part-time programmer with just three years’ experience. Make that two years, damn you, Haskell. This would be my first experience contributing to an open source project so training wheels are tightly secure, with git man page on hotkey. Obligatory links below: [srcibble](https://docs.racket-lang.org/scribble/index.html) [scribble/bnf](https://docs.racket-lang.org/scribble/bnf.html) [BNF Grammer examples](http://www.cs.utsa.edu/~wagner/CS3723/grammar/examples2.html) [scribble/xref](https://docs.racket-lang.org/scribble/xref.html) The reference below is an overview of the tool chain: mouse event on the heading ‘6.1.2 Layer Roadmap’ to see section link. (\<- mum that means click the mouse button.) Flatt M, & Barzilay, E 2019, _Scribble: The Racket Documentation Tool_, Racket documentation series, v7.2, viewed 24 Feburary 2019, [https://docs.racket-lang.org/scribble/layers.html#(part.\_.Layer\_.Roadmap)](https://docs.racket-lang.org/scribble/layers.html#%28part._.Layer_.Roadmap%29). ---
**Author:** ![robertmeta](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/robertmeta/32/833_2.png) [@robertmeta](https://discuss.kakoune.com/u/robertmeta)\ **Post date:** [February 27, 2019, 7:07pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/15 "2019-02-27T19:07:22Z")
The bar for me is fairly low. I want to be able to do `:h def` or `:doc def` or something similar. ---
**Author:** ![duncan](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/duncan/32/95_2.png) [@duncan](https://discuss.kakoune.com/u/duncan)\ **Post date:** [March 2, 2019, 4:19pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/16 "2019-03-02T16:19:36Z")
> [@Screwtapello](#): > > is anybody willing to contribute _financially_ to reorganising the documentation? You raise a good point @Screwtapello, I would like to donate to a collaborative expense that promotes the usability of Kakoune. I’m investing a considerable amount of time with the editor and finding myself with a list of features that I’m unable to quickly implement. Has there been any discussion on financially backing Kakoune and community-driven features? I currently support [Polar-Bookshelf](https://opencollective.com/polar-bookshelf) on [Open Collective](https://opencollective.com) which promotes open source projects and would subscribe monthly to Kakoune development. If you’re unfamiliar with the site: “[Open Collective](https://opencollective.com/discover) is an online funding platform for open and transparent communities. We provide the tools to raise money and share your finances in full transparency.” Yes, the site is open source with a [github repo](https://github.com/opencollective). [Asciidoctor](https://opencollective.com/asciidoctor) is a good example on open-collective that everyone can relate to with the use of asciidocs for Kakoune documentation. @robertmeta yes the sentiment of documentation as a secondary concern is widespread. This can be seen on thousands of github readme.md landing pages and with no considerable investment coming from Github (or a competitor) to inspire design. A user’s first experience with your hard work is the bland flat and unimaginative dull landscape of markdown in either light or dark grey and now continuously looping gifs. Sorry, bit of a rant and I too prefer reading an applications documentation inside the environment or pdf. ---
**Author:** ![Delapouite](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/delapouite/32/10_2.png) [@Delapouite](https://discuss.kakoune.com/u/Delapouite)\ **Post date:** [October 1, 2020, 3:15pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/17 "2020-10-01T15:15:28Z")
@Screwtapello congrats! The PR about searching in plugins doc is now merged [https://github.com/mawww/kakoune/pull/3704](https://github.com/mawww/kakoune/pull/3704) Do you mind recapping what the impact on plugins authors who want to benefit from this new feature? Thanks ---
**Author:** ![Screwtapello](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/screwtapello/32/12_2.png) [@Screwtapello](https://discuss.kakoune.com/u/Screwtapello)\ **Post date:** [October 2, 2020, 4:51pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/18 "2020-10-02T16:51:38Z")
The thirty-second summary: If you include a file with the `.asciidoc` extension in your plugin, Kakoune’s `:doc` command can now find it and display it just like all the built-in documentation. The standard `autorestore` and `lint` plugins now have very basic documentation which you can browse with `:doc autorestore` and `:doc lint`. `:doc` itself now has documentation too - you can display it with `:doc doc`, but maybe one day it will be updated to display that documentation with bare `:doc`, instead of displaying an error. I wrote a lot more [on the wiki](https://github.com/mawww/kakoune/wiki/Documenting-Plugins) about what kind of documentation plugins should have and where to put it, but this is definitely not a command or requirement — it’s helpful to have some basic conventions to start with, but I’m sure they’ll shift over time as new plugin authors copy whatever popular plugin authors do. ---
**Author:** ![Delapouite](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/delapouite/32/10_2.png) [@Delapouite](https://discuss.kakoune.com/u/Delapouite)\ **Post date:** [October 4, 2020, 10:38am UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/19 "2020-10-04T10:38:06Z")
Thanks a lot for your explanations. The new `doc.kak` now searches inside the `/autoload` directory which is definitely the way to go. Unfortunately, for situations where plugins are handled by `plug.kak`, the `/plugins` directory is voluntarily managed independently for the classical autoloading system, meaning that `.asciidoc` inside it are not found. I don’t expect this exotic directory scanning to be handled by Kakoune itself, but does anyone has an elegant solution in mind that could be patched on `plug.kak`? Thanks! ---
**Author:** ![alexherbo2](https://discuss.kakoune.com/user_avatar/discuss.kakoune.com/alexherbo2/32/1140_2.png) [@alexherbo2](https://discuss.kakoune.com/u/alexherbo2)\ **Post date:** [October 4, 2020, 1:54pm UTC](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303/20 "2020-10-04T13:54:00Z")
@Delapouite I feel that with the autoload and built-in module system that plug.kak is not necessary to have a declarative kakrc now. A `doc_search_paths` option could be added to allow plugins to register their path. [`doc.kak`](https://github.com/mawww/kakoune/blob/master/rc/tools/doc.kak) ```auto declare-option -docstring 'Search paths for the documentation' str-list doc_search_paths "%val{config}/autoload" "%val{runtime}/doc" "%val{runtime}/rc" define-command doc -params 1..2 -shell-script-candidates %{ eval "set -- $kak_quoted_opt_doc_search_paths" ... find -L "$@" ... } %{ ... } ``` `plug.kak` ```auto set-option -add global doc_search_paths "%val{config}/plugins" ``` [Next page](https://discuss.kakoune.com/t/rewriting-reorganising-kakounes-documentation/303.md?page=2)