Re: Feature request: Radio button option for lists of checkboxes
On 12/02/20 12:10 pm, Bastien wrote: > From latest master, please try C-c C-x C-r on a checkbox or turn > on M-x org-list-checkbox-radio-mode RET so that C-c C-c consider > all checkboxes as radio buttons. Brilliant, thanks Bastien! A nice feature that may be missing from this implementation is the ability to mark individual lists as radio-button lists, and then have C-c C-c do the right thing contextually. The syntax John and Matúš used was: #+attr_org: :radio - [ ] localhost - [X] staging - [ ] production Then you can always just use C-c C-c to select a checkbox -- but if the list is intended to be radio buttons then that behaviour gets used automatically. If that's practical to add to the new implementation, I would think it would provide the best end-user experience for interacting with such lists. -Phil p.s. Their code for detecting this was along similar lines: (when (-contains? (org-element-property :attr_org (org-element-property :parent (org-element-context))) ":radio") vs (let ((list (org-radiobutton--get-list-at-point))) (when (-contains? (org-element-property :attr_org list) ":radio")
Feature request: Radio button option for lists of checkboxes
(Where "radio button" means that for a list of checkboxes, only one may be selected at any given time -- selecting a different checkbox automatically de-selects the previous one.) Hello org-mode, John Kitchin posted this blog a few years back: http://kitchingroup.cheme.cmu.edu/blog/2015/10/05/A-checkbox-list-in-org-mode-with-one-value/ Subsequently Matúš Goljer adapted that code here: https://github.com/Fuco1/org-radiobutton I'm slow in following this up, but I contacted both John and Matúš last year suggesting that this facility would make a nice addition to the core org-mode features. Both of them were happy for me to submit the feature request, and both confirmed that they have signed FSF copyright assignment, and so their code may be safely adapted. I have CC'd them both to this message. Matúš's github project has subsequently merged a branch from one other contributor, so I have pushed a fork which excludes that particular change, as I am not aware of the copyright status for that. This FSF-safe fork is: https://github.com/phil-s/org-radiobutton (n.b. I've assigned FSF copyright for Emacs too, but none of the code on this fork was written by me.) John also independently made some later changes to his original code, and the current version of that can be found here: https://github.com/jkitchin/scimax/blob/740591268a868b4944193e0600bf71b6f2553f2b/scimax-org.el#L1426 Both implementations depend upon the dash library, so I expect the relevant bits of code would need rewriting. I suspect that a standard implementation would be able to approach things a bit differently in any case; but the existing code would surely provide at minimum a valuable reference for a core implementation, and I imagine at least some of the code could be used verbatim. I'm not familiar with org-mode internals, so I've not attempted to provide a patch for this, but I'm hoping there's enough here that someone with existing knowledge could run with it, as it seems like a nice feature to include. -Phil
Re: [O] [RFC] Replace lambda functions added to org-mode-hook with named funcs
On Fri, Oct 5, 2018, 6:42 AM Nicolas Goaziou wrote: Kaushal Modi writes: > I propose to replace such lamba functions with named functions. > Here's an example of diff on maint branch, after making one such change: > > -;; Remove overlays when changing major mode > -(add-hook 'org-mode-hook > - (lambda () (add-hook 'change-major-mode-hook > - 'org-show-block-all 'append 'local))) > +(defun org--unfold-all-blocks-on-major-mode-change () > + "Remove overlays when changing major mode." > + (add-hook 'change-major-mode-hook #'org-show-block-all 'append 'local)) > +(add-hook 'org-mode-hook #'org--unfold-all-blocks-on-major-mode-change) If that's a function added to `org-mode-hook', it is not useful to add "on major mode change". Certainly it's useful. Or at least in general it's a common *pattern* for a major mode to add a function to `change-major-mode-hook' so that if the user changes from that major mode to some other major mode, the function will be called and can put the buffer into a sensible state before the replacement mode function is called. The only curious thing about it to me is that this code is being run via `org-mode-hook' rather than in the `org-mode' body; but maybe there's some reason for that. Regarding the general issue: Grep shows me all of the following instances in the master branch (commit d215c3a8c0b4c027), where a lambda is added to a hook variable (a few of them in the form of commented suggestions to the user). It's never a good idea; all of these should be changed to use named functions, IMO. -Phil -*- grep -*- ./ob-core.el:1429:(add-hook 'org-mode-hook ./ob-haskell.el:66: (add-hook 'inferior-haskell-hook ./ol-w3m.el:171:(add-hook ./ol-w3m.el:176:(add-hook ./org-agenda.el:2246: (add-hook 'filter-buffer-substring-functions ./org-agenda.el:2935: (add-hook ./org-attach.el:697:;; (add-hook ./org-compat.el:813: (add-hook 'imenu-after-jump-hook ./org-compat.el:817: (add-hook 'org-mode-hook ./org-compat.el:880: (add-hook 'speedbar-visiting-tag-hook ./org-crypt.el:144: (add-hook 'auto-save-hook ./org-crypt.el:267: (add-hook ./org-ctags.el:196:(add-hook 'org-mode-hook ./org-ctags.el:59:;;(add-hook 'org-mode-hook ./org-indent.el:188:(add-hook 'filter-buffer-substring-functions ./org-mouse.el:1085:(add-hook 'org-agenda-mode-hook ./org-mouse.el:856:(add-hook 'org-mode-hook ./org-src.el:745: (add-hook \\='org-src-mode-hook ./org.el:15697: (add-hook 'after-save-hook ./org.el:18978:(add-hook 'occur-mode-find-occurrence-hook ./org.el:21221:(add-hook 'org-mode-hook ;remove overlays when changing major mode ./org.el:2916: (add-hook \\='org-capture-mode-hook
