Live data from Hacker News

Vis: A Vim-Like Text Editor

github.com

111–120 of 166 posts

Re: Vis: A Vim-Like Text Editor

#111
post #79
post #69

Earlier quoted context omitted.

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…

There are more concerns than performance. The choice of C here is a philosophical one. Vis seems to come from the same school of thought as the Suckless projects, where the unix design principles are worshipped. People who are interested in that kind of stuff are also usually fans of writing in C, simply because C is the most Unix of languages: Makefiles control the build, which allows trivial integration of external…

I agree that often the choice of C is philosophical rather than technical, or we wouldn't see so much misuse of that language (and yes, I wouldn't count the build or package management system (or rather the non-existence thereof) or the documentation format as serious technical arguments for or against a language).

Just to be clear, I'm not advocating the usage of Javascript here, rather I'm trying to make the point that C is a really really primitive language and programming in it, rather than in a higher-level language (any higher-level language) is almost always a waste of time.

(Drivers and memory / performance-constrained code being an exception.)

Btw, there's a mmap module or library for any major programming language out there (checked for Js, Python, Ruby, Haskell, even Clojure.)

Re: Vis: A Vim-Like Text Editor

#112
post #69

Earlier quoted context omitted.

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.

I meant hard realtime [0]. Your operating system is probably not hard realtime, which means that any editor you run isn't either.

[0] http://stackoverflow.com/questions/17308956/differences-betw...

Re: Vis: A Vim-Like Text Editor

#113
post #95
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.

Oh, you don't care for JS/node? That's really interesting. Do you have a non-flammable, on-topic comment about the project?

A drive-by provocation can be hard to resist, but please don't take HN threads further into flamewar.

Re: Vis: A Vim-Like Text Editor

#114
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.

Please don't engage in programming language flamewars here. They're shallow, tedious, and silly, and never teach anybody anything (except maybe flamewar tactics).

Re: Vis: A Vim-Like Text Editor

#115

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.

"Plugins" can mean many things, ranging from dynamically loading parts of the app to having an embedded scripting language.

I'm fine with a text editor without plugins as long as the editor can neatly interface with external applications. I used to use some Vim plugins but I found them to be more trouble than they're worth. Now I have vanilla Vim with only some syntax highlighting additions.

Rather than embedding my workflows into the editor, I'd like to embed the editor in my workflows. I don't want to run terminal apps from inside the editor, but I do want to run external apps and get the results in the editor. E.g. Vim has :make and :grep that work with the quickfix list, but this can also be done by invoking make or grep in the shell and piping the output to vim (+ some command line options to read the quickfix from stdin).

For my use, the feature that Vis needs the most is the client-server model, so I can use tmux to manage windows and open editor windows in any terminal session. That, coupled with some helpers to run external apps should do more than 80% of what I'd use editor plugins for.

Re: Vis: A Vim-Like Text Editor

#116

You won't do it. You're too lazy and there is no immediate motivation for doing something like that.

We've banned this account for repeatedly breaking the site guidelines.

We detached this subthread from https://news.ycombinator.com/item?id=11446242 and marked it off-topic.

Re: Vis: A Vim-Like Text Editor

#118
post #91

Earlier quoted context omitted.

Yeah. I've been using Acme for awhile now. While Acme itself is nice, what I really like is the B/E editor embedded in it. It's just a very simple editor that can be extended with _external_ programs. Finally, I've come to appreciate using a mouse with my editor. Until I completely got rid of using most keyboard shortcuts (other than the most basic ones), I didn't realize how much cognitive taxes I was paying to reta…

What does B/E stand for?

They are the utility scripts to start an editor window in Acme. B is async whereas E is sync (so that it can be used for the EDITOR env variable for software like git).

Not sure what they stand for for sure. E is probably editor. B might be buffer?

Re: Vis: A Vim-Like Text Editor

#119

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

Yes the lack of binary packages is a known problem.

The whole project is still somewhat in flux, feel free to contribute by filling a packaging request to your favorite distribution ...

Historically it originates from a community which is comfortable building from source.

Re: Vis: A Vim-Like Text Editor

#120
Every good programmer should write their own text editor, I think, much as each Jedi must build their own light saber. It's the tool that a programmer will spend a disproportionate amount of their time using, and they should know it well. And it's fun to do, and easy (c. 7KLOC or so for mine).
Post reply on HN