[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pending contents in org documents (Re: Asynchronous blocks for every
From: |
Bruno Barbier |
Subject: |
Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)) |
Date: |
Fri, 08 Mar 2024 15:19:11 +0100 |
Hi Ihor,
Ihor Radchenko <yantar92@posteo.net> writes:
> Thanks!
> I have some minor concerns about implementation, but you clearly
> demonstrated the things can be working in general.
Thanks!
> While reading the library header and `org-pending' docstring (btw, it
> should probably be a separate library, not a part of org-macs),
I was feeling more and more like squatting the wrong file :-)
Would "lisp/org-pending.el" be OK ? Or do you see a better place/name ?
> I felt confused about terminology and also had déjà vu's about what
> org-pending does.
> More or less, org-pending implements Elisp asynchronous process control,
> but the processes are associated with region, not the whole buffer.
> Hence, I feel that we should adopt terminology similar to the existing
> terminology for processes - process filters, process sentinels, sending
> signals to processes, etc. And similar API.
The current `org-pending' doesn't know what a process is, or a thread.
The job of org-pending is only to let Emacs know that a given region
will be updated at some point later (much like what
`org-edit-src-code' does, when a source block is being edited
manually).
I've re-read the Elisp manual about asynchronous processes. The only
thing that seemed obvious to me, was to replace "feedbacks-handler"
with "sentinel". I also tried to simplify things and use REGION
instead of CONTENT where it make sense. Thanks.
Do you see something else ?
> Also, I am not sure if I like the idea of exposing raw PINFO alist and
> mutating it. In particular, I have doubts about mutating CONTENT.
> What we might do instead is implement PINFO as struct with custom
> accessors/setters.
I went for this simple alist because it's more flexible (easy to add new
bindings) and less code than using a struct. And Org already uses lists
like this (params, info, etc.). Mutating CONTENT (or other essential
data) would be a very bad idea indeed; but it's like that for pretty
much everything with elisp.
I'm OK to rewrite it using a cl-defstruct (to be honnest, I just
flipped a coin to decide between a struct or an alist :) ).
I'll push my new version after relocating everything into its own
file. Let me know if lisp/org-pending.el is OK.
Thanks.
Bruno
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Ihor Radchenko, 2024/03/02
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Bruno Barbier, 2024/03/02
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Ihor Radchenko, 2024/03/02
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Bruno Barbier, 2024/03/02
- Message not available
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Bruno Barbier, 2024/03/07
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Ihor Radchenko, 2024/03/07
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)),
Bruno Barbier <=
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Ihor Radchenko, 2024/03/13
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Bruno Barbier, 2024/03/19
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Ihor Radchenko, 2024/03/20
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Bruno Barbier, 2024/03/21
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Ihor Radchenko, 2024/03/21
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Bruno Barbier, 2024/03/25
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Ihor Radchenko, 2024/03/27
- Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)), Rudolf Adamkovič, 2024/03/30