아니요.

마케팅 프로모션은 "지금 사용할 수 있는 것"보다 "앞으로 나올 것"에 가깝습니다. 이 프로젝트를 계속 진행하는 동안 양해해 주셔서 감사합니다. :)

또한 연결을 위해 #555

@tackyunicorn - 터미널 비디오 는 열망입니다. 이

현재 확장성 호스트 및 "링크 미리보기"와 같은 확장 기능은 아직 설계 또는 구현되지 않았으며 v1.0 이후에 출시될 예정입니다. 우리는 나중에 중단을 최소화하기 위해 이러한 중요한 기능을 "올바른" 빌드하도록 시간과 노력을 투자하고 싶습니다.

우리는 미래 로드맵을 작업 중이며 앞으로 몇 주 안에 커뮤니티와 공유할 것입니다.

새로운 기능/개선 사항 요약

URL을 감지하고 클릭 가능하게 만듭니다(기본 브라우저에서 URL 열기). 이것은 다른 많은 터미널에 있는 편리한 기능입니다.

나는 값이 자명하다고 생각하지만 여기에 관계없이 구체적인 사용 사례가 있습니다. yarn outdated (Yarn은 패키지 관리자)를 실행하면 나열된 모든 패키지에 대한 저장소/홈페이지 URL이 출력됩니다. 해당 URL 중 하나를 클릭하여 페이지를 빠르고 쉽게 열고 새 버전의 패키지에서 변경된 사항을 확인하고 싶습니다.

구현 세부 정보

• 아마도 http:// 또는 https:// 시작하는 텍스트 이상을 지원할 필요가 없습니다.
• 여러 줄에 걸쳐 있는 URL(창 너비에 의해 잘림으로 인해)은 올바르게 처리되어야 합니다.
• URL이 클릭 가능하다는 표시가 있어야 합니다(예: 커서 변경 + 마우스 호버 시 밑줄).
• 대부분의 다른 터미널은 alt 또는 ctrl 클릭이 필요합니다. 복사할 때 우발적인 클릭을 방지하기 위한 것 같습니다.

영감을 얻으려면 VS Code의 터미널과 같은 것을 볼 수 있습니다. 다시 말하지만 이것은 모두 자명한 것입니다.

스트레치 골 (#204에서 다룸)

IMO는 완료를 위해 모든 스키마를 지원해야 하며, 코드/라이브러리의 재사용 및 새 스키마 추가를 요구하는 추가 문제를 피해야 합니다.

올바르게 하기가 복잡해질 수 있는 한 가지는 괄호 처리입니다. 내가 만난 대부분의 구현은 닫는 괄호 문자( ) )가 여러 Wikipedia 링크를 끊는 링크의 마지막 문자인 경우 닫는 괄호 문자를 잘못 건너뜁니다. 아마도 이 마지막 문자가 링크의 일부인지 여부를 결정하기 위해 알고리즘과 일치하는 일부 괄호를 사용해야 합니다.

편집: 오타

내가 만난 대부분의 구현은 여러 Wikipedia 링크를 끊는 링크의 마지막 문자인 경우 닫는 괄호 문자( ) )를 잘못 건너뜁니다.

