Loading syntax highlighting themes

Thank you for this example. I see an immediate application of the YAML format for something that I am developing.

I am curious how the in-line STRUCT definition does not throw an error. Somehow, in the far corners of my memory, I seem to recall reading that STRUCT definitions have to be on separate lines, not in-line, for function definitions. Also, the definition seems to have a mistake in spacing that does not throw even a warning???

STRUCT RGBColor &color    NOT      STRUCT RGBColor& color

Inspired by your creation, I post below a snippet for a generic YAML loader. The mstr is the message string. The vstr in the validator string. The YAML is loaded into a text wave called YAMLwave. A return of -1 to -4 with YAMLwave having no row length means nothing was loaded for various reasons (parsed by the return value). Note that position [0, 0] in the YAMLwave text wave is the validator string, with [0, 1] as a blank.

Function load_YAML(string mstr, string vstr)
 
    variable refNum, slen
    string fileFilters = "(*.yml, *.yaml):.yml, .yaml;"
    string fName, line = ""
    
    // make storage text wave
    make/N=(0,2)/T/O YAMLwave
    YAMLwave = ""
    
    // open the file
    open/R/F=(fileFilters)/M=mstr refNum
    if (strlen(s_fileName) == 0)
        return -1
    endif   
    fName = s_fileName
    
    // validate the first line
    FReadLine refnum, line
    slen = strlen(line)
    close refNum
    if (slen != 0)
        if (cmpstr(line[0,slen-3],vstr) != 0)       
            return -2
        endif
    else
        return -3
    endif
    
    // load the text wave
    loadwave/A=YAML/J/K=2/M/V={":","",0,1} fName
    fName = StringFromList(0,s_wavenames)
    wave/T yw = $fName
    if (DimSize(yw,0) != 0)
        duplicate/O/T yw YAMLwave
    else
        killwaves/Z yw
        return -4
    endif
 
    killwaves/Z yw  
    return 0
end

I would parse the text wave as the next step.

Now a question. What would you suggest to someone who would want to operate with one YAML file that has multiple themes rather than multiple YAML files, each with their own theme? Good idea, bad idea, or ... just neutral at this point?

theme: 
  name: Desert Sage
  keyword: #6288ba
  comment: #989898
  string: #cb8076
  operation: #739079
  bifunction: #b98a51
  userfunction: #b98a51
  directive: #c76060
  opkey: #4f92c5
theme: 
  name: Monochrome
  keyword: #989898
  comment: #989898
  string: #989898
  operation: #989898
  bifunction: #989898
  userfunction: #989898
  directive: #989898
  opkey: #989898
theme:
 ...

And further, in case you wonder, I am building a way to use YAML to store graph styles that can be applied through popup control menus.

I answered my own question. The more robust approach is to keep each YAML as its own file at the OS level.

Here is a function to recast a YAML text wave into a text wave with the (theme or whatever) name. The first row after the validation string must be of the form "name: (name)"

Function recast_YAML(wave/T ywave)
 
    variable npts = DimSize(ywave,0)
    string wname
    
    duplicate/FREE/T ywave twave
 
    // remove tab characters
    twave[][] = ReplaceString("\t",twave[p][q],"")
 
    // validate that name exists
    if (cmpstr(twave[1][0],"name") != 0)
        return -1
    endif
    
    // clean up wave first and last blank
    DeletePoints 0,1, twave
    if (cmpstr(twave[npts-2][0],"") == 0)
        DeletePoints (npts-2),1, twave
    endif
 
    // create new text wave
    wname = twave[0][1]
    duplicate/O twave, $wname
    
    return 0
end

The approach is to load_YAML(...), recast_YAML(...), and process_YAML(...), with the latter written to carry out whatever coding is needed. With the YAML in a text matrix, the process_YAML code does not need to use the SplitString operation to pull off two sides around a colon.

I will post the code in a separate snippet.

I am curious how the in-line STRUCT definition does not throw an error. Somehow, in the far corners of my memory, I seem to recall reading that STRUCT definitions have to be on separate lines, not in-line, for function definitions. Also, the definition seems to have a mistake in spacing that does not throw even a warning???

You're right that (maybe all) of our examples in the documentation use the old-style structure definitions that are on a separate line, but I think inline should be fine. As for the position of the ampersand, that's mostly a matter of personal preference -- both of these are acceptable to the compiler, similar to how passing references or pointers works in C++.

struct RGBColor& color
 
struct RGBColor &color

I find the first example easier to read, where the type can be read more clearly as 'RGBColor reference' and the name is 'color.