From: Psionic K <psionik@positron.solutions>
To: emacs-orgmode@gnu.org
Subject: Completions Registry
Date: Thu, 12 Dec 2024 12:15:06 +0900 [thread overview]
Message-ID: <CADQMGAQkAh0ApLW39VwOys-NdtcmvikbZX-T3+ozY53g5FG=1A@mail.gmail.com> (raw)
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.
reply other threads:[~2024-12-12 3:16 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADQMGAQkAh0ApLW39VwOys-NdtcmvikbZX-T3+ozY53g5FG=1A@mail.gmail.com' \
--to=psionik@positron.solutions \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).