Hi everybody!

I just wanted to mention that I have been maintaining a scvim plugin for quite some time (before supercollider moved to github) , that you can find over here - also based on the original scvim work.

https://github.com/sbl/scvim

Some rework has gone in it and different people have contributed and used it over the time. Happy to move that over here to have one unified place for a scvim plugin. Why don't you try it out and see if it makes sense to merge both efforts.

Best
Stephen

I installed the following Supercollider rpms through the PlanetCCRMA repository:
supercollider-3.9.3-1.fc29.ccrma.x86_64.rpm
supercollider-vim-3.9.3-1.fc29.ccrma.x86_64.rpm

When I open a test.sc with vim, and try :SClangStart I get:
E492: Not an editor command: SClangStart

Is there something I'm missing?

Hi,

while trying this out again I seem to have found the solution ;)

so asking for :SCTags (as documented in the Readme) I get:

E492: Not an editor command: SCTags

But then trying SCtags seems to work ;)

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?

Any idea what this error is about? I always see it when starting scvim:

/home/awright/.vim/plugged/scvim/bin/start_pipe
awright@ovitus:~/tidal$ /home/awright/.vim/plugged/scvim/bin/start_pipe
compiling class library...
[0108/181607.596102:WARNING:stack_trace_posix.cc(699)] Failed to open file: /memfd:/.glXXXXXX (deleted)
Error: No such file or directory
Found 845 primitives.
Compiling directory '/usr/share/SuperCollider/SCClassLibrary'
Compiling directory '/usr/share/SuperCollider/Extensions'
Compiling directory '/home/awright/.local/share/SuperCollider/Extensions'
Compiling directory '/home/awright/.local/share/SuperCollider/downloaded-quarks/Vowel'
Compiling directory '/home/awright/.local/share/SuperCollider/downloaded-quarks/Dirt-Samples'
Compiling directory '/home/awright/.local/share/SuperCollider/downloaded-quarks/SuperDirt'      
numentries = 1189267 / 18280590 = 0.065                                                         
5745 method selectors, 3182 classes
method table size 19375088 bytes, big table size 146244720
Number of Symbols 14482
Byte Code Size 415003
compiled 457 files in 0.68 seconds

It's the third time I'm trying to install scvim on linux mint, I'm following the instructions and I simply end up with a terminal appearing and disappearing right away when I type :SClangStart.

Operating System: Linux Mint 21.1                 
Kernel: Linux 5.15.0-73-generic

From a clean install (never installed vim or SC before on this system):

sudo apt vim
sudo apt install supercollider
mkdir -p ~/.vim/pack/my/opt/
git clone https://github.com/supercollider/scvim.git ~/.vim/pack/my/opt/scvim

I then copied the two lines at the end of my .vimrc file (which I had kept from a previous install):

au BufEnter,BufWinEnter,BufNewFile,BufRead *.sc,*.scd set filetype=supercollider
au Filetype supercollider packadd scvim

Then I symlinked as was suggested, getting the target path by executing Platform.UserExtensionDir inside Supercollider IDE to which I appended /SCVim.sc:
ln .vim/pack/my/opt/scvim/sc/SCVim.sc xxx/SuperCollider/Extensions/SCvim.sc

I then tried out if it worked:

touch test.sc
vim test.sc

And inside vim,
:SClangStart

A terminal appears and disappears right away.

I have absolutely ZERO idea of what I'm supposed to do. Couldn't find any help anywhere. I don't know supercollider yet (was planning to get scvim running and then start learning it) so I don't in particular know its inner workings or if I have to tinker into specific places.

Any help would be appreciated.

In case it helps, the content of my .vimrc:

" Syntax highlighting
syntax on

" Adds line numbers
set relativenumber

" Sets up tab indent spaces
set shiftwidth=2
set tabstop=2

" Adds a vertical line at column 80 (for pep8)
set colorcolumn=80
highlight colorcolumn term=reverse ctermbg=240 guibg=DarkRed

" Tabs put spaces instead
set expandtab

" Do not let cursor go to the edges when scrolling
set scrolloff=10

" Stuff for scvim
au BufEnter,BufWinEnter,BufNewFile,BufRead *.sc,*.scd set filetype=supercollider
au Filetype supercollider packadd scvim

And it is properly loaded when I start vim.

It would be most awesome to write a completer for youcompleteme.
The ycm plugin is the overall approach for completion and preview for vim and people are even thinking about merging it into neovim.

