Re: [code] Textadept: how to event-handle multiple subsequent select_word operations? UPDATE_UI isn't triggered

From: Mitchell <>
Date: Sun, 4 Nov 2018 09:12:02 -0500 (EST)


On Sun, 4 Nov 2018, Mitchell wrote:

> Hi Phil,
> On Sun, 4 Nov 2018, Phil S. wrote:
>> To summarize: I'm subscribing to `events.UPDATE_UI` branching on
>> `buffer.UPDATE_SELECTION` --- this works great for manually-performed
>> multiple-range-selections but not those performed programmatically in
>> `textadept.editing.select_word` except when no prior selections:
>> When there is no range-selection currently present in the buffer and I do
>> an
>> initial `textadept.editing.select_word` op (via keybord shortcut), the
>> expected event fires. But, subsequent repeats of the op (each selecting the
>> next occurrence) won't trigger the event again!
>> (Manually doing multiple selections with the mouse and Alt or Ctrl DO
>> trigger
>> the event handler each time another selection is added, as expected).
>> The handler:
>> events.connect(events.UPDATE_UI, function(upd)
>> if upd == buffer.UPDATE_SELECTION then
>> ui.statusbar_text = "sel:"..tostring(buffer.selections)
>> end
>> end
>> On subsequent `select_word` ops: not even another value for upd is given,
>> the
>> handler simply isn't entered. (The ui.statusbar_text is also being cleared
>> by
>> something other than my own scripts.)
>> How does one reliably subscribe to ANY and ALL sorts of (multiple /
>> subsequent) selection changes in the buffer, regardless of its reason or
>> originator?
>> (NB I took a quick look at `textadept/modules/textadept/editing.lua`s
>> `function M.select_word` and it seems the module is not to blame, rather
>> the
>> internal implementations of `buffer:multiple_select_add_next` and/or
>> `buffer:multiple_select_add_each` might be the culprit here. Sure one could
>> hotpatch the `editing.lua` module for a quick&dirty but I'd guess that any
>> random custom module ever calling `buffer:multiple_select_add_*` shouldn't
>> have to go through the same issue =)
> This looks like a bug in Scintilla (Textadept's editing component). I'll
> produce a temporary patch and then submit it upstream for inclusion.

I've temprarily patched Textadept's use of Scintilla[1] and submitted the patch upstream[2]. The fix for Textadept should appear in tonight's nightly build.



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 - 09:12:02 EST

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