add .loadRelative support

[grirgz]

No description provided.

[gilfuser]

Hi.
I know this is not ready yet but I'm interested in having this feature, so, I tried it.
I changed the SCVim.sc into this here proposed.
If I evaluate q = q ? (); I get this message:
E247 no registered server name "SCVIM": sending of the expression failed
and if I try "0_globals/0_loadGlobalUtils.scd".loadRelative;
I get this:
can't load relative to an unsaved file

I'm on Linux and tried both with neovim and vim and inside and outside tmux.
I would like to help, but I have no experience in writing SC Classes. So, I could test it if its needed.

bests,
Gil

[gusano]

@grirgz this will only work if vim has clientserver feature compiled-in, which AFAIK isn't always the case.

[gilfuser]

Hi @gusano. I checked if I have already clientserver compiled-in with this script:
[[ -n "vim --version | grep client" ]] && echo "Installed" || echo "Not installed"
Since I have it, I opened the scd in vim like this vim --servername SCVIM 0_startUp.scd
It worked fine!
I wouldn't know what to do with neovim though, since it doesn't have clientserver

[gusano]

@gilfuser IMHO implementing something which depends on an optional vim feature is not a good idea.. (on Archlinux, vim does not come with clientserver feature)

[dvzrv]

On 2018-11-06 06:01:48 (-0800), Yvan Volochine wrote: @gilfuser IMHO implementing something which depends on an optional vim feature is not a good idea.. (on Archlinux, vim does not come with *clientserver* feature)

We can ask for it to be changed though!

[grirgz]

Hi,

I agree it's unfortunate to clentserver vim mode is not enabled by default everywhere. I don't think there is any other mecanism to query informations from vim without clientserver mode, that's why it was implemented by vim programmers afterall ;)

Maybe it's possible to send the current path to SC each time we open or switch to a file in vim instead of querying it, but i don't know if it's possible or how.

Regarding archlinux vim package, it seems to me by looking at the PKGBUILD of https://www.archlinux.org/packages/extra/x86_64/vim/ that the huge option is used, which imply that clientserver is enabled. Maybe you didn't know you need to add a --servername option when launching vim.

Really I don't think the fact it's depending on an optional feature is a good reason to block the merge, because the optional feature is the feature specially made for communication with another process, and it's what we want to achieve here. Reinventing the wheel of communication to avoid installing a full-featured vim would be a bit crazy

Also, controlling vim from SC allow a lot of nice features like selecting a block of code, hit a shortcut to edit it by SC GUI, then code is updated automatically in vim. But this is off topic =)

[gusano]

Regarding archlinux vim package, it seems to me by looking at the PKGBUILD of https://www.archlinux.org/packages/extra/x86_64/vim/ that the huge option is used, which imply that clientserver is enabled. Maybe you didn't know you need to add a --servername option when launching vim

@grirgz

vim --servername foo
VIM - Vi IMproved 8.1 (2018 May 18, compiled Dec  28 2018 11:23:48)
Unknown option argument: "--servername"

Really I don't think the fact it's depending on an optional feature is a good reason to block the merge

Sorry but I have to strongly disagree unless you have a check in your code which tests if vim was compiled with that optional feature.
(this is not Archlinux specific)

Reinventing the wheel of communication to avoid installing a full-featured vim would be a bit crazy

Completely agreed ;)

[grirgz]

@gilfuser regarding neovim, the first implementation was for neovim, i adapted it to vim (see #36 )

For information, here is the script I use to start supercollider with tmux and clientserver mode

tmux new-session "vim --servername scvim -c 'set ft=supercollider | SClangStart'"

I was apparently wrong for the huge option. Now that I check it on #archlinux irc channel, the clientserver option is available on gvim package. And that's the same for my distro, i forgot i had the gvim package installed. The gvim package provide the vim executable so you can still use it in terminal

@gusano sorry i didn't understood this was the problem. Now I see there is an error message each time we run some code if there is no clientserver option or vim is not started with the correct servername. Which is obviously not acceptable.

I have added a check :

		vimServerEnabled = "vim --version".unixCmdGetStdOut.contains("+clientserver") and: {
			"vim --serverlist".unixCmdGetStdOut.contains(vimServerName.toUpper)
		};

But i'm a bit worried about systems where vim is not named vim, since a few lines above there is a mention of mvim for MacOS.

Another way could be to run "SCVim.vimServerEnabled = true" from the startup script of SCVim by querying the v:servername vim option. Do you know at which place this could be best put ? I don't know scvim internals very well.

[grirgz]

i have handled the case for mvim, see my new commit

[gusano]

@grirgz it would also be nice to mention this feature in the README :)

[capocasa]

I think the feature is cool! But my call is that it would need to be implemented in a cleaner way. Two problems that, to me, are a dealbreaker when taken together: (1) not supported across all vim versions as mentioned above, (2) need to execute a seperate process on each instance of loadRelative, which has a lot of potential for causing subtle bugs when using SC on low grade or embedded hardware. Also, there is a workaround available- you just send the entire file to scvim, then it works fine.

I'm fine with using hacks occasionally- how about a file in a well known location? Or you could add a global variable containing the file name on every command execution in code. Just ideas, no idea if they would pan out.

[grirgz]

@capocasa I don't understand your workaround proposal, what do you mean by sending entire file to scvim ?

Putting the filename in a file or in a local variable is a nice idea. I could even put my vim server code in a separate quark. However, I need to ask you: did you think about adding more features to the class Document ? Like editing a new file or inserting text for example. It would be really hard to implement this by using a temporary file or hidden variable. If we want full control of vim from SC and reverse, we need to communicate with vim and the vim way to communicate to other programs is the server mode

[capocasa]

If we want full control of vim from SC and reverse, we need to communicate with vim
and the vim way to communicate to other programs is the server mode

Fair point- you're right, it's not just about the feature at hand, it's also about good architecture.

I was on the fence, but I withdraw my opposition to using server mode, provided there is some kind of graceful degradation.