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

233

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).

indicação de nível de aninhamento do editor de código

[Editar]

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

Idéias iniciais

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

insira a descrição da imagem aqui

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:

insira a descrição da imagem aqui

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:

insira a descrição da imagem aqui

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:

insira a descrição da imagem aqui

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:

insira a descrição da imagem aqui

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.

insira a descrição da imagem aqui

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
pgfearo
fonte
6
Não tenho uma resposta real para você, apenas opinião. Olhando para seus exemplos, B é minha escolha preferida. Isso se destaca para mim porque o "mapa de calor" segue o recuo, em vez de espelhá-lo como no primeiro exemplo e C faz. A também segue o recuo real, mas B é mais parecido com o que você veria quando o xml real seria recuado. O segundo exemplo é simplesmente "sólido" demais para o meu gosto.
Marjan Venema
4
Eu preferiria o código recuado. Não sabe qual seria o benefício disso? Estou perdendo algo óbvio? (Realmente não pretendo para este soar negativo.)
Chris
9
Não vejo como ocupar uma margem enorme em 100% das linhas é melhor do que ocupar apenas a margem necessária para cada linha.
John Gietzen
1
@John Gietzen. O objetivo não é salvar o espaço da tela (embora isso possa ser o efeito em muitos casos). É para permitir um controle mais rígido dos caracteres de espaço em branco quando isso é importante - uma exibição recuada ainda seria fornecida (mas virtual, sem o uso de caracteres de preenchimento).
Pgfearo
3
Estou votando para encerrar esta questão como fora de tópico, porque é uma pergunta UX, mas muito antiga para migrar.
Ratchet freak

Respostas:

104

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:

insira a descrição da imagem aqui

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':

insira a descrição da imagem aqui

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

insira a descrição da imagem aqui

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

insira a descrição da imagem aqui

pgfearo
fonte
1
Parece ótimo ! Bom trabalho. Mas como ficará quando houver mais indentação?
Loïc Lopes
1
@Louhike Thanks! Sim, está no máximo em quatro níveis e não quero esticar a margem esquerda para obter mais - portanto, compactarei a largura das barras verticais cada vez mais em níveis de aninhamento mais altos - um pouco como um mapa de contorno, espero.
Pgfearo
2
@Louhike. Adicionei uma imagem extra para mostrar como as coisas poderiam parecer com 9 níveis de aninhamento - após cerca de 15 níveis, provavelmente seria necessário mesclar as barras do meio, talvez usando um preenchimento de gradiente.
Pgfearo
10
Isso é simplesmente incrível. +1 para levar a edição de código e a interface do usuário para o próximo nível. Alguém com uma conta deve postar isso no Hacker News, /.ou r / programming.
Konrad Rudolph
2
Se perguntou como seria parecido com a barra lateral lançado horizontalmente ... imgur.com/u5mNi
chanux
24

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:

insira a descrição da imagem aqui

Ficaria assim:

insira a descrição da imagem aqui

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:

insira a descrição da imagem aqui

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:

insira a descrição da imagem aqui

Alinhado à esquerda:

insira a descrição da imagem aqui

Dave Gallagher
fonte
2
É tentador fazer algo com o texto, mas isso é difícil de fazer sem distrair o desenvolvedor enquanto ele digita ou logo depois. Alterações que afetam a altura da fonte causam problemas - possivelmente toleramos ver nosso código subir e descer ainda menos do que um lado para o outro. Gosto da sua idéia de sombrear o código, mas isso teria que ser sutil, pois quero tentar manter as coisas organizadas.
Pgfearo
2
mas isso seria ótimo para ambientes de ensino!
jcolebrand
A sugestão de tamanho da fonte é estranhamente atraente - embora eu possa ver suas desvantagens. Por que não fazer o tipo de letra menor que o escopo é mais profundamente aninhados - isso ajudaria a desencorajar profunda nidificação (embora ele iria causar problemas onde assentamento profundo é realmente uma solução sensata)
Peter
2
o heatmap é realmente muito melhor em visualizar escopo do que a visualização escopo alinhado à esquerda (@ solução de pfgearo)
Sandeep
@Sandeep. Concordo que essa é, em muitos casos, uma solução melhor - especialmente ao revisar o código em vez de editá-lo. Restrições técnicas (conforme explicado na pergunta) dificultam a modificação da cor do plano de fundo com o controle atual que estou usando. Efetivamente, usei o lado esquerdo do mapa de calor nesta resposta - mas com as bordas inclinadas em direção à área editada para ajudar a chamar a atenção. Um problema com um fundo de texto colorido é que a legibilidade / contraste é perdida em maior níveis de aninhamento.
Pgfearo
21

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.

cápsulas

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

Jeremy Giberson
fonte
2
Prefiro a suavidade das suas cápsulas, por mais que pareçam muito distantes do texto, preciso de algo mais coeso e que ofereça uma visão mais clara do que são as partes que os contêm.
Pgfearo
9

Minha ideia:

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

broc7
fonte
Acho que o que você está propondo é essencialmente o mesmo que a resposta (inspirada nos outros) que dei, mas sem as linhas inclinadas. Eu acho que linhas inclinadas ajudam a chamar a atenção do que é melhor para abrir e fechar. A largura não é um problema real porque (como mostrado na imagem de 9 níveis) a largura da linha vertical é independente da largura da linha inclinada, portanto, as linhas verticais podem ser compactadas.
Pgfearo
Sim, pg- notei isso depois que postei. Eles são topograficamente idênticos - para se divertir com isso. É uma questão de gosto, suponho, mas minha versão simplesmente grita "aninhamento" para mim da maneira que sua versão não. Talvez esse recurso possa ostentar os dois e permitir que o usuário escolha.
broc7
8

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.

Gauthier
fonte
Sim, as idéias ainda estão evoluindo. As imagens na resposta que enviei (em vez da minha pergunta) são menos irregulares porque têm inclinações à frente / à direita. Estou pensando em usar gradientes (mas de maneira um pouco diferente) também para diminuir um pouco as coisas. Estou com você nas diferentes cores, para indentação alta, mas também para destacar coisas como comentários ou erros. E há o destaque dinâmico, para mostrar o contexto / depuração atual ... a dificuldade estará em julgar quando parar.
Pgfearo
5

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.

jimp
fonte
@ jimp Sim, a visualização não pode estar com ou por trás do código - tanto quanto eu adoraria tentar isso, minhas habilidades / plataforma de codificação tornariam isso muito complexo. As cores de segundo plano no próprio editor são novamente difíceis, mas isso me dá a ideia de que eu poderia experimentar diferentes tons de cores de primeiro plano. Vou experimentar uma barra da esquerda para a direita e um mapa de calor também, como você sugere.
Pgfearo
+1 para a ideia do mapa de calor (Y). E posso sugerir que o nível de aninhamento esteja dentro da cor para pessoas com necessidades especiais visuais (como daltonismo).
M.Sameer
@jimp. Atualizado a minha pergunta para ilustrar sua idéia heatmap, que eu gosto, mas eu acho que eu tenho a coisa da esquerda para a direita errado ...
pgfearo
@pgfearo Estou feliz que minhas idéias foram úteis! Com base no que vejo que você fez, acho que estou gostando mais do L&F da direita para a esquerda. Lamento não ter tido a chance de verificar antes (fim de semana movimentado). Como você fez tanto progresso, comentarei a resposta que você postou acima.
jimp
@pgfearo Ops, não tenho reputação o suficiente para comentar sua resposta! Vou postar algumas reflexões sobre sua resposta assim que ganhar esse privilégio, espero que em breve!
jimp
3

O jGRASP faz isso usando um marcador visual na margem:

insira a descrição da imagem aqui

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.

cinza
fonte
5
Muito barulhento na minha opinião, mas ainda é uma boa idéia.
Konrad Rudolph
Eu procurei isso, e a documentação do site implica que a captura de tela é de um visualizador de código, é um diagrama, não um editor de código. Além disso, concedido que não há caracteres de preenchimento, mas ainda é uma exibição recuada. Estou procurando soluções simples que não exijam recuo do código, pelas razões indicadas na pergunta. Dito isto, o JGrasp parece uma excelente ferramenta para melhorar a compreensibilidade do código.
Pgfearo
O JGrasp deveria ser um editor de código da minha escola. Nós o usamos em nossa aula de introdução à ciência da computação, era o editor de código recomendado. Possui ferramentas para ajudar a compilar e executar seu programa, mas não é tão sofisticado quanto o Eclipse ou o Netbeans. Mas está um pouco diferente do que você descreveu como não é realmente um objetivo geral e só está realmente ciente da sintaxe do java.
cinzas
3

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:

amostra de xml mostrando a margem esquerda em movimento e o espaço em branco realçado

Justin Ohms
fonte
Com a visão recuada, o plano é iluminar os espaços em branco dinamicamente, semelhante à sua ideia. Além disso, lembre-se de que, em uma visualização plana, 30 níveis de aninhamento ocupam o mesmo espaço que 1 nível, recuado, ele fica fora da borda da tela. Esse é um dos motivos pelos quais os desenvolvedores podem escolher as visualizações.
Pgfearo 01/07
1
Sim, foi por isso que eu disse que não era uma ideia nova. No entanto, se o nível de recuo for logarítmico ou dinâmico, com base no nível que estou editando no momento, você não terá o problema que está falando. Mesmo se fosse simplesmente fixado em 1 espaço, não ficaria fora da tela. Você não estaria nem na metade de uma tela antiga de 80 caracteres. Sim, com algumas dessas idéias, 30 níveis ocupam o mesmo espaço que 1 nível, mas quando você olha algumas delas, elas não economizam espaço apenas no recuo, elas apenas recuam a coisa toda e adicionam alguns gráficos sofisticados.
Justin Ohms
Ohms. Agora há uma seção sobre imóveis na tela na pergunta (este é um wiki da comunidade e tudo), isso inclui uma comparação de captura de tela. Se você pudesse atualizar esta seção com suas próprias observações, isso seria ótimo. Por favor, aceite que eu sou um mega fã de visualizações recuadas (trabalhando no mundo XML e tudo mais), é por isso que passei os últimos 6 meses ou mais aperfeiçoando a técnica de formatação virtual onde a indentação é gerenciada pelo sistema. Se há uma coisa que eu aprendi, é que os desenvolvedores gostam de uma escolha - daí a visão plana.
Pgfearo
Na primeira leitura, perdi suas idéias sobre larguras de recuo dinâmico - esse poderia ser um recurso poderoso. Isso aumenta a possibilidade de até mesmo ter algum código recuado enquanto o restante é plano, sem saber como isso funcionaria na prática, mas é facilmente testado - com o meu projeto, a lógica do recuo ainda é invocada até para a visualização plana, é apenas que o multiplicador está definido como 0. Portanto, é apenas esse multiplicador que precisa ser ajustado. Boa decisão.
Pgfearo
2

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.
Ando
fonte
Algumas idéias úteis - tentarão incorporá-las, especialmente o bit XML-ish. Além disso, há muita coisa dinamicamente, e eu provavelmente poderia acrescentar mais - sem que isso seja arrogante.
Pgfearo
2

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.

Herbert Sitz
fonte
O editor que estou projetando deve ser integrado a um sistema muito maior com uma GUI em que o Vim, ou qualquer ferramenta de terceiros não está sendo considerada, por motivos técnicos e de licenciamento. No entanto, estou interessado em saber como o Vim lida com isso para investigar - espero que eles tenham capturas de tela na documentação. Sim, os gráficos baseados em caracteres podem funcionar até certo ponto - eu zombei de um para pesquisa. A dobragem de código pode ser feita a partir da margem esquerda, mas também é fornecida uma exibição em árvore de estrutura de tópicos sincronizada.
Pgfearo
@pgfearo: Você pode olhar para o protocolo NetBeans do Vim. Ele deve ser usado para incorporar o Vim dentro de um IDE, sem problemas de licenciamento.
greyfade
@greyfade - Receio que haja problemas de licenciamento, pelo menos no meu projeto atual, porque é de código fechado e eu precisaria da facilidade (mesmo que não o tenha usado) para modificar a fonte do Vim sem preocupações com a GPL. Além disso, o protocolo parece interessante.
Pgfearo
1

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.

Inca
fonte
Agora enviei uma resposta que acho cruzada com a sua, mas coincidentemente vincula sua ideia de destacar o escopo atual (com uma borda brilhante) ?. Eu concordo que os blocos devam ser menos invasivos, os efeitos são exagerados aqui para ajudar no meu desenho e também para que fiquem ok em uma captura de tela reduzida.
Pgfearo
1

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.

Phil Miller
fonte
Isso destaca, eu acho, que ainda há muito a ser feito para adicionar detalhes à implementação desse padrão. Sim, estou mais confortável em usar tons para evitar problemas de reconhecimento de cores, mas, desde que haja opções disponíveis, concordo que ajudará a adicionar uma dimensão extra. Como essa pergunta agora é um wiki da comunidade, tentarei enviar um wireframe para ver se outras pessoas desejam contribuir com imagens que são variações do tema - as preferências provavelmente variarão entre diferentes classes de uso, sintaxe da linguagem e contexto dinâmico.
Pgfearo
0

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.

Peter Taylor
fonte
Eu estava apenas me concentrando nesse controle, mas uma 'Barra de Localização XPath' com o navegador 'breadcrumb' funciona e é incorporada ao editor, assim como uma visualização em árvore de elementos sincronizados.
Pgfearo
0

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.

mattimus
fonte
O suporte a altos níveis de aninhamento é uma prioridade. Mas há muito o que os olhos precisam ver (e podem absorver) a qualquer momento, então, além de um certo nível, estou pensando em misturar cores, para dar uma impressão de profundidade e apenas os principais níveis destacados. Então, vou verificar sua ideia para quando os níveis de aninhamento forem altos.
Pgfearo