Ihor Radchenko <yanta...@gmail.com> writes: > Max Nikulin <maniku...@gmail.com> writes: > >> Consider the following case. A user has 2 virtual desktops dedicated to >> rather independent tasks and an Emacs frame on each desktop. On desktop >> 1 she opens help for some function with aim to evaluate if it is >> appropriate for some particular purpose. Next she has to switch to >> another task and applications for it reside on virtual desktop 2. To >> proceed further she has to read several help pages relevant for task 2. >> After completion of this task it is time to resume task 1 and to switch >> to virtual desktop 1. Does a window with the help buffer still display >> the same content as before switching to task 2? No, context on desktop 1 >> lost due to some actions in the Emacs frame on desktop 2. >> >> Such synchronization is against multitasking and I do not like the idea >> to get it for org-capture as well. Currently read-key and modal prompt >> is a kind of excuse, but the idea of new menu library is non-blocking >> keymap-based selection. > > I understand. > From the perspective of the library being discussed, what you want does > not look impossible. > > The other question is altering the org-capture code. > I think that it is too early to discuss org-capture part just yet. > Lets first finalize the generic library itself and discuss the > appropriate adjustments to > org-capture/org-agenda/org-export/org-todo/etc code later. > I think it sounds like a wise proposal :).
Thanks.