This is a nice tool; I had one of my own but never nearly as extensive as this one. Unfortunately, there seems to be an issue with variable names that are also function names. I couldn't solve it, maybe you could...
If, for example, you write
S = struct('sigma',0.25);
on the command prompt, you have that sigma is 0.25. However, if you wrap this into function test.m (not a script, a function) then you have this oddity:
Name Size Bytes Class Attributes
S 1x1 184 struct
sigma 1x1 8 double
??? Error using ==> sigma at 83
Not enough input arguments.
Error in ==> test at 5
where Matlab tries to call a function called sigma!?
A minor thing though... Under my installation, the private/ghostscript.m function had a minor bug that resulted in the whole function being whipped out and replaced by solely the 'gs' path. Just in case it happens to anyone else, here is a simple patch:
Hi Oliver, still having problems exporting patches and lines or symbol.
I can use uistack or uistack2 from the file exchange here and get good looking results BUT, if I export PDF using export_fig the patch is always in front of everything else. Maybe you can look into that and fix it! thanks Arnold.
I encountered the exact same name collision problem that Christian Dorion mentioned in his comment below. If I unpack a structure in a function, and one of the resulting variable names is also a function name (it was "ngrid" in my case), then Matlab interprets the variable name as a function call. The strangest think is that if I do a "who" or "which" within the function, then Matlab correctly reports that ngrid is a variable. But then it fails to interpret it correctly. I have a very hard time coming up with an explanation for this behavior. Anyone?