I'd like to see ycm be able to handle SuperCollider. I think this would be a very good improvement.

Due to the fixed tarball for supercollider 3.8, there is no :SCtags in that release, as SCVim.sc doesn't have a *generateTagsFile class function (yet).
Additionally, if one tries to use the current version of scvim with supercollider 3.8, the /usr/share/SuperCollider/Extensions/scvim/SCVim.sc (in case of Linux) file has to be deleted to use the up-to-date one (as there can not be two files representing the same class in the path, when not using overrides).

This effectively makes it impossible to use the current version of scvim with supercollider 3.8, but would work, as soon as the SC_VIM=OFF build option is set as a default (#1 (comment)).

I suggest to update the README to declare this dependency.

I've been trying to follow the readme.

I setup pathogen and installed scvim into ~/.vim/bundle

I created ~/.vimrc with the following:
execute pathogen#infect()
let g:sclangTerm = "x-terminal-emulator -e $SHELL -ic"
syntax on
filetype plugin indent on

I created a system link:
ln -s ~/.vim/bundle/scvim/sc/SCVim.sc ~/.local/share/SuperCollider/Extensions

Then I test it:
vim test.sc
:SClangStart

s.boot;
(
Pbind(
\freq, Pn(Pseries(110, 111, 10), 2),
\dur, 1/2,
\legato, Pwhite(0.1, 1)
).play;
Pbind(
\freq, Pn(Pseries(220, 222, 10), 4),
\dur, 1/4,
\legato, Pwhite(0.1, 1)
).play;
Pbind(
\freq, Pn(Pseries(330, 333, 10), 6),
\dur, 1/6,
\legato, 0.1
).play;
)

F6 to evaluate s.boot; and F5 to evaluate the block. I see :call SClang_block(), but I hear nothing.

Shouldn't I be seeing a Post or Help window in vim after executing :SClangStart?

I guess I could have put the link in /usr/share/SuperCollider/Extensions. IDK if that makes a difference. I get E492: Not an editor command: SClangStart when trying to run :SClangStart as root.

When launching the HelpBrowser on a keyword through vim (ctrl+K), the HelpBrowser renders the HTML Help page for the keyword using SCDoc and opens it (HelpBrowser.openHelpFor("keyword");).
Inside the HelpBrowser however, this doesn't apply and thus clicking on links for keywords, that have not been rendered yet, does nothing.
Is there any way to change this? It's pretty annoying to use the HelpBrowser this way.
SCIDE does this on the fly. I wonder, in what way this can be changed when using scvim, as the HelpBrowser is launched as a singleton.

On a different note: It would be great to have the HelpBrowser stay open even between recompiles, or re-open the last opened Help page on recompile. Currently it is closed, as the sclang process launching it is killed.

sorry, but can't get it working on debian testing. I'm new to vim...

Installed scvim via vim-plug
Added the symlink

But when I start :SClangStart it gives me a flashing terminal, but it doesn't launch.

edit: Did try to add
let g:sclangTerm = "gnome-terminal -x $SHELL -ic"

to .vimrc, but doesn't change anything (just put it somewhere in the file?)

Installed gnome-terminal, but would prefer lxterminal

On linux, when running :SClangStart with no terminal configured and no x-terminal-emulator program installed, nothing happens. The defaulting mechanism should be improved for linux, for example checking specifically for more common terminals.

Reported by @vivid-synth (was supercollider/supercollider#2660)

In scvim some characters don't highlight correctly:

x = [ $1 , $a , $* , $# ]
observe $* and $# are not displaying properly

I installed scvim with Pathogen, and have F6 not working.

Tried to add au BufEnter,BufWinEnter,BufNewFile,BufRead *.sc,*.scd set filetype=supercollider to ~/.vimrc, to call source ~/.vim/bundle/scvim/ftplugin/supercollider.vim, also prepended with let loaded_scvim=0, but neither helps.

I am experiencing a strange issue that I can't quite pin down the reason for: When I work in scvim I keep getting disturbed by the message "Press ENTER or type command to continue". This is exclusive to scvim, ie. it doesn't happen when I work in vim elsewhere. I am running this on the latest Arch kernel, sc3.9dev, I have the latest version of scvim (at least I have been running PluginUpdate, so it should be OK...). scvim is running without any extraneous options, the only mention of it is let g:sclangTerm = "xfce4-terminal -x $SHELL -ic" in .vimrc.
My full .vimrc is here: https://pastebin.com/V5sQHat5
I have been running basically the same setup on macOS without a hitch, this is brand new to me... (oh, and I am a complete Linux rookie, so please bear with me if this is something so, so basic...)

Please check this issue over at the main supercollider repo. Short recap: the help browser is crashing on me, both using wayland and xorg with nouveau drivers. It seems to be caused by a known qtwebengine/noveau issue, and is solved in scide by running with scide --disable-gpu. I would like to disable gpu in scvim as well, but don't know where to start! Most of all, though, I would like to get rid of the help browser as such, and rather have access to the help files natively in vim! At the moment I am using w3m on a local copy of doc.sccode.org, but this is pretty far from an ideal workflow...

System: Arch Linux 4.14.71-rt44-1-rt-lts/swaywm/urxvt/scvim/sclang 3.10.0

I'd like to make scvim a true filetype based plugin.
Currently it's started through using the scvim script, but that's not needed at all. vim can decide upon filetype and just use the plugin.
Maybe I'm wrong here and there was some abstract use-case for it (once)?

In any case I've tested this, but have unfortunately overwritten my local changes by testing an alpha of 3.7 back in the day.
Will reconstruct and do a pull request.

Before the sbl/scvim merge there was screen support and sclang in tmux could be started vertically or horizontally.
I'd like to add that back to scvim. I still have an older version of the plugin through my distribution, in which I added those features.
Will try and merge it back into the current version of the plugin. Hope it works out okay.

Hi,

it seems to run sclang in a non-standard install location (e.g. in userspace) you have to find bin/scpipe/lib/sc/pipe.rb and edit that file.

Would be nice if the sclang path could be set in .vimrc (or can it, and I just overlooked the option?)

Thanks
.r.

I'm using gruvbox, and some of the syntax ( SinOsc, wait, play, etc...) I don't know if it's a problem with the plugin or is it something local. If anyone knows what it might be lend me a helping hand =)

So this one's been with me a while. The help browser in SCVim works pretty great but there's a few bugs at least on MacOS that are kind of crippling:

1. It is not possible to copy-paste from the help browser window to anywhere ( I have no idea why at the moment)
2. The search is case sensitive as opposed to the one on http://doc.sccode.org/ and in the IDE
3. Internal links don't work in the help browser

I'm running SC 3.9.1 on High Sierra 10.13.4 but these bugs have been with me for a long time now.

Thanks a lot !

While trying to start scvim with supercollider 3.8, I ran into the problem, that basePath in SCVim.sc is not searched generically (enough).
It basically assumes a folder called scvim below ~/.vim. This however is most likely not generic enough. VAM for example puts the plugin folders wherever you want it to and it will automatically set the plugin folder names (depending on their origin). In the case of scvim, it boils down to a folder called github-supercollider-scvim.

When assuming, that scvim from now on will only be installed on a per-user basis, below ~/.vim, SCVim.initClass should at least a) search for a folder with scvim in the name (not just as the whole name), b) traverse deeper below ~/.vim than just one folder (at least two) and c) document what is expected behavior in the README.md.

