emacs-snap:master

Last commit made on 2022-06-01
Get this branch:
git clone -b master https://git.launchpad.net/emacs-snap

Branch merges

Branch information

Name:
master
Repository:
lp:emacs-snap

Recent commits

82b52fe... by Alex Murray

Only do emacsclient desktop bits when launched from desktop file

In our emacsclient wrapper we can detect if we have been launched as a
desktop file via GIO_LAUNCHED_DESKTOP_FILE and
GIO_LAUNCHED_DESKTOP_FILE_PID and then only do the desktop specific parts
in that case, otherwise we can just run emacsclient directly.

Signed-off-by: Alex Murray <email address hidden>

58acb5c... by Alex Murray

Implement emacsclient.desktop shell logic in a wrapper script

Should fix issue #40

Signed-off-by: Alex Murray <email address hidden>

40d0f27... by Alex Murray

Ensure we require 'comp before we try and update native-comp-driver-options

Fixes #39

Signed-off-by: Alex Murray <email address hidden>

9787196... by Alex Murray

Try ensure native-comp-driver-options then unset SNAP too

We can unset SNAP once we are sure we have used it so in site-start.el
first update native-comp-driver-options just in case our patched version of
comp.el didn't work for some reason and then go and unset $SNAP as well.

Signed-off-by: Alex Murray <email address hidden>

58411aa... by Alex Murray

Don't unset SNAP environment variable

This is used by our patched version of comp.el to setup the
native-comp-driver-options correctly so we need to retain this.

Signed-off-by: Alex Murray <email address hidden>

7d892b6... by Alex Murray

Unset various SNAP environment variables on startup

Firefox (and other applications) may change their behaviour when running as
a snap - as such, if we have these SNAP environment variables set in our
environment and then we go and execute say Firefox, it will assume it is
running as a snap and may then misbehave. This causes issues like Firefox
using the wrong profile as seen in
https://bugs.launchpad.net/snapd/+bug/1835024 and more specifically in
https://github.com/alexmurray/emacs-snap/issues/36. If we unset the
variables then we avoid any confusion in these other applications, plus
Emacs itself doesn't do anything with these anyway so it is safe to unset
them too.

Fixes #36.

Signed-off-by: Alex Murray <email address hidden>

96b1d4b... by Alex Murray

Try ensure we run unconfined by AppArmor

When launching classic snaps, snapd generates a basic profile based off a
standard template. This profile runs in complain mode and so in general
does not restrict what a classic snap can do. However, it does result in
the process being labelled by AppArmor as
"snap.emacs.emacs (complain)". Any subsequent process launched by emacs
also then inherits this profile and so then gets labelled also by the emacs
snap AppArmor label. The Ubuntu dock appears to fall-back to indentifying
an application by it's AppArmor label and so then if say emacs launches
Firefox, the Firefox window gets associated with the Emacs icon on the dock
and not the Firefox icon. So fix this by moving the emacs snap itself to
run unconfined and as such any process it launches will also then run
unconfined too.

Fixes issue #36

Signed-off-by: Alex Murray <email address hidden>

8b4be59... by Alex Murray

Set native-comp-driver-options in core emacs comp.el

Setting it in site-lisp.el is too late for some use-cases.

Fixes issue #35.

Signed-off-by: Alex Murray <email address hidden>

6308794... by Alex Murray

Set native-comp-driver-options as default value

When setting native-comp-driver-options in our site-start.el set this as
the default value so that early init uses it too - fixes issue #35

Signed-off-by: Alex Murray <email address hidden>

a83059c... by Alex Murray

Don't assume snap is mounted under /snap

Instead use the $SNAP environment variable to get the path

Signed-off-by: Alex Murray <email address hidden>