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

151–160 of 166 posts

Re: Vis: A Vim-Like Text Editor

#151

Post by woah »

ktamura wrote: post #91
xiaopingguo wrote: post #39

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

What?? I've gone the opposite direction on mousing.

Re: Vis: A Vim-Like Text Editor

#152

Post by woah »

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…

Microsoft VS Code is MIT licensed.

Re: Vis: A Vim-Like Text Editor

#153

Post by cced »

Undertow_ wrote: post #64
cced wrote: post #47

Earlier quoted context omitted.

As much as I love visualizing my code with Intellij, the thing is huge and clunky. Nothing beats the simplicity of Sublime and the good'ol Terminal.

Quite a few IDE's have the inherent flaw of being super bloated.

One of many reasons I prefer to build using Sublime as opposed to a big IDE.

Re: Vis: A Vim-Like Text Editor

#154

Post by ufo »

cm3 wrote: post #138
martanne wrote: post #24

Earlier quoted context omitted.

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.

Dunno about libtermkey but I wouldn't worry too much about the Lua dependency. Lua is very portable and lightweight and the entire Lua interpreter and standard library are just a couple hundred kbs. You always have the option of linking them statically if you really need to.

Re: Vis: A Vim-Like Text Editor

#155

Post by jstimpfle »

mhd wrote: post #60
xiaopingguo wrote: post #39

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.

Yeah, every programmer at one point has to make her own argument parsing library. Nope, there is no one syntax that fits all use cases.

While there are thousands of ways programs can parse arguments (and that's great!) there is only one argument passing mechanism in Unix (plus environment variables for implicit static things and file descriptors for streams).

Unix doesn't care how you parse your arguments, and that's why it is lean, and why it has been successful as a development platform.

Donald Knuth: "I define UNIX as 30 definitions of regular expressions living under one roof."

Re: Vis: A Vim-Like Text Editor

#156

Post by pka »

martanne wrote: post #131
pka wrote: post #126

Earlier quoted context omitted.

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…

Fair enough - if portability to systems without much more than a C compiler is a project goal, than C is obviously a good (the only?) choice :)

Re: Vis: A Vim-Like Text Editor

#157

Post by Scarbutt »

pka wrote: post #73
kromem wrote: post #56

Earlier quoted context omitted.

I just switched from vim to neovim to evil. I can't see myself ever going back. (Neovim was basically just vim with async support, and terminals, but as a tmux user, that didn't really grab my attention). There's a lot more polish in the integrations for emacs than vim, likely as a result of literally everything in the editor being a function call that can be hooked into. The only thing I miss is solid tab functional…

I tried out evil some time ago, and while it was very nice, it glitched out regularly - I would (mis)type a key combination and suddenly I'm dropped to Emacs and feel completely lost. Has this happened to you? On a side note, one of those days I'll just have to drop everything for 2 weeks and just learn Emacs.

sounds like PEBCAK to me.

Re: Vis: A Vim-Like Text Editor

#158

Post by mbrock »

to3m wrote: post #145
mbrock wrote: 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 this specific ecosystem please stop being a massive pile of crap? Then maybe we can have something nice to say about it :) Perhaps the new ECMAScript standard will help. I have my doubts (but as with any statement about the future it is hard to say with any certainty what will happen). The Node rot runs deeper than the usual Javascript nonsense. If it feels like Javascript is being unjustly maligned: (a), it isn'…

I don't think people despise C, they just think it's misused and difficult to master.

With JavaScript, many people are just vitriolic about it. I try to offer counterpoints because I'm a small part of this ecosystem, and I'm thankful for the work people put into open source tools, libraries, etc.

I also happen to think JavaScript is a pretty neat language... like, one of my favorites, despite its shortcomings.

By the way, I don't know of any languages without serious shortcomings... funny, that...

Re: Vis: A Vim-Like Text Editor

#159

Post by 6d65 »

exDM69 wrote: post #132
6d65 wrote: post #99

Earlier quoted context omitted.

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

> There exist plans to use a client/server architecture, delegating window management to your windowing system or favorite terminal multiplexer.

This is from Vis's Github page. It looks like Vis's author thinks the same way as you. And I get it, it's the Unix philosophy. Though the embedded terminal is the single biggest feature I chose Neovim, over Vim. And that's just my opinion.

Will give it a try though, to Vis, and some terminal multiplexer. See if I can make it work.

Re: Vis: A Vim-Like Text Editor

#160

Post by martanne »

jhallenworld wrote: post #110

I'd like to suggest trying integrating the syntax highlighter from JOE for speed, but JOE is GPL... Also, I'm not sure how large the Lua/LPeg state is, but for JOE we found the highlighter is more accurate if you retain the state of each line (or every n lines), and start parsing from a real known state. It looks like Vis starts parsing 16K before the start of the window. https://sourceforge.net/p/joe-editor/mercuria…

Thanks for the hacking file, it is a good read for people like myself who are interested in text editor implementations. If time permits I will try delve a bit into the joe code base.

As for the syntax highlighting in vis, yes it currently is stateless and only considers a fixed range of text prior to the start of the window. Having no state at all simplifies some things and allows vis to highlight even extremely large files at the expense of the occasional glitch. In practice it seems to work reasonably well.

This approach also requires that the highlighting is fast, because nothing is cached, it is completely redone after every cursor motion. I'm quite happy with LPeg so far, it is convenient to express grammars in a high level language like Lua. It also supports nested grammars nicely, but due to the completely stateless approach taken by vis this is currently not fully exploited. As an added bonus there were already ~100 lexers (of admittedly varying quality) available for use.

Post reply on HN