Do yourself a favor and try to configure your shell without ohmyzsh first. You’d be surprised at how few plugins actually require it, and you save yourself from horrible performance.
Performance? If you are talking about the startup performance, no it doesn't bother me. Again, nothing is slowly enough to cause noticeable delays in basic typing/editing and the bottleneck is almost never on them. (I regularly work on codebase of hundreds to thousands of files or more.) So I don't spend time worrying about saving a few seconds in total per day when I can use my brain elsewhere.
I had slow starts when I added nvm completion to .zshrc and .. maybe conda environment but that was unrelated to oh-my-zsh
This was years ago, no idea how it is today. But I also have no reason to go back.
> I had slow starts when I added nvm completion to .zshrc
That too, but that’s unrelated. To me that was yet another reason to stop using node altogether, I wasn’t enjoying it anyway.
'Wansmer/symbol-usage.nvim' is one of them. I found that I didn't really need it as much so disabled it and LunarVim became much snappier.
All without using any “plugins” or ohmyzsh. All just within my .zshrc, and a few extra files that get “sourced” depending which computer I’m on. Only occasional copy-pasting a few things I liked from StackOverflow.
Basically instantaneous speed. Don’t even notice any performance penalties from all of the customization and styling.
I did have a performance issue early on, but I profiled my zsh startup time and saw 97.5% of my shell startup was consumed by NVM (node version manager), and another 2.4% was RVM (ruby). Switched to FNM and Chruby instead, and it was zippy.
And it’s all mine, so there are no “updates” to break anything. Throw it all in source control and you can keep improving it without risk of losing your previous working config.
But lately I've become really happy with just installing spaceship.
Sure, it doesn't look exactly like I want it to. But it shows git status.
Various features just "pop up" if I install the right things on the system.
My prompt is a 1 liner that shows your git branch as well as coloring up $ to be red or not based on if the last command failed. Coincidentally I just released a blog post today on coloring up your prompt based on if the last command failed at https://nickjanetakis.com/blog/color-your-shell-prompt-red-i... , there's solutions for both zsh and bash.
* Exporting shell variables such as HISTFILE isn't necessary, and can be unsafe. For example, if you decide to pop open unconfigured bash from within a zsh session it would intermingle its history on write.
* There is a smart keyboard subsystem that neatly manages terminal differences¹, making it much nicer compared to inserting {system,term}-specific escapes in to your config.
Hoping this comes across in the helpful spirit it was intended, not as nitpicky unwanted code review.
¹ https://zsh.sourceforge.io/Doc/Release/User-Contributions.ht...
* For shell history I don't think I've encountered that issue yet. For example if I have zsh loaded and run `bash` and then within that bash session run `whoami` and exit bash, my `history` within zsh doesn't include the whoami command, only `bash`. Is there another workflow that would produce intermingled history?
* Ah, this is likely in reference to the home / end / insert / etc. key binds I added? I think I came up with those from following a 2007 blog post[0] which I found here[1]. Do you know what the nicer versions would be for those specific keys? The docs are coming up empty with specific examples and most Google results return the escaped references.
[0]: https://blog.andrewbeacock.com/2007/08/how-to-get-home-end-k...
[1]: https://stackoverflow.com/questions/8638012/fix-key-settings...
export HISTFILE=trash
bash --norc
echo hello
exit
cat trash
The point wasn't just about HISTFILE really though, very few of the shells own configuration variables are useful in child processes. (LC_* and PATH being the obvious exceptions that spring to mind.)
---
For the second; The doc I linked to above shows how to use zkbd to handle terminal differences in a clean way. Run the wizard, and then you can use the $key array as in $key[Home]. The neat thing to do with zkbd is have the wizard run on startup when it can't find its definitions file, that way you'll get correct behaviour whenever you play with a new terminal type.
Another option is to use the terminfo database¹ directly, if you trust it to be correct for your terminals. "zmodload terminfo", and then the database is available through the $terminfo array as in $terminfo[khome] or using the echoti function².
¹ https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#The-...
² terminfo(5) contains the mappings, but they're often far less readable than the $key array. $terminfo[kpp] vs $key[PageUp], for example.
The dividing line between variables that should be prefixed by export are ones that are generally useful to child processes and ones that are not.
For example, $PATH is useful and should be exported. You probably want scripts you start to have access to all the things you have installed, not just the locations of the default search path:
PATH= =zsh -fc 'print -l $path'
Oftentimes it doesn't make much difference. However, some such as $CDPATH can cause non-obvious bugs when they're exported, and some such as $HISTFILE can cause data corruption or even loss when the planets align against you.
There was just enough time after your talk for 1 more question from the audience:
For my zshrc that you poked around in, is this issue related specifically to HISTFILE or all of the history related env vars?
Of course, their config is the best according to the benchmark (and ohmyzsh is the slowest option), but DIY configs are also covered, particularly possible performance optimizations.
Would recommend using a PS1 generator, e.g. [1].