https://linen.dev logo
Powered by
# haxe-ui
  • b
    but your bulk standard "make this this colour" is actually pretty straight forward
  • b
    weirdly, i cant seem to find implementations for existing lexers (like wxSTC_LEX_XML) though
  • b
    > There is some "hook" that calls a custom style routine that you can set in your own part without modifying wxWidgets itself. It is the LEX_CONTAINER "lexer". If you set this, STC will call an event each time style is needed
  • b
    well, its certainly doable:
  • p
    Oh thats very nice!
  • b
    Copy code
    json
{
    "defaults": {
        "foreground": "0x9CDCFE",
        "background": "0x1E1E1E",
        "caret": "0xFFFFFF",
        "selection": "0x4E4E4E",
        "fontSize": 14
    },
    "formatting": [
        {
            "foreground": "0x5499D2",
            "rules": [
                "mut",
                "func"
            ]
        },
        {
            "foreground": "0xCE9178",
            "rules": [
                "'.*'"
            ]
        },
        {
            "foreground": "0xDCDCAA",
            "rules": [
                "(?<=\\.).*(?=\\()"
            ]
        }
    ]
}
  • b
    not plugged into haxeui-code-editor (this is just "raw" hxWidgets)... but i think it certainly could be, and be useful
  • p
    would love to use it once its ready
  • b
    sure, ill ping you once its in and ive had a proper play with it, would be interesting to see if its "up for the task" wrt to your editor / viewer
  • b
    would also be nice to see if i could use that same format to create syntax rules for monaco too
  • b
    what font name were you using btw?
  • p
    Consolas
  • b
    👍
  • b
    ... i like it 🙂
  • b
    using regexp, so not 100% ideal, but alot better than nothing and alot easier than first assumed
  • b
    Have some issues compiling a haxeui-hxwidgets project with the haxe server on
  • b
    first this path isn't the same as compiling without the server
  • b
    then it gives an error like this
  • b
    is this more likely to be something to do with hxcpp?
  • b
    hmmm, hard to say really... does a "normal" command line compile work?
  • b
    If i remove the --connect 6000 everything works fine
  • b
    right... so its the language server acting up... im not 100% sure what to do about these kinds of things... things similar have been going on for a while (with vscode for example)... ive tried (and failed) to sort it out a few times
  • b
    i think it caches, or doesnt cache certain things... i cant remember which way round it is
  • b
    Hm, that seems odd, i guess it works if i turn off the server so it's not like it's impossible to work around
  • b
    yeah, its a less than idea solution, im certainly all ears to possible fixes, but ive heard the language server has issues with macros in general (not all, but i dont understand what "type" of macros it doesnt play well with)
  • b
    its shame though really, as its totally valid haxe (hence the good compile without the server)
  • b
    in a perfect world the language server would work with all valid haxe code (including macros) but it doesnt seem to be the case... and im hesitant to be making huge edits to haxeui in order to appease, what seems to be, a semi broken language server
  • b
    that said, if changes in haxeui can appease the language server and not have some big impact on haxeui (which im hoping is the case) then im more than happy to include them
  • b
    It seems to be unable to access the environment variable for hxwidgets and it can't find the .hxcpp_config.xml, wouldn't that be beyond something that can be changed in haxeui?
  • b
    yeah, that does sound like an hxcpp issue
1...550551552...1687Latest