Re: [code] Re: Textadept: often no buffer.UPDATE_CONTENT firing on certain modifications:

From: Phil S. <>
Date: Tue, 6 Nov 2018 15:10:21 +0100

Well there seem to be more undocumented UPDATE_UI enumerants now that I
print all unknown to me: 6, 7, 10 and 14 so far. Probably some forward
Scintilla internals that we scripters usually don't need to know about?

On 11/6/18 2:58 PM, Phil S. wrote:
> Good hints, thanks! stdout to the rescue. Just noticed in my
> troubleshooting:
> Although UPDATE_SELECTION is 2 and UPDATE_CONTENT is 1 (the scrolls are
> 4 and 8) --- typing in Enter or Backspace at my end only gives a
> (non-documented AFAICT) value of 3. Same for Undo ops of such edits.
> I can work with that! But wondering about the reasons --- would be neat
> if UPDATE_CONTENT could reliably trigger whenever *any* buffer
> modification has incurred --- whether manual or programmatic, whether
> via paste or undo or redo or typing or other ops. (Could imagine the 3
> is some accidentally slipped-in-earlier bug perhaps and didn't used to
> be this way?)
> (SCN_MODIFIED seems indeed overkill looking at all the events it can
> fire for.)
> On 11/6/18 2:46 PM, Mitchell wrote:
>> Hi Phil,
>> On Tue, 6 Nov 2018, Phil S. wrote:
>>> In addition to many-not-all backspace (both with selection and without)
>>> enterings, the lack of UPDATE_UI+UPDATE_CONTENT firings also appears to
>>> pertain to many-not-all textadept.editing.enclose calls for the common
>>> textadept.editing.auto_pairs
>>> Could it be a bug in Scintilla? Or is the order of event handlers
>>> random such
>>> that my handlers setting ui.statusbar_text do get called but sometimes a
>>> textadept-builtin handler runs later than mine and resets the status
>>> bar,
>>> hence I'm not seeing this 'printf-of-sorts'? (I can't ui.print in this
>>> scenario as it would keep popping up the messagebuffer)
>> I use Lua's `print()` function to print to stdout and then run
>> Textadept from a terminal. I think you're on Linux, so this would work
>> well for you. Based on your findings, we will go from there.
>> I get the feeling that UPDATEUI is ill-suited for tracking document
>> changes. You could try connecting to the undocumented
>> `events.MODIFIED` handler, which may end up being slow because it
>> fires so frequently. You can find more information on this event in
>> Scintilla's documentation[1].
>> Cheers,
>> Mitchell
>> [1]:

You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Tue 06 Nov 2018 - 09:10:21 EST

This archive was generated by hypermail 2.2.0 : Wed 07 Nov 2018 - 06:30:24 EST