Como um editor de código pode sugerir efetivamente o nível de aninhamento de código - sem usar recuo? [fechadas]

Eu escrevi um editor de texto XML que fornece duas opções de exibição para o mesmo texto XML, um recuado (virtualmente) e o outro justificado à esquerda. A motivação para a visualização justificada à esquerda é ajudar os usuários a 'ver' os caracteres de espaço em branco que estão usando para indentação de texto sem formatação ou código XPath sem interferência da indentação que é um efeito colateral automatizado do contexto XML.

Desejo fornecer pistas visuais (na parte não editável do editor) para o modo justificado à esquerda que ajudará o usuário, mas sem ser muito elaborado.

Tentei apenas usar linhas de conexão, mas isso parecia muito ocupado. O melhor que eu vim até agora é mostrado em uma captura de tela zombada do editor abaixo, mas estou procurando alternativas melhores / mais simples (que não exigem muito código).

[Editar]

Tomando a ideia do mapa de calor (de: @jimp), recebo esta e três alternativas - rotuladas como a, bec:

A seção a seguir descreve a resposta aceita como uma proposta, reunindo idéias de várias outras respostas e comentários. Como esta pergunta agora é wiki da comunidade, fique à vontade para atualizá-la.

NestView

O nome dessa idéia, que fornece um método visual para melhorar a legibilidade do código aninhado sem usar recuo.

Linhas de contorno

O nome das linhas sombreadas de maneira diferente no NestView

A imagem acima mostra o NestView usado para ajudar a visualizar um snippet XML. Embora XML seja usado para esta ilustração, qualquer outra sintaxe de código que use aninhamento poderia ter sido usada para esta ilustração.

Uma visão geral:

1. As linhas de contorno são sombreadas (como em um mapa de calor) para transmitir o nível de aninhamento

2. As linhas de contorno são anguladas para mostrar quando um nível de aninhamento está sendo aberto ou fechado.

3. Uma linha de contorno vincula o início de um nível de aninhamento ao final correspondente.

4. A largura combinada das linhas de contorno fornece uma impressão visual do nível de aninhamento, além do mapa de calor.

5. A largura do NestView pode ser redimensionada manualmente, mas não deve mudar à medida que o código é alterado. As linhas de contorno podem ser compactadas ou truncadas para manter isso.

6. Às vezes, linhas em branco são usadas para dividir o texto em pedaços mais digeríveis. Essas linhas podem desencadear um comportamento especial no NestView. Por exemplo, o mapa de calor pode ser redefinido ou uma linha de contorno de cor de fundo usada, ou ambas.

7. Uma ou mais linhas de contorno associadas ao código atualmente selecionado podem ser destacadas. A linha de contorno associada ao nível de código selecionado seria mais enfatizada, mas outras linhas de contorno também poderiam "acender", além de ajudar a destacar o grupo aninhado

8. Comportamentos diferentes (como dobra de código ou seleção de código) podem ser associados ao clicar / clicar duas vezes em uma linha de contorno.

9. Diferentes partes de uma linha de contorno (aresta inicial, média ou final) podem ter diferentes comportamentos dinâmicos associados.

10. As dicas de ferramentas podem ser mostradas em um evento de foco do mouse sobre uma linha de contorno

11. O NestView é atualizado continuamente à medida que o código é editado. Onde o aninhamento não é bem equilibrado, é possível fazer suposições onde o nível de aninhamento deve terminar, mas as linhas de contorno temporárias associadas devem ser destacadas de alguma forma como um aviso.

12. Os comportamentos de arrastar e soltar das linhas de contorno podem ser suportados. O comportamento pode variar de acordo com a parte da linha de contorno que está sendo arrastada.

13. Recursos comumente encontrados na margem esquerda, como numeração de linhas e destaque de cores para erros e alteração de estado, podem sobrepor o NestView.

Funcionalidade Adicional

A proposta aborda uma série de questões adicionais - muitas estão fora do escopo da pergunta original, mas um efeito colateral útil.

Vincular visualmente o início e o fim de uma região aninhada

As linhas de contorno conectam o início e o fim de cada nível aninhado

Destacando o contexto da linha atualmente selecionada

À medida que o código é selecionado, o nível de ninho associado no NestView pode ser destacado

Diferenciando entre regiões de código no mesmo nível de aninhamento

