Except on airplanes.
I sold my desktop, and now use a cheap £200 garbage laptop as a thin-client to my machine. Not only do I get incredible compile performance due to being able to use 16 core Xeon's, but I am not tied to any desktop.
I can whip out my phone and pop open a tmux session from anywhere, in an emergency I can hop onto a friends computer and thanks to SSH 2FA fearlessly login to my dev system with my full environment that I never have to close.
At this point, I would actively avoid jobs that wouldn't let me work this way. Currently got a sweet remote gig and I'm going to fly to Spain next week and spend a couple of weeks coding on the beach with my 3G tethered laptop.
Edit: Just to clarify, I don't need to work in an IDE or use any Windows software that I couldn't tunnel over X. So it might not work for everyone. Just wanted to give an example of it working out great for someone.
Some people are using kakoune with fzf, using tmux to open a split, which is very simple to implement with fzf-tmux. Interacting with Kakoune interface ought to be possible but possibly more tricky.
But again, the stuff you have in this editor is absolutely fantastic, really, I can't say that enough. I just personally find kak less flexible than an already inflexible vim so I couldn't stay with it.
If you have a way to do the fzf example though I'd be curious to see how you do it.
Glad to hear you liked the interaction model, may I ask you what kind of options were missing for you ?
The extension model is, I agree, unorthodox, but I think it does work reasonably well (the file you linked manage to provide asynchrounous clang completion and syntastic like diagnostics using it), and keeps things simple. Note that we try really hard only to depends on POSIX tools, so the scripts are actually targeting POSIX shell.
The rational behind this extension model can be found there: https://github.com/mawww/kakoune/blob/master/doc/design.asci...
And a more in depth explanation on how to use it is there: https://github.com/mawww/kakoune/blob/master/doc/interfacing...
> We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them).
I don't really want to switch to an editor where missing options might have to be justified. I'm not knocking your work, it's really good, and my complaint applies to vim as well. But if I can't implement something myself as an add-on (which I definitely have more power to do in vim) and have to wait for it to be patched and released in your release cycle I'd rather just try and implement your features in vim and keep the customisability.
Having said that I could be wrong and maybe the plugin system is more powerful than I thought. But as an example, I have a 5 line function letting me have ctrl-p like functionality backed by fzf in vim. I can't figure out how I would do that in kakoune at all.
However I couldn't stick with it for two reasons. The first is when I went to figure out how to customise it, I found that the customisation is essentially vim like but weaker. Everything is hardcoded like it would be in vim but with less options. If you're used to Emacs insane customization, this is the other end of the spectrum. The stuff that IS customisable works by executing embedded bash scripts[1]!? You can only embed these in specific hooks and places, so it's really limited, and platform specific. Install this on a system missing a bash feature someone is using and who knows how it'll behave.
Basically, the features implemented are gorgeous, but past that I can't stick with it. Just going to consider trying to port the selection based movements to a vim plugin but I think it'll be a challenge.
1: https://github.com/mawww/kakoune/blob/master/rc/clang.kak
Typing accented characters is far easier in Spanish with a Spanish layout, that we all grow up with. The software shouldn't just ignore half the planet on the basis of "use English".
Rust people, is there a way to tell the compiler that each thread gets its own elements? Do you really have to either (unnecessarily) add a lock or reach for unsafe?