On Thu, Nov 9, 2017 at 5:31 AM, Thomas S. Dye <t...@tsdye.com> wrote:
> Aloha Nicolas, > > Nicolas Goaziou writes: > > > Hello, > > > > Takaaki Ishikawa <tak...@ieee.org> writes: > > > >> I also support the idea of keeping "<s" as it was. > >> Please give importance to the backward compatibility in this case. > > > > I explained why I thought it could be removed. I also suggested > > solutions to get an equivalent feature without implementing it in Org. > > > > What is wrong with Abbrev mode, skeletons, tempo.el, expand.el, all > > bundled with Emacs, or YASnippet, in the Emacs ecosystem? It sounds like > > NIH. Or, to put it differently: why in the world would Org implement its > > own template system? > > The "why in the world" question is likely one that can be answered by > the author of the Org template system. > I guess that would be me. The reason why I implemented it was the same reason why I implemented org-mode. It scratched an itch that I was having, and so I implemented it to solve this issue, without much regard for existing expansion systems - back then, I am not sure which of them did even exist and how easy it would have been to deal with dependencies. The reason why the leading character is "<" lies in the fact that, at the time, I was experimenting with HTML tags, mainly because this was how emacs MUSE was handling markup. I left it at that because it led to very few conflicts and because "<" is a character that is easily typed. I have always come down on the side of NOT breaking backward compatibility unless we really HAVE TO in order to make progress. The reason for this bias is because most Org users are not reading this maling list and just want the system to function and to continue to function the way they are used to, while it is hopefully improving. It will stop them from upgrading if such breakage happens too often. So I would support reimplement the expansion (including org-try-structure-completion for people who use that in custom code), if possible of course on the back of one of the built-in expansion systems in Emacs, before pushing this change out in a release. I would certainly reimplement this in some way for myself, because using these abbreviations is already hardcoded in my spine, I think. That does not take away from that fact that I am really happy we now can wrap existing text into a block structure. Very useful indeed. Carsten > > > The only argument so far is "<" cannot be expanded since it not word > > constituent. Seriously. "<" has no meaning anyway. You can use "@", > > which is word constituent and just as meaningless. So, you can define, > > e.g., a skeleton, that will expand "@s" to "#+begin_src\n#+end_src". > > > > We can even document how to do it in the manual. > > For me, the issue isn't about how the template system is implemented, it > is about backwards compatibility of (org-try-structure-completion). > > All the best, > Tom > > -- > Thomas S. Dye > http://www.tsdye.com > >
