emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] ol.el: Restore complete by description for insert link
Date: Sun, 11 Sep 2022 20:02:45 +0800	[thread overview]
Message-ID: <87k06aw23e.fsf@localhost> (raw)
In-Reply-To: <86r10jdnzv.fsf@gmail.com>

Tim Cross <theophilusx@gmail.com> writes:

> You don't appear to be getting a lot of feedback on this. However, I
> think it is important work your doing. I suspect the lack of feedback is
> partially due to Emacs' completion infrastructure being somewhat
> confusing, combined with references to ido, which I suspect is one of
> the less popular completion frameworks these days. .

Not necessarily Emacs infrastructure. Org completion functions are
fairly confusing as well, which makes it difficult to provide
constructive feedback. We should really work towards (1) documenting the
expected features in Org completion functions; (2) unifying and
de-duplicating completion code across Org, like in

> My take on this, which might be completely wrong, is that org-mode
> should not cater for or support any specific completion
> framework. Things like ido, icomplete, fido, vertico, corfu, et. al. are
> something which should be supported in a generic and abstract manner
> i.e. we just provide minimal necessary code to generate the candidates
> these systems use. From your description, I think this is what your
> doing. Perhaps the requirements might become clearer if you also tried
> other completion frameworks, like fido, icomplete and vertico.

I'd say that we may still do it. At least, for the most common completion
frameworks. However, we should do everything to reduce the maintenance
overheads of such support.

If some non-standard completion framework offer extra functionality
compared to built-in, we can provide Org's framework that extends
completion-read to support the extra functionality.

What I have in mind is something like

(org-completing-read normal-args extra-args)

with extra-args only playing out when more featureful completion
framework is active.

However, it is critical not to require the normal Org code to account
for non-standard frameworks. All the frameword-specific handling should
be done in a separate localized function/library.

Feel free to refute.

Ihor Radchenko,
Org mode contributor,
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

  reply	other threads:[~2022-09-11 12:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 14:34 ido, org-insert-link, and completion based on link description Max Nikulin
2022-09-10 11:04 ` [PATCH] ol.el: Restore complete by description for insert link Max Nikulin
2022-09-10 19:19   ` Tim Cross
2022-09-11 12:02     ` Ihor Radchenko [this message]
2022-09-11 11:48   ` Ihor Radchenko

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:

  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=87k06aw23e.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=theophilusx@gmail.com \


* 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


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