Live data from Hacker News

Vis: A Vim-Like Text Editor

github.com

161–166 of 166 posts

Re: Vis: A Vim-Like Text Editor

#161
post #108

I note that with the exception of the sam code (which unfortunately uses the Lucent Public License Version 1.02, this editor is very liberally licensed (ISC/MIT/CC0). If the sam code is optional or easily replaced, this could evolve to become a serious, modern text editor with a truly liberal license (something surprisingly absent from the current landscape, to the best of my knowledge - I've done a couple searches f…

nvi? https://sites.google.com/a/bostic.com/keithbostic/vi/ Sure it doesn't have the features of Vim or Emacs (and some would say that's a feature!), but it's perfectly serviceable if you're okay with vi's modality.

Close, but it doesn't appear to be active (the version you get from the download link is from 1996?) and it's using the 4 clause BSD license, which (as I understand it) poses GPL compatibility problems.

Re: Vis: A Vim-Like Text Editor

#162
post #135

I note that with the exception of the sam code (which unfortunately uses the Lucent Public License Version 1.02, this editor is very liberally licensed (ISC/MIT/CC0). If the sam code is optional or easily replaced, this could evolve to become a serious, modern text editor with a truly liberal license (something surprisingly absent from the current landscape, to the best of my knowledge - I've done a couple searches f…

Go is a good target for portable text editors these days, IMO: https://github.com/nsf/godit

A good point. I didn't specify in my initial comment (and I should have) but one of our other criteria is to be able to build everything with just a C/C++ compiler. So we'd have to bundle/bootstrap Go just to build the editor, which I believe is too heavy to be practical for that (unfortunately).

Re: Vis: A Vim-Like Text Editor

#163
post #147

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…

What are multiple cursors useful for?

evil-mode lets you do things like "insert this text into the same position in a block of consecutive lines" using rectangular selections. I find it occasionally very helpful. It's a little clunky though: you make the selection, press I, edit the first line, press esc, and then the other lines get edited the same way. (I'm not sure what "the same way" means if you delete a bunch of text or move the cursor around while editing.)

I haven't used multiple cursors, but I imagine they'd let you do that, but with the other lines getting updated in real time, and without requiring the insert points to be neatly aligned.

Maybe other stuff too.

Re: Vis: A Vim-Like Text Editor

#164
post #144

Earlier quoted context omitted.

So instead of the vim philosophy of embedding every functionality within vim, this potentially embeds vis in every functionality? I actually like that--much more composable.

I believe (and I may be wrong) that the vim philosophy is actually to embed vim in things rather than embed things in vim. They've just lost track of that a little over time. See also :help design-not : 'Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A sa…

You're right, and I sold vim a little short there, compared to something like emacs.

More accurately, I meant that when someone wants to combine vim with a functionality they tend to implement it as a plugin with vim as the host and interface. I won't speak for anyone else, but my vimrc tends to accumulate a lot of behavior such that it's still a kitchen sink--it just wasn't included with the initial distro.

Re: Vis: A Vim-Like Text Editor

#165
post #66

Earlier quoted context omitted.

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

I wrote a compiler for a toy functional (lazy) language.

In bash.

Re: Vis: A Vim-Like Text Editor

#166
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…

Hope ZyX-l could join vis. :)
Post reply on HN