Tree sitter grammar for Svelte



Tree-sitter grammar for svelte


npm i tree-sitter-svelte tree-sitter


To get started with exploring the grammar in a web-ui. Run:

NOTE: emcc must be installed and in your path

npm run ui

To use the grammar from javascript:

const Parser = require("tree-sitter");
const Svelte = require("tree-sitter-svelte");

const parser = new Parser();

const sourceCode = `
<script context="module">
    let name = 'world';
<h1>Hello {name'<>{}``"\\''""``{}}!</h1>

const tree = parser.parse(sourceCode);

// (document
//    (script_element
//        (start_tag (tag_name)
//            (attribute (attribute_name) (quoted_attribute_value (attribute_value))))
//        (raw_text)
//        (end_tag (tag_name))
//    )
//    (element
//        (start_tag (tag_name))
//        (text) (raw_text_expr) (text)
//        (end_tag (tag_name)
//    )
//  )


  • Move all C++ functions to C
    • TagVector
    • Tag
    • cstring
    • zzzAllocator



  • each with round brackets breaks highlighting

    each with round brackets breaks highlighting

    Hi! Thanks for your work! :slightly_smiling_face:

    I've found an issue with highlighting when round brackets are present in the each block.

    {#each someFunc(someArr) as someItem (}
    {#each someArr.filter(someFunc) as someItem (}

    Also do you know by any chance where should I post about indent issues? :thinking:

    opened by non25 10
  • feature request: treat any node between special block as its childnode

    feature request: treat any node between special block as its childnode

    I think it would be better if a node between special_block is treated as its childnode. Consider the following snippet

    {#if something}

    Both <div /> element will be considered as a sibling node instead of special_block's childnode. Treating them as a childnode makes more sense in my opinion, similar to how if else expression in Javascript where anything inside {} is treated as a childnode.

    I rely on this for indent feature that nvim-treesitter has. I don't know how hard is this to implement so if it's not possible then feel free to close this issue :) Thanks in advance!

    opened by elianiva 10
  • Seg fault with Neovim

    Seg fault with Neovim

    I'm running Neovim on the latest HEAD. And since I think the last few commits it SEG faults when opening Svelte files. Any idea how I fix or debug this?


    Process:               nvim [8532]
    Path:                  /usr/local/Cellar/neovim/HEAD-0ab88c2_1/bin/nvim
    Identifier:            nvim
    Version:               ???
    Code Type:             X86-64 (Native)
    Parent Process:        zsh [2139]
    OS Version:            macOS 11.2.3 (20D91)
    Report Version:        12
    Crashed Thread:        0  Dispatch queue:
    Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes:       EXC_I386_GPFLT
    Exception Note:        EXC_CORPSE_NOTIFY
    Termination Signal:    Segmentation fault: 11
    Termination Reason:    Namespace SIGNAL, Code 0xb
    Terminating Process:   exc handler [8532]
    Thread 0 Crashed:: Dispatch queue:
    0                     	0x00000001042e0062 hashmap_put + 91
    1                     	0x00000001042e02ad hashmap_put + 678
    2                     	0x00000001042deafb tree_sitter_svelte_external_scanner_create + 939
    3   libtree-sitter.0.dylib        	0x0000000103fa04d9 ts_parser_set_language + 75
    4   vim                           	0x0000000103cdc2fb tslua_push_parser + 108
    5   libluajit-5.1.2.dylib         	0x0000000103fd29c5 lj_BC_FUNCC + 68
    Thread 1:
    0   libsystem_pthread.dylib       	0x00007fff205e2458 start_wqthread + 0
    Thread 2:
    0   libsystem_kernel.dylib        	0x00007fff205b67e2 kevent + 10
    1   libuv.1.dylib                 	0x0000000103f34461 uv__io_poll + 871
    2   libuv.1.dylib                 	0x0000000103f24ec6 uv_run + 359
    3   vim                           	0x0000000103c7036c loop_poll_events + 137
    4   vim                           	0x0000000103dc9bf2 tui_main + 797
    5   libsystem_pthread.dylib       	0x00007fff205e6950 _pthread_start + 224
    6   libsystem_pthread.dylib       	0x00007fff205e247b thread_start + 15
    Thread 0 crashed with X86 Thread State (64-bit):
      rax: 0x0000000000000000  rbx: 0x00000001042e0590  rcx: 0x0000000000000000  rdx: 0x656e223d66657268
      rdi: 0x0000000000000000  rsi: 0x00007ffeec037580  rbp: 0x00007ffeec037550  rsp: 0x00007ffeec0374d0
       r8: 0x00000000642d7377   r9: 0x0000000000000100  r10: 0x0000000000000000  r11: 0x0000000000050000
      r12: 0x0000000000000000  r13: 0x00007ffeec037580  r14: 0x0000000000000000  r15: 0x00007fcb380a8840
      rip: 0x00000001042e0062  rfl: 0x0000000000010246  cr2: 0x00007fcb380a9440
    Logical CPU:     3
    Error Code:      0x00000000
    Trap Number:     13
    Thread 0 last branch register state not available.
    Binary Images:
           0x103bc2000 -        0x103e4dfff +vim (0) <297623E3-5B78-3AD4-A168-57E05941A519> /usr/local/bin/vim
           0x103f07000 -        0x103f10fff +libintl.8.dylib (0) <FA921CC0-395B-3155-8259-EA61DE25C5D2> /usr/local/opt/gettext/lib/libintl.8.dylib
           0x103f1e000 -        0x103f39fff +libuv.1.dylib (0) <AB054F09-01C5-3967-8AC3-AD2C02277737> /usr/local/opt/libuv/lib/libuv.1.dylib
           0x103f55000 -        0x103f59fff +libmsgpackc.2.dylib (0) <948223FF-9AE0-3DA0-A554-7A368A42E966> /usr/local/opt/msgpack/lib/libmsgpackc.2.dylib
           0x103f64000 -        0x103f6dfff +libvterm.0.dylib (0) <0F941D08-A254-3C55-8F40-19436071F61D> /usr/local/opt/libvterm/lib/libvterm.0.dylib
           0x103f72000 -        0x103f77fff +libtermkey.1.dylib (0) <BF173A8F-189B-36FE-883B-C2122522721B> /usr/local/opt/libtermkey/lib/libtermkey.1.dylib
           0x103f82000 -        0x103f89fff +libunibilium.4.dylib (0) <05759550-C0EC-3345-8BAD-D2A91463F56A> /usr/local/opt/unibilium/lib/libunibilium.4.dylib
           0x103f99000 -        0x103fb8fff +libtree-sitter.0.dylib (0) <20E756EB-B6BE-3B0B-AD96-B6EFCC43160B> /usr/local/opt/tree-sitter/lib/libtree-sitter.0.dylib
           0x103fcc000 -        0x10402ffff +libluajit-5.1.2.dylib (0) <540EF076-821F-3548-91EF-4144C17ABD7B> /usr/local/opt/luajit-openresty/lib/libluajit-5.1.2.dylib
           0x1042d9000 -        0x1042e0fff (0) <8AE79FAB-FD8A-3E1A-B02C-D3CF9A57ADC7> /Users/USER/*/
           0x10e3ad000 -        0x10e448fff  dyld (832.7.3) <0D4EA85F-7E30-338B-9215-314A5A5539B6> /usr/lib/dyld
        0x7fff2031b000 -     0x7fff2031cfff  libsystem_blocks.dylib (78) <E644CAA0-65B7-36E4-8041-520F3301F3DB> /usr/lib/system/libsystem_blocks.dylib
        0x7fff2031d000 -     0x7fff20352fff  libxpc.dylib (2038.80.3) <70F26262-01AA-3CEC-9FAD-2701D24096F0> /usr/lib/system/libxpc.dylib
        0x7fff20353000 -     0x7fff2036afff  libsystem_trace.dylib (1277.80.2) <87FEF600-48D9-31C9-B8FC-D5249B2AE95D> /usr/lib/system/libsystem_trace.dylib
        0x7fff2036b000 -     0x7fff2040afff  libcorecrypto.dylib (1000.80.5) <1EB11CFB-ABD7-36DD-97C7-C112A6601416> /usr/lib/system/libcorecrypto.dylib
        0x7fff2040b000 -     0x7fff20437fff  libsystem_malloc.dylib (317.40.8) <A498D1EF-E43D-310C-84E8-9C0AADA0C475> /usr/lib/system/libsystem_malloc.dylib
        0x7fff20438000 -     0x7fff2047cfff  libdispatch.dylib (1271.40.12) <AD988EEA-1A2F-3404-9A6E-390FC2504223> /usr/lib/system/libdispatch.dylib
        0x7fff2047d000 -     0x7fff204b5fff  libobjc.A.dylib (818.2) <EB6B543F-D42C-3FB2-A2EC-43407C5F80D3> /usr/lib/libobjc.A.dylib
        0x7fff204b6000 -     0x7fff204b8fff  libsystem_featureflags.dylib (28.60.1) <9CECB43A-094E-3CA9-B730-24DEA1A6DE05> /usr/lib/system/libsystem_featureflags.dylib
        0x7fff204b9000 -     0x7fff20541fff  libsystem_c.dylib (1439.40.11) <4AF71812-4099-3E96-B271-1F259491A2B2> /usr/lib/system/libsystem_c.dylib
        0x7fff20542000 -     0x7fff20597fff  libc++.1.dylib (904.4) <B217D905-4F9C-3DE0-8844-88FAA3C2C851> /usr/lib/libc++.1.dylib
        0x7fff20598000 -     0x7fff205b0fff  libc++abi.dylib (904.4) <3C9FE530-3CD2-3A64-8A36-70816AEBDF0D> /usr/lib/libc++abi.dylib
        0x7fff205b1000 -     0x7fff205dffff  libsystem_kernel.dylib (7195.81.3) <AB413518-ECDE-3F04-A61C-278D3CF43076> /usr/lib/system/libsystem_kernel.dylib
        0x7fff205e0000 -     0x7fff205ebfff  libsystem_pthread.dylib (454.80.2) <B989DF6C-ADFE-3AF9-9C91-07D2521F9E47> /usr/lib/system/libsystem_pthread.dylib
        0x7fff205ec000 -     0x7fff20626fff  libdyld.dylib (832.7.3) <4641E48F-75B5-3CC7-8263-47BF79F15394> /usr/lib/system/libdyld.dylib
        0x7fff20627000 -     0x7fff20630fff  libsystem_platform.dylib (254.80.2) <1C3E1A0A-92A8-3CDE-B622-8940B43A5DF2> /usr/lib/system/libsystem_platform.dylib
        0x7fff20631000 -     0x7fff2065cfff  libsystem_info.dylib (542.40.3) <0C96CFE8-71F5-3335-8423-581BC3DE5846> /usr/lib/system/libsystem_info.dylib
        0x7fff2065d000 -     0x7fff20af8fff (6.9 - 1774.101) <2A0E160E-9EE6-3B23-8832-6979A16EC250> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
        0x7fff227e9000 -     0x7fff22a4afff  libicucore.A.dylib (66109) <8F8D8A8B-4EE0-3C09-9F45-725A1FBDD38C> /usr/lib/libicucore.A.dylib
        0x7fff22a4b000 -     0x7fff22a54fff  libsystem_darwin.dylib (1439.40.11) <E016D8F7-C87F-36F8-B8A0-6A61B8E4BACB> /usr/lib/system/libsystem_darwin.dylib
        0x7fff22e66000 -     0x7fff22e71fff  libsystem_notify.dylib (279.40.4) <B2BF20C7-448A-3FBD-A2F5-AB7618D173F6> /usr/lib/system/libsystem_notify.dylib
        0x7fff24dc2000 -     0x7fff24dd0fff  libsystem_networkextension.dylib (1295.80.3) <5213D866-7D0E-3FD9-8E1A-03C0E39CEC44> /usr/lib/system/libsystem_networkextension.dylib
        0x7fff24e2e000 -     0x7fff24e44fff  libsystem_asl.dylib (385) <5B48071E-85EB-33B0-AE9B-127AEB398AEC> /usr/lib/system/libsystem_asl.dylib
        0x7fff2652d000 -     0x7fff26534fff  libsystem_symptoms.dylib (1431.40.36) <BC85B46C-02EE-31FF-861D-F0DE01E8F6CF> /usr/lib/system/libsystem_symptoms.dylib
        0x7fff2857d000 -     0x7fff2858dfff  libsystem_containermanager.dylib (318.80.2) <6F08275F-B912-3D8E-9D74-4845158AE4F3> /usr/lib/system/libsystem_containermanager.dylib
        0x7fff2928a000 -     0x7fff2928dfff  libsystem_configuration.dylib (1109.60.2) <4917D824-4DE8-32CC-9ED2-1FBF371FEB9F> /usr/lib/system/libsystem_configuration.dylib
        0x7fff2928e000 -     0x7fff29292fff  libsystem_sandbox.dylib (1441.60.4) <5F7F3DD1-4B38-310C-AA8F-19FF1B0F5276> /usr/lib/system/libsystem_sandbox.dylib
        0x7fff29f96000 -     0x7fff29f98fff  libquarantine.dylib (119.40.2) <40D35D75-524B-3DA6-8159-E7E0FA66F5BC> /usr/lib/system/libquarantine.dylib
        0x7fff2a518000 -     0x7fff2a51cfff  libsystem_coreservices.dylib (127) <529A0663-A936-309C-9318-1B04B7F70658> /usr/lib/system/libsystem_coreservices.dylib
        0x7fff2a733000 -     0x7fff2a77afff  libsystem_m.dylib (3186.40.2) <DD26CC5C-AFF6-305F-A567-14909DD57163> /usr/lib/system/libsystem_m.dylib
        0x7fff2a77b000 -     0x7fff2a77bfff  libcharset.1.dylib (59) <D14F9D24-693A-37F0-8F92-D260248EB282> /usr/lib/libcharset.1.dylib
        0x7fff2a77c000 -     0x7fff2a781fff  libmacho.dylib (973.4) <C2584BC4-497B-3170-ADDF-21B8E10B4DFD> /usr/lib/system/libmacho.dylib
        0x7fff2a79e000 -     0x7fff2a7a9fff  libcommonCrypto.dylib (60178.40.2) <822A29CE-BF54-35AD-BB15-8FAECB800C7D> /usr/lib/system/libcommonCrypto.dylib
        0x7fff2a7aa000 -     0x7fff2a7b4fff  libunwind.dylib (200.10) <1D0A4B4A-4370-3548-8DC1-42A7B4BD45D3> /usr/lib/system/libunwind.dylib
        0x7fff2a7b5000 -     0x7fff2a7bcfff  liboah.dylib (203.30) <44C477D9-013F-3A6D-A9FE-68A89214E6A5> /usr/lib/liboah.dylib
        0x7fff2a7bd000 -     0x7fff2a7c7fff  libcopyfile.dylib (173.40.2) <39DBE613-135B-3AFE-A6AF-7898A37F70C2> /usr/lib/system/libcopyfile.dylib
        0x7fff2a7c8000 -     0x7fff2a7cffff  libcompiler_rt.dylib (102.2) <62EE1D14-5ED7-3CEC-81C0-9C93833641F1> /usr/lib/system/libcompiler_rt.dylib
        0x7fff2a7d0000 -     0x7fff2a7d2fff  libsystem_collections.dylib (1439.40.11) <C53D5E0C-0C4F-3B35-A24B-E0D7101A3F95> /usr/lib/system/libsystem_collections.dylib
        0x7fff2a7d3000 -     0x7fff2a7d5fff  libsystem_secinit.dylib (87.60.1) <E05E35BC-1BAB-365B-8BEE-D774189EFD3B> /usr/lib/system/libsystem_secinit.dylib
        0x7fff2a7d6000 -     0x7fff2a7d8fff  libremovefile.dylib (49.40.3) <5CC12A16-82CB-32F0-9040-72CFC88A48DF> /usr/lib/system/libremovefile.dylib
        0x7fff2a7d9000 -     0x7fff2a7d9fff  libkeymgr.dylib (31) <803F6AED-99D5-3CCF-B0FA-361BCF14C8C0> /usr/lib/system/libkeymgr.dylib
        0x7fff2a7da000 -     0x7fff2a7e1fff  libsystem_dnssd.dylib (1310.80.1) <E0A0CAB3-6779-3C83-AC67-046CFE69F9C2> /usr/lib/system/libsystem_dnssd.dylib
        0x7fff2a7e2000 -     0x7fff2a7e7fff  libcache.dylib (83) <1A98B064-8FED-39CF-BB2E-5BDA1EF5B65A> /usr/lib/system/libcache.dylib
        0x7fff2a7e8000 -     0x7fff2a7e9fff  libSystem.B.dylib (1292.60.1) <83503CE0-32B1-36DB-A4F0-3CC6B7BCF50A> /usr/lib/libSystem.B.dylib
        0x7fff2a7ea000 -     0x7fff2a7edfff  libfakelink.dylib (3) <D939A124-9FD5-37A2-B03B-72E98CBC98FE> /usr/lib/libfakelink.dylib
        0x7fff2a7ee000 -     0x7fff2a7eefff (1.0 - 1) <EF2AC5FF-B98D-3252-ABA8-2FC721CBA942> /System/Library/PrivateFrameworks/SoftLinking.framework/Versions/A/SoftLinking
        0x7fff2a827000 -     0x7fff2a917fff  libiconv.2.dylib (59) <AD10ECF4-E137-3152-9612-7EC548D919E8> /usr/lib/libiconv.2.dylib
        0x7fff2af8f000 -     0x7fff2af92fff  libutil.dylib (58.40.2) <0A268749-08E7-3551-8969-442210651CCA> /usr/lib/libutil.dylib
        0x7fff2dc21000 -     0x7fff2dc21fff  liblaunch.dylib (2038.80.3) <C7C51322-8491-3B78-9CFA-2B4753662BCF> /usr/lib/system/liblaunch.dylib
        0x7fff300d5000 -     0x7fff300d5fff  libsystem_product_info_filter.dylib (8.40.1) <20310EE6-2C3F-361A-9ECA-4223AFC03B65> /usr/lib/system/libsystem_product_info_filter.dylib
    opened by jgelens 9
  • feature request: move `as` to its own keyword

    feature request: move `as` to its own keyword

    Hi there! I really appreciate the work you've put into this parser and I absolutely love it. I have an issue though. Is it possible to separate the keyword as from raw_text_expr ? Consider this snippet.

    {#each $jobs as { created_at, title, type, company, location, company_logo, id }}

    The $jobs as { created_at, title, type, company, location, company_logo, id } will get parsed as raw_text_expr. I use javascript parser to handle those bits, since as is not a valid javascript keyword, it throws an error. My idea is to make {#each foo as bar} where foo and bar is a raw_text_expr but make as a keyword similar to if_tag or else_tag.

    Here's a rough representation of how the tree would look like.

      (as_keyword) ;not sure about the name

    This doesn't cause any big impact, it still works fine but having a keyword that isn't a valid javascript syntax to be placed inside raw_text_expr isn't ideal IMO

    edit: I found another one which is {@html ...}, I think we should make @html as a keyword.


    opened by elianiva 8
  • {#if}{:else}{/if} block is missing highlight colors

    {#if}{:else}{/if} block is missing highlight colors

    Hello Himu, I have a small suggestion, I hope it's not too difficult to implement. It would be nice if the {#if} block could get some highlighting like normal ifs similar to what we have in VS Code:


    instead of what we have now:


    It definitely adds readability to the code when having the if with a highlight.

    I hope you consider it, thank you.

    opened by charbelnicolas 7
  • Minor inconsistencies with indenting

    Minor inconsistencies with indenting

    Hi, thanks for maintaining this package. Tree-sitter is awesome!

    I'm getting into svelte and I noticed minor inconsistencies but I'm not sure if it is because of this module. I'm using neovim with treesitter and lsp and have installed this language for treesitter so I think I'm in the right place, the indenting is coming from treesitter, I guess.

    Now, to the point: Untitled

    Notice how: (A) When my cursor is under <script> tag, the next line is not automatically indented. It is not considered a child node (sorry, I don't know the exact terminology you guys use for this since I'm not into this). The same goes for <style> tag. (B) When my cursor is under the html tag <main>, the next line is automatically indented. Indenting works as expected. (C) When you're already in an indented child node, the indenting works as expected for the next line.

    I think these are minor inconsistencies that thanks to (C) shouldn't be considered as a priority, but as a QoL update it would be great to have them fixed.

    Am I in the right place reporting this here? Maybe this is the intended behavior?

    opened by pmrt 7
  • Request: make WASM file available to download

    Request: make WASM file available to download

    It would be great if there was a wasm file to download as in I've tried building my own but got errors (bad magic number). Having it in a central place would also mean we could see which version of tree-sitter it has been compiled against.

    opened by gushogg-blake 7
  • Tree-sitter queries

    Tree-sitter queries

    Write Tree-sitter queries for the library.

    Hi @elianiva can you export your queries in a ./queries folder for the library. Use as a reference.

    opened by Himujjal 7
  • failed to parse certain components

    failed to parse certain components

    I noticed that certain component doesn't get parsed correctly, see this scenario for better explanation.


    The first element is parsed correctly, it looks like this:

    (document [0, 0] - [3, 0]
      (element [0, 0] - [2, 6]
        (start_tag [0, 0] - [0, 5]
          (tag_name [0, 1] - [0, 4]))
        (text [0, 5] - [1, 2])
        (element [1, 2] - [1, 18]
          (start_tag [1, 2] - [1, 8]
            (tag_name [1, 3] - [1, 7]))
          (text [1, 8] - [1, 11])
          (end_tag [1, 11] - [1, 18]
            (tag_name [1, 13] - [1, 17])))
        (text [1, 18] - [2, 0])
        (end_tag [2, 0] - [2, 6]
          (tag_name [2, 2] - [2, 5])))
      (text [2, 6] - [3, 0]))

    but the second element gets parsed as this:

    (document [0, 0] - [3, 0]
      (element [0, 0] - [1, 2]
        (start_tag [0, 0] - [0, 6]
          (tag_name [0, 1] - [0, 5])))
      (element [1, 2] - [1, 18]
        (start_tag [1, 2] - [1, 8]
          (tag_name [1, 3] - [1, 7]))
        (text [1, 8] - [1, 11])
        (end_tag [1, 11] - [1, 18]
          (tag_name [1, 13] - [1, 17])))
      (text [1, 18] - [2, 0])
      (ERROR [2, 0] - [2, 7]
        (ERROR [2, 2] - [2, 6]))
      (text [2, 7] - [3, 0]))
    test.svelte	0 ms	(ERROR [2, 0] - [2, 7])
    opened by elianiva 4
  • fix: allow script to be nested inside svelte:head

    fix: allow script to be nested inside svelte:head

    without this PR, this would break because HTML parser doesn't allow script or style tag to be nested inside another tag but in Svelte we can do that by placing them inside svelte:head

      <script>console.log("Hello World!")</script>
    opened by elianiva 4
  • The dot character in component's name breaks the highlighting

    The dot character in component's name breaks the highlighting

    Hi :wave:. It seems like having a . (dot) in a component name, breaks the highlighting (especially the css).

    For some reason, the .Root doesn't seem to have the correct highlighting, and the css's is fully absent (although I seem to be able to "fix" it when adding/removing a level of indentation).

    opened by AnatoleLucet 2
  • tree-sitter-css doesn't highlight correctly

    tree-sitter-css doesn't highlight correctly

    The grammar parser, for whatever unfathomable reason, marks the class selectors, CSS properties and various other things the same colour. See for photo examples. This issue on this repo implies that the treesitter-css parser is the only one that works with the svelte parser.

    My question: is there any way for me to use the default CSS parser instead of the treesitter one? The default CSS syntax highlighting is exactly how I want it to look, but it's physically impossible to replicate it with the treesitter-css parser.

    BTW: Loving this parser in all other facets, great work!

    opened by sammce 1
  • Error when querying with nvim-treesitter: Invalid node type at position 5 for language svelte

    Error when querying with nvim-treesitter: Invalid node type at position 5 for language svelte

      local tsparser = vim.treesitter.get_parser(0, "svelte")
      local root = tsparser:parse()[1]:root()
      local query = vim.treesitter.parse_query('svelte', [[
        (identifier) @var
      for id, captures, metadata in query:iter_matches(root,0) do

    Running the above lua code in neovim results in the error described in the title. The same snippet works fine when replacing the language, so I assume it's not an issue with nvim-treesitter. I will gladly provide any information that I can if needed.

    opened by stefanwatt 4
  • npm run ui fails on Fedora Silverblue 36 (Wayland)

    npm run ui fails on Fedora Silverblue 36 (Wayland)

    Running npm run ui (with emcc on my path), gives the following output:

    > [email protected] ui
    > tree-sitter build-wasm && tree-sitter web-ui
    Started playground on:
    F: X11 socket /tmp/.X11-unix/X0 does not exist in filesystem, trying to use abstract socket instead.

    In the browser (tested on Firefox and Ungoogled Chromium), I get the following errors:

    RuntimeError: abort(Assertion failed: undefined). Build with -s ASSERTIONS=1 for more info.
    Uncaught (in promise) Error: Parsing failed
    Uncaught TypeError: tree is undefined

    Wondering if this is a Wayland-related issue as the web ui appears to be attempting to do some sort of X11 forwarding?

    System information

    Node version: 18.4.0
    emcc version: emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.15 (8b4443a87f5eab5dbb9adb690f9ebed0a9da4bd9)
    OS: Ubuntu 22.04 LTS x86_64 (running in container on Fedora Silverblue 36)
    Host: B550I AORUS PRO AX 
    Kernel: 5.17.12-300.fc36.x86_64 
    Uptime: 1 day, 21 hours, 1 min 
    Packages: 1017 (dpkg), 58 (flatpak) 
    Shell: fish 3.4.1 
    Resolution: 3840x2160 
    DE: GNOME 
    Theme: Adwaita [GTK2/3] 
    Icons: Adwaita [GTK2/3] 
    CPU: AMD Ryzen 7 5700G with Radeon Graphics (16) @ 3.800GHz 
    GPU: AMD ATI 07:00.0 Cezanne 
    Memory: 6930MiB / 63710MiB 
    opened by aral 4
  • v0.10.1(Apr 13, 2022)

    • added const expr and latest wasm generated 46611de
    • added indent to script element and style element ad07069

    Source code(tar.gz)
    Source code(zip)
  • v0.10.0(Apr 12, 2022)

    • Added compilation fix for MacOS, Node v16
    • removed Zig dependencies
    • npm package upgradation
    • Dot html tags #25

    Source code(tar.gz)
    Source code(zip)
  • v0.9.0(Oct 28, 2021)

    • each round bracket issue fixed #14 13dc7e3
    • Merge pull request #16 from elianiva/fix/regression 349a598
    • fix: regression after #15 95db315
    • Merge pull request #15 from elianiva/fix/whitespace d8c7ef9
    • fix: don't capture whitespace as text node a23065e
    • fixed #13 10c1130
    • Merge pull request #12 from elianiva/fix/typo c00bd51
    • fixed uppercase and lowercase letters in tags 84d1a6a
    • fix: errorneous -> erroneous 3c3eebd
    • updated cargo.toml 6e9ff3a
    • fixed Cargo.toml dce55dd
    • cargo publish 0.8.1 d8cbeee
    • updated cargo version e63ded0
    • small commit 3244254
    • updated repo for zig support 437b6a8

    Source code(tar.gz)
    Source code(zip)
  • v0.8.1(Mar 20, 2021)

Himujjal Upadhyaya
Himujjal Upadhyaya
A tree-sitter grammar for go.mod files

tree-sitter-go-mod tree-sitter grammar for go.mod files. Status The grammar is fairly small, and has been working well for highlighting for me. I expe

Camden Cheek 24 Dec 3, 2022
A tree-sitter grammar for HCL (HashiCorp Configuration Language), used by projects such as Terraform.

tree-sitter-hcl tree-sitter grammar for HCL (HashiCorp Configuration Language) files. HCL is the configuration format used by projects such as Terrafo

Mitchell Hashimoto 65 Nov 29, 2022
A tree-sitter grammar for protocol buffer files (proto3).

tree-sitter-proto tree-sitter grammar for protocol buffer files (proto3 only). Status The grammar should be complete. I'm still working on the highlig

Mitchell Hashimoto 43 Nov 2, 2022
Org grammar for tree-sitter

tree-sitter-org Unstable: This build will change. Org grammar for tree-sitter. It is not meant to implement emacs' orgmode parser, but to implement a

Emilia Simmons 161 Jan 7, 2023
Golang template grammar for tree-sitter

tree-sitter-go-template Golang templates grammar for tree-sitter. NeoVim integration using nvim-treesitter Add gotmpl parser following nvim-treesitter

Nikita Galaiko 28 Nov 30, 2022
Surface grammar for Tree-sitter

Tree-sitter Surface Tree-sitter grammar and parser for Surface, the server-side rendering component library for Phoenix. Supports the Surface 0.5+ tem

Clay 13 Jul 12, 2022
A tree-sitter grammar for the Gleam programming language

tree-sitter-gleam A tree-sitter grammar for the Gleam programming language This is, presently, very much a work-in-progress. DONE Parsing import state

Jonathan Arnett 0 Mar 30, 2022
A tree-sitter grammar for `git diff` output

tree-sitter-git-diff A tree-sitter grammar for git diffs. Status Working, but needs more testing. Examples Highlighting a .diff file: Injecting this g

Michael Davis 5 Dec 9, 2022
Promela grammar for tree-sitter

tree-sitter-promela Promela grammar for tree-sitter. Motivation Promela is a language used for specifying models, especially in distributed systems co

Ben Siraphob 6 Nov 22, 2022
Scheme grammar for tree-sitter

tree-sitter-scheme Scheme grammar for tree-sitter. Status tree-sitter-scheme should work on a superset of Scheme. The standards are expected to suppor

null 6 Dec 27, 2022
This is like Inverting Binary Tree, but instead of a Binary Tree it's a File Tree.

Invert File Tree in C++ This is like Inverting Binary Tree, but instead of the Binary Tree it's a File Tree. This is intended as a simple exercise to

Tsoding 12 Nov 23, 2022
An intrusive C++17 implementation of a Red-Black-Tree, a Weight Balanced Tree, a Dynamic Segment Tree and much more!

This is Ygg (short for Yggdrasil), a C++17 implementation of several intrusive data structures: several balanced binary search trees: a red-black Tree

Lukas Barth 98 Dec 25, 2022
Build a tree-sitter dynamic module

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I should clarify that this module is NOT a standalone tree-sitter module. It is supo

Yuan Fu 53 Jan 5, 2023
tree-sitter parser and syntax highlighter for the Dwarf Fortress raw language

tree-sitter-dfraw A simple language parser and highlighter made with tree-sitter tokyonight nightfly Using with nvim-treesitter Please refer to the ad

null 2 Apr 1, 2022
HEEx grammer for Tree-sitter

Tree-sitter HEEx Tree-sitter grammar and parser for HEEx, the HTML-aware and component-friendly extension of EEx for Phoenix. For Surface support, see

Connor Lay (Clay) 33 Dec 23, 2022
Languages for the Tree-sitter parser generator wrapped in Swift packages

TreeSitterLanguages Languages for the Tree-sitter parser generator wrapped in Swift packages. Motivation There are two reasons this package exists: As

Simon Støvring 23 Dec 21, 2022
This repository provides implementation of an incremental k-d tree for robotic applications.

ikd-Tree ikd-Tree is an incremental k-d tree designed for robotic applications. The ikd-Tree incrementally updates a k-d tree with new coming points o

HKU-Mars-Lab 362 Jan 4, 2023
Device Tree for Redmi K30 Ultra

Copyright (C) 2020 PixelExperience Plus Edition Device configuration for Redmi K30 Ultra ========================================= The Redmi K30 Ultra

Xayah 22 Jun 2, 2022