桌面应用跨平台【免费下载链接】nativeToolkit for building native desktop apps项目地址https://gitcode.com/gh_mirrors/ze/native点击查看免费下载editors/native-markup是 Native SDK 为.native标记视图markup view提供的编辑器工具集一份 TextMate 语法文件、一个基于 stdio 的 LSP 语言服务器以及一个零 npm 依赖的 VS Code 扩展。本指南以 editors/native-markup/README.md 为主干结合 tools/native-sdk/markup.zig、tools/native-sdk/markup_lsp.zig 与 editors/native-markup/extension.js 等源码实现完整讲解语法高亮、诊断、补全、悬停文档的底层原理并给出 VS Code、Helix、Neovim 三个编辑器的可复制配置与无编辑器冒烟测试方法。读完本文你将能把这套工具链接入任意支持 LSP 的编辑器并理解其模型无关、构建期校验的设计边界。一、整体架构三件套如何分工.native是 Native SDK 的声明式 UI 标记语言语言本身见 skill-data/native-ui/SKILL.md它编译为与手写canvas.Ui(Msg)构建器完全一致的原生 widget 树。为了让编写.native文件时获得现代编辑体验editors/native-markup/目录提供了三块互补的组件组件文件职责TextMate 语法syntaxes/native-markup.tmLanguage.json标签、属性名、字符串、注释、{...}绑定表达式各有独立 scopeon-*事件属性与for/if/else结构标签被区分着色语言服务器native markup lsp实现见 markup_lsp.zig通过 stdio 讲 LSP 协议打开/变更时推送诊断、后补全元素名、标签内补全属性/事件名、元素与属性的悬停文档VS Code 扩展package.json extension.js零依赖的 LSP 客户端自行实现 spawn、Content-Length 分帧、initialize、文档同步、诊断、补全、hover无需npm install与打包器三者共用同一个解析器与校验器语言服务器在打开/变更文档时执行的诊断与native markup check命令完全同源因此编辑器里看到的错误和命令行校验报出的错误是同一套判词含行列定位与教学式提示信息。二、TextMate 语法作用域设计语法文件scopeName为source.native-markupVS Code 侧声明于 package.json 的grammars段。顶层 pattern 依次包含四类规则#comment!-- ... --块注释scope 为comment.block.native-markup#structure-tag匹配/?后紧跟for|if|else以(?![a-z0-9_-])防止误匹配format之类前缀作为meta.tag.structure.native-markup其中标签名落在keyword.control.structure.native-markup#tag匹配/?后跟小写开头的标识符[a-z][a-z0-9_-]*标签名落在entity.name.tag.native-markup#expression匹配{...}边界内的嵌入表达式。标签内部#tag-innards进一步区分#event-attributeon-开头的属性名on-[a-z][a-z0-9_-]*落在entity.other.attribute-name.event.native-markup与普通属性entity.other.attribute-name.native-markup视觉区分——这正是 README 所说on-*事件属性被独立着色的实现#string双引号字符串string.quoted.double.native-markup内部还会继续识别{...}表达式以及消息载荷分隔冒号:punctuation.separator.message-payload.native-markup对应on-pressopen_note:{n.id}这种tag:{payload}写法#expression内部记为比较运算符keyword.operator.comparison.native-markup形如a.b.c的路径记为variable.other.binding.native-markup.为punctuation.accessor.native-markup。配套的 language-configuration.json 定义了编辑行为块注释!--/--、括号对/与{/}、自动闭合对含!--/--、环绕对以及分词器词元模式[a-zA-Z0-9_-]。注意 Helix 目前没有.native的 tree-sitter 语法因此其高亮依赖scope source.native-markup加 TextMate 语法的近似呈现详见下文 Helix 小节。三、语言服务器native markup lsp的协议能力语言服务器由 CLI 子命令native markup lsp启动纯 stdio 传输。其完整能力声明在initialize响应中markup_lsp.zigtextDocumentSync 1全量文档同步full-document sync客户端每次变更推送整份文本服务器对带range的增量变更直接跳过容错处理completionProvider.triggerCharacters [, ]补全在输入或空格时触发hoverProvider true。3.1 诊断diagnosticstextDocument/didOpen与textDocument/didChange都会触发publishDiagnostics。诊断内容与native markup check共用同一解析器和ui_markup.validate结构性错误未知元素、未知属性、未知事件属性、结构标签误用、表达式语法/越界、导入失败等以Errorseverity 1上报文档校验干净后可访问性a11ylint 的警告类发现未命名的图片、冗余标签等以Warningseverity 2上报——与命令行检查行为一致见 markup_lsp.zig行列位置从解析器 1-based 的line/column转换为 LSP 的 0-based 坐标诊断消息保留教学式文案如unknown element、unknown attribute命令行还会附上 did you mean ...? 拼写建议。3.2 补全completion补全按当前光标所处的语法上下文分为三类markup_lsp.zig元素名在之后返回全部元素文档kind class与结构标签for/if/elsekind keyword属性/事件名在标签内部按元素名分发for只补each/as等 for 专用属性if补 test 专用属性avatar/image、dropdown-menu等会附带通用属性与on-*事件kind event其余元素补通用属性集else、step、context-menu等无属性的元素不返回任何属性项图标名在图标值属性的引号内补全内置矢量图标名与app:命名空间前缀对应icon namesearch/与app:name两种引用方式后者需应用在启动时通过canvas.icons.registerAppIcons注册。3.3 悬停文档hover对元素名与属性名返回一行式说明文档例如row的 Flex container。悬停内容来自服务器内置的文档表与native markup check的词汇表一致。3.4 设计边界绑定路径与 Msg 标签不检查README 明确说明绑定路径{...}与on-*的 Msg 标签不会被语言服务器检查。原因在 markup_lsp.zig 的注释中写得很清楚——它们依赖应用具体的Model/Msg类型而这两者只在应用构建时存在。因此编辑器中写错绑定路径不会报错模型无关是 LSP v1 的刻意范围绑定与消息的校验发生在应用构建期以及热重载时native check在应用目录内、且有新鲜的 model-contract 工件时会针对应用真实的Model/Msg校验绑定、可迭代源、消息标签与表达式类型README 将构建集成的绑定校验build-integrated binding validation列为未来工作。这一点决定了工具链的正确使用姿势LSP 提供语法与词汇的即时反馈类型级校验交给native check/zig build/ 热重载。四、构建语言服务器服务器并非独立产物而是nativeCLI 的一个子命令。构建方式zig build # produces zig-out/bin/native构建产物zig-out/bin/native包含markup check、markup dump、markup lsp三个子命令见 tools/native-sdk/markup.zig 的 usage 文本。使用方式任选其一把zig-out/bin加入PATH编辑器直接以native markup lsp启动服务器或者在编辑器配置中指向绝对路径如 VS Code 的native-markup.serverPath。markup lsp的入口在 markup.zig用 64 KiB 缓冲的 stdio reader/writer 初始化markup_lsp.Server并run()。服务器主循环读取 Content-Length 分帧消息直到收到exit或输入流结束markup_lsp.zigshutdown返回 null未知带 id 的请求返回-32601 method not found未识别通知则静默忽略。协议层只用 stdstd.Io.Reader/std.Io.Writerstd.json手写无第三方依赖——这也让服务器可以被注入固定缓冲的测试直接驱动。五、VS Code 集成零依赖的 LSP 客户端5.1 安装符号链接方式code --install-extension期望打包好的.vsix文件本扩展刻意避免引入vsce/npm因此官方推荐符号链接安装ln -s /path/to/native-sdk/editors/native-markup ~/.vscode/extensions/native-sdk.native-markup-0.1.0示例路径中的native-sdk在本仓库中对应/data/web/disk1/git_repo/gh_mirrors/ze/native根目录请替换为你的实际路径。随后重载 VS Code 并打开一个.native文件。如果native不在PATH上在设置中指定服务器绝对路径{ native-markup.serverPath: /path/to/native-sdk/zig-out/bin/native }native-markup.serverPath的默认值为native声明于 package.json 的contributes.configuration。另外务必删除旧的可能把*.native映射到html的files.associations配置否则文件不会拾取native-markup语言 id。5.2 扩展内部实现extension.js 是一个足够用的 LSP 客户端其设计动机在文件头注释中写明不依赖vscode-languageclient——那是个需要构建步骤的 npm 包而本扩展直接手写协议因此无需npm install、无需打包器、无构建链。关键实现点进程与分帧spawn(serverPath, [markup, lsp])pumpMessages()用indexOf(\r\n\r\n)解析头部、正则content-length:\s*(\d)提取长度、按字节数切分 JSON body发送侧统一Content-Length: len\r\n\r\nbody封装extension.js生命周期activate中创建诊断集合与输出通道startServer()发送initializeclientInfo: { name: native-markup-vscode, version: 0.1.0 }随后发送initialized并补发所有已打开文档的didOpendeactivate走shutdown→exit→ 1 秒超时兜底 kill文档同步didOpen/didChange全量同步/didClose按语言 id 过滤仅处理native-markup文档didClose同时清空该文档的诊断诊断呈现publishDiagnostics通知被转换为vscode.Diagnostic注意 LSP 的 severity 是 1-based、VS Code 是 0-based做了(item.severity || 1) - 1的换算extension.js补全与 hover注册CompletionItemProvider触发字符、 与HoverProvider将 LSP 的 completion kind元素Class、属性Property、结构标签Keyword、事件Event映射为 VS Code 对应类型extension.js启动失败提示spawn 或进程error事件会弹出警告消息提示用zig build构建 CLI 并设置native-markup.serverPath指向zig-out/bin/nativeextension.js。5.3 扩展元数据package.json 汇总了关键元数据publisher: native-sdk、version: 0.1.0、engines.vscode: ^1.75.0、激活事件onLanguage:native-markup语言贡献包含 idnative-markup、扩展名.native、语法文件路径与language-configuration.json。六、Helix 集成在~/.config/helix/languages.toml中声明语言服务器与语言[language-server.native-markup-lsp] command native args [markup, lsp] [[language]] name native-markup scope source.native-markup file-types [native] comment-tokens [] block-comment-tokens { start !--, end -- } language-servers [native-markup-lsp] auto-pairs { , { }, }由于 Helix 目前没有.native的 tree-sitter 语法可给[[language]]块追加grammar html获得近似高亮——诊断、补全与悬停无论如何都来自 LSP不依赖语法树。七、Neovim0.10集成在 init 配置中注册文件类型并按FileType自动启动 LSPvim.filetype.add({ extension { native native-markup } }) vim.api.nvim_create_autocmd(FileType, { pattern native-markup, callback function(args) vim.lsp.start({ name native-markup-lsp, cmd { native, markup, lsp }, root_dir vim.fs.dirname(vim.fs.find({ build.zig, .git }, { upward true })[1]), }, { bufnr args.buf }) end, })高亮方面两条路任选把缓冲区按 HTML 处理vim.treesitter.language.register(html, native-markup)或采用纯 LSP 配置——无论哪种诊断、补全与悬停都照常工作。八、冒烟测试不依赖编辑器验证服务器scripts/lsp-smoke.py 是一个端到端冒烟测试直接用真实 Content-Length 分帧驱动服务器走完整协议流python3 editors/native-markup/scripts/lsp-smoke.py zig-out/bin/native测试脚本的断言流程lsp-smoke.py非常直观地展示了服务器的完整行为契约initialize→ 断言返回capabilities且textDocumentSync 1全量同步initialized→didOpen一个故意写错的文档column\n bogus /\n/column→ 断言收到publishDiagnostics恰好 1 条诊断消息为unknown element且行列定位精确到1:20-based指向bogus对应解析器 1-based 的 2 行 3 列didChange为已修复的文档row gap8texthi {name}/text/row→ 断言诊断清空completion位置 0:5即row标签内部→ 断言结果同时包含属性gap与事件on-presshover位置 0:2即row元素名上→ 断言悬停内容含Flex containershutdown→exit→ 断言进程以 0 码干净退出最后输出PASS。该脚本是理解服务器协议细节的最佳教材既能验证构建出的二进制是否工作也展示了任何自定义编辑器客户端应发送的消息序列。九、与其他markup子命令的关系语言服务器不是孤立功能它与native markup命令族的另外两个成员共享同一套解析/校验内核tools/native-sdk/markup.zignative markup check file.native [more files...] [--strict]解析并校验视图——语法、表达式形式、元素、属性、结构标签、import闭包、字体覆盖tofu 字符会报错并指出码点、可访问性未命名的交互控件/单选组、无标签的纯图标控件、角色误用是错误未命名的图片与冗余标签是警告。在应用目录内且有新鲜的zig-out/model-contract.zon时用native test刷新还会对应用真实Model/Msg校验绑定、可迭代源、消息标签、表达式类型与app:图标引用并报告未被任何视图使用的模型状态与 Msg 标签--strict把警告提升为失败。这正是语言服务器诊断的命令行版本native markup dump file.native [--out doc.nsui]解析校验并规范化视图编码为规范二进制 NSUI再从解码后的二进制派生 JSON 检查视图所见即产物所言--out额外写出.nsui工件。三者关系可以概括为check是批处理校验CI 友好dump是二进制工件检视lsp是交互式编辑体验——但共享同一解析器与校验器保证命令行的判词与编辑器里的红线永远一致。十、常见问题与排错要点编辑器提示无法启动服务器确认zig build已产出zig-out/bin/native且native-markup.serverPath或 Helix/Neovim 的command指向正确路径VS Code 扩展的警告消息会直接给出这两条建议.native文件没有高亮/没有语言服务检查语言 id 是否为native-markup并清理残留的files.associations: {*.native: html}映射Helix 用户确认scope source.native-markup与语法文件 scopeName 一致写错绑定路径编辑器不报错这是设计使然模型无关的 LSP v1 边界请依赖native check、zig build或应用热重载完成类型级校验诊断位置与预期有偏差解析器位置为 1-based 字节坐标LSP 侧统一转换为 0-based参考lsp-smoke.py中断言的行列换算即可校准理解怀疑旧二进制误报若报 unknown element/attribute 而语法明明是对的可能是zig-out/bin/native过期未覆盖新增语法重建并对比native version即可markup.zig 会主动提示这一可能。赞分享桌面应用跨平台【免费下载链接】nativeToolkit for building native desktop apps项目地址https://gitcode.com/gh_mirrors/ze/native点击查看免费下载相关推荐Regal 编辑器集成全指南在 VS Code、Neovim、Zed、Helix 与 Kakoune 中启用 Rego 语言服务器与调试支持Regal 编辑器集成全指南在 VS Code、Neovim、Zed、Helix 与 Kakoune 中启用 Rego 语言服务器与调试支持 Regal 是后端认证鉴权云原生语言服务器协议LSPVS Code 语言扩展开发指南语言服务器协议LSPVS Code 语言扩展开发指南 本文详细介绍了语言服务器协议LSP在VS Code扩展开发中的核心原理与实践应用。内容涵盖LSP示例工程为 templ 语言配置 IDE 与编辑器支持VS Code、Neovim、Vim、JetBrains、Helix、Emacs 全指南为 templ 语言配置 IDE 与编辑器支持VS Code、Neovim、Vim、JetBrains、Helix、Emacs 全指南 本篇指南以 templ开发工具代码生成后端上一篇DINOv3 预训练超参数完整指南5 个数字决定收敛下一篇手把手打造 Sunshine 游戏库应用添加与串流配置终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考