Additionally, if basePath is not set, the supercollider_objects.vim file should not be written! This otherwise leads to an unnecessary error.

Pull request #28 fixes it.

if echo has('terminal') returns 1 then the current vim build will have the :term command which i believe behaves pretty much like neovim :term

We should then be able to open SC in a split on vim instead of using a standalone terminal?

open

(
  //(
  "got it".postln;
)

:call SClang_block() anywhere inside gives an error about unmatched paren

closed

(
  //)
  "got it".postln;
)

:call SCLang_block() on the "got it" line gives an error about unmatched paren as well, if you eval on the //) line, the block block is sent to sclang and you get this error:

ERROR: Command line parse failed
-> nil
ERROR: syntax error, unexpected $end, expecting ')'
  in interpreted text
  line 3 char 1:

Because, I assume, the block that is sent is:

(
  //)

t was working flawlessly, and now suddenly it's telling me there is already a sclang session running, remove it first, then retry

This is in tmux, when I run :SClangStart

this happens even on fresh reboots, so there is definitely no sclang session running.

running :SClangHardstop or :SClangKill just hangs. I can get back into nvim with ctrl+c

I'm running nixos 21.05 on kernel 5.14.14 on an amd cpu/gpu. everything is updated.

Thank you for understanding, I've never written an issue on github before, so I'm quite sure I'm not doing this exactly right. Please let me know other information can help! This is super important to me.

I think that most people these days use Vundle to install packages.

https://github.com/VundleVim/Vundle.vim

Somebody should test if that works and if so then make the install directions first suggest doing that.

(I'm not saying that @danstowell should do it !)

Thanks for separating this out dan !

With Supercollider 3.7.2 on OSX I get the following error after sending SCVim.updateHelpCache to the server:

-> SCVim
SCVim: processing help docs, this takes a little while....
ERROR: Message 'tree' not understood.
RECEIVER:
class Help (0x11386f000) {
  instance variables [19]
    name : Symbol 'Help'
    nextclass : instance of Meta_HelpBrowser (0x114c05b00, size=19, set=5)
    superclass : Symbol 'Object'
    subclasses : nil
    methods : instance of Array (0x11386f180, size=1, set=2)
    instVarNames : instance of SymbolArray (0x11386f240, size=3, set=2)
    classVarNames : instance of SymbolArray (0x11386f3c0, size=4, set=2)
    iprototype : instance of Array (0x11386f300, size=3, set=2)
    cprototype : instance of Array (0x11386f480, size=4, set=2)
    constNames : nil
    constValues : nil
    instanceFormat : Integer 0
    instanceFlags : Integer 0
    classIndex : Integer 564
    classFlags : Integer 0
    maxSubclassIndex : Integer 564
    filenameSymbol : Symbol '/Applications/SuperCollider.app/Contents/Resources/SCClassLibrary/SCDoc/Help.sc'
    charPos : Integer 0
    classVarIndex : Integer 27
}
ARGS:
CALL STACK:
    DoesNotUnderstandError:reportError   0x11515d9c8
        arg this = <instance of DoesNotUnderstandError>
    Nil:handleError   0x115139c38
        arg this = nil
        arg error = <instance of DoesNotUnderstandError>
    Thread:handleError   0x11515cd68
        arg this = <instance of Thread>
        arg error = <instance of DoesNotUnderstandError>
    Thread:handleError   0x11513a898
        arg this = <instance of Routine>
        arg error = <instance of DoesNotUnderstandError>
    Object:throw   0x115160938
        arg this = <instance of DoesNotUnderstandError>
    Object:doesNotUnderstand   0x11513a108
        arg this = <instance of Meta_Help>
        arg selector = 'tree'
        arg args = [*0]
    < FunctionDef in Method Meta_SCVim:updateHelpCache >  (no arguments or variables)
    Routine:prStart   0x11515c3c8
        arg this = <instance of Routine>
        arg inval = 27.618982983
^^ The preceding error dump is for ERROR: Message 'tree' not understood.
RECEIVER: Help

So, if I press F5 inside a code block (between "()") sometimes it returns an error:

Error detected while processing function SClang_block[1]..findOuterMostBlock:

I recently updated from an old version of supercollider and configured this new scvim. But i can't anymore execute a block of code which i selected in visual mode. It seems that's instead it just run "execute one line" on each line of the block

this works:

1.postln;
2.postln;

give me the result:

1
-> 1
2
-> 2

this doesn't work:

3.do { arg x;
x.postln;
}

give me the result:

ERROR: syntax error, unexpected $end, expecting '}'
in interpreted text
line 2 char 1:

ERROR: Command line parse failed
-> nil
nil
-> nil
ERROR: Parse error
in interpreted text
line 1 char 1:

}
^

unmatched '}'
in interpreted text line 1 char 1
ERROR: syntax error, unexpected BADTOKEN, expecting $end
in interpreted text
line 1 char 1:

}
^

