flathub/org.gnu.emacs

Missing binaries for Doom Emacs

Closed this issue · 2 comments

Hi, thanks for org.gnu.emacs !

Here is the output of doom doctor :

$ bin/doom doctor
The doctor will see you now...

> Checking your Emacs version...
> Checking for Emacs config conflicts...
> Checking for private config conflicts...
> Checking for stale elc files...
> Checking Doom Emacs...
  ✓ Initialized Doom Emacs 2.0.9
  ✓ Detected 0 modules
  ✓ Detected 19 packages
  > Checking Doom core for irregularities...
    x Couldn't find the `rg' binary; this a hard dependecy for Doom, file searches may not work at all
    ! Couldn't find the `fd' binary; project file searches will be slightly slower
    Found font material-design-icons.ttf
    Found font weathericons.ttf
    Found font octicons.ttf
    Found font fontawesome.ttf
    Found font file-icons.ttf
    Found font all-the-icons.ttf
  > Checking for stale elc files in your DOOMDIR...
  > Checking your enabled modules...


There are 1 errors!
There are 1 warnings!
✓ Finished! (1.1357s)

Would you mind to embed ripgrep and fd in this app ?

muep commented

Thank you for the request.

At this point, I don't think it is sustainable to add tools required by each and every Emacs package. Even more so with tools like fd and rg, which would add an entirely new language ecosystem into the dependencies of the flatpak.

At least for me, the aim is not to cover all use cases that can be served by an usual non-sandboxed Emacs, because the amount of integration work would be enormous. With more people maintaining the flatpak it would be possible and with some planning even sensible, but it might start to resemble the work of assembling a small Linux distribution. What might be more reasonable goal would be to try to focus on and cover all things that might be required by a stock Emacs without extensions, but even that would require integrating quite a few things.

To rehash - while the flatpak here does provide a simple way to get an up-to-date copy of Emacs, the isolated runtime and sandbox do not fit well with how Emacs is often used to interact with all kinds of stuff. Many other development environments suffer from the same problems, but in Emacs' case it is perhaps even more common that extensions make use of external tools that are simply hoped to be present.

To work around these limitations in your case, I would suggest compiling fd and rg with cargo and placing the binaries to some location that is not hidden by the sandbox.

Sorry for not being able to address this with more than the workaround suggestion.

That's fair. Thanks for the answer.