351–360 of 429 posts
Neovim 0.5 is awesome. It has native LSP support, Lua configuration support that it feels like true revolution over past versions. But, getting into optimal setup in neovim/vim involves lot of configuration. Here is mine if you want to refer: https://github.com/varbhat/dotfiles/tree/main/dot_config/nvi...
Earlier quoted context omitted.
I think you’re overestimating how well real life actions map to the object/verb dichotomy. So you’d say that it’s object first because you first get the wood and saw and then decide to saw the wood with it. I could argue it’s verb first because you first GET the wood and saw. I’m not saying that I’m right and you’re wrong. In fact, quite the opposite. My point is that I don’t think real life actions can be broken cle…
"I need to GET something. I know, I'll GET some WOOD." "I need some WOOD. I think I'll GET some WOOD."
Earlier quoted context omitted.
> Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs Early Emacs and the modern GNU/Emacs I think, are two distinct worlds. I believe Lisp has shaped Emacs into its modern form. I just can't imagine the possibility of building something like Org-mode, with the same level of extensibility and flexibility in any other language that is not a Lisp. I bet if you ask any serious Emacs…
Funny, because Magit has been ported to Vim, I use it daily.
Earlier quoted context omitted.
Funny, because Magit has been ported to Vim, I use it daily.
Magit is not just a user interface. It's also a number of emacs-lisp packages useful on their own. It's Transient that's gaining popularity for building modal key UIs in Emacs. It's Forge that paved the road for nice packages like github.com/anticomputer/gh-notify. It is Org-mode integration and many other things. What you're using is a ported subset of them.
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…
If your brain prefers that order, you can emulate it in vim by doing v-movement-action, for example viwd to first select an inner word and then delete it.
Earlier quoted context omitted.
Magit is not just a user interface. It's also a number of emacs-lisp packages useful on their own. It's Transient that's gaining popularity for building modal key UIs in Emacs. It's Forge that paved the road for nice packages like github.com/anticomputer/gh-notify. It is Org-mode integration and many other things. What you're using is a ported subset of them.
So much better, because what I want is to interact with git, not to manage a hodge podge of libraries.
Some people like Ferrari. For some - the utilitarian value of it, is minimal. They'd rather have "a bucket of bolts and nuts" instead. They can't go camping in a Ferrari. They can't take their bullmastiff to a vet in it. They can't help a friend to move furniture.
Emacs is that - it's not akin to a shiny, expensive but not very useful car. It's like a transformer - you can build a pickup truck, a camper, an ambulance, or a race car.
But some people like Ferrari. And that's totally fine.
NeoVIM seems like a big upgrade over a lot of editors. As a very casual Emacs user who never got excited enough for the "self-documenting and programmable editor" idea, VIM gets more appealing by the day for me. I am also using Spacemacs for a year or so and it's definitely better than normal Emacs. Haven't tried Doom Emacs and I doubt that I will, regardless of a lot of positive feedback. I mean, Emacs is alright bu…
Maybe I'm weird, but stock GNU Emacs as out of the box is perfect for me. Tried configuring it with various bells-and-whistles over the years, but I always come back to stock Emacs.
(And no, despite using Emacs for 25 years I don't write elisp.)
Neovim 0.5 is awesome. It has native LSP support, Lua configuration support that it feels like true revolution over past versions. But, getting into optimal setup in neovim/vim involves lot of configuration. Here is mine if you want to refer: https://github.com/varbhat/dotfiles/tree/main/dot_config/nvi...
Thanks for making your configuration available, I want to try out Neovim because it's an exciting project and having carefully constructed configurations available as a starting point will make it easier. Your configuration doesn't look too long to me, my own Emacs configurations are much, much longer and not at all stable--every so often I declare Emacs bankruptcy and start over. Now, some off-topic musings: I switc…
No affiliation and haven’t even used it - but it seems to have legs.
I'm in the curiously rare position of being a long time Neo/vim user who doesn't use its modal features. Namely I have all my keybindings setup like a "normal" editor, CTRL+S to save etc. I say it's curious because I've always been surprised that Neo/vim is mainly celebrated as "that modal editor". Whereas for me I celebrate it as the most feature-packed and lightweight terminal editor. Neo/vim is sooo much more than…
I didn't go that far, but for small movements I use arrow keys. hjkl don't make any sense to me and I'm not keen on using them just because someone had that keyboard layout in 1978.
I'm a long time (20+ years) vim user, and neovim doesn't fit my use case. I've tried it, most recently today, to have a look at LSP and treesitter. Treesitter added different syntax colors, but the result wasn't necessarily better than vanilla vim. More like an overly decorated christmas tree. LSP and other "make it into an IDE" I usually turn off after a few minutes, it's more of a hindrance than a help. I mainly co…
Whenever I read about LSP I'm reminded of Jonathan Blow's talk Preventing the Collapse of Civilization where he talks about LSP and how it turns your single app into a fragile distributed system[1]. The sheer complexity of going from vi, to vim (and plethora of plugins), to vim + LSP is simply insane to me. It does feel like we've all lost our minds. [1] https://www.youtube.com/watch?v=pW-SOdj4Kkk&t=2546s
An LSP is a program that parses and internalizes a project written in a particular language and serves information, diagnostics, and edits, to a generic editor. The protocol is broad enough to serve all the "smart" language-aware functions provided by full-blown IDEs.
This allows one LSP to be used in ... many different editors. The advantage to the users is obvious: if go has one standard LSP, people who use neovim, vscode, vim, emacs etc all have an interest in maintaining that one LSP and will contribute to it in various ways.
Let me give you a few reasons why not only is it fine that it's a separate process, but you want it to be in a separate process.
1. LSPs will be better written if they themselves are written using runtime and the language that they serve.
2. LSPs can potentially hold a lot of memory. Sometimes you need to manage them, and potentially even cut them off, for example if you have a few very large java projects that you're switching between. Generally if they are separate processes, you can just kill them without affecting the editor. Additionally this also means the editor itself doesn't risk a memory leak caused by a rouge LSP server.
3. Subprocess management is not that hard. The editors can do it. Neovim does it pretty well in my experience. The presenter acts as if the server is some totally separate thing that you have to manage yourself. In reality the language server process is launched, managed, and owned by the editor, and often just communicates over stdin and stdout, not that there's anything wrong with ports.
Using multiple processes to distribute work among programs that do one thing well has always been the UNIX way.