The high count for times that compdef is run indicates that this run is without a cache for compinit. The lack of calls to compdump also indicates that it isn’t creating a dump file. This cache, speeds compinit startup massively. I’m not quite sure how the blog post author has contrived to not have a dump file.
“contrived” is a rather strong word to use here and suggests intent (perhaps to deceive). I’m not sure if it was your intent or not.
This actually is with a dump file. A .zcompdump-MACHINENAME file is created in ~ (see here).
The issue is that this is recreated each time the shell starts up. There are multiple places in OMZ that call compinit. In the additional reading at the bottom there is a link that modifies zsh to only recreate it once a day, but I still feel like that’s not ideal.
Can you redefine compinit to a no-op during OMZ loading, and then do it yourself at the end?
IMO zshrc should explicitly call compinit so it happens exactly once in a central location.
I use vim and a text file but for some passwords, rather than store the password in clear, I have to run pwgen with -H and it regenerates the password.
Quite probably - I’ve used that too quite a bit - https://zwischenzugs.com/2017/12/18/project-management-as-code-with-graphviz/ - have you done this before/seen this written up?
But Zsh does have a visual mode! Don’t rebind v to something else. Pick something else: I use ‘^X^E’.
I’ve seen this bind v to edit-command-line advice before, probably because oh-my-zsh does it. I can only guess that the existence of visual mode simply isn’t obvious because by default it is highlighted in a manner that is indistinguishable from the cursor. My advice is to pick something more obvious and set it in zle_hightlight. Note that much of the zsh documentation talks about the “region” which is emacs terminology.
Does Zsh have a visual mode? If so it’s not on by default, or at least by default it’s not mapped to v in command mode. I also could not find any documentation on Zshell visual mode. Can you provide links to any documentation or articles on this? Closest thing I found was a Zshell plugin that implemented this behavior (https://github.com/b4b4r07/zsh-vimode-visual).
Go to http://zsh.sourceforge.net/Doc/Release/Zsh-Line-Editor.html or type man zshzle and search for the word “visual”. There are several references. The feature was added three years ago. In general for vi-mode I would recommend using at least 5.0.8 and preferably 5.1 or newer as a lot of vi/vim related improvements were made around the time of those releases. To verify, run zsh -f and try bindkey -a v and you should find v is bound to visual-mode. There’s also visual-line-mode for V and a visual keymap.
Wow! How did I miss that?! That’s really nice, and much faster than opening Vim. I will remove my custom mapping and update the blog post accordingly.
It looks like you’re using oh-my-zsh. The vi plugin seems to remap v: https://github.com/robbyrussell/oh-my-zsh/blob/3705d47bb3f3229234cba992320eadc97a221caf/plugins/vi-mode/vi-mode.plugin.zsh#L20
I actually decided against using that vi plugin for some other reasons, so at least in theory v should be mapped to the default command.
I don’t get this sort of thing at all. For me, j and k motions are used constantly, and I don’t know of any other commands that substitute well. I even set up J and K to be 10j and 10k, respectively, because I often find { and } not that useful. I don’t want a plugin to turn them off, because I’m not sure what they plan to replace them with.
Meanwhile, I very rarely use h and l. I find them super-tedious to move more than a few chars at a time. I don’t see why anyone would use them over w and b. I don’t need a plugin to convince me not to use them - I’m already convinced.
Meanwhile, I very rarely use h and l. I find them super-tedious to move more than a few chars at a time.
What do you do if you want to change something like FooBarFoo to FooFooFoo or similar middle-of-the-identifier edits where w/e don’t consider the terms distinct? I seen people recommend f<letter>c<motion> but I’ve always thought counting letters to use with the f motion takes more time than leaning on h/l. Similar story for forward/backward search when your target is on the same line.
;' repeats the last f/F/t/T motion, and,’ does the same in the
opposite direction. If I’m in a situation where counting would be
necessary, it’s sometimes faster to spam ;' a few times, and if I accidentally pass it, use,’.
It’s not elegant, but it works well for those situations where you expect `fB’ to match but it doesn’t.
e.g. to s/FooBarFoo/FooBarQuux/, `fF;cwQuux’.
Usually there’s other motions that’ll work in context too, depending on what text surrounds it.
I would do fBctF for that. I find it easy because I’m already thinking about “I want to change Bar to Foo right up to the next Foo”, so the letters to to f and t to come to mind easily. If I’m h/ling, then I have to either try to count letters, which is distracting, or hold one down, probably overshoot and need to go back, which is also distracting. The whole thing I like about Vim is how, once you commit certain things to instinctive memory, you spend very few mental cycles thinking about how to make an edit you want to make or waiting to switch between mouse and keyboard.
It’s also cool that Vim is almost a completely different program for everyone who uses it and can fit many different mental models about how to edit text.
Does anyone know the longish term ramifications? I realize the SGI we knew back then is dead but did releases after 5.1 improve in quality?
Obviously I wasn’t there, but - https://en.wikipedia.org/wiki/IRIX seems to indicate that there wasn’t much “long term” beyond IRIX 5. If you look at the timelines given, IRIX 6 was only about adding new MIPS processor support, SGI’s downfall was not long to follow.
Right there with ya - I was a sysadmin back in the IRIX 4->5 days and I remember it being slow and bloaty as well and having folks whine about their workstations after we updated.
SGI made some crazy cool mechanical designs though :)
IRIX 5.3 was essentially solid. You have to put that note in context. To me as a user, an Indy seemed insanely fast at that time - not even vaguely in the same league as a Macintosh of that era.
IMHO, IRIX definitely got better after 5.1. I’ve only used 5.3 and various 6.x releases and thought they were all pretty decent as 90s/early 2000 commercial UNIX goes. I still have very fond memories of my R10K O2 (sadly traded with a friend for some Sun machines)…
I usually stick to doing things in a pure command-line way rather than using things like tig but this system of composing shell commands to capture the inputs for subsequent commands does at least seem like the right basic approach. It took a bit of fiddling to get it working. Seems to need the initial command to be specified with -cmd which seems a bit of a nuisance: I’d have thought the entry point commands could be in the config file but perhaps it would be clearer if used for more than a basic test.
I especially prefer OSM for pedestrian route-finding. I use it on Android via Maps.me, but there are various other apps too. Google Maps seems much more oriented towards road maps and often pedestrian-only paths will be missing, at least in the UK.
What I haven’t found is a decent app for replacing the functionality of my old Garmin: showing maps and doing logging to a GPX file at the same time. Maps.me can show a track of recent movements but can’t save it.
https://osmand.net/ might be something for you.
As an update to this, it turns our that in fdroid, there is a fork of Maps.me called just Maps that adds just this functionality. The problem with osmand is the limited downloads.