Re: [code] [textadept] I want to contribute

From: code <>
Date: Fri, 06 Mar 2015 17:00:09 -0500

Hey Mitchell,

On 03/06/2015 03:38 PM, Mitchell wrote:
> Hi Alejandro,
> On Tue, 3 Mar 2015, code wrote:
>>> [snip]
>>> * While snippets are being expanded, the placeholders are shown in the
>>> snippet text (%n and friends). This is done for the sake of
>>> simplicity, but
>>> there may be a way to hide them using by cleverly using indicators
>>> and a
>>> table that keeps track of placeholders, positions, and text. I'm not
>>> sure
>>> this is possible right now, but if you'd like to attempt it, I can
>>> give you
>>> some more information.
>> Entirely possible. If you haven't checked out Qt Creator, they have gone
>> about and done exactly what you are referring to. Yeah, definitely
>> throw this
>> one at me too. Due to my extensive use of the snippets on Textadept,
>> I have
>> been eking to do a patch on snippets for a while now anyhow.
> Here's some info to help with snippets:
> Right now, snippets are inserted as pretty much raw text, including %
> placeholders. I use an invisible indicator to mark the current end
> position of the snippet for bookkeeping purposes. By using raw text, I am
> able to easily move to the next placeholder (on Tab keypress) by
> searching
> for the next "%n", where n is the next placeholder number. Similarly,
> if I
> want to move backwards through placeholders, I can simply restore a saved
> text "snapshot".
> Your task involves removing the % placeholders from text. That means you
> need to parse the snippet text and store placeholders, positions (?), and
> metadata (placeholder, default text, is it shell or Lua code?, etc.) in a
> table. You'll probably want to use invisible indicators to track
> placeholder positions as the user enters placeholder text. One thing to
> note is that should only use only ONE indicator for ALL placeholder
> indicators. (You don't want to be allocating new indicators for each
> placeholder in a snippet.) Instead, you'll differentiate placeholder
> indicators from one another with the undocumented
> `buffer.indicator_value`[1] property. This allows individual
> indicators of
> the same type to be differentiated, allowing you to create a one-to-one
> mapping of indicator instances with metadata or other placeholder
> information you created when parsing the snippet text.
Before going ahead with removing the `%n` placeholders, I have a
question for which form you are asking to mask. Are you referring to
`text` when a snippet is initiated or when it is defined? Masking the
the placeholders on an initiated snippet is doable. However masking from
raw definition as in `for %1(i) in %2(iterator):\n\t%0`would require an
entirely different format of snippet definitions which I don't think I'm
willing to do, due to the ease of written definitions on Textadept now.
So for the remainder of my response, I will assume you are referring to
masking of placeholders on initiation of a snippet and not on definition.

One indicator is good. Having multiple would be like trying to edit
multiple iterations on an iterator at the same time. Not a fun time...
Position I think is also doable with added navigational ability to
reverse. All thanks to the use of the indicator and not the raw
definition. Will use the `n` value of `%n`, on parse, to get the
navigational value for the indicator. Have to try this out before saying

> Now you'll be able to find the next %n to go to by first searching for
> the
> next indicator, and then using the undocumented
> `buffer:indicator_value_at()`[2] with your one-to-one mapping to
> determine
> whether or not that indicator's n is the n you're looking for. If not,
> search for the next indicator and repeat the process. (Once you've found
> the right indicator, you can repeat the process to set additional carets
> for mirrors.)
> One part I haven't thought much about is moving backwards through
> placeholders. As I mentioned earlier Textadept just keeps a set of
> "snapshots" of raw text it can revert to (which makes things easy). I'm
> not sure how you're going to do this since indicators do not behave the
> same way. Perhaps keeping "snapshots" of indicator positions would be
> sufficient.
Right. I was thinking of having each indicator positional value also
hold itself as a store. Then have the final `%0` parsed placeholder
cause the indicator to flush the store and complete its walk through the
snippet. In this form, as long as the user doesn't reach the `%0`
placeholder, they can reverse similar to now by using `keys['s\t']`. All
that would really be happening would be the previous indicator value
position would get called with the store and continuing again to the
`%n` until reaching `%0`.
> I hope this is clear and gives you an idea of the direction to take in
> tackling this problem. Let me know if you have any questions.
> Cheers,
> Mitchell
> [1]:
> [2]:
Thank you for the extra help and direction on this one. I still have to
give that college try and see what I get. Still, transitioning to
masking the placeholders on initiation with using indicators, I think
is a step on the right direction. Will let you know if I reach any hiccups.


Alejandro Baez

You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Fri 06 Mar 2015 - 17:00:09 EST

This archive was generated by hypermail 2.2.0 : Sat 07 Mar 2015 - 06:46:51 EST