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.
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.
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 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.
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.
It'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.
> 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:
set runtimepath^=~/.vim runtimepath+=~/.vim/after
let &packpath = &runtimepath
source ~/.vimrc
That lets me directly use vim config from neovim.
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).
> 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.
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.
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).
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).
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.
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.
> 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".)
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.
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 :)
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.
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.
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).
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?
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.
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.
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.
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.
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
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.
: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).
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.
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.
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.
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:
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.
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.
> 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.
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?
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?
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.
> 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.
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.
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.
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.
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.
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.
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).
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)
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 )
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.
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.
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?
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.
An instance of this is Oni[0].
- https://github.com/onivim/oni