반면에 URL은 텍스트 흐름(예: http://example.com/foobar 참조) <- 여기에서처럼 괄호로 묶인 경우가 많으며 Markdown 파일에서도 마찬가지입니다.

gnome-terminal에서 우리는 괄호 () 와 대괄호 [] 가 균형 잡힌 쌍으로 발생하는 한 허용하여 이 두 가지 모순되는 요구 사항을 해결했습니다. 이것은 재귀 정규 표현식을 사용하여 구현되었습니다. gt 763980을 참조하십시오.

또 다른 유사한 까다로운 경우는 후행 아포스트로피입니다( gt 448044 참조).

서버를 폴링하지 않고는 이것을 알 수 없습니다

하하, 이것도 가능성이 있습니다. 하지만 개인적으로 그렇게 하지는 않을 것입니다. 데이터 유출 및 속도 저하에 대한 내 우려를 공유할 것이라고 확신합니다.

그것은 모두 추측이며 완벽한 솔루션은 없습니다(이 격차를 해결하기 위한 #204가 있습니다). 우리는 일치하는 괄호가 충분히 잘 작동한다는 것을 발견했지만 그것을 구현한 이후로 보고서를 받지 못했습니다. 적어도 항상 부모와 일치하거나 일치하지 않는 것보다 확실히 더 나은 것으로 판명되었습니다. 특정 정규식 라이브러리의 거의 사용되지 않고 거의 알려지지 않은 정규식 기능을 파헤쳐 구현하는 것은 약간 까다로웠지만(많은 터미널에서 신경 쓰지 않는다는 사실에 놀라지 않았습니다), 그만한 가치가 있었다고 생각합니다. :)

폴더 경로를 감지하고 클릭 가능하게 만들어야 한다고 생각합니다.
더 쉬운 코드 디버그:

링크 미리보기 기능에 TeachingTip 컨트롤을 사용할 수 있습니다.

영감을 얻으려면 VS Code의 터미널과 같은 것을 볼 수 있습니다. 다시 말하지만 이것은 모두 자명한 것입니다.

왜 같은 코드를 공유하지 않습니까?

아마도 http:// 또는 https://로 시작하는 텍스트 이상을 지원할 필요가 없을 것

www. 감지 기능을 추가해야 한다고 생각합니다.

왜 같은 코드를 공유하지 않습니까?

글쎄, 그것은 자바 스크립트의 방언인 TypeScript로 작성되었으므로 ... 우리 C++ 프로젝트에서 정확히 작동하지 않을 것입니다.

이 기능이 기대됩니다!! Ctrl 키를 누른 상태에서 ConEmu에서 밑줄이 그어진 링크를 보고 왼쪽 클릭하면 기본 브라우저에서 열립니다. URL 강조 표시의 간단한 정규식 구현이 올해 말 이전에 구현되기를 바랍니다. :)

링크 미리보기 기능에 TeachingTip 컨트롤을 사용할 수 있습니다.

링크에 대한 Favicon, 사이트 이름 및 URL 또는 Bing 설명과 함께 이 컨트롤이 링크 위에 표시되는 것을 상상할 수 있습니다.

@mdtauk & @awarmfastbear - 터미널의 지글지글 영상에서 설명한 링크 미리보기 팝업 같은 말인가요?

이 기능은 @bitcrazed 를 지적하면서 그

@bitcrazed 는 말 그대로 이 문제의 첫 번째 문장입니다. btw ;)

@mdtauk 동의합니다. 우리는 불필요하게 바퀴를 재발명하고 싶지 않습니다. 표준 XAML 컨트롤을 사용하여 이와 같은 기능을 구현할 수 있다면 그렇게 할 것입니다.

그렇지 않은 경우 XAML 컨트롤 팀과 협력하여 기존 컨트롤을 변경해야 하는지 또는 올바른 동작을 가진 새 컨트롤이 필요한지 파악합니다.

솔직히 말해서, 여기서 가장 큰 도전은 어떤 컨트롤을 사용할 것 같지는 않습니다. 필요한 모든 기능을 제공하면서 충분히 빠르고 안정적이며 안전한 확장성 메커니즘을 구축하는 방법이 될 것입니다.

https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda를 지원할 수 있다면 좋을 것입니다.

Ignite 2019 세션 중 하나에서 이것이 확장 기능을 통해 지원될 것이라고 밝혔습니다. 따라서 확장 지원이 완료될 때까지 기다려야 합니다.

@bitcrazed 현재 Windows 터미널은 https://github.com/pew/ternimal 의 "무지개 모드" 벤치마크에서 엄청나게 빠릅니다 . 적절한 파서가 연결된 모든 문자를 다시 스캔해야 하므로 "클릭 가능한 링크"가 문자를 화면에 쓸 때마다 많은 구문 분석 대기 시간이 발생하고 Windows 터미널 속도가 심각하게 느려질 것이라는 동일한 우려를 공유합니다. 유효한 링크를 형성하는 것이 있는지 확인하기 위해 화면에 작성된 문자로 이동합니다.

아이디어가 있습니다. 링크가 전혀 구문 분석되지 않고 사용자가 Control(또는 Alt) 키를 누르고 Windows 터미널 위로 마우스를 가져갈 때까지 클릭할 수 없으면 어떻게 될까요? 이 시나리오에서 코드는 라인을 스캔하고(앞/뒤 라인에서 래핑된 라인 지원), 마우스 커서에서 정확히 URL 또는 FILE PATH를 찾습니다. 그렇다면 URL을 강조 표시하고, 미리보기를 표시하고, 클릭 가능하게 만드십시오(Ctrl 키를 계속 누르고 있는 동안).

