Omar Antolín Camarena

Oh, that doesn't quite fit the Embark export model, which is supposed to be a function of the list of completion candidates, not of the minibuffer input used to produce...

The cheating solution would be slightly limited compared to usual embark export: normally you can use embark-select to choose some subset of the completion candidates and export only those.

Mmh. Is there an analogue of the `helm-org-ql-buffers-files` dynamic variable for `org-ql-find`? I think that information is locked away in a lexically scoped function parameter, right?

Yes, definitely, @minad. That kind of function wouldn't really take any advantage of Embark infrastructure. It would be better bound to some key in the minibuffer via a setup hook...

Embark users, if they wished, could remap `embark-export` to that `org-ql-save` function while in `org-ql-find`, just to take advantage of muscle memory.

Oh, yes, if we want `embark-collect` to work, definitely a default action override is needed. There's enough to warrant an `embark-org-ql` package even if this export-like functionality is more properly...

(Clearly I forgot the first line of that comment by the time I wrote the last one: damn Chrome and its tiny-by-default text areas. 😄 It's actually pretty unusual that...

> I suggest to add a completion category here. I consider this good style Oh, I agree, and [proposed that a little over two months ago](https://github.com/alphapapa/org-ql/pull/357#issuecomment-1605788880).

I just remembered there was a discussion on oantolin/embark#639 about how to best support acting on agenda items and you, @minad, pointed out that the current support for the org-agenda...

I'm inclined to make that change in `embark-org` and make a one-line PR here adding the completion category and no `embark-org-ql` package would be needed. Oh, and then someone would...