ERROR: Command line parse failed
-> nil

On Linux, package managers take care of where files are installed for which application (package) on a system-wide level.
Vim supports several plugin folders, that are tested, when it starts. One is system-wide (all users of a given system can use that plugin) and one is user-specific (only the user starting vim can use that plugin).

As I'm now maintaining supercollider for Arch Linux, I'd like to have a look into how to ship scvim as a plugin package (e.g. vim-scvim or vim-supercollider).
This has the above mentioned benefit of several users being able to use the same installation.
Starting from 3.9, scvim will most likely not be compiled by default (which has the benefit of being able to update scvim, while supercollider is not updated).
Also, to circumvent #27, I have disabled scvim in the updated build of 3.8.0 for Arch Linux.

For this to happen, several things (ideally) will have to be done though:

• start to version (tag) scvim
• install supercollider and scvim files system wide
• install binaries and link libraries (sc_dispatcher and start_pipe)
• extend initClass and startUp.add of SCVim.sc for a global install
• bake a package

Hello, I'm really hoping to get scvim working on my Ubuntu 19.04 install. When I enter SCLandStart the server window opens, but this is the output:

	Compiling directory '/usr/share/SuperCollider/SCClassLibrary'
	Compiling directory '/usr/share/SuperCollider/Extensions'
	Compiling directory '/home/jcovingt/.local/share/SuperCollider/Extensions'
	numentries = 818594 / 11958602 = 0.068
	5353 method selectors, 2234 classes
	method table size 13112760 bytes, big table size 95668816
	Number of Symbols 12127
	Byte Code Size 364116
	compiled 317 files in 0.46 seconds

