I think that's a joke, reads like one at least. I think even if you're in a "tribe" like that, you can recognize the cult-like environment. Many Clojure followers would acknowledge the community can sometimes be like a cult. Same thing for Rust and a bunch of other languages. Doesn't mean we don't like it :)
Is there a conference for everything nowadays? I mean with the digital conference it's not really going to happen, but didn't some companies declare bankruptcy because they kept pouring all their money and effort into conferences?
I like niche conferences, especially more-so if you're part of the group! I've been using vim for my entire career and neovim since around v0.2.
One of vim/neovim conferences (forgot which one) I was introduce to one of my favorite plugins: harpoon [1]. I would have never learned about this plugin if it wasn't for these types conferences.
If it's called VimConf, I could understand including content from anything vim related, even vi or neovim stuff (or from the other forks/variations/bases).
But if it's called NeovimConf, I wouldn't expect that to include the entire Vi ecosystem.
That will be changing soon. Vim 9 has a new version of Vimscript (called Vim9script) which Neovim doesn't support, and its APIs for things like async jobs are also different. However Vimscript itself will probably remain a common denominator for many years to come.
TJ DeVries (one of the Neovim contributors, and a frequent streamer) was working on some sort of vim9 translation support for Neovim. Seems more like a side project rather than something that will be built into Neovim, though.
Harpoon is really cool, especially if you only work with 3 to 4 files. The ability to switch files with two keys is extremely nice. It's just a very ergonomic and pleasant plugin to use.
You might already know this but niche conferences are part of some larger marketing strategies. Seeing conferences for a product can add legitimacy in the minds of people who are shopping for solutions. But over time I've realized there's more to it, almost an Inception-like quality to a lot of conference topics.
A company I worked for had a whole division dedicated to inventing conferences around products or ideas that other companies wanted to promote. A great example are conferences where there are talks on cloud-based tools. The speakers don't just go up there and say "go buy compute from vendor X". Instead, everything is structured around how to use (often free) tools or techniques that ultimately require investment in "compute or storage from vendor X".
Another, more abstract, example is a conference on programming languages or frameworks. These are great places to push ideas about "the new way" or "the right way" to do something that happen to include something you're selling. I've seen conferences make attendees into low-level developer evangelists. Those people went back to their companies to endorse programming languages and architectures that had a lot of support from particular vendors, and the cycle was complete. It may seem a bit hand-wavy the way I've explained it, but I've seen it work.
My point is, conferences may cost a lot to put on but have quite a few obscured benefits that you have to price in when considering if they're worth it.
Hell yeah. I've heard enough war stories from conference organizers to know that they'd really benefit from a small conference to share tips on running conferences.
The problem is that anyone who'd benefit from it would want to run it.
I'm happy to see that Neovim is still going strong. Most promising text editor projects (xi, oni2, ...) seem to stall after 1-4 years, so this is a pleasant surprise. To be honest, I wish that the Neovim devs had forked Emacs instead of Vim but oh well, can't have everything.
Neovim is a hard fork, not a continuation. Vim is still being developed by Bram and other contributors, and has a lot of the same functionality now with different API surfaces. Questionable choices by both development groups (but, IMO, mostly from the initial arrogance of the neovim developers) are increasing the gap to the point where, in a couple of years, I do not expect there to be meaningful compatibility between them.
A lot of people don’t like Vimscript, but I personally find the Lua integrations which neovim has to be harder to use because the language isn’t built around the editor, it requires bridging, and there’s a definite impedance mismatch involved.
For me, without an equivalent of `gvim`/`MacVim`, neovim is a non-starter. The OS-level integration is important, and none of the various neovim GUIs that exist are nearly as good as the original `gvim` for X or Windows or MacVim for macOS.
I find lots of arguments about who was actually more arrogant. But lets look at it from objective perspective. Looking at neovim[1] vs vim[2] contribution
Bram is top contributor for vim. 16,211 commit right now. Second top most contributor has 194 commits only.
Neovim top contributor has 2285 commits, followed by 21,66 commits for second.
It looks to me that neovim is more open to community contribution.
Then look at commit graph over period of time. It looks like Neovim is more actively developed. There development activity level around vim also increased in 2016. Perhaps that was the time when bram realized that he need to do more with vim, to compete with neovim.
I myself was a longtime vim user, who switched to neovim 2 years ago, and am happy with it.
Pretty much everything, including the ongoing lie that Neovim is a "continuation" of Vim.
I replied in a different comment (https://news.ycombinator.com/item?id=33922783) about the async patches, which is where the whole things started. Because the patches weren’t accepted as is, they hard forked.
That requires an incredible amount of arrogance.
Neovim is not better than Vim. It is (increasingly) different. They have made different choices, some of which are interesting, some of which are baffling, and most of which are just different, although I consider the removal of GUI support to be about as arrogant as the gemini protocol stuff. There is a pernicious strain of software developer that thinks that they know better on everything and that GUIs are bad.
I felt that way in 1992 or so, despite having been exposed in 1990 to X, because it was easy to pick on Windows 3.1 and (then) Mac users. I got over it because there are things which are better, easier, and faster with GUIs than without. Not everything needs a GUI, but if you want people to use your software, leaving it in the terminal is unlikely to be a long-term success strategy.
Bram/Vim had a clear minimalist philosophy. Many wanted More from Vim; namely things like Terminals, Async, better scripting, etc.
Bram wasn't going to add those updates/upgrades (for philosophical reasons). So the community did what OSS does; and forked/added them. NeoVim was born.
Others could (justifiably) contest, but that caused Bram to ~panic that Vim wouldn't be the primary 'vi' moving forward, and Vim updates (adding NeoVim features or equivalents, sometimes better sometimes worse) started coming out.
{Neo,}Vim is in a much better state functionally than it was a few years ago because of the schism; enough that I switched back from VSCode without missing (much). I am saddened by the split community now though.
> although I consider the removal of GUI support to be about as arrogant
They didn't just delete the GUI. They made it easy to embed neovim and as a result there are several GUI frontends now. Seems like a good call - gvim is not a great gui so why keep it around rather than making it easy for gui people to make good ones against an api? There are several active guis right now: https://github.com/neovim/neovim/wiki/Related-projects#gui
None of the ones that support macOS are good, and all of them that don’t have explicit macOS support are all awful.
Given the choice, I can either:
1. Hate every day of working with the substandard state of neovim GUIs
2. Hate every day of working with neovim remediated by a terminal
3. Switch to Emacs
4. Switch to VS Code
or
5. Keep using MacVim, because it just works
I try each of the various active neovim GUIs every few months. Usually, I end up noping out of each one with just trying to edit a single file. For ones that have stuck for a day or two, I end up noping out of them because they are missing key OS integrations or are sluggish or have made decisions to act more like an IDE (Vimr) that result in a UI that’s less flexible than gvim or MacVim itself.
You say that gvim isn’t a great GUI, but that’s a subjective — and IMO wrong — opinion. It is vim. It doesn’t try to be anything but vim. It doesn’t try to add IDE frippery (because you can implement all of that with vim plugins) or switch to an entirely different plugin system where you can’t use any of your existing configuration (Oni2).
gvim — and MacVim — are great GUIs for being separate non-terminal-bound views on vim. There’s not a single neovim GUI that has reached that level, and most of them get abandoned because, in the end, no one on the neovim ecosystem cares because the core project doesn't care.
I suggest that you start reading for clarity and stop assuming that someone who feels strongly about something is angry. The condescension you’re expressing is both ignorant and asinine.
It’s not very good. It is perhaps the best available Neovim GUI, but VimR has been an unusable mess every time I have tried because it’s trying to be an IDE first and not Vim first.
Before I can take Neovim seriously, I need a Neovim GUI that is exactly what gvim or MacVim provide — not something that adds features I neither want nor need nor can I easily disable.
Granted, it’s been about six months since I’ve used VimR, but I bounce off it every time, because it doesn’t work with the configuration that I have built up trying to match my Vim configuration to the best of my ability.
>Before I can take Neovim seriously, I need a Neovim GUI that is exactly what gvim or MacVim provide — not something that adds features I neither want nor need nor can I easily disable.
Having used MacVim for several years and now using Neovim mostly in the terminal but sometimes VimR, I disagree that it's a mess.
I get wanting to have a common gvim ui/ux across platforms, but I think having a Mac-like or Windows-like ui/ux on those platforms mostly trumps that.
Also, the special features of VimR, like the built-in file browser and Markdown preview can easily be disabled. Using the native rendering of macOS and support for ligatures, for example, is certainly a plus IMHO.
> Because the patches weren’t accepted as is, they hard forked.
They weren't accepted for years, and if you're being honest, they never were going to be accepted. I'm guessing you thought Bram was also arrogant for forking vi?
You’re right. They weren’t going to be accepted, because they didn’t work the way that Bram thought they should and the people who pushed them would not change them to fit Bram’s goals. As package maintainer myself, if I get a PR/patchset the implements something in a way with which I disagree, I will not accept the changes. If I don’t care enough about the changes, then I probably won’t implement them either. Or I might do so later when I have time.
On the history of things, please be more precise. Bram did not fork vi. He worked from the Stevie code, which only ran on the Atari ST, so that he could use it on Amiga. It quickly expanded to other systems (I believe I encountered it after trying other DOS-based vi-like editors). That expansion eventually made it into the relative juggernaut it is today.
So... Bram won't accept their input, so they go make their own product with their input, and you call it arrogance. Got it.
You have every right to disagree with people's patchset, just as they have every right to disagree with your direction and decide to do it their own way.
I think that you’re intentionally misunderstanding, because that’s not at all what I said.
The arrogance is twofold:
1. Their way or the highway. It wasn’t that Bram wouldn’t accept their input, but that would not accept Bram’s input and change the patches to be closer to what he wanted for such a feature. He would not accept their input under their arrogant terms.
2. Their continued description of Neovim as a "continuation" of Vim—as if the development of Vim had stagnated (it had not, it just wasn’t at the pace that the Neovim developers wanted). It’s a garbage statement that should have been removed five minutes after it was first stated, unless the person making (and continuing to make) the statement is so arrogant that they can’t see that it’s an outright falsehood.
Frankly? I don’t care that Neovim forked from Vim. IMO, it’s got some interesting ideas overshadowed by a core team that is careless with its language and some of its technical direction (see elsewhere on the treatment of ACLs, which makes neovim fundamentally unsuitable as a system editor). As an editor, I think that it’s less mature and stable than vim. I think that the use of Lua is interesting, but that the Lua/Vim API is less than useful. As an experimental testbed for some neat ideas…good on them.
Could I contribute to neovim to fix some of the issues that I have with it? Sure. I don’t want to, though, because on the whole I find the attitude from the neovim developers to be unwelcoming. That could be fixed by removing unnecessarily inflammatory language and no longer lying about the origins of neovim.
Forks can be good, even if there is no cross-pollenization between the projects. Look at the success of egcs. But they aren’t good when they’re founded on lies and ill will.
Frankly? I don’t care that Neovim forked from Vim.
I don't mind your indigination -- you've given neovim v. vim more
thought than most. I do mind when pointy heads say "I don't care" when
they clearly do.
Point of clarification: I don’t care about the fork. If you want to go a different direction than a parent project, that’s absolutely what you should do.
I do care about the way that the fork happened and the misrepresentations of the fork, so I’ve written way too many words about this today.
IIRC GUI support was taken out because one of their long term goals was (is?) to reduce the codebase and to make neovim something you can plug into any text input field. You could use it as a backend for a standalone GUI app, or in Firefox for leaving HN comments. I seem to recall they had plans for an official GUI after they got to a certain point. Not sure if they still do.
Things have calmed down a bit now, but there were quite a lot of harsh words coming from some Neovim developers aimed at Vim and Bram personally which really turned me off; things like "lazy" and such. You can disagree on a technical level without being an asshole about it.
Hard agree on lua v. viml. Viml really isn't that bad. I'm certainly not claiming it doesn't have its warts and shouldn't keep improving, but it's a DSL for a text editor...
And as you point out, you still need to know a bunch of viml that you have to wrap in Lua calls.
At the same time, I haven't actually given vim scripting in Lua a fair shot, so I'd be happy if anyone could shed some light on why they might think it's better.
You’re right, at one point nvim was a continuation, but no more. For example nvim significantly cleaned up and reorganized and rewrote vim’s C code, they added complex new features like Lua config, floating windows, better plugin support. Vim copied many features they released independently… maybe vim is the continuation here now? I think one of my favorite things about vim the continuation is that after sitting on a terrible config language for >2 decades somehow when nvim released Lua support all of the sudden vim was working on a new incompatible version of vimscript.
Neovim was never a continuation. Bram has never stopped developing Vim.
As I understand it, the people behind Neovim developed some async patches which were not accepted by Bram for various reasons, and there was an ongoing discussion. Rather than reworking them to something that Bram thought was acceptable, they performed a hard fork. In the process of hard forking, they removed everything that they considered unimportant. This included gvim, support for older OSes, etc.
Vim has not, to the best of my knowledge, copied any features back from neovim, although it does now (shortly after Neovim forked) have async features (written with an API and user surface that Bram prefers) and various other features that may be similar.
Please note that Vim has had Lua, Ruby, Python, Perl, and other scripting language support for a very long time. The main difference is that rather than being compiled as an add-on and using bridging, neovim has added a Lua engine into the core (increasing complexity that way) and creating a DX-poor bridge for common vim configuration things so that startup scripts can be written in Lua.
Yes, Bram started working on Vimscript9 late, but your characterization of the history also is (unintentionally?) dishonest in that Vimscript has had extensive expansion and updates through time.
Neovim is not and has never been a continuation of the Vim project, despite their press. It has always been a hard fork that is getting increasingly incompatible with the source project, and I personally find it less usable than Vim because there’s not a single good GUI for it (there are several which may eventually become promising, and there are several which have taken bizarre directions like Oni2 did).
>… neovim has added a Lua engine into the core (increasing complexity that way) and creating a DX-poor bridge for common vim configuration things so that startup scripts can be written in Lua.
And one can look at the explosion of new Lua-based plugins that have been developed because of it. People hated Vimscript. Now that there is a better first class language (guaranteed! Not dependent upon the host environment or compilation target), NeoVim is gaining some of the plug-in functionality that had previously been Emacs exclusive.
Neovim provided Bram competition, but he has not copied those features from Neovim.
vimscript9 doesn’t look or act like Lua (it still acts like a first-class citizen, unlike Lua) even though it is definitely improved over the previous version.
There have been terminal scripts for a while, but adding virtual terminal support was something resisted because a lot of people ran vim in a tty or with tmux. (Strictly speaking, terminal support is only something that to me makes sense for gvim and the like, otherwise you’re getting into terminal emulators all the way down. So much for the neovim philosophy of ripping unnecessary things out.)
And async was the entire reason that Neovim hard forked from Vim. Bram did not like the patches and asked for changes. The Neovim developers didn’t like the changes, so they hard forked. Bram implemented the async features / API surface that he wanted shortly thereafter.
There is a constant push from the Neovim camp that Vim is stagnant, backwards, dead, etc. None of this is true, and the messaging should absolutely stop. Frankly, I’d be happier if they rebranded from Neovim, because IMO they’re not vim and have stopped caring about compatibility with vim.
> There is a constant push from the Neovim camp that Vim is stagnant, backwards, dead, etc. None of this is true, and the messaging should absolutely stop. Frankly, I’d be happier if they rebranded from Neovim, because IMO they’re not vim and have stopped caring about compatibility with vim.
I have happily used (Brams) Vim the majority of my career; some daliances into PyCharm or VSCode here and there.Prior to the NeoVim fork; Vim felt.. slow.. to adopt new features. I was OK with that generally. 5 years for Vim7 to come out was the biggest gap, before Vim8 released after a decade gap (with NeoVim getting forked ~halfway through). Each major release taking longer than the previous. You can say Vim development hadn't slowed; but major releases did; with a ten year gap was concerning.
I don't say that as a negative on Bram, but 10 years between major releases is an eternity in the modern programming world - I'm glad he's refocused, Vim-9 is a huge leap forward.
>Strictly speaking, terminal support is only something that to me makes sense for gvim and the like, otherwise you’re getting into terminal emulators all the way down.
Terminal is what allows plugins such as fzf.vim to work, I think it's amazing.
I only welcome the competition between vim and neovim, I think it's been a great improvement to the ecosystem.
I dont know if its me but I find it utterly incomprehensible to read any Lua plugin in neovim. The API is magic and Lua itself isnt a very good language. That is to say, it didnt really get any better than vimscript. Ive written a couple of plugins in vimscript back in the day so i know the pain.
"Lua itself isnt a very good language" is very subjective.
The API is pretty well documented now I think? If there is a specific area that isn't, then file a bug or write the docs. It is an open source project and thus is heavily depends on people contributing to make things better.
I use neovim heavily and I spend the first five minutes of my morning thanking the developers for their hard work - without their selflessness we wouldn't have the best text editor in the world. I was just commenting on whether the purported benefits of using Lua over Vimscript as the core scripting language really panned out. Clearly a lot of people think they did.
I haven't implemented this yet, but one thing I'm looking forward to is lua libraries. I have a data YAML that carries some autocomplete information. To use it with a vimscript function I had to convert it to a JSON first. With lua I should be able to use a library to just read the YAML directly.
I disagree that Lua isn’t a good language. As a general purpose language, it is better than Vimscript, which sort of expanded into a general purpose language by fits and starts, and often not very cleanly.
Vimscript9 fixes some of this, but it is still focused on being a special purpose language (scripting vim) far more than being a general purpose language.
I agree with you that the neovim / Lua bridge is substandard and poorly documented, and way too magic. There’s too much distance between Lua and the vim model that isn’t well bridged by the API that has been written.
Certain things are better for neovim with Lua, because you can (in theory) take advantage of all that Lua has via luarocks. But that bridge back to the editor is still ugly, and I don’t like it.
> and I personally find it less usable than Vim because there’s not a single good GUI for it
What features do you use from gvim? I used to switch between them, but I hated updating the vim font when I decided to change my terminal font, so eventually I just switched to the terminal version full-time. It's been over 10 years at this point, but I don't remember anything useful in gvim.
The OS clipboard integration, the good font hinting and rendering, better colour rendering, the fact that the terminal doesn’t intercept some keyboard strokes. There’s a bit more, but I also find vim in the terminal to be less responsive overall than gvim.
I’m using MacVim as my gvim, but as I’ve indicated, the amount of code in MacVim is fairly small over that in gvim.
VimScript has been in development for 30 years now. There has been support for many other languages (including Lua) for over 20 years, well before Neovim was a thing. The idea that Vim9Script is only due to Neovim is one of those weird ideas that I will never understand.
I don't especially like Lua as a language (it's okay-ish, I guess, but not great), and I certainly don't think it's a good fit for a Vim configuration language, but it's okay to disagree on that. But it seems that some people are unable to comprehend that some people don't think that Lua is a gift from heaven for Vim.
Vim9Script is very similar to "legacy VimScript", but with slightly different syntax and typing. Overall, I'd say is less of a breaking change than Python 3 was, and it's not like Python 3 is a "new language": just a continuation of the >20 years of Python 1 and 2 before it.
If you look at vim commit history, it was pretty much stagnant for a long period of time, and then activity picked up in 2016, when it finally got competition from neovim. IMO governance model for vim, is not much receptive to community contribution, while neovim is more open. Looking at commit history and contributors graph on github seems to validate this.
Nitpicking (or maybe educating?) but WYSIWYG is specifically editors that allow you to create things like GUIs by dragging and dropping elements rather than writing code. Most text editors allow you to change the font one way or another, but that doesn't mean they are WYSIWYG editors ("What You See Is What You Get").
The standard definition of WYSIWYG is a text editor where what you see on the screen (fonts and all) is what gets printed. Prior to the Bravo text editor on the Xerox Alto, this was not the case.
To join the (nit)pickin' party, I would argue that MacVim is WYSIWYG in that what comes out of the printer will look just like what's on my screen, minus the editor chrome that MacVim adds. IOW, if :set guifont=Courier_New:h12, then a bunch of code in 12pt. Courier New comes out of my printer.
Can't stand it, myself. Of the various Neovim macOS UIs, this is the one that is perhaps closest to MacVim, but the UI choices about having the drawers present all the time and other pieces make it both less reliable and less usable than MacVim itself.
That's the main problem with most of the neovim GUIs—they get opinionated about what a Vim GUI should be. First, foremost, and always, it must be vim in a GUI window. Second, it must have native OS keybindings and integration (clipboard, menu, etc.). Finally, it should be able to have possible extensions that work well with existing plug-ins. (I use Fern for my file tree. I don’t need a built-in file tree that is always visible.) They must, at the core, always be vim. This is why I think that Oni2 was a mistake and why it’s one of the few software packages I regret paying. I don’t want vim motion keys with VSCode extensions. I want a Vim GUI.
> Great comment, I’ll add there’s a MacVim-like GUI wrapper but for Neovim called VimR that i really like.
Thanks for pointing this out. One thing I like is being able to command tab in MacOS -- if you have multiple terminal windows it breaks that, so any kind of GUI wrapper, even if it's basically just a glorified replication of the terminal app, is useful from a usability perspective. (To me at least)
That's how I originally moved from vim to MacVim -- I wanted terminal for sysadmin stuff, something like Sublime for coding, TexMaker for LaTeX (because it's it's own beast), and so on and so forth.
Neovide is fast, but does not have any macOS-level integration. While it’s nice that it’s not electron like so many other neovim GUIs, it does not work well on macOS.
NVIM = A fully compatible re-write with focus on better scripting (lua), performance etc
GUIs = Alternative for using VIM/NVIM inside a terminal, with better optimisation for performance, smooth scrolling, animations etc (e.g MacVim, Neovide etc)
I didn’t know that Neovim was a complete rewrite, thanks for sharing. The fact that I didn’t know while actively using nvim is a testament to the quality of compatibility they deliver.
I don't believe it's a full rewrite. From Neovim's Vision statement:
"Neovim is a refactor, and sometimes redactor, in the tradition of Vim (which itself derives from Stevie). It is not a rewrite but a continuation and extension of Vim."
The Neovim hard fork is not fully compatible, nor is it always better performing. I also do not find that Lua is better for scripting overall, because there is an impedance mismatch when you need to interact with the editor model. (If you’re doing just programming then, yes, it’s better. But it’s the interface layer which is difficult, and which I find worse than Vimscript or Vimscript9.)
MacVim is a macOS packaged version of Vim with (fairly) light customizations of gvim which is part of the vim source bundle. All neovim GUIs are from-scratch constructions because the neovim developers decided that they did not want to support GUIs directly. IMO, this was a mistake, because none of the neovim GUIs that exist work as well or are as well OS integrated as gvim or make for as "easy" packaging as MacVim has.
Neovim also has some surprising feature regressions compared to Vim. I tried switching to neovim for a while until I realized it was silently removing all ACLs on edited files and breaking services for me. Looking into it, I found that, for no clear reason, ACL handling was removed early on in neovim, and a bug had been open about it, with multiple pull requests that were never merged, since 2014 (https://github.com/neovim/neovim/issues/1200). Vim has never had a problem with this, as far as I know.
Besides CCC, I'm not sure what kind of infrastructure you could use, if you expect (lets say) 1000+ viewers from around the world. Running it yourself would be a lot, and you'd have to reach out to CCC way before in order to set things up with them to ensure good service.
Peertube does live p2p streaming. Plus you can also register the videos in advance given that this is not an in-person conference. Also CCC as you pointed out. And more.
After browsing around the website for EmacsConf, I don't find much information exactly how they did it. What software they used? Where is the infrastructure hosted?
The authors on that GitHub repo might be able to offer some advice or other help to F/OSS communities interested in hosting conferences where presenters can call in using only free software!
IIRC 2020's all-virtual NixCon was simultaneously streamed to live.nixos.org, YouTube, Twitter, and maybe a PeerTube instance (conf.tube?) from self-hosted infrastructure.
The more recent one in Paris might've been only on YouTube, idr. So maybe it doesn't always seem worth it to conference organizers. But it definitely seems at least doable.
Were they streaming real-time? I could only find that they are hosting their videos on https://media.emacsconf.org (would be interested to know who the host is and how much it costs to host videos in this way).
Hosting videos is trivial, especially for a relatively low-traffic event like this. Getting a dedicated host with unlimited traffic (like what Hetzner offers), you usually get a 1G uplink or better, should be able to host it no problem. Under 100 USD/month should be doable.
