Live data from Hacker News

Vim 8.0 is coming

github.com

411–420 of 420 posts

Re: Vim 8.0 is coming

#411
post #335

Earlier quoted context omitted.

Using separate programs like eqn. ( http://www.kohala.com/start/troff/v7man/eqn/eqn2e.ps )

Sorry, but eqn is just not in the same league as LaTeX. It's okay for simple equations, but as can be seen from the document you linked, it produces awful output as soon as the equations become a little bit complex.

Take a look at http://download.savannah.gnu.org/releases/lout/lout-3.40-use... (page 148 and followings).

Re: Vim 8.0 is coming

#412

Earlier quoted context omitted.

> 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 y…

The question was not about regulation - of course you can tell anyone to do whatever nonoptimal bullshit you want if you have power over them. I'm asking what gives anyone the ability to make a correct judgment about tools and productivity?

>I'm asking what gives anyone the ability to make a correct judgment about tools and productivity?

Extended experience (compared to someone who've only used X, someone who has extensively used X,Y and Z editors trumps them).

Besides, some people have so narrow a view, that almost anybody even a little experienced can immediately tell (correctly) that they are not using the correct tools. E.g. people coding with Notepad...

Also, science. E.g. statistical tests with control groups et al, with teams using A or B editor, and checking for speed of writing code, number of bugs, impediments to workflows, etc.

Re: Vim 8.0 is coming

#413

Earlier quoted context omitted.

The question was not about regulation - of course you can tell anyone to do whatever nonoptimal bullshit you want if you have power over them. I'm asking what gives anyone the ability to make a correct judgment about tools and productivity?

> I'm asking what gives anyone the ability to make a correct judgment about tools and productivity? Extended experience (compared to someone who've only used X, someone who has extensively used X,Y and Z editors trumps them). Besides, some people have so narrow a view, that almost anybody even a little experienced can immediately tell (correctly) that they are not using the correct tools. E.g. people coding with Note…

Your extended experience is valid only for you because it represents your biases for the way your mind works. It is not valid for the larger population.

To my knowledge, no such scientific statistical tests exist with a large enough sample size.

Re: Vim 8.0 is coming

#414

Earlier quoted context omitted.

I use these editors for so much more than programming. I'll often have a buffer open just for scratch notes and org-mode for my todo lists. I've written papers for school using LaTeX in emacs too. If you're editing a lisp in emacs, you can already get halfway there with plugins like paredit or smartparens. You are pretty much editing the AST at that point.

Paredit is a textbook leaky abstraction. I find the experience very jank because of it.

how so?

Re: Vim 8.0 is coming

#415

Earlier quoted context omitted.

If you ever wind up booting the OpenBSD ramdisk kernel (typically used for installation and system rescue), the only editor available is ed. Luckily, if you're reasonably comfortable with vi, you'll find that most of the 'colon commands' work, and the other commands are pretty familiar ('i' for insert, 'a' for append, etc.). If you're an OpenBSD power user, it behooves you to have a hardcopy of the ed manpage handy ;…

The OpenBSD ramdisk doesn't provide busybox vi?

Nope. The OpenBSD ramdisk doesn't provide busybox anything. I just double-checked on 5.8. I also doubt that they'd ever switch to using busybox given their aversion to the GPL. They also have their own tool (crunchgen) that packs a bunch of binaries into a single "Swiss army knife" executable.

Re: Vim 8.0 is coming

#416
post #385

Earlier quoted context omitted.

The Vim emulation plugin that ships with Intellij IDEA is absolutely awful. I used it for about 30 minutes, then uninstalled it in frustration. Certain commands just didn't work right, and some didn't work at all. There was also no indication whatsoever of what mode you were in, so you just had to keep track of it in your head. The experience was not pleasant at all. I'd rather have no Vim emulation than poor emulati…

I'm wondering what you thought the worse omissions on it were. I've used IdeaVim on Android Studio, and find it passable, if not great. My main beefs that I can think of right now are that my vimrc commands for leader+j and k mapping to 10j and k don't work, and it sometimes messes up the spacing on blank lines, causing the { and } jumps to not work right. I'm pretty sure the cursor changing on mode switch worked rig…

I honestly can't remember the details now, because it was quite some time ago. I just remember getting fed up rather quickly and returning to the default keybindings. Perhaps the situation has improved since then.

Re: Vim 8.0 is coming

#417
post #331

Earlier quoted context omitted.

I think the former---from what I've heard neovim and vim are on very good relations, and here is the fruit of that.

Negative. NeoVim does away with supporting the ancient systems that are important to Bram for some reason. I seriously doubt they will merge.

Good relations =/=> must plan to unfork, at least in a post-git world.

Re: Vim 8.0 is coming

#418

Earlier quoted context omitted.

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 subs…

> "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." Nah, it's nothing to do with the blub paradox. I've dabbled with…

Visual Studio integrates well with the capabilities of C++ and of languages that run on the CLR. Outside that realm, it can do little or nothing for you.

Emacs integrates well with the same capabilities in almost any language that provides them - even C#.

See the difference?

Re: Vim 8.0 is coming

#419
post #137

Earlier quoted context omitted.

> 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. In what way?

Auto-update of plugins. Plugin listing, download, and installation.

Re: Vim 8.0 is coming

#420
post #399

Earlier quoted context omitted.

Hence why we GUI guys rather use a REPL than a plain UNIX CLI. Graphics, the expressiveness of a sane programming language and interaction with the complete OS stack.

Firstly, Bash et al is a REPL in it's own right. What you're discussing there is that UNIX shells make a rubbish programming environment, which is a completely different argument to anything that was being discussed here. For example, DOS can inline graphics as well (proper DOS, not Windows' cmd.exe). So to follow the linked tangent you've made: DOSbox is also a better REPL than UNIX shells. Obviously neither of us w…

UNIX shells aren't a REPL because 99% of their features are implemented in external commands. The shell is reduced to orchestrate logic between those commands.

None of the common ones, ash, sh, bash.... provide a rich programming environment that doesn't rely on external commands.

Interaction with the whole OS goes back to Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon REPL experiences. Nothing to do with running headless, which means you didn't got the message.

In those environments I can via the REPL directly interact with running applications from the REPL. For example, search for a specific text in all open windows and act upon it if found.

The whole OS API is exposed in the REPL via library calls.

No UNIX shell provides this expressiveness without relying on external commands and applications implementing specific APIs like dbus.

Post reply on HN