[i put an unnecessary and not really meant word truly there. accessbililty reasons could of course make it necessary.]
i think it is needed to do accessibility and great to do factoring. shows our maturity as a project and developers. [accessbilty/refactoring aside, i want to say i really like many aspects of the care taken to make many of our menus. e.g. kw selection or tag selection use colors, have low key count. date selection too. i wonder how much of this will survive?] On 6/6/22, Samuel Wales <samolog...@gmail.com> wrote: > 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 > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com