I have a magic keyboard for my studio, bloody expensive, but I just love the ergonomics and feel compared to my two TKL (really nice) mechanical keyboards.
I haven't been to a cinema in 15 years, but I went to view yesterday with Gold seating. Didn't even know you could get alcohol served to your seat these days.
might be, i wouldnt be sure but i would encourage author to dive a lil deeper based on some comments in the thread. Theres obviously lots to explore. Anything that goes into this topic is likely to make omissions, have some ,wrong viewing angle' or such things.
I just want to give a perspective of someone that uses the 'eternal history' in bash per Eli Bandersky [1] and reluctance to use something like atuin (without/ignoring shared history).
First, as for speed and responsiveness, if there is a degradation, it is imperceptible to me. I wouldn't have a clue that my interactive shell is slowing down because it is logging a command to ~/.persistent_history.
My persistent_history is 4MB and has been migrated from machine to machine as I've upgraded, it's never felt slow to edit with (neo)vim or search with system supplied grep.
Eli's way of doing it also includes the timestamps for all commands, so it's easy to trace back when I had run the command, and duplicates are suppressed. In fact my longest persistent_history goes back to 2019-07-04, so I've been using it for quite some time now.
But the larger point I wanted to make is that I wouldn't feel comfortable switching this, in my opinion, quite efficient setup to displace it with an sqlite database. That would require a special tool to drill through the history and search rendering simple unix utilities useless. As Eli suggested, if your history gets too big, simply rotate the file and carry on. I have the alias phgrep to grep ~/.persistent_history, but I can easily have another alias to grep ~/.persistent_history*.
I much prefer the parts pairing that is required by Apple. Parts pairing is a mitigation to theft, but in my opinion should be a stronger anti-theft measure. I don't think Apple goes far enough with this. At the moment, a locked part, that is a part that has been taken from a mac with the activation lock still enabled, should render unusable on another mac, or at least show up in the parts setting as marked lost or stolen, and should at render as completely inferior to that of a genuine or authenticated part.
This doesn't hinder repairability, as you will find with the Macbook Neo. It just thwarts a secondary market for stolen Macbooks and/or parts.
The same thing you'd do yoursef if you wanted to assign it to a namesake local variable even if it was in a dict to begin with: you'd make the dash an underscore.
It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict, but regardless a dict doesn't have that limitation. The namespace thing is atrocious and bad design -- no straightforward way to iterate over them, merging/updating them is awful, collides with keyword methods (keys, items, etc.), and so on; thankfully more modern argument parsing libraries didn't repeat this mistake. It's just a shame this ended up in the standard library, but then Python standard library has never really been any good, e.g. logging and urllib1234567.
My favourite trick is either commenting out a whole command or placing a comment at the end of a command to make it easier to find in my persistent history (thanks eliben) [0], using the # character.
I tried this in zsh and it wasn't the default behaviour which immediately made me nope from the shell altogether, among all the other quirks. I've just been using bash for far too long to switch to something different.
I've been a (n)vim user for 20+ years now, but I hate vi-mode in the shell. However if I feel that I need to do a complex command, I just do ctrl-x+e to open up in neovim (with EDITOR=nvim set). I find it a good middle ground.
You're not alone, I heavily rely on vi mode and often struggle if I'm on someone else's machine and can't use it. I always wonder how you're supposed to work without it but I never dare to ask
it is an additional burden to switch to shell vi mode, it is not the standard. Maybe you can put it in all of yout bashrc files but you will probably hear some swearing from the people logging to your machines :).
I'm the same and in my opinion this is the best of both worlds. Taking the time to learn some of the regular (emacs-style) shortcuts is one of the best investments I've ever done. Even just CTRL+Y and the likes.
edit: And of course, CTRL+R, the best time saver of all
agreed, i use neovim as a terminal multiplexer because vi-mode is really bad. I wrote a blog post on how i solved the issue for myself https://loosh.ch/blog/neovidenal
I WANT to love it - and if I was only ever working on one, or a small number of systems that I was the only one working on I’d probably do it. I’m ALL about customizing my environment.
However ssh into various servers through the day (some of which are totally ephemeral), and having to code switch my brain back and forth between vim mode and emacs mode in the shell would just slow me down and be infuriating each time I connect to a new box.
I used to hate it because I'd sometimes change modes without realizing it, but I began to appreciate it a lot more when I added a mode indicator -- a red 'N' on the rightmost side of the input line.
reply