Não.

A promoção de marketing é mais um "o que está por vir" do que um "o que está disponível agora". Agradecemos sua paciência enquanto continuamos a trabalhar neste projeto :)

Também para vinculação, # 555

@tackyunicorn - o vídeo do

Atualmente, o host de extensibilidade e extensões como "Visualização do link" ainda não foram projetados ou implementados e provavelmente serão enviados após a v1.0. Queremos despender tempo e esforço para garantir que construímos esses recursos cruciais "da maneira certa" para minimizar interrupções no futuro.

Estamos trabalhando em nosso roteiro futuro e compartilharemos com a comunidade nas próximas semanas.

Resumo do novo recurso / aprimoramento

Detecte URLs e torne-os clicáveis ​​(abra o URL no navegador padrão). Este é um recurso prático presente em muitos outros terminais.

Eu acredito que o valor é autoevidente, mas aqui está um exemplo de caso de uso concreto independentemente: quando executo yarn outdated (Yarn é um gerenciador de pacotes), ele gera uma URL de repositório / página inicial para cada pacote listado. Desejo poder clicar em um desses URLs para abrir a página de forma rápida / fácil e dar uma olhada no que mudou na nova versão do pacote.

Detalhes de implementação

• Provavelmente não precisa suportar nada mais do que texto começando com http:// ou https:// .
• URLs que abrangem várias linhas (devido a serem truncados pela largura da janela) devem ser tratados corretamente.
• Provavelmente deve haver uma indicação de que o URL é clicável, por exemplo, mudança do cursor + sublinhado ao passar o mouse.
• A maioria dos outros terminais exige um clique alt ou ctrl, presumo que seja uma proteção contra cliques acidentais ao copiar e assim por diante.

Você pode olhar para algo como o terminal do VS Code para se inspirar. Novamente, tudo isso é provavelmente evidente.

Meta de alongamento (abordada em # 204)

O IMO deve oferecer suporte a todos os esquemas para fins de conclusão, evitando problemas adicionais que solicitem a adição de novos e a reutilização do código / biblioteca.

Uma coisa que pode ficar complexa para acertar é o manuseio de parênteses: a maioria das implementações que conheci pula incorretamente o caractere de parêntese de fechamento ( ) ) se for o último caractere no link quebrando vários links da Wikipedia. Provavelmente deve ser usado algum algoritmo de correspondência de parênteses para decidir se este último caractere faz parte do link ou não.

EDIT: erro de digitação

a maioria das implementações que encontrei incorretamente pula o caractere de parêntese de fechamento ( ) ) se for o último caractere no link quebrando vários links da Wikipedia

Por outro lado, os URLs são frequentemente colocados entre parênteses no fluxo de texto (consulte, por exemplo, http://example.com/foobar) <- como aqui, e também nos arquivos Markdown.

No gnome-terminal abordamos esses dois requisitos contraditórios, permitindo os parênteses () e colchetes [] , desde que ocorram em pares equilibrados. Isso foi implementado usando expressão regular recursiva. Consulte GT 763980 .

Outro caso complicado semelhante é o apóstrofo à direita, consulte gt 448044 .

não podemos descobrir isso sem consultar o servidor

Haha, essa também é uma possibilidade - eu pessoalmente não aceitaria, no entanto. Tenho certeza de que você compartilha minhas preocupações sobre vazamento de dados, bem como lentidão.

É tudo adivinhação, não há solução perfeita (bem, há # 204 para resolver essa lacuna). Descobrimos que os parênteses correspondentes funcionam bem o suficiente, não recebemos um relatório desde que os implementamos. Pelo menos, definitivamente acabou sendo melhor do que sempre combinar o parênteses ou nunca combinar. Foi um pouco complicado de implementar, cavar em recursos regex raramente usados ​​e pouco conhecidos de certas bibliotecas de regex (então não estou surpreso que muitos terminais não se importem com isso), mas acho que valeu a pena. :)

Acho que precisamos detectar o caminho das pastas e torná-las clicáveis ​​também.
Mais fácil de depurar o código:

O controle TeachingTip pode ser usado para o recurso Link Preview

Você pode olhar para algo como o terminal do VS Code para se inspirar. Novamente, tudo isso é provavelmente evidente.

Por que não apenas compartilhar o mesmo código?

Provavelmente, não precisa oferecer suporte a nada mais do que texto começando com http: // ou https: //.

Acho que você deve adicionar detecção de www. .

Por que não apenas compartilhar o mesmo código?

Bem, é escrito em TypeScript, um dialeto de javascript ... então não funcionará exatamente em nosso projeto C ++.

Mal posso esperar por esse recurso !! Eu adoro poder segurar o CTRL e ver um link sublinhado no ConEmu onde clicar com o botão esquerdo para abri-lo no navegador padrão. Esperamos que uma implementação simples de regex de destaque de URL chegue antes do final do ano :)

O controle TeachingTip pode ser usado para o recurso Link Preview

Você pode imaginar esse controle aparecendo sobre o link, com o Favicon, Nome do site e URL ou descrição do Bing para o link

@mdtauk & @awarmfastbear - Você quer dizer o pop-up de visualização do

O recurso foi sugerido naquele carretel chiado quando você aponta @bitcrazed - Meu comentário é mais sobre como usar um controle XAML padrão para implementá-lo, e não fazer isso de uma maneira que seja inconsistente com a IU do Windows. Pense nisso como um ataque preventivo 😉

@bitcrazed, essa é literalmente a primeira frase deste problema, aliás;)

