Classic confinement, name request and aliases for emacs

store-requests
#1

As Emacs is an editor / IDE users expect to be able to edit files from anywhere on their file-system and to be able to call-out to toolchains installed on the host system - as such Emacs requires classic confinement.

I have created what is currently a name-spaced version of this snap - emacs-alexmurray - but ideally I would like this to be just emacs - there should be a definitive version of this application in the store, and I am willing to maintain it - as such I have already put in a request for this name via the store.

Finally, the snap ships both the emacs command as well as a few other commands (emacsclient, ctags, etags etc) so I would like to request appropriate aliases for each of these as well.

Classic confinement, name request and aliases for Emacs (git)
#2

Hi Alex,

Iā€™ve assigned the emacs name to you, you can now potentially just upload your existing snap under that name and publish it.

Iā€™m +1 as reviewer to assigning the emacs auto-alias to the emacs command (though - if the snap is called emacs and the command is called emacs IIRC thereā€™s no need to add an alias; emacs should just work?).

However, Iā€™m -1 to assigning auto-alias for the emacs-bundled ctags, etags and etc since these are generic enough that they might conceivably be bundled with other editors (hypothetical vim snap anyone?). Can emacs be configured to use emacs.ctags? and/or, maybe those generic editor tools could be bundled in a central snap and made available via e.g. content interface (though - if they are granted classic, as theyā€™re likely to be they wouldnā€™t need an interface, I think?). In any case - I donā€™t think an alias for a snap-bundled version of these generic tools is appropriate.

Iā€™ll let others comment/process the request for classic :slight_smile:

  • Daniel
#3

Thanks @roadmr - will wait to see what others think (you are right that there is no need for the emacs alias itself - emacs.emacs aliases to emacs already it seems)

#4

ping @reviewers :slight_smile:

#5

@alexmurray, I noticed thereā€™s another emacs version in the store (last updated 2016). Do you know if upstream are interested in owning and maintaining the emacs snap?

#6

@Igor the other one (emacs-tealeg) looks to be a ā€˜privateā€™ version that has never been updated. I will ask on emacs-devel to see whether there is any interest in upstream owning this and get back to you.

#7

The requirements are understood and Iā€™ve vetted the publisher. Granting use of classic. This is now live.

1 Like
#8

As for the aliases, while Iā€™m not an emacs user, @roadmrā€™s points make sense to me, so -1 on the auto-aliases for etags and ctags. Can you describe ebrowse and emacsclient a bit more?

#9

@reviewers - can some of you (especially emacs users or those familiar with it) vote on the aliases request?

#10

+1 for emacsclient, as one would expect itā€™s shipped in the emacs .deb and provides a way of remotely interacting with an emacs ā€œserverā€. I use it tens if not hundreds of time a day and would expect it to be installed and accessible as emacsclient after installing the snap (so my scripts wouldnā€™t break).

Iā€™m not familiar with ebrowse which appears to be something specific to C++ in emacs

#11

+1 for emacsclient.

Iā€™m also +1 for ebrowse, as this is primarily associated with emacs.

#12

+1 for aliases for ebrowse and emaclient. -1 for etags and ctags

#13

0 votes for, 2 votes against for etags and ctags
3 votes for, 0 against for emacsclient
2 votes for, 0 against for ebrowse

Granting use of the emacsclient and ebrowse aliases. This is now live.

#14

Thanks for that @jdstrand