Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vis: A Vim-Like Text Editor

github.com

Post reply on HN
Print view View original

81–90 of 166 posts

Re: Vis: A Vim-Like Text Editor

#81

Post by [deleted] »

martanne wrote: post #22
Mossisen wrote: post #11

How would you compare this to the NeoVim project? https://github.com/neovim/neovim

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…

[deleted]

Re: Vis: A Vim-Like Text Editor

#82

Post by falcolas »

starseeker wrote: post #43

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…

For a standalone piece of software, what about licensing matters for your use cases?

Re: Vis: A Vim-Like Text Editor

#83

Post by bigtunacan »

This seemed interesting and I'm glad they posted their "Non goals". For me, and I would assume many others, plugins (which apparently is part of the 20% they don't plan to support) is one of the most critical features to any good text editor. This is one area where I think they may want to reconsider.

Re: Vis: A Vim-Like Text Editor

#84

Post by notzorbo3 »

falcolas wrote: post #82
starseeker wrote: post #43

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…

For a standalone piece of software, what about licensing matters for your use cases?

It's right there in his comment:

> I've done a couple searches for an editor that could be embedded with an LGPL project, and the choices were pretty limited.

Re: Vis: A Vim-Like Text Editor

#85

Post by notzorbo3 »

I was gonna complain about the lack of binaries, which will instantly make me skip your project, until I saw this:

> On Linux based systems make standalone will attempt to download, compile and install all of the above dependencies into a subfolder inorder to build a self contained statically linked binary.

You'll still need the entire compiler toolchain, and 'libtool' on Ubuntu. I got as far as the ncursesw dependency before I gave up.

Re: Vis: A Vim-Like Text Editor

#86

Post by lolsal »

cloudhead wrote: post #33
StreamBright wrote: post #30

What would be the advantage of using it over vim? I am just curious. One thing I found is huge file support that would be definitely good but not sure about the rest.

The promise is that given it's a new, modern codebase, it could quickly outpace vim in capabilities and usability. Vim's legacy is what is holding the editor back from major improvements.

It sounds like you are saying it is better just because it is being written from scratch. I don't plan on contributing or writing any plugins to Vis (or vim) so I don't really care about what the 'guts' of the project look like as long as it does what I use it for (text editing). What motivation would I have to install Vis and deal with the mental overhead of switching (I am sincerely asking)? I have the same concerns with NeoVim. Maybe I just need to wait a decade for the ecosystem to catch up.

Re: Vis: A Vim-Like Text Editor

#87

Post by kps »

cturner wrote: post #9
pttrsmrt wrote: post #4

But what does it got that vim doesn't?

Sam expressions for manipulating text. This is a blub thing - if you haven't seen them you might not realise what you're missing out on. Try to imagine an editor where the core idea is a better-sed-than-sed. Two well-known editors to come from the ed tradition: vi and sam. Vi is an obvious evolution - make it 2d. Sam did this as well, but its main focus was developing the expression language. For example, so you can…

Mouse-dependency put me off the sam/acme line (I'm stuck with only two hands, and ssh rather than 9p), but this looks very interesting.

Naming nit: vis(1) has been around for 25 years: http://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/share/...

Re: Vis: A Vim-Like Text Editor

#88

Post by SpaceCadetJones »

bigtunacan wrote: post #83

This seemed interesting and I'm glad they posted their "Non goals". For me, and I would assume many others, plugins (which apparently is part of the 20% they don't plan to support) is one of the most critical features to any good text editor. This is one area where I think they may want to reconsider.

I imagine this would be a non-starter for a lot of people, it definitely is for me

Re: Vis: A Vim-Like Text Editor

#89

Post by zeveb »

mbrock wrote: post #54
rplnt wrote: post #51

I feared it would be written in javascript (it's on the front page of HN after all), but I was very positively surprised. There are projects where it's not appropriate to use node.js and the hell it comes with.

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

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

Back in the second century BC, Cato the Elder ended his speeches with the phrase 'Carthago delenda est,' which is to say, 'Carthage must be destroyed.' It didn't matter what the ostensible topic of the speech was: above all, Carthage must be destroyed.

My opinion towards JavaScript is much like Cato's towards Carthage: it must be rooted out, eliminated and destroyed entirely. I don't know if I'd go quite so far as to say that the fundamental challenge of mass computing is the final destruction of JavaScript — but I want to say it, even though it's false.

JavaScript is a pox, a disaster, a shame. It is the most embarrassingly bad thing to become popular in computing since Windows 3.1. Its one virtue (that it's on every client device) is outshone by its plethora of flaws in much the same way that a matchstick is outshone by the sun, the stars and the primordial energy of the Big Bang added together.

JavaScript is the XML, the Yugo, the Therac-25 of programming languages. The sheer amount of human effort which has been expended working around its fundamental flaws instead of advancing the development of mankind is astounding. The fact that people would take this paragon of wasted opportunity and use it on the server side, where there are so many better alternatives (to a first approximation, every other programming language ever used), is utterly appalling.

JavaScript delenda est.

Re: Vis: A Vim-Like Text Editor

#90

Post by digitaltoad »

pka wrote: post #69
benbenolson wrote: post #59

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…

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

>end-of-the-world absolutely need performance/hard realtime guarantees

As someone who spends much of their time inside a editor, I would say that this is pretty important to me.

Post reply on HN