Embark support #299
Comments
|
Hi Akira, Yes, clocking and refiling are two obvious uses for Anyway, you can see the Line 88 in e41cdb4 As for getting an outline path, the function returns a marker, so it should be as simple as this: (org-with-point-at (org-ql-completing-read ...)
(org-get-outline-path))So there should be no need to change the API. |
|
Thank you for your quick response. What I want is a unified completion API that can handle both existing entries (returning a marker) and non-existent ones (returning an olp). I have the following function that can create a heading from an olp (even if its parent does not exist), which can be integrated with org-capture and org-refile: (defun akirak-org-goto-or-create-olp (olp)
(let ((level 1))
(dolist (heading olp)
(unless (catch 'found
(while (re-search-forward (format org-complex-heading-regexp-format
(regexp-quote heading))
nil t)
(when (equal level (- (match-end 1) (match-beginning 1)))
(throw 'found t))))
(org-end-of-subtree)
(insert "\n" (make-string level ?*) " " heading))
(org-narrow-to-subtree)
(setq level (org-get-valid-level (1+ level))))))It would be nice if I could build the olp using |
That is a nice idea, but returning a non-existent heading would seem to violate the concern of I think you will need to do something like having an alternative key binding, like |
I understand your point.
It doesn't look easy to define such a keybinding. It would be nice if |
|
Ok, feel free to propose a patch that adds one. :) |
akirak
changed the title
I tried to implement this idea, but it turns out that this is not easy, at least for vertico users. Vertico uses its own keymap: (defun vertico--setup ()
"Setup completion UI."
(setq vertico--input t
vertico--candidates-ov (make-overlay (point-max) (point-max) nil t t)
vertico--count-ov (make-overlay (point-min) (point-min) nil t t))
;; Set priority for compatibility with `minibuffer-depth-indicate-mode'
(overlay-put vertico--count-ov 'priority 1)
(setq-local completion-auto-help nil
completion-show-inline-help nil)
(use-local-map vertico-map)
(add-hook 'post-command-hook #'vertico--exhibit nil 'local))Even if I could somehow create a heading during the minibuffer session, the completion table would never include a marker to the new entry, which would mean |
|
Ok, maybe we can figure something out in the future. Thanks. |
|
Not sure if I understand this issue correctly, but if you want a local keymap for a command you can use
This approach should be compatible with all completion UIs (at least as long as you don't override some important bindings which are already in use). |
|
@minad Thanks. Since this issue was originally filed, |
alphapapa
changed the title
|
Repurposing this issue for Embark support. @oantolin made this comment:
Omar, if you're still interested in working on that, please let me know how I can help. One feature I'd like to add is the equivalent of |
|
I am interested in working on Embark support. For actions on the org-ql-find completion candidates I think the just-merged org-marker text properties are enough. With that I can have Embark jump to the heading before executing an action. For export, can I just stick the strings that have the org-marker property into a buffer and put it in org-agenda mode? I'm not very familiar with org internals. Oh, I just took a peek at my org agenda and boy do those lines have text properties! So maybe it's not as simple as inserting the org-q-find candidates into a buffer. Does org-ql have a helper function that can make an org-ql view buffer from a list of strings with org-marker text properties? Probably not. |
Hurray! :)
No, the model to follow is here: Lines 162 to 168 in f65b1d9 org-ql-search; it will then show the same results in an org-ql-view buffer (similar to org-agenda).
|
|
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 them. But I guess we can cheat. |
|
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 |
|
@oantolin The function |
|
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 as you suggest. But then it should be just made a part of |
|
Embark users, if they wished, could remap |
|
It could still be that some org-ql-specific support is in order, leading to an embark-org-ql package, or a tiny bit of integration code in a |
|
Oh, yes, if we want
|
|
(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 wrote that in Chrome instead of copy-pasting from Emacs.) |
|
Yes, sounds good. I suggest to add a completion category here. I consider this good style because of |
Oh, I agree, and proposed that a little over two months ago. |
|
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 commands is pretty superfluous since those commands already have bindings in |
|
I'm inclined to make that change in |
|
Woah! |
|
OK. If anyone wants to try preliminary Embark support, just use the remote-org-heading branch of Embark and use this Marginalia configuration: (add-to-list 'marginalia-command-categories '(org-ql-find . org-remote-heading))Actions offered are the same as for the org heading at point in an org buffer, and when acting on an You can currently run |
|
On 9/7/23 08:14, Omar Antolín Camarena wrote:
Woah! |org-ql-completing-read| /overrides/ |completion-styles|! That
seems crazy. Why not just provide a completion table? Overring
|completion-styles| totally messes with my recursive minibuffer habit.
Org-ql does that such that the entire input is passed to the completion
table. Furthermore the input is interpreted in its own way, different
from the usual completion style filtering. The approach is similar to
consult-grep, where the prefix part of #prefix#suffix is not used for
filtering.
|
|
I realized that a little later, @minad. Even if you can get a completion table to produce the right candidates you definitely don't want to match against them in the normal way. I posted here in shock that my recursive minibuffer was broken without pausing to think. The correct thing to say was instead that setq-local should be used, not let. |
|
Of the original use cases @akirak mentioned, the current Embark support takes care of clocking in. For refiling a special action function should be wrriten, because if you use org-refile on heading X it means refile X somewhere else, and I think @akirak wanted an action to refile the heading that was at point before running org-ql-find to X. That extra function would be just like org-ql-refile except non-interactive and it would take a string with an org-marker text property instead of directly taking the marker. |
|
FWIW, the |
It seems to have four: goto heading, open heading in indirect buffer, refile to heading (the missing one I mentioned above), and insert link to heading. Funnily enough embark only has the first one bound to a key, but opening a heading in an indirect buffer and storing (not inserting, though) a link to a heading are org commands you can use as an action. I'll see about adding single-letter keybindings for them. I'm a little surprised helm-org didn't have actions for clocking in, scheduling, adding a deadline, setting properties, etc., like embark-org does (I mean bindings for them: I didn't write them, they are the normal org commands). |
|
Oh, I guess I'm not such an embark expert as I thought I was: there is already a key binding for org-store-link. But not for the indirect buffer thing. |
|
One thing I can't decide on is whether to display the buffer containing the heading you act on from |
|
I think this is ready for v0.8. Thanks to all! |
Hello,
I want to get an olp entered from the user in
org-ql-completing-read. Specifically, I am thinking of the following use cases:This can be solved by adding a history variable for
completing-readin the command. If the function returns nil, the user can get the latest item from the history and split the string with/to get an olp. This is hacky, but it achieves the desired effect with minimal changes to the implementation.An alternative way is to change
(gethash selected table)to
and add
:return-olpargument to the function. The extra argument is needed to avoid confusion in normal use cases, but it is more complicated (in API and implementation) than adding the history variable.What is the best way to solve the problem?
The text was updated successfully, but these errors were encountered: