Rasmus <ras...@gmx.us> writes: > Rasmus <ras...@gmx.us> writes: > >> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> >>> 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. >> >> Which sounds fair. >> >>> 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? >> >> tempo.el, which I was unaware of, will be able to do this. Thanks for the >> pointer. >> >> I have started to write a replacement. It seems to work fairly OK so far. >> Not all keywords have been added, and no mechanism for adding additional >> keywords is there yet. >> >> Nicolas, what would be the best way to hook ‘tempo-complete-tag’ into >> "space"? Should I add support directly in org-self-insert-command or add >> it to post-command-hook? > > Actually, it should just hook into TAB (doh). > > The attached version seems to replicate the old behavior more or less. I > had to add a new custom variable to store keywords. > > Also, Eric, it seems that org-structure-template-alist only supports a > single letter for short-hands (the car of an entry in > org-structure-template-alist is a char). I used to have blocks like "<ab" > expanding to an "abstract" special-block, which I guess isn’t possible > anymore?
I hadn't thought of that. Really, all I ever wanted was to wrap things in blocks... I don't see any reason why org-structure-template-alist couldn't go back to using string keys. Then we could use read-string, and wouldn't have to have special <TAB> behavior -- a string that didn't exist in the alist could just be used literally to make a block. Eric
