ecode
ecode 0.6.4
O ECODE é um editor de código de várias plataformas leve, projetado para hardware moderno, com foco na capacidade de resposta e desempenho. Ele foi desenvolvido com a GUI EEPP acelerada por hardware, que fornece a tecnologia principal para o editor. O projeto é o primeiro projeto sério usando a GUI da EEPP e está sendo desenvolvido atualmente para melhorar a Biblioteca da GUI da EEPP como parte de um de seus principais objetivos.
Para obter mais check -out de capturas de tela em execução no macOS, executando no Windows, executando em haiku, baixo DPI, conclusão de código, terminal, localizador de arquivos, formatos de arquivo, findos globais, substituição global, linter.
.gitignore * O Ecode trata as pastas como projetos, como muitos outros editores. A principal diferença é que ele também tenta higienizar automaticamente os arquivos do projeto, filtrando qualquer arquivo que seja filtrado nos arquivos do repositório .gitignore . A idéia é usar o arquivo .gitignore como uma configuração de projeto. Os arquivos do projeto serão os usados para encontrar arquivos no projeto e fazer pesquisas globais. Geralmente, isso se traduz em resultados muito melhores para qualquer pesquisa relacionada ao projeto. Há também um mecanismo muito simples para permitir a visibilidade de arquivos filtrados pelo .gitignore , adicionando um arquivo com os padrões filtrados permitidos em uma subpasta sobre a pasta carregada, criando um arquivo em .ecode/.prjallowed com os padrões globais necessários, permitindo que os padrões filtrados sejam "não filtrados". O ECODE adicionará apenas arquivos suportados pelo editor, o editor não tentará fazer nada com arquivos que não sejam oficialmente suportados.
Alguns pontos para ilustrar a filosofia do projeto:
O ECODE pode ser compilado ao WASM e executado em qualquer navegador moderno. Não há planos de concentrar o desenvolvimento na versão da Web (pelo menos no momento), pois existem muitas boas soluções por aí. Mas você pode tentar:
Demonstração aqui
Atualmente, o código -fonte está localizado no repositório do projeto EEPP. O ECODE Editor Source está localizado no SRC/Tools/Ecode. O ECODE está sendo usado para melhorar e iterar ativamente a Biblioteca da GUI da EEPP. Em algum momento, será migrado para este repositório. O repositório do ECODE deve ser usado para problemas e documentação. O PRS for ECODE será aceito no repositório EEPP.
Existem scripts para cada plataforma suportada pronta para criar o aplicativo. Para Linux e MacOS , é trivial construir o projeto, você só precisará instalar o GCC/CLANG e também a biblioteca de desenvolvimento do LIBSDL2. Atualmente, o script do Windows Build é um script de compilador cruzado e usa o MingW64. Mas também pode ser facilmente construído com as bibliotecas de desenvolvimento do Visual Studio e Libsdl2 instaladas. Para obter mais informações sobre como criar um projeto manualmente, siga as instruções de construção do EEPP. O nome do projeto é sempre o ECODE (por isso, se você estiver construindo com a marca, precisará executar make ecode ).
build.app.sh tentará criar o pacote AppImage e tar.gz com o aplicativo compactado. A pasta ecode conterá o aplicativo não compactado.build.app.sh criará ecode.app . Execute create.dmg.sh para criar o arquivo dmg . A pasta ecode.app conterá o aplicativo não compactado.build.app.sh criará um arquivo zip com o pacote de aplicativos zippeado. A pasta ecode conterá o aplicativo não compactado. Para construir a partir do Windows, siga as instruções aqui.build.app.sh tentará criar um tar.gz com o aplicativo compactado. A pasta ecode.app conterá o aplicativo não compactado.build.app.sh tentará criar um tar.gz com o aplicativo compactado. A pasta ecode.app conterá o aplicativo não compactado. As compilações noturnas estão sendo distribuídas aqui para os usuários mais impacientes. O ECODE está sendo desenvolvido ativamente, as construções noturnas podem não ser estáveis para o uso diário, a menos que haja uma correção não lançada pendente necessária para o usuário.
O ECODE está constantemente adicionando mais suporte de idiomas e também suporta estender o suporte ao idioma por meio de arquivos de configuração (para cada recurso: destaque da sintaxe, LSP, Linter e Formatter).
| Linguagem | Destaque | LSP | Linter | Formatador |
|---|---|---|---|---|
| .htaccess | ✓ | Nenhum | Nenhum | Nenhum |
| .IGNORE ARQUIVO | ✓ | Nenhum | Nenhum | Nenhum |
| [x] IT! | ✓ | Nenhum | Nenhum | Nenhum |
| adepto | ✓ | ADEPTLSP | Nenhum | Nenhum |
| angelscript | ✓ | Nenhum | Nenhum | Nenhum |
| Script Awk | ✓ | Nenhum | Nenhum | Nenhum |
| bastão | ✓ | Nenhum | Nenhum | Nenhum |
| Bazel | ✓ | Nenhum | Nenhum | Nenhum |
| dobrar | ✓ | Nenhum | Nenhum | Nenhum |
| Blueprint | ✓ | Nenhum | Nenhum | Nenhum |
| experiência cerebral | ✓ | Nenhum | Nenhum | Nenhum |
| zumbido | ✓ | Nenhum | Nenhum | Nenhum |
| c | ✓ | Clangd | cppcheck | formato de clang |
| carbono | ✓ | Nenhum | Nenhum | Nenhum |
| Clojure | ✓ | Clojure-lsp | Nenhum | Nenhum |
| cmake | ✓ | servidor de língua cmake | Nenhum | Nenhum |
| cpp | ✓ | Clangd | cppcheck | formato de clang |
| cristal | ✓ | cristalino | Nenhum | Nenhum |
| CSharp | ✓ | Omnisharp | Nenhum | Nenhum |
| CSS | ✓ | servidor de língua Emmet | Nenhum | nativo |
| d | ✓ | servido | Nenhum | Nenhum |
| dardo | ✓ | Dart Language-Server | Nenhum | Nenhum |
| Dif | ✓ | Nenhum | Nenhum | Nenhum |
| Dockerfile | ✓ | Docker-LangServer | Nenhum | Nenhum |
| elixir | ✓ | elixir-ls | Nenhum | Nenhum |
| olmo | ✓ | servidor-idioma de elm | Nenhum | Nenhum |
| arquivo de ambiente | ✓ | Nenhum | Nenhum | Nenhum |
| Fantom | ✓ | Nenhum | Nenhum | Nenhum |
| fortran | ✓ | fortls | Nenhum | Nenhum |
| fstab | ✓ | Nenhum | Nenhum | Nenhum |
| GDScript | ✓ | Nenhum | Nenhum | Nenhum |
| glsl | ✓ | GLSL_ANALYZER | Nenhum | Nenhum |
| ir | ✓ | Gopls | Nenhum | Gopls |
| GraphQL | ✓ | Nenhum | Nenhum | Nenhum |
| Groovy | ✓ | Nenhum | Nenhum | Nenhum |
| lebre | ✓ | Nenhum | Nenhum | Nenhum |
| Haskell | ✓ | servidor-língua de Haskell | hlint | ormolu |
| Haxe | ✓ | Nenhum | Nenhum | Nenhum |
| Argumentos do compilador Haxe | ✓ | Nenhum | Nenhum | Nenhum |
| hlsl | ✓ | Nenhum | Nenhum | Nenhum |
| html | ✓ | servidor de língua Emmet | Nenhum | mais bonito |
| ini | ✓ | Nenhum | Nenhum | Nenhum |
| Jai | ✓ | Nenhum | Nenhum | Nenhum |
| Java | ✓ | jdtls | Nenhum | formato de clang |
| JavaScript | ✓ | servidor de idioma digital | Eslint | mais bonito |
| JavaScriptreact | ✓ | servidor de idioma digital | Nenhum | Nenhum |
| JSON | ✓ | Nenhum | JQ | nativo |
| Julia | ✓ | Languageserver.jl | Nenhum | Nenhum |
| Kotlin | ✓ | Kotlin-Language-Server | Ktlint | Ktlint |
| látex | ✓ | Texlab | Nenhum | Nenhum |
| lagosta | ✓ | Nenhum | Nenhum | Nenhum |
| Lua | ✓ | servidor de língua Lua | Luacheck | Nenhum |
| makefile | ✓ | Nenhum | Nenhum | Nenhum |
| Markdown | ✓ | Nenhum | Nenhum | Nenhum |
| méson | ✓ | Nenhum | Nenhum | Nenhum |
| Moonscript | ✓ | Nenhum | Nenhum | Nenhum |
| Nelua | ✓ | Nenhum | Nelua | Nenhum |
| nim | ✓ | nimlsp | nim | Nenhum |
| Objeck | ✓ | Nenhum | Nenhum | Nenhum |
| Objective-C | ✓ | Clangd | Nenhum | formato de clang |
| OCAML | ✓ | OCAML-LSP | Nenhum | Nenhum |
| Odin | ✓ | ols | Nenhum | Nenhum |
| OpenScad | ✓ | Nenhum | Nenhum | Nenhum |
| Pascal | ✓ | Nenhum | Nenhum | Nenhum |
| perl | ✓ | Perlnavigator | Nenhum | Nenhum |
| php | ✓ | phpactor | php | Nenhum |
| Pico-8 | ✓ | Nenhum | Nenhum | Nenhum |
| texto simples | ✓ | Nenhum | Nenhum | Nenhum |
| po | ✓ | Nenhum | Nenhum | Nenhum |
| pônei | ✓ | Nenhum | Nenhum | Nenhum |
| PostGresql | ✓ | Nenhum | Nenhum | Nenhum |
| Powershell | ✓ | Nenhum | Nenhum | Nenhum |
| Python | ✓ | pylsp | Ruff | preto |
| r | ✓ | r linguagemerver | Nenhum | Nenhum |
| anel | ✓ | Nenhum | Nenhum | Nenhum |
| rubi | ✓ | SolarGraph | Nenhum | Nenhum |
| ferrugem | ✓ | analisador de ferrugem | Nenhum | rustfmt |
| Sass | ✓ | servidor de língua Emmet | Nenhum | Nenhum |
| scala | ✓ | metais | Nenhum | Nenhum |
| ShellScript | ✓ | servidor de idiomas de bash | Nenhum | Nenhum |
| Smallbasic | ✓ | Nenhum | Nenhum | Nenhum |
| solidez | ✓ | Solc | Solhint | Nenhum |
| SQL | ✓ | Nenhum | Nenhum | Nenhum |
| Swift | ✓ | SourceKit-LSP | Nenhum | Nenhum |
| tcl | ✓ | Nenhum | Nenhum | Nenhum |
| cerceta | ✓ | Nenhum | tl | Nenhum |
| Toml | ✓ | Nenhum | Nenhum | Nenhum |
| TypeScript | ✓ | servidor de idioma digital | Eslint | mais bonito |
| Digitriptreact | ✓ | servidor de idioma digital | Nenhum | Nenhum |
| v | ✓ | V-analisador | Nenhum | v |
| Vala | ✓ | servidor de linguagem de vala | Nenhum | Nenhum |
| Verilog | ✓ | Nenhum | Nenhum | Nenhum |
| Visual Basic | ✓ | Nenhum | Nenhum | Nenhum |
| Vue | ✓ | VLS | Nenhum | Nenhum |
| carriça | ✓ | Nenhum | Nenhum | Nenhum |
| Assembléia x86 | ✓ | Nenhum | Nenhum | Nenhum |
| xml | ✓ | servidor de língua Emmet | nativo | nativo |
| Xtend | ✓ | Nenhum | Nenhum | Nenhum |
| Yaml | ✓ | Servidor de língua Yaml | Nenhum | Nenhum |
| Zig | ✓ | zls | Zig | Zig |
Tag nativo significa que o recurso é suportado nativamente pelo ECODE e não precisa de nenhuma ferramenta externa para funcionar.
O ECODE traz uma ferramenta para exibir a saúde atual do idioma. No ECODE, você pode verificar seu status de saúde a partir de Settings -> Tools -> Check Language Health e, da CLI, você pode usar a bandeira --health : ecode --health . Use o sinalizador de verificação de saúde para solucionar problemas de servidores de idiomas, linheiros e formatados.
Verifique a saúde de todos os idiomas com ecode --health ou peça detalhes sobre um idioma específico com ecode --health-lang=<lang> .
Os plugins estendem a funcionalidade do editor de código base. Atualmente, todos os plug -ins são ativados por padrão, mas são opcionais e podem ser desativados a qualquer momento. O ECODE implementa um protocolo interno que permite que os plugins se comuniquem. O protocolo LSP será usado como base para implementar a comunicação do plug -in. E, por exemplo, o plug -in do Linter consumirá o LSP para melhorar seus diagnósticos. Além disso, o módulo completo completo solicitará assistência do LSP, se disponível, para melhorar as conclusões e fornecer ajuda de assinatura.
O suporte do Linter é fornecido executando linters já estabelecidas a partir de cada idioma. O ECODE fornece suporte para vários idiomas por padrão e pode ser estendido facilmente, expandindo a configuração linters.json . linters.json A configuração padrão pode ser obtida daqui. Para configurar novos linters, você pode criar um novo arquivo linters.json no caminho de configuração padrão do ecodo .
linters.jsonO formato é um objeto JSON muito simples, com um objeto de configuração e uma matriz de objetos que contêm os formatos de arquivo suportados, o padrão Lua para encontrar qualquer erro impresso pelo linhador no stdout, a posição de cada grupo do padrão e o comando para executar. Ele também suporta algumas teclas de objeto extras opcionais.
Javascript Linter Exemplo (usando Eslint)
{
"config" : {
"delay_time" : " 0.5s "
},
"linters" : [
{
"file_patterns" : [ " %.js$ " , " %.ts$ " ],
"warning_pattern" : " [^:]:(%d+):(%d+): ([^%[]+)%[([^ n ]+) " ,
"warning_pattern_order" : { "line" : 1 , "col" : 2 , "message" : 3 , "type" : 4 },
"command" : " eslint --no-ignore --format unix $FILENAME "
}
]
} É tudo o que precisamos para ter um linhador de trabalho no Ecode . Os executáveis dos liners devem ser instalados manualmente pelo usuário, os linheiros não virão com o editor e também precisam ser visíveis para o executável. Isso significa que ele deve estar na variável do ambiente PATH ou o caminho para o binário deve ser absoluto.
Verifique a tabela de suporte ao idioma
"disable_lsp_languages": ["lua", "python"] , desativa Lua e Python."disable_languages": ["lua", "python"] , desativa Luacheck e Ruff, respectivamente. O plug-in do formatador funciona exatamente como o plug-in Linter, mas executará ferramentas que o código de formato automático. O ECODE fornece suporte para vários idiomas por padrão, pode ser estendido facilmente expandindo a configuração formatters.json . formatters.json A configuração padrão pode ser obtida daqui. Ele também suporta alguns formatados nativamente, isso significa que o formatador vem com o ECODE sem exigir nenhuma dependência externa. E também suporta formatação de documentos de texto LSP, o que significa que, se você estiver executando um LSP que suporta documentos de formatação, a formatação também estará disponível. Para configurar novos formatados, você pode criar um novo arquivo formatters.json no caminho de configuração padrão do ECODE .
formatters.json formato {
"config" : {
"auto_format_on_save" : false
},
"keybindings" : {
"format-doc" : " alt+f "
},
"formatters" : [
{
"file_patterns" : [ " %.js$ " , " %.ts$ " ],
"command" : " prettier $FILENAME "
}
]
}Verifique a tabela de suporte ao idioma
O suporte ao LSP é fornecido executando o LSP já estável a partir de cada idioma. O ECODE fornece suporte para vários idiomas por padrão e pode ser estendido facilmente, expandindo a configuração lspclient.json . A configuração padrão lspclient.json pode ser obtida daqui. Para configurar novos LSPs, você pode criar um novo arquivo lspclient.json no caminho de configuração padrão do ECODE .
Nota importante: os servidores LSP podem ser muito intensivos em recursos e podem não ser sempre a melhor opção para projetos simples.
Detalhes da implementação: os servidores LSP são carregados apenas quando necessário, nenhum processo será aberto até que um arquivo suportado seja aberto no projeto.
lspclient.json O formato segue o mesmo padrão que todos os arquivos de configuração anteriores. A configuração é representada em um arquivo json com três chaves principais: config , keybindings , servers .
Exemplo de servidor C e C ++ LSP (usando Clangd)
{
"config" : {
"hover_delay" : " 0.5s "
},
"servers" : [
{
"language" : " c " ,
"name" : " clangd " ,
"url" : " https://clangd.llvm.org/ " ,
"command" : " clangd -log=error --background-index --limit-results=500 --completion-style=bundled " ,
"file_patterns" : [ " %.c$ " , " %.h$ " , " %.C$ " , " %.H$ " , " %.objc$ " ]
},
{
"language" : " cpp " ,
"use" : " clangd " ,
"file_patterns" : [ " %.inl$ " , " %.cpp$ " , " %.hpp$ " , " %.cc$ " , " %.cxx$ " , " %.c++$ " , " %.hh$ " , " %.hxx$ " , " %.h++$ " , " %.objcpp$ " ]
}
]
} É tudo o que precisamos para ter um LSP em funcionamento no ECODE . Os executáveis LSPs devem ser instalados manualmente pelo usuário, os LSPs não virão com o editor e também precisam ser visíveis para o executável. Isso significa que ele deve estar na variável do ambiente PATH ou o caminho para o binário deve ser absoluto.
Verifique a tabela de suporte ao idioma
lspclient.json . Também é possível especificar um comando diferente para cada plataforma, já que ela pode mudar em algumas ocassions por plataforma. Nesse caso, um objeto deve ser usado, com cada chave sendo uma plataforma, e também há uma plataforma curinga "outro" para especificar qualquer outra plataforma que não corresponda à definição da plataforma. Por exemplo, sourcekit-lsp usa: "command": {"macos": "xcrun sourcekit-lsp","other": "sourcekit-lsp"}{"name": "clangd","command_parameters": "--background-index-priority=background --malloc-trim"} O ECODE fornece uma integração básica do Git (mais recursos virão no futuro). Seu principal objetivo é ajudar o usuário a fazer as operações mais básicas com o Git. Alguns dos recursos atuais suportados: status Git e visualização de estatísticas (estados de arquivos), comprometimento, empurrar, fazer checkout, puxar, buscar, mesclagem rápida, criação de+renomeação+exclusão de ramificações, gerenciando stashes. Todas as estatísticas serão atualizadas/atualizadas automaticamente em tempo real. Há também alguma configuração básica disponível. O plug -in exige que o usuário tenha um binário git instalado e disponível na variável do ambiente PATH .
git.json O formato segue o mesmo padrão que todos os arquivos de configuração anteriores. A configuração é representada em um arquivo json com três chaves principais: config , keybindings , servers .
Exemplo de servidor C e C ++ LSP (usando Clangd)
{
"config" : {
"silent" : false ,
"status_recurse_submodules" : true ,
"statusbar_display_branch" : true ,
"statusbar_display_modifications" : true ,
"ui_refresh_frequency" : " 5s "
},
"keybindings" : {
"git-blame" : " alt+shift+b "
}
}.git ).O plug-in de preenchimento automático é responsável por fornecer sugestões para a conclusão do código e ajuda de assinatura.
O plug -in XML Tools (desativado por padrão) fornece algumas boas melhorias ao editar o conteúdo XML.
O ECODE respeita os caminhos de configuração padrão em cada sistema operacional:
XDG_CONFIG_HOME , geralmente se traduz em ~/.config/ecode/pluginsApplication Support em HOME , geralmente se traduz em ~/Library/Application Support/ecode/pluginsAPPDATA , geralmente se traduz em C:Users{username}AppDataRoamingecodepluginsTodas as configurações de plug -in foram projetadas para serem substituíveis pelo usuário. Isso significa que a configuração padrão pode ser substituída por configurações personalizadas do usuário. Por exemplo, se o usuário quiser usar um linhador diferente, ele só precisará declarar uma nova definição de Linter em seu próprio arquivo de configuração do Linter. O mesmo se aplica aos servidores Formatters e LSPS. Os plug -ins sempre implementarão uma "configuração" para a personalização de plug -ins e sempre implementarão uma tecla "Keybindings" para configurar as peças de chave personalizadas.
Os esquemas de cores do editor personalizado podem ser adicionados no diretório de esquemas de cores do usuário encontrado em:
XDG_CONFIG_HOME , geralmente se traduz em ~/.config/ecode/editor/colorschemesApplication Support em HOME , geralmente se traduz em ~/Library/Application Support/ecode/editor/colorschemesAPPDATA , geralmente se traduz em C:Users{username}AppDataRoamingecodeeditorcolorschemesQualquer arquivo gravado no diretório será tratado como um arquivo de esquema de cores do editor. Cada arquivo pode conter qualquer número de esquemas de cores.
O formato de um esquema de cores pode ser lido a partir daqui.
Os esquemas de cores do terminal personalizado podem ser adicionados no diretório de esquemas de cores do terminal do usuário encontrado em:
XDG_CONFIG_HOME , geralmente se traduz em ~/.config/ecode/terminal/colorschemesApplication Support em HOME , geralmente se traduz em ~/Library/Application Support/ecode/terminal/colorschemesAPPDATA , geralmente se traduz em C:Users{username}AppDataRoamingecodeterminalcolorschemesQualquer arquivo gravado no diretório será tratado como um arquivo de esquema de cores do terminal. Cada arquivo pode conter qualquer número de esquemas de cores.
O formato de um esquema de cores pode ser lido a partir daqui.
Os esquemas de interface do usuário personalizados podem ser adicionados no diretório de temas da interface do usuário do usuário encontrado em:
XDG_CONFIG_HOME , geralmente se traduz em ~/.config/ecode/themesApplication Support em HOME , geralmente se traduz em ~/Library/Application Support/ecode/themesAPPDATA , geralmente se traduz em C:Users{username}AppDataRoamingecodethemes Um arquivo de tema da interface do usuário personalizado deve ter a extensão .css , o ECODE procurará todos os arquivos com a extensão .css no diretório, o nome do tema da interface do usuário é o nome do arquivo sem a extensão. O novo tema aparecerá nas Settings -> Window -> UI Theme .
Os temas personalizados da interface do usuário permitem personalizar o editor à vontade do usuário. Como o ECODE usa o CSS para estilizar todos os elementos da interface do usuário, é fácil criar novos temas. É possível personalizar apenas a paleta de cores, mas também é possível personalizar todos os elementos da interface do usuário, se desejar. A personalização de todo o tema da interface do usuário pode ser extensa, mas a personalização das cores é tão simples quanto alterar os valores das variáveis CSS usadas para colorir a interface do usuário. Para referência, o tema completo da interface do usuário baseado pelo Ecode pode ser visto aqui. O seletor mais importante seria o :root , onde todas as variáveis são definidas. As variáveis de cores podem ser facilmente extraídas desse arquivo.
Um exemplo simples de um tema personalizado da interface do usuário que muda apenas as cores do tom, vamos chamá -lo de Breeze Light Red.css :
: root {
--inherit-base-theme : true;
--primary : # e93d66 ;
--scrollbar-button : # a94074 ;
--item-hover : # 502834 ;
--tab-hover : # 5e3347 ;
} Isso efetivamente criaria/adicionaria um novo tema da interface do usuário com cores vermelhas claras. Um detalhe muito importante é que, se o tema da interface do usuário deverá herdar a definição completa do tema padrão, devemos adicionar --inherit-base-theme: true ao :root , caso contrário, o tema da interface do usuário deve ser definido completamente, o que significa que todos os widgets devem ser estilizados do zero (não recomendado devido à sua complexidade). Também é possível substituir o estilo dos diferentes widgets, redefinindo suas propriedades com as regras usuais que se aplicam à conhecida especificação CSS (também conhecida em usar especificidade adequada e provavelmente abusando do sinalizador importante).
O suporte a idiomas personalizados pode ser adicionado no diretório de idiomas encontrado em:
XDG_CONFIG_HOME , geralmente se traduz em ~/.config/ecode/languagesApplication Support em HOME , geralmente se traduz em ~/Library/Application Support/ecode/languagesAPPDATA , geralmente se traduz em C:Users{username}AppDataRoamingecodelanguages O ECODE lerá cada arquivo localizado nesse diretório com a extensão json . Cada arquivo pode conter um ou vários idiomas. Para definir vários idiomas, o elemento raiz do arquivo JSON deve ser uma matriz, contendo um objeto para cada idioma; caso contrário, se o elemento raiz for um objeto, ele deve conter a definição de idioma. As definições de idioma podem substituir qualquer definição atualmente suportada. O ECODE priorizará as definições definidas pelo usuário.
{
"name" : " language_name " ,
"files" : [ " Array of file extensions supported " ],
"comment" : " Sets the comment string used for auto-comment functionality. " ,
"patterns" : [
{ "pattern" : " lua_pattern " , "type" : " type_name " },
{ "pattern" : " no_capture(pattern_capture_1)(pattern_capture_2) " , "type" : { " no_capture_type_name " , " capture_1_type_name " , " capture_2_type_name " } },
{ "pattern" : [ " lua_pattern_start " , " lua_pattern_end " , " escape_character " ], "type" : " type_name " }
],
"symbols" : [
{ "symbol_name" : " type_name " }
],
"visible" : true , /* sets if the language is visible as a main language in the editor, optional parameter, true by default */
"auto_close_xml_tag" : false , /* sets if the language defined supports auto close XML tags, optional parameter, false by default */
"lsp_name" : " sets the LSP name assigned for the language, optional parameter, it will use the _name_ in lowercase if not set "
}O ECODE usa o mesmo formato para definição de idioma que os editores Lite e Lite-XL. Isso facilita muito a adição de novos idiomas ao ECODE. Há também uma ferramenta auxiliar que pode ser download do repositório Ecode localizado aqui que permite exportar diretamente uma definição de idioma Lite para o formato de arquivo JSON usado no ECode.
É possível estender facilmente qualquer definição de idioma exportando-a usando os argumentos da CLI fornecidos: --export-lang e --export-lang-path . Um usuário que deseja estender ou melhorar uma definição de idioma pode exportá -lo, modificá -lo e instalar a definição com uma extensão .json no caminho de linguagens personalizadas. Por exemplo, para estender o idioma vue você precisará executar: ecode --export-lang=vue --export-lang-path=./vue.json , saia do arquivo exportado e mova-o para o caminho dos idiomas personalizado.
{
"name" : " Elixir " ,
"files" : [ " %.ex$ " , " %.exs$ " ],
"comment" : " # " ,
"patterns" : [
{ "pattern" : " #.* n " , "type" : " comment " },
{ "pattern" : [ " : " " , " " " , " \ " ], "type" : " number " },
{ "pattern" : [ " """ " , " """ " , " \ " ], "type" : " string " },
{ "pattern" : [ " " " , " " " , " \ " ], "type" : " string " },
{ "pattern" : [ " ' " , " ' " , " \ " ], "type" : " string " },
{ "pattern" : [ " ~%a[/ " |'%(%[%{<] " , " [/ " |'%)%]%}>] " , " \ " ], "type" : " string " },
{ "pattern" : " -?0x%x+ " , "type" : " number " },
{ "pattern" : " -?%d+[%d%.eE]*f? " , "type" : " number " },
{ "pattern" : " -?%.?%d+f? " , "type" : " number " },
{ "pattern" : " : " ?[%a_][%w_]* " ? " , "type" : " number " },
{ "pattern" : " [%a][%w_!?]*%f[(] " , "type" : " function " },
{ "pattern" : " %u%w+ " , "type" : " normal " },
{ "pattern" : " @[%a_][%w_]* " , "type" : " keyword2 " },
{ "pattern" : " _%a[%w_]* " , "type" : " keyword2 " },
{ "pattern" : " [%+%-=/%*<>!|&] " , "type" : " operator " },
{ "pattern" : " [%a_][%w_]* " , "type" : " symbol " }
],
"symbols" : [
{ "def" : " keyword " },
{ "defp" : " keyword " },
{ "defguard" : " keyword " },
{ "defguardp" : " keyword " },
{ "defmodule" : " keyword " },
{ "defprotocol" : " keyword " },
{ "defimpl" : " keyword " },
{ "defrecord" : " keyword " },
{ "defrecordp" : " keyword " },
{ "defmacro" : " keyword " },
{ "defmacrop" : " keyword " },
{ "defdelegate" : " keyword " },
{ "defoverridable" : " keyword " },
{ "defexception" : " keyword " },
{ "defcallback" : " keyword " },
{ "defstruct" : " keyword " },
{ "for" : " keyword " },
{ "case" : " keyword " },
{ "when" : " keyword " },
{ "with" : " keyword " },
{ "cond" : " keyword " },
{ "if" : " keyword " },
{ "unless" : " keyword " },
{ "try" : " keyword " },
{ "receive" : " keyword " },
{ "after" : " keyword " },
{ "raise" : " keyword " },
{ "rescue" : " keyword " },
{ "catch" : " keyword " },
{ "else" : " keyword " },
{ "quote" : " keyword " },
{ "unquote" : " keyword " },
{ "super" : " keyword " },
{ "unquote_splicing" : " keyword " },
{ "do" : " keyword " },
{ "end" : " keyword " },
{ "fn" : " keyword " },
{ "import" : " keyword2 " },
{ "alias" : " keyword2 " },
{ "use" : " keyword2 " },
{ "require" : " keyword2 " },
{ "and" : " operator " },
{ "or" : " operator " },
{ "true" : " literal " },
{ "false" : " literal " },
{ "nil" : " literal " }
]
}Para definições de sintaxe mais complexas, consulte a definição de todos os idiomas nativos suportados pelo ECOode aqui.
Listado em nenhuma ordem específica:
O autor é mais do que aberto a colaborações. Qualquer pessoa interessada no projeto é convidada a participar. Muitos recursos ainda estão pendentes e o projeto crescerá muito mais ao longo do tempo. Por favor, colabore. =)
Alguns caracteres Unicode não serão renderizados no editor fora da caixa. Você precisará alterar a fonte Monospace padrão em favor de uma fonte que suporta os personagens que você deseja ver que não estão sendo renderizados. Você também pode alterar a fonte de fallback padrão no caso em que deseja usar uma fonte monoespagada tradicional. A fonte de fallback padrão deve cobrir uma ampla gama de idiomas, mas você pode precisar de uma fonte especial (atualmente cobre idiomas CJK).
*1 Limitações atuais do recurso EEPP.
*2 Não sou fã de sugestão de sub-pixel. Mas estou mais do que disposto a implementá -lo, não sou muito versado no assunto, então qualquer ajuda será apreciada.
*3 Eu realmente não gosto de ligaduras. Estou aberto a PRs implementando -os.
*4 Não sou um usuário do VIM e não estou qualificado para implementar o modo VIM ou qualquer edição modal. Os PRs são bem -vindos para apoiar isso.
*5 Melhor suporte de formação de texto virá com o tempo, mas sem pressa no momento. A arquitetura EEPP está pronta para adicionar suporte de harfbuzz.
Este editor tem uma inspiração profundamente enraizada dos editores Lite, Lite-XL, Qtcreator e Sublime Text. Vários recursos foram desenvolvidos com base nas implementações Lite/Lite-XL. Alguns recursos podem ser portados diretamente do Lite: esquemas de cores e padrões de iluminação de sintaxe (a implementação do EEPP expande a implementação original do Lite para adicionar muitos outros recursos).
O ECODE está sendo usado principalmente em Linux e MacOS, ele não é bem testado no Windows. Se você encontrar algum problema com o editor, denuncie -o aqui.
Este é um trabalho em andamento, a estabilidade não é garantida. Por favor, não o use para tarefas críticas. Estou usando o editor diariamente e é estável o suficiente para mim, mas use -o por sua conta e risco.
Niels Lohmann para JSON para C ++ moderno
Neil Henning para Subprocess.h
Todos os autores do emulador de terminal sem sucção
Fredrik Aleksander para o Terminal HEXE
rxi para lite
Franko e todos os colaboradores do Lite-XL
Andreas Kling for Serenityos
E muito mais pessoas!
MIT Licença
