Something rather similar to visual mode, and which I've learned to like a lot, is the https://github.com/folke/flash.nvim plugin (NeoVim only since it uses Lua). It gives you a commmand you can bind to a key (https://www.lazyvim.org/ defaults to binding it to `s` for "Seek"). Press that key and then type a couple letters that appear somewhere on your screen. All occurrences of the letters you typed will be highlighted (and the rest will be dimmed), and next to each of them will appear a bright, contrasting letter that serves as a label. Type the label character and you will jump to the start position of the text you typed.
Why is that handy? Well, the idea is that you're probably already looking at the point on the screen you want to move the cursor to, so instead of figuring out a complex navigation, you can type a few keys: `s` plus the letters you're looking at. Then pause for a quarter-second, and type the letter that just appeared where you're looking at. The label letters will be chosen such that none of them appear after the text you typed, e.g. if the words "car", "cat", and "can" all appear in your document, then after you press `sca` the labels `r`, `t`, and `n` will never be chosen. (But the label `d` might be chosen if the word "cad", or words containing it such as "academic", never appear in the document).
It took a little getting used to, but now I've found it's quite the fastest way to issue commands. Want to delete everything from here to that closing parenthesis right there? If you're on its matching open parenthesis then `d%` is fastest, but if you're not, then `ds)` followed by split-second pause to see the label appear (in a bright contrasting color), then type the label. Quite a bit faster than `v` plus a bunch of movement, in my experience. Once you get used to it, it really speeds you up.
And when you get down to it, isn't "once you get used to it, it really speeds you up" a description of the entire vi family of editors in the first place?
I think you're right and visual mode is underused. It gives you the best of both worlds: "cw" meaning "change word" for when it's obvious what you're going to be selecting, and "v3wwwc" for "change 5 words" when you discover (by experimentation) that the text you wanted to change actually counted as 5 words due to punctuation, not 3 as you had first thought.
I still haven't edited the default config much, actually. But now I'm probably 2x to 3x as productive in vim (nvim, now) as before.
P.S. If you decide to check out the LazyVim config, I highly recommend reading https://lazyvim-ambitious-devs.phillips.codes/ all the way through. There's a lot of new keybindings to learn, but Dusty Phillips's book gives you a gentle on-ramp to learning most of them.
I should mention what is becoming my favorite thing about LazyVim's default config, which is the "flash" or "seek" command (LazyVim maps it to `s` so I think of it as "seek") from https://github.com/folke/flash.nvim. I didn't like it at first as I was used to typing `s` to quickly replace a single character with a bunch of text (as opposed to `r` which replaces it with just one character). But I soon learned to remap my brain to use `cl` where I used to use `s`, and then I learned to love "flash"/"seek" mode.
I wrote about how it works in https://news.ycombinator.com/item?id=48118585 so I won't repeat that here. But if I had to pick my favorite feature from LazyVim's config... well, actually it would probably be something else, but `s` is definitely in the top three by now.
Flash is amazing, and what made me drop VSCode. Flash feels like an innovation and basically lets me move my cursor at almost the speed of thought. Highly recommend people try it out and play with it!
BTW: The Vimium extension [1] for Firefox has a similar mode for links called "linkHinting" which I've mapped to s[2] for a similar experience in the browser :)
I am with you on that one. I use Emacs and the Vi family. If I wanted IDE features in my text editor, then I would probably be better served using an IDE. Less to manage is less to burden.
I similarly thank the stars I ran into AstroNVim, which itself is based on LazyVim. Out of the box it has a lot of well integrated/just works pieces. It has a bunch of leader key things setup, and, crucially, a little visual navigator at the bottom of the screen. Going from powerful but invisible to having something I could see was such a help! I'd compare it to moving from tmux to zellij but I'm a pretty happy tmux user. https://astronvim.com/
What really seals the AstroNVim deal for me though is the community packs. People have very thoughtfully integrated support for a huge range of nvim plugins. And it's super easy to install, and they often fit in nicely to the existing out of box experience of nvim. https://github.com/AstroNvim/astrocommunity
Yeah, I have also been really impressed with AstroNVim. I tried using LazyVim for quite some time but I kept having a hard time getting used to it. Somehow I kept tripping up when trying to do things.
On one of my servers I needed to disable icons which AstroNVim handles very conveniently (https://docs.astronvim.com/recipes/icons/#disable-icons). After switching I noticed that using AstroNVim feels so much more natural to me. It's been a joy to use.
I think it might be because the defaults are less bespoke and it's just a bit leaner. The community packs have also been great for customization.
Hey, AstroNvim core maintainer here! Just wanted to clear something up. AstroNvim is in no way based on LazyVim, AstroNvim existed for almost 2 years before LazyVim existed...
I started learning vi around the same time, but in my case (since I was expecting to work on Unix systems for decades, which has proven true) it was "because it'll always be there." I.e. if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there (perhaps the problem you're fixing is that /usr isn't mounting), but you can nearly always count on /bin/vi being available: if you can access the server at all, you will be able to access vi, so at least learn its basic keystrokes, our prof told us.
That advice was not entirely accurate (sometimes vi is in /usr/bin/vi, for example), and the merging of /bin with /usr/bin has made it kind of a moot point. (EDIT to add: Though the fact that busybox includes a basic vi implementation has kind of un-mooted the point, actually). But I first started learning vi because I figured I would need it professionally, and when the modal-editing workflow "clicked" for me, I figured out that I had just learned the editor I would want to stick with for years.
And although vim replaced vi and nvim replaced vim in my finger-macros, that has remained true to this day.
Yes, I can use TRAMP but as I ssh to the server anyway to run commands, I'm editing the files with vi there. Furthermore I'm sure I don't inadvertently edit the local version of the file instead of the remote one, or that I forget to kill the buffer with the remote file and edit it instead of the local one after a few days. What's on the server stays on the server.
Never really learned emacs so didn't know TRAMP existed. When was it created? I was given that advice ("vi will always be available on the server") in the late 90's so I'm curious to know if TRAMP was an option my prof didn't know about (or didn't mention), or whether it was developed later and the advice was good at the time.
EDIT: Found http://www.fifi.org/doc/tramp/tramp-emacs.html which mentions that TRAMP started development in November 1998. I would have been getting that advice in late 1997 or early 1998, given when I started my Unix class at college. So the answer appears to be that the advice was actually correct at the time, but superseded sooner than I thought it was.
Well, TRAMP was preceded by ange-ftp, which let you edit files remotely over ftp. I was using that in 1995, and I didn't get the impression then that it was brand new, so it had probably been around for a while already.
Of course, if your problem is "/usr won't mount", then it's likely that the ftp server isn't running either, so the advice still makes sense.
I often use vim despite knowing only a few basic commands because I'm already running various commands on the remote machine in the terminal and don't want the context switch. And because connection / file path completion in TRAMP is annoyingly slow if the server is far enough.
As an extreme example, today I needed to combine parts of two files into one and decided that
cat foo bar > foobar && mv foobar bar && vim bar
of all things will better keep me in the flow than either googling how to insert one file into another in vim or starting up TRAMP.
Usually I post the original title in a comment for the sake of transparency (because some people may comment without reading the entire article), but that is not the case here. In this case, I posted the original title so that future me would be able to use HN Algolia search to find out whether I had cited or posted this article in the "past".
That a Democrat-leaning paper would criticize Republican politicians is not surprising. A better test of independence would be whether they criticize Democratic politicians (when they do things deserving criticism, that is: I don't expect them to criticize policy positions that they agree with, but all politicians do some things, in some cases many things, deserving of criticism).
The point is that they shouldn't be criticizing anyone which I think is the point of independent journalism.
That they publish articles that put Republicans in an unfavorable light is I think because Republicans are doing things that put themselves in an unfavorable light.
To your point, there have been at least a few articles I've seen that put Democrats in an unfavorable light as well.
And for what it's worth I consume news outlets that lean both ways. What's more important to me is factual accuracy.
I stopped buying cartridge-based inkjets years ago. I'm happy with my Canon G3020, which uses ink tanks (built into the printer, not a third-party addon that the manufacturer will claim voids the warranty).
And it's impressive how long those ink tanks last: I printed out 400 pages of full color and the ink tanks went from 80% full to about 50% full. (There's a clear plastic window in front of the ink tanks, with a "refill when ink reaches this level" line on it — a raised line of plastic, not something inked or painted onto it that could rub off — so you can glance at the printer and see what level the ink is at). The ink bottles cost me about $12 each if I remember right, and each one will fill the ink tank from the "refill here" line to more than 100%: I had to stop filling, then wait until I had printed a few hundred more pages, then refill the rest. Rough back-of-the-envelope math says maybe 1200 pages from a full ink tank. The C, M, and Y bottles will cost $36 total (the K bottle will last a lot longer so I'm not counting it in this math), which means 3 cents a page for full-color, ink covering nearly the whole page, prints. Considering the cheapest print shop I've found would charge me 20 cents per page (and I've seen 50-cents-a-page quotes for full-color printing), the $200 printer will have already paid for itself by the time you run through one ink tank (17 cents saved times 1200 pages is $204).
This is turning into an ad for Canon, but seriously, it's a great printer. The only thing I don't like about it is that it doesn't do automatic duplex printing (I have to pull the pages out, flip them over, and put them back in), and I knew that when I bought it (the model that did automatic duplex was $450, and I chose not to buy that one). Oh, and I am not affiliated with Canon in any way: considering how glowing a review this is, I should probably say that explicitly.
But the best part for me was that it's not an Epson. I previously owned an Epson ink tank printer, and it was great... until the ink sponge filled up. Did you know that ink jet printers, at least the ink-tank variety, have a sponge inside them? When you do a "clean clogged print heads" routine, the printer moves the print head over to the position of the sponge, and pushes ink through the print heads until it's moved enough liquid to hopefully push the clog out. Sometimes it works, sometimes it doesn't. But the sponge can only absorb so much ink before it fills up. And on an Epson, the sponge is not a user-serviceable part. They want you to send it to one of their official repair shops to get it replaced, costing I don't know how much because I refused to do it. I found an unofficial way to wipe the printer's internal counter that kept track of how much ink was in the sponge... and when the printer died about a year later (for unrelated reasons), I went shopping for another brand. I'll never buy an Epson printer again. Canon, on the other hand, will sell you a "maintenance cartridge" (a large sponge mounted in a plastic tray of the right shape to slot into the printer) for about $10 plus shipping. When the sponge gets full you can just swap in a new one. Dead simple.
Enough gushing from me. The point that I spent way too long getting to is, ink-jet printers don't have to use cartridges. Ink-tank printers used to only be available in the Asia/Pacific market, but they're available in the US now. A couple years ago I helped my parents (in the US) buy a Canon G3020 and set it up for them. So far their experience has been positive, too.
<del>The server-client model means you can run the server (MPD, Rockbox Zig, whatever) on your homelab, and stream music to multiple clients. So you don't have to copy all your music onto your phone, you can just run an MPD client like M.A.L.P. and it will stream from the files on your server. Then there's just one copy of your music collection, tags, etc.: no more keeping tags up-to-date between the copies on your home server, your laptop, your phone... (Do make sure your files are backed up, of course).<del>
MPD doesn't really do streaming. If you install MPD on your server and then install an MPD client on your phone, the music will play on your server when you press play on your phone. You can re-encode the playback as an audio stream and stream that to your phone, but it's not really what MPD is built for.
Thanks for the correction; edited my comment to ensure nobody gets confused by my mistake. (I'm brand-new to using MPD, just installed it last week, so I had things backwards in my head).
And the PICO-8 has produced some impressive projects, such as UnDUNE II (https://liquidream.itch.io/undune2) which reimplements the old Dune II game (which started the entire RTS genre). Yes, within the PICO-8's constraints. I loved Dune II, and while I don't plan to pick up a PICO-8 just to play it, I love that this exists.
Why is that handy? Well, the idea is that you're probably already looking at the point on the screen you want to move the cursor to, so instead of figuring out a complex navigation, you can type a few keys: `s` plus the letters you're looking at. Then pause for a quarter-second, and type the letter that just appeared where you're looking at. The label letters will be chosen such that none of them appear after the text you typed, e.g. if the words "car", "cat", and "can" all appear in your document, then after you press `sca` the labels `r`, `t`, and `n` will never be chosen. (But the label `d` might be chosen if the word "cad", or words containing it such as "academic", never appear in the document).
It took a little getting used to, but now I've found it's quite the fastest way to issue commands. Want to delete everything from here to that closing parenthesis right there? If you're on its matching open parenthesis then `d%` is fastest, but if you're not, then `ds)` followed by split-second pause to see the label appear (in a bright contrasting color), then type the label. Quite a bit faster than `v` plus a bunch of movement, in my experience. Once you get used to it, it really speeds you up.
And when you get down to it, isn't "once you get used to it, it really speeds you up" a description of the entire vi family of editors in the first place?
reply