Colorscheme collection about tym

[r3lgar]

https://terminal.sexy

I think, for better theming, you need a separate table for colors (and font?) instead of using Lua's crappy dofile (it's not as ugly as unsafe).

[endaaman]

@r3lgar

I also feel Lua's dofile is a bit inconvenient.

As a developer of terminal, I want users to feel easy to check, try and share themes. Ideally, I think it is best we can write a simple config like following and get ANY themes in the world.

tym.theme('monokai')

Of course I will leave the way to write directly like color_0 = #..... But I think most people do not want to see something they feel complex like theme definition. So easiness is needed.

Tentatively, I'm thinking about some ways.

1. Fetch from web

On first running, a theme is fetched from web and cached on local. Theme definitions are placed in appropriate repository (e.g. themes dir of this repo).

This way complicates codes because I need to do network programming. Or, if we distribute this system as a plugin (written in Lua) or a supporting CLI utility, it may get easier.

2. Containing themes in a package

Containing /usr/share/config/*.lua files in a package. Theme loading function does just load from there. In this case tym.theme('hoge') will do file /usr/share/tym/themes/hoge.lua. Users can decide whether or not to install themes by --with-themes param of configure script.

This ways need users to hold all themes in their local machines.

Which is best?

Which is best as a system? And I also do not know the best way to write the config with Lua. Please let me know the most comfortable config for you and how you think about this.

[r3lgar]

@endaaman

On first running, a theme is fetched from web and cached on local.

It's not a good idea. tym is a simple terminal (and I love it!).

Users can decide whether or not to install themes by --with-themes param of configure script.

Or you can use a separate repo for themes only (and use it as submodule). In both cases, maintainers and users can do what they need.

In this case tym.theme('hoge') will do file /usr/share/tym/themes/hoge.lua.

Anyway, you need a separate table for the theme (or any plain format). You need to sure that themes doesn't break things from config.

Which is best as a system?

As I said before, tym is a simple terminal, not a web application, KISS. You can implement some API for hacking with Lua, and we can write a plugin for fetch themes from web.

And I also do not know the best way to write the config with Lua.

• Simple table with colors and font:

theme = {
  	font = "Terminus 11",
	allow_bold_font = false,
	cursor_blink_mode = "off",
	color_foreground = "#b9bbbd",
	...
	color_15 = "#ffffff",
}

• As above, but with subtable for base colors:

  	font = "Terminus 11",
	allow_bold_font = false,
	cursor_blink_mode = "off",
	color_foreground = "#b9bbbd",
	...
	base_colors = {
		-- Keep in mind that the Lua table starts with 1, not 0!
		["0"] = "#000000",
		...
		["15"] = "#ffffff"
	}
}

Anyway, we can convert 2nd to 1st:

if theme.base_colors then
	if type(theme.base_colors) == "table" then
		for k, v in pairs(theme.base_colors) do
			theme["color_" .. k] = v
		done
	end
	theme.base_colors = nil
end

[endaaman]

First of all I have to tell you that tym's config loading process is as follows:

1. Create an internal hash table
2. Set the default values to the hash table
3. Define global config table on Lua VM
4. Copy the values of hash table to config table
5. Run config.lua
6. Copy the values of config table to the internal hash table
7. Start App

(* If provided -u NONE, step 3 .. 6 will be skipped)

For this reason

config = {
  hoge = 'fuga'
}

above code is inappropriate. Because it will destroy default values. Even if it is split into the theme table, if it contains any meaningful default value, it is also inappropriate.

I think this specification is suitable. Because, due to it, users who do not carefully read documents can know what options are available and what the default value is just by looking at the contents of the config table. I'd like to provide a way to know how to write config without reading documents.

Conversely, if the default value is meaningless(only color_* and font(not sure) ), your config style like following is available.

theme = {
  font = 'Monospace 12'
  color_foreground = "#f00",
  ...
  color_15 = "#ffffff",
}

You need to sure that themes doesn't break things from config.

I am still not sure about this. The line like config.title = 'shit' may break the existent config even if it is written in a theming script file.

[r3lgar]

above code is inappropriate. Because it will destroy default values. Even if it is split into the theme table, if it contains any meaningful default value, it is also inappropriate.

I wrote my theme = {...} example only for clarity.

The line like config.title = 'shit' may break the existent config even if it is written in a theming script file.

Yes, by now. It's because you dofiled your theme in config.lua. Separate files, then separate the logic, and you will get more or less safe way to use themes (even from a third party).

---

Crazy idea: tym.periodic(int, function) for automatic change the theme by time (e.g. day/night colors) ☺;

[endaaman]

Separate files, then separate the logic, and you will get more or less safe way to use themes (even from a third party).

Or, how can this be implemented? Do you want to have multiple entry-points (e.g. config.lua and theme.lua) and make them have separated global contexts? I do not agree with this way. There should be one entry-point and one global context.

[r3lgar]

Do you want to have multiple entry-points (e.g. config.lua and theme.lua) and make them have separated global contexts?

Not exactly.

I do not agree with this way. There should be one entry-point and one global context.

All I want to say is, you need to be sure that theme can't modify user's configuration (and user can be sure that he/she will not receive unexpected settings).

[endaaman]

@r3lgar

I may understand. If there is a single table for configuration, people may accidentally write themeing script like following.

-- correct
config.color_hoge = '#f00'

-- accidentally written, wrong and harmful
config.hoge = '#f00'

You mean If we separate table we never mistake?

-- correct
theme.color_hoge = '#f00'

-- wrong but not harmlful
theme.hoge = '#f00'

Did I say it right?

[r3lgar]

You mean If we separate table we never mistake?

We can do mistakes with no pain when tym parse config/theme.

With separated tables, you never get a critical error by a stupid typo, it just never handled by tym.

Did I say it right?

Yes. :3

[endaaman]

@r3lgar

I was thinking what is the best config in the bath, then I found a convincing way.

Proposal for new theming system

theme.lua

Prepare ~/.config/tym/theme.lua in addition to ~/.config/tym/config.lua.

After executing config.lua, if theme.lua exists, read it. How to write theme.lua is

return {
  color_1 = "#f00",
  color_background = "#0f0"
}

It may be more concise that there is no prefix color_, but the style{["1"] = "#f00" '} is a bit annoying and ugly. I'd like to make it work even if I write it like color_cyan, but its implementation is on the back burner :)

And as in the past, config.lua can be written in the style of config.color_XXX = "#f00" because not everyone uses theme.lua.

tym.reload_config() completely reloads config.lua and theme.lua. New API tym.reload_theme() reloads only theme.lua.

Only this is the change of specifications directly related to tym.

tym-theme command

In addition to this, make a script tym-theme (I think it is better to be written in bash). The script is completely optional.

$ tym-theme install <name>

Download (using curl or wget) <name>.lua over web (tym-theme repository or themes directory of this tym repo) and save it in ~/.config/tym/themes/<name>.lua

$ tym-theme select <name>

Put a symbolic link from ~/.config/tym/themes/<name>.lua to ~/.config/tym/theme.lua.

If tym is running at that time, reflect the theme in each process. However, for this feature, dbus is required for interprocess communication, so this immediate-theme-reflection feature may be good to be created later.

If ~/.config/tym/theme.lua is not a symbolic link for ~/.config/tym/themes/*.lua or when an operation that can destroy the user's setting is attempted, a warning is strictly issued.

And It is fine if you have $ tym-theme list or $ tym-theme delete <name> etc.

How about these spec?

---

Additional note:
~/.local/share/tym/themes/<name>.lua may be better than ~/.config/tym/themes/<name>.lua

[r3lgar]

@endaaman

I'd like to make it work even if I write it like color_cyan, but its implementation is on the back burner :)

I can write a script that will convert from human-readable config to { ["1"] = "#f00" } or something. Or do you want to make tym a Swiss Army knife? (=

I think it is better to be written in bash

If you want tym-theme to work in BSD, it should be POSIX-compatible, because bash is not installed out of the box. I can test it if you want.

for this feature, dbus is required for interprocess communication

Or you can use UNIX sockets (in ${XDG_RUNTIME_DIR}). ^_~

~/.local/share/tym/themes/<name>.lua may be better than ~/.config/tym/themes/<name>.lua

I think, ~/.config/tym is for user-defined things, ~/.local/share/tym for downloaded themes and so on.

[endaaman]

@r3lgar

I can write a script that will convert from human-readable config to { ["1"] = "#f00" } or something. Or do you want to make tym a Swiss Army knife? (=

Internally, config values are stored to a single hash table under the key 'color_XXX' along with other config values like 'title' and 'width' etc (because they can be set by tym.set('color_XXX', '#f00') ), so theme table is returned in that style from Lua (for simplicity of code).

And a transformation process ( { red = "#f00" } → { color_9 = "#f00" } ) should not be bundled in tym (to keep tiny).

Therefore, the process should be written in tym-theme ... ?

If you want tym-theme to work in BSD, it should be POSIX-compatible, because bash is not installed out of the box. I can test it if you want.

And we can write it in Lua with #!/usr/bin/env lua (we can distribute it via LuaRocks as well).

Or you can use UNIX sockets (in ${XDG_RUNTIME_DIR}). ^_~

I should’ve come up with UNIX domain socket! ( though we may need a bit more complicated coding... )

I think, ~/.config/tym is for user-defined things, ~/.local/share/tym for downloaded themes and so on.

OK. I will use ~/.local/share/tym.

[r3lgar]

{ red = "#f00" } → { color_9 = "#f00" }

I think it doesn't matter if everything is well documented.

If users need a user-friendly terminal emulator, they'll choose terminal emulator with GUI.

we can distribute it via LuaRocks as well

It will be better to put it in this repo and install it with the tym itself.

I should’ve come up with UNIX domain socket!

With UNIX socket, we can manage everything in tym from the outside (even switch themes for day/night).