Closed mralusw closed 1 day ago
Would you consider making a PR for this?
yes please. I'd appreciate it.
I've pushed PR #68; it's a little complicated, comments in the commit message (identical to PR message).
Summary:
Vim.appimage
didn't have any problems to begin with.GVim.appimage
(un-extracted) can now be symlinked to vim
/ gvim
and behaves accordingly (just as the release notes say — they were incorrect as this issue explains).GVim.appimage
's AppRun is generated by linuxdeploy-plugin-gtk
(i.e. not under our control) and fails when symlinked from an extracted appimage (aka AppDir); this is not a new problem — it also fails before the PR, when symlinked (due to dirname
/ readlink
order).AppDirRun
, similar to the one I quoted in my initial issue) for users who extract. Alternatively, we'd need to mess with the deployment process and patch / replace the "broken" AppRun
just before packaging the appimage
archive (I'm not keen on this).I've tested by regenerating Vim.appimage
and GVim.appimage
manually with appimagetool
; I have not tested the GitHub deployment workflow though.
Should I add a separate AppDirRun
as proposed in #68?
closing as fixed by #68
The GVim appimage always tries to run as
gvim
(even if called through a symlink namedvim
, and even if no X11$DISPLAY
is set). This is becauseAppRun.wrapped
tries firstCutting through all the cruft probably generated by
linuxdeploy
(twobash
exec's even though nobash
features are needed, the"${@+"$@"}"
workaround for 1990's Bash), here's a simplerAppRun
that works as vim when the appimage is called asvim
. As a bonus thisAppRun
works when symlinked from an extracted appimage (hidden optiongvim.appimage --appimage-extract
available with all appimages)(note: updated after further investigation & #68)