Snap package for Kakoune

I created basic Snap package for Kakoune. It’s avaliabe on snap branch at my GH.

Disclaimer:

  • I’m not big fan of Snaps. They are supported on all major distributions tho. That is a lot of potential users who could use Kakoune without compiling it manually.
  • It needs some testing. I haven’t created snap before so I don’t know If I packaged it correctly.
  • For now it needs to be built manually. I guess Snaps could be build on Travis and uploaded to GH releases. I’m not sure how Snap store submission process looks like (It’s a classic Snap so it would require manual verification), also I’m not sure if it’s worth a hassle.

How to build and install:

snapcraft
snap install --classic --dangerous kakoune_v2019.01.20_amd64.snap
sudo snap alias kakoune kak

You can also use pre-build snap from my releases (if you don’t mind running random binaries from Internet :V )

1 Like

What about AppImage or Flatpack? I don’t know much about these package systems, since I don’t need them, but quick look at this table makes me think that AppImage is more appropriate format. Maybe I’m wrong though.

I’v never managed to create Appimage, I can give it a try. I’m not sure how well they work for CLI apps, I’v seen only GUI appimages so far.

Wow, thanks @TeddyDD, I am super-excited about this because it scratches my pain point!

Let me know if it works :wink:

I added build from master branch to releases. Still trying to figure out how to build snaps on Travis (without Ubuntu store integration)

Okay I give up - Snaps are pile of garbage, builds break randomly, documentation is incomplete and often out of sync with actual state of things and I don’t feel like it’s worth the trouble.

1 Like

Sorry to hear that, yeah, it is rough stuff.

In case anybody is interested, I build a static binary, install it in to a subfolder in $HOME. I can rsync this folder to any linux host and run kakoune with all the plugins and everything. For me using kakoune means that I quickly loose my vim skills, so if I need an editor on a remote for longer periods I switch to kakoune.

https://git.io/fjQAh

1 Like

This is so true.

I’m using sshfs for that. Basically mounting remote server to some directory, that using local installation of any editor to work with those files. But I think it would be nice if Kakoune had something like Emacs TRAMP

I have had terrible experience with sshfs and similar. I tend to work on mid-sized projects (10s of thousands of files) and whenever I do something like ripgrep or run certain tools, I always get into a weird place with lag and frustration.

Do you have any tricks for making this work well, more aggressive caching, etc?

I have no such problems, (un)?fortunately. I guess that’s because all servers that I mount usually are in local network.

I use sshfs as well. It’s easier than carry my config around :wink:

I use syncthing for my config files, doesn’t work too well with large git projects though.

I find it much easier to carry my config around with me.

sshfs is not working well for me, probably all the plugins do too much on the filesystem. In that case I use a script I call fsevdo:

#!/bin/dash
while inotifywait -q -r -e create,modify,delete .; do
    "$@"
done

And I then use rsync with fsevdo:

cd myproj
fsevdo rsync -a --delete  ../myproj/ me@myhost:myproj/

Every time I save the project is synced to the host.

I will have to give this a spin! Sshfs is virtually useless for me unfortunately.