Re: Completions Registry

[Karthik Chikmagalur <karthikchikmagalur@gmail.com>]

>> Not just a problem for dslide but for org in general, any time a
>> package adds keys to configure blocks or properties, these do not
>> complete except through dabbrev etc.
>> ...
>
> I am sorry, but it is not clear for me from your email what concrete
> improvement you want to see.
>
> There are indeed sub-optimal historical decisions that could be improved
> in the hindsight, but we are not going to remove the existing conventions.

Maybe we can use this as a jump-off point to decide on a convention for
libraries to supply keyword/special-property/babel-header-args
documentation via Elisp?  i.e. a Completions Registry.

As discussed in the last Org meetup, I would like to write a CAPF that
provides completions and annotations when typing in keywords provided by
(loaded) Org libraries.  The annotations providing inline documentation
require this information to be available in the Elisp file.

My understanding is that babel header-args are available in defvars like

    (defvar org-babel-header-args:sqlite
      '((db        . :any)
        (header    . :any)
        (echo      . :any)
        (bail      . :any)
        (csv       . :any)
        (column    . :any)
        (html      . :any)
        (line      . :any)
        (list      . :any)
        (separator . :any)
        (nullvalue . :any)
        (readonly-p . ((yes no))))
      "Sqlite specific header args.")
      
and that the documentation for these cannot be included in the same
variable as the cons-cell structure and the :any symbols have special
meanings.

Karthik