Live data from Hacker News

Vis: A Vim-Like Text Editor

github.com

91–100 of 166 posts

Re: Vis: A Vim-Like Text Editor

#91

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…

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 retain and context-switch among different families of keyboard shortcuts. Mousing is so much more uniform.

Re: Vis: A Vim-Like Text Editor

#92
post #80

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…

I still like node for writing utility CLIs as well, which I find myself doing A LOT these days. To be totally fair, that's mainly because of the excellent feature rich CLI modules out there (yargs, commander, etc...); but, I've found I want my CLI utilities to be in an interpreted language, and node just fits the bill pretty well for that.

But why? It's a deployment nightmare to keep node updated on servers and laptops and desktops that will never, ever use node to server server-side JS, why do I need it and NPM and the whole upgrade nightmare it implies to run a random CLI utility?

Re: Vis: A Vim-Like Text Editor

#93
post #89
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?

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

+1 for effort, but I fucking love Javascript.

Re: Vis: A Vim-Like Text Editor

#94
post #89
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?

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

That's great, but someone else thinks PHP is worse than javascript. (All those copy-pasted security holes.) Another person thinks iOS is the real problem. (If we don't own our devices, we're not free.) For me it's malaria. (Think how many more capable programmers we'd have if fewer people were dying every day. Plasmodea delenda est!)

We can all go around commenting on every single thread about how our chosen terrible thing is terrible, and then every thread looks exactly the same and it gets really boring. Or we can all restrain ourselves to only talking about how terrible our chosen terrible thing is, in threads that are about that thing.

Re: Vis: A Vim-Like Text Editor

#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?

Re: Vis: A Vim-Like Text Editor

#96
post #89
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?

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

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

Well, as long as you're having fun!

Re: Vis: A Vim-Like Text Editor

#98

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…

Have you seen http://c9x.me/edit/?

Re: Vis: A Vim-Like Text Editor

#99
post #57
post #32

Earlier quoted context omitted.

Well. Having a terminal as a buffer makes it possible to copy/paste into/from the terminal. Also autocomplete from all the buffers is working. It's really convenient. And implementing a repl integration is trivial.

You can also make a command that inserts a file into the current tmux buffer, which is technically a much more straightforward solution than reimplementing terminal emulation, I think.

Fair enough. Though, I've tried vim/neovim inside a tmux session, and the terminal in neovim. And I find the latter(my personal opinion) to be more fluent to use.

There's only one .nvimrc to manage as opposed to also, tmux's file. Also, when I was using it, tmux it didn't support 24bit colors.

Again, that's a trade off, for the maintainer of the editor, it makes sense to make it as simple as possible. But this means that the user of the app will have to manage a part of the complexity, of setting up and maintaining a tmux instance.

About terminal integration, I think neovim does it by embedding libvterm, which takes care of handling the terminal part. This might be an oversimplification though.

Re: Vis: A Vim-Like Text Editor

#100
post #60

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…

9term/Unix is still not as lean as something you'd get with a more integrated environment like Oberon or Lisp. Just think of the many ways of parsing arguments and input. Ad-hoc languages wherever you look.

Exactly. When you want to exchange data, it's much preferable to have typed/tagged representations. If not that, then one should strive to at least avoid regex "parsing" everything. The exception is that plumbing is okay because it integrates output from all kinds of programs that already exist, but if you have control, it's a lot better to have short prefixes like, say, bug:BUG123, git:COMMITID, pkg:DISTROPACKAGE, etc. But these short prefixes miss namespacing. Anyway, this is only true for acme and friends and in Oberon elements are rich and not plain text.
Post reply on HN