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

From: cryo shock <>
Date: Wed, 3 May 2017 23:14:13 +0200

X Hi Mitchell, I found a way to recreate the strange behaviour where
TA deletes the first symbol in the first line of a document, when a certain
placeholder is manually deleted BEFORE using TAB-key to switch from
to placeholder. I will upload this document as *.txt in case it is

First, notice that this text starts with "X Hi". I will come back to this.

The snippet in my init.lua is

snippets.trow = '\\NC %1 \\NC %2 \\NC %3 \\NC\\NR'

(Note that I didn't use the %0 placeholder, so the last one is %3, which
should be the final position naturally.
Yet after testing I can say that %0 and %n seem to behave the same)

When I type the keyword "trow" and TAB-key to place the snippet in a
document, then the result looks like this:


[Note at this point, that placeholders are not saved (in textfiles only?),
when you reopen this textfile.
If so, place your cursor at the line above anyway: notice the space at the
end of the line?
It is not specified in the snippet code.]
Visually you can see two of three placeholder rectangles, as after
insertion the cursor was placed in the first placeholder,
so that its rectangle disappeared. But in fact there are four placeholders
when a the snippet is pasted:
Insert the snippet. While remaining the text in this state, place your
cursor at the very end of the pasted snippet.
Notice that there is another placeholder (without visible rectangle). Now
delete this placeholder
and press TAB-key: TA jumps to the first line of the document and deletes
the "X".

Another easter egg I found is: place the snippet two times, delete the very
last placeholder at the end of the second
line and see what happens; I get a message:

D:\textadept/modules/textadept\snippets.lua:552: attempt to index a nil
value (local 'ph')

This "fourth" placeholder remains until all placeholders within the snippet
have been switched through with TAB.

I know now how to circumvent this, but if this were somehow fixable, I
would enjoy your work even more once again.

Cheers Sebastian

2017-04-20 8:15 GMT+02:00 Pedro Andres Aranda Gutierrez <>:

> Hi Mitchelk,
> thanks a lot for the work. I've started to test the new snippets.lua file
> and, until now, it fixes the duplication issues. I can now use the snippets
> using the trigger word and Tab, from the menu and using an assigned key
> sequence.
> Best, /PA
> PS: Since it is mentioned in the thread, I remember having had troubles in
> the past with the Del key in a snippet. However I'll keep silent on this,
> because I don't have any example I can reproduce. But I'll be more alert on
> this one.
> On 19 April 2017 at 03:43, Mitchell <> wrote:
>> Hi,
>> On Tue, 18 Apr 2017, cryo shock wrote:
>> 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.
>> Yes, I think I identified the issue and committed a fix[1]. Testing
>> Pedro's snippets from his original screenshot seems to work fine.
>> 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
>>> words
>> Okay, I think this has been fixed. It seems to only happen when the caret
>> position is at the end of a selection. If it is at the beginning of the
>> selection, I was not able to reproduce the problem.
>> - 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
>> Do you have an example? Sorry, but I don't see one in the e-mail chain.
>> - 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
>>> \starttext
>>> When I do as described above, then the first line looks like this ( _ is
>>> the cursor position after using Tab):
>>> _starttext
>> Again, an example would help me identify the issue. Textadept uses
>> invisible markers for snippet boundaries and placeholders. If you are
>> backspacing in all sorts of places while a snippet is running, you are
>> probably asking for trouble, as I didn't envision that's how snippets are
>> used.
>> Cheers,
>> Mitchell
>> [1]:
>> --
>> 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 Wed 03 May 2017 - 17:14:13 EDT

This archive was generated by hypermail 2.2.0 : Thu 04 May 2017 - 06:46:01 EDT