Hacker News new | past | comments | ask | show | jobs | submit | hatmatrix's comments login

I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings.

There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost. Yes, there is Ctrl+[ for single commands, but this is still an additional step compared to the key chord model of Emacs for instance.


I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point.

Take, for example, writing a for loop. I might type:

  for (int
Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode. Even if I only pause for a second, I reflexively return to normal mode the moment I stop typing.

Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".

Or say, I want to open a new line above and insert "xyz". Again, I think of it as a single operation in normal mode that includes the key sequence "shift+o x y z ESC".

This applies to all insert-mode operations for me. Normal mode feels like "home" and insert mode is just an editing phase I dip into when I need and exit. That's why it doesn't feel like I am constantly switching modes (even though I am).


I think one (often forgotten) good advice to get used to the mode-switching is to move the ESC key to Capslock on the keyboard. It's tedious to learn to always go to the ESC key, upper left of the keyboard. Capslock is available from home row, and you should probably not use CAPSLOCK anyway, it's a bad practice.

Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.


Indeed! Sometime between 2010 and 2015, I used to often work with Windows computers, so I wrote a tool for myself back then to remap Caps Lock to Esc on Windows machines:

https://github.com/susam/uncap

While it was certainly possible to do that by editing Windows registry (and I have noted those techniques too in the README), registry changes couldn't be enabled or disabled without a reboot. That's what motivated me to write the above tool. And indeed, having the Caps Lock work like Esc made using Vim a much better experience!


For a win, replace Caps Lock with Esc when tapped and with Control when held.

I map 'jk' in Insert mode to <Esc>. In Insert mode, it takes me out to Normal mode. If I'm already in Normal mode, it simply moves down a line and right back up. This habit is so burned into my muscle memory that I often end up typing 'jk' into non-Vim input areas (like this HN comment box).jk

I’d recommend taking it even further and mapping capslock to escape when pressed by itself and CTRL when held in sequence with another key.

at most one y in way since Capslock is an unergonomic key in itself - it requires an unergonomic lateral movement of your weakest finger of your weaker hand

It never made any sense to me that people claim Emacs has no modes. What do you think you're doing when you hold down a modifier key? What else would it be except entering a mode in which other keys have a different meaning? Is that really different from vim's mode switching? They're just different ways of expressing modifiers.

> Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".

It is an action. Check out what happens if you prefix it with a repetition:

   5iHello<esc>
-->

   HelloHelloHelloHelloHello
Same goes for other ways to get into insert mode (like I, a, A, o, O), then for dual-actions that do a delete and switch to insert mode (like s, c) the repetitions apply to the delete part.

I used Vim for 5-ish years and I kinda got into that mindset, but on occasion I would fail to switch to insert mode (I think by not hitting the i or a key properly, but when in the flow I don't really pay attention to what my hands are doing) and stuff would go haywire. After 5 years of that happening intermittently I got really fed up with it and I started trying various alternatives.

I have been using Emacs for about 6 years now and when I fail to engage a modifier key properly all that happens is that I type some text in the active buffer. If I really manage to do a silly mistype, I can just hit C-h l to show my recent keystrokes to find out what I did.


I wonder if it would be possible to write some code to auto switch to insert mode if you press like 3 key in a very rapid succession, while in normal mode ?

> Take, for example, writing a for loop. I might type:

> for (int

> Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode.

I personally wouldn't but that's only because even in the case above I think in the same way as you mentioned next:

> I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".

in the sense that I will ESC only after I have instered a "semantic-ish unit", which would include the variable name.

So I'd probably enter:

   i for (int foo; foo < 42; foo++) ESC :?foo nnn cw
and think there (and finalise with ESC N . N .)

I don’t know I edit a lot but I also really like vim motion. It gets really natural at some point. The mix of b and e to move around, using cw or ce to remove and start editing then getting back to moving around. Plus a lot of edit actually happens straight from normal mode (case correction, one character changes, short deletion).

You don’t really think about the modes because things flow naturally. It might also be due to the fact that I nearly never actually switch conscientiously into a mode. I always do actions which send me in insert (like c and o, very rarely I or A) and revert back to normal when done.

Plus vim has the advantage of making things like just remove everything between these symbols and set me in edit there very easy which is something I miss when I don’t have vim bindings.


I don't think it's the keybindings in particular that people love about vim, you can rebind everything after all. I'm attached to vim keybindings in the same way I'm attached to qwerty keyboards - something had to be the default, it's fairly arbitrary, and there's very marginal benefits in switching to a different set of bindings.

It really is the modal editing style that's the main draw. Someone who edits frequently should find vim more convenient, not less, but it does require a lot of time to learn all the available commands and burn them into your muscle memory.


Yes, the default. That's why, although I am french speaking, I switched a few years ago from azerty to qwerty keyboard just to be using the keyboard used by the people who programmed the default in editors like vim and emacs. Otherwise it is just a PITA. Should have done that from the very beginning I was programming. With Karabiner and Goku I have been able to configure some key combinations to get accented letters like righr alt+e for é, right shift+right alt+e for è, ...

> There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost.

I edit this way too and there's no heavy cost here. Well, maybe when you're first learning and switching hasn't become second nature, but when you do it's not something you even notice.


> who prefer these key bindings

Which ones? Do you mean the unergonomic defaults where one of the most popular action (quitting to normal mode) is bound to one of the most inconvenient keys (Esc)? Also for editing within a word you actually don't need to switch between modes, but instead could use something like a home row cursor with a modifier to move in insert mode.


Indeed there is administrative bloat everywhere, and I can sympathize with your hope that tearing down the current system will leave room for building anew.

However, it's hubris to assume that everything is bloat. There is the adage of Chesterton's fence, which reads: "...reforms should not be made until the reasoning behind the existing state of affairs is understood." Many things that appear to be bloat that serves a useful function, and tearing them blindly is going to do irreparable damage.

[1] https://en.wiktionary.org/wiki/Chesterton%27s_fence


Such a functionality would be useful for developing some scripts and then converting to a Quarto document [1].

[1] https://quarto.org/


I've never used Quarto, but I might give it a go someday. I currently have a convoluted workflow for generating math-heavy documents that involves generating equations using SymPy in a notebook, accumulating them in a string, and ultimately dumping the string into a Markdown. I would love to simplify this sooner rather than later. I'm also keeping an eye on https://typst.app/ and hoping for a sane alternative to LaTeX to emerge.


Second hooray for Quarto. Great tool.


Is it? I use org-babel regularly but wasn't aware of it - what's the function called? As great as org-mode / org-babel is, the user base is too small to not be overlooked.


Well in general I've put entire projects into org docs, and ran the code blocks, essentially using it like a Jupyter notebook (although honestly it wasn't always as smooth as I'd like). And I haven't done this myself, but there's a neat literate programming talk from the last EmacsConf[0] in which the presenter showed some custom capabilities which improved the experience even more for him.

[0] https://emacsconf.org/2024/talks/literate/


Peter Norvig himself has come around to embracing Python as an alternative to Lisp:

https://norvig.com/python-lisp.html

https://news.ycombinator.com/item?id=1803815

and there is indeed a Python implementation for the PAIP programs.

https://github.com/dhconnelly/paip-python

GC conferring additional composability is an interesting take - I hadn't thought of that (though I don't spend much time in this ___domain).


Just imagine what a godawful mess it would be to write really complex libraries that are supposed to be composable in C. (I'm going to argue this is why there is no 'npm' or 'maven' for C)

The point of programming C is it is very low level and you have complete control over memory allocation so you're losing much of the benefit of C if you have a one-size-fits-all answer.

The application might, in some cases, pass the library a buffer that it already allocated and tell the library to use it. In other cases the application might give the library malloc and free functions to use. It gets complicated if the application and library are sharing complicated data structures with a network of pointers.

In simple cases you can find an answer that makes sense, but in general the application doesn't know if a library is done with some memory and the library doesn't know if the application is done with it. But the garbage collector knows!

It is the same story in Rust, you can design some scheme that satisfies the borrow checker in some particular ___domain but the only thing that works in general is to make everything reference counted, but at least Rust gives you that options, although the "no circular references" problem is also one of those design-limiting features, as everything has to be a tree or a DAG, not a general purpose graph.


The reason there is no npm/maven for C, is because UNIX culture prefers Makefiles and packages on whatever format the actual UNIX implementation uses.

Depots on Aix, pkgsrc on Solaris, tgz/rpm/deb on Linux, ports on BSDs,...

In any case, I would argue that we have npm/maven for C, and C++ nowadays, via CMake/Conan/vcpkg.


Good point. When Clojure first came out it was questioned whether it's a lisp at all, but now I commonly hear many say it is the best Lisp.


I believe it's open source but requires a commercial license; free for academics.


To be slightly more precise, it's not open source, but source available.


Good distinction


I understand native multithreading would be one of the key advantages of Guile Emacs.


always thought the problem was not multi-threading per se but the whole rendering code that's single threaded with tons of global state that's difficult to decouple without breaking the ecosystem


As a fan of Julia, surprised to see how julialang/julia has so few links. It's a niche language; how isolated it is on this map is maybe not so unrepresentative of the user or developer experience.


There's a JuliaLand to the west of the island where julialang/julia is.

The fact that julialang/julia ended up near tensorflow and opencv, and actual Julia packages ended up elsewhere, probably reflects a difference between aspirational users and real users: a lot of people who starred the Julia project itself were numeric Python users who were looking for a new Python, but then mostly stuck to Python itself, so their other stars are in the numeric Python land. Those who starred the JuliaLand packages are the actual Julia users who aptly enough ended up near Moleculandia and AstroSpace and Quantumia.


Ah I didn't see that.

That explanation sounds very plausible.


I can't imagine the use cases for parsing org-syntax in Julia - is it for textual analysis?


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: