Thanks for the review Ihor!
>> Thanks. I've improved the documentation of `org-pending' to mention >> that one may want to customize the following fields of a reglock: >> before-kill-function, user-cancel-function and >> insert-details-function. And, also, I added that one can attach >> custom properties using the "properties" field. > > Thanks, but I still feel confused. > May you: > > 1. Explain what does "kill" and "cancel" mean in the context of the > REGLOCK. I tried to document that as part of the function `org-pending. That is: | - Emacs may have to kill your locks; see the field | `before-kill-function' if you wish to do something before your | lock is killed. In other words, Emacs has to kill the locks, because the user decided to kill Emacs or some buffers. The user has no say about this. This is when org-pending calls the private function `org-pending--forced-kill'. | - The user may ask Emacs to cancel your lock; see the field | `user-cancel-function' to override the default cancel function. The user is not interested anymore by the lock. He makes a polite request to the library that locked the region to unlock it, the sooner the better. I added some documentation about them to the top level commentary. > 2. Add information about visual hints, "kill", and "cancel" to the > top-level commentary. > > For now, when reading the top commentary: > > ;; This library contains an API to lock a region while it is "being > ;; updated"; the content of the region is "pending" and cannot be > ;; modified. It will be updated, later, when the new content is > ;; available. > > I have an impression that the only side effect of "locking" is that the > region becomes read-only. It is not clear at all that any other > visual indication will be provided. I added a description of the user interface at top-level. [...] > Yes, I do think that top commentary should explain this. > The very idea that lock may be "canceled" or "killed" is important when > designing Elisp code that uses the org-pending library. > Both "killed" and "canceled" are now described in the user interface top-level section. [...] > > I hope that the above clarifies what I am looking for. I think it did. And I even hope the improved top-level documentation shows it :) I've pushed the modification to my branch. Thanks again for the review, your time and useful comments, Bruno
