jedahan
commented
5 years ago Can you try this on https://github.com/jedahan/geometry/tree/mnml ? I'm going to delete the info-command branch as it is out of date
Closed psprint closed 4 years ago
jedahan
commented
5 years ago Can you try this on https://github.com/jedahan/geometry/tree/mnml ? I'm going to delete the info-command branch as it is out of date
psprint
commented
5 years ago It gives the same errors. Have you maybe started to use short_loops in the branch?
psprint
commented
5 years ago You can check if it reproduces for you – following will compile all files that zplugin-module compiles, probably all that are in use by default:
all=(
./async.zsh.zwc
./functions/geometry_docker_machine.zsh.zwc
./functions/geometry_exec_time.zsh.zwc
./functions/geometry_git.zsh.zwc
./functions/geometry_hg.zsh.zwc
./functions/geometry_hostname.zsh.zwc
./functions/geometry_jobs.zsh.zwc
./functions/geometry_kube.zsh.zwc
./functions/geometry_node.zsh.zwc
./functions/geometry_path.zsh.zwc
./functions/geometry_ruby.zsh.zwc
./functions/geometry_rustup.zsh.zwc
./functions/geometry_status.zsh.zwc
./functions/geometry_virtualenv.zsh.zwc
./geometry.plugin.zsh.zwc
)
for file in ${all[@]}; do zcompile "${file:r}"; echo $file:r compiled; doneAhh okay, so yeah I get the same errors you do, after compiling and opening a new tab
jedahan
commented
5 years ago Can you give it a shot now?
jedahan
commented
5 years ago Also if you know a way I should be using bindkey better than just mapping '^M' I'm all ears!
psprint
commented
5 years ago It works now, cool. I have a more "private" issue thought – I simulate initial precmd call, set up with:
% grep precmd geometry.plugin.zsh
add-zsh-hook precmd geometry::clear_title
add-zsh-hook precmd geometry::promptI do call them in zplugin's atload'' hook:
atload.geometry:: ~/.zshrc mnml 15h::⬡
zplugin ice load'![[ $MYPROMPT = 4 ]]' unload'![[ $MYPROMPT != 4 ]]' atload"geometry::clear_title; geometry::prompt" lucid # ver"mnml"But I don't get the prompt until first command being run, like it is shown in this video:
https://asciinema.org/a/XNtEXTtNiRTNGMsvilo8X9vce
Do you maybe know what else geometry runs through some hooks, that might be causing this?
jedahan
commented
5 years ago geometry::rprompt is also run once when sourcing geometry.zsh, maybe that needs to be run?
jedahan
commented
5 years ago Did running geometry::rprompt fix things?
psprint
commented
5 years ago No, sadly no
jedahan
commented
5 years ago does it work if you manually source geometry.zsh in your zshrc instead of using zplugin? just trying to narrow down where the issue may be
psprint
commented
5 years ago Yes it worked. All this resulted in a diagnosis:
chpwd hookchpwd to be called, so say that "order of loaded plugins doesn't matter" (precisely: fsh-auto-themes was being loaded before zdharma/fast-syntax-highlighting, a risky act, as it depends on F-Sy-H)To solve this geometry should use -q option with cd – it suppresses side-effects. I've had this situation with zplugin, and I also suppress "autopushd" option effects by:
() { setopt localoptions noautopushd; builtin cd -q "$local_dir/$dirname"; }But a solution would also be to use pushd and then popd builtins.
I can now test the new geometry 😄
jedahan
commented
5 years ago Awesome debuggging! I pushed it to https://github.com/jedahan/geometry/commit/e7b9e87dfcdba140fb76cdf708275fdd88eb15b4
jedahan
commented
5 years ago How are things looking @psprint ? Any other bugs/questions/suggestions?
psprint
commented
5 years ago I've ran the new geometry for a few days (7-10), but switched back to normal version, because of the blue, not blue-bold for the path ;). I've also had an impression of changes in the arrangement of the information of the prompt, i.e. visual locations of the bits of information, but running the jedahan/geometry plugin now shows that there are no changes in the arrangement. Maybe the updates (I'm running zplugin update --all quite often) restored the normal-geometry visual arrangement, I don't know.
In general, I've felt bad after switching to the jedahan/geometry, because it was taking away the normal-geometry of confirmed-value... So I couldn't keep up using it for more than 7-10 days.. :unamused: I can switch now again after I'll figure out how to change the color of the path to light-blue (from blue).
jedahan
commented
5 years ago Thanks for the feedback, and giving it another try.
It sounds like there are two main issues, correct me if I am wrong:
The path status color changed. Do you mean the ▲ or the actual path like ~/some/dir? The status symbol color can be set with GEOMETRY_STATUS_COLOR, and if you are on a terminal with 256 colors you can choose a number instead of a word. If this does not do what you want, what would be ideal?
I am not sure what you mean, but this sounds important: normal-geometry of confirmed-value being taken away. Could you show me an example?
psprint
commented
5 years ago blue color of the path in the prompt.psprint
commented
5 years ago I've run zplugin report on the jedahan/geometry theme, it might be interesting to you, here's the result:
There's seem to be no *color* variable other than the *TIME* parameters:
zplg report jedahan/geometry | grep -i color master 5d::●::⬡
GEOMETRY_TIME_COLOR_SHORT [ "" -> scalar ]
GEOMETRY_TIME_COLOR_NEUTRAL [ "" -> scalar ]
GEOMETRY_TIME_COLOR_LONG [ "" -> scalar ]Although some variables could be created at runtime, e.g. in precmd hook, although GEOMETRY<tab> doesn't yield any. Setting GEOMETRY_COLOR_DIR doesn't cause the current-path to change like the README says.
What is a way to configure the dir color?
jedahan
commented
5 years ago Most plugins try not to export their environment variables to help reduce pollution. From geometry_path, GEOMETRY_PATH_COLOR is the thing to be set. I will add it to the readme. Do you have suggestions on how to make it easier to find out what can be set without polluting env with hundreds of variables?
▲ echo "$functions[geometry_path]"
local dir=${GEOMETRY_PATH_SYMBOL_HOME:="%3~"}
(( ${GEOMETRY_PATH_SHOW_BASENAME:=false} )) && dir=${PWD:t}
ansi ${GEOMETRY_PATH_COLOR:=blue} $dirI also wonder how I can hide all the _{rebase,stashes,etc} functions
psprint
commented
5 years ago Most plugins try not to export their environment variables to help reduce pollution. From
geometry_path,GEOMETRY_PATH_COLORis the thing to be set. I will add it to the readme. Do you have suggestions on how to make it easier to find out what can be set without polluting env with hundreds of variables?
Zstyles are for this. So e.g.:
# To set:
zstyle :plugin:geometry:color path_dir 131
# To read:
zstyle -s :plugin:geometry:color path_dir my_path_dir || my_path_dir="some-default-value"I've missed the zstyle-way too, in Zsh-Navigation-Tools, there're many znt_* variables ( like:znt_list_instant_select=1 or znt_list_border=0). However, the upper-case global parameter way feels more natural.
There's no way to hide the functions. I once posted on zsh-workers mailing list about the need of namespaces for functions, but it didn't catch-on any attention and/or response.
PS: Maybe you have an idea how the functions-namespaces or functions-hiding should work? You could post to zsh-workers about this.
PS2: The good thing is that function name can consist of probably literally any ASCII character, even e.g. ], so you could namespace the function this way (so \]rebase() { echo Hello; } in the synthetic [-based example).
jedahan
commented
5 years ago Though zstyle is cool, I would rather people be able to use geometry with as few new concepts to learn as possible.
The downside of putting environment variables inside functions is they are hard to discover. I might be convinced that its better for discoverability by putting them outside functions, even if that does pollute the environment.
I think at one point there was another benefit to the environment variables being outside the functions, where you could change them on the fly and it would update everywhere, but that might not be the case now.
Regarding namespacing functions, I also think geometry:: could be fine. Right now I do like that geometry::* is "internal" functions, and geometry_blah are just default functions provided by the project, because the visual separation is nice, and people might think that :: has some special meaning when it really doesn't.
functions-hiding and functions-namespaces I think should really only exist with the same scoping rules we have for variables right now. That is, if i want to hide some internal geometry function, I should just define it within the scope of the enclosing function. Even if I have to define twice, oh well.
psprint
commented
5 years ago Yeah, the fever concepts issue, I agree. Although the nice looking of the :-separated path, i.e. ":plugin:geometry:color" might be worth adding a concept.
I've recalled one other way – a global hash. Like in Zplugin, where I use $ZPLGM, i.e. "z-plugin-map" for internal use and for user's customization. The issue – user has to adopt a skill (global hash variable definition, understanding what happens if one writes to the hash and then again calls declare -A...). However the internal-use is a nice thing. For example in fast-syntax-highlighting I'm using a global hash FAST_HIGHLIGHT for everything, like cache of available git commands, user-exposed flags (like use_async field). I've checked now and the hash has 287 keys, head of the keys list:
chroma-git-call-nr
cache-path-info-7072-born-at
cache-path-info-7814-born-at
cache-path-string-7156-born-at
cache-path-/dev/null-7822-born-at
cache-path-n-history-18
cache-path-info-7163
cache-path-0-7106-born-at
chroma-git
chroma-pip
cache-path-\=-1275
cache-path-20000-8690-born-at
cache-path-addwin-7065
ointeractive_comments
cache-path-\=-8109I'm going to close this issue for now, and we can investigate exposing environment variables, and renaming them in the future. Thanks for all your patience and testing @psprint!
psprint
commented
5 years ago I'm running jedahan/geometry prompt for the last 7 days and don't occur any problem. One more thing for the global-param-home-hash, I can give the key count for zplugin (as FAST_HIGHLIGH consists only from cache fields):
% print -rl -- ${#ZPLGM}
108 # (on a fresh session: 87)
% print -rl -- ${(k)ZPLGM}
col-bar
col-rst
alias-map-psprint/fsh-auto-themes
alias-map-zdharma/zsh-diff-so-fancy
alias-map-%/Users/sgniazdowski/gitlab/zsh-tag-search.git
TIME_19_iwata---git-now
WAIT_IDX
TIME_INDEX
TIME_17_psprint---vramsteg-zsh
UPAR
col-pname
TIME_22_zdharma---git-url
alias-map-Fakerr/git-recall
TIME_6_psprint---zsh-editing-workbench
SHADOWING
TIME_4_zdharma---zconvey
WAIT_ICE_10
...So this method is really handy in having parameter-availability freedom (except for hashes & arrays, but I'm doing serialization/deserialization and store them anyway, e.g. under the key WAIT_ICE_10, there's a serialized hash stored, via the method: http://zdharma.org/Zsh-100-Commits-Club/Zsh-Native-Scripting-Handbook.html#serializing-data) and non-polluting the global namespace.
BTW. Maybe I could test some new subsystem of the new geometry or stress-test an subsystem?
jedahan
commented
5 years ago Thanks for reporting back! Glad to hear things are stable now. I really wanna coordinate a release with the rest of the team soon. Hopefully with lots of screenshots :)
The serialization/deserialization is really cool, but since geometry really does so little I can't think of what makes the most sense to hide :)
The weirdest bugs are still when rendering single-width emoji, which are really apparent in tab-complete.
Other stress tests could be zle bind conflicts, and performance issues.
And investigating replacing our custom git plugin with vcs_info (if its fast enough).
Oh any possibly replacing our use of grep/rg/ag with (m) but I don't think we need to.
psprint
commented
5 years ago Hello,
I have run the zplugin-stress-test command on jedahan/geometry:
▲ ~/github/zplugin.git zplg stress jedahan/geometry master 1d::●::⬡
Stress-testing geometry.plugin.zsh for option NO_SHORT_LOOPS [Success]
Stress-testing geometry.plugin.zsh for option IGNORE_BRACES [Fail]
Stress-testing geometry.plugin.zsh for option IGNORE_CLOSE_BRACES [Fail]
Stress-testing geometry.plugin.zsh for option SH_GLOB [Success]
Stress-testing geometry.plugin.zsh for option CSH_JUNKIE_QUOTES [Success]
Stress-testing geometry.plugin.zsh for option NO_MULTI_FUNC_DEF [Success]```So the plugin won't work if someone enables the two *BRACES* options. The function that does the stress test is fairly simple, I;m pasting it so that it is known that what actually happens during the tests:
local -a ZPLG_STRESS_TEST_OPTIONS
ZPLG_STRESS_TEST_OPTIONS=( "NO_SHORT_LOOPS" "IGNORE_BRACES" "IGNORE_CLOSE_BRACES" "SH_GLOB" "CSH_JUNKIE_QUOTES" "NO_MULTI_FUNC_DEF" )
(
builtin emulate -LR ksh
builtin unsetopt shglob kshglob
for i in "${ZPLG_STRESS_TEST_OPTIONS[@]}"; do
builtin setopt "$i"
builtin print -n "Stress-testing ${fname:t} for option $i "
builtin zcompile -R "$fname" 2>/dev/null && {
builtin print "[${ZPLGM[col-success]}Success${ZPLGM[col-rst]}]"
} || {
builtin print "[${ZPLGM[col-failure]}Fail${ZPLGM[col-rst]}]"
}
builtin unsetopt "$i"
done
)The plugin gemoetry-zsh/geometry passes all the tests.
▲ ~/github/zplugin.git zplg stress geometry-zsh/geometry master 1d::●::⬡
Stress-testing geometry.plugin.zsh for option NO_SHORT_LOOPS [Success]
Stress-testing geometry.plugin.zsh for option IGNORE_BRACES [Success]
Stress-testing geometry.plugin.zsh for option IGNORE_CLOSE_BRACES [Success]
Stress-testing geometry.plugin.zsh for option SH_GLOB [Success]
Stress-testing geometry.plugin.zsh for option CSH_JUNKIE_QUOTES [Success]
Stress-testing geometry.plugin.zsh for option NO_MULTI_FUNC_DEF [Success]Also, I'm using the new plugin without problems starting from the last conversation.
jedahan
commented
5 years ago I think I fixed this in the latest mnml branch.
It would be cool to add tests to either the dockerfile or somewhere else.
All I did was manually do setopt ignore_braces; zcompile -R geometry.zsh and zcompile -R functions/*zsh....
jedahan
commented
5 years ago err, the mnml branch on https://github.com/jedahan/geometry
jedahan
commented
4 years ago should be fixed
psprint
commented
4 years ago Yes I've checked, both geometry-zsh and mnml pass the stress test.
After I invoke
git checkout info-command, thenfind . -iname '*.zwc' -exec rm -f \{\} \;, then I get error:("READY >" is my prompt). Then, if I run the prompt second time, I get many errors:
What happens before 1st and 2nd run is that
zpluginbinary module automatically compiles anysource'd file. So each of geometry's components gains a .zwc file.After those errors, if I invoke
READY > cd .., I can see the prompt rendered (has a blue color for path, doesn't it). Entering a git repo triggersRPROMPTalso correctly.If I starth zsh without zplugin-module, and then remove the
zwcfiles and compile everything manually via:then the problem still persists. What can be wrong?