Re: [code][textadept] view:split() initialization problem

From: Peter Rolf <indiego.att.gmx.net>
Date: Thu, 24 May 2018 13:50:19 +0200

Am 2018-05-23 um 23:31 schrieb Mitchell:
> Hi Peter,
>
> On Wed, 23 May 2018, Peter Rolf wrote:
>
>> Am 2018-05-22 um 17:15 schrieb Peter Rolf:
>>> Hi Mitchell,
>>>
>>> sorry for the late reply, I was on "digital diet" (0 bytes) the last few
>>> days :D
>>>
>>> Am 2018-05-21 um 15:46 schrieb Mitchell:
>>>> Hi Peter,
>>>>
>>>> On Sat, 19 May 2018, Peter Rolf wrote:
>>>>
>>>>> Hi Mitchell,
>>>>>
>>>>> I have a problem with new views in the latest version [Textadept 10.0
>>>>> beta, W32 nightly build 2018-05-18].
>>>>> When I call "view:split()", the new view isn't initialized properly (a
>>>>> copy of the active buffer).
>>>>>
>>>>> I used this test code
>>>>>
>>>>> keys["f7"] = function()
>>>>>     local old, new = view:split()
>>>>>     persistence.store("t:/new.lua",    new)
>>>>>     persistence.store("t:/old.lua",    old)
>>>>>     new:goto_buffer(new.buffer)
>>>>>     old:goto_buffer(old.buffer)
>>>>> end
>>>>> ------
>>>>> [new.lua]
>>>>> -- Persistent Data
>>>>> local multiRefObjects = {
>>>>>
>>>>> } -- multiRefObjects
>>>>> local obj1 = {
>>>>>     ["widget_pointer"] = nil --[[userdata]]
>>>>> ;
>>>>>     ["split"] = nil --[[non-lua function not supported]];
>>>>>     ["goto_buffer"] = nil --[[non-lua function not supported]];
>>>>>     ["unsplit"] = nil --[[non-lua function not supported]];
>>>>> }
>>>>> return obj1
>>>>> -----
>>>>>
>>>>> The new view is empty and complete black (no styles set, not even line
>>>>> numbers are visible) and I have to activate the new view once to
>>>>> "bring
>>>>> it to life".
>>>>
>>>> I am unable to reproduce this issue. I created a new file called
>>>> "new.lua" with the contents you posted. I then created an identical key
>>>> binding to yours, except I commented out the "persistence.store()"
>>>> calls
>>>> since I do not have that code. I started Textadept, opened "new.lua",
>>>> pressed F7, and got the expected split views.
>>>>
>>>> I suspect your "persistence.store()" calls are silently erroring, or
>>>> there is another silent configuration issue in your init.lua. It's
>>>> unfortunate that the error is not more obvious.
>>>>
>>>> Cheers,
>>>> Mitchell
>>>
>>>
>>> First, thanks for all the effort. I have looked into it again and it
>>> seems to be mainly a "property" related problem. Sorry for my wrong
>>> assumption.
>>>
>>> I used
>>>
>>> property["style.default"] =
>>>   "fore:$(fg.default),back:$(bg.default)" .. font_default
>>>
>>> in my style ("twentyfour-light") and that seems to lead to some problems
>>> when (resetting all styles by) setting the "default" style later on.
>>>
>>> The color variables [$(...)] are locals in the style file and I guess
>>> they are not accessible anymore when used later on (?). This would
>>> result in the observed "black on black" style when the colors are set
>>> again (LEXER_LOADED). I hope this makes sense.
>>>
>>>
>>> The usage of color properties instead of local variables solved the
>>> color problems [all local colors were already copied into properties in
>>> the style file beforehand].
>>>
>>> property["style.default"] =
>>>   "fore:" .. property_int["color.fg.default"] .. ",back:" ..
>>>   property_int["color.bg.default"] .. font_default
>>>
>>>
>>> Be aware that the default styles may also be affected by this problem,
>>> as they use the same mechanism.
>>>
>>> There is still a small problem left with new views. The colors are
>>> correct now, but the fonts are not. It seems that the LEXER_LOADED event
>>> is not fired for the new view (so no style changes take place).
>>>
>>>
>>
>> For the record:
>>
>> I also had to hook into VIEW_NEW (first) to get the desired result.
>> Looks like VIEW_NEW is no longer automatically causing a LEXER_LOADED
>> event. This was the first thing I tried when running into problems, but
>> at that time the property problem (all black) was not solved...
>
> I'm having trouble following the flow here. Is there still a problem?
>
> Cheers,
> Mitchell

Thanks for asking, but all is working as expected now.

A hopefully better description of the problems I run into ...

1.) The "$(color_variable)" construct in themes in combination with
local(!) color variables doesn't work with later style resets ("default"
style is set); the color variables are undefined then and "black" is
used as fallback. You end with a "black on black" style.

There are no such problems if you use a property (color) name in that
"$()" construct, as properties are global. The default styles do that,
so they are fine.

2.) New views no longer emit a LEXER_LOADED event and have to be dealt
with separately (VIEW_NEW).

Cheers, Peter

-- 
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 Thu 24 May 2018 - 07:50:19 EDT

This archive was generated by hypermail 2.2.0 : Fri 25 May 2018 - 06:39:02 EDT