Live data from Hacker News

Neovim v0.4.0

github.com

81–90 of 168 posts

Re: Neovim v0.4.0

#81
post #16
post #13

Earlier quoted context omitted.

Both neovim-gtk & gnvim are great but don't integrate nicely with standard ctrl + c, ctrl + v actions which is super frustrating. VSCode with vim plugin handles this well with the Use Ctrl Keys option set. If you're in insert mode, ctrl + v will paste, otherwise ctrl + v will start visual mode. If you are selecting text, ctrl + c will copy.

set clipboard+=unnamedplus imap + vmap y Most probably you want this as well: cmap +

> set clipboard+=unnamedplus

TIL. This goes into my vimrc right now.

Re: Neovim v0.4.0

#82
post #30
post #2

> nvim_open_win: create floating windows (and external, for supporting UIs) I've been running 0.4.0 since it came out for this feature. Also I recommend you check out coc.vim for the best completer. It uses the same language server protocol that VS Code uses (and many of the plugins for coc.vim are forked fr VS Code plugins)

Are there any good alternatives for coc.vim? I do not like the NodeJS dependency.

See https://langserver.org/#implementations-client

Re: Neovim v0.4.0

#83
post #64

Earlier quoted context omitted.

I just tried this. I get rendering artifacts when scrolling. BUT! The scroll speed is absolutely wonderful. I've tried all the UIs and always find myself going back to the terminal, but this is something else. Although I have to say fvim looks tempting as well and vimr(I'm not on MacOS anymore). For those people mocking vim users and bragging about their IDE's. With languageserver and the other kind of refactoring da…

I'm not going to mock you, but why not just use an IDE with a vi(m) mode or plugin in the first place, if you really want all those features? Modern IDEs are following a platform + plugins architecture that is probably as flexible but more robust than whatever you can tape together around vim.

Because Vim modes usually don't support more than a handful of basic features, let alone plugins and custom keybindings.

Vim also starts up without any noticable delay and can be used for every text file, no matter in what context.

Re: Neovim v0.4.0

#84
post #2

> nvim_open_win: create floating windows (and external, for supporting UIs) I've been running 0.4.0 since it came out for this feature. Also I recommend you check out coc.vim for the best completer. It uses the same language server protocol that VS Code uses (and many of the plugins for coc.vim are forked fr VS Code plugins)

All completers will be able to utilize floating windows immediately, so it's not a special feature of coc.nvim. Using LSP is also not unique to coc.nvim. Deoplete, for instance, supports both as well. I personally have no interest in using coc since it's a javascript based project.

Yes, I wasn't trying to say it's only possible to use with coc.vim, and neither was I trying to say that LSP is unique to coc.vim. But I would not recommend Deoplete.

Re: Neovim v0.4.0

#85
post #72

Earlier quoted context omitted.

