Bruno Barbier <brubar...@gmail.com> writes: >> I now think that overlays are the right way; the /pending content/ is >> attached to one buffer: a base or a clone; this is for the user to >> decide. >> >> I will manually add text properties, below the overlay, to mark the text >> as /pending/, so that pending contents will be visible and read-only in >> all other buffers, base or indirect ones.
Thanks! I have some minor concerns about implementation, but you clearly demonstrated the things can be working in general. Let me now zoom out all the way down to org-pending library design. While reading the library header and `org-pending' docstring (btw, it should probably be a separate library, not a part of org-macs), 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. 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. WDYT? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>