Editores de texto com código de domínio [fechado]

5

Editores gerais de texto não mudam muito. O realce de sintaxe e o recolhimento de código não são realmente grandes mudanças. Se um editor tiver estrutura ou domínio, isso geralmente vem com layouts diferentes - treeviews, menus de contexto, drag-and-drops e assim por diante. Então, há um bom exemplo para adicionar mais controle de domínio ao editar com cursor, seleção de texto e assim por diante?

Quando penso em explicar isso com exemplo, o que vem à mente:

  • Controle de sincronização (quando você exclui o primeiro i em <div>...</div> , isso muda automaticamente para <dv></dv>
  • Controle somente leitura (você está em "/" no fragmento acima que você não pode editar, mas se você selecionar <div> e pressionar Del, ambos serão excluídos
  • Navegação em camadas. Provavelmente modos diferentes quando o cursor ignora camadas irrelevantes quando você pressiona Esquerda, Direita e assim por diante. Por exemplo, se você estiver em navegação de texto para html, todas as tags serão ignoradas
  • Controle copiar e colar. O fragmento selecionado deve conter uma frase válida para o domínio e o local a ser inserido também deve ser compatível com ele.

Estes são apenas exemplos para você lembrar os editores do mundo real onde você conheceu algo semelhante.

Provavelmente, existem editores que permitem uma ou várias coisas dessa lista, mas suponho que soluções parciais não ajudem e possam até causar danos e causar transtornos. Portanto, a questão é mais sobre soluções complexas destinadas a melhorar a produtividade geral nos editores de texto gerais.

    
por Maksee 27.04.2012 / 10:01
fonte

4 respostas

1

Desenvolvi um editor de texto que era 'domínio ciente', mas provavelmente é melhor descrito como 'específico de domínio', pois foi escrito especificamente para XSLT.

Foi construído especialmente com questões de espaços em branco em mente. No XSLT, o espaço em branco no código-fonte precisa de atenção especial, pois ele provavelmente acabará na árvore de resultados.

A maioria dos editores depende da inserção de elementos XML extras para separar o espaço em branco de formatação de código dos espaços em branco destinados à saída - isso aumenta a verbosidade do código e reduz a legibilidade. Este novo editor usa o Virtual Formatting, que evita esse problema simplesmente usando margens dinâmicas para recuar o XSLT automaticamente.

O problema é que os usuários não podem se beneficiar totalmente da formatação virtual , a menos que outros editores também forneçam essa opção. Caso contrário, assim que um arquivo XSLT virtualmente formatado é aberto por um editor XSLT comum, uma carga inteira de caracteres indesejados é adicionada - para manter a formatação.

Não consegui persuadir outros fornecedores a considerar essa abordagem para a formatação. O que aprendi com isso é que os editores de texto não podem realmente mudar porque qualquer mudança seria perturbadora. A maioria dos desenvolvedores deseja usar editores de texto genéricos que possam trabalhar adequadamente com qualquer gramática / sintaxe em vez de usar aqueles dedicados a uma tarefa específica.

    
por 10.05.2012 / 14:58
fonte
3

Os editores de texto comuns do UNIX (emacs, vi e seus vários clones) são altamente extensíveis e provavelmente podem ser configurados para fazer a maioria ou todos os recursos listados.

O

vim, por exemplo, fornece uma gama de recursos prontos para uso que permitem o que você descreve ou alcança o mesmo objetivo em um caminho diferente. Por exemplo, os movimentos it e at ('marca interna' / 'a') podem ser usados para aplicar todos os tipos de operações gerais de edição a uma marca XML ou seu conteúdo. Escrever uma macro que fecha automaticamente uma tag é trivial. O salto pode ser conseguido usando movimentos baseados em tags em combinação com comandos gerais de movimento. O vim também tem um dobrador configurável com reconhecimento de sintaxe, e acho que fazê-lo dobrar o XML corretamente não deve ser muito difícil. Se isso não for suficiente, você pode canalizar qualquer parte do documento atual por meio de um comando externo usando a família ! de comandos. E finalmente, o vim tem alguma integração com ferramentas de construção e pode ser configurado para analisar sua saída para posicionar o cursor em qualquer erro.

Eu sou todo um especialista em emacs, mas estou bastante certo de que os emacs podem fazer as mesmas coisas, ou seus equivalentes no paradigma emacs.

O controle somente leitura é um recurso que eu odiaria - é meu texto, está lá, não há razão para me negar a editá-lo, se eu assim escolher. Sinalizar que o documento está errado por meio do realce agressivo da sintaxe e fornecer macros confortáveis para manipular o texto de uma maneira específica do domínio é uma escolha muito melhor.

Mas a razão mais importante para usar um editor de texto de propósito geral em uma ferramenta específica de domínio é que você só precisa aprender uma ferramenta - isso significa que você pode (e provavelmente irá) aprender essa ferramenta de dentro para fora, e isto, por sua vez, significa que uma ferramenta com uma curva de aprendizado louca e íngreme está perfeitamente bem, contanto que compense em termos de produtividade. O editor de texto de um especialista não precisa de uma interface gráfica, não precisa gastar recursos do sistema e exibir propriedades para a descoberta, e pode assumir que eu sei o que estou fazendo, em vez de tentar adivinhar onde estou. indo e sugerindo soluções.

    
por 27.04.2012 / 10:23
fonte
1

Um editor que, na minha humilde opinião, um belo exemplo de edição sensível ao contexto é o TeXmacs do GNU. Experimente, é de código aberto e mostra exatamente os prós e contras da edição com reconhecimento de contexto.

    
por 27.04.2012 / 13:16
fonte
0

Estou trabalhando em um editor com esses recursos. É um editor de texto simples projetado para editar dados que se assemelham a tabelas, onde as colunas são delimitadas por pipes (na verdade, space-pipe-space). Pressionar a guia moverá você para outra "célula", como uma planilha, e há comandos que lidam com "células" e "linhas" em vez de "palavras" e "linhas de texto". Ele possui recursos para alinhar colunas e para detectar linhas contíguas com um número igual de colunas (cada linha pode potencialmente ter um número diferente de colunas). Ele também conhece a sintaxe da variável um tanto peculiar, os títulos das tabelas e assim por diante.

O júri ainda está fora do sucesso deste tipo de editor, mas acho que tem algum potencial. Enquanto os usuários avançados ainda podem configurar seu editor de força industrial (ou seja: vim, emacs) para fazer as mesmas coisas, há um segmento muito grande da população que não utiliza essas ferramentas. Então, enquanto, sim, você pode fazer isso com o emacs, a maioria dos usuários (que eu estou segmentando, de qualquer forma) quer algo menos complexo.

    
por 27.04.2012 / 13:08
fonte