Live data from Hacker News

Vis: A Vim-Like Text Editor

github.com

131–140 of 166 posts

Re: Vis: A Vim-Like Text Editor

#131
post #126

Earlier quoted context omitted.

Some things are just more convenient/efficient to do in C. As an example the mark handling[1] used to represent cursors/selection relies on pointer arithmetic. Other things like the syntax highlighting are implemented in Lua which is high level but still has low resource usage. And yes part of the choice is also philosophical. I consider an editor a core system tool which should have minimal dependencies. [1] https:/…

A mark could just be an offset inside the Text buffer instead of a direct pointer. Yes, dereferencing a mark would be slower, but do you really think that matters? I mean even if you did that 1M times/sec there wouldn't be a noticeable difference to the user. On the other hand, look at array.c. Or buffer.c. Or map.c. Or all the manual linked list management stuff. Or all the other logic that would be so much simpler…

The nice thing about the pointer as mark thingy is that while the offset from the start of the file might change when something is inserted before it, the pointer will remain the same.

Anyway this was just an example. I agree that higher level languages (including functional ones) have their own merit. If I would start again today I might consider Rust. But again the LLVM dependency seems kind of scary.

Again for me an ideal base system is built upon a kernel, libc (musl), C compiler (cparser/libfirm), coreutils (sbase/ubase, toybox, busybox), editor (vis) etc. Writing a C compiler is non-trivial, but doable. Creating a C++ compiler on the other hand ...

A self contained (including terminfo entries etc), statically linked vis binary weights in at around ~800K. This allows usage in resource constrained sytems, I don't think the same would be possible using e.g. Haskell.

Re: Vis: A Vim-Like Text Editor

#132
post #99
post #57

Earlier quoted context omitted.

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…

> There's only one .nvimrc to manage as opposed to also, tmux's file.

Yes, this is definitely a trade-off.

I tend to have a global .vimrc and .tmux.conf with some sensible default settings and on top of that, I do ad-hoc per project config files that have keybindings and other definitions unique to the project configuration. E.g. run a certain test suite with a keypress.

The neat part in this is composability. The editor is just a component that you embed in your tmux. You might have other "components", such as a debugger or REPL or a file browser (ranger/midnight commander) in there too. This doesn't work as nicely if the "top level" is a text editor.

I'm really fond of building these per-project ad-hoc "IDEs" out of terminal and editor windows because I work with a really diverse set of languages and tools and no single IDE or editor plugin suite would cover all my use cases without hurting the others.

Re: Vis: A Vim-Like Text Editor

#133
post #71

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

(a meta-comment: please don't call people 'lazy' on hackernews. We're all here specifically because we enjoy thinking about the tools we use. It's like telling an artist not to paint a picture because they won't ever be able to capture the scene they want in the right way, or telling a student to they shouldn't bother trying their homework because they won't get every question right.)

I'm not telling not to paint, I'm telling him that in all likelihood he won't paint because his motivations aren't good enough.

I'm not trying to discourage him, I'm trying to encourage him to be a more productive person by taking a critical look at the flaws in how he motivates himself.

Re: Vis: A Vim-Like Text Editor

#134
post #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.

Dang, there is nothing negative about being critical. The user I responded to clearly has childish ways of motivating himself. Being critical helps him analyze the flaws in how he motivates himself.

Hacker news is degrading quickly and you blocking me is helping that. This site needs inter-user critical comments. I doubt you have the insight to see that yourself and you're probably just following implied orders from Sam and Paul. This site is facing a leadership vacuum in this crisis and will likely implode. Good job.

Re: Vis: A Vim-Like Text Editor

#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

Re: Vis: A Vim-Like Text Editor

#137
post #125

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

Is your editor publicly available?

Sure: https://github.com/pklausler/aoeui

Re: Vis: A Vim-Like Text Editor

#138
post #15

Sounds similar to Kakoune ( http://kakoune.org/ ) but with Sam expressions

Yes from a design philosophy standpoint vis is closer to kakoune than {neo,}vim. The implementation is quite different though (no C++, no boost, no home grown scripting/extension/syntax highlighting language).

I don't use either, but to be fair, I wouldn't call vis's requirements lighter than kakoune. Vis needs Lua and libtermkey (which according to its author is EOL'ed) at build and run time.

Re: Vis: A Vim-Like Text Editor

#139

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've never tried sam, but I used to do all my unix coding in nano, because it was simple enough that I never had to think about how to use it. I prefer simpler tools, generally, since I don't want to think about the tool; I want to think about the work I'm doing with the tool. People do amazing things with emacs, and to a lesser degree also with vi, but I simply don't want to spend the time it would take to learn such a complicated interface when I clearly don't need such a powerful tool to get my job done.

I eventually wrote my own editor, which is effectively just a text-mode window manager wrapped around a simplified nano clone which uses the control key bindings I'm familiar with from non-terminal environments. I'd be reluctant to recommend it to anyone else, since it's such a specific implementation of my own personal taste, and it has a handful of minor problems I've never bothered to fix that might cause someone else significant irritation; but it suits me. It's a very comfortable feeling to know all that can be known about the tool; I never have to waste a moment trying to remember how any of it works, and can direct my full attention through the tool to the work I'm actually trying to do.

Re: Vis: A Vim-Like Text Editor

#140
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.…

For a non-vim user - can you describe what vimdiff is please?
Post reply on HN