Re: [code] Possible GTK init problem

From: Mitchell <m.att.foicica.com>
Date: Fri, 21 Oct 2016 17:08:27 -0400 (EDT)

Hi Markus,

On Thu, 20 Oct 2016, Markus F.X.J. Oberhumer wrote:

> Hi Mitchell,
>
> thanks, but the following does not work for me:
>
>
> local function gui_ready()
> if buffer.lines_on_screen > 0 then
> -- disconnect immediately to avoid recursion
> events.disconnect(events.UPDATE_UI, gui_ready)
> local l = string.format('%d', buffer.lines_on_screen)
> buffer:append_text('lines_on_screen='..l..'\n')
> end
> end
>
> events.connect(events.UPDATE_UI, gui_ready)
>
>
> I think the problem here is that disconnect inside an event handler
> is somewhat flaky.

No, that's not the issue. I can use `print()`, `ui.statusbar_text = ...`,
etc. I just cannot modify buffer contents, so it seems Scintilla is not
re-entrant in this way. The following works for me on both GUI and
terminal versions:

   if not CURSES then
     local function gui_ready()
       if buffer.lines_on_screen > 0 then
         events.disconnect(events.UPDATE_UI, gui_ready)
         -- Emit 'gui_ready' as soon as UPDATE_UI returns since Scintilla
         -- is not re-entrant for UPDATE_UI.
         timeout(0.1, function() events.emit('gui_ready') end)
       end
     end
     events.connect(events.UPDATE_UI, gui_ready)
   end

   events.connect(not CURSES and 'gui_ready' or events.INITIALIZED, function()
     local l = string.format('%d', buffer.lines_on_screen)
     buffer:append_text('lines_on_screen='..l..'\n')
   end)

At least this method does not rely on an arbitrary timeout in an
`events.INITIALIZED` event handler. I agree that was not an ideal
solution.

Cheers,
Mitchell

-- 
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 Fri 21 Oct 2016 - 17:08:27 EDT

This archive was generated by hypermail 2.2.0 : Sat 22 Oct 2016 - 06:44:42 EDT