Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim 8.0 is coming

github.com

Post reply on HN
Print view View original

351–360 of 420 posts

Re: Vim 8.0 is coming

#351

Post by Watabou »

kh_hk wrote: post #94
dockerlocker wrote: post #34

Is there a way how I can copy blocks of code outside the vim window to another application without also copying the line numbers? Also is there one simple key combination to [un]comment a line or a selected block? I found out how to do many simple operations with this ancient tool, what can be really fun if you have nothing else funny in life (too many people have no other sources of fun, really) - but I am still not…

vnoremap "+y

Just a minor nitpick, vnoremap creates a mapping for select and visual modes. You should use xnoremap as that's restricted to visual mode only.

Select mode is used by snippet engines mostly, and you don't want this mapping to affect select mode.

Re: Vim 8.0 is coming

#352

Post by Watabou »

saturn_vk wrote: post #136
mgreenly wrote: post #96

Earlier quoted context omitted.

A better option would be to use a plugin that yanks text to the system clipboard.

You don't need a plugin for that. Just set the 'clipboard' option.

Note that you need Vim compiled with +clipboard for this to work (or +xterm_clipboard if you are using X11)

Re: Vim 8.0 is coming

#353

Post by coldtea »

laumars wrote: post #301
zeveb wrote: post #262

Earlier quoted context omitted.

