Live data from Hacker News

Neovim 0.5 is overpowering

crispgm.com

371–380 of 429 posts

Re: Neovim 0.5 is overpowering

#371
post #276

Earlier quoted context omitted.

The way vim works is actually the opposite of what your brain wants, this is one of the reasons why learning vim tricks is hard. The vim model is "action-object" (eg dw, delete word). A more natural, friendly and interactive model is the opposite, "object-action": first you select the text, your editor highlights the text, then you apply actions to the selection, one by one, and see what happens after each one. Becau…

Whenever you say words “natural”, or “friendly” you actually mean “what I am used to”. As the saying goes “Basically, the only ‘intuitive’ interface is the nipple. After that, it's all learned.” (Usenet discussion about Apple Macintosh). So, no, I spent couple of years struggling with non-modal editors, where I had that feeling all the time “I have no idea how to do it effectively in this $EDITOR, while I know five k…

Just an FYI Kakoune is a modal editor. I've actually tried it and OP has a point, for many of the things that you would use visual mode in vim things are very natural in Kakoune. It's also surprisingly accessible to someone used to vim. That said, it's difficult to leave the huge community behind vim behind.

Re: Neovim 0.5 is overpowering

#372

Earlier quoted context omitted.

While you didn't refer to any explicit programming language (so your example is correct by definition), I think you may have mixed up something. The order is reversed, but typically not in the way you describe. For your example of f(g(h(x))), you would write (f . g . h) x in Haskell. So for this particular example, the syntactical order is not reversed. However, you could say the natural order of reading is reversed:…

