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

From: Peter Rolf <indiego.att.gmx.net>
Date: Wed, 23 May 2018 14:49:53 +0200

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...

Updated the archive with my current settings (link see below).

> Cheers, Peter
>
>
>
> PS 7-zip archive of my current Textadept settings can be found here
> https://spideroak.com/browse/share/indiego/public/textadept/
>

-- 
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 Wed 23 May 2018 - 08:49:53 EDT

This archive was generated by hypermail 2.2.0 : Thu 24 May 2018 - 06:35:06 EDT