Ihor Radchenko <yanta...@posteo.net> writes:
> Bruno Barbier <brubar...@gmail.com> writes: >> Would "lisp/org-pending.el" be OK ? Or do you see a better place/name ? > > org-pending sounds fine. Maybe org-pending-text to be more explicit. I've picked: "org-pending"; it's shorter and can by used as a prefix. Thanks. > Similar to process API, your library provides means to interact with > process associated with the pending text - create them (40.4 Creating an > Asynchronous Process), handle feedback (40.9.2 Process Filter > Functions), handle on-done/fail/etc (40.10 Sentinels: Detecting Process > Status Changes), kill/cancel execution (40.5 Deleting Processes, 40.8 > Sending Signals to Processes), insert-log (strerr in Emacs processes) > list pending (40.6 Process Information), org-pending-on-kill-buffer > (40.11 Querying Before Exit), get information (`process-attributes', > 40.12 Accessing Other Processes) > > I simply went across 40 Processes section of Elisp manual and I see > parallels for pretty much every subsection; but the terminology _and > API_ are different. > I rewrote the API, rename many things, moved the code around and sorted everything into heading/subheading sections. This is hopefully less confusing and a lot simpler; and the documentation hopefully explains better how to use it. The updated section "Commentary", in org-pending, describes the 3 steps that are needed to mark and use a pending region: a PENREG (I've renamed "PINFO" to "PENREG", for PENding REGion, more specific). I tried to stick with the process terminology when relevant (mostly kill-query and sentinel). It doesn't really match the process API, but, now, it should be easier to understand why. >> 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 think that I need to elaborate. > It is not necessarily a matter of alist vs. struct, but more about the > API. I do not like the idea of mutating the alist entries directly. I'd > rather expose an API to work with "pending" as an opaque object - send > signals to it, get status, etc. > > struct is slightly better here because it automatically defines setters > and getters for all the slots without a need to write extra boilerplate > code. Done. Thanks! I added a function `org-pending-user-edit': it allows to edit a region using org-pending and `string-edit' (see org-pending.el). I also added an other execution engine (DEMO_ONLY), that allows to execute any elisp asynchronously, using callbacks (see `my-use-callbacks-schedule', in my-async-tests.el), and in my-async-tests.org, near the multithreading examples. To test, follow the org file [my-async-tests.org] (see direct link below). WDYT of this version ? Thanks! Bruno [I've forced push the new version, squashing everything into simple commits, if you need the old version, just ask and I'll push a copy there.] [my-async-tests.org]: https://framagit.org/brubar/org-mode-mirror/-/blob/bba-pending-contents/scratch/bba-pending-contents/my-async-tests.org?ref_type=heads [repo & branch]: https://framagit.org/brubar/org-mode-mirror/-/tree/bba-pending-contents?ref_type=heads bba-pending-contents