From: Mitchell <>
Date: Sun, 4 Nov 2018 14:43:56 -0500 (EST)

Hi Phil,

On Sun, 4 Nov 2018, Phil S. wrote:

> Thank you for the explanation!
>> The primary for `events.BUFFER_AFTER_SWITCH` is to restore a previous
>> buffer's state like selection, folded lines, etc. When a new buffer is
>> opened and switched to, it doesn't have any state to restore, so
>> `events.FILE_OPENED` is sufficient.
> This plays into two things I just scripted: first, having ctrl+shift+tab
> re-open most-recently closed tab, and second, restoring on such re-opens the
> caret-pos that was there just before the most-recent closing. (Not persistent
> across sessions or resets, just in-memory for accidental/reflexive "too
> quick" mistaken tab closings.)
> So right now I'm memorizing and restoring only the caret pos because that's
> dead-trivial and the most crucial, whereas traversing selection_n stuff /
> multi-selections / fold states etc would be too much hassle I feel.
> BUT as I read the above, I got curious if the state capture/restore logic you
> describe was to be found somewhere in `textadept/modules/textadept/*.lua`.
> Doesn't seem like it as only `restore_lexer` reacts to `BUFFER_AFTER_SWITCH`
> in `file_types.lua`. Don't suppose that's the "buffer state" alluded to in
> above quote.
> Have I overlooked something handy in the API or the
> `textadept/modules/textadept` that would let one easily obtain and pass back
> some sort of consolidated 'state object' meant for just that purpose?

*core/ui.lua* around lines 335 and 350 has buffer state save/restore. There's no single state object. Just some simple arbitrarily "_"-prefixed properties.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Sun 04 Nov 2018 - 14:43:56 EST

This archive was generated by hypermail 2.2.0 : Mon 05 Nov 2018 - 06:47:11 EST