is it possible to choose a completion engine?

is it possible to choose a completion engine?

[Tory S. Anderson]

Org currently stands out from my workflow because it does completions its own way, with lists and number/letter keys. It would be nice if I could instead have the benefit of vertico, or helm, or whatever else instead. Org would even benefit from marginalia and embark in some cases. Is there an easy variable I'm missing to make org use completing-reads instead of the indexing thing it does?

Thanks!
- Tory

Re: is it possible to choose a completion engine?

[Ihor Radchenko]

webdev@toryanderson.com (Tory S. Anderson) writes:

> Org currently stands out from my workflow because it does completions its own way, with lists and number/letter keys. It would be nice if I could instead have the benefit of vertico, or helm, or whatever else instead. Org would even benefit from marginalia and embark in some cases. Is there an easy variable I'm missing to make org use completing-reads instead of the indexing thing it does?

This is because you customized your tags/todo keywords to have a quick
key binding to set. By default, Org uses custom "fast" interface for
completion in such cases. You can either remove the bindings to
explicitly set `org-use-fast-tag-selection' and/or
`org-use-fast-todo-selection' to nil.

-- 
Ihor Radchenko // yantar92,
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>

Re: is it possible to choose a completion engine?

[Samuel Wales]

i guess menu selection is a kind of completion and frameworks coud be
used also.  a big thing for me that works with ido and ido-hacks and
ido-clever-match is olpath completion for refile-goto and refile.


On 5/22/23, Ihor Radchenko <yantar92@posteo.net> wrote:
> webdev@toryanderson.com (Tory S. Anderson) writes:
>
>> Org currently stands out from my workflow because it does completions its
>> own way, with lists and number/letter keys. It would be nice if I could
>> instead have the benefit of vertico, or helm, or whatever else instead.
>> Org would even benefit from marginalia and embark in some cases. Is there
>> an easy variable I'm missing to make org use completing-reads instead of
>> the indexing thing it does?
>
> This is because you customized your tags/todo keywords to have a quick
> key binding to set. By default, Org uses custom "fast" interface for
> completion in such cases. You can either remove the bindings to
> explicitly set `org-use-fast-tag-selection' and/or
> `org-use-fast-todo-selection' to nil.
>
> --
> Ihor Radchenko // yantar92,
> 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>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: is it possible to choose a completion engine?

[Tory S. Anderson]

Samuel Wales <samologist@gmail.com> writes:

> i guess menu selection is a kind of completion and frameworks coud be
> used also.  a big thing for me that works with ido and ido-hacks and
> ido-clever-match is olpath completion for refile-goto and refile.

Thank you for the recommendation! I've never tried ido, having gone from Helm to Avy/Ivy to Selectrum to Vertico. IIRC, ido is built in to emacs, right? So that would be a big plus. It sounds like it finds a sweetspot for you.

Re: is it possible to choose a completion engine?

[Samuel Wales]

[well it does not work on some cmpleting-reads now in 27.1, and melpa
seems to be unsigned, so if i am able i have to upgrade a component,
try a different ido package perhaps, or try vertico and friends....
but yes it was a sweet spot.]

On 5/23/23, Tory S. Anderson <webdev@toryanderson.com> wrote:
> Samuel Wales <samologist@gmail.com> writes:
>
>> i guess menu selection is a kind of completion and frameworks coud be
>> used also.  a big thing for me that works with ido and ido-hacks and
>> ido-clever-match is olpath completion for refile-goto and refile.
>
> Thank you for the recommendation! I've never tried ido, having gone from
> Helm to Avy/Ivy to Selectrum to Vertico. IIRC, ido is built in to emacs,
> right? So that would be a big plus. It sounds like it finds a sweetspot for
> you.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: is it possible to choose a completion engine?

[Tory S. Anderson]

Ah! Turns out I rely on the Fast completion more than I realized; I am used to hitting "t p" from the agenda to tag an item with a custom status I've created, as you guessed in your message. But untouched was the type of key-menu I really want to hide when, for example, I hit =C-c a= =org-agenda= and get a menu of agenda options to choose from, or =(org-clock-goto '(4))= and I get a big indexed list of clock items. I don't mind keeping the fast keys, but would love for the big screens of options to go away. The =org-use-fast-todo-selection= and =org-use-fast-tag-selection= variables do not effect the method used for those big index screens, which are the ones I actually care about and would like to use with standard completion.

Ihor Radchenko <yantar92@posteo.net> writes:

> webdev@toryanderson.com (Tory S. Anderson) writes:
>
>> Org currently stands out from my workflow because it does completions its own way, with lists and number/letter keys. It would be nice if I could instead have the benefit of vertico, or helm, or whatever else instead. Org would even benefit from marginalia and embark in some cases. Is there an easy variable I'm missing to make org use completing-reads instead of the indexing thing it does?
>
> This is because you customized your tags/todo keywords to have a quick
> key binding to set. By default, Org uses custom "fast" interface for
> completion in such cases. You can either remove the bindings to
> explicitly set `org-use-fast-tag-selection' and/or
> `org-use-fast-todo-selection' to nil.

Re: is it possible to choose a completion engine?

[Ihor Radchenko]

"Tory S. Anderson" <webdev@toryanderson.com> writes:

> ... But untouched was the type of key-menu I really want to hide when,
> for example, I hit =C-c a= =org-agenda= and get a menu of agenda
> options to choose from, or =(org-clock-goto '(4))= and I get a big
> indexed list of clock items. I don't mind keeping the fast keys, but
> would love for the big screens of options to go away.

These two are hard-coded for now.
See `org-agenda-get-restriction-and-command' and
`org-clock-select-task'. Patches welcome!

-- 
Ihor Radchenko // yantar92,
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>

Re: is it possible to choose a completion engine?

[Pedro Andres Aranda Gutierrez]

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

Tory writes:

> Org currently stands out from my workflow because it does completions its
own way, with lists and number/letter keys. It would be nice if I could
instead have the benefit of vertico, or helm, or whatever else instead. Org
would even benefit from marginalia and embark in some cases. Is there an
easy variable I'm missing to make org use completing-reads instead of the
indexing thing it does?

Hi Tory,

I'm using company-mode and I do have auto-completions without any specific
org configuration. Org is also quite well integrated with jinx as my
spellchecker. Since I mainly use org as a 'high-level' layer for
presentations and documents, I'm well served with that. And it is basically
the same I have for LaTEX and markdown.

Hope it helps,
/PA
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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