Struggling to get help installing a working Helix Editor On Debian (For C/C++ programming.) Can anyone help me?

Z

ZennMystic

Member
Joined
Jul 7, 2021
Messages
42
Reaction score
12
Credits
388
So I wanted to install and use Helix editor on my Debian 12 OS.

I have read a few ways to install it:

#1 I could install cargo and use that. But I have no intention of using/programming in Rust at all other then using Helix.
#2 install using ppa. But I read this is a very bad idea under Debian and does not always work or work well.
#3 Flatpak install.

I did the flatpak install as it was something I had installed already and was easy enough to use to install apps. But then I run into sandbox issue as it need to use clangd, which is installed and in my path but not seen by helix due to sandbox.
I wish flatpak said something to me about what it was blocking and do I want to allow. I like Flatpak but hate it blocks in secret.

I read I need to use SDK extensions like llvm16? But then what? I have no idea beyond what I have said above... Everywhere seems to use native install and everything just works... I also admit to not understanding a lot of what I read and I'm looking for help from someone who has gone through the setup...

Yea am sure it is obvious I'm a noob to this... I know some may think how dumb are you.. But I just do not understand a lot of the install process of Helix.
 


Sadly the main Debian repositories don't currently have a native debian package for helix, but hopefully one will be added at some point in the future.

Perhaps you should try using the appimage instead? I don't think appimages use any kind of sandboxing by default (like flatpaks and snapcraft snaps do). Sandboxing with appimages is optional, I think people usually use 3rd party sanboxing solutions like firejail. So without using a 3rd party sandboxing solution, the appimage of Helix should just run and be able to access the system as normal. So it should be able to access external things like clangd.

Another thing you could try is adding the Ubuntu PPA, but that;s generally not a good idea with Debian - especially if you're running Debian stable - because stable uses slightly older versions of libraries. Whereas Ubuntu generally uses packages from Debian testing and unstable. So if the PPA requires newer versions of libraries that Debian stable doesn't currently have, it will cause dependency issues.
PPA's are supported in Debian and can be used, but only if the contents of the PPA are compatible with the version of Debian you have installed. But most PPA's are Ubuntu-centric and will only work on Ubuntu, or Ubuntu derived distros.

The only other option would be to build and install from source. This is usually my preferred, go-to solution. I'm not a fan of snapcraft and flatpak - they are the absolute worst of the so-called "universal" packaging solutions for Linux. Appimage is a lesser evil in my eyes - it doesn't require a ton of additional system plumbing in order to work. And sandboxing is optional. There may be some way of getting these sandboxed flatpaks and snaps to integrate with the wider system and to use external tools, but I'm not familiar enough with them. I was an early adopter of flatpak and snapcraft/snaps. But I was also quick to abandon them.

As a long-time Debian user - if pre-built, native Debian packages are not available to me. I always prefer to build and install from source. That's the next best thing to having a native package IMO.

But I'm a professional software developer, so I don't mind installing tons of development tools and libraries on my machines. And I'm comfortable building and installing from soruce. Sometimes there are a few extra hoops to jump through, but most software isn't very difficult to build/install.

However, there have been a few occasions where I've just downloaded and used an appimage. Usually for quick, convenience until I have time to grab a copy of source code and to build and install.

So yeah..... Appimage, or build from source would be my main two choices in this situation. But you could also try installing via the Ubuntu PPA (but it may cause dependency related issues on your Debian install if it's Ubuntu-centric).
 
vs2-free-users said:
I know this is not a really solution but you can use
geany

this is a lightweight code editor that runs on every system is use without any problem.
Click to expand...

Thank you. I have herd of it.. I will look into this also for completeness. Thank for responding. I did not think or expect I was going to Go one. So I appropriate that people took the time.
 
JasKinasis said:
Sadly the main Debian repositories don't currently have a native debian package for helix, but hopefully one will be added at some point in the future.

Perhaps you should try using the appimage instead? I don't think appimages use any kind of sandboxing by default (like flatpaks and snapcraft snaps do). Sandboxing with appimages is optional, I think people usually use 3rd party sanboxing solutions like firejail. So without using a 3rd party sandboxing solution, the appimage of Helix should just run and be able to access the system as normal. So it should be able to access external things like clangd.

Another thing you could try is adding the Ubuntu PPA, but that;s generally not a good idea with Debian - especially if you're running Debian stable - because stable uses slightly older versions of libraries. Whereas Ubuntu generally uses packages from Debian testing and unstable. So if the PPA requires newer versions of libraries that Debian stable doesn't currently have, it will cause dependency issues.
PPA's are supported in Debian and can be used, but only if the contents of the PPA are compatible with the version of Debian you have installed. But most PPA's are Ubuntu-centric and will only work on Ubuntu, or Ubuntu derived distros.

The only other option would be to build and install from source. This is usually my preferred, go-to solution. I'm not a fan of snapcraft and flatpak - they are the absolute worst of the so-called "universal" packaging solutions for Linux. Appimage is a lesser evil in my eyes - it doesn't require a ton of additional system plumbing in order to work. And sandboxing is optional. There may be some way of getting these sandboxed flatpaks and snaps to integrate with the wider system and to use external tools, but I'm not familiar enough with them. I was an early adopter of flatpak and snapcraft/snaps. But I was also quick to abandon them.

As a long-time Debian user - if pre-built, native Debian packages are not available to me. I always prefer to build and install from source. That's the next best thing to having a native package IMO.

But I'm a professional software developer, so I don't mind installing tons of development tools and libraries on my machines. And I'm comfortable building and installing from soruce. Sometimes there are a few extra hoops to jump through, but most software isn't very difficult to build/install.

However, there have been a few occasions where I've just downloaded and used an appimage. Usually for quick, convenience until I have time to grab a copy of source code and to build and install.

So yeah..... Appimage, or build from source would be my main two choices in this situation. But you could also try installing via the Ubuntu PPA (but it may cause dependency related issues on your Debian install if it's Ubuntu-centric).
Click to expand...

Tank you for the response...

I do not mind building from sources... But I have only done it twice... once was when I wanted to try NeoVim. But the institutions I found were very very clear and was part of an over all set up....
I have not found the same with Helix... So again if there is some I could contact... That could walk me through the process. I am more than happy to give it a go.

Yes Appimage is an option...

I also found that Nix? Could be an option as well.. I came across a YouTube video by Titus Tech about... Looks like it might be even better to use than Flatpak?
 
Why not just do:
"Download pre-built binaries from the GitHub Releases page. Add the binary to your system's $PATH to use it from the command line."

either stick it in /.local/bin/ or in /usr/local/bin/
either way works.
 
You must log in or register to reply here.

Staff online

Members online

Total: 912 (members: 4, guests: 908)

Latest posts

Top