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

From: Peter Rolf <>
Date: Mon, 26 Mar 2018 16:21:55 +0200

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.

Cheers, Peter

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 - 10:21:55 EDT

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