Re: [code] [textadept] Textadept 10.0 alpha issue II

From: Gabriel Dubatti <gdubatti.att.gmail.com>
Date: Tue, 9 Jan 2018 16:28:10 -0300

Hi Mitchell,

El 09/01/2018 a las 11:22, Gabriel Dubatti escribió:
> Well, that's what INITIALIZED is for.... fool of me :)
>
>
> El 09/01/2018 a las 11:17, Gabriel Dubatti escribió:
>> Hi Mitchell,
>>
>> El 08/01/2018 a las 19:59, Mitchell escribió:
>>> Hi Gabriel,
>>>
>>> On Fri, 5 Jan 2018, Gabriel Dubatti wrote:
>>>
>>>> Hi Mitchell,
>>>>
>>>> I have been testing this version and have found that it breaks some
>>>> of my
>>>> project management code.
>>>>
>>>> I think I discovered that the issue originates in the new set_theme()
>>>> behaviour (save all buffer settings to load them later in each new
>>>> buffer).
>>>>
>>>> The problem with that is that "all" the buffer settings are saved,
>>>> not only
>>>> the theming related.
>>>>
>>>> If I'm not getting all this wrong, I think a "buffer.user" object
>>>> could be
>>>> added to put in it all the thing you don't want to be duplicated in
>>>> all
>>>> buffers (buffer.user could be ignored or deleted when the setting are
>>>> collected).
>>>
>>> It's hard for me to visualize the kinds of settings you are
>>> referring to. Can you give an example? Also, if you are creating
>>> buffer settings on startup that you do not want to persist, have you
>>> tried wrapping them in either an `events.BUFFER_NEW` or
>>> `events.INITIALIZED` event?
>>>
>>> Cheers,
>>> Mitchell
>>
>> I put some time into this and found where the problem is.
>>
>> Basically, I assign a unique number to each buffer to facilitate some
>> tasks such as tab tracking and buffer deletion detection.
>>
>> The numbers are assigned in the BUFFER_NEW event with something like:
>> if buffer._buffnum is nil, assign a global number and increment.
>>
>> But since the RESET sequence does not send the NEW event, I have to
>> add a function to the init code (HERE IS THE ISSUE) so that the
>> buffers are numbered correctly after a reset and the toolbar is
>> updated properly  (function toolbar.update_all_tabs()).
>>
>> After opening TA9 these events are generated:
>> ----------------------------------------------------
>> 09/01/2018 10:20:03: INIT_START
>> 09/01/2018 10:20:03: events.RESET_BEFORE
>> 09/01/2018 10:20:03: events.RESET_AFTER
>> 09/01/2018 10:20:03: toolbar.update_all_tabs()
>> 09/01/2018 10:20:03: new buffnum: 1  <<<<<< this value is duplicated
>> in all buffers in TA10 becase is set before INIT ends.
>> 09/01/2018 10:20:03: INIT_END
>>
>> 09/01/2018 10:20:03: events.BUFFER_NEW (ignore buffer #0 = command
>> entry)
>> 09/01/2018 10:20:03: events.BUFFER_NEW (buffer #1, already marked as
>> buffnum: 1)
>> 09/01/2018 10:20:03: events.BUFFER_NEW
>> 09/01/2018 10:20:03: new buffnum: 2
>>
>> 09/01/2018 10:20:03: events.BUFFER_NEW
>> 09/01/2018 10:20:03: new buffnum: 3
>> 09/01/2018 10:20:03: events.FILE_OPENED
>>
>> 09/01/2018 10:20:03: events.BUFFER_NEW
>> 09/01/2018 10:20:03: new buffnum: 4
>> 09/01/2018 10:20:03: events.FILE_OPENED
>> .....
>>
>> After a RESET, no NEW or OPENED events are sent:
>> --------------------------------------------------------------
>> 09/01/2018 10:21:22: INIT_START
>> 09/01/2018 10:21:22: events.RESET_BEFORE
>> 09/01/2018 10:21:22: events.RESET_AFTER
>> 09/01/2018 10:21:23: toolbar.update_all_tabs()
>> 09/01/2018 10:21:23: new buffnum: 1
>> 09/01/2018 10:21:23: new buffnum: 2
>> 09/01/2018 10:21:23: new buffnum: 3
>> 09/01/2018 10:21:23: new buffnum: 4
>> 09/01/2018 10:21:23: new buffnum: 5
>> 09/01/2018 10:21:23: new buffnum: 6
>> 09/01/2018 10:21:23: new buffnum: 7
>> 09/01/2018 10:21:23: new buffnum: 8
>> 09/01/2018 10:21:23: INIT_END
>>
>>
>> Note that if I don't re-number all buffers after a reset, I could
>> avoid this issue, but the copy process of set_theme will still set
>> something in the NEW event of future opened buffers.
>>
>> I think a new high-level reset event is required by the new set_theme
>> behaviour, something like "INIT_COMPLETE", that allow us to correct
>> some buffer variables after a reset if needed.
>>
>> Cheers,
>> Gabriel
>
I find this a little disconcerting...

I'm running this test code in TA 9.6:
-------------- (init.lua) ------
local log_ev={}

function log_event(event)
   local line= os.date('%c')..": "..event.."\n"
   log_ev[#log_ev+1]= line
end

log_event("INIT_START")

events.connect(events.RESET_BEFORE, log_event("RESET_BEFORE"))
events.connect(events.RESET_AFTER, log_event("RESET_AFTER"))
events.connect(events.INITIALIZED, log_event("INITIALIZED"))
events.connect(events.BUFFER_NEW, log_event("BUFFER_NEW"))

keys.cf4 = reset

keys.cf5 = function()
   buffer.new()
   for i=1,#log_ev do
     buffer:append_text(log_ev[i])
   end
   buffer:set_save_point()
end

log_event("INIT_END")
------------------

And get the following output (press Ctrl+F5 to show):
........................
mar 09 ene 2018 16:10:31 -03: INIT_START
mar 09 ene 2018 16:10:31 -03: RESET_BEFORE
mar 09 ene 2018 16:10:31 -03: RESET_AFTER
mar 09 ene 2018 16:10:31 -03: INITIALIZED
mar 09 ene 2018 16:10:31 -03: BUFFER_NEW
mar 09 ene 2018 16:10:31 -03: INIT_END
....................

Why does the INITIALIZED event appear before "INIT_END" ?

I get the same results with TA10 alpha.

Cheers,
Gabriel

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Tue 09 Jan 2018 - 14:28:10 EST

This archive was generated by hypermail 2.2.0 : Wed 10 Jan 2018 - 06:34:19 EST