Hello, Bastien <b...@gnu.org> writes:
> Well, let's agree to disagree on this one. > > org-tempo and C-c C- fill two different use cases: the first one for > fast block insertion while typing, the second one for e.g. when the > region is selected. I don't understand. C-c C-, combination is as fast as Org Tempo: C-c C-, s : 3 keys < s TAB : 3 keys I can agree to disagree, but I don't buy the "fast block insertion while typing" argument: they are as fast. We could even add an "expert" interface that would not display the help menu for an even faster C-c C-, experience. And, about the "while typing" part, C-c C-, can be used anywhere amidst a line. One true argument in favor of Org Tempo, however, is its extensibility. IIRC, it can also insert non-block templates, e.g., "#+include:", whereas C-c C-, cannot. Org has built-in completion for these, tho. > M-x customize-option RET org-modules seems okay to me. Then you may belong to the happy few that happen to find Customize interface "okay". :> I was speaking about "init.el" hacking. One must be cautious when setting Org modules: it requires to be set before Org is loaded. >> By the way, this does not belong to the same category as other >> defcustoms discussed. This is only tangential to "how does Org should >> look and feel by default". It relates to: should Org provide multiple >> snippet extensions, knowing this is not a central feature, and Org is >> often seen as bloated by Emacs devs? I don't think so, no matter how >> useful this feature can be for some users. > > I'll be more receptive to this argument when animate-birthday-present > is not in Emacs's core anymore :) That's true. But I think they do have a point, though. Also, my question is still open: is there any strong reason to provide, out of the box, two template mechanisms in Org? This is genuine question. In any case, I don't think it is just a matter of personal preference, like defcustoms. There should be some clear design decision behind the answer. Let's un-bundle this issue from the rest of the poll, and think about it separately. > That said, I'm receptive to the idea that Org could be more focused to > its core functionalities. E.g., I think we could be more minimalistic > about the ol-* and ox-* libraries in Org. Hmmmm. This is another topic. "ox-" are fine, IMO, even though I'm not sure about the health of "ox-odt" these days. "ol-*" libraries make sense as long as the suffix is bundled with Emacs. E.g.,"ol-eww" is fine, but "ol-w3m" could be an external module. A real issue, however, lies within "ob-*". Many of them require libraries external to Emacs. There's a running bug report about it, IIRC. We may not ship them with Emacs. But, again, this is another topic. Regards, -- Nicolas Goaziou
