Re: [textadept] pointers for implementing abbreviation expansion

From: David Tweed <>
Date: Fri, 8 Apr 2011 22:35:09 +0100

On Fri, Apr 8, 2011 at 2:03 PM, mitchell <> wrote:
> On Fri, 8 Apr 2011, mitchell wrote:
>>> I've been looking around for an simple text editor to try some UI
>>> experiments with and I'm looking at textadept. In particular, I'm
>>> looking at fully automatic abbreviation expansion (the standard idea
>>> is that if you've stored an abbreviation "phy"->"phylogenetic", then
>>> if you type p-h-y-<non-word character> the editor replaces the phy
>>> with phylogenetic, leaving the "insertion point" after the <non-word
>>> character> after it's finished). A websearch doesn't reveal any links,
>>> so it looks like this hasn't been implemented already. I know lots of
>>> languages, but Lua is one I've never done anything more than tweak
>>> existing scripts with. So I'm taking the liberty of asking a question
>>> of those familiar with these things:
>> I would certainly take advantage of the snippets module that is already
>> available. You can probably then hook autoexpansion into the 'char_added'
>> event.
>> events.connect('char_added',
>>  function() _m.textadept.snippets.insert() end)
> I should add that in the interest of performance, maybe you only want to
> limit autoexpansion to a certain set of characters:
> events.connect('char_added', function(c)
>  if c >= 65 and c <= 90 or c >= 97 and c <= 122 then
>    _m.textadept.snippets.insert()
>  end
> end
> The above only tries to autoexpand after [A-Za-z]
>> I haven't tested this, but in theory it should work.

Thanks to everyone for the comments.

I think I may have been a bit confused about the generality of the
snippets mechanism. I had thought that the "Tab" keypress was being
treated like an accelerator key, whereas I'm trying to (initially)
duplicate the emacs-style behaviour where whenever a non-word
character is entered into the buffer (eg, a character like a ","
character you want to remain in the buffer after the expansion stuff),
the word immediately to the left is checked in a big hash-table and if
it's there it gets automatically replaced with no further user
intervention. But it looks like the distinction between normal
characters and accelerators doesn't need worrying about in textadept.
(I've been scanning through the source code of 6 different FOSS
extensible editors trying to see which looked clearest over the past
couple of days, so I'm mixing things from different ones up...). I've
been thinking about it some more and think I should do a direct scan
and figure out the word myself rather than trying to use
"buffer:get_sel_text()" for something it wasn't intended for.

Regarding the computational expense, as I wasn't being clear that it
only does abbreviation lookup after you type a non-word character, so
it's only doing more than just a quick "is this a non-word character"
check once every (say) 5 keypresses, so I don't think it's going to be

cheers, dave tweed__________________________
computer vision reasearcher:
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
Received on Fri 08 Apr 2011 - 17:35:09 EDT

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 12:05:13 EST