I just moved to win10 platform this month (Feb 2019) and using the wsl/ubuntu. I found ‘apt-get’ did not install the same kakoune experience I had been used to on the osx. I used homebrew package manager for linux which solved my kakoune problems and am now back to normal with little effort.
As I read this thread on my way to eventually finding a solution thought it might help others posting it here.
If you don’t mind, I would like to ask you, what kind of problems/differences you had during the usage of kakoune installed with apt compared to the one installed with brew?
It was only late last year that the Debian package for Kakoune started getting updated regularly. Even the most recent Ubuntu release has a Kakoune from 2016, but the next release (in April) should be up-to-date.
The console team at Microsoft have put together a blog on the future direction of ‘Windows Command-Line applications’. And quote ‘The new Win32 ConPTY API provides a mechanism that is similar to the POSIX PTY model’.
Link: Introducing the Windows Pseudo Console (ConPTY) API
With a github repo “EchoCon” ConPTY Sample App.
Link: EchoCon
The terminal IO (which ConPTY would help with) is an easy problem, Kakoune already has user interfaces abstracted away, so implementing a win32 based UI (with actual windows widgets) is doable and might be relatively easy to write.
The hard problem for native windows support is that the interaction/extension model of Kakoune expects a posix shell and the basic posix tools to be available, most interaction of Kakoune with the external world starts by it forking a shell process (I am thinking of |command<ret> and %sh{...}). I suspect we can get relatively far if there was (did not check if that exists) a windows native busybox, then its just a matter of tweaking ShellManager to use win32 api to run busybox in shell mode with the relevant arguments and redirections.
Yeesss of course…for those who are thinking along the lines of IO redirection to win32 from wsl Windows and Ubuntu Interoperability another great blog post from Microsoft.
The continuous development of the wsl on win10 and with Terminus I am enjoying an uninterrupted experience with Kakoune. The new April 2019 windows patch will add file sharing between the mediums.
So I think I will head over to @Screwtapello@andreyorst help on kakoune documentation (racket/scribble just putting it out there have not looked if it is possible yet, docs::OOP->Functional).
Make more sense @andreyorst we back to playing nice.
Don’t mind me I am on a new badge frenzy emoji time .
Quick note: you should not use surround with back-tics on links. Plain [text](url) is enough to insert links.
Excuse me, but I simply can’t understand the message here (why me? I’m maintaining a plugin manager and several plugins for Kakoune, not the documentation)
I just posted into the thread request help on Kakoune documentation where you are a participant, along with others, perhaps its a mistake or just merely a laps in judgement. More coffee or quieter music take your pick.
I’m selfishly trying to revive this to know what is the go-to method of having Kakoune on Windows these days. I’m in love with the editor but unfortunately, there are certain industry like mine (gamedev) where Windows is the standard.
I’d love to be able to use it everywhere without too much hassle and requirements (of installing Unix-like subsystems, a lot of other software/dependencies, etc, which you might not be able to do depending on the place). And I was wondering if there have been any advancements on getting Kakoune running well on Windows or what is the current method people recommend or tend to use
Please help me and my buddies not have to go to gvim or nvim!!!
I think a compelling argument could be made to have a Kakoune that is backed by Powershell Core. Open source (MIT), cross platform, powerful, and modern. If added as an additional target (like we have for windowing operations) it could be immensely powerful. A friend of mine privately started work down this path but it fizzled out as it was very hard.
Back when I was in the gamedev industry, I used either cygwin or WSL to run Kakoune. Having a posix enviornment is a necessity for both Kakoune and myself.
Cygwin did a pretty good job most of the time, except for fork heavy plugins that tended to be a bit slugish.
WSL was better in this regard, and I progressively ended up hiding windows behind a X11 server with a nice window manager running…
Building was unfortunately not a very nice story, as I still had to run visual studio in the background to compile the project, hopefully it got easier to trigger a VS compilation from the command line.
Kakoune being even more dependend on a posix environement underneath it than vim did, a native port is not really planed, hopefully cygwin or WSL are good enough for your use case.
I’m on Windows 10, and with the release of WSL2, I moved from a gVim-based setup on Windows to a Kakoune based setup using Ubuntu 20.04 in WSL2, which I access through the new Windows Terminal.
When figuring out how to do things, I just pretend I’m on Ubuntu 20.04, and things work accordingly. Ubuntu wouldn’t be my first choice distro, but being able to run a fully linux-based development setup in Windows is already a pretty remarkable thing.
So far I’ve only ran into 2 issues relating to the Windows integration.
First, while you can access your entire Windows file system from a linux shell running in WSL2, it’s pretty slow. However, I haven’t noticed any performance issues as long as I stick to working with files on the linux side. (So clone any project repos into the Linux file system rather than attempting to access them from a location on the windows side).
Second, I’m using Tmux to enable multi-window functionality. The problem I’m having is that when opening files in a side-by-side split view, the rendering gets all messed up as I change things. I think this has to do with Windows Terminal, but am not sure. As a work around, I open file splits in Windows Terminal panes instead of Tmux. However, I still open kak instances in Tmux to enable things like temporary fzf search windows. Alternatively, I found it easy to set up an X server with MobaXterm in Windows to run GUI apps from WSL2. This would make it possible to use something like i3 for a window manager, circumventing both Windows Terminal and Tmux.
Overall, if you’re stuck needing to work in Windows 10 for some things, but want to use Kakoune and other Linux command line tools, doing so via WSL2 is a big win.
.
to know what is the go-to method of having Kakoune on Windows these days. I’m in love with the editor but unfortunately, there are certain industry like mine (gamedev) where Windows is the standard.
