um icon indicating copy to clipboard operation
um copied to clipboard

templates don't work with Visual Studio Code

Open matthewpflueger opened this issue 6 years ago • 4 comments

I am using Visual Studio Code as my editor which is on my path. My config looks like:

* editor = code
* pager = less
  pages_directory = /Users/matthewpflueger/.um/pages
  default_topic = shell
  pages_ext = .md

When doing

um edit grep

just brings up a blank editor. HOWEVER, setting the editor to vi brings up what you'd expect (a the template file).

matthewpflueger avatar Aug 24 '18 16:08 matthewpflueger

um is pretty dumb and it launches the editor by invoking the editor and passing the file path as the first argument.

Does that work with the code executable? It could be that Visual Studio Code expects you to pass the file argument differently.

sinclairtarget avatar Aug 24 '18 18:08 sinclairtarget

Well VS works well with git and other programs that uses the EDITOR environment variable. I haven’t had any issues doing code . Anyway, I haven’t looked but um must be invoking the editor differently than programs like git. On Fri, Aug 24, 2018 at 14:01 Sinclair Target [email protected] wrote:

um is pretty dumb and it launches the editor https://github.com/sinclairtarget/um/blob/master/libexec/um-edit.rb#L59 by invoking the editor and passing the file path as the first argument.

Does that work with the code executable? It could be that Visual Studio Code expects you to pass the file argument differently.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sinclairtarget/um/issues/11#issuecomment-415836413, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHVLdpNK6NMboFnRock-CJF85GapUTjks5uUD9_gaJpZM4WLpyh .

matthewpflueger avatar Aug 25 '18 18:08 matthewpflueger

Is this still a concern / issue?

With regards to git - it seems there's a difference in the way the editor is invoked, yet not too material:

While um writes a shell invocation directly through the system command (system(%{#{editor} "#{page_path}"})), git creates a child process and runs it - yet the result is very similar, as the the file is passed in as the second argument of the process (the first being the editor's name itself).

It would be nice to know what file VisualStudio Code has opened when it renders a blank.

iajrz avatar Oct 19 '18 14:10 iajrz

For the record, specifying editor = code seems to work fine on macOS Mojave (10.14.something; Catalina and Big Sur could present their own challenges). That is, provided you've followed the instructions for installing the code command line executable.

Workaround for VS Code .deb package on Linux

On Ubuntu 18.something (elementaryOS 5.1.x Hera), I was able to find a workaround for problem noted here, by pointing directly at VS Code's main executable:

editor = /usr/share/code/code --no-sandbox

It should be noted that there is also /usr/bin/code, a symlink to /usr/share/code/bin/code, but the one I'm talking about is 108 MB on my system (probably because it includes the Electron runtime).

Now, that's assuming that you've used the VS Code .deb. RPMs, tarballs, snaps, and flatpaks, and all the other whatnot may put the code executable somewhere else, like under /opt, for example.

However, I don't think this is um's problem (any more than if um had trouble opening a new page in an editor inside a flatpak), and this issue could be closed.

ernstki avatar Aug 14 '20 03:08 ernstki