Design·16 de junho de 2026·6 min de leitura

Por que criamos mais um editor de Markdown

Já existem muitos editores de Markdown, então por que criar mais um? Não foi por falta de recursos, mas porque os valores que ele mantém em aberto, os vestígios que o salvamento deixa e a sensação nas pontas dos dedos nunca estiveram em sintonia dentro de um mesmo produto.

mote

Notas de lançamento abertas no modo ao vivo. Os símbolos de Markdown ficam ocultos e aparecem discretamente apenas na linha do título onde o cursor está posicionado.

Sempre que escolhia um editor de Markdown, precisava abrir mão de alguma coisa.

Os aplicativos com edição em linha conveniente alteravam o arquivo ao salvá-lo. Os que preservavam o arquivo como estava deixavam a desejar na experiência de edição. E os aplicativos repletos de recursos para notas eram pesados até mesmo para abrir um único documento.

No fim, eu mantinha dois editores abertos ao mesmo tempo.

Foi por isso que comecei a criar o mote. Um editor que preserva as três coisas.

Ocultar os símbolos de Markdown e permitir a edição direta
Salvar exatamente como está o arquivo que escrevi
Funcionar de forma leve, sem um motor web

Já existem muitos produtos que fazem cada uma dessas coisas. Mas não encontrei nenhum que atendesse às três ao mesmo tempo.

Vou falar de leveza com números

A maioria dos editores de Markdown que oferece edição em linha usa um motor web como WebKitGTK ou Chromium. É uma abordagem que transforma o Markdown em HTML e o renderiza em um navegador.

A implementação fica mais fácil, mas isso tem um custo. É como se houvesse um navegador aberto ao lado do documento. O número de processos e o uso de memória aumentam, e cada tecla digitada passa por várias etapas.

Ainda assim, são raros os produtos que divulgam esse custo. Nas páginas dos produtos, em vez do uso de CPU em repouso ou da latência de digitação, só resta a palavra “leve”.

O mote faz diferente.

Medimos o uso de CPU em repouso, a memória, a latência de digitação e o tempo de inicialização no mesmo computador e da mesma maneira. Os scripts de medição e os dados brutos também ficam no repositório. Não lançamos nenhuma compilação que ultrapasse o orçamento de desempenho definido.

Nas comparações, também usamos apenas valores medidos no mesmo momento. Um valor que não foi possível medir não é registrado como zero, mas identificado como não medido.

Porque leveza deve ser uma medida, não uma sensação.

Não alteramos o arquivo ao salvá-lo

Quando você gerencia documentos com git, às vezes encontra diffs estranhos.

Você altera apenas uma célula de uma tabela, mas o commit seguinte aparece cheio de linhas que não foram modificadas. Isso acontece porque o editor reajustou os espaços ou o alinhamento da tabela ao salvar. Uma linha alterada por você acaba misturada a vinte linhas alteradas pelo editor.

Isso não significa que todo o conteúdo seja alterado. Há editores que preservam bem as quebras de linha e os espaços consecutivos. As diferenças aparecem principalmente em tabelas e alinhamentos. E a capacidade de salvar o arquivo exatamente como está também não é exclusiva do mote.

Mesmo assim, considerei que essa era uma condição indispensável.

No mote, o texto é a referência. Os bytes do arquivo são colocados diretamente no buffer, e o texto em negrito, as tabelas e as fórmulas são desenhados sobre ele. Ao salvar, o buffer é gravado diretamente no disco.

A aparência da tela pode melhorar, mas o arquivo não é alterado às escondidas.

Diff do git depois de alterar uma única célula da tabela de 'review' para 'approval' e salvar — as únicas linhas modificadas são a da célula e a do último parágrafo, enquanto o alinhamento dos pipes e os marcadores com asterisco permanecem intactos. A linha de status mostra +8 −6 B.

Começamos fazendo a digitação em coreano funcionar direito

O desconforto sutil dos editores baseados na web é sentido nas pontas dos dedos. Mesmo quando a rolagem, o desfoque e os movimentos parecem semelhantes, eles diferem um pouco dos aplicativos nativos do sistema operacional.

A diferença fica ainda maior ao digitar em coreano.

Às vezes, o caractere que está sendo composto se separa, o cursor salta ou a entrada se perde no fim da linha. Esses problemas surgem durante o processamento dos eventos de composição do coreano pelo editor web.

No mote, os caracteres e os efeitos são desenhados diretamente pelo sistema operacional. A composição do coreano também é recebida diretamente pelo método de entrada da plataforma. Em contrapartida, é preciso implementar o método de entrada separadamente para cada sistema operacional e verificá-lo em dispositivos reais. No momento, temos o Linux, enquanto as versões para macOS e Windows estão em desenvolvimento.

É o caminho mais difícil, mas essa diferença é importante para quem escreve textos longos.

Documento em coreano aberto no modo ao vivo — o # no início aparece discretamente apenas na linha do título onde o cursor está posicionado, enquanto o negrito, o itálico e o código em linha acima são renderizados sem os símbolos. — Documento em coreano aberto no modo ao vivo — o `#` no início aparece discretamente apenas na linha do título onde o cursor está posicionado, enquanto o negrito, o itálico e o código em linha acima são renderizados sem os símbolos.

Talvez não sejam muitas as pessoas que precisam do mote.

Desenvolvedores que gerenciam arquivos README e documentos de projeto com git. Pessoas que escrevem textos longos em coreano. Pessoas que mantêm o editor aberto no notebook o dia inteiro.

Mas os motivos que as fazem abandonar um editor são claros.

Diffs bagunçados. Digitação em coreano interrompida. A ventoinha que não para de girar.

Também definimos o que não faremos

O mote não tem sincronização, plugins, backlinks, IA nem recursos de colaboração.

Não criaremos um sistema próprio de sincronização. Não teremos contas nem servidores. Nem sequer criaremos um arquivo de configuração separado na pasta de documentos. Não incluímos recursos que exijam um estado que não possa ser expresso em Markdown.

Assim, apenas arquivos .md permanecem na pasta. iCloud, Syncthing e git continuam funcionando normalmente sem sequer saber que o mote existe.

Também não abriremos uma API de plugins. Isso porque até mesmo um único temporizador executado por um plugin pode quebrar a promessa de desempenho. Em vez disso, deixamos abertos os temas, os snippets e os modelos de exportação. É possível mudar a aparência do resultado sem afetar o desempenho durante a edição.

Também não criaremos backlinks nem visualização em grafo. Afinal, este não é um produto que pretende competir com bancos de dados de notas. O suporte vai apenas até a árvore de pastas e os links relativos padrão.

Também não incluiremos IA. Ela não resume nem continua textos e tampouco lê a pasta de documentos para enviá-la a serviços externos. Também considero uma funcionalidade importante o fato de o editor não enviar meus documentos para lugar algum.

Também não oferecemos colaboração em tempo real. Para permitir a edição colaborativa, o modelo de documento do servidor precisaria ser a referência. Isso entraria em conflito com o princípio de preservar exatamente como está o arquivo no disco.

Entre os dois, o mote escolheu o arquivo.

Se você precisa do ecossistema do Obsidian, o Obsidian é melhor. Se a estabilidade consolidada do Typora é importante, o Typora é a escolha certa. E a tipografia do iA Writer ainda é um objetivo que precisamos alcançar.

O mote não pretende substituir todos os editores de Markdown.

Também não era simplesmente necessário ter mais um editor de Markdown.

Era necessário ter um editor que respeitasse ao mesmo tempo os arquivos e o notebook.

Mais recentes →O que tornava tudo pesado não era o Markdown, mas o motor web

Acompanhe por RSS.