supercollider
thisProcess.nowExecutingPath
Something I've missed for a long time in scvim is using thisProcess.nowExecutingPath in a .scd file to get the current buffer's absolute path.
I think the way to achive this is to implement Document support for scvim. I have a proof-of-concept here which works for neovim using the neovim-remote tool. It should be easy to adopt for regular vim as well which already include the --remote-expr flag by default.
Implementing Document for scvim comes with some issues though, because you get a "duplicate class" conflict when using the IDE (ScIDE.sc also implements Document). I have looked at ScelDocument, which inherits another implementation of Document (found in editors/scel), so I'm guessing scel-users suffer the same problem with the "duplicate class" error in the IDE. Maybe someone using emacs/scel could confirm this? I'm hoping there is some way to only include SCVim.sc when running sclang with the -i scvim flag, but I haven't found one yet.
Does anyone with more experience with Document have any thoughts on this?
In order to get the proof-of-concept working I had to start a new nvim instance using nvr foo.scd (even though the documentation of nvr says this should not be necessary) haven't debugged that yet.
Last time I looked into that, I found that scvim and scel lack proper implementation. Here's some relevant mailing list doc: https://www.listarc.bham.ac.uk/lists/sc-dev-2015/msg54676.html
@dvzrv Thanks for the link! Dan's answer worked. After creating scide_scvim/ in SCClassLibrary and symlinked SCVim.sc there I could use both scvim and ScIDE without the duplicate class conflict. So this looks like the correct approach. Now its only a matter of properly implementing the Document class for scvim ^^
Hmm, the thing is: scvim is now a submodule. We have to find out, how to do this, so it works out of the box for SuperCollider, when using vim/scvim.
Yes, for sure. I somehow feel like this approach of putting SCVim.sc in scide_scvim should be the default installation method. I've always had it in my Extensions dir, but then it gets compiled with rest of the class library when using the IDE which shouldn't be necessary when using that environment.
Maybe manually creating scide_scvim/ wherever SCClassLibrary lives and symlinking SCVim.sc there could be added to the installation instruction at some point in the future? (It doesn't matter much now if there is no Document support). It would be nice with an automated approach of course, but it would be hard to know which SCClassLibrary a user is sourcing (if they use the checked out version from git, or the one packaged in SuperCollider.app for instance).
Based on @davidgranstrom solution, i've made it work for vim, but this require to start vim in server mode. If I understand correctly, there is no start script, so i guess this up to the user to start vim in correct mode and correct server name
Closed the pull request, as it was, unfortunately- I missed this feature as well. I also didn't know it was working for neovim. I actually thought about this some more, but I just can't justify to myself scvim not behaving identically across platforms in order to support this feature, and also not the code complexity.
I still think is very worthwhile to do, but we need something that's easy on the user- the more I think about it, the more I like the idea of executing an additional command in sclang to set the value that loadRelative needs before executing the proper command, but some thought may be required on how to prevent that idea from breaking stuff. Using a global variable with a long name should work, even with environments.