@mdtauk Concordo. Definitivamente, não queremos reinventar desnecessariamente a roda. Se pudermos usar controles XAML padrão para implementar recursos como este, o faremos.

Do contrário, trabalharemos com as equipes de controles XAML para descobrir se as alterações nos controles existentes precisam ser feitas ou se um novo controle com o comportamento correto é necessário.

Para ser honesto, porém, o maior desafio aqui provavelmente não será qual controle usar, mas como construir um mecanismo de extensibilidade que forneça todos os recursos necessários, enquanto permanece suficientemente rápido, estável e seguro.

Seria maravilhoso se você pudesse oferecer suporte a https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

Em uma das sessões do Ignite 2019, foi indicado que isso seria compatível com um recurso de extensão. Portanto, precisamos esperar que o suporte à extensão seja concluído.

@bitcrazed No momento, o Windows Terminal é incrivelmente rápido no benchmark "modo Arco-íris" em https://github.com/pew/ternimal. Definitivamente, compartilho a mesma preocupação de que "links clicáveis" vão introduzir muita latência de análise toda vez que os caracteres são gravados na tela e tornar o Terminal do Windows muito lento, já que um analisador adequado teria que verificar novamente todos os caracteres conectados ao caractere que foi gravado na tela, para ver se algum deles forma links válidos.

Eu tenho uma ideia: e se os links não forem analisados ​​e NÃO puderem ser clicados ATÉ que o usuário mantenha pressionada a tecla Control (ou talvez Alt) E passe o mouse sobre o Terminal do Windows. Nesse cenário, o código examinaria a linha (com suporte para linhas quebradas nas linhas anteriores / posteriores) e procuraria por um URL ou CAMINHO DE ARQUIVO exatamente no cursor do mouse. SE sim, então realce o URL, mostre a visualização, torne-o clicável (desde que Ctrl ainda esteja pressionado), etc.

Além disso, se o usuário clicar com o botão direito, faça uma análise da sequência de caracteres ininterrupta naquele ponto (então pare nos espaços em branco antes / depois da sequência clicada), destacando assim a palavra inteira. Em seguida, faça a análise do link. Se um link for detectado, mostre um item de menu "Abrir Link".

Em ambos os cenários, ctrl-and-hover e click com o botão direito, o analisador é idêntico:

• Obtenha a "linha + coluna" suspensa do cursor do mouse.
• Se essa coluna for um espaço em branco, não faça nada, pois não há nada para verificar.
• Se essa coluna NÃO FOR espaço em branco, colete todos os caracteres "conectados" antes e depois dela, examinando até encontrar espaços em branco (novas linhas, espaços, etc; espaços em branco verticais e horizontais). O resultado será uma palavra, um link ou qualquer outra coisa.
• Faça uma análise simples do link para detectar se é um URL. Também faça a análise do sistema de arquivos, se algo parecer um caminho de arquivo local (por exemplo C:\Tools\foo.cpp:80 seria analisado da esquerda para a direita e detectaria que C:\Tools\foo.cpp é um arquivo).
• Se um URL / caminho de arquivo for detectado, manipule o link.

Essas duas soluções seriam A resposta de melhor desempenho, e segurar Ctrl (ou talvez Alt) não é grande coisa. Muitos terminais lidam com isso dessa forma, como o terminal macOS. No terminal do macOS, você segura Command + clique duplo para abrir os links ou, alternativamente, clica com o botão direito para obter um menu que "analisa" a palavra / link destacado (se você clicar com o botão direito em um link, esse fato é detectado e destaca o link inteiro) e, em seguida, escolha "Abrir link".

Todas as alternativas seriam um desperdício e muito mais lentas.

