Ihor Radchenko <yanta...@gmail.com> writes: > Arthur Miller <arthur.mil...@live.com> writes: > >> Simplicity comes from the org-templates. Me, and I guess other people are >> familiar with org-catpure templates already, and I mean, can it be simpler to >> create a menu of choices then a simple list: >> >> '(("key1" "label1" exec (lambda () ...)) >> ("key2" "label2" exec (labmda () ...)) >> ... >> ) >> >> People are already writing those as part of org-capture, so there is a >> familiarity factor. Transient has to be learned, and the complexity is much >> bigger. > >>> If anything, capture >>> menu might be factored out to a generic menu framework. >> >> Please no. Not every single piece of Emacs has to be a generalized >> framework. Generalized frameworks add an extra layer of complexity, and it >> this >> case, as you point out, we have other frameworks, so yet another framework is >> *definitely* not what I ask for. > > By "generic" I did not mean general-purpose all-functional framework. > We just need something to remove code duplication in > org-export-dispatch, org-agenda, org-capture, org-set-tags-command, etc > They all share pretty similar code to generate dialogues. > > As for familiarity, I understand and it is exactly the reason why I > suggested to factor out the menu code from capture templates.
I am not really familiar with those other dialogues but org-capture, so I only had that one in the mind. Yes, I agree if the similar code is used/shared in several places than it does make sense to refactor it out. > I am strongly not in favor of adding exec to org-capture itself. It's > a bit like if you were to add :activate-func for a link that actually > downloads some file from internet, then generates and exports agenda, > and meanwhile also restarts your remote server. This will also kind of > save the code, but completely out of purpose of :activate-func. Of > course, I am exaggerating here, but just want to make my point clear. I understand, it is ok :). >>> We actually had multiple threads discussing possibility to port all the >>> Org dialogues to transient. >> >> I have unfortunately missed those discussions. But as said, I am not in to >> argue >> for or against transient at all. I would just like to re-use the org-capture >> code, since it is already in-place. > > The last one was > https://orgmode.org/list/8c364693bf6856e60cdd3e8b63ab0c9284d16733.ca...@heagren.com > And we had multiple complaints that Org menus are not searchable and do > not allow recursive edit. I am not sure what complain about searchability is/was, so I should not say much there, but those are just a list of lists, saved in a well-known place, org-caputre-templates var, so one can always traverse that list, or search the menu buffer itself. Anyway thanks for the link, I have read through that discussion. Seems to me like most of you are in favour of refactoring org to use transient everywhere? >>> It seems to be quite out of scope of org-capture. >> >> Maybe, but than what is in scope of org-mode or org-capture or Emacs? We are >> constantly bending code to do what it is not really meant to do. Since to be >> a >> DNA of Emacs :). > > Sure. But another feature of Emacs is being consistent. Emacs does > provide flexible interfaces, but they stick to they purpose. Abusing > them is up to the user (with no guarantees to work in future versions), > but not up to Emacs itself. > > If we were to include your suggestion, we would also need to maintain > the new generalized functionality in future. Even if we need to change > some internals of org-capture. Over-generalization will put an extra > burden on future maintenance. Np, I understand. Thanks for the answer anyway. Best regards /a