choosing varnames in output about shrinko8

[thisismypassport]

Implemented - let me know if there are any issues, I didn't test it too thoroughly.

[pancelor]

I did custom names last year for my minesweeper 1k demake by not using shrinko8 renaming at all, and using sed instead:

This was clunky, and now that shrinko8 is much smarter about choosing compression-friendly names it'd be a shame to bypass the system entirely.

Is there some way I can use custom python scripts for this somehow...? Or maybe use specific easy-to-sed names like _var1_ and _var2_ in test.lua, --preserve them during shrinko8 and then add a sed step afterwards (sounds tricky -- how would I be sure that the final name I choose hasn't been already taken by shrinko8? Also, --preserve doesn't seem to preserve function argument names like b in function(b) in test.lua)

[pancelor]

Here's our previous discussion, for reference: https://discord.com/channels/215267007245975552/999490991524429895/1121957790294999071

Summary:

1. What's the interface for telling shrinko8 how to rename things? (no solid answer)

thisismypassword: Basically we have 3 possible desires here:
thisismypassword: - Minifying with fixed rename instructions
thisismypassword: - Unminifying with custom rename instructions
thisismypassword: - Unminifying with the rename map generated during minify
thisismypassword: I was hoping to have one implementation doing all 3, but it doesn't seem like it'd be helpful

3. maybe pico-ls for vscode can do renaming? it's still manual but might be a bit easier

[thisismypassport]

Hmm - I think the only sane way to specify which local to rename is by adding a comment next to it. (Like you tried in the other issue)

E.g. I could imagine adding a comment like this:

function f(--[[rename::x]]my_param) return my_param end

That would become

function f(x) return x end

Would that be useful?

[thisismypassport]

More notes:

It is a bit annoying that --[[rename::...]] would affect all usages of a var, while --[[preserve]] affects only one instance...
But I assume --[[rename::...]] is more than verbose enough, so you wouldn't want --[[rename-var::...]] or --[[rename-all:...]]

I'm semi-considering to deprecate the use of --[[preserve]] on identifiers, except I'm not sure how to call the new name for the hint - --[[preserve-occerence]] is excessive (and there is a valid usecase for --[[preserve]] on identifiers as seen in the readme)

I'd be glad to hear what you think.

[pancelor]

Deprecating/renaming --[[preserve]]: that sounds good. I think my misunderstanding (from #27) stemmed from the fact that --preserve in the commandline affects all occurences, so I assumed --[[preserve]] inside lua would act similarly.

I like the idea of renaming it; maybe --[[preserve-once]] or --[[preserve-single]]? In the example from the readme (tweetcart circfill/rectfill) it seems fine to me, and that specific use-case seems rare.

[pancelor]

--[[rename::x]]: yes, that would be excellent! I remember suggesting something like this but decided against it in discord:

maybe inline rename hints of some sort would be more natural
something like this? urg, also gross. I didn't even do the whole thing

--[[rename TILE_CHEESE]]n=5
function --[[rename make_cheese]]e(--[[rename cx]]l,--[[rename cy]]u,--[[rename tile]]t)
local --[[rename act]]e={
  --[[rename kind]]l="cheese",
e=t or n,
c=l,
o=u,
u=true
}
function e:t()
local n=self.e+time()\1%2*16
local e,o=c(self)
spr(n,self.c*8+e,self.o*8+o,1,1,self.r)
end
return add(o,e)
end

I think it would be unusable if I wanted to rename every variable, but in that case maybe I should use sed instead.

In this case and others like it (just wanting to rename a few specific things) an inline annotation would work great!

[pancelor]

Thank you! unfortunately I have returned with some bugs:

-- > cat bug1.lua
x=0 ::loop:: --[[rename::o]] y=32 goto loop

-- > shrinko8 --minify bug1.lua - -f lua
o=0::o::o=32goto o

-- > cat bug2.lua
list={{a=1}}
for --[[rename::o]] outer in all(list) do
  for inner in all(list) do
    outer.a=2
  end
end

-- > shrinko8 --minify bug2.lua - -f lua --no-minify-spaces
o={{o=1}}
for  o in all(o) do
  for o in all(o) do
    o.o=2
  end
end

-- > cat bug3.lua
--[[rename::a]]x=1 y=2

-- > shrinko8 --minify bug3.lua - -f lua
a=1a=2

-- > cat bug4.lua
x=1 --[[rename::a]]y=2

-- > shrinko8 --minify bug4.lua - -f lua
a=1a=2

...unless this is some sort of optimization, because it notices the variables aren't used? but bug1 and bug2 are distillations of actual bugs in my game, and adding prints to use the vars doesn't remove the bug (I checked bug1 and bug4 only)

[thisismypassport]

Whoops - I knew I didn't test it thoroughly enough 😄
Pushed a fix now, fixes the above. LMK if there are still issues.

[pancelor]

works great! saved me 3 bytes :D
(for context, I'm at the stage where small reorderings tend to add 6~12 bytes for no apparent reason. ghosts moving between MTF and REF sections, I assume...)