Re: [code] Feature request: snippet._insert should allow replacing the selection

From: cryo shock <>
Date: Tue, 18 Apr 2017 21:12:59 +0200

Hi guys,

I think, when Mitch finds the time to solve the problem with selected_text
 and *appending* or *replacing*, then your problem will be solved Pedro.

I'd also like to remind what I experienced so far:

Instead of replacing, a snippet with selected_text gets appended after the
highlighted text

- problem is not occuring for a whole line only; it also happens for single

- there seems to be a difference in using %selected_text while
-- pasting snippets directly after each other
-- on the contrary to pasting a snippet, then writing some text, then
pasting a snippet again

- problem might also have to do with *placeholders*
-- personally I think, there might be a problem with the jump from %1 to
%0, or with %n while n>=1 in general
--- I think that, because there seems to happen an unexpected jump, when
you *delete* a placeholder, without jumping there by using *Tab*-key
before. I.e.: although there is no more placeholder, TA jumps to the
beginning of the document and deletes the first symbol.
---- To clearify: when creating a snippet with placeholders, you can not
assume, that the user will always use those placeholders. That counts for
me. Sometimes after pasting a snippet I just use arrow keys to go down a
line and delete (most of the time) the %0 placeholder by using
Backspace-key. Then an unexpected event happens: when I use Tab-key again
to create a simple Tab break, the cursor jumps to the first line of the
buffer and deletes the first symbol.
For example, CTX starts its docs with


When I do as described above, then the first line looks like this ( _ is
the cursor position after using Tab):


I hope that helps, cheers, Sebastian

2017-04-18 12:26 GMT+02:00 Pedro Andres Aranda Gutierrez <>

> Hi Mitchell,
> no worries. I do fully understand and appreciate your effort. I'm just
> trying to see where the problem is from "outside the box". It has sometimes
> helped me to have people looking at was actually happening and not at the
> code. If this is not helpful, just tell me and I'll stop bugging.
> So my take is the following:
> There are two situations:
> 1.- I type a snippet trigger and then 'Tab' and that is working
> 2. I have a part of the buffer selected and then I go and select a snippet
> from the menu
> t is here where we have the problem. Again, from outside the box, I would
> expect something like a
> buffer:replace_sel(<expanded snippet>)
> but I seem to be getting a
> buffer:insert_text(<expanded snippet>)
> Because the generated snippet is appended after the selection.
> This is why I say that when we bind a snippet to a key, the function may
> have to be something different than snippet._insert(), which is bound to
> <Tab>. Of course, if snippet._insert() is made to replace the selection
> instead of appending text after the selection, the bug would be solved...
> My .0002 cents,
> /PA
> On 18 April 2017 at 02:53, Mitchell <> wrote:
>> Hi Pedro,
>> On Mon, 17 Apr 2017, Pedro Andres Aranda Gutierrez wrote:
>> Happy Easter to everybody!
>>> I have been giving this issue a thought and I think that we may need to
>>> split treatments depending on whether it is the Tab key or not that calls
>>> the function. Something like:
>>> When tab is pressed, we execute the following function
>>> get the word before the cursor and try to find a snippet
>>> if found:
>>> kill the word before the trigger
>>> execute the snippet associated to the word
>>> else:
>>> insert a tab
>> Okay, the Tab key is already bound to a function that does this very
>> thing.
>> When we bind a key to a snippet, then we only execute the snippet
>>> associated to the word we indicate in the code
>> I can bind a key to `function() snippets._insert(snippet_text) end` and
>> it works as I expected (except for some cases of selected text as pointed
>> out earlier in this thread).
>> I'm having trouble understanding where Textadept is falling short in your
>> opinion (other than the bug that I have not had the time to look into yet,
>> sorry).
>> Would that kill recursive snippets?
>> I'm not sure what you mean be recursive. Perhaps nested? If so, no that
>> would not kill nested snippets -- it would just add another one to the
>> stack.
>> Cheers,
>> Mitchell
>> --
>> You are subscribed to
>> To change subscription settings, send an e-mail to
>> To unsubscribe, send an e-mail to
> --
> Fragen sind nicht da um beantwortet zu werden,
> Fragen sind da um gestellet zu werden
> Georg Kreisler

You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Tue 18 Apr 2017 - 15:12:59 EDT

This archive was generated by hypermail 2.2.0 : Wed 19 Apr 2017 - 06:25:28 EDT