emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] function for inserting a block


From: Eric Abrahamsen
Subject: Re: [O] function for inserting a block
Date: Thu, 09 Nov 2017 08:50:31 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Rasmus <address@hidden> writes:

> Rasmus <address@hidden> writes:
>
>> Nicolas Goaziou <address@hidden> writes:
>>
>>> Takaaki Ishikawa <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]