Live data from Hacker News

Vim 8.0 is coming

github.com

281–290 of 420 posts

Re: Vim 8.0 is coming

#281
post #137

Earlier quoted context omitted.

I value very different things than you do. Vim and Emacs have a more difficult learning curve but the beauty of it... and configuring it to your liking is that it can surpass in speed and capabilities what some very convenient editors can do for a single language. I use MacVim and my .vimrc file follows me around wherever I go. My experience is great in my editor because the few minutes I invested here and there have…

> I use MacVim and my .vimrc file follows me around wherever I go. Minor nit in support of parent comment: no it doesn't, you have to copy or sync it around yourself. Atom is a great example of an editor that is aware of the internet existing. Vim, while my daily driver, is not.

> Atom is a great example of an editor that is aware of the internet existing. Vim, while my daily driver, is not.

I don't know how I'd securely and easily have a powerful editor configuration follow me around.

A powerful editor can do damaging things: it interacts with its host system; it can run commands; it can read and edit any files on disk; it can access the network. That means that I — not some web site run by attention-deficit VCs and subject to any number of hostile governments — must have ultimate control over what it can do.

So it has to be secure. But security means that the configuration may not be visible to others (because it may contain information I choose not to release) and it means that the configuration I fetch today must verifiably be the configuration I pushed yesterday. That means hashes, and signing, and identities.

None of that is easy, and building that infrastructure just for trading editor-configs seems like a waste. Wouldn't it be nice to have a general infrastructure for that?

So maybe it makes sense to sync editor configs around after all.

Re: Vim 8.0 is coming

#282

Earlier quoted context omitted.

a good example for a stupid limitation and the enprmous waste of brian power just for a very simple thing. Have to start studying and doing real research for the most simple features. Waste!

Ideally, Vim is a tool you'll be able to use for the rest of your life, so an upfront cost in learning it is a cost that becomes small when measured against the time scale of your career. Furthermore, Vim needs to be setup and is configurable because it existed before many computer usage patterns had been standardized that we take for granted now (e.g., Vim's cut and paste system is different than any current big nam…

Very true. I hand-compiled and memorized my own vi cheat sheet decades ago, and it has paid off very well. It's systematic, as many tutorials point out, which helps a lot.

Re: Vim 8.0 is coming

#283
post #245

Earlier quoted context omitted.

I apologise in advance if this sounds dismissive, but: I've tried to use both Vim and Emacs and Neovim and Spacemacs, and every time my pain point is that they're designed for use on the command line rather than as an environment I can switch in and out of. I know this isn't strictly true as both editors can be run as separate applications that you don't quit for weeks, but their roots have persisted into how they're…

Short life times for vim are more a thing on remote sessions, e.g. for server configuration. I agree with you, that such a work flow is suboptimal for the general development case, so I will just describe what works for me: Do not close vim. I keep a main vim instance which has different buffers open. These buffers have their own history, e.g. undo-tree, etc. And keep in mind, that it takes time to get adjusted to vi…

Yeah, I do still use vim on remote sessions where I know I'm just going to be making a small change and then be done with it -- losing your entire environment or history is a lot less worrying in that case, and it's way easier than mounting the server locally or something.

However, as someone once said: "The universe tends toward maximum irony. Don't push it." If you don't close vim and keep it open for weeks, then all your environment changes are going to keep on building up, only for you to lose everything the next time you need to restart your system, or upgrade your editor or terminal, or your OS crashes, or there's a power failure, or your computer catches fire.

Re: Vim 8.0 is coming

#284
post #4

I have vim, neovim and emacs (and spacemacs) installed. Right now I'm trying to get into emacs a bit more. What's interesting to me, and the reason I try to keep up to date with the latest changes for all four editors, is that it's been now, what, 25 years (?) since emacs and vim started "competing" and they still are. I guess we could be saying the same in 10 years about firefox and chrome, but it still is amazing i…

>I guess we could be saying the same in 10 years about firefox and chrome That's pretty optimistic considering Firefox's current marketshare. Based on its momentum I'd say in 10 years, at best, I expect it to be where Opera was before it became a Chromium fork. For now Firefox does things better than Chrome but I don't expect them to keep up when it becomes a community project. It'll be like using Opera used to be.

Didn't Firefox just announce that future plans include moving to Chromium?

Re: Vim 8.0 is coming

#285
post #4