No caso do XML, diferentes matizes podem ser usados ​​para diferentes namespaces. Linguagens de programação (como c #) oferecem suporte a regiões nomeadas que podem ser usadas de maneira semelhante.

Dividindo áreas dentro de uma área de nidificação em diferentes blocos visuais

Linhas extras são frequentemente inseridas no código para facilitar a legibilidade. Essas linhas vazias podem ser usadas para redefinir o nível de saturação das linhas de contorno do NestView.

Visualização de código de várias colunas

Código sem recuo torna o uso de uma exibição de várias colunas mais eficaz, pois é menos provável que seja necessária a quebra de linha ou a rolagem horizontal. Nesta visão, quando o código atinge a parte inferior de uma coluna, ele flui para a próxima:

Uso além de apenas fornecer uma ajuda visual

Conforme proposto na visão geral, o NestView poderia fornecer uma variedade de recursos de edição e seleção que estariam amplamente alinhados com o que é esperado de um controle TreeView. A principal diferença é que um nó TreeView típico possui 2 partes: um expansor e o ícone do nó. Uma linha de contorno NestView pode ter até três partes: um abridor (inclinado), um conector (vertical) e um fechamento (inclinado).

No recuo

O NestView é apresentado juntamente com complementos de código não recuado, mas é improvável que substitua a exibição de código recuado convencional.

É provável que qualquer solução que adote um NestView forneça um método para alternar perfeitamente entre exibições de código recuadas e não recuadas sem afetar nenhum texto do código em si - incluindo caracteres de espaço em branco. Uma técnica para a exibição recuada seria 'Formatação virtual' - onde uma margem esquerda dinâmica é usada no lugar de caracteres de tabulação ou espaço. Os mesmos dados no nível de aninhamento usados ​​para renderizar dinamicamente o NestView também podem ser usados ​​para a exibição recuada de aparência mais convencional.

Impressão

O recuo será importante para a legibilidade do código impresso. Aqui, a ausência de caracteres de tabulação / espaço e uma margem esquerda dinâmica significa que o texto pode quebrar na margem direita e ainda manter a integridade da exibição recuada. Os números de linha podem ser usados ​​como marcadores visuais que indicam onde o código está quebrado por palavras e também a posição exata do recuo:

Imobiliário de tela: plano versus recuado

Abordando a questão de saber se o NestView usa valiosos imóveis da tela:

As linhas de contorno funcionam bem com uma largura igual à largura dos caracteres do editor de código. Uma largura do NestView de 12 caracteres pode, portanto, acomodar 12 níveis de aninhamento antes que as linhas de contorno sejam truncadas / compactadas.

Se uma vista recuada usar 3 larguras de caracteres para cada nível de aninhamento, o espaço será economizado até o aninhamento atingir 4 níveis de aninhamento. Após esse nível, a vista plana terá uma vantagem de economia de espaço que aumenta a cada nível de aninhamento.

Nota: Um recuo mínimo de 4 larguras de caracteres é frequentemente recomendado para código, no entanto, o XML geralmente gerencia com menos. Além disso, a Formatação virtual permite que menos recuo seja usado porque não há risco de problemas de alinhamento

Uma comparação das 2 visualizações é mostrada abaixo:

Com base no exposto, provavelmente é justo concluir que a escolha do estilo de exibição será baseada em outros fatores que não sejam os imóveis na tela. A única exceção é onde o espaço na tela é limitado, por exemplo, em um Netbook / Tablet ou quando várias janelas de código são abertas. Nesses casos, o NestView redimensionável parece ser um vencedor claro.

Casos de Uso

Exemplos de exemplos do mundo real em que o NestView pode ser uma opção útil:

1. Onde os imóveis da tela são escassos

   uma. Em dispositivos como tablets, blocos de notas e smartphones

   b. Ao mostrar código em sites

   c. Quando várias janelas de código precisam estar visíveis na área de trabalho simultaneamente

2. Onde a recuo consistente de espaço em branco do texto no código é uma prioridade

3. Para revisar código profundamente aninhado. Por exemplo, onde sub-idiomas (por exemplo, Linq em C # ou XPath em XSLT) podem causar altos níveis de aninhamento.

Acessibilidade

As opções de redimensionamento e cor devem ser fornecidas para ajudar as pessoas com deficiência visual e também para atender às condições ambientais e preferências pessoais:

Compatibilidade do código editado com outros sistemas

Uma solução que incorpore uma opção NestView deve, idealmente, ser capaz de remover os caracteres de tabulação e espaço iniciais (identificados como tendo apenas uma função de formatação) do código importado. Então, uma vez retirado, o código poderia ser renderizado ordenadamente nas visualizações justificada à esquerda e recuada sem alterações. Para muitos usuários que confiam em sistemas como ferramentas de fusão e de diferenças que não reconhecem o espaço em branco, essa será uma grande preocupação (se não um completo complemento).

Outros trabalhos:

Visualização da marcação sobreposta

A pesquisa publicada por Wendell Piez , datada de 2004, aborda a questão da visualização da marcação sobreposta, especificamente o LMNL . Isso inclui gráficos SVG com semelhanças significativas com a proposta do NestView; portanto, eles são reconhecidos aqui.

As diferenças visuais são claras nas imagens (abaixo), a principal distinção funcional é que o NestView é destinado apenas a XML ou código bem aninhado, enquanto os gráficos de Wendell Piez são projetados para representar aninhamento sobreposto.

Os gráficos acima foram reproduzidos - com a devida permissão - de http://www.piez.org

Fontes:

1. Rumo à marcação hermenêutica
2. Meios passos em direção a LMNL

Eu tentei responder minha própria pergunta aqui, mas isso está incorporando a ideia de mapa de calor do @jimp e também a idéia de 'torná-lo mais XML-ish' de @Andrea:

Felizmente, as cores no mapa de calor, juntamente com as linhas angulares, ajudam a chamar a atenção entre as tags de início e fim; a remoção dos separadores de linhas horizontais melhora o 'fluxo' do início ao fim. À medida que o usuário seleciona com um elemento, a parte correspondente no mapa de calor pode ser destacada de alguma forma - talvez com uma borda brilhante (como mostrado).

Editar Decidiram ir com isso, provavelmente haverá opções de usuário para as cores. Uma captura de tela 'pronta para produção':

E para comparação ... a visão recuada alternativa:

Editar agora, para o caso mais aninhado - testar minhas habilidades de desenho ...

Uma idéia pode ser tentar adicionar 3D ao texto. Aumente / diminua o tamanho da fonte com base em qual nível está.

Por exemplo, este código:

Ficaria assim:

Isso pode ser chato de trabalhar, pois perde o alinhamento fixo do tamanho do texto em diferentes níveis. Outra ideia; altere a saturação de cada nível:

Quão bem isso vale para algo realmente profundo? Não tenho certeza...

Na verdade, eu gosto muito da sua ideia de visualização da sarjeta; é fácil agrupar as coisas. Talvez combinado com uma dessas idéias, pareça ainda melhor ou muito ruim. ;)

Algum tempo atrás, fiz um mapa de calor mostrando o escopo em C. Pode ser divertido olhar para um brainstorming:

Alinhado à esquerda:

Basta ajustar a sua ideia original e mudar de quadrados para cápsulas. Acho que essas versões (incluindo a original) são mais fáceis de ler, porque são menos complexas que a que mostra o aninhamento através do aninhamento dos elementos de exibição. Eu acho que os elementos da árvore transmitem as informações de uma maneira mais simples e intuitiva.

Eu acho que a esquerda é ótima para mostrar diretamente o recuo, enquanto a direita é melhor para transmitir um relacionamento aninhado.

Minha ideia:

O aninhamento se parece mais com o aninhamento. A largura horizontal de cada camada não precisa ser tão larga.

Adoro a ideia. Minha sugestão para manter o "ocupado" baixo seria usar gradientes em vez de quadrados. Reduziria as linhas. Talvez cores diferentes para indentação extrema.

Eu diria que tudo o que você tem é ótimo, embora um pouco complicado para o meu gosto.

Meus comentários: Eu tenho lutado constantemente com a maneira como o Visual Studio IDE identifica. Eu adoraria usar algo assim ou uma variação.

Imagine esse link sem as linhas e alinhe-se com o seu xml / código atual.

Como você disse que a visualização deve existir na margem não editável (esquerda?), Acredito que isso significa que a visualização não pode ser misturada ou por trás do código.

Talvez um mapa de calor na coluna da esquerda, com cores mais brilhantes indicando recuo mais profundo? Torne a margem um tamanho fixo, com uma visualização como a que você tem (espere que vá da esquerda para a direita como o recuo) que usa dinamicamente todo o espaço fornecido de acordo com o recuo máximo, conforme determinado pela profundidade do DOM.

Se você deseja se ramificar na região do editor, sugiro algo muito semelhante, mas como pano de fundo do documento. A área sombreada seria onde os espaços em branco estariam se o recuo estivesse ativado. Nesse caso, eu usaria uma cor sólida e clara que contrasta com o realce do texto.

O jGRASP faz isso usando um marcador visual na margem:

Ele até reconhece quando você está usando um loop e usa um tipo diferente de linha para representar esse loop interno.

Apenas pensei em apontar como um editor existente faz isso.

Não é uma má idéia, mas ter que fazer referência à margem esquerda para ver claramente meus bloqueios pode ficar um pouco chato. Isso nem sequer está pensando no espaço da tela ou em como as coisas podem começar a parecer se a estrutura ficar muito profunda.

Como a motivação é ajudar os usuários a 'ver' os caracteres de espaço em branco que estão usando para indentação, você pode apenas mostrar a eles os caracteres de espaço em branco.

Não estou falando de caracteres visuais especiais, como marcadores de parágrafo, apenas os destaques. Espaços em amarelo, tabulações em verde (ou o que seja)

Para a questão de margem / aninhamento, você pode simplesmente mover a margem para cada bloco. Não há nada que diga que a margem deve ser uma linha reta.

Tenho certeza de que essa não é uma idéia nova.

Algo assim:

Por que não abrir e fechar parênteses?

1. Indentação significa contenção: (e) significa exatamente isso para os programadores.
2. (e) têm um único caractere: a barra esquerda permanecerá muito fina.
3. Os elementos vazios são facilmente identificados: use () na mesma linha.
4. O conteúdo de um elemento não precisa de uma pista visual: um espaço em branco é muito melhor.
5. A posição do cursor à direita pode ser correspondida pelo bloco à esquerda: adicione dinamicamente uma cor aos caracteres na coluna com (e)
6. Você poderia torná-lo mais XML-ish usando <e>, que parecem melhores à distância.

O Vim já pode fazer algo semelhante, embora não tão bonito.

Existem várias maneiras de fazer "dobragem de código" no Vim. Um deles é baseado em regras de dobragem de sintaxe. Quando isso é feito, o código pode ser dobrado usando uma estrutura de estrutura de tópicos aninhada e o "FoldColumn" pode ser usado para fornecer uma representação gráfica (na verdade "baseada em caracteres" com '|' e '-' chars) representação do "nível de dobra" .

A coluna fold pode fornecer a representação de aninhamento, independentemente do método fold, mas o método baseado em sintaxe é aquele que provavelmente seria apropriado para o que você deseja. Não tenho certeza se existem regras de dobragem pré-fabricadas baseadas em sintaxe para xml em algum lugar, eu acho que pode haver.

Acho que você está no caminho certo com as opções B e C: inclua a largura e a coloração do mapa de calor. Eu gosto da opção B mais do que C no momento, porque é menos intrusiva (seja larga e diluída, ou estreita e intensa, ao invés do bloco muito pesado no meio de C). Uma desvantagem é que, com essa opção, você precisa reconstrua o gráfico inteiro se você inserir um nível em algum lugar. Eu acho que você poderia fazer os blocos muito menores, 1 ou 2 px provavelmente seria suficiente. Não precisa ser muito, só precisa ser distinguível. Especialmente quando se espera que as pessoas usem o editor muitas vezes, é mais fácil trabalhar com efeitos discretos e mais sutis, porque eles não distraem tanto.

Uma coisa que é importante ao usar um tipo de editor é destacar o escopo atual: ao selecionar uma linha no editor, você precisa ver exatamente quais elementos ela contém e onde ela para. Você pode até destacar a árvore (de quais elementos ela é filha). Eu acho que é uma questão separada que precisa ser tratada e pensada e terá mais influência sobre como os usuários avaliarão sua experiência com o editor.

Uma coisa que eu não vi mencionada é o que você pode fazer com a tonalidade além do efeito de saturação em que você parece ter se estabelecido. Minha sugestão é mudar a cor do ninho em que o ponteiro se encontra. Isso tornaria mais fácil para o usuário distinguir quais linhas fazem parte do ninho, versus irmãos ao longo do caminho.

Ao implementar itens baseados em matiz, tenha consciência do daltonismo e selecione cores universalmente distinguíveis ou ofereça algumas opções para as pessoas escolherem.

Uma opção, que poderia ser usada em conjunto com as outras sugestões até agora, seria usar uma dica de ferramenta na margem esquerda que mostra o caminho para a linha usando a notação XPath. As ferramentas do "inspecionar elemento" do navegador (por exemplo, Firebug, aquele incorporado ao Chrome) geralmente fazem algo semelhante, mas em uma barra de status.

Possivelmente, você pode ter uma visão reduzida do mapa de calor (da postagem original) com apenas uma coluna de cores e os números de profundidade. Isso permitiria que eles soubessem a profundidade deles e lhes desse mais espaço na tela para o xml. Parece uma vitória para mim.

Estou preocupado se haverá diferenças de cores suficientes para aninhar as coisas profundamente.