Live data from Hacker News

Vis: A Vim-Like Text Editor

github.com

61–70 of 166 posts

Re: Vis: A Vim-Like Text Editor

#61
post #50

Kudos to the developers for listing non goals. Too many software projects lose focus and become bloated because they take on features that are secondary to the main purpose. Projects may refrain from listing non goals for fear of excluding people who may want some of those features. And looking at the list, there are some pretty nice features excluded. For example network support, or editing compressed or tar files.…

concerning vimdiff: one of the goal is to get vis to also work in server mode and be embeddable. it should then be possible to create a diff tool that uses vis for the editing.

Re: Vis: A Vim-Like Text Editor

#62
post #47

Earlier quoted context omitted.

As much as I love visualizing my code with Intellij, the thing is huge and clunky. Nothing beats the simplicity of Sublime and the good'ol Terminal.

Unless it's vim and the good ol' terminal. :-D

.. unless its vim+cscope.

Re: Vis: A Vim-Like Text Editor

#63
post #56

One of these days, I'm going to sit down and try out this, emacs-evil, and neovim. Side-by-side. Need to figure out which one I like most.

I just switched from vim to neovim to evil. I can't see myself ever going back. (Neovim was basically just vim with async support, and terminals, but as a tmux user, that didn't really grab my attention). There's a lot more polish in the integrations for emacs than vim, likely as a result of literally everything in the editor being a function call that can be hooked into. The only thing I miss is solid tab functional…

Damn, thanks for the detailed comment. Pretty inspiring. I'm going to see whether I can switch over this weekend.

Re: Vis: A Vim-Like Text Editor

#64
post #47

More people should definitely try out sam and 9term as examples of how much code/features you don't really need and can still get real work done. Personally, I wish sam had even less complexity and features than it currently does and thus be more understandable and hackable. Also, never going back to a normal terminal again, "dumb" terminals are awesome. And actually, this experience has lead to a philosophy of softw…

As much as I love visualizing my code with Intellij, the thing is huge and clunky. Nothing beats the simplicity of Sublime and the good'ol Terminal.

Quite a few IDE's have the inherent flaw of being super bloated.

Re: Vis: A Vim-Like Text Editor

#65
post #25

Earlier quoted context omitted.

Reposting an answer from a related thread. The main difference is that vis is written from scratch while neovim inherited an old and hard to maintain code base. This allows vis to experiment with various ideas: - native multiple cursors/selection support - structural regular expression support - different core data structure resulting in efficient large file support - LPeg based syntax highlighting - Lua as an in pro…

Great! I remember last time I looked at Vis it wasn't so far along (it had no Lua integration AFAIK). When I started submitting code to Neovim my biggest desires for it were (1) Lua extensibility (2) A clean codebase (3) Compatibility with (most) Vim plugins. Perhaps ZyX-l's Vim to Lua project (for Neovim) could help with (3) at some point, if that's desired. An LPeg based syntax highlighting was also something in th…

> Does it build with LuaJIT?

I'm not sure. I think a few Lua >= 5.2 dependencies have crept in, but it shouldn't be difficult to fix this if desired.

LuaJIT's FFI is indeed very nice, but it is unfortunate that Lua has essentially been forked after the 5.1 release. The current C->Lua interface has been manually written.

Re: Vis: A Vim-Like Text Editor

#66
post #54

Earlier quoted context omitted.

Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?

It's not node.js that's horrible: it's great for what it does (web development). When taken out of that use case, it's awful, because it's simply not meant to do systems programming or to make local applications. It's kind of like people who knock Perl: it's made specifically for text parsing, nothing more, and too many people use it for much more. Since it's not meant for more complex things, it fails, understandabl…

"Hey guys, look what I did!"

crickets

"... with JAVASCRIPT!"

thunderous applause and/or retweets

Re: Vis: A Vim-Like Text Editor

#67

More people should definitely try out sam and 9term as examples of how much code/features you don't really need and can still get real work done. Personally, I wish sam had even less complexity and features than it currently does and thus be more understandable and hackable. Also, never going back to a normal terminal again, "dumb" terminals are awesome. And actually, this experience has lead to a philosophy of softw…

Just jumping off your last sentence: "Simplicity" and "Transparency" are orthogonal.

In the case of deep learning, all current state-of-the-art models can be expressed as nothing more than matrix multiplication, addition, and clipping. That's all you need. It's so simple: multiply, add, clip. Multiply, add, clip.

But the model isn't transparent. It's clear what each step is doing (multiply! add! clip!), but it's not clear to the human why that's necessary.

Re: Vis: A Vim-Like Text Editor

#68

More people should definitely try out sam and 9term as examples of how much code/features you don't really need and can still get real work done. Personally, I wish sam had even less complexity and features than it currently does and thus be more understandable and hackable. Also, never going back to a normal terminal again, "dumb" terminals are awesome. And actually, this experience has lead to a philosophy of softw…

I agree there are a lot of interesting ideas in 9term/sam/acme and Oberon (which was the initial inspiration for the project). In the future I would like to experiment with integrating a few more, but unfortunately time is a limiting factor.

Re: Vis: A Vim-Like Text Editor

#69
post #54

Earlier quoted context omitted.

Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?

It's not node.js that's horrible: it's great for what it does (web development). When taken out of that use case, it's awful, because it's simply not meant to do systems programming or to make local applications. It's kind of like people who knock Perl: it's made specifically for text parsing, nothing more, and too many people use it for much more. Since it's not meant for more complex things, it fails, understandabl…

That's because it's a waste of time to write a program in a primitive language like C when you don't end-of-the-world absolutely need performance/hard realtime guarantees; even then it's a better idea to only write the 5% performance-critical parts in C/asm and the rest in a saner high-level language.

C is definitely the wrong choice for a complex data-structure processing piece of software like a text editor.

Even though vanilla JS is madness, it gives you a very nice base to build on - namely closures and a GC, which make languages like Clojure or Purescript possible.

Still, for an editor I'd prefer pure Javascript over C every time.

Re: Vis: A Vim-Like Text Editor

#70
post #56

One of these days, I'm going to sit down and try out this, emacs-evil, and neovim. Side-by-side. Need to figure out which one I like most.

I just switched from vim to neovim to evil. I can't see myself ever going back. (Neovim was basically just vim with async support, and terminals, but as a tmux user, that didn't really grab my attention). There's a lot more polish in the integrations for emacs than vim, likely as a result of literally everything in the editor being a function call that can be hooked into. The only thing I miss is solid tab functional…

What's wrong with buffers? (Not attacking, just genuinely curious)

Like you, I loved my vim tabs. But "state" is what changed my mind.

In a few keystrokes, sure I could switch tabs. Right, right, right, right, there that's the tab I want. But it's coupled to my project state: if I close a tab, there goes the muscle memory for that session. Now it's "right-right" to get to the thing I need instead of "right-right-right".

Buffers are invariant to your session state. In a few keystrokes, I could just search for the buffer by the first few letters of its filename.

I routinely keep >500 buffers open in emacs. Ten projects, half a year of journal entries, a few dozen mail messages. Having all those things available in the same number of keystrokes no matter where I am is immensely helpful.

It's like Huffman coding for your workspace.

Post reply on HN