Completions Registry

Completions Registry

[Psionic K]

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.

The keys are likely not already in documents.  The only way I can
reason to make them visible is to provide functions to register
various completions and then let completion backends pick up on these.
Some keys may even have completions for the allowable values.  The
values may be dynamic.

Language server features are one path to wiring these into org mode
without org mode and completion backends doing work.  It would be
generally good for the ecosystem.

However the problem will remain, how can we find the keys?  Even if
Emacs has a  conversation with a language server, someone will have to
answer regarding what completions exist.

I haven't really looked into the language server implementation, but
if not a tree sitter grammar for parsing, the decisions around inline
markup etc are critical to making progress.

I haven't been a fan of the `#+attr' requirement on affiliated
keywords nor the inconsistency about not applying these for headlines.
While it may be ambiguous if keywords apply to immediately following
elements or the document, I don't see an issue with applying to both
when there is an ambiguity.

I'm not sure what the conversation around inline markup looks like,
but I'm in favor of any remote definition solution like footnotes
where we mark the inline region or object and then fill in the details
somewhere else.  Inline escaping rules and general ugliness are not my
preference.

Some set of decisions and tree sitter grammar would enable org to make
use of the tree sitter tools for parsing, probably good for org
element and font locking both.  Everyone knows that.  Just my +1.

Re: Completions Registry

[Ihor Radchenko]

Psionic K <psionik@positron.solutions> writes:

> 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.

> Some set of decisions and tree sitter grammar would enable org to make
> use of the tree sitter tools for parsing, probably good for org
> element and font locking both.  Everyone knows that.  Just my +1.

It is too much for Org mode maintainers to provide an official grammar.
Mostly because it will require knowledge of JS/C (basically, non-Elisp
languages). I am highly skeptical that we can reliably find people who
can regularly contribute if Org becomes multi-programming language
project.

The official parser will thus remain written in Elisp.

I am, however, in favor of making things easier for people to implement
tree-sitter grammar, if anything can be done to help this from Org side
without actually having to write and maintain that grammar.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Completions Registry

[Psionic K]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

Sorry, my initial thoughts are too far ranging.

More directly, how can I inject extra values into `org-special-properties'
or elsewhere so that they appear when completing `org-set-property'?
Applications that use non-standard properties don't have a way AFIAK to
inform these completions.

[-- Attachment #2: Type: text/html, Size: 380 bytes --]

Re: Completions Registry

[Ihor Radchenko]

Psionic K <psionik@positron.solutions> writes:

> More directly, how can I inject extra values into `org-special-properties'
> or elsewhere so that they appear when completing `org-set-property'?
> Applications that use non-standard properties don't have a way AFIAK to
> inform these completions.

org-default-properties

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Completions Registry

[Karthik Chikmagalur]

>> 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