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

From: Peter Rolf <indiego.att.gmx.net>
Date: Tue, 22 May 2018 17:15:31 +0200

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

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 Tue 22 May 2018 - 11:15:31 EDT

This archive was generated by hypermail 2.2.0 : Wed 23 May 2018 - 06:43:39 EDT