Just to chime in, I edit all my Csound code, Cabbage stuff included, using Vim with Luis Jure’s Csound plugin and am generally very pleased with that setup. Editing source files with Vim and running them from Cabbage works pretty seamlessly in my experience. Even the main Cabbage program works fine as long as you just press the play button and don’t try to save the code from within the editor.
Editor very slow when csound source code is big
I gived up on using the editor integrated in Cabbage, because with my actual csound code (about 1600 lines) the editor is unbearably slow when I use my notebook in power saving mode (I don’t like the CPU fan runs at full speed only to edit a text file!).
Fortunately, the CabbageLite solution is very good for me. On Windows now I use CabbageLite with Notepad++, an open-source text-editor that is really really fast, despite all its features. With it you can easily define your User Defined Language for syntax highlighting and other things.
For those interested I attached an XML file you can import in Notepad++ to have the syntax highlighting for Csound code. 
myCSOUND.xml (14.8 KB)
I use Visual Studio Code quite a lot these days. It has a Csound package, as too does Atom. That one is very nice.
I tried Atom on a Linux machine… It’s a very cool-looking text editor! It has a very nice and clean graphic style and I like the easyness with which you can display multiple documents next to each other. But with the Csound language pack installed, I think the auto-completion feature is so invasive that it’s annoying and I don’t know how to disable it (if you can).
File an issue on his github page. He usually responds quite quickly
I noticed that (on Windows) Atom installation file is 145MB vs 4.4MB of Notepad++ !!!
If I have to use an external text-editor with Cabbage, I prefer a little and fast one, so I think on Windows I will stick to Notepad++ (that does all I want: syntax highlighting, not-too-invasive code-completion, function list, code-folding, multi-document, multi-view, is fully customizable and… I already said this, but it’s very fast!!).
I just found that there is a “Notepad++”-inspired text-editor on Linux too: it’s called Notepadqq… I have to try it!
The other thing about Atom and Visual Code is they are Electron based, meaning they are huge memory consumers. Check these benchmarks. It’s almost impressive how much memory they use.
It’s really crazy… Now I have Notepad++ open with 8 tabs (8 different source code files) and the memory occupied is just 18MB of which 5MB are used by Notepad++ only and 13MB are shared with other apps. And Atom would use 256MB with only a single little file open? This is not my “idea” of text-editor… I know today we have plenty of RAM, but… I don’t know, maybe I’m too old-school…
P.S.: do the JUCE guys know of the editor slowness with big files? Do you think they will fix it soon?
I don’t think they will any time soon, it seems to be low priority with them. I must check if it’s sluggish on Windows and OSX. On Linux I found scrolling to be slow with very large files. I’ll check and if so I’ll get back to the JUCE guys and ask what’s up.
If it can help you, with my csound file (about 1630 lines), in Cabbage 2.0 (on a Windows 10 laptop in power saving mode), there are at least 1 or 2 seconds of lag between a key press and the display of a character in the editor area. But the strange thing is that sometimes I see a similar lag with a little file too… I think there could be something wrong with JUCE editor syntax highlighting routines (or the code that parses a line and display the opcode parameters in the helper bar under the editor area) that put too much stress on the CPU. Or maybe the regular expressions used are too complex. Have you tried to check if the editor control is slow without syntax highlighting or other things activated too?
Actually, this shouldn’t happen. I thought it was just a scrolling thing? I’ll take a look tomorrow.
I tested some of Iain’s largest instruments and I could not recreate this, even with the auto-complete enabled in Cabbage. Even files of over 10,000 lines cause me no issues (apart from sluggish scrolling). The latest Cabbage version is 2.02, is this the one you’re using?
First of all, thank you for your tests.
The version I use is Cabbage 2.0.02 on Windows 10 v1803. The problem of the keyboard lag is the most annoying thing for me.
But now I’m astonished: I tried to delete the “Cabbage2.settings” file to let Cabbage recreate it, but the editor was always slow so I restored the old file with my settings (I use customized colours). Then I tried to change my screen resolution and Cabbage editor was slow as before. Then I tried to change the default GPU associated to Cabbage process (I have 2 GPU: one integrated and another dedicated) but the result was the same. At this point I returned to the original screen resolution I used and the original GPU (the integrated one) association with the Cabbage executable file and… PUFF! Now Cabbage editor is fast in the scrolling and the keyboard lag is gone with the same file that 5 minutes ago was slow as hell!! Honestly, I don’t know what happened… Maybe some bug with the GPU intel integrated driver (but it’s strange that it only affects Cabbage editor)… Now I am curious to see how long it lasts before going back to being slow… 
Me too. Hopefully it’s sorted now
Try to load the attached file in Cabbage.
Now try to scroll the vertical bar. It should be fast.
Ok, now add a " (double quote) character at the beginning of the file. Try to scroll now…
testText.txt (390.3 KB)
Another test: take the previous attached file “testText.txt” and rename it as a .csd file. Now try to load it in Cabbage… The editing it’s not as fast as when it had a “.txt” extension, but it’s still reasonable.
Now try to add a
/*
at the beginning of the file… The editor becomes much slower than before and if you use a notebook you will notice that your mobile CPU has to increase its frequency to the max only to make you add some characters in the editor at a reasonable speed.
This is the JUCE code editor. It’s always been the weakest component of the JUCE framework. Try building the JUCE demo and doing a similar test in the code editor example. You’ll see the same behaviour. I recently looked into using a different editor with Cabbage, a fast JS editor that I could load in a browser component, but JUCE doesn’t really have very good browser support either. It works, but once the browser has focus, keyboard shortcuts no longer work. It’s a real pity because the current editor is slow.
But I don’t understand why when you load a simple text file in Cabbage, there are some things that get highlighted (and it slows down) if you use double quotes… This is a normal behaviour for the JUCE code editor?
It seems that this is normal behaviour for the JUCE code editor. Try it yourself with the JUCE demo. I did last night and found the same behaviour. I was following this thread for a while. It looked promising but then development seemed to fizzle out. Might be an idea to try it out and see how it compares to the native JUCE component.
A much better programmer than I once tried to embed Scintella into a JUCE project, but had quite a few problems with it.
Do Juce devs know that their code editor component has some serious performance troubles or they are convinced that it has no problems? Maybe we could submit to their attention that file I attached before and see what they say on this matter… I would do it myself but actually I don’t know nothing of how Juce works, so I would be a little embarassed…
[quote=“rorywalsh, post:27, topic:1065”]
A much better programmer than I once tried to embed Scintella into a JUCE project, but had quite a few problems with it.
[/quote]That would be very good. Scintilla is a great and light source code editor component and it’s used by some very nice and efficient text editors (like Notepad++ on Windows, or Geany on Linux/Windows/OSX).