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.…
Vis: A Vim-Like Text Editor
61–70 of 166 posts
Re: Vis: A Vim-Like Text Editor
#62Re: Vis: A Vim-Like Text Editor
#63One of these days, I'm going to sit down and try out this, emacs-evil, and neovim. Side-by-side. Need to figure out which one I like most.
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…
Re: Vis: A Vim-Like Text Editor
#64More 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…
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.
Re: Vis: A Vim-Like Text Editor
#65Earlier quoted context omitted.
Reposting an answer from a related thread. The main difference is that vis is written from scratch while neovim inherited an old and hard to maintain code base. This allows vis to experiment with various ideas: - native multiple cursors/selection support - structural regular expression support - different core data structure resulting in efficient large file support - LPeg based syntax highlighting - Lua as an in pro…
Great! I remember last time I looked at Vis it wasn't so far along (it had no Lua integration AFAIK). When I started submitting code to Neovim my biggest desires for it were (1) Lua extensibility (2) A clean codebase (3) Compatibility with (most) Vim plugins. Perhaps ZyX-l's Vim to Lua project (for Neovim) could help with (3) at some point, if that's desired. An LPeg based syntax highlighting was also something in th…
I'm not sure. I think a few Lua >= 5.2 dependencies have crept in, but it shouldn't be difficult to fix this if desired.
LuaJIT's FFI is indeed very nice, but it is unfortunate that Lua has essentially been forked after the 5.1 release. The current C->Lua interface has been manually written.
Re: Vis: A Vim-Like Text Editor
#66Earlier quoted context omitted.
Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?
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…
crickets
"... with JAVASCRIPT!"
thunderous applause and/or retweets
Re: Vis: A Vim-Like Text Editor
#67More 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…
In the case of deep learning, all current state-of-the-art models can be expressed as nothing more than matrix multiplication, addition, and clipping. That's all you need. It's so simple: multiply, add, clip. Multiply, add, clip.
But the model isn't transparent. It's clear what each step is doing (multiply! add! clip!), but it's not clear to the human why that's necessary.
Re: Vis: A Vim-Like Text Editor
#68More 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…
Re: Vis: A Vim-Like Text Editor
#69Earlier quoted context omitted.
Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?
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…
C is definitely the wrong choice for a complex data-structure processing piece of software like a text editor.
Even though vanilla JS is madness, it gives you a very nice base to build on - namely closures and a GC, which make languages like Clojure or Purescript possible.
Still, for an editor I'd prefer pure Javascript over C every time.
Re: Vis: A Vim-Like Text Editor
#70One of these days, I'm going to sit down and try out this, emacs-evil, and neovim. Side-by-side. Need to figure out which one I like most.
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…
Like you, I loved my vim tabs. But "state" is what changed my mind.
In a few keystrokes, sure I could switch tabs. Right, right, right, right, there that's the tab I want. But it's coupled to my project state: if I close a tab, there goes the muscle memory for that session. Now it's "right-right" to get to the thing I need instead of "right-right-right".
Buffers are invariant to your session state. In a few keystrokes, I could just search for the buffer by the first few letters of its filename.
I routinely keep >500 buffers open in emacs. Ten projects, half a year of journal entries, a few dozen mail messages. Having all those things available in the same number of keystrokes no matter where I am is immensely helpful.
It's like Huffman coding for your workspace.