또한 사용자가 마우스 오른쪽 버튼을 클릭하면 해당 지점에서 끊어지지 않은 문자 시퀀스를 구문 분석하여(클릭한 시퀀스 앞/뒤 공백에서 중지) 전체 단어를 강조 표시합니다. 그런 다음 링크 구문 분석을 수행합니다. 링크가 감지되면 "링크 열기" 메뉴 항목을 표시합니다.

Ctrl-and-hover 및 마우스 오른쪽 버튼 클릭 시나리오에서 파서는 동일합니다.

• 마우스 커서의 "행 + 열"을 가져옵니다.
• 해당 열이 공백이면 스캔할 것이 없으므로 아무 작업도 하지 마십시오.
• 해당 열이 공백이 아닌 경우 공백(줄 바꿈, 공백 등, 세로 및 가로 공백 모두)이 나타날 때까지 스캔하여 그 앞뒤의 모든 "연결된" 문자를 수집합니다. 결과는 단어, 링크 또는 다른 무엇이든 됩니다.
• URL인지 여부를 감지하기 위해 간단한 링크 구문 분석을 수행합니다. 또한 로컬 파일 경로처럼 보이는 경우 파일 시스템 구문 분석을 수행합니다(예 C:\Tools\foo.cpp:80 는 왼쪽에서 오른쪽으로 구문 분석되고 C:\Tools\foo.cpp 가 파일임을 감지함).
• URL/파일 경로가 감지되면 링크를 처리합니다.

이 두 가지 솔루션은 가장 고성능의 답변이 될 것이며 Ctrl(또는 Alt)을 누르고 있는 것은 큰 문제가 되지 않습니다. macOS 터미널과 같은 많은 터미널이 그런 식으로 처리합니다. macOS 터미널에서 Command + 두 번 클릭하여 링크를 열거나 마우스 오른쪽 버튼을 클릭하여 강조 표시된 단어/링크를 "분석"하는 메뉴를 가져옵니다(링크를 마우스 오른쪽 버튼으로 클릭하면 해당 사실이 감지되고 강조 표시됩니다. 전체 링크)를 선택한 다음 "링크 열기"를 선택합니다.

모든 대안은 낭비적이고 훨씬 느릴 것입니다.

추신: 도움이 되는 경우 Alacritty 터미널은 이러한 문자를 "문자열 링크 구분 기호": ",│`|:\"' ()[]{}<>\t" 로 정의합니다. 이는 클릭된 경로, URL 등을 감지하기 위해 문자열을 분할하는 방법을 정의하는 데 유용할 수 있습니다 /hovered 문자 시퀀스. 파서를 작성 중이라면 위에서 설명한 "공백이 아닌 완전한 문자 시퀀스 가져오기" 기술을 사용한 다음 " <> 또는 () 와 같은 쓰레기 주변 스트립"을 통과합니다.

안녕하세요 @VideoPlayerCode - 여기에 의견을 제출해 주셔서 감사합니다.

동의합니다. 사용자가 키/코드를 눌렀을 때의 URL 구문 분석은 정규식 스캔을 연기하는 것이지만 여전히 많은 사용자가 이미 요청한 텍스트에 포함된 강조 표시 URL에 색상을 지정할 수 없음을 의미합니다.

또한 URL은 우리가 찾고 식별하고자 하는 텍스트 패턴 클래스 중 하나일 뿐입니다. 예를 들어, 터미널에 지정된 텍스트 패턴/regex/etc. - 웹 서버 로그가 스트리밍될 때 이러한 방식으로 오류 메시지를 강조 표시할 수 있다고 상상해 보십시오. 😁

나는 우리가 패턴/정규식 일치를 꽤 성능이 좋은 방식으로 식별할 수 있는 전략을 찾을 수 있을 것이라고 확신합니다. 결국. 어느날 😜

@bitcrazed

동의합니다. 사용자가 키/코드를 눌렀을 때의 URL 구문 분석은 정규식 스캔을 연기하는 것이지만 여전히 많은 사용자가 이미 요청한 텍스트에 포함된 강조 표시 URL에 색상을 지정할 수 없음을 의미합니다.

아, '항상 활성 스캐너' 기능이 마케팅 비디오에서 제시되었고 사용자들이 기대하는 기능이라는 것을 방금 깨달았습니다. 죄송합니다.