PS: Caso seja útil, o terminal Alacritty define esses caracteres como "separadores de links de sequência de caracteres": ",│`|:\"' ()[]{}<>\t" , o que pode ser útil para definir como dividir strings para detectar caminhos, URLs, etc, no / sequência de caracteres pairada. Se eu estivesse escrevendo um analisador, usaria a técnica "obter a sequência completa de caracteres sem espaço em branco" que descrevi acima, seguida por uma passagem pela "faixa ao redor do lixo, como <> ou () depois disso, para detectar o link final.

Olá @VideoPlayerCode - obrigado por enviar suas opiniões aqui.

Eu concordo, apenas a análise de URLs quando o usuário pressiona uma tecla / acorde permitiria é adiar a varredura regex, mas ainda significaria que não poderíamos colorir os URLs incorporados no texto - algo que muitos usuários já pediram.

Além disso, os URLs são apenas um de uma classe de padrões de texto que queremos procurar e identificar: Por exemplo, adoraria poder dizer ao Terminal para desenhar uma caixa vermelha com um preenchimento amarelo sob o texto que corresponde um padrão de texto / regex / etc especificado. - imagine ser capaz de destacar mensagens de erro desta forma em um log do servidor da web enquanto ele passa. 😁

Tenho certeza de que seremos capazes de encontrar uma estratégia para identificar padrões / correspondências de regex de uma maneira com bom desempenho. Eventualmente. Um dia 😜

@bitcrazed

Eu concordo, apenas a análise de URLs quando o usuário pressiona uma tecla / acorde permitiria é adiar a varredura regex, mas ainda significaria que não poderíamos colorir os URLs incorporados no texto - algo que muitos usuários já pediram.

Ahh, acabei de perceber que o recurso "scanner sempre ativo" foi apresentado no vídeo de marketing e é esperado pelos usuários. Opa.

Além disso, os URLs são apenas um de uma classe de padrões de texto que queremos procurar e identificar: Por exemplo, adoraria poder dizer ao Terminal para desenhar uma caixa vermelha com um preenchimento amarelo sob o texto que corresponde um padrão de texto / regex / etc especificado. - imagine ser capaz de destacar mensagens de erro desta forma em um log do servidor da web enquanto ele passa. 😁

Uau, adoro essa ideia! Ser capaz de definir uma regex na configuração do usuário e selecionar como destacar correspondências seria fantástico.

Tenho certeza de que seremos capazes de encontrar uma estratégia para identificar padrões / correspondências de regex de uma maneira com bom desempenho. Eventualmente. Um dia 😜

Bem, se houver necessidade de digitalização contínua ... aqui estão algumas idéias:

• Ao fazer as varreduras, faça apenas o buffer de tela visível no momento. Se o buffer de tela começar com um caractere diferente de espaço em branco, inclua também o texto que estava fora da tela até o espaço em branco anterior (como se a linha superior fosse hub.com/foo mas na verdade é uma continuação encapsulada de https://git<wrap>hub.com/foo ).
• A execução da regex nesse buffer precisaria ser limitada de uma das quatro maneiras (ou combinações de todas):
• R: Faça uma varredura apenas quando nada tiver sido gravado na tela (nenhum texto novo / caracteres alterados) por um período razoável de tempo, como 300 ms. Isso significa que quando os registros de rolagem rápida ou "gato" estão ativos, eles serão executados sem inibições.
• Ou B: execute-o em um intervalo pulsante como 300ms, onde você bloqueia a execução, faz uma varredura rápida, marca os destaques onde necessário e continua a execução (consumindo os dados stdout de entrada).
• Ou C: faça a varredura em tempo real quando a rolagem for lenta, mas pare completamente a varredura em tempo real quando a taxa de saída for muito alta. Por exemplo, "cat 10mbfile.txt" desabilitaria a varredura em tempo real, pois o terminal notaria uma taxa de saída insana. E assim que a saída insana parar, faça uma passagem única pelo buffer de saída antigo que acabou de ser transmitido. Eu gosto mais dessa ideia. E combine-o com a técnica de apenas escanear o buffer de tela visível.
• Ou D: faça a varredura de todos os dados ao vivo à medida que eles entram (vai ser péssimo para o desempenho) e armazene os resultados em cache. Sempre que linhas são adicionadas ou caracteres são substituídos no buffer, faça a varredura / varredura novamente apenas essas linhas.
• Considere também links de suporte, pelo menos para verificação em tempo real. Porque regexps personalizadas podem ser literalmente insanas o suficiente para corresponder a todo o buffer. Imagine como você começaria a combinar uma regexp que corresponde desde as palavras "Resultado do log:" até uma linha que diz "Fim do log", em seu exemplo de "regexp personalizado". Isso pode ser milhares de linhas de dados que devem corresponder. Caramba, aquele regexp nem saberia como combinar nada até que ele visse o "Fim do Log" travando no final da partida. Muito louco...
• Se você só oferece suporte a links, pode otimizar como um louco escaneando apenas "http:" e "https:" (não diferencia maiúsculas de minúsculas) com um comparador de padrões otimizado muito simples e, em seguida, fazendo uma varredura de "mecanismo regexp completo" _apenas_ na sequência de caracteres delimitada por espaços em branco em torno dessa correspondência.
• Também tenha cuidado com as pessoas fazendo "cat" em arquivos que têm personagens rodando indefinidamente, já que isso vai prejudicar o desempenho.
• Para os métodos A, B e C: quando o usuário rola para trás no buffer para ver o texto antigo, ele será exigente e não esperará que os links "apareçam" durante um intervalo de pulso acelerado. Portanto, faça uma varredura mais rápida ao rolar manualmente com as barras de rolagem. Mas, ai, eu mal posso imaginar o quão difícil seria o código para escanear texto fluente / auto-modificador em tempo real de uma forma eficiente.

Resumindo: Nossa, boa sorte em atender às expectativas do usuário em relação a um recurso bastante insano (com um desempenho ruim). Este problema é como tentar escrever um regexp rápido para escanear uma página HTML que constantemente baixa mais e mais dados e se auto-modifica dados antigos ... 😛 Espero que pelo menos parte disso possa inspirar algumas linhas de pensamento para uma solução eventual!

Obrigado por compartilhar suas idéias :) Que bom que você gostou deste recurso tanto quanto eu;)

