Run ctags on source code in arbitrary directories, not necessarily contained in their $HOME.
Read config from arbitrary locations, for example during scripted scenarios which use a different set of config than the user’s personal defaults. The application supports command-line flag --options=FILE for this purpose.
Write output to arbitrary locations, such as the current dir when operating on source outside of $HOME, or, as in the issue linked above, specified using the application’s -f=FILE flag, for example to write to /tmp during scripted scenarios.
Background
This is an active fork of the venerable but stalled ‘exuberant-ctags’. The ‘ctags’ executable scans source code directories and writes an index of defined symbols to a ‘tags’ file.
I haven’t yet tried to upload a ‘classic’ release of our snap - I’ll do it after submitting this.
This is typically not a justification for classic confinement since the home and removable-media interfaces provide typical locations that DAC allows users to operate in. What specific locations are not covered by these interfaces?
What are specific, representative config file locations that are not currently covered by your snap?
This is mostly covered by home and removable-media. It is true that snaps use a per-snap /tmp directory, but this can be handled by adjusting to use TMPDIR or advising users to not use /tmp. Difficulties with the per-snap /tmp is not typically a justification for classic.
Thanks for the response, that really helps me to understand.
> What specific locations?
One user has regular config is in ~/.ctags.d/, which can be accessed fine via our existing :personal-files:. But when calling ctags from a Vim script/shortcut, they use a different ctags config, and they keep that config inside $HOME/.vim.
Three users have posted issues because they use the universal-ctags snap in conjunction with the neotags plugin for neovim, which requires read/write access to $HOME/.vim-tags.
One user posted an issue when trying to run on source on an external hard drive. I’ve asked them where it gets mounted (sounds like they manually added a mount to a Windows disk) I’m hazy on whether this is covered by the removeable-media interface, but I’ll go and read up on it.
One user posted an issue when trying to run universal-ctags ... -f /tmp/x123y456 (ie write output to the named file in /tmp) I’ll see whether I can fix this specific problem by adjusting TMPDIR as you mention.
I was expecting to achieve feature parity with apt installs of ctags. It sounds like this is not possible in the first two kinds of scenarios, and is only possible in the last two for specific predictable directories like /tmp, and not arbitrary (hypothetical) scenarios like: “My company has a crazy setup and we edit source on a dev VM in /srv/project”.
I think personal-files could be used here, read-only, without auto-connect. universal-ctags wouldn’t normally need access to ~/.vim, but I can see how some users might do this since it is used so often with vim. Alternatively, your application could direct them to move these files to somewhere else your application has access to.
Same, though possibly with autoconnect (that can be discussed when reviewers vote).
It should be, yes. removeable-media handles both /media (where udisks auto-mounts external drives) and /mnt (typical location for manual mounts).