I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI. That's true enough, although honestly I'm at a point in my computing where the G part of the GUI is pretty limited: my windows are all full-screen; the only clicking I regularly do is on links and tabs, and sometimes text (honestly, I'm trying to use the keyboard more for th…

> I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI. That's not strictly fair because running ncurses applications inside split tmux panes would give you a GUI-like UI inside a command line environment. Also some of the more esoteric WM's would provide that kind of functionality as well. The main reason it's more common to r…

You also get access to the whole world of GUI applications.

Watching video and editing pictures is not much fun with only ncurses... (ascii video hardly took the world by storm).

Re: Vim 8.0 is coming

#354

Post by coldtea »

Karunamon wrote: post #232
coldtea wrote: post #160

Earlier quoted context omitted.

> For me it's the question, why it's so hard to understand that people have different likings without to downgrade them? Because while everyone can have this or that preferences, personal taste is not the be all end all argument, except in the "it's a free country" way. Whenever we want to assess the state of our tools, and what we need to make them better etc, we need to reach an agreement beyond "works for me" and…

Who's "we"? If someone reaches a maximum of productivity using an editor made in the 70's, who is anyone else to tell them otherwise? Preferred tooling for reaching maximum productivity is an inherently personal thing - you may do your best in emacs, the other guy in vi, yet someone else in Sublime3 on Windows. Nobody is qualified to make broad sweeping judgments as to what works best for everyone. A few try, and som…

>Who's "we"? If someone reaches a maximum of productivity using an editor made in the 70's, who is anyone else to tell them otherwise?

Unless they work for themselves, that "anyone" can be: colleagues, supervisors, bosses, teachers, and even clients, and also industry experts and seasoned pros telling best practices.

>Preferred tooling for reaching maximum productivity is an inherently personal thing - you may do your best in emacs, the other guy in vi, yet someone else in Sublime3 on Windows.

And yet tooling is regulated all the time in all kinds of companies.

And all kinds of people mistakenly think they are more productive with X, where they would be with Y. People make bad tooling decisions all the time. For those people it's perfectly OK for others to tell them what they should use.

Re: Vim 8.0 is coming

#355

Post by mkehrt »

aidos wrote: post #25
arnsholt wrote: post #18

Earlier quoted context omitted.

Since I happen to have the answer to both of those: `daw` and `diw` deletes a whole word (unlike `dw` which only deletes forward). They differ in what they do with whitespace; `aw` also trims trailing whitespace (or leading whitespace if there's no trailing) while `iw` leaves the whitespace alone. These two are text objects that can be combined with other commands and quantifiers, so that `yaw` copies a word without…

If I want to put parens around a word I do, ciw() P (change word pulls it into the default register, insert the parens and then paste from the register back between the parens). You can use the same pattern for any selection you have visually highlighted, such is the wonderful power of vim.

Take a look at vim-surround, which adds mappings for a lot of things like this.

Re: Vim 8.0 is coming

#356

Post by tvon »

nerdponx wrote: post #145
octref wrote: post #49

I have a mixed feeling as a NeoVim user and long-time Vim user. On the one hand, great to see such a huge release for Vim that brings so many features people have been begging for. Especially Async IO and JSON. On the other hand, I hope Vim just become more stable and performant while not introducing new features. At the same time, I hope more development could go into NeoVim, and more people could start using it and…

I'm not a NeoVim user, but I've been on the edge of becoming one for a while. What I'm still holding out for is an _embeddable_ NeoVim. The thing I really don't like about IDEs is that I love my Vim configuration but I never get to actually use the damn thing since I do most of my work in an IDE. Now imagine if the IDE could actually just embed NeoVim, and I could use my Vimrc as-is with all the plugins (now managed…

As far as I know the NeoVim GUI apps[1] use msgpack-rpc[2].

[1] https://github.com/neovim/neovim/wiki/Related-projects#gui-p... [2] https://neovim.io/doc/user/msgpack_rpc.html

Re: Vim 8.0 is coming

#357

Post by jen20 »

Gonzih wrote: post #98
jen20 wrote: post #93

Earlier quoted context omitted.

You may want to consider looking at Evil mode, which gives you a very close approximation to the vim editing bindings in emacs. I've been using it as part of the spacemacs distribution for a while now and find it to be the best of both worlds.

Evil mode is slower than vim. And also you are in evil mode only during the editing phase. All other menus drop you back to default emacs keybindings and that is very painful experience. I used evil mode for a couple of years and still just went back to vim.

Spacemacs does a good job of _not_ dropping you back to emacs keybindings, though on occasion it still happens. I've not yet worked out how - my only recourse as someone who has never used Emacs without Spacemacs in Evil mode is to restart it...

The startup time compared to vim is painful, and the daemon mode on OS X appears not to work. For project work I use it heavily, but for quick edits still fall back to vim. I've yet to test whether neovim gets rid of the UI blocking that made vim so unusable for me though.

Re: Vim 8.0 is coming

#358

Post by cm3 »

mr_november wrote: post #299
cm3 wrote: post #241

Does anybody know what native feature is missing in Vim that makes Ctrl-P (with all optimizations) slower than Emacs ido-mode?

Not a real answer to your question, but for the last number of years I've been using Command-t ( https://github.com/wincent/command-t ) and after the initial index operation, it's super quick.

Command-t requires Ruby support in Vim.

It's interesting that ido-mode doesn't first create a cache, and the built-in functionality available via elisp seems to be sufficient for speedy performance.

Re: Vim 8.0 is coming

#359

Post by kolme »

microtonal wrote: post #336
kolme wrote: post #315

Earlier quoted context omitted.

> Software doesn't need to be developed ad-aeternum to remain 'alive'. I have to politely but firmly disagree. Software rots if it's not being actively maintained. Underlying API/ABI's get deprecated and eventually dropped, dependencies reach end-of-life and need to be replaced, and so on. Take one program today and try to run it in 10 years, as is. I bet it won't work. I'm talking of course, of any non-trivial piece…

Underlying API/ABI's get deprecated and eventually dropped, dependencies reach end-of-life and need to be replaced, and so on. But BSD vim (nvi) is maintained as part of the base systems of the BSDs, so it changes with system changes although it's in maintenance mode. E.g.: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/vi/

So yeah, it's being maintained. That's why it doesn't rot.

Re: Vim 8.0 is coming

#360

Post by kolme »

iamcurious wrote: post #344
kolme wrote: post #315

Earlier quoted context omitted.

> Software doesn't need to be developed ad-aeternum to remain 'alive'. I have to politely but firmly disagree. Software rots if it's not being actively maintained. Underlying API/ABI's get deprecated and eventually dropped, dependencies reach end-of-life and need to be replaced, and so on. Take one program today and try to run it in 10 years, as is. I bet it won't work. I'm talking of course, of any non-trivial piece…

Hey, if you want text in italics use asterixs. So > *Software doesn't need to be developed ad-aeternum to remain 'alive'.* becomes > Software doesn't need to be developed ad-aeternum to remain 'alive'.

Fixed it, thanks.
Post reply on HN