A variable `fun` gets defined

Question

A variable `fun` gets defined

psprint opened this issue 5 years ago · 8 comments

Hello,
zplugin report revealed that a rather unintentional variable gets defined:

Answer 1 · 2019-09-09T04:30:28.000Z

hmm I wonder if there are better solutions than

. <(cat "${GEOMETRY_ROOT}"/functions/geometry_*.zsh)

or

for fun ("${GEOMETRY_ROOT}"/functions/geometry_*.zsh(N.)) . $fun; unset fun

Answer 2 · 2019-09-09T13:44:04.000Z

You can declare the fun var local :)

Answer 3 · 2019-09-09T13:56:00.000Z

Hmm I had to do geometry::load() { local fun; for fun ("${GEOMETRY_ROOT}"/functions/geometry_*.zsh(N.)) . $fun }; geometry::load for local to stick. Wish I could just have it be an anonymously invoked function.

Answer 4 · 2019-09-09T14:10:03.000Z

Ahso, so it was declared at global scope earlier, what would help when loading in a plugin manager but not when sourcing? pon., 9 wrz 2019, 15:56 użytkownik Jonathan Dahan <notifications@github.com> napisał:

…

Hmm I had to do geometry::load() { local fun; for fun ("${GEOMETRY_ROOT}"/functions/geometry_*.zsh(N.)) . $fun }; geometry::load for local to stick. Wish I could just have it be an anonymously invoked function. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#269?email_source=notifications&email_token=ABOE4CESBG7WZK5RK22B2Q3QIZIXDA5CNFSM4IUVKDQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6HVHKQ#issuecomment-529486762>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABOE4CGOEWNJ67L23XS5V43QIZIXDANCNFSM4IUVKDQA> .

Answer 5 · 2019-09-09T15:44:57.000Z

What is the difference between loading in a plugin manager and sourcing?

Right now, when you source geometry.zsh, it will source everything in functions. I am open to doing something with fpath/autoload if there are tangible benefits but all my previous tries have failed using those.

Answer 6 · 2019-09-09T18:30:08.000Z

Plugin manager will load with a function, so local parameters will go out of scope.

Answer 7 · 2019-09-09T21:39:33.000Z

Ahh yeah but we want all local parameters to go out of scope if possible I think. Does the current version of geometry have other obvious deficiencies?

Out of that list of variables, ideally the user would only see GEOMETRY_PROMPT, GEOMETRY_RPROMPT, and GEOMETRY_INFO. I wonder if there are good ways to hide the other variables. Unfortunately they are all state that needs to exist outside of the prompt render loop.

Answer 8 · 2019-09-10T00:25:43.000Z

I've recently drastically reduced the number of variables used in Zplugin by changing A_MAP[A_$KEY] into ONE_MAIN_MAP[A_MAP__A_$KEY]. Basically, with this technique, all possible variables can be put into a single map. I've had the comfort that I was having only maps, not integer-indexed arrays to reduce this way, so I've even used vim patterns with $…$ in them and substituted, but in general, even integer-indexed arrays are possible to be reduced with this method. For arrays I would however rather serialize/deserialize them rather than use the above method.