I have vim, neovim and emacs (and spacemacs) installed. Right now I'm trying to get into emacs a bit more. What's interesting to me, and the reason I try to keep up to date with the latest changes for all four editors, is that it's been now, what, 25 years (?) since emacs and vim started "competing" and they still are. I guess we could be saying the same in 10 years about firefox and chrome, but it still is amazing i…

I think emacs is fundamentally a better system but I'm using vim because that's what my computer could run better when I was 15 in the mid 90s.

Shackled by my past...

Re: Vim 8.0 is coming

#286
post #155

Earlier quoted context omitted.

To be fair, vim is not strictly vi although they were related. Amazing, I was 1 year old when both were started. How many other software package has such longevity? Unix and its various guises?

I have a better question. Will those tools be still used in 40 years? And what modern tools will be used after that time?

Let's hope not.

Re: Vim 8.0 is coming

#287

Earlier quoted context omitted.

>On the other hand, mice-based GUIs ARE a 100% replacement for CLIs. Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs. (Points deducted for anything that inv…

AppleScript can do pretty complex GUI automation tasks.

Windows 3.1 had a macro recorder that allow to automate task over a GUI.

Re: Vim 8.0 is coming

#288
post #162
post #10

Earlier quoted context omitted.

I became an heavy Emacs user as I could not find the comfort of Borland IDEs in UNIX, as I started to use it. Since I moved away from C++ into Java and .NET land, never felt the need to use them any longer. And nowadays, with Qt Creator, Clion, xCode, AppCode and VS, I also don't feel the need of them when I need to go back to C++. It is very good to know the basics from plain Vi, because there are still commercial U…

At my last job, I was doing mostly Java server stuff. I switched between Vim and Eclipse seamlessly, depending on what task I was trying to accomplish. Vim is better at plain text editing, Eclipse is better at navigating convoluted Java hierarchies or debugging Java code. For me, those tools are not exclusive but complementary.

use the VI plugin for eclipse. At least can handle :w and :%s

Re: Vim 8.0 is coming

#289
post #4

I have vim, neovim and emacs (and spacemacs) installed. Right now I'm trying to get into emacs a bit more. What's interesting to me, and the reason I try to keep up to date with the latest changes for all four editors, is that it's been now, what, 25 years (?) since emacs and vim started "competing" and they still are. I guess we could be saying the same in 10 years about firefox and chrome, but it still is amazing i…

I think emacs is fundamentally a better system but I'm using vim because that's what my computer could run better when I was 15 in the mid 90s. Shackled by my past...

You might want to give spacemacs a try. It really doesn't feel like emulation. For me, it's been the better of both worlds. Ultimately, you'd have to learn some emacs stuff for sure, but you should be able to get day-to-day productive almost immediately.

Re: Vim 8.0 is coming

#290

Earlier quoted context omitted.

Nope. This isn't a migration; it's one-off data population. Fluent Migrator can do that, from its documentation, but it wouldn't be required, and since this isn't a migration, Fluent Migrator doesn't really bring anything to the table that I can see. So you're building a custom software project in your language of choice, with all the overhead that implies. In the workflow I described, you create a file and activate…

> "In the workflow I described, all that code is already written, and you can invoke it with a single keystroke." The thing is, if that's the case, what you're describing isn't a custom plugin, it's an existing plugin someone else has taken time to write that you're making use of. If that's the argument you're making then you could say Emacs has a better ecosystem of plugins, and that it's easier to tie them together…

It's a subset, and the Blub paradox applies.

For one thing, Org isn't a plugin; it's part of the Emacs distribution, rather than something you have to explicitly install. All you need to do to use all the functionality I described is install Emacs and start it up.

For another, Emacs doesn't actually have a plugin system, per se. Instead of the usual headache, where a program written in language A exposes a lossy subset of itself to plugins written in language B, Emacs just exposes all of the language in which it itself is written, and you can do what you like. The usual distinction between first-class application code and second-class plugin code doesn't exist. There's just Emacs Lisp code, any of which can freely interact with any other Emacs Lisp code running in the same process space, including effectively all of Emacs itself.

You can add new code by installing packages from a repository, which you can do in a single command if you know the name of the plugin you want. (If you don't, there's a searchable list.) Or you can do it by opening an Emacs Lisp buffer, writing some code, and evaluating it - again, with a single keystroke. If you like it and want to keep it around, save it to a file: boom, it's a "plugin". Add a line to your init file to load it, and it's a "plugin" you're using. Or you can just drop your new code into your init file directly, because your init file is - you guessed it - just Emacs Lisp code, that happens to be in a file Emacs will load and execute when it starts up.

As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too.

Post reply on HN