Open pcompassion opened 9 months ago
As you said, org-ql is a query/search library. What your code does with the results is up to you.
If you need a library to help with editing, maybe this can help: https://github.com/ndwarshuis/org-ml
(org-element-at-point) is buggy with non-ascii character (in my case Korean, I guess I'll have to put some encoding hint at the top of file or somewhere)
If you're sure that's the problem, please report a bug to the Org mailing list so it can be fixed.
@alphapapa thanks for response. I was not seeing org-ml-update , so i can use it as to edit the node.
If you're sure that's the problem, please report a bug to the Org mailing list so it can be fixed.
I'll do if I'm convinced, since encoding needs to be told explicitly, i might need to set somewhere default encoding for org file is utf-8 or something. (so it might be my lack of system setup)
Thank you for support
I can see using org-ql to selecting the nodes to edit, and modify using org-ml on selected nodes.
just in my short experience,
I think org-ql can be useful when updating because it provides tool to select the nodes to edit. and here are some difficulties I had
If I happen to have more needs to update using org-ql (and org-ml) I'd probabily make utility function that automates the above pattern.
If I may propose,:action-reverse
would be useful, (it would do the forward search to build up the nodes, and call action-reverse for each match in reverse order (in buffer position)
then, one could just perform modification work in :action-reverse function
IIUC, you needn't bother about those complicated patterns. Just perform the edit in the org-ql-select
's ACTION function. When your function returns, org-ql
will continue and find the next match, skipping to the next heading before searching again.
Alternatively, you could return a marker rather than an integer position, collecting a list of markers. Then use org-with-point-at
with the marker as the first argument.
since buffer itself might get destroyed after org-ql call
It's good to keep that in mind, but since this is your own code, what would be killing the buffer too soon?
wow, thanks for the response.
So it was the org-element-at-point
all along.
I thought cutting element from source buffer somehow disrupts org-ql-select , selecting next node.
But it was org-element-at-point
(with non-ascii character) playing against me.
About buffer, I provided files and since org-ql-select opened the buffer,
I thought I had no reason to expect the buffers to be alive after org-ql-select
returned
(Because at that time, I thought I couldn't modify buffer in :action
and stored buffer so that I can work on later)
Now, looking at org-ql-select code, it advances with outline-next-heading
,
so, cutting an element wouldn't matter, as long as following two cases are covered
my cursor falls into next-heading, then this heading would be considered as (current-heading) by org-ql and it will be skipped. (and it happend because (org-end-of-subtree t t)
placed cursor after current element against my assumption)
my cursor somehow falls into nowhere (I'm not sure if any cursor position after the first heading belongs to a heading in org document, specifically I'm not sure if org considers in-between-lines as part of previous heading, which I suspect so)
Thank you for taking time to point it out.
I can't say I understand exactly what you mean. But:
my cursor falls into next-heading, then this heading would be considered as (current-heading) by org-ql and it will be skipped.
Unless your action function actually deletes the heading, I don't think this will be a problem.
my cursor somehow falls into nowhere (I'm not sure if any cursor position after the first heading belongs to a heading in org document, specifically I'm not sure if org considers in-between-lines as part of previous heading, which I suspect so)
Yes, every position after the first heading is part of an "entry" under a heading. There is no non-entry content after the first heading position, nor any between-entry content.
Unless your action function actually deletes the heading, I don't think this will be a problem.
Yes that's exactly what I'm doing, I'm doing similar thing as org-journal
carries over items
Essentially, it's moving left over items from previous days to current buffer.
(I'm doing two moving operations, the one described above (cut-and-paste)..
and another one is.. creating a copy of items into this buffer,
With two operationsm I'm trying to collect items into a buffer and sends it back to where it came Then I can have editable agenda buffer where I don't need to visit the original buffer to edit items )
So, this kind of operation is not typical I guess, org-ml also doesn't seem to expect this kind of operation (I can't cut and paste somewhere because org-ml doesn't expect someone to change :begin
)
Yes, every position after the first heading is part of an "entry" under a heading. There is no non-entry content after the first heading position, nor any between-entry content.
Thank you for letting me know!
I am trying to carry-over todo items, (similar to what org-journal carry over does)
I used org-ql to do query what I want to carry over.
Here's the code.
I had some perplexing bug on putting
only when cursor at source buffer is at the end of the end. Caused my code to not correctly carry-over.
I was suspecting many things, but it turned out
(org-element-at-point) is buggy with non-ascii character (in my case Korean, I guess I'll have to put some encoding hint at the top of file or somewhere)
Since I didn't know what the cause was, I also suspected it might be related to org-ql (specially how it caches..) But it was not.
@alphapapa Thanks for saying to ask for help. While I prepared the question, I found the bug. I ask a general question, since org-ql seems to be supporting "query" not "replace or edit" I was wondering if I was misusing library or if there are things I need to know when using it for editing. (maybe too general question.. but I 'll be glad if I can get any hints)
and the test org doc is