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

From: Mitchell <>
Date: Sat, 7 Apr 2018 19:01:56 -0400 (EDT)

Hi Peter,

On Wed, 28 Mar 2018, Peter Rolf wrote:

> Am 2018-03-26 um 19:00 schrieb Peter Rolf:
>> Am 2018-03-26 um 17:26 schrieb Mitchell:
>>> 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.
>>> Cheers,
>>> Mitchell
>> Yep, that fixed it!
>> Thanks again,
>> Peter
> I have noticed a problem with derived styles ("markdown"). When I just
> set the "standard" style for such a buffer (s. line 110, style.lua), I
> end up with the complete buffer in that style (totally uniform). I would
> at least expect the "h1-6" styles to be bigger.

If I understand you correctly, you are essentially calling `['style.default'] = ...` and then expecting the markdown styles to automatically adjust accordingly.

This is not supported. When 'style.default' is set, all other styles are reset to this style, but it is up to either you or your theme to set all of the other styles, including derived styles.

When the markdown lexer is loaded, its header styles use the current value of the 'fontsize' property variable (if it exists). If you want to adjust those styles after this initialization, you will need to set them again yourself.

I hope this makes sense.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Sat 07 Apr 2018 - 19:01:56 EDT

This archive was generated by hypermail 2.2.0 : Sun 08 Apr 2018 - 06:28:13 EDT