AwesomeWM: To replace/override type() or not?

[psychon]

AwesomeWM replaces Lua's type function so that e.g. type(screen[1]) will return "screen" (see luaAe_fixups and luaAe_type in luaa.c). In way-cooler, this will result in "table" instead.

This breaks e.g. the compatibility stuff in awful.taglist.new: In older versions of awesome, this function got six arguments which all were basically optional. These days it gets a table instead in which it looks up its arguments. Based on type(first_argument) == "screen" it provides backward-compatibility with the old arguments list. Since the rc.lua that comes with way-cooler uses an old-style call... well, I got a cryptic error about table index is nil in a line that used a screen as a table index because the code tried to use argument.screen as the screen, where argument was already supposed to be a screen.

[Timidger]

Hmm, that is a problem.

I'm hoping that we can eventually have the same structure as old awesome if the points I made in this old issue are addressed. Since there's little response there (unsurprising with the holiday season, and it is an old "solved" issue) I'm thinking I'm might try to tackle it next week and send a pr to them. The main thing is trying to achieve it safely, since it won't be merged if it exposes a safety hole in the library.

If that doesn't work out, there probably is a way we can get the custom type checking working with the table. I'd rather fix the underlying structure though, because I think this issue is going to keep coming up for us otherwise.

[Timidger]

This should be fixed thanks to this change in rlua. We just need to propogate it here by changing how we store the types as uservalues rather than the tables. Then we don't need to override type.

[psychon]

Then we don't need to override type.

Uhm, yes, you do. As far as I know, Lua's built-in type always identifies userdata as "userdata". That's why awesome explicitly overwrites _G.type with its own function.

[Timidger]

Whoops, sorry. Read this issue too quickly last night and obviously wasn't awake enough.

Yes we'll still need to override type

[psychon]

This should be fixed by 5003763. Sorry, I forgot to refer to this issue in the commit message.