When using Edit mode, to move or resize widgets, each movement of the respective widget adds new text to the source code, making it more or less unreadable (and perhaps unusable? Did not try that).
Of course, I can resize or position the widgets manually using coordinates in the source code, but doing it graphically could be a bit easier…
Am I doing something wrong?
I think there is a rogue identifier that is causing the issue here. If you create a new instrument and add some controls it works fine right? I wonder if you can identifier what causes the formatting issue to take place? Btw, are you using the latest beta version? Or are you using 2.9?
I still use 2.9.0.
Indeed, edit mode works fine for new instruments, but not for pre-existing ones. Good to know.
Willl try to find out, whether the is an entry, that confuses cabbage.
I’ve experienced this many times, and have stopped using the Edit mode because of this. Only using bounds() at the moment.
IMO, the Cabbage-section should be as strict as Csound when detecting syntax errors, but @rorywalsh might disagree 
Could nail the problem down a bit. Started with a new project, added some code and when I added this, the problem occured:
#define SLIDER1 textColour ( 0, 0, 0), trackerColour (170, 170, 170)
rslider $SLIDER1 bounds ( 12, 14, 105, 101), channel ("att"), range (0.01, 20, 1, 1, 0.01), text ("Attack")
Same situation with this:
#define COMBO1 colour (170, 170, 170), fontColour (0, 0, 0)
combobox $COMBO1 bounds ( 20, 160, 200, 30), channel ("pol"), items("0", "2", "4", "6"), text ("Off", "2", "4", "6"), value(1)
Even if I remove the #define (i.e. use the default colours), the problem persists. Something wrong with the rslider or combobox definition?
On the other side - this works fine:
#define LABEL1 textColour ( 0, 0, 0), fontColour (0, 0, 0)
label $LABEL1 bounds(50, 164, 250, 30), text ("HPF Filter Poles:")I am seeing the same destructive behaviour using curly brackets to create groups, the following gets destroyed badly when trying to move things:
image bounds (0, 0, 270, 170)
{
image bounds(10, 10, 250, 50) colour(0, 255, 255, 255)
{
hslider bounds(0, 10, 240, 50) channel("band") range(0.0010, 1.5, .17, 1, 0.001) align("top")
label bounds(0, -8, 250, 30) text("FREQ SPREAD") fontSize(12) align ("centre")
label bounds(0, 10, 250, 20) text("Focused <-------------------> Diffuse") fontSize(10) align ("centre")
}
image bounds(10, 60, 250, 50) colour(100, 255, 255, 255)
{
hslider bounds(0, 10, 240, 50) channel("dur") range(0.01, 2.5, 0.17, 1, 0.001)
label bounds(0, -8, 250, 30) text("DURATION") fontSize(12) align ("centre")
label bounds(0, 10, 250, 20) text("Short <-------------------> Long") fontSize(10) align ("centre")
}
image bounds(10, 110, 250, 50) colour(200, 255, 255, 255)
{
hslider bounds(0, 10, 250, 50) channel("rate") range(0.1, 2, 0.17, 1, 0.001)
label bounds(0, -8, 250, 30) text("RATE") fontSize(12) align ("centre")
label bounds(0, 10, 250, 20) text("Fast <-------------------> Slow") fontSize(10) align ("centre")
}
}Thanks guys I’ll take a look when I get a chance 
Hi @stefanv, I’m jut getting around to looking at this now. I don’t doubt that there is a problem here but I can’t seem to recreate it. Check the screengrab below. Note I obviously have to hit save after I enter the text in order to make it appear.
Would you mind posting a video, or explicitly outlining the steps I need to take in order to recreate the problem. Thanks.
I just noticed now that you have sub groups in this. The dynamic syntax system was never really designed to handle this kind of complexity. 
Any chance you could describe to me the simplest way I can recreate the problem on my end?
I use curly brackets (Plants), with a label as the container, and with slider inside. Try to move the widget in GUI-editor with this example. It will do all sorts of odd stuff.
<Cabbage>
form caption("Untitled") size(400, 300), guiMode("queue"), pluginId("def1")
keyboard bounds(8, 158, 381, 95)
label bounds(0, 78, 80, 16) channel("label10002") {
rslider channel("rslider10001") channel("rslider10001") range(0, 1, 0, 1, 0.001)
}
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 --midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
; Initialize the global variables.
ksmps = 32
nchnls = 2
0dbfs = 1
;instrument will be triggered by keyboard widget
instr 1
kEnv madsr .1, .2, .6, .4
aOut vco2 p5, p4
outs aOut*kEnv, aOut*kEnv
endin
</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
</CsScore>
</CsoundSynthesizer>Yup, that does the trick alright 
this isn’t going to be easy but I’ll try to find a fix for it.
What I do, is very simple:
Result: garbage.
That’s all.
Two things here seems to break things. 1) The tab indentation, and 2) the fact you have no bounds set for the label.
I can’t seem to recreate this here? Can you spot anything I’m not doing? It does add a few colour identifiers, but that’s not so bad.
Very strange…
I used the built-in windows recorder, so I can show only the cabbage window, not the plugin…
…and now the video is too big. Pls. find the link to the video here (valid for one week):
Great - that does the trick! Problem solved!!!
(But does not improve raedability… )
No, but at least we know now what is causing the issue. I have some place to start 
I pushed a fix for this now. While some of the use cases above still result in issues (1, 2), adding spaces or tabs to the starts of lines in order to create a better formatted document should no longer results in garbage. So @stefanv, you should be free to add as many tabs/spaces as you like from now on.