Neovim v0.2.1 released(github.com)
github.com
Neovim v0.2.1 released
https://github.com/neovim/neovim/commit/c67dd5acd0bb9f8d08789dfe6af27d9045e95fb4
165 comments
I was going to rant about this idea but it looks really good and not at all like gvim.
No no no no no. This is based on Electron and is a non-starter.
How would you feel about Electron projects if Electron was instead:
1. a single shared runtime install, installed transparently by the first thing to need it (similar to how the Adobe Air first-use experience worked), rather than a vendored dependency?
2. a shared VM that ran its apps in separate V8 execution contexts (like how browsers isolate tabs), but with a lot of shared resources so that each Electron app didn't end up with a GB of (mostly redundant) memory consumption?
I find that most people don't object to HTML5 apps per se; they just object to the way Electron handles things. The above was going to be the strategy of Chrome's "app-only runtime" mode, until they just killed off Chrome Apps altogether. I still think it's a decent strategy, all-said.
1. a single shared runtime install, installed transparently by the first thing to need it (similar to how the Adobe Air first-use experience worked), rather than a vendored dependency?
2. a shared VM that ran its apps in separate V8 execution contexts (like how browsers isolate tabs), but with a lot of shared resources so that each Electron app didn't end up with a GB of (mostly redundant) memory consumption?
I find that most people don't object to HTML5 apps per se; they just object to the way Electron handles things. The above was going to be the strategy of Chrome's "app-only runtime" mode, until they just killed off Chrome Apps altogether. I still think it's a decent strategy, all-said.
I would feel marginally better but still hate it. I don't like the web as a platform anyway, especially not one for applications with cancerous amounts of JavaScript. HTML is not a platform for desktop applications. It shouldn't be a platform for almost anything.
I've always thought that HTML made a pretty amazing platform for applications when you have the specific goal that the application should be an enhancement (of editing controls + toolbars + whatever) on top of a clean, semantic, static HTML document. Because then you get all the advantages of having a "document" even though you have an application. (These arguments don't apply to "native-ized" apps like Electron apps; only to actual apps-at-URLs-in-a-browser.)
You can, for example, print your application's interface (i.e. your document), without having to implement your own print-layout logic, because that logic can just be the browser doing CSS @media(print) to the DOM. (Which can, with a few @media(print)-scoped rules, hide all the toolbars to just leave the document.)
Or, users can use User-Agent stylesheets (think "forcing high-contrast" or "disabling serif fonts") and browser extensions to customize your application [or, more importantly, anyone's old closed-source abandonware application that's never gonna make an accessibility update ever again], because your application's interface is guaranteed to exist in the intermediary state of a DOM tree, where those things can get to it to munge it†.
† (This is also true in various ways for each OS UI framework—and you can create native "extensions" like screen-readers that use the OS accessibility APIs of each OS—but you have to redo this work. WebExtensions are cross-platform.)
Also, with web-apps, users get final control over how the application is sized and shaped on the desktop, and so apps are forced to be at least semi-responsive—which is easy, because the default layout algorithm for any container, if you don't override it, is a reflowable-text algorithm. Web-apps are the only apps where I'm (nearly) guaranteed to have the ability to adjust the em-widths of blocks of text so that they're actually comfortable to read.
And, as an added benefit, as long as you ensure that you really are serving a static HTML document at each URL that is progressively-enhanced into being your app—then your web-app can double as a programmatically-accessible infobase. Google can't index a native app. You can't scrape a native app. You can't embed microformats into a native app. Etc.
You can, for example, print your application's interface (i.e. your document), without having to implement your own print-layout logic, because that logic can just be the browser doing CSS @media(print) to the DOM. (Which can, with a few @media(print)-scoped rules, hide all the toolbars to just leave the document.)
Or, users can use User-Agent stylesheets (think "forcing high-contrast" or "disabling serif fonts") and browser extensions to customize your application [or, more importantly, anyone's old closed-source abandonware application that's never gonna make an accessibility update ever again], because your application's interface is guaranteed to exist in the intermediary state of a DOM tree, where those things can get to it to munge it†.
† (This is also true in various ways for each OS UI framework—and you can create native "extensions" like screen-readers that use the OS accessibility APIs of each OS—but you have to redo this work. WebExtensions are cross-platform.)
Also, with web-apps, users get final control over how the application is sized and shaped on the desktop, and so apps are forced to be at least semi-responsive—which is easy, because the default layout algorithm for any container, if you don't override it, is a reflowable-text algorithm. Web-apps are the only apps where I'm (nearly) guaranteed to have the ability to adjust the em-widths of blocks of text so that they're actually comfortable to read.
And, as an added benefit, as long as you ensure that you really are serving a static HTML document at each URL that is progressively-enhanced into being your app—then your web-app can double as a programmatically-accessible infobase. Google can't index a native app. You can't scrape a native app. You can't embed microformats into a native app. Etc.
Actually, I wouldn't mind it that much if it was as you described.
I believe that a web-based UI would still be slower than a native application, if only because of the huge number of abstractions in-between, but I'd say it's something that can be overcome by (a) newer hardware, (b) better development i.e. careful profiling and optimization, (c) advancements made by the browser engine developers, and (most likely) a combination of all three.
There's also the issue with the Web as a platform, but honestly, it's not as bad as purists on HN make it. No technology is perfect. I used to be a very loud opponent of using Web technologies for applications, but I realize that ship's pretty much sailed, and we could have had a much worse outcome than this.
My main gripe with Electron has always been the inability to share resources between instances. If firing up Slack or VSCode would have the same net impact on my memory use as opening a new Chrome tab, I'd gladly run them and quit complaining.
I believe that a web-based UI would still be slower than a native application, if only because of the huge number of abstractions in-between, but I'd say it's something that can be overcome by (a) newer hardware, (b) better development i.e. careful profiling and optimization, (c) advancements made by the browser engine developers, and (most likely) a combination of all three.
There's also the issue with the Web as a platform, but honestly, it's not as bad as purists on HN make it. No technology is perfect. I used to be a very loud opponent of using Web technologies for applications, but I realize that ship's pretty much sailed, and we could have had a much worse outcome than this.
My main gripe with Electron has always been the inability to share resources between instances. If firing up Slack or VSCode would have the same net impact on my memory use as opening a new Chrome tab, I'd gladly run them and quit complaining.
I would still hate it. When it comes to UX I care a lot about the little stuff, and with all web-wrapper apps I've ever used it's death by a thousand cuts. Lots of little things that work in native apps don't work in Electron apps.
Let's take Slack as an example. All the keyboard shortcuts use weird modifier keys like option instead of command, and I can't discover any of them by looking through the menu bar like I can in a native app.
Or for another example, the Services feature of macOS doesn't work correctly with Electron apps. In any native app I can select some text and then trigger a Service on that text (for example, I've defined a service to be able to select a bug id and hit a keyboard shortcut to view that bug in our bug tracker). No such luck in Slack.
Let's take Slack as an example. All the keyboard shortcuts use weird modifier keys like option instead of command, and I can't discover any of them by looking through the menu bar like I can in a native app.
Or for another example, the Services feature of macOS doesn't work correctly with Electron apps. In any native app I can select some text and then trigger a Service on that text (for example, I've defined a service to be able to select a bug id and hit a keyboard shortcut to view that bug in our bug tracker). No such luck in Slack.
I'd like electron if it was just a natively, AOT compiled rendering library.
I stick to this philosophy for many things, tracked for many months the more efficient GUIs for neovim (mainly neovim-qt, see full list at [0]).
However I really wanted to have a little more interactivity (and visuals) than what the terminal can provide and so far Oni has delivered it good enough for me.
That said, there are a lot of daily editing issues to be solved before it can be said battle-tested.
[0]: https://github.com/neovim/neovim/wiki/Related-projects#gui
However I really wanted to have a little more interactivity (and visuals) than what the terminal can provide and so far Oni has delivered it good enough for me.
That said, there are a lot of daily editing issues to be solved before it can be said battle-tested.
[0]: https://github.com/neovim/neovim/wiki/Related-projects#gui
Was pretty curious about this until I saw that awful "e" word thanks for the heads up.
But this looks just like a customized Vim in a terminal with what some may consider bloat.
> Oni brings several IDE-like integrations to neovim:
> Oni brings several IDE-like integrations to neovim:
Quick Info
Code Completion
Syntax / Compilation Errors
Fuzzy Finding
Status BarIt's not a terminal though, so you can get GUI features that terminal nvim can't do.
Personally I use terminal vim not any sort of nvim (maybe I should change over but then I potentially have to maintain two sets of plugins, one for nvim and one for vim. ).
No if you want to call this out, I'd call it out for the lack of features. This only supports code completion in JS and TypeScript. I have code completion plus snippets for a lot more then that with vim.
Honestly if you want to wow me, someone should build a GUI configuration tool for neovim/vim. One big benefit of GUIs is that you can generally see all the possible settings with tool tips and explanations, and I can see that being useful for vimmers, especially if it did the right thing, like using ft-plugins to do filetype specific settings, instead of a bunch of one line autogroups based on file extension.
Yes there are vim config generators, but the neovim api means you could programmatically query the current configuration and display it along with the options, meaning you could have interactive configuration modification.
Personally I use terminal vim not any sort of nvim (maybe I should change over but then I potentially have to maintain two sets of plugins, one for nvim and one for vim. ).
No if you want to call this out, I'd call it out for the lack of features. This only supports code completion in JS and TypeScript. I have code completion plus snippets for a lot more then that with vim.
Honestly if you want to wow me, someone should build a GUI configuration tool for neovim/vim. One big benefit of GUIs is that you can generally see all the possible settings with tool tips and explanations, and I can see that being useful for vimmers, especially if it did the right thing, like using ft-plugins to do filetype specific settings, instead of a bunch of one line autogroups based on file extension.
Yes there are vim config generators, but the neovim api means you could programmatically query the current configuration and display it along with the options, meaning you could have interactive configuration modification.
> maybe I should change over but then I potentially have to maintain two sets of plugins, one for nvim and one for vim
I use this in my ~/.config/nvim/init.vim:
Then I set up an alias in my zsh profile:
alias vim=nvim
All of my plugins thus far have worked without a hitch (and I have a lot of configuration/plugins). If I ever run into problems, I can bail out by removing the alias (or for a one-off editing session, I can just run: $ command vim).
You might give something like that a go.
I use this in my ~/.config/nvim/init.vim:
set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath = &runtimepath
source ~/.vimrc
Then I set up an alias in my zsh profile:
alias vim=nvim
All of my plugins thus far have worked without a hitch (and I have a lot of configuration/plugins). If I ever run into problems, I can bail out by removing the alias (or for a one-off editing session, I can just run: $ command vim).
You might give something like that a go.
two plugins failed until I installed https://github.com/neovim/python-client
Which seems to have fixed things.
Which seems to have fixed things.
You'd be surprised, when I switched to nvim my plugins just worked.
> This only supports code completion in JS and TypeScript. I have code completion plus snippets for a lot more then that with vim.
No, this only supports the extended features fro completion for those languages. It should use the simpler completion system for other languages, in which case you are using vim's support anyway.
No, this only supports the extended features fro completion for those languages. It should use the simpler completion system for other languages, in which case you are using vim's support anyway.
I've been wanting to do exactly this for a long time, for exactly the reasons you state.
>But this looks just like a customized Vim in a terminal with what some may consider bloat
But we can chose to ignore those "some", just like they can keep using whatever works for them.
But we can chose to ignore those "some", just like they can keep using whatever works for them.
You can literally use Neovim as the Sublime Text editing engine.
Is there a plugin for this?
https://github.com/lunixbochs/actualvim
It's not just "literally use Neovim as the editing engine", I've tried to make editing the text in "Sublime Mode" work too, including running Sublime plugins. Work in progress, but afaik the most complete Vim integration for an existing editor. Waiting on updates to both Neovim and Sublime Text to polish it a bit more.
VSCodeVim is using it as a reference for some of their new work as well.
It's not just "literally use Neovim as the editing engine", I've tried to make editing the text in "Sublime Mode" work too, including running Sublime plugins. Work in progress, but afaik the most complete Vim integration for an existing editor. Waiting on updates to both Neovim and Sublime Text to polish it a bit more.
VSCodeVim is using it as a reference for some of their new work as well.
Thanks!
I really, really want VSCode's Vim mode to be based on Neovim (they already do some kind of Neovim integration.) I wish I had more time during my weekends to collaborate on such a thing.
It's coming! From the VSCode Vim v0.10.0 path notes:
> One more thing. I apologize for less work being done on the main repo. Much of my effort recently has gone into the neovim version of this extension (still in development).
> One more thing. I apologize for less work being done on the main repo. Much of my effort recently has gone into the neovim version of this extension (still in development).
The current work for this is being done here: https://github.com/chillee/vscodeneovim
Someone is working on that:
https://github.com/VSCodeVim/Vim/pull/1897
https://github.com/VSCodeVim/Vim/pull/1897
I wish someone would give this kind of love to emacs.
emacs's gui is sufficient but really doesn't take advantage of any of the features a GUI offers.
I can't wait to make my code editor eat 2GB of RAM, like modern editors do, without sacrificing on Vim features.
Nice to see things moving forward !
I've been a very happy neovim user for over a year now (on linux). My switch was pre-vim 8 so the ability to have things (like plugins) run asynchronously was a huge plus, but now vim has that too.
For me the biggest selling point is the plugin architecture, I've been a vim user for over a decade now, and I'm only writing my own vim plugins now, because neovim allows me to do that in the language of my choice (ie. not VimL).
I've been a very happy neovim user for over a year now (on linux). My switch was pre-vim 8 so the ability to have things (like plugins) run asynchronously was a huge plus, but now vim has that too.
For me the biggest selling point is the plugin architecture, I've been a vim user for over a decade now, and I'm only writing my own vim plugins now, because neovim allows me to do that in the language of my choice (ie. not VimL).
I use both vim and neovim and kick in a butt that neovim provides for vim has been awesome. It really helps make things better for all of us.
My biggest pet peves of both neovim and vim8 is that there are like 5 different (and complicated) ways to get plugins, none of which are compatible with the other.
Compare this to VSCode, Atom or IntelliJ.
Compare this to VSCode, Atom or IntelliJ.
There are always 5 different ways to do everything. For what it's worth, I've gone with the simple vim.plug. I don't worry about whether it's compatible with any other way of installing plugins. I just add a single line to my vimrc file per plugin and type :PlugInstall.
Is it easy to update the plugins as well?
Yeah:
EDIT: formatting
:PlugUpdate
EDIT: formatting
There are too many options, I agree. But vim-plug is ultra easy. In my opinion, it should be the recommended package manager.
or even Emacs.
> My switch was pre-vim 8 so the ability to have things (like plugins) run asynchronously was a huge plus, but now vim has that too.
My (perhaps uncharitable) understanding, as a dedicated vim user with no thought of switching, is that vim has that because of Neovim. (On rereading, I guess this is what desireco42 (https://news.ycombinator.com/item?id=15650991) means by the "kick in a butt that Neovim provides for vim".)
My (perhaps uncharitable) understanding, as a dedicated vim user with no thought of switching, is that vim has that because of Neovim. (On rereading, I guess this is what desireco42 (https://news.ycombinator.com/item?id=15650991) means by the "kick in a butt that Neovim provides for vim".)
You can write Vim plugins in other languages as well.
Technically true, but practically worthless.
Python example:
Python example:
import vim
# Show current directory in Vim
cwd = vim.eval('getcwd()')
cmd.command(':Explore %s | redraw' % cwd)
This is a little unkind. Vim has actual APIs for most things you'd want to do. Ex: https://github.com/camgunz/u300Blog/blob/master/u3b.vim#L307
It's not complete coverage, but it's not "the API is just a thin Python wrapper around Vim commands as strings" as your comments suggest.
It's not complete coverage, but it's not "the API is just a thin Python wrapper around Vim commands as strings" as your comments suggest.
[deleted]
It looks to me like more than half of that is a thin wrapper around strings.
I'm not trying to be mean or mislead. I've used vim for decades, and emacs too for that matter. My favorite editors by far.
I'm not trying to be mean or mislead. I've used vim for decades, and emacs too for that matter. My favorite editors by far.
Haha yeah I'm not trying to be shitty with you.
Vim gives you buffer, window, cursor and range, plus eval and command. The eval/command stuff is a "shim", insofar as you have to wrap them yourself if you want more programmatic access; like you'd have to do `def getcwd(): vim.eval('getcwd()')` But for a lot of what you want to do, you're messing with buffer/window/cursor. I wouldn't call it a full-featured scripting API, and certainly Neovim's is better, but your posts suggested all the scripting API was was just an entry point to ex commands. There's a lot more than that, to the extent that it covers most of what you want to do.
Vim gives you buffer, window, cursor and range, plus eval and command. The eval/command stuff is a "shim", insofar as you have to wrap them yourself if you want more programmatic access; like you'd have to do `def getcwd(): vim.eval('getcwd()')` But for a lot of what you want to do, you're messing with buffer/window/cursor. I wouldn't call it a full-featured scripting API, and certainly Neovim's is better, but your posts suggested all the scripting API was was just an entry point to ex commands. There's a lot more than that, to the extent that it covers most of what you want to do.
Would it hurt to provide a five line summary of changes? This is completely unreadable for someone who doesn't actively follow neovim development.
Newsletter will be published in a few days.
I think OP should have waited for that newsletter to post here. And people shouldn't upload changelogs like this. Of course, nobody has any control over these things :)
You do have some degree of control, you just have to do a better job of persuading me why this was a bad idea.
If it's not you it will be someone else. People upvote the title, not the content.
etiquette stems from effective persuasion.
Highlights include an api for a built in Lua(JIT) : https://github.com/neovim/neovim/pull/4411
So what's this API do? Allow you to ditch vimscript for lua or something else?
It's been possible to script vim in Lua (and various other languages including Python, Ruby, Perl, and even Scheme) for a long time.. long before neovim existed.
The problem is that the overwhelming majority of vim scripts are written in vimscript. So even if you switch to using some other language to script vim, virtually all the rest of the vim ecosystem will still be in vimscript.
The problem is that the overwhelming majority of vim scripts are written in vimscript. So even if you switch to using some other language to script vim, virtually all the rest of the vim ecosystem will still be in vimscript.
Not the same. At least pre vim 8. I don't know if this has changed.
https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-...
Example for python from the post
https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-...
Example for python from the post
import vim
# Show current directory in Vim
cwd = vim.eval('getcwd()')
vim.command(':Explore %s | redraw' % cwd)
Who is that a problem for?
Sure, but now, because neovim is guaranteed to have lua available (not necessarily the case in all vim builds), you can count on it, which in turn eases the problem of consuming the scripts.
Isn't LuaJIT stuck on Lua 5.1, and no longer in development?
It's 5.1 compatible plus some nice-to-haves from 5.2: http://luajit.org/extensions.html
I wouldn't call it 'not in development' and even if, then 5.1 is a fine version of Lua and LuaJIT is battle tested very well and rock solid still. Changes in Lua 5.2 and 5.3 are breaking (and some are deep, like the ints, bit ops, function environments) but most of 'usual' code is compatible between 5.1, 5.2 and 5.3.
I learned Lua 5.2 and then went back to 5.1 when 5.3 came out because I didn't like the int stuff in 5.3 and didn't want to use an obsolete version (5.2) with no upsides (5.1 has the upside of being compatible with LuaJIT).
I wouldn't call it 'not in development' and even if, then 5.1 is a fine version of Lua and LuaJIT is battle tested very well and rock solid still. Changes in Lua 5.2 and 5.3 are breaking (and some are deep, like the ints, bit ops, function environments) but most of 'usual' code is compatible between 5.1, 5.2 and 5.3.
I learned Lua 5.2 and then went back to 5.1 when 5.3 came out because I didn't like the int stuff in 5.3 and didn't want to use an obsolete version (5.2) with no upsides (5.1 has the upside of being compatible with LuaJIT).
To those who downvoted FRex's comment:
Do you care to elaborate? I don't see anything wrong with it.
(And it's definitely more insightful than the slightly older sibling comment, which apparently has not been downvoted.)
Do you care to elaborate? I don't see anything wrong with it.
(And it's definitely more insightful than the slightly older sibling comment, which apparently has not been downvoted.)
Maybe someone fat-fingered it?
No, it had more than one downvote when I upvoted it, i.e. stayed grey after upvote. Moreover, I just saw it being black, then grey, then black. So it still receives a mix of downvotes and upvotes. Very strange.
I tried to upvote and it's still grey. There's obviously something wrong in the information, but those who know better aren't taking the time to impart that to us.
If you or someone can't come and point out that 'obviously wrong something' then don't say that just because a comment got downvoted for some bizarre reason. That same comment now has 11 points. I hope it didn't now become 'obviously right' to you just because of the point count. The fact this (going into 'grey' or 'black' with 0 retort or correction given by anyone) even happened is just stupid to me.
I believe nothing I said is wrong and anyone is welcome to prove me wrong. I also answered the original questions/doubts clearly (Is LuaJIT stuck on 5.1 and no longer in development - no and no and there is nothing wrong with 5.1 itself). The only downside could be how brief I was but I gave plenty of keywords ('ints', 'bit ops', 'function environments') for an astute reader to google or look up in the documentation of Lua (which is a Ctrl + F friendly one pager plain HTML with minimal styling and no JS, I have it as a single .html file with inline PNG and css on my desktop to use offline).
This stealthy downvote drama is why I use HN passively, logging in only to do a fire and forget comment. I've just avoided seeing this entire downvote debacle unfold in real time during my normal browsing (and thus avoided wondering what's going on or if I were providing people wrong information or something else wrong on my part, since it's not like any downvoter told us why they did it) because of that habit.
I believe nothing I said is wrong and anyone is welcome to prove me wrong. I also answered the original questions/doubts clearly (Is LuaJIT stuck on 5.1 and no longer in development - no and no and there is nothing wrong with 5.1 itself). The only downside could be how brief I was but I gave plenty of keywords ('ints', 'bit ops', 'function environments') for an astute reader to google or look up in the documentation of Lua (which is a Ctrl + F friendly one pager plain HTML with minimal styling and no JS, I have it as a single .html file with inline PNG and css on my desktop to use offline).
This stealthy downvote drama is why I use HN passively, logging in only to do a fire and forget comment. I've just avoided seeing this entire downvote debacle unfold in real time during my normal browsing (and thus avoided wondering what's going on or if I were providing people wrong information or something else wrong on my part, since it's not like any downvoter told us why they did it) because of that habit.
If someone has mixed feelings from what FRex said here, but is not aware of what Lua world consists of, let me explain. Js will be mentioned, so reader can have a base level of understanding what happens and how good/bad it is. It is not js criticism.
First of all, original 5.1 was a complete language with few technical problems unsolved. These problems were hard and didn’t exist, say, in javascript, because it has no such primitives at all, not because 5.1 was bad. To name a few fundamental: yield across pcall, C-call, for-iteraror; specific metamethods for regular tables.
LuaJIT derived from 5.1 and then development went in parallel, never being stopped or unmaintained. Original Lua experimented with features in 5.2 and while it fixed and added few nice things, it used completely different env resolution (which also doesn’t exist in javascript). 5.2 was also improved in execution speed. LuaJIT specified that it will stick with original env scheme, and personally I find it more powerful than new one. All others features were backported from 5.2, so effectively LuaJIT is 5.2 with setfenv() still working, not some obsolete chunk that you may try to guess from semantic versioning, which doesn’t take place in Lua. Versions of Lua are NOT “semantic”.
5.3 introduced things that personally I find mad, and it diverged from 5.1/5.2, which were pretty compatible if written with care (not more incompatible than javascript is in different browsers; an order of magnitude less so). So, the future of 5.3 is somewhat unclear to me. It is still good language, thought, planned, experimenting, technical, non-crowd non-legacy driven. It will show what’s wrong and what’s right, as all Lua versions perfectly did.
To sum it up. If you’re going production, you can take any version of Lua, and it will be still more compatible and feature-rich than different versions of javascript. If you want all 5.1 design holes covered and incomparable execution speed, then you take LuaJIT in place of 5.1. If you want new environments (read what they are before you want), take 5.2. If you want to test new experiences and language design, take 5.3. But there is no superiority in any version, unless you’re taking one of these perks to extreme. These are different but similar languages with different strengths.
I know it’s all harder than just “5.1 < LJ < 5.2 < 5.3”, but what can you do?
First of all, original 5.1 was a complete language with few technical problems unsolved. These problems were hard and didn’t exist, say, in javascript, because it has no such primitives at all, not because 5.1 was bad. To name a few fundamental: yield across pcall, C-call, for-iteraror; specific metamethods for regular tables.
LuaJIT derived from 5.1 and then development went in parallel, never being stopped or unmaintained. Original Lua experimented with features in 5.2 and while it fixed and added few nice things, it used completely different env resolution (which also doesn’t exist in javascript). 5.2 was also improved in execution speed. LuaJIT specified that it will stick with original env scheme, and personally I find it more powerful than new one. All others features were backported from 5.2, so effectively LuaJIT is 5.2 with setfenv() still working, not some obsolete chunk that you may try to guess from semantic versioning, which doesn’t take place in Lua. Versions of Lua are NOT “semantic”.
5.3 introduced things that personally I find mad, and it diverged from 5.1/5.2, which were pretty compatible if written with care (not more incompatible than javascript is in different browsers; an order of magnitude less so). So, the future of 5.3 is somewhat unclear to me. It is still good language, thought, planned, experimenting, technical, non-crowd non-legacy driven. It will show what’s wrong and what’s right, as all Lua versions perfectly did.
To sum it up. If you’re going production, you can take any version of Lua, and it will be still more compatible and feature-rich than different versions of javascript. If you want all 5.1 design holes covered and incomparable execution speed, then you take LuaJIT in place of 5.1. If you want new environments (read what they are before you want), take 5.2. If you want to test new experiences and language design, take 5.3. But there is no superiority in any version, unless you’re taking one of these perks to extreme. These are different but similar languages with different strengths.
I know it’s all harder than just “5.1 < LJ < 5.2 < 5.3”, but what can you do?
Is this just Python 3 vs 2, with PyPy refusing to update to 3?
An important part of this is that Lua is generally embedded into larger programs. This is pretty much the #1 production-grade use case of the language. So when a new version of Lua is released, no one is actually expected to update their old versions. Rather, they use the new version in future projects. This allows the language designers to improve the language in ways that are backwards incompatible (imagine if JS could do this; the `let` keyword wouldn't even exist because you could just fix the default scoping).
So Lua 5.3 has a lot of breaking changes without a clear upgrade path. LuaJIT simply isn't going to support this, because its users generally use it more like a normal scripting language like Python and expect more stability.
So Lua 5.3 has a lot of breaking changes without a clear upgrade path. LuaJIT simply isn't going to support this, because its users generally use it more like a normal scripting language like Python and expect more stability.
It may be simply a game of words, but if taken literally, then the point is still missed. There is no “update”. These three could be named 5.s, 5.e and 5.i respectively. For setfenv, _ENV and integer experiments. No “justs”, please, this poisons Lua image in a wrong way.
Python 3 was meant to solve a problem (among other features ofc). 5.1, 5.2 and 5.3 are engineerng experiments, there is no “problem” that LJ has in respect to these two, nor the other way round.
Python 3 was meant to solve a problem (among other features ofc). 5.1, 5.2 and 5.3 are engineerng experiments, there is no “problem” that LJ has in respect to these two, nor the other way round.
Pypy supports Python 3...
I think the parent meant that as a hypothetical: The Lua situation would be like the Python 2/3 situation if PyPy decided not to support Python 3.
excellent opportunity for somebody to step up!
First of all, it was never unmaintained, and has two parts: interpreter and jit-compiler. The interpreter is rock-hard and was battle-tested in many production environments for years. There is nothing to do in it anymore[1]. Jit part is under active development. For one, among many others, they recently patched GC to remove the famous 2Gb memory restriction for LuaJIT. Jit was also always production-ready, but their sense of “ready” is too responsible, so their current version is beta3.
[1] yeah, the language doesn’t have to change and “evolve” constantly, if its roots were planned thoroughly.
[1] yeah, the language doesn’t have to change and “evolve” constantly, if its roots were planned thoroughly.
Why should I use this over vim?
I am a web developer so I am mostly editing html, JavaScript, ruby and css files.
I love my tmux + vim setup. Give me reasons to switch. I mean practical reasons to switch not technical implementation niceties.
I am a web developer so I am mostly editing html, JavaScript, ruby and css files.
I love my tmux + vim setup. Give me reasons to switch. I mean practical reasons to switch not technical implementation niceties.
Some of the more successful features that appeared first in NeoVim have also been adopted in Vim 8. One of the new features in this release is that NeoVim will use the tmux clipboard if running in Tmux, so you can use "+y to yank in one Vim instance and "+p to paste into another vim instance running elsewhere in tmux. https://github.com/neovim/neovim/pull/6894/files
welp, i'm convinced!
I remember hearing that vim8 added some of the concurrency for plugins that neovim introduced. At the time, it sounded like this was done in a non-compatible way. I haven't really followed up with this, so I'm wondering if that's still the case (or ever was). Do concurrent neovim plugins work in vim8 without change?
one cool thing is the `:terminal` mode which allows you to move a lot of window management to nvim, and your terminal is now an nvim buffer (with all the exciting possibilities that affords :) Vim window management comes naturally if you spend sufficient time in vim.
I'm using tmux less now (although my knowledge of it was limited at best), but its still useful for persistence and some window management.
I'm using tmux less now (although my knowledge of it was limited at best), but its still useful for persistence and some window management.
:terminal is now also part of the Vim 8 patches as an experimental feature. NeoVim seems to have a large influence on Vim, given that the previous "vimshell" patches never made it into upstream.
Do you really want to do window management and terminal tasks in your text editor? I'd rather use my window manager for managing windows, or my terminal for doing terminal tasks.
Just try to imagine someone wanting to have the editor fill the entire screen, and designate one small pane to a terminal. I can't imagine how to do that with something like tmux and vim (other than running multiple instances of vim which is bad for its own reasons).
Take a cross split.
https://i.imgur.com/Flqexnq.png
I left neovim for vim, though, because of the known system clipboard pasting issue.
Take a cross split.
https://i.imgur.com/Flqexnq.png
I left neovim for vim, though, because of the known system clipboard pasting issue.
> I left neovim for vim, though, because of the known system clipboard pasting issue.
What clipboard issue is that? I couldn't find it online, and don't currently use neovim.
What clipboard issue is that? I couldn't find it online, and don't currently use neovim.
Do you refuse to use vim's tabs and windows for the same reason?
It makes it really easy to write Perl/c, compile and run it, search the history for output of previous runs etc. It's a big improvement on having to have multiple putty sessions, or even alt-tabbing between shells on a box with a UI.
It makes it really easy to write Perl/c, compile and run it, search the history for output of previous runs etc. It's a big improvement on having to have multiple putty sessions, or even alt-tabbing between shells on a box with a UI.
I don't refuse to use tabs or windows, but a lot of the times I'd rather split them out into separate non-vim windows.
I guess it all depends on your workflow though. I mainly use vim in a tiling wm environment on Linux, not through putty on Windows.
I guess it all depends on your workflow though. I mainly use vim in a tiling wm environment on Linux, not through putty on Windows.
I don’t use it regularly, but it’s handy in a few scenarios. When you’re in a terminal and working with nvim and never launched tmux, it’s handy to be able to build or access a REPL without suspending your editor. Also, in a GUI editor where you don’t have tmux.
I do those things inside emacs.
Is it any different to :terminal in Vim?
You shouldn't feel compelled to switch, Nvim is intentionally user-compatible with Vim.
But these days it also makes sense to ask instead "why should I use Vim?" The version of Vim that you actually use probably wasn't installed by default on your main development system. So installing Nvim is the same as upgrading Vim.
But these days it also makes sense to ask instead "why should I use Vim?" The version of Vim that you actually use probably wasn't installed by default on your main development system. So installing Nvim is the same as upgrading Vim.
He literally asked several times for reasons to switch to nvim, but your answer basically amounts to "well because it's not hard". Telling him upgrading is not hard, or that it is compatible with vim gives him nothing.
From the nvim GitHub page:
From the nvim GitHub page:
Modern GUIs
API access from any language including clojure, lisp, go, haskell, lua, javascript, perl, python, ruby, rust.
Embedded, scriptable terminal emulator
Asynchronous job control
Shared data (shada) among multiple editor instances
XDG base directories support
Compatible with most Vim plugins, including Ruby and Python plugins.Yes. My perspective is:
- It's ok if this person doesn't want to use Nvim.
- The "Why should I switch to Nvim" question is based on a questionable premise. I think the question should be "Why should I should to Vim".
- It's ok if this person doesn't want to use Nvim.
- The "Why should I switch to Nvim" question is based on a questionable premise. I think the question should be "Why should I should to Vim".
What do you use as your main development system? I'm on an Arch Linux VM, so I have an up-to-date Vim 8.0.
And since Vim 8.0 does terminals and asynchronous jobs now, I don't see much value for Neovim unless you have an IDE that integrates Neovim via its API.
And since Vim 8.0 does terminals and asynchronous jobs now, I don't see much value for Neovim unless you have an IDE that integrates Neovim via its API.
> unless you have an IDE that integrates Neovim via its API.
This will be the biggest win for Neovim. When something like pycharm/webstorm vim support is moved to real vim rather than a reimplementation I will change.
This will be the biggest win for Neovim. When something like pycharm/webstorm vim support is moved to real vim rather than a reimplementation I will change.
I used to think in similar paths too.
Honestly, NeoVim's biggest wins are a nice website, cleaner code (I think) and XDG basedir support.
(And to be fair, switching on Arch is really easy since it's in the official repositories)
(And to be fair, switching on Arch is really easy since it's in the official repositories)
I tried NVim maybe 2 years ago. At this time it wasn't able to read my complete .vimrc. So that was a huge show stopper. Does that work now and can I be sure that nvim creates the same setup based on my rc file?
Not sure about your setup, but my .vimrc is pretty non-trivial and nvim Just Works. I even have ~/.config/nvim just symlinked to ~/.vimrc.
I know this may sound quite weird, but I'm actually wondering what the benefits could be from consuming neovim api from emacs.
Maybe this could lead to something like having a better modal editor than what evil is already providing (and doing a great job at it), with emacs' benefits like orgmod and magit?
What are my fellow hners thinking on that?
Maybe this could lead to something like having a better modal editor than what evil is already providing (and doing a great job at it), with emacs' benefits like orgmod and magit?
What are my fellow hners thinking on that?
Neovim has sparked a dream in me, that every IDE in the future will have a "use vim" instead of "use vim commands", that will litterally use neovim, and give users the modal power and their preferred setup of vim combined with all the niceties of the given IDE for profiling, debugging code combined with the GUI features.
As a Spacemacs user for over a year (and a neovim user for a few years before that, and a vim user for a few years before that), I find that spacemacs does a good job of emulating vim keybindings, but it isn't exactly right. Having neovim handling the keybindings and communicating what actions need to be taken back to emacs would let me have the great flexibility of emacs' plugin system, while retaining the vim keybindings in as authentic a manner as possible.
Switched back to nvim from spacemacs because of this. Significant cognitive dissonance when something is familiar but not exact.
Have decided that just going full emacs would be a better route if the pain is going to be there anyways.
Have decided that just going full emacs would be a better route if the pain is going to be there anyways.
> having a better modal editor than what evil is already providing
FWIW, after using Evil for 1 year and generally liking it, it still fell a bit short for me since you are still in emacs and still need emacs keybindings some of the time, and some other modes will conflict with Evil, so it was a bit hard to maintain. I switched from Evil to God Mode which gives you modal editing in emacs but using emacs key bindings. I have found this to be a good compromise.
FWIW, after using Evil for 1 year and generally liking it, it still fell a bit short for me since you are still in emacs and still need emacs keybindings some of the time, and some other modes will conflict with Evil, so it was a bit hard to maintain. I switched from Evil to God Mode which gives you modal editing in emacs but using emacs key bindings. I have found this to be a good compromise.
I believe the general idea to integrate an actual Vim implementation like nVim instead of an emacs plugin would enhance the vim experience inside emacs a lot.
But then you would give up Emacs's benefits if being able to reprogram everything. And you would lose the interaction with magit and org. After all, if you used nvim on Emacs, nvim would be doing the syntax highlighting and source code interaction, which defeats the point of running it in Emacs.
My favorite thing in this release is that shift+tab works in the terminal now.
To unindent a visual selection? The "correct" way to do that is "<" in visual mode.
What has always annoyed me about this is that < and > (de)indent but also unselect the text and put you back in normal mode. Why? I often want to indent more than once but don't want to count ahead of time how many it will take, but that means I have to reselect the text N times. Is there a good way around this?
Edit: just found that gv will reselect the last visual mode selection, which makes this much less cumbersome.
Edit: just found that gv will reselect the last visual mode selection, which makes this much less cumbersome.
Why don't you just hit . to repeat the last indent?
This is the super easy way to do it.
I like to us gv as default, so I have this in my .vimrc:
" Align blocks of text and keep them selected
vmap < <gv
vmap > >gv
" Align blocks of text and keep them selected
vmap < <gv
vmap > >gv
[deleted]
[deleted]
I think my comment wasn't super clear. What I meant is shift-tab in terminal emulation, which wasn't registering correctly.
What does/should shift+tab do ?
Before this release, using shift tab (as well as the function keys and a few other key combos) in the embedded terminal would just output weird junk characters. Now they all get passed through to the terminal correctly and behave like they would in a normal terminal.
Reverse tab completion for autocomplete suggestions.
How does one obtain Neovim v0.2.1 for Windows? The installation instructions at https://github.com/neovim/neovim/wiki/Installing-Neovim point to https://github.com/neovim/neovim/releases/download/v0.2.0/nv... , and the obvious guess https://github.com/neovim/neovim/releases/download/v0.2.1/nv... doesn't exist.
Releases page always has pre-built packages (look for "Downloads"):
https://github.com/neovim/neovim/releases
I've updated the wiki URLs also, thanks for mentioning it.
https://github.com/neovim/neovim/releases
I've updated the wiki URLs also, thanks for mentioning it.
Does anyone have any recommendations for NeoVim GUI client on OSX?
VimR is nice, but very buggy in my experience. I'm using Neovim.app at the moment after fixing a few bugs in it, but it's got plenty of issues.
VimR is nice, but very buggy in my experience. I'm using Neovim.app at the moment after fixing a few bugs in it, but it's got plenty of issues.
I wonder if you can build neovim-qt for OSX. I don't see what would stop you, since Qt is available on OSX.
Thanks for the pointer. It builds and runs well. Font rendering is fine on my MacBook's retina screen, but it looks terrible on my external monitor for some reason.
What are the benefits of neovim over vim 8?
The main features of neovim from my point of view are the messagepack based remote API letting you write plugins in any language. Many have bindings already to go such as haskell and golang: https://github.com/neovim/neovim/wiki/Related-projects
This API, for example as let people write a vim plugin for VSCode that actually runs neovim in the background.
It's pretty slick.
From a user point of view, more plugins is probably it. I don't know if vim has it yet, but neovim has asynchronous process support, so repls and terminals are easier to use.
This API, for example as let people write a vim plugin for VSCode that actually runs neovim in the background.
It's pretty slick.
From a user point of view, more plugins is probably it. I don't know if vim has it yet, but neovim has asynchronous process support, so repls and terminals are easier to use.
For emacs users, the Wilfred/remacs[1] project may be equally interesting.
It is an ambitious fork of emacs, written in rust.
[1] https://github.com/Wilfred/remacs
It is an ambitious fork of emacs, written in rust.
[1] https://github.com/Wilfred/remacs
I wonder if it's stable on Windows now. I tried 0.2.0 but it felt more like a proof of concept. To be honest the version number kind of implies that this is not a super-stable version :)
Every Neovim release is considered stable. The leading zero means we may break backwards-compatibility in some cases (but we rarely do; we are considering 1.0 after 0.3 is finished).
For Windows, are you adopting a GUI as part of the packages supported by the official devs? A GUI-less Windows editor isn't of much use, especially considering the rather sorry state of Windows terminals (even with the enhancements in Windows 10).
The Windows packages include a GUI.
https://github.com/neovim/neovim/releases
https://github.com/neovim/neovim/releases
Is the windows GUI advertised in any way, like screenshots, feature lists, etc?
If it wasn't for your post, I wouldn't have known this even existed. Now that I do know, I'm wanting to know more before I bother trying.
If it wasn't for your post, I wouldn't have known this even existed. Now that I do know, I'm wanting to know more before I bother trying.
Yes, I know, I has just checking if it's there to stay for 1.0. Good to know that it is! :)
(Off-topic: you guys rock, I hope the Neovim vision of a high quality Vim component scriptable picks up steam and maybe one day in the distant future Neovim powers a top-notch IDE powered by Lua scripts, instead of the ugh Vimscript ones)
(Off-topic: you guys rock, I hope the Neovim vision of a high quality Vim component scriptable picks up steam and maybe one day in the distant future Neovim powers a top-notch IDE powered by Lua scripts, instead of the ugh Vimscript ones)
A lot of work seems to have gone into the windows version for 0.2.1, I would try it again.
From a quick test, :terminal did not work on my windows setup on 0.2, it is now working (which is a least a new feature of neovim vs vim)
It's not, I still get a white background I cannot change, even with nvim-qt -- -u NORC. It's been fine on Linux for ages.
I think you interpret that correctly.
I stopped using Neovim a few months ago because of sporadic freezes. I often freezed when I was using :Glog and so on. Now I think I will give it a chance again )
That sounds a lot like this issue with jemalloc and Neovim on macOS:
- https://github.com/neovim/neovim/issues/5681
- https://github.com/neovim/neovim/issues/6950
- https://github.com/neovim/neovim/issues/5681
- https://github.com/neovim/neovim/issues/6950
Just wondering if it is possible to use neovim as lua REPL.
they are releasing linux in AppImage format. Works pretty well!
Oh good ol times... :wq
Actually, why do so many people still use :wq? Vim has :x which does the same thing and saves a keystroke and saving keystrokes is what Vim is about, right?
IIRC :wq always writes to and exits the file, thus updating the timestamp on it. :x (and ZZ) will only write to the file if there are new changes. So there is a difference between the two.
Personally, I just use :wq because muscle memory and that I sometimes find knowing the last time I even opened the file in an editor is a useful thing to know.
Personally, I just use :wq because muscle memory and that I sometimes find knowing the last time I even opened the file in an editor is a useful thing to know.
I didn't know about it until now. It might be because after a change I know I want to :w, but haven't yet decided if I also want to :q.
In such a situation I also do the :w and :q separately without even considering :x.
ZZ is way faster than either, especially on Dvorak.
What is the difference in Dvorak here? Is shift not used for upper case letters?
No, but w and q are on opposite sides of the keyboard.
Which should make wq faster?
You're forgetting the colon. You're already pressing shift.
Actually I meant that when touch typing, using both hands is quicker than one hand/typing the same character twice. But you're right ofcourse ; it's ":wq" vs "ZZ" - which means the latter is quicker. Not that I actually think it matters much, but that's neither here nor there - it's important to decide what colour the bikeshed should be ;)
I use :x all the time, and I haven't used :wq, at least in a while. Also, I remapped ctrl-s to :w, which is easier especially when control key is my capslock key. But I do get a kick of seeing the ":wq" joke/sticker, which is funny but only Vim users can understand.
nmap <C-m> <ESC>:w!<CR>
nmap <C-n> <ESC>:q<CR>
nmap <C-l> <ESC>:q!<CR>
[deleted]
Actually, why do so many people still use :x? Vim has ZZ which does the same thing and saves a keystroke and saving keystrokes is what Vim is about, right?
I know it was more of a joke, but there are actual reasons not to use ZZ.
(1) The difference is small, but one could argue that shift-z shift-z are more like 3.5 clicks, while shift-dot x are certainly 3 clicks.
(2) People are used to do a colon before an actual interaction with the editor instead of the text.
(3) taste. Even if one argues that both has the same effort then taste is the final decision and there people can be different.
(1) The difference is small, but one could argue that shift-z shift-z are more like 3.5 clicks, while shift-dot x are certainly 3 clicks.
(2) People are used to do a colon before an actual interaction with the editor instead of the text.
(3) taste. Even if one argues that both has the same effort then taste is the final decision and there people can be different.
Regarding (1), ZZ is [hold shift][type zz][release shift], while :x is [hold shift][type :][release shift][type x], so I'd say :x is 1 more action than ZZ, and the timing of the release makes it slower IMO.
Is there a parallel to :w as ZZ is to :wq or :x? With my layout at least, typing double colons is a bit more annoying than regular letters.
did NOT know this, thanks a lot lol. (vim user for 5 years)
Muscle memory
Literally the only sticker I will allow to be on my laptop:
https://squaredesign.com/builds/wq/
:wq
https://squaredesign.com/builds/wq/
:wq
I've been a user for over a year now. For me the biggest selling point is the plugin architecture.
An instance of this is Oni[0].
- https://github.com/onivim/oni