As someone who's been doing sysadmin-ing things for a while... (10+ years) I don't think I've ever seen Emacs installed on any server where it wasn't maybe pulled in as a dependency by something else. Emacs is almost never installed by default, you could instead install micro ( https://micro-editor.github.io/ ) instead, use normal keybindings, and call it a day :-)

> As someone who's been doing sysadmin-ing things for a while... (10+ years) I don't think I've ever seen Emacs installed on any server Chances are the Emacs-users are working on files on that server remotely via TRAMP, from their nicely and 100% personally customized Emacs-installation. Why bother replicating all that setup on a server when you don't have to?

True, but that also means that as someone who regularly SSHes into servers, you don't need to learn anything about Emacs. For local stuff on the servers, vi(m) is always there (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/v...), for remote operation you can use any other editor ranging from Emacs + TRAMP to VS Code + remote extension to ...

Re: Neovim v0.4.0

#86
post #77
post #64

Earlier quoted context omitted.

I'm not going to mock you, but why not just use an IDE with a vi(m) mode or plugin in the first place, if you really want all those features? Modern IDEs are following a platform + plugins architecture that is probably as flexible but more robust than whatever you can tape together around vim.

vim modes in IDEs are often inadequate (if this is not immediately obvious, you probably just don't use vim as fully as possible). The IDEs are often (too) complex in the sense of a hodgepodge of GUI options and menus which are hard to navigate. You often can't put the IDE configuration in a version control system easily. IDEs are often sluggish. The plugin system for vim is superior to most IDEs. It's not that using…

I agree completely. For me, for now, I have vscode with vim emulation. I find that it's more convenient to have everything vscode has + vim keys for a lot of things, than have all of vim + try to make vim do what I like from vscode.

I really hope in the future I'll find the time to do that, but for now I am content. It's always a trade-off.

Re: Neovim v0.4.0

#87
post #71
post #19

Why do we need such things in 2019?

The terminal is common to many operating systems and keyboard shortcuts leant there are pretty universal. If you prefer a keyboard driven workflow learning to use a terminal and terminal based editor will give you a very portable solution. Vi's commands are somewhat like a language for manipulating text. This is a different philosophy to many non-modal editors. In vi you can say change the next 3 paragraphs to foo or…

I guess it depends on the usecase.

You mention a lot of scripting, and also the terminal.

Would you also recommend vim for working on large projects with 100+ files? I believe in this case, a full on IDE is suited better.

Also I'm not so sure about the portability. Sure, some of the knowledge is reusable, but when all the vim installations are not "batteries included", every installation will be configured differently.

Another point: I think with strongly and statically typed languages one shouldn't think about writing code as writing text, but about building a syntax tree that happens to be text.

Re: Neovim v0.4.0

#88
post #58
post #52

Earlier quoted context omitted.

I'd say language support is the most important for productivity if we talk about programming. Having the whole API under your fingertips, doing safe refactorings easily, etc. are much more important for productivity than simple editing. If you can refactor a class, move functions, rename variables across the whole project safely (string replace is not enough) with a few clicks then you are much faster than when you h…

This. First of all, I don't know about vim/neovim, but I think a lot of the issues apply there as well. When I develop software, I don't need an editor, I need a development environment. I spend 90% of my time reading code, so reading and navigating the codebase should be very straightforward. Most importantly I want to have a tree view of the files in the project, I want to be able to jump to function/class definiti…

Tree view and go to def plus basic autocompletion (through tags) are very much built into vim. The rest can be done through plugins, these days very painlessly - but admittedly even a few years ago rather a hassle to set up.

Debugging, while perfectly doable depending on language, is I'd say the one thing still rather awkward.

Re: Neovim v0.4.0

#89
post #19

Why do we need such things in 2019?

I didn't get why this was important until I started working on a remote cluster. The only environment was the shell. Being used to VS code, I had a rough time with vim.

Learning neo/vim has been interesting in many regards. I now have a more "portable" setup (up to plug-ins)

Re: Neovim v0.4.0

#90
post #44
post #36

Earlier quoted context omitted.

Interesting. Are you using some sophisticated plugins, some unusual platform? I've aliased vim to neovim a few years ago and it has not crashed once for me.

OSX. Plugins: ale, bufexplorer, nerdtree, rust.vim, vim-airline, vim-airline-themes, vim-colors-solarized I generally start vim in my src folder on Monday and exit it on Friday. Occasionally, just on a whim, I run nvim instead. Mostly its fine. But the times I've experienced crashes or other hickups like rendering bugs forcing me to :qa!, it's been on nvim. Edit: Oh and I run it in the terminal, iTerm2 to be precise.

I wonder if any 2-4 of the folks who’ve never had it crash would find it fun to join in a mob-debugging session where you screenshare, we all open an discord* channel, and we try and figure out the cause and solution.

——

(* IM could be discord, gitter, slack, or whatever.

I’d argue strongly against IRC because I think the lack of support for code blocks and especially newlines makes it harder to talk about code/stacktraces.)

Post reply on HN