i must be confused. menus aside, you can currently capture and it uses the org forest itself, so it is both crash-proof and snappy. and you can yakshave as much as you want, starting a capture while doing a capture. those were design goals.
you can even be in the middle of a capture, get distracted, navigate around your forest, and find where you are in the middle of a capture. goes with the original crash-proof and yakshave and snappy use-original-buffer design goal. so are we talking about menus then? is there truly a need to make /menu state/ persistent or yakshaveable? On 6/6/22, Max Nikulin <maniku...@gmail.com> wrote: > On 05/06/2022 22:07, Arthur Miller wrote: >> Max Nikulin writes: >> >> After input from Ihor I agree that it isn't the best way, and was >> able to refactor org-mks to create a menu where I can execute any lisp >> form, >> when it comes in a list like this : ("h" "hello-word" (message "Hello, >> World")), where third element is just a lisp form. I have something like >> this: > > This message is merely my opinion that you may disagree. I am not trying > to prevent you from going forward. > > From my point of view current `org-mks' is more general giving you > opportunity to treat extra elements as you wish. A thin wrapper allows > to evaluate 3rd element of returned list. You have not convinced me that > built-in executable form is the essential feature. > >> (defun demo3 () >> "Illustrate nested menus, unicode separator and alternative >> decorator." >> (interactive) >> (let ((quick-menu-key-decorator-chars "<>") >> (quick-menu-vertical-separator ?─)) >> (quick-menu >> ;; table >> '(("g" "Greetings") >> ("gh" "Hello, World!" (message "Hello, World!")) >> ("gb" "Bar" (message "Hello, Bar!"))) >> ;; description >> nil >> ;; more tables >> '(("f" "Functions") >> ("ff" "Find File" (call-interactively #'find-file)) >> ("fo" "Open File" (flet ((next-read-file-uses-dialog-p () t)) >> (call-interactively 'find-file)))) >> '(("q" "Abort" (user-error "Abort")))))) > > It is tightly based on org-mks, but actually it is way to represent list > of choices with some hints to possible hierarchy and accelerator keys. > Quite similar list may be fed to completion read or represented as a > hierarchical GUI menu. The only specific is "always visible" elements > like "abort". When Ubuntu used Unity desktop their had a nice feature of > searching in application menu. > > There should be an extension point that allows users to replace > representation e.g. to improve accessibility. > >> DESCRIPTON is a property list containing following members: > ... >> :horizontal when `t', if multiple menus are present they are rendered >> from >> left to right, otherwise from top to bottom. > > It may depend on whether a window created to display menu is tall and > narrow or wide. > >> I have paramterized decorator character for shortcut keys as they appear >> in the >> buffer, org-capture uses "[]", as well as menu separator, which is >> currently >> hard-coded in org-capture, > > I agree that org-mks may have additional argument to specify menu > decoration. > >> Exactly. It is important that org-capture is one capture at the time so >> people >> don't mess their note files, agenda files etc. >> >>> Unsure if some >>> intermediate persistent store would be an improvement. >> >> Not sure what you mean here, but I don't plan to change anything in >> org-capture >> itself, it should still be one-task at the time. > > Changing interface to less degree of blocking may be confusing for > users. Capture template selection menu may be displayed in another frame > hidden behind other application, on another monitor, on another virtual > desktop, so invisible. So a user earlier distracted by something urgent > may try to start another capture. Captures may be initiated from other > applications using org-protocol. > > To avoid data loss while other capture is in progress, the data of next > capture may be temporary saved to some place till the user pops it from > the queue. I mentioned persistence since something may unexpectedly > crash, so it should be possible to resurrect enqueued captures in next > Emacs session. > >>> Likely nobody performed any steps toward `transient' as the interface, >>> but due >>> to such requests it would be nice to have possibility to switch between >>> menu >>> implementations. >> >> I am not building some generalized framework, as I said in my first >> respone to >> Ihor :-). > > I am not requesting for a framework, I mean API compatible with other > frameworks to let user choose their preferred ones. > > So tunables to control decoration sounds interesting. I am in doubts > concerning fixing some element as executable. Mode-map instead of > minibuffer may be a great step to more convenient interface (it > resembles help buffers), but may require more changes in functions that > do actual job. From other messages on this list my impression is that > API should be designed having in mind flexibility and other UI packages. > > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com