또한 URL은 우리가 찾고 식별하고자 하는 텍스트 패턴 클래스 중 하나일 뿐입니다. 예를 들어, 터미널에 지정된 텍스트 패턴/regex/etc. - 웹 서버 로그가 스트리밍될 때 이러한 방식으로 오류 메시지를 강조 표시할 수 있다고 상상해 보십시오. 😁

와, 그 아이디어가 좋아요! 사용자 구성에서 정규식을 설정하고 일치 항목을 강조 표시하는 방법을 선택하는 것은 환상적일 것입니다.

나는 우리가 패턴/정규식 일치를 꽤 성능이 좋은 방식으로 식별할 수 있는 전략을 찾을 수 있을 것이라고 확신합니다. 결국. 어느날 😜

지속적인 스캔이 필요한 경우... 여기에 몇 가지 아이디어가 있습니다.

• 스캔을 수행할 때 현재 보이는 화면 버퍼만 수행합니다. 화면 버퍼가 공백이 아닌 문자로 시작하는 경우 이전 공백까지 화면 밖에 있던 텍스트도 포함합니다(예: 맨 위 행이 hub.com/foo 이지만 실제로는 https://git<wrap>hub.com/foo 의 래핑된 연속인 경우).
• 해당 버퍼에서 정규식을 실행하려면 다음 네 가지 방법 중 하나로 제한해야 합니다(또는 모두 조합).
• A: 정상적인 시간(예: 300ms) 동안 화면에 아무 것도 기록되지 않은 경우(새 텍스트/변경된 문자 없음)에만 스캔을 수행하십시오. 즉, 빠르게 스크롤되는 로그 또는 "cat"이 활성화되면 제한 없이 실행됩니다.
• 또는 B: 300ms와 같은 펄스 간격으로 실행합니다. 실행을 차단하고 빠른 스캔을 수행하고 필요한 곳에 하이라이트를 표시한 다음 계속 실행(수신 표준 출력 데이터 사용)합니다.
• 또는 C: 스크롤이 느릴 때 실시간으로 스캔하지만 출력 속도가 매우 높을 때 실시간 스캔을 완전히 중지합니다. 예를 들어 "cat 10mbfile.txt"는 터미널이 미친 출력 속도를 감지하므로 실시간 검색을 비활성화합니다. 그리고 미친 출력이 멈추는 즉시 방금 스트리밍된 이전 출력 버퍼를 한 번만 통과합니다. 이 아이디어가 가장 마음에 듭니다. 그리고 보이는 화면 버퍼만 스캔하는 기술과 결합합니다.
• 또는 D: 들어오는 모든 데이터를 실시간으로 스캔하고(성능 저하) 결과를 캐시합니다. 버퍼에서 라인이 추가되거나 문자가 교체될 때마다 해당 라인만 스캔/재스캔하십시오.
• 또한 최소한 실시간 검색의 경우 지원 링크만 고려하십시오. 사용자 정의 정규 표현식은 문자 그대로 전체 버퍼와 일치할 만큼 충분히 미쳤을 수 있기 때문입니다. "사용자 정의 정규식" 예제에서 "로그 결과:"라는 단어에서 "로그 끝"이라는 줄까지 일치하는 정규식과 일치하도록 시작하는 방법을 상상해 보십시오. 일치해야 하는 수천 줄의 데이터가 될 수 있습니다. 젠장, 그 정규 표현식은 경기가 끝날 때 "로그 끝" 클램핑을 볼 때까지 아무것도 일치시키는 방법조차 알지 못합니다. 아주 미친...
• 링크만 지원하는 경우 매우 간단하고 최적화된 패턴 일치 프로그램으로 "http:" 및 "https:"(대소문자 구분 안 함)만 검색한 다음 "전체 정규 표현식 엔진" 검색을 수행하여 미친 듯이 최적화할 수 있습니다 _only_ 해당 일치 주위의 공백으로 구분된 문자 시퀀스에서.
• 또한 끝없이 실행되는 문자가 있는 파일에 대해 "cat"을 수행하는 경우 성능이 저하될 수 있으므로 주의하십시오.
• 방법 A, B 및 C의 경우: 사용자가 이전 텍스트를 보기 위해 버퍼에서 뒤로 스크롤하면 까다로워 링크가 제한된 펄스 간격 동안 보기에 "팝"되는 것을 기대하지 않습니다. 따라서 스크롤 막대를 사용하여 수동으로 스크롤할 때 더 빠른 스캔을 수행하십시오. 하지만 아야, 실시간 흐름/자체 수정 텍스트를 성능이 좋은 방식으로 스캔하기 위한 코드가 얼마나 거친지 거의 상상할 수 없습니다.

간단히 말해서: 오 이런, 정말 미친(나쁜 성능 방식으로) 기능에 대한 사용자의 기대를 충족시키는 행운을 빕니다. 이 문제는 계속해서 점점 더 많은 데이터를 다운로드하고 오래된 데이터를 자체 수정하는 HTML 웹페이지를 스캔하기 위해 빠른 정규 표현식을 작성하려고 하는 것과 같습니다... 😛 적어도 이 중 일부가 궁극적인 솔루션에 대한 생각에 영감을 줄 수 있기를 바랍니다!

생각을 공유해 주셔서 감사합니다 :) 이 기능이 저만큼 마음에 드셨다니 다행입니다 ;)