This x |> h |> g |> f syntax is Elixir (and F# perhaps? and surely other langs). In Haskell this is written x & h & g & f And in shell script, this is written echo x | h | g | f This operator is sometimes called the pipeline operator Anyway, here is some ghci session exemplifying the usage of the & operator $ ghci λ import Data.Function((&)) λ a f g h x = x & h & g & f λ b f g h x = (f . g . h) x λ c = f g h x = f (g…

to be honest, idiomatic code in haskell-land tends to be written right-to-left and not left-to-right, so you'd usually write it with the ($) and (.) operators. I personally have gotten used to reading it right to left more, as have probably most people who use haskell extensively. And I think it's only fair that haskell chose a 1 character operator: composing functions and applying them to arguments is the main way to make programs, so it's good that you have to type the least amount characters possible to do it, compared to something like F# where all the function composition and application operator take two characters (|>, >, <<)

Re: Neovim 0.5 is overpowering

#373

Earlier quoted context omitted.

The way vim works is actually the opposite of what your brain wants, this is one of the reasons why learning vim tricks is hard. The vim model is "action-object" (eg dw, delete word). A more natural, friendly and interactive model is the opposite, "object-action": first you select the text, your editor highlights the text, then you apply actions to the selection, one by one, and see what happens after each one. Becau…

You've oddly crystallized why Kakoune has so far failed to grab me! The description you gave of the actions one takes in editing makes sense: in most non-modal editors, you select the text you want to take actions on, then choose the action to take. But, I can do that in literally every modeless editor! That's the way essentially all of them work. But when people write of "Vim as a text editing language" as many comm…

In English, sure. Not in Hindi for example (मैं खाना खाता हूँ - 'I food eat') or in .. object-oriented methods of many programming languages.

I don't think there's anything special about that mapping, whichever way around. I'm not inclined to think I'd perceive things or act any differently if my main way of describing things (English) had a different grammar - a rose would smell just as sweet.

I can see some value, especially for beginners, in 'highlight while object selecting, then act' (which you can do in vim with visual select and then action, e.g. instead of c2w do v2wc - or v2w -wait no that's not what I want-).

I do prefer it as it is though, probably just because I'm used to it, but I think of it as 'up to' rather than 'define the object', since it is always anchored (at least, without any plugins doing differently like is being discussed with Treesitter here, adding context awareness) by the cursor position. So I'm thinking 'change from here to..'. I suppose if one wants to think about 'object first' you could argue vim already is that anyway - you move to the object before typing any of the command.

Re: Neovim 0.5 is overpowering

#374
post #362

Earlier quoted context omitted.

"I need to GET something. I know, I'll GET some WOOD." "I need some WOOD. I think I'll GET some WOOD."

I think this supports the point - in either case the syntax for the action is 'get wood'.

This whole back and forth in this subthread is ridiculous. People are comparing command syntax (not even a proper PL) with natural language syntax. First one is used to define actions first and foremost, and the second one to describe them.

How we formulate our actions in our head/speech to describe them is mostly irrelevant here.

Re: Neovim 0.5 is overpowering

#375

Earlier quoted context omitted.

This looks like the sort of thing you would intuitively solve with visual selection and a regex. ``` Vjj:s/\v'(.*)',/'\1': Enum.\u\1,/ ``` This is all just muscle memory. It seems impossible until you get used to it, and then it's the most natural thing in the world.

TIL s/\u, thanks! I know I’ve read that part of the documentation before, but probably not for over five years. In cases where I’ve wanted something like that, I’ve tended to reach for macros, visual block editing, and s/\=. A few days ago I did a somewhat more complicated one that s/\U wouldn’t be sufficient for: :' s/.*/\=" pub const ".substitute(toupper(submatch(0)), "[^A-Z0-9]\+", "_", "g").": &'static str = \"".…

Vim's documentation is complete and very well-written. I've been using the editor for over 10 years and I still learn new things when perusing :help.

Re: Neovim 0.5 is overpowering

#376

Earlier quoted context omitted.

They make sense because they are directly under your fingers, so you don't have to move them all the way over to the arrow keys and back just to move around. jkl; would make more sense, that's the only oddity.

There was a time that keyboard had their arrows keys on the left side. I forgot the source.

I think the issue was (back in the day) that many computer keyboards didn't have arrows _at all_. See for example the IBM Model F: https://commons.wikimedia.org/wiki/File:IBM_Model_F_XT.png

If you search for "oldest computer keyboards" in your favorite image search utility, you'll notice that many keyboards there don't have arrows at all. I did not find any keyboards with the arrows on the left side, although it wouldn't surprise me.

Re: Neovim 0.5 is overpowering

#377

Earlier quoted context omitted.

All modern IDEs have vim bindings.

Better still, all modern IDEs have tools that actually work with code , not text. And navigating code is significantly fatser in an IDE than in Vim. This includes things like juping to definitions and implementations, finding call sites, fuzzy search on symbols (not text) and dozens and dozens of other things.

All those things you mentioned work in vim through plugins like coc.nvim

Re: Neovim 0.5 is overpowering

#378

Earlier quoted context omitted.

They make sense because they are directly under your fingers, so you don't have to move them all the way over to the arrow keys and back just to move around. jkl; would make more sense, that's the only oddity.

There was a time that keyboard had their arrows keys on the left side. I forgot the source.

https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys

Re: Neovim 0.5 is overpowering

#379

I'm most excited for the treesitter integration and its potential to amplify Vim's "killer feature": text editing as a language. Vim's editing language feels most powerful when I'm using its text objects: "ciw" means "change in word", "cis" means "change in sentence", and so on. But Vim's built-in text objects are not always a perfect match for the code you're editing. Suppose you want to change the first argument of…

Do you find your brain can actually work that way? My issue with all of these relative jump points, repeat this N times, etc of VIM is by the time I’ve calculated in my mind what the command should be I’d have already done it with just standard navigation/mark/yank/repeat. But perhaps you have galaxy brain ;)

You can't calculate those commands because you're not meant to calculate them: They are meant for macros and scripting.

Re: Neovim 0.5 is overpowering

#380

Earlier quoted context omitted.

I usually just keep space bound along the lines of: :noremap :silent noh echo :syn sync fromstart This recalculates syntax highlighting as well as removes highlighting on search results/etc. Basically, whenever stuff "looks weird", just mash space in normal mode and it fixes it. The fact that I have this bound to something like space should tell you how often I end up using it. :)

I recently gained a liking to search result highlighting, it's much more useful than I originally thought. The problem is not the highlighting itself but its persistence. I added a few autocmds to automatically hide it in certain events and a manual shortcut. Works better for me now, though it is annoying that `:noh` has some weird special status that makes it nonfunctional in autocmd.

I evaluated few plugins around this and this one I liked the most: https://github.com/romainl/vim-cool
Post reply on HN