From: Phil S. <>
Date: Sun, 4 Nov 2018 20:21:59 +0100

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?

If not: no pressing need at all really! Just gotten of course curious if
there was something neat&handy there pre-existing & ready-made that I
could leverage here but might have overlooked..

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:21:59 EST

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