우리가 사용하는 스캐닝 메커니즘이 무엇이든 간에 다음과 같이 될 것이라고 확신합니다.

1) 비동기
2) 효율적
3) 구성 가능

머리에 못을 박으셨군요. perf에 대한 귀하의 의견 - 이것은 이와 같은 기능의 주요 관심사이며 우리가 세심한 주의를 기울여야 하는 것입니다. 단순히 이전 콘솔 엔진 위에 일반 솔루션을 설계하는 것은 불가능했지만, 특히 터미널의 기본이 되는 새롭게 재설계된 엔진이 우리에게 필요한 액세스 및 기능을 제공해야 하는 지점에 가까워지고 있습니다.

이제 우리에게 도움이 될 기술과 시간을 가진 더 많은 개발자 및/또는 충분히 의욕적인 커뮤니티 구성원이 있었다면 😜

두 번째로 확장 지점이 있는 경우에는 기술을 가진 우리가 많이 있을 것이라고 확신합니다. 그리고 우리는 시간을 만들기 위해 매우 열심히 노력할 것입니다 :) 최소한 나 자신을 믿으십시오.

그날이 기대됩니다 :)

이것이 착륙하면 프로필별로 기본 응용 프로그램을 무시할 수 있으면 좋을 것입니다. 궁극적인 꿈은 다른 코드를 사용하여 다른 브라우저에서 URL을 실행할 수 있는 것입니다.

나는 당신이 이미 알고 있다고 생각하지만 과거에 유사한 문제를 일으킨 몇 가지 보안 위험이 있습니다. 특히 iTerm은 클릭하기 전에 링크를 강조 표시하기 위해 링크 위로 마우스를 가져갈 때 DNS 조회를 수행하는 데 문제가 있었습니다. 이것은 실제 공격을 조사하는 보안 분석가에게 상당히 중요한 문제였지만 일반 텍스트로 된 URL(민감한 정보 포함 - 암호 포함)과 유사한 항목에 대한 DNS 조회를 전송하기 때문에 문제도 발생했습니다.

나는 이 동작이 옳다 그르다라고 말하지는 않겠지만, 이것을 구현할 때 확실히 염두에 두어야 할 사항입니다. 참고로:
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

나는 이것이 더 큰 기능 요청을 염두에 두고 작게 시작하도록 정중하게 요청하기 위해 이 글을 씁니다. CTRL+클릭할 때 기본 브라우저에서 열리는 http(s):// 링크를 얻는 것은 좋은 시작이 될 것입니다! 너무 많은 명령줄 도구가 웹 링크를 내보내므로 지금 당장 복사하여 브라우저에 붙여넣어야 합니다. 우리가 그 기능만 있었다면 꽤 오랫동안 그것으로 충분할 것 같았습니다. 제 생각에는요. 당신의 배려에 감사합니다!

윈도우 터미널은 좋지만 링크를 클릭할 때마다 다른 터미널로 전환하는 것은 싫어요. 그게 다야.

이 기능을 요청하기 위해 여기에서 악수에 뛰어듭니다. macOS에서는 어색한 복사/붙여넣기 절차를 거치지 않고 URL을 클릭할 수 있는 빠른 방법이 정말 그리워집니다.

클릭 가능한 링크는 V2.0 로드맵에 있습니다. https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

주목할만한 변경/업데이트를 보고 있는 일부 구독자를 대신하여 지금 이 문제를 잠그거나 음소거해도 됩니까?

추가 요청, +1은 가치를 제공하지 않으며 받은 편지함에 더 많은 오염을 가져옵니다. 누군가가 이에 기여하고 싶다면 CR을 만들고 이 문제를 참조할 수 있습니다. :)