Vis: A Vim-Like Text Editor
github.com
github.com
And looking at the list, there are some pretty nice features excluded. For example network support, or editing compressed or tar files. I guess the expectation is that these can still be accomplished by leveraging commands outside the editor. This is a clean approach.
Okay, but no diff mode? vimdiff is fantastic! And I'm not sure how you recover that functionality without multiple workspaces. Maybe the answer is you don't. Use vis for normal editing and pull out vimdiff only when you need it.
Very often I find myself editing outside of vim and wishing vim style editing were there. Recreating optional vim key bindings for every app that has text is clearly not realistic. Getting as many things inside of vim as possible is just tantalizing enough that a lot of people (myself included) try it. It's better than nothing, but results in some very hacked together tools.
Embedding vim (or in this case, vis) inside of other things would be a much better solution.
See also :help design-not: 'Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"'
More accurately, I meant that when someone wants to combine vim with a functionality they tend to implement it as a plugin with vim as the host and interface. I won't speak for anyone else, but my vimrc tends to accumulate a lot of behavior such that it's still a kitchen sink--it just wasn't included with the initial distro.
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.
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 software where I think the "dumb"er a piece of software the better and more reliable/performant it is likely to be. So I'm also hugely skeptical of the current Deep AI efforts leading to anywhere good.
Nothing beats the simplicity of Sublime and the good'ol Terminal.
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."
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.
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.
Not sure what they stand for for sure. E is probably editor. B might be buffer?
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.
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 process extension language
- client/server design (not yet implemented)
without having to care about backward compatibility and legacy systems. Of course this has also some drawbacks for example there is no existing plugin ecosystem etc
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 the back of my mind, though way down the priority list. Fantastic to see it implemented, it truly is the right choice (Neovim uses Corsix's C99 LPeg parser for its testing framework, automatically exposing headers in a way LuaJIT's FFI groks).
Does it build with LuaJIT? (Sorry for the perhaps stupid question, I've just glanced at your comments here and the terminal "video".
Keep up the good work.
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.
I haven't used multiple cursors, but I imagine they'd let you do that, but with the other lines getting updated in real time, and without requiring the insert points to be neatly aligned.
Maybe other stuff too.
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 for an editor that could be embedded with an LGPL project, and the choices were pretty limited. This looks quite interesting.
From a portability standpoint, is there any chance of creating a native Windows version using something like http://www.projectpluto.com/win32a.htm ? That was another kicker when I was searching previously - only the really big editors like vim/emacs appear to have Windows ports...
> I've done a couple searches for an editor that could be embedded with an LGPL project, and the choices were pretty limited.
Sure it doesn't have the features of Vim or Emacs (and some would say that's a feature!), but it's perfectly serviceable if you're okay with vi's modality.
I always strip anything after the hash, checking the link still works. Medium adds this info, in my opinion, for tracking.
Chrome: https://chrome.google.com/webstore/detail/pure-url/mphlceppe...
Firefox: https://addons.mozilla.org/en-US/firefox/addon/pure-url/
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/mercurial/ci/default/tr...
Thanks, Joe author!
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.
- modal over chords
- text objects
- the vim "language" which ties it together
- all the other good stuff, did I mention text objects ?
Regarding vis, Lua is optional (you lose syntax highlighting though). libtermkey is a 3 file library and despite what the author claims it works, is useful and could be maintained in the vis repository if necessary.
If you think anything C++ related is lighter than something C based, then we just have to agree to disagree.
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 functionality (there's a short of hack I've seen so far, but feels too rough for me). But honestly, with projectile + heap, I barely miss that.
Company-mode far outpaces the auto completion options in vim (though to be fair to the plugin authors, apparently they need to resort to major hacks to perform some of the things they do). Just as an example, when you autocomplete a function call, it populates the arguments and let's you tab through completing them. This same functionality sits as open tickets in the major vim autocomplete plugins, with a response of essentially "this is really hard to do in vim, hopefully we can figure something out in neovim".
It's worth the 2-3 days to make the switch and set yourself up. Also, a recommendation -- autostart emacs in server mode and use enacsclient to connect to that for all your editing needs.
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.
On a side note, one of those days I'll just have to drop everything for 2 weeks and just learn Emacs.
IIUC it works okay-ish in at least two of them: https://github.com/Rip-Rip/clang_complete and YCM after https://github.com/Valloric/YouCompleteMe/issues/36.
(Happy Emacs user and contributor here; just want all editors to stand on their merits).
I'm fine with a text editor without plugins as long as the editor can neatly interface with external applications. I used to use some Vim plugins but I found them to be more trouble than they're worth. Now I have vanilla Vim with only some syntax highlighting additions.
Rather than embedding my workflows into the editor, I'd like to embed the editor in my workflows. I don't want to run terminal apps from inside the editor, but I do want to run external apps and get the results in the editor. E.g. Vim has :make and :grep that work with the quickfix list, but this can also be done by invoking make or grep in the shell and piping the output to vim (+ some command line options to read the quickfix from stdin).
For my use, the feature that Vis needs the most is the client-server model, so I can use tmux to manage windows and open editor windows in any terminal session. That, coupled with some helpers to run external apps should do more than 80% of what I'd use editor plugins for.
Two well-known editors to come from the ed tradition: vi and sam. Vi is an obvious evolution - make it 2d. Sam did this as well, but its main focus was developing the expression language. For example, so you can chain expressions together for text manipulation. Another comment mentions multiple cursors.
But sam also has plan9 culture. It strongly encourages the mouse with an interaction that I've found to difficult to adjust to.
Vis seems to unify the best bits of vi and sam, from a unix user's perspective.
If anyone reading this knows sam or vis fluently, it would be helpful to have a youtube video for each of sam and vis in the the style of the recent Russ Cox video on acme.
[I'm struggling to get this vis thing to build and run, tips? Debian stable. I downloaded libtermkey, configure, make make install. Not thrilled about this - would rather it create .a and .h files I could copy it into the vis dir. Now when I run ./vis it says, "error while loading shared libraries: libtermkey.so.1: cannot open shared object file: No such file or directory".]
More notes on what to do if a build system for a project doesn't link in libraries, and you can't simply install the relevant -dev package through apt-get: http://homepages.inf.ed.ac.uk/imurray2/compnotes/library_lin...
Naming nit: vis(1) has been around for 25 years: http://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/share/...
Definitely going to give it a try. Currently I'm using Neovim and I like a lot the embedded terminal feature. I wonder how easily this can be recreated using a Lua plugin.
It's probably a better idea to use tmux/screen/dtvm for terminals rather than embedding a terminal in a minimal editor.
The TODO list mentions asynchronous event loops, that's necessary to do any plugins with external processes neatly.
Also autocomplete from all the buffers is working. It's really convenient.
And implementing a repl integration is trivial.
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.
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.
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.
- x/pattern/ extracts stuff from the text, creates a selection for every match
- some normal vi motions are used to modify the selections, "o" to move the
cursor from one end of the selection to the other, "w" to move the cursor
to the start of the next word
- y/,/ similar to x/ but create a selection for everything which does not match,
hence splitting the existing selection into multiple ones
- \ trim selections i.e. remove leading and trailing white space
- v/Vis keep all selection not matching Vis
- g/F|C keep all selection matching F|C
- + rotate selection contents on the same line
- v/Com keep all selection not matching Com
- + rotate some more
- ESC clear selections, ESC remove all cursors
- x/pattern select different regions
- .,/^\} extend selection by searching in forward direction until the first match
of } at the start of a line
- { i/#if 0\n/ a/\n#endif/ } insert some text before every selection with i/text/
and append some text after every selection with a/text/
- change file, select similarily indented code block using a text object: vi<Tab>
- x/\w+ extracts all words from selection
- Tab align selections
- C-c remove first selection column (i.e. remove first selection on every line)
- Esc clear selections, switch to normal mode, move to next { with f{
- i<S-Tab> goto insert mode and align cursors
- search a variable, select it with C-n
- C-n select next match
- C-x skip this match, that is clear it and select next match
- C-n select next match
- c vi change operator, delete selection, switch to insert mode
- rename the variable, switch back to normal mode
- undo the changesNo offense to your texteditor, I'm a vim enthusiast and after installing vis just now I really liked it, but that I can copy paste from that screencast caught me really off guard, and it's the height of my day today.
Sure, in hindsight it seems obvious, but ... that's pretty cool!
... not sure what that says about me, maybe I don't wanna know.
thanks for pointing my eyes that way!
Only engineers see stuff like this and go "aw, cool!"
Incidentally the "video" is a small pile of JSON - filter for XHR in the devtools to find it, the URL uses an expiration system so a direct link would break. (Aaaand I just learned they implemented VT100 in JavaScript... the JSON is full of actual, real, escape sequences...)
(If you haven't seen it, you might also like: https://github.com/TheMozg/awk-raycaster / https://news.ycombinator.com/item?id=10896901)
:[range]v[global]/{pattern}/[cmd] Same as :g!.
Where:
:[range]g[lobal]!/{pattern}/[cmd] Execute the Ex command [cmd] (default ":p") on the lines within [range] where {pattern} does NOT match.
So :v/error/d will delete all lines that don't contain the string "error".
sed -i "/#include <vcl\/button\.hxx>/d" $(git grep -l "vcl\/button\.hxx" *.hxx | grep -v precompiled)
Navigating large files with motions like 50%, 70% should however be instantaneous. Navigating by line number is again somewhat slower, because the file actually needs to be read in this case.
Aside from that :v/ has a different meaning in vis.
> On Linux based systems make standalone will attempt to download, compile and install all of the above dependencies into a subfolder inorder to build a self contained statically linked binary.
You'll still need the entire compiler toolchain, and 'libtool' on Ubuntu. I got as far as the ncursesw dependency before I gave up.
The whole project is still somewhat in flux, feel free to contribute by filling a packaging request to your favorite distribution ...
Historically it originates from a community which is comfortable building from source.