emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] ol.el: Restore complete by description for insert link
Date: Sun, 11 Sep 2022 05:19:09 +1000	[thread overview]
Message-ID: <86r10jdnzv.fsf@gmail.com> (raw)
In-Reply-To: <tfhqvm$qlf$1@ciao.gmane.io>


Max Nikulin <manikulin@gmail.com> writes:

> On 06/09/2022 21:34, Max Nikulin wrote:
>> Does anyone have an idea why it was necessary to drop completion of stored links based
>> on their description for the sake of ido?
>
> I have no idea what is the proper way to enable ido for `org-insert-link'. Functions and
> variables specific to ido were removed from Org.
> (ido-everywhere) and (ido-mode) are not enough.
>
> I tried
>
>     (setq-local completing-read-function #'ido-completing-read)
>
> and the command broke completing read completely.
>
>     (add-function :override completing-read-function #'ido-completing-read)
>
> inspired by `ido-everywhere' code broke M-x, but it enabled ido for `org-insert-link'.
>
> I believe that descriptions as completion options were removed because ido signals an
> error when nil is passed inside completion list. I consider it as a bug in ido (at least
> in Emacs-27), but even when `completing-read-default' is used, it causes appearance of
> undesired "nil" option. No description is a frequent case for links.
>
> So I am attaching a patch to restore completion of link targets by their description, nil
> descriptions are filtered out.
>
> The change is caused by the auto-desc local variable in `org-insert-link', its usage is
> rather strange and confusing currently.   Despite with this patch descriptions are
> restored, I believe that logic related to auto-desc should be removed, anyway it was
> broken for 10 years. I am unsure in which thread the next change should be discussed.
>
>> P.S. My question is related to the following threads:
>> - Carlos Pita. Adding target and custom id links doesn't ask for description. Tue, 2 Aug
>> 2022 14:44:58
>> -0300. https://list.orgmode.org/D99A712C-18D1-4A4F-8093-35A0BFB469C4@gmail.com
>> - Max Nikulin. Re: Bug: org-store-link uses CUSTOM_ID instead of target point. Sat, 6
>> Nov 2021 19:51:29
>> +0700. https://list.orgmode.org/e2c807a7-1924-6f08-9e63-4f70aee9d3b5@gmail.com
>
> [2. text/x-patch; 0001-ol.el-Restore-complete-by-description-for-insert-lin.patch]...

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

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 think there has been a fair bit of work in this area in recent
versions of Emacs (i.e. Emacs 28). I also quite like packages like
vertico, corfu and embark because unlike other frameworks, they work
hard to be based on just core Emacs features/functionality and avoid
adding new libraries or re-implementing existing functionality in a new
library. THis tends to make the smaller and with better core Emacs
compatibility (main reason I don't like helm and to a lesser extent,
ivy). 


  reply	other threads:[~2022-09-10 19:33 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 [this message]
2022-09-11 12:02     ` Ihor Radchenko
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:
  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=86r10jdnzv.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --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).