It makes me sad to see a respectable piece of open source software hosted on this site with its intrusive advertising practices such as ads with fake "install" buttons on the download page.
What is the advantage of using Sourceforge these days when github and bitbucket are free for open source?
Even before github was around, sourceforge was a PITA. I remember clicking through the web UI for more than half an hour before finding the place where you could configure the project website/homepage.
Also, trying to delete an abandoned project, which had a mailing list, but it wouldn't let me delete the mailing list, because there was still an admin in there (me!), and I couldn't leave the mailing list, because then it would have been without admin. D'uh. And you couldn't delete a project with an active mailing list...
Then a few years later, after I didn't use SF much anymore, I tried to comment on the bug in the bug tracker, and didn't find any option to do that, even as a logged-in user.
I used google code as soon as it became available, because it worked, and had a much cleaner admin interface. Not to mention user interface.
> What is the advantage of using Sourceforge these days when github and bitbucket are free for open source?
I imagine the author figures that moving is a pain.
Don't forget, Sourceforge was the Github of yesteryear. I imagine in 10 years we may very well be asking the same of some old project hosted on Github.
Sourceforge's downfall was not finding a better business model than advertising – which has devolved into the worst kind of spammy ads. GitHub, on the other hand, has a solid business model that doesn't involve advertising. In fact, putting ads on the site would be suicide.
Sourceforge tried to find a better business model -- sourceforge enterprise edition -- but then spun it off and then sold it to a different company (CollabNet) in 2007...then over the next 3-5 years, laid off almost everyone behind sourceforge.net/OSDN. The only thing left of the company now is thinkgeek.
> Don't forget, Sourceforge was the Github of yesteryear.
Not really.
At that time, there were almost no alternatives. Sourceforge was slow and bloated, even without ads. Nobody wanted to use it, but at least it was free (in the sense of free beer).
And it took them ages to support SVN in addition to CVS. When they finally supported it, many project were already thinking about switching from SVN to a distributed VCS.
> It was "the way" to share your OSS project in its time
Nobody questions that.
But that doesn't quality for "the GitHub of that time", because most people like to use GitHub, so the analogy is incomplete in some essential aspects.
Eh, that's pretty nebulous. There's a whole lot not to like about GitHub, too. Vaguely hand wavy "oh that doesn't count cuz most people like GitHub" isn't really much proof of anything.
If you had the resources to host your own tracker/repository/wiki/mailinglist instead of using Sourceforge you did that. Github is so good it's actually hard to convince people it would be a good idea to have server for those things, even if money and time isn't the issue.
Not sure what you mean by "proof". Just take it as an anecdote of a contemporary witness. From your previous comments it seems that you didn't have to suffer through that time. Lucky you!
Hah, not quite. I've been in IT since 1995, suffered a layoff in the first dotcom crash. Don't get me wrong, Sourceforge has never been something I liked, but that didn't mean I agreed with the premise.
I'm also struggling to see any advantages to still using Sourceforge in 2015.
Firstly, they're well-known by now to be complicit in sponsored 'wrapper' installers bundling some pretty awful stuff - check out what they did with FileZilla - which is an even more intrusive advertising practice than that.
Secondly, they host a lot of executable code (and don't forget build scripts in source code, unless you check your Makefiles!), but they still don't use TLS, and don't even seem to have any plans to - which is by now negligent practice, I think, considering the widespread public knowledge of Hacking Team's (and GCHQ's) at-scale deployments of network-level file infectors.
SourceForge itself is free software. I think that's one possible reason to use it rather than GitHub or else.
The other possible is that SourceForge provide mailing list server and other service for projects. Anyway, you won't move a project around unless you have some strong motivations.
Is SourceForge really open source? Guess I must have missed that news. Regardless, Gitlab would still be a better choice in terms of UX and is also open source.
I agree that sourceforge.net as a service might not be my favourite, but Allura the forge-software seems pretty good. I think the only thing that comes close is the stack from Canonical -- but Allura seems more viable to self-host (and scale up when needed -- rather than "only a vm" or "full cluster"). It also seems less "overly opinionated", and still includes sensible defaults (contrast with getting up and running with Trac).
YMMV, but it doesn't look half-bad. Right now I don't need anything more than what you can easily get with either a separate wiki+mercurial+mailing-list, "just" trac or fossil -- but for something in-between "too big to host internally" and "too complex for Trac to be easy" -- it looks rather interesting. I'd love to hear any war stories.
GitLab developer here; it does! Where GitHub only allows images to be dragged into issue and comment description fields, GitLab allows this for any type of file.
Or, they could go one step further and do it like WinSCP.
That is, WinSCP has an own website that contains ads with fake download buttons. It's really nasty, but at least the advertisement payments go directly to the project, rather than just to the hosting service.
Searching the tmux mailing list [0], it looks like there were some recent discussions about migrating to GitHub.
Basically, it looks like the developers don't see any benefit to migrating that outweighs the cost of a migration. [1]
There is a GitHub mirror [2] maintained by, I think, one of the developers, but they don't accept pull requests.
It's interesting to note that, for such a popular project like tmux, there are so few contributors. [3] Five, to be exact.
Maybe that's an artifact of how the mirroring to GitHub works (perhaps the commit authors aren't translated correctly?), but I suspect it's more an artifact of an outdated contribution process and tooling.
lots of people have contributed to tmux (on a quick grep through the logs, probably ~25 have made significant or multiple contributions, ~170 have made small contributions)
Because it's how 99% of websites get their funding, allowing them to survive. Why have an adblocker installed when you can avoid the sites with obnoxious adverts?
Sometimes I have to get useful tools from them....like tmux.
As to why I use Adblock, I've never. Not once. Ever. Bought anything from an ad on a website. I _have_ bought books and such from the referral links on blogs (which adblock doesn't block).
The reason I use adblock is because I'm not the demographic ads on websites are targeting. So websites aren't losing any revenue by me not seeing their ads.
Of course they lose revenue. your view is like any other.
(http://en.wikipedia.org/wiki/Cost_per_impression)
you won't be taking money from the company, which started the ad campaign.
also: don't underestimate the effects on brand value, which will come subconsciously, if you look at ads.
You will know certain companies are still active etc. This is why you don't necessarily need to be targeted. simply informed.
The "sometimes" you talk about should just be with ads on. it won't hurt much, because it's just sometimes.
Only if you view CPI in isolation as money from the sky.
Marketers estimate the CPI they're willing to pay based on estimated conversions per impression. Ultimately, the money comes from sales. It always comes from sales.
If I don't ever purchase anything from a website ad, my impressions are worth zero. My impressions, and impressions by those like me, will drive down the price a company is willing to pay per impression since the conversion ratio also goes down. In fact, my impressions incur a negative effect since it still incurs a cost to the advertiser.
In the best of all possible worlds, only those who will ultimately buy a product are displayed the ad. Resulting in a 100% conversion ratio. Each impression would be maximally valuable and the price paid for that impression would rise to reflect that.
Those of us who use adblock have removed ourself from the market and from the conversion ratio calculations and cost per impression to the advertiser.
They might lose revenue at first, but in a way that is entirely healthy for a larger system of advertisers and clients, in that both advertiser and client reassess the effectiveness of an instrument (an ad network or product), and thus reassess the correctness of a price for an advertising opportunity.
Maybe I'm apathetic to these arguments because I'm quite comfortable paying for content and services, and I'm comfortable with a version of the web where a paying class gets to have paying-class products. If the public feels there should be a free thing, then let it be funded by taxes.
What do you gain by blocking adverts? An extra 150K from your data plan?
Quicker page loads, avoiding seizure inducing ads that are designed to attract your attention in an overly aggressive way, better visibility of text because it's not surrounded by flashy pictures, animations and videos. Plus avoiding Flash/Java/JS ads poisoned with malicious content.
And, oh yeah, and ~150K that won't hit my data plan.
For the record, I don't block all ads. I have sites that I allow them on because I am a frequent user and their ads are not too obnoxious to deal with. If my page views (never clicks though) help them then great! But I surf with the blocker on by default for the reasons laid out above.
Consuming content or a product whilst deliberately evading the means put in place to compensate a creator for the work done is akin to piracy. I don't see how there's any question that that isn't at least a morally grey area
"Your contract with the network is, you're going to watch the spots. Any time you skip a commercial or watch the button you're actually stealing the programming."
At least with lynx/links, you don't get any javascript functionality and the experience as a whole is diminished.
With an ad blocker, you selectively block the javascript you don't like but that the operators rely on to bring in revenue, while still getting the otherwise 'full' experience.
If sourceforge went under, do you think I'd be unable to get the source to tmux?
Since obviously I'd still be able to get tmux, what value is sourceforge actually providing me? They might be providing tmux developers some value, but they aren't providing any value to me.
I value what these sites are giving me, but not enough to put up with ads. If adblock didn't exist I'd probably visit places like sf or youtube a lot less.
If you're developing anything for the web that might involve advertising, and even certain things that don't, it makes it hard to test, especially if you continually forget to disable your ad blocker. (I'm only being marginally facetious; I worked with a developer who refused to accept that his ad blocker prevented him from seeing issues with Omniture - now Site Catalyst - eating mouse clicks.)
A ponzu scheme is a fraudulent investment operation where the operator pays returns to its investors from citrus-flavoured soy sauce sent to the operators by new investors.
Perhaps no advantage, but it's a good thing. As in the CPU market, there are Intel, AMD, even another architecture alternatives, eg. ARM. It's just an analogy. :-)
Does anyone who would be downloading tmux not use an ad blocker? Because if so, consider me shocked. I mean, not that the ads aren't still a moral concern, but from a practical standpoint it doesn't seem like a big deal. I didn't even realize Sourceforge still had ads...
For those who are just getting started with tmux: I advise looking around others' .tmux.conf files for some sensible settings. Like Vim, Tmux ships with a lot of powerful features disabled by default.
My absolute favorite has to be binding a hotkey to opening URLs in the current window [0]. See [1] for a small demo I just recorded.
As long as the comment is useful and contributes, I think it's fair game. This definitely qualifies. That said, if it's not free, I personally would prefer that be mentioned, (and at the same time a link to a free sample chapter or equivalent if it exists would be useful).
One tweak I can't live without is having the same key bindings to seamlessly switch between tmux panes and Vim split windows. (https://gist.github.com/mislav/5189704)
My prefix key is Ctrl-Space. It's very convenient to press on the keyboard, I'm surprised to not see it used more widely (maybe because it's commonly bound to some OS utilities?).
> One tweak I can't live without is having the same key bindings to seamlessly switch between tmux panes and Vim split windows.
YES, THIS! Setting up directional pane navigation to work with both tmux and vim panes as first-class entities was a huge workflow boon for me as well. It was a significant change that helped kick my setup over into vim+tmux+zsh as IDE vs. merely a collection of separate parts.
It's worth noting that some relevant bits of @mislav's stuff has been packaged up nicely as a Vim plugin:
I also just noted that @tarruda (of neovim fame) chimed in on @mislav's gist with his own independently created version of the Vim-side of things. It looks worth comparing some of the implementation details from @tarruda's work, he's done some stuff to eliminate redraws in Vim, etc.
> It was a significant change that helped kick my setup over into vim+tmux+zsh as IDE vs. merely a collection of separate parts.
Same thing here :) I also set `tmux attach -t base || tmux new -s base` as my start command in iTerm which kind of forces me to use tmux windows/panes/sessions instead of iTerm tabs. It took a while to lose the habit of hitting `cmd-t` but was definitely worth it.
The thing that sucks now is that I'm really not sure which parts of my environment can be optimised further other than learning new Vim commands :)
Heh, I have something similar, with a tmux session-start script[1] that's the first thing run by my default iTerm windows. It displays and lets me select from existing sessions via prompt tab completion. Or I can just enter a new session name at the prompt.
Or used directly from a normal command line (with zsh completion [2]) as:
mux <session_name>
Apologies to tmuxinator users for conflicting with 'mux'; obviously feel free to rename it. This is really just a part of my personal setup vs. a formally published utility, and I don't use tmuxinator.
Honest question: Is there any benefit of using tmux over a proper tiling window manager? Or, why would I want to delegate some of the window manager tasks to a terminal emulator?
I use both a tiling window manager (xmonad) and tmux. The main reason I started using tmux was to do pair programming sharing the same terminal via ssh. If you pair program and have never tried this before, I highly recommend trying it. I live in Japan and even pair with people in London using tmux and vim. It's the next best thing to being there.
After I started getting used to using tmux, I found that my workflow naturally separated between things I'm doing on my terminal and things that require X (like my browser). These days I use a separate workspace for X apps and terminal (occasionally moving them around).
To make my life easy, I've added xmonad-like key bindings and window layout to tmux. Since other people are sharing:
I often work while travelling and when I'm on the road I often don't bother cranking up X -- just work in the Linux console. Using tmux I barely notice a difference in my workflow and it helps extend the battery.
For me it's having two different terminals connected to same tmux session. I use tiling window manager and work on two monitors. Sometimes there is some stuff that I'm working on on my main monitor but I want to have quick look at the terminal. Because I have two terminals opened on both monitors I can just switch to the other one, press ctrl+f(my prefix)+number and have exactly same window as in my main terminal.
For anyone wondering you can achieve above by typing tmux new-session -t and giving it number/name of your current session.
Also there are minor things that are nice. Like if you need to open another terminal instance in the same directory as you're currently in.
I use <C-s> for my local machine, and I make the servers I login to use <C-a>. I bind the caps-lock key to ctrl, so it works out pretty well, and lets me work with both local and remote contexts at the same time fairly nicely.
> My absolute favorite has to be binding a hotkey to opening URLs in the current window.
I suppose this stops working if you SSH into some box and run tmux there? I've implemented something similar, but as an urxvt plugin instead, which avoids that limitation: http://www.cs.helsinki.fi/u/tmtynkky/urxvt.png (Once Alt-O is pressed, the hotkeys with the red background appear next to each link; pressing the hotkey opens the link in browser and copying to clipboard is also possible)
For a while I ran a setup where I did all of my work in a local tmux session, but part of this work involved SSH-ing and attaching to a screen session.
When using both, especially nested, I found it beneficial to have a different leader for each.
I also use <^-a> to go to the start of the line, so I'd miss that.
Does anyone else wish tmux were modal like vim, ie. without a "leader" key? My conf file has a ton of custom key bindings for window / pane management, and I'd love for them to go away or become simplified by simply dropping into a "window management mode". Likewise, I'd like the command mode to stay open until I close it. I have some scripted hacks to do this, but it's nowhere near what I'd expect from true modality.
One of these days I guess I could get around to writing a patch. This single feature is probably my most wanted for any software at the moment.
Yes! Probably my biggest workflow pipe dream since getting some fluency in vim is to be able to drop into an "outside mode". I've cobbled something vaguely modal together for bspwm with abuse of shkd, so a lot of the binds map similarly, but like your solution it's far from ideal.
As for "Why would you want this?" For me, the straightforward answer is "modes are modular". A core concept in vim is that your input can be thought of as a string describing the edit you wish to make, and modes help me keep that manageable in my head: I can first think about the mode I plan to enter, and then separately what I plan to do under the constraints of that mode. It's a little hard to explain, and I'm sure acolytes of other paradigms have their own philosophies, but it fits in really well to my workflow.
It's a subtle thing in the limited world of text editing, but I definitely miss the semantics whenever I leave it, whether to a terminal or a browser or whatever. So for me, it comes down to wanting to bring the cost of task switching closer to what it is in the editor.
"It's a little hard to explain, and I'm sure acolytes of other paradigms have their own philosophies"
Yes, yes they do[1]. Some people (not me) are vehemently, religiously opposed to "modes":
"To promote his preference, as of 2010, Tesler equipped his Subaru automobile with a personalized California license plate with the license number "NO MODES". Along with others, he has also been using the phrase "Don't Mode Me In" for years, as a rally cry to eliminate or reduce modes."
Maybe because I'm an emacs user, I find it pretty intuitive. As a ratpoison/conkeror/emacs/tmux user I often find myself juggling at least 4 sets of prefix keys. It works surprisingly well, I just made sure they are in different places on the keyboard, so that I don't mix them up.
Odd. I'd consider myself a 'power user', but I hardly ever find I have that need. Could you describe what you do when you're entering several command-mode lines in succession?
it would probably be a relatively easy change to make this happen with key tables (which are in git), you would only need to change it so there is a way to permanently enter a key table (at the moment the key table is only entered until a command is run from it)
I recently discovered Tmux after years of using GNU Screen. I love it. It feels much easier to use and more intuitive, easier to script. Also integration with terminal emulators such as iTerm2 on OS X or Byobu on Linux is fantastic. Tmux earned a place in my list of favorite daily used tools.
The biggest advantage of tmux over screen is its ability to automatically resize based on the smaller terminal connected to it. I know there are a lot other advantages, but this in itself was a game changer for me.
Congrats to the Tmux team for a great open source tool. Its sad that HN decided to take this moment to talk about sourceforge and not the product announcement.
- its old. A stable version is on every distro. Trying to start a screen session is more likely to succeed on any given box than a tmux session. I see my friends wrestle with their tmux setup being more recent on one box than another and their nested sessions get screwed up. I never have any issue.
- I know it, and for my simple use it does everything perfectly. I can split panes, I can detach and come back, I can nest sessions.
- screen can attach to serial terminals.
What's the killer feature of tmux that I'm missing out on?
Try out Byobu. It's built on tmux, and it's nicer to use than screen, I find. Stupid name, but has some conveniences. Mostly I just use F2 to create a parallel terminal and F3/4 to cycle through them.
Does tmux still have no flow control? Just compare how tmux locks up when you `tar xfv linux-4.0.tar.xz` and screen doesn't. None of the knobs to control output throttling helped. How do you get around this problem?
That's a different flow control than what I'm talking about. tmux is just overwhelmed and cannot keep up with the output from tar whereas screen takes care of it and still responds to user input. Frankly I'm amazed there's only one or two posts about this on the internet as there's more than the pathological linux tarball extract where this problem will lock up tmux.
yes, this sucks but i have never myself been able to find a reliable case where screen reacts any better than tmux (for example, both behave similarly with yes(1))
the c0-* stuff is poor (i'm tempted to remove it) but it is not an easy problem to solve, people want tmux to be fast, except when they don't. it's also tricky remotely where ssh and the network stack are buffering too
The main thing that I wish I could have in tmux is the ability to disable other sessions attached to the current terminal without outright detaching them. I intend to go back to that other machine at some point, I just don't want its tiny screen making my current session tiny for no reason.
Maybe this is actually possible already and I just haven't found it?
Say you want to attach to session 0 (use `tmux list-sessions` to see available sessions).
A trick I've found is not attaching to that session, but starting a new session sharing all underlying windows. The model in tmux is [session]->[windows]->[panes], but something I did not realize until recently is that [session] can be multiple.
So rather than `tmux attach -t 0` use `tmux new-session -t 0`, allowing you to interact with the same windows without disturbing the other session.
Is this a feature in 2.0? It doesn't seem to work for me - I still see a large part of my terminal window filled with the dots, since the other session's terminal window is much smaller.
Ah, I forgot to mention: the resize -if the terminal-window is smaller- will still happen, but as long as the two sessions are operating on a different window they can be of different size.
Terminal A: 300x10 lines (long across, but short)
Terminal B: 120x30 lines (standard new terminal size)
I have a tmux session running in A; I open terminal B, and attach to it with -new-session. My first pane is trimmed to the height of Terminal A.
If I do prefix-c (create new pane), the new pane is now the size of Terminal B - hurray!
But if I open Terminal C, which is yet another size, and attach to my existing session, it resizes every pane in Terminal B to the size of Terminal C; and when I disconnect from Terminal C, those panes do not appear to switch back to what they now should be, unconstrained by Terminal C.
(If I didn't explain this clearly, I can provide some screenshots later.)
I don't have any issue with the session itself being shared. It's actually the desired behaviour almost all the time. I just don't want to be dependent on the frame sizing of a terminal no one's even looking at.
jbnicolai's method kinda solves this for me. The upshot is the set of windows is mirrored between both clients, but they can each be looking at different windows. You still have a problem if the other client is looking at the same window that you're on, though.
Would doing <bind>D (note the casing) help? It will list all the currently attached sessions and allow you to remotely disconnect them. I use it when I forget to detach at home and I'm at work or vice versa.
That's exactly what I do. First of all, it's annoying that I have to go and choose each one to detach it. Second, I usually invoke tmux directly with mosh or ssh -t, so detaching also disconnects them, which I don't really want.
I basically want an untouched session to go into a screensaver mode where it no longer controls the terminal size.
It's certainly not the end of the world to detach them, but I'd rather not. And detaching before I leave a session is just busywork.
I've only recently discovered tmux (feels ashamed).
It's fantastic. The only thing I miss is just a sprinkle of mouse interaction. Moving around with the keys is easy enough of course but if you have a terminal in an otherwise desktop environment, it would be really nice to just be able to "click" in a pane to focus it.
If you check the tmux manpage and search for 'mouse', there's a whole bunch of mouse-enabling options; you might as well turn them all on -- except for "mouse-utf8", which is a compatibility option that can potentially screw things up.
The downside to enabling mouse support in tmux is that it disables mouse support in the outer terminal (the one tmux is running inside). If you select text in tmux, it will go to the tmux clipboard instead of your system clipboard. You can get around that by holding shift before selecting text, but some people get annoyed by the extra action required.
Learned Tmux a few weeks ago and use it every day now. You can enable Mouse Mode, on Macs you can install extra Tmux features, and iTerm2 has mouse mode built in.
They broke features between releases before without increasing the major version number.
While trying to use the same .tmux.conf over multiple versions of tmux 1.x, I often had to adapt the config file to settings being renamed or just going away without a deprecation warning beforehand.
Incompatible Changes
====================
* The choose-list command has been removed.
* 'terminal-overrides' is now a server option, not a session option.
* 'message-limit' is now a server option, not a session option.
* 'monitor-content' option has been removed.
* 'pane_start_path' option has been removed.
* The "info" mechanism which used to (for some commands) provide feedback
has been removed, and like other commands, they now produce nothing on
success.
I tried the same patch on 1.9a but couldn't get it to work (tmux built fine but no dice with 24 bit colours). Very curious to hear if it works with 2.0.
a couple of people have asked me about how true colour should look but none have sent code so far, it's not a very interesting feature to me so it'll need someone who cares about it to do it
Actually, I already provide this in the release notes. A PROTOCOL_VERSION bump means restarting tmux. We didn't do this between 1.9a -> 2.0, hence why it wasn't mentioned. Look at the release notes for 1.9, you'll see it was mentioned there. Simples.
This is great news! But I've started to use Tmux less after being REALLY into it. I've slowly replaced it with a tiling window manager because I've noticed my ncurses and curses programs don't draw right in Tmux. I've found a couple work arounds, like using the TERM env var, but it doesn't work for everything.
I'm wondering how others have solved this problem, if they have at all.
I run into the opposite. St doesn't play well with n/curses in my experience (mostly corrupt characters on display), and the easiest solution I've seen is to run these programs in a Tmux session. I use Tmux all the time anyway, so this doesn't add any extra overhead for me (mental or system).
I wish it was possible to have screen-like bindings that don't require explicitly defining them all so that you don't have to unpress Ctrl each time. In screen you can press C-a c quickly but for that to work in tmux you have to add this:
Tried that before and with 2.0 but it doesn't work. You still have to release both 'Ctrl' and 'a' before pressing 'c'. In screen you don't have to and chaining works comfortably.
I don't see anything about it, so I'm assuming there's still no support for "true" (24 bit) colour? Would really love if they added that, since Neovim now supports it.
Does anyone have Tmux 2.0 working alongside Tmuxinator? I know the project only claims support for 1.8, but I've been using it alongside 1.9 (mostly without issue) for many months.
True enough. The session restore still stands. I know tmuxinator exists, but as a personal preference I'd prefer it in-built/native. Also to save state, which I'd expect is asking too much.
what do you mean session restore? we could restore the basic layout of sessions, windows, panes but we couldn't restore what was run in them (and it would be dangerous to try)
I'm looking forward to the combination of Tmux and Neovim. Both (will) support detached/shared sessions, both are scriptable/configurable, both can be driven by a remote process. I believe with Tmux and Neovim you could put together anything from a simple test/editing environment to a full-blown IDE.
You're not doing a good sell for Emacs. People choose vi because of modal editing, not because they are ignorant of the Emacs feature set. You should at least say, "If you like vim for its modal editing features, but would also like support for session detachment along with a host of other stuff, you might find Spacemacs, or emacs with evil mode setup, a good alternative. There's a little bit of a learning curve, but it may be less than you think depending on how customized your vim setup is."
As someone who switched a few weeks ago, I would find that a much more intriguing breadcrumb trail.
> People choose vi because of modal editing, not because they are ignorant of the Emacs feature set.
Exactly this. I had used Emacs for many, many years and finally decided to give Vim a go... and never looked back. Emacs is very powerful, and while the Elisp infrastructure has distinct advantages over Vimscript, the compositional richness of Vim's editing model is amazing. I don't have to drop to scripting because Vim gives me the power I need more quickly and easily.
So, that said, have you tried out spacemacs? It's really, really good. It's not a zero cost switch, but I really think it makes the good things about vim work in emacs.
Curious that you chose to switch editor outright rather than just install some more modal package, after all those years. I chouse the former as the path of least resistance.
That choice was actually motivated for other reasons rather than just the modal workflow. The biggest of which was that (at the time) I found I had to really struggle to get Emacs and its ecosystem to play nicely with a highly project-centric workflow. I had used old vi regularly starting decades ago, and thus had basic usage burned in. E.g. I never understood these seemingly lame "minimal system editors" that some distros use vs. the old sysadmin standard of a minimal vi implementation (vs. full vim, emacs, etc.)
But it was becoming clear that something else was going on with modern vim, so after testing the waters a bit for my needs, I decided to go all-in as much as an ecosystem research project as anything else.
Last time I tried ansi-term and friends (not that long ago), it was very slow and struggled rendering my fairly vanilla (by some people's standards) shell prompt. Neovim's terminal emulation, by contrast, is a very great deal faster and can run Neovim inside itself with no discernible issues.
That's not actually a feature that was listed (because it's a pretty useless feature - I don't know anyone who actually uses ansi-term rather than screen/tmux, M-x shell or M-x eshell, and likewise it's not going to be useful for neovim to embed a terminal, the useful part is integration.)
Emacs is great and I know lots of people who love evil mode. I prefer vim because it comes pre-installed - good for ops. Many of my tools have embedded Lua, so it's great that I can exercise my Lua skills with Neovim. None of my other tools embeds elisp, so for me, elisp is a dead-end.
Neovim won't be preinstalled for a long time. Possibly it never will be. Also, writing Elisp is not far from writing Guile Scheme, and there are many tools that embed Guile.
Yeah but - I like Neovim's msgpack-api, and the built-in terminal emulation. On the Neovim roadmap: attach/detach from a background session, multiple screens with different sizes.
What is the advantage of using Sourceforge these days when github and bitbucket are free for open source?