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

121–130 of 166 posts

Re: Vis: A Vim-Like Text Editor

#121

Post by robenkleene »

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…

A great trivia bit about Sam is that it's the first full screen editor Ken Thompson switched too, and he still uses it today[1]. Ken Thomspon wrote ed (in addition to being the primary original author of Unix).

[1]: http://m.slashdot.org/story/50858

Re: Vis: A Vim-Like Text Editor

#122

Post by martanne »

pka wrote: post #111
adrusi wrote: post #79

Earlier quoted context omitted.

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…

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://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...

Re: Vis: A Vim-Like Text Editor

#123

Post by geoelectric »

aoloe wrote: post #61
loudmax wrote: 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.…

concerning vimdiff: one of the goal is to get vis to also work in server mode and be embeddable. it should then be possible to create a diff tool that uses vis for the editing.

So instead of the vim philosophy of embedding every functionality within vim, this potentially embeds vis in every functionality? I actually like that--much more composable.

Re: Vis: A Vim-Like Text Editor

#124

Post by isxek »

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 writing the JOE editor. I've been using it for simple text editing tasks (commit messages, etc.) now that I've moved over to a Linux system. I appreciate its simplicity.

Re: Vis: A Vim-Like Text Editor

#125

Post by vbit »

pklausler wrote: post #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).

Is your editor publicly available?

Re: Vis: A Vim-Like Text Editor

#126

Post by pka »

martanne wrote: post #122
pka wrote: post #111

Earlier quoted context omitted.

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…

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 with a more functional language. I mean, sure - there's an unique feeling to being so close to the metal, and that's fine, but if you want to build something new reinventing the wheel for the millionth time is a waste of time.

edit: there are compiled higher-level languages too (i.e. Haskell). If you want minimal dependencies, it doesn't really matter how the binary got built.

Re: Vis: A Vim-Like Text Editor

#127

Post by mbrock »

vbit wrote: post #107
mbrock wrote: post #55

Earlier quoted context omitted.

Does this kind of PEG parser deal somewhat decently with partial or incorrect syntax trees?

The parser will match the specified grammar exactly, like it should. You could of course specify a grammar that is broader than the actual language you are parsing.

Well, I am vaguely aware of the existence of "incremental parsers" and "tolerant parsers", and a code editor necessarily works on code that's only partially correct...

Re: Vis: A Vim-Like Text Editor

#128

Post by lewiscollard »

isxek wrote: post #124
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 writing the JOE editor. I've been using it for simple text editing tasks (commit messages, etc.) now that I've moved over to a Linux system. I appreciate its simplicity.

I shall add to your thanks. Joe's the first thing I install on any new box or server and has been my default "quickly edit this thing" editor for a decade and a half now.

Thanks, Joe author!

Re: Vis: A Vim-Like Text Editor

#130

Post by sea6ear »

rbonvall wrote: post #102
loudmax wrote: 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.…

The great thing about vim is that it'll always be there as a fallback. I keep a file with my passwords, encrypted with Vim's builtin encryption. Neovim removed that feature. If I ever switch to neovim, I can still use vim when I need to open that file.

TIL that Vim supports encryption out of the box. Thanks :)
Post reply on HN