Info: 4 methods are currently overwritten by extensions. To see which, execute:
MethodOverride.printAll

compile done
localhost : setting clientID to 0.
internal : setting clientID to 0.
Couldn't set realtime scheduling priority 1: Operation not permitted
Class tree inited in 0.01 seconds


*** Welcome to SuperCollider 3.10.0. *** For help type :SChelp.
Couldn't set realtime scheduling priority 1: Operation not permitted

...And unfortunately any lines I try to evaluate and play don't have any effect that I can tell (silence). Any one else experiencing this issue or similar issues?

It is not an issue, it rather suggestion or question:

I use ScVim quite often now even for live-coding performances, I was wondering if there is a chance to get the blocks of code highlighted while being executed (as in ScIde for instance)?

Maybe more Vim question…

whatever, any ideas or suggestions?

thx!

Please add "" around the environment variable in plugin/supercollider.vim:
if exists("$SCVIM_TAGFILE")
otherwise, on my system, vim cannot add it to tagfiles.

see:
https://github.com/vim/vim/blob/d6105cb4085ad166910897a640693d3bada603e1/runtime/doc/eval.txt#L3741

Character literals are not escaped and therefore not passed to sc interpreter:

x = $a

// -> nil

x = [ $1, $a ]

// ERROR: syntax error, unexpected ',', expecting ']'
//   x = [ ,  ]
//         ^

Also kinda related: supercollider/supercollider#2660

I'm on OS X 10.11
If 'sclang' is aliased, sclangpipe_app can't detect it.
which sclang.chmod which returns an empty string if sclang is aliased.
If one shouldn't use alias for this maybe the used should be warned?

When starting from nvim, scvim fails sto initialize because it doesn't find a .vim folder, since nvim uses the .config/nvim folder.
This can be easily fixed by the user by symlinking ~/.config/nvim to .vim, but the error message is very unhelpful:

SCVim could not be initialized. Consult the README to see how to install scvim.

since the readme doesn't mention anything about needing scvim to be on the .vim folder.
I suggest either changing the error message to something more specific or adding a line or two in the README making it clear that scvim needs to be in the ~/.vim folder

Hello !

Just a tiny bug: When using the SCfindArgs() command it works great on stuff where the method is explicit (SinOsc.ar for example) but it comes back with nothing when it's implcit (Pseq for example). Maybe it's a hard nut to crack but it would be a nice feature to have both work in the future.

Thanks !

Ruby is a dependency for this plugin on all operating systems. It's not Linux specific. The ruby install instructions however are too specific and not really needed (depend on one's distributions package manager, naming, etc. anyways).

I propose to remove the redundant Linux specific information, as the usage of g:sclangTerm is explained later on in the README for all supported OS's.
Additionally it would probably be wise to mention, that scvim is tested on MacOSX and Linux only so far (not to get potential Windows user's hopes up too high ;-) ).

Getting strange behavior from scvim. It's been working well so far, but now it fails completely. I can run my patches from scide and sclang on the command line, but trying to run it from nvim (and vim) fails. Output from journalctl -xe (excerpt) is this:

Aug 29 20:47:07 arch systemd-coredump[10894]: Process 10841 (nvim) of user 1000 dumped core.
                                              
                                              Stack trace of thread 10846:
                                              #0  0x00007f3188ba6d7f raise (libc.so.6)
                                              #1  0x00007f3188b91672 abort (libc.so.6)
                                              #2  0x00007f3189e20075 n/a (libuv.so.1)
                                              #3  0x00007f3189e2df7c n/a (libuv.so.1)
                                              #4  0x00007f3189e2f0e6 uv_signal_stop (libuv.so.1)
                                              #5  0x0000555af00532c0 n/a (nvim)
                                              #6  0x00007f3189dfda9d start_thread (libpthread.so.0)
                                              #7  0x00007f3188c6aa43 __clone (libc.so.6)
                                              
                                              Stack trace of thread 10841:
                                              #0  0x00007f3188858e9b ~system_error_category (libstdc++.so.6)
                                              #1  0x00007f3188ba9997 __cxa_finalize (libc.so.6)
                                              #2  0x00007f3188829b38 __do_global_dtors_aux (libstdc++.so.6)
                                              #3  0x00007f3189e9c8de _dl_fini (ld-linux-x86-64.so.2)
                                              #4  0x00007f3188ba945c __run_exit_handlers (libc.so.6)
                                              #5  0x00007f3188ba958e exit (libc.so.6)
                                              #6  0x0000555aeff8b5e6 preserve_exit (nvim)
                                              #7  0x0000555aeffc58c2 n/a (nvim)
                                              #8  0x0000555aefefbfc9 multiqueue_process_events (nvim)
                                              #9  0x0000555aefefb699 loop_poll_events (nvim)
                                              #10 0x0000555af005780e n/a (nvim)
                                              #11 0x0000555af005484b ui_builtin_stop (nvim)
                                              #12 0x0000555aeffc61b3 mch_exit (nvim)
                                              #13 0x0000555aeff6bd1f getout (nvim)
                                              #14 0x0000555aeff8b679 preserve_exit (nvim)
                                              #15 0x0000555aeffc58c2 n/a (nvim)
                                              #16 0x0000555aefefbfc9 multiqueue_process_events (nvim)
                                              #17 0x0000555aefefb699 loop_poll_events (nvim)
                                              #18 0x0000555aefefcc3d process_wait (nvim)
                                              #19 0x0000555aeffc4b20 n/a (nvim)
                                              #20 0x0000555aeffc57e1 os_system (nvim)
                                              #21 0x0000555aefed5b9f n/a (nvim)
                                              #22 0x0000555aefedd7a3 call_func (nvim)
                                              #23 0x0000555aefee1dd2 n/a (nvim)
                                              #24 0x0000555aefee6862 ex_call (nvim)
                                              #25 0x0000555aeff1df9b do_cmdline (nvim)
                                              #26 0x0000555aefedcbfd call_user_func (nvim)
                                              #27 0x0000555aefedd590 call_func (nvim)
                                              #28 0x0000555aefee1dd2 n/a (nvim)
                                              #29 0x0000555aefee6862 ex_call (nvim)
                                              #30 0x0000555aeff1df9b do_cmdline (nvim)
                                              #31 0x0000555aefedcbfd call_user_func (nvim)
                                              #32 0x0000555aefedd590 call_func (nvim)
                                              #33 0x0000555aefee1dd2 n/a (nvim)
                                              #34 0x0000555aefee6862 ex_call (nvim)
                                              #35 0x0000555aeff1df9b do_cmdline (nvim)
                                              #36 0x0000555aeff3c3d8 n/a (nvim)
                                              #37 0x0000555aeff3d137 apply_autocmds (nvim)
                                              #38 0x0000555aeff6be03 getout (nvim)
                                              #39 0x0000555aeff0254e do_wqall (nvim)
                                              #40 0x0000555aeff1df9b do_cmdline (nvim)
                                              #41 0x0000555aeff9a208 n/a (nvim)
                                              #42 0x0000555aeffa3377 n/a (nvim)
                                              #43 0x0000555af0035c10 state_enter (nvim)
                                              #44 0x0000555aeff9a78a normal_enter (nvim)
                                              #45 0x0000555aefe795aa main (nvim)
                                              #46 0x00007f3188b93223 __libc_start_main (libc.so.6)
                                              #47 0x0000555aefe7a56a _start (nvim)
-- Subject: Process 10841 (nvim) dumped core
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
-- 
-- Process 10841 (nvim) crashed and dumped core.
-- 
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.

Running this on Arch linux
4.14.59-rt37-1-rt-lts

Any thoughts are much appreciated! Reboot usually solves it for a little while.