291–300 of 398 posts
Earlier quoted context omitted.
Seriously, it hurts. It makes sense, but it hurts. If only there were a more gentle path to editor modes. Maybe some simple graphical representation of the modes and commands that could be down in the corner? Like a dynamic vim infographic that clued a user into the most likely commands.
Helix is beginner friendly. It's keybindings make more sense than vim's.
Earlier quoted context omitted.
for a moment there, I was wondering why they'd install a JavaScript engine in a tesla.
Tesla uses Qt and Qt WebEngine uses Chromium, meaning that there is probably in fact a V8 JavaScript engine in any given Tesla. https://github.com/teslamotors/buildroot/tree/buildroot-2021...
I don't think this covers the main reason I only use vim occasionally: it is the only reasonable editor available over ssh by default on all VMs deployed in your typical org. Over there it usually has default settings, and it's not trivial to change configs or install other editors. Worthy attempt, looks cool, but I'm still stuck with having to learn the basics of moving a cursor around reasonably :(
Earlier quoted context omitted.
nano of course has syntax highlighting, so I’m curious where it falls short.
Does it have syntax highlighting for the same amount of languages as vim does, out of the box? I just installed nano-7.2-1 and opened a HTML file with `nano test.html` and it opened without syntax highlight, I can see the point in authors endeavor if syntax highlighting out of the box is what they're looking for.
Earlier quoted context omitted.
> vi and vim have modes becaus they were created in an era where computing and terminal capabilities were very limited. that's the whole point. it was designed for limited terminals and high latency, very slow serial links. that means when you learn it and all of its shortcuts and you have a fast and modern terminal, you are able to edit at ludicrous speed. it's like training at altitude or running with weight belts…
> you are able to edit at ludicrous speed I never ever got this argument for Vim. I don't spend most of my time slinging around huge chunks of text or repeating commands like they do in YouTube videos where Vim pros flex their skills (to extend the fitness metaphor). I spend most of my time thinking about code design, reading documentation, writing plans, discussing stuff with my colleagues—editing, writing code is m…
ahh yes, the central brooklyn coffee shop as existential bus stop school of computering. "oh, you're 38 too, well then what are you doing with your existential crises?" "well, when i'm not working on my book, i like to think about code design and discuss stuff with my colleagues while listening to instrumental remixes of 90s punk and indie rock classics. my preferred languages are ocaml, erlang and ruby, but usually i tend towards microsoft visual foxpro for professional efforts."
As an old vim graybeard, more power to you. I'd recommend checking out `vim -y` as well. (And once you try _that_, you'll likely have a question, the answer to which is Ctrl-l.) To others on this thread decrying this as heresy: leave 'em be. Let everyone use whatever editor flows works for them. Programming is hard enough without having to conform to other people's beliefs of how _you_ ought to use your own editor!
Thanks.
Earlier quoted context omitted.
> It's like installing a V8 in a Tesla, or replacing the pumpkin in pumpkin pie. Most pumpkin pies are actually made with butternut squash and other similar squashes, not pumpkin. https://en.wikipedia.org/wiki/Cucurbita_moschata https://www.thekitchn.com/whats-actually-in-your-canned-pump...
Not sure about where you’re from but where I’m from, you don’t make pumpkin pie from a can. You make it with pumpkin purée. From scratch. Get out of here with your non-pumpkin pumpkin pie propaganda. Some pumpkin, blended into a paste, some brown sugar, an egg or two, some heavy cream and some cinnamon and crushed cloves and you have your pie filling.
This "tradition" of using Butternut Squash instead goes back to the 1930s at least.