Qualquer que seja o mecanismo de varredura que usamos, tenho certeza que vai acabar sendo:

1) Assíncrono
2) Eficiente
3) Configurável

Você acertou em cheio na cabeça. seus comentários sobre o perf - esta é a principal preocupação de um recurso como este e precisamos prestar atenção. Simplesmente não era possível projetar uma solução geral sobre o antigo mecanismo do Console, mas estamos nos aproximando do ponto em que o mecanismo recém-redesenhado subjacente ao Terminal em particular deve nos dar o acesso e os recursos de que precisamos.

Agora, se tivéssemos mais desenvolvedores e / ou membros da comunidade suficientemente motivados com as habilidades e tempo para ajudar 😜

No segundo em que você tiver pontos de extensão, tenho certeza de que há muitos de nós com as habilidades. E vamos tentar arduamente para arranjar tempo :) Contar comigo mesmo, pelo menos.

Ansioso por esse dia :)

Quando isso acontecer, seria ótimo poder substituir o aplicativo padrão por perfil. O sonho final seria poder usar acordes diferentes para lançar uma URL em navegadores diferentes.

Imagino que você já saiba, mas há alguns riscos de segurança que causaram problemas semelhantes no passado, principalmente o iTerm tinha problemas para fazer pesquisas de DNS ao passar o mouse sobre os links para destacá-los antes de clicar. Esse era um problema bastante importante para analistas de segurança que investigavam ataques ao vivo, mas também causava problemas, pois estava enviando pesquisas de DNS para coisas que se assemelhavam a urls (incluindo informações confidenciais - por exemplo, senhas) em texto simples.

Não vou tão longe a ponto de dizer que esse comportamento é certo ou errado, mas definitivamente algo a se ter em mente ao implementá-lo. Para referência:
https://gitlab.com/gnachman/iterm2/issues/6050
https://gitlab.com/gnachman/iterm2/issues/3688
https://gitlab.com/gnachman/iterm2/issues/5303
https://gitlab.com/gnachman/iterm2/-/wikis/dnslookupissue
https://nvd.nist.gov/vuln/detail/CVE-2015-9231

Estou escrevendo para solicitar respeitosamente que comece pequeno, de olho na solicitação de um recurso maior. Obter links http (s): // para abrir no navegador padrão, ao clicar com CTRL + clicar neles, seria um ótimo começo! Tantas ferramentas de linha de comando geram links da web que agora devem ser copiados e colados em um navegador. Se tivéssemos essa funcionalidade, já bastaria por um bom tempo, na minha opinião. Obrigado pela sua consideração!

Gosto do terminal do Windows, mas odeio mudar para um terminal diferente toda vez que quero clicar em links. Isso é tudo.

Saltando no movimento aqui para pedir esse recurso. Vindo do macOS, eu realmente sinto falta de uma maneira rápida de clicar em URLs sem ter que passar pelo complicado ritual de copiar / colar.

Links clicáveis ​​estão no roteiro para V2.0: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

Em nome de alguns dos assinantes que estão assistindo a mudanças / atualizações notáveis; podemos bloquear / silenciar esse problema por enquanto?

As perguntas adicionais, + 1s, não agregam valor e trazem mais poluição para nossas caixas de entrada. Se alguém quiser contribuir para isso, pode fazer uma CR e fazer referência a esse problema. :)