Re: [code] [textadept]Some questions about buffer.set_theme()

From: Mitchell <>
Date: Mon, 26 Mar 2018 11:26:42 -0400 (EDT)

Hi Peter,

On Mon, 26 Mar 2018, Peter Rolf wrote:

> Am 2018-03-26 um 16:35 schrieb Mitchell:
>> Hi Peter,
>> On Mon, 26 Mar 2018, Peter Rolf wrote:
>>> Hi Mitchell,
>>> Am 2018-03-25 um 23:08 schrieb Mitchell:
>>>> Hi,
>>>> On Wed, 7 Feb 2018, Mitchell wrote:
>>>>> Hi Barna,
>>>>> On Tue, 6 Feb 2018, Keresztes Barna wrote:
>>>>>> Hi,
>>>>>> I have some questions about the behavior of the buffer.set_theme()
>>>>>> function.
>>>>>> 1. It sets the theme only at the startup and for every buffer, it's
>>>>>> clearly
>>>>>> a
>>>>>> function affecting the UI (like, not a buffer-level function
>>>>>> (properties that can be different for every buffer - like tab width or
>>>>>> margin). So I don't really understand why was it moved from the ui
>>>>>> class to
>>>>>> buffer class?
>>>>> I agree it's not perfect, but there are two reasons for the change: (1)
>>>>> ui.set_theme() can imply the entire ui is themed (menus, text boxes,
>>>>> buttons,
>>>>> etc.) and this is not the case; (2) [ui|buffer].set_theme() only ever
>>>>> sets
>>>>> buffer properties and calls buffer functions. With the new feature in
>>>>> Textadept 10 that makes any buffer settings on startup apply to all
>>>>> subsequent buffers, `buffer.set_theme()` seems more appropriate.
>>>>>> 2. I understand that it works only at startup, but I don't find it
>>>>>> normal
>>>>>> that subsequent calls give "nil value" error (as it's an API
>>>>>> function). IMO
>>>>>> it should do nothing or give a warning.
>>>>> That is a fair point. Despite the fact that the documentation states
>>>>> the
>>>>> function can only be called on startup, I will do something about it.
>>>>>> 3. The most interesting question: It should be really interesting
>>>>>> to be
>>>>>> able
>>>>>> to define a different theme for different buffers. I like to have a
>>>>>> light
>>>>>> theme for text editing (LaTex, Markdown) and a dark theme for code.
>>>>>> Something
>>>>>> like:
>>>>>>     events.connect(events.LEXER_LOADED, function(lang)
>>>>>>       if lang == 'markdown' or lang == 'latex' then
>>>>>>         buffer.set_theme(not CURSES and 'base16-tomorrow-light')
>>>>>>       else
>>>>>>         buffer.set_theme(not CURSES and 'base16-monokai-dark')
>>>>>>       end
>>>>>>     end
>>>>>> I don't think there is a technical obstacle as I found a workaround by
>>>>>> replacing `buffer.set_theme` by `dofile('path/to/theme.lua')`.
>>>>>> Could you implement the per buffer theme feature?
>>>>> That's an interesting idea. I will explore it and get back to you.
>>>> I've committed a change[1] that removes the call restrictions on
>>>> `buffer.set_theme()` and adds an initial `buffer` argument like all
>>>> buffer functions. As a result, you can now call `buffer:set_theme(name,
>>>> props)` at any time, not just on startup. This enables per-language
>>>> themes if you like.
>>>> The next nightly build will have this change. You'll need to use a
>>>> nightly since I fixed a bug[2] in the Scintilla lexer that this change
>>>> depends on.
>>>> There will also be a new compatibility notice if your
>>>> *~/.textadept/init.lua* uses the old `buffer.set_theme(name, props)`
>>>> syntax. (Note the '.' instead of the new ':'.)
>>>> Cheers,
>>>> Mitchell
>>>> [1]:
>>>> [2]:
>>> just tested the nightly (W32) and I run into problems with unset style
>>> properties. Sometimes only "number" isn't set correctly, sometimes all
>>> but "string" is unset. Tried it several times, never got all my styles
>>> working at the same time. Strange (looking).
>>> I load my theme once (now buffer:set_theme(); called in init.lua), and
>>> change some of its properties afterwards ([] at
>>> "LEXER_LOADED"), if the conditions are met.
>> Would you please post your LEXER_LOADED event handler? I am not able to
>> reproduce with something simple like:
>>   events.connect(events.LEXER_LOADED, function(lexer)
>>     if lexer == 'ansi_c' then
>>     end
>>   end)
>> Cheers,
>> Mitchell
> Thanks for the quick reply :D
> Attached my actual "style.lua" (converted from Elastic Tabstops). It
> contains all the style related settings and is loaded at the end of my
> "init.lua". I tried to copy the related code parts first, but ended in a
> mess of ugly looking text.

I think I see the problem. Prior to your iteration over `HiDPI_styles`, try calling `set_style_property()` on your "default" key's values first. Then in your iteration skip over the "default" key when it comes up.

In brief, the change I committed yesterday "resets" all styles when the "style.default" property is changed. Scintilla (the editing component Textadept uses) intends for the default style to be defined first, and then have all styles "reset" so that they inherit from that default style. Without this "reset", on-the-fly theme switching via `buffer:set_theme()` would not be possible.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Mon 26 Mar 2018 - 11:26:42 EDT

This archive was generated by hypermail 2.2.0 : Tue 27 Mar 2018 - 06:47:33 EDT