no gtags or cscope

[pid42]

The app does not have gtags or cscope available, and, it can t use the one installed because of the sandbox.

[zoglesby]

This is a very basic copy of Emacs that includes nothing more than Emacs itself and what is included in the flathub copy of the freedesktop.org sdk, if you need more than that I recommend forking this and building it yourself.

That is what I am doing for my own copy as well. (https://zach.oglesby.co/pages/flatpak-repo)

[muep]

Currently emacs on flathub does not bundle anything extra beyond using an SDK as the runtime to get a fairly large collection of development tools.

It is not entirely out of question that something could eventually be bundled. However, given how vast the set of different use cases that emacs can be used for is, it seems that there is potential for getting to bundle a small GNU/Linux distribution. This would end up being a lot of work just for one application.

There is some work going on which might allow addressing this issue without bundling all the tools into Emacs, for example:
flatpak/freedesktop-sdk-images#105

I do not know a a good way to address this immediately, but in the mean time as a short term solution it is indeed possible to build a custom copy that includes the tools you need. For example, you could add this snippet into the modules list in org.gnu.emacs.json:

    {
        "name": "cscope",
        "sources": [
            {
                "type": "archive",
                "url": "https://downloads.sourceforge.net/project/cscope/cscope/15.8b/cscope-15.8b.tar.gz",
                "sha256": "4889d091f05aa0845384b1e4965aa31d2b20911fb2c001b2cdcffbcb7212d3af"
            }
        ]
    }

Then rebuild and install locally by running something like:

flatpak-builder --user --install emacs-builddir org.gnu.emacs.json

Also in many cases there is the obvious alternative of just using the Emacs from your GNU/Linux distribution if your Emacs use case requires full access to all tools supplied by the distribution.

[muep]

Issue #14 has some related discussion which might produce instructions to deal with this class of problems. Especially it might result in something that allows you to avoid building a custom version. I'm closing this one since it kind of overlaps with #14.