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

381–390 of 420 posts

Re: Vim 8.0 is coming

#381

Post by Gonzih »

tingol wrote: post #343
Gonzih wrote: post #222

Earlier quoted context omitted.

I was also using spacemacs for something like 2 month. After that I just rewrote my vim configuration with what I learned from spacemacs in mind. It's great and clean. But it's still emacs and vim emulation. Nowadays i'm much happier with my vim configuration partially thanks to spacemacs.

Can you share the things you took with you? I'm always interested in spicing up my vim experience.

Mostly key bindings. Space as a leader. Everything themed by prefix. Like mee to eval clojure form in repl. mek to show clojure documentation. cl - comment line. Switched to unite. Duplicated most used things from helm in unite. You can check out my github repo with vim configs at Gonzih/.vim on github.com

Re: Vim 8.0 is coming

#382

Post by Joof »

coldtea wrote: post #200
cicero wrote: post #175

Earlier quoted context omitted.

Mice are not a 100% replacement for keyboards. If you're doing lots of typing, there is something to be said for keeping your hands on the keyboard. Vim and emacs facilitate this much better than GUI-based editors.

> Mice are not a 100% replacement for keyboards. And they're not used as such. They are used as complimentary to keyboards. On the other hand, mice-based GUIs ARE a 100% replacement for CLIs.

While more complicated, CLIs tend to be more expressive, easier to program as a platform and simpler to communicate between than GUIs.

Expressive, because they are built on top of (and as a part of) languages. You can do this in a GUI, but it seems to be rare; instead the program typically defines how you manage inputs and outputs.

They are easy to program for. GUIs typically require an additional framework (and are still difficult to build).

CLI typically communicates over plain text. Getting two GUI programs to talk to each other is typically very difficult. You can string a bundle of CLI commands together and build new functionality, but this is much more difficult with a GUI. This is partly a philosophical difference; the CLI platform encourages plaintext interop, but a GUI platform typically encourages isolated programs (possibly with API).

That said, nothing is perfect. There are plenty of instances were a GUI is better. People can understand visual data better and notably it's far easier to understand in an intuitive way. But it's certainly not a 100% replacement.

Re: Vim 8.0 is coming

#383

Post by pjmlp »

vbit wrote: post #342
cytzol wrote: 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…

I agree with you that session persistence is generally lacking in a most of these tools. I there an editor/IDE you use that gives you the persistence?

Smalltalk and commercial Common Lisp environments come to mind, where you can save the working session as an image.

Most modern IDEs also have a notion of session.

Re: Vim 8.0 is coming

#384

Post by blueblob »

groovy2shoes wrote: post #366
baldfat wrote: post #111

Earlier quoted context omitted.

Vim stands for vi improved and started on the Amega in 1991 so almost 25 years old. Certain people still use vi which was an improvement over ed August 1969 (Though I have been known to use ed in scripts from time to time).

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?

Re: Vim 8.0 is coming

#385

Post by ufmace »

groovy2shoes wrote: post #368
drKarl wrote: post #213

Earlier quoted context omitted.

Have you tried Vrapper, or any other Eclipse Vim plugin like viPlugin or Eclim? Or if you use IntelliJ Idea it also has a plugin for Vim

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 right for me.

Maybe check for updates? They do seem to update it semi-regularly - I think they fixed the number-gt command within the last 6 months or so.

Re: Vim 8.0 is coming

#386

Post by pklausler »

pyre wrote: post #377
pklausler wrote: post #307

Earlier quoted context omitted.

Write one, then. I did. It's not hard. Mine's about 7K lines of code and it's the perfect text editor for me.

Do you have fun integrating every new mode that you might like to use when you decide to open a source file for a new programming language?

I think that what you're trying to express is that I might be wasting some time implementing support for some syntax highlighting and code formatting features that are already present in other editors. Thank you for your concern. It hasn't been much of a problem since (1) I don't really used much syntax highlighting other than for reserved words, string literals and comments, and paired bracketing characters, (2) I rarely need to view or edit files besides C/C++/Haskell/bash/LaTeX, which I have support for, and (3) the editor works just fine on other files without fancy-pants modes anyway.

Re: Vim 8.0 is coming

#387

Post by laumars »

coldtea wrote: post #353
laumars wrote: post #301

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 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).

There's no reason you can't have a CLI interface with graphics support. Granted the vt100-style terminals can't easily do it, but it was possible with the old REPL machines of the 80s (eg most micro computers which booted into a BASIC interpreter).

There are some also some terminal emulators in Linux that support inlined graphics, however I'm not sure how easy it would be to run them as a WM.

Re: Vim 8.0 is coming

#388

Post by na85 »

blueblob wrote: post #384
groovy2shoes wrote: post #366

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?

But ed is the standard Unix text editor.

Re: Vim 8.0 is coming

#389

Post by exception_e »

hack_edu wrote: post #167
akerro wrote: post #155

Earlier quoted context omitted.

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

As long a there are keyboards, there will be Vim.

This is the most beautiful thing I've read all day.

Re: Vim 8.0 is coming

#390

Post by andrewstuart2 »

andrewstuart2 wrote: post #313
majewsky wrote: post #72

Earlier quoted context omitted.

Especially Syntastic. It's always a pain when every ":w" of a Ruby file hangs for 5 seconds during syntax checking because Ruby is so abysmally slow.

Yeah, Syntastic is my number one offender. I'd love to see Syntastic be able to just maintain a background server linting process (or several). I can imagine that alone, skipping all the environment loading/code parsing, would likely be good enough to make all but the longest files lint fast enough to be unnoticeable.

(Still worth it by far, though. I'll take a few seconds and nice error highlight over an hour of "Where the heck is my missing semicolon?")
Post reply on HN