Неа.

Маркетинговая реклама - это скорее «что будет дальше», чем «то, что доступно сейчас». Благодарим вас за терпение, поскольку мы продолжаем работать над этим проектом :)

Также для линковки, # 555

@tackyunicorn - видеоролик о интересен - его цель - проиллюстрировать некоторые из ключевых функций, которые мы упорно трудимся, чтобы добавить в Терминал. Некоторые из проиллюстрированных функций уже есть в Терминале. Большинство из них будет выпущено в версии 1.0 к концу 2019 года. Для других может потребоваться больше времени на проектирование, сборку и выпекание, и они будут поставляться после версии 1.0.

В настоящее время хост расширяемости и расширения, такие как Link Preview, еще не разработаны и не реализованы и, вероятно, будут выпущены после версии 1.0. Мы хотим потратить время и усилия, чтобы убедиться, что мы создаем такие важные функции «правильно», чтобы свести к минимуму перебои в работе позже.

Мы работаем над нашей будущей дорожной картой и поделимся с сообществом в ближайшие пару недель.

Краткое описание новой функции / улучшения

Определите URL-адреса и сделайте их интерактивными (откройте URL-адрес в браузере по умолчанию). Это удобная функция, присутствующая во многих других терминалах.

Я считаю, что значение самоочевидно, но вот конкретный пример использования независимо от того: когда я запускаю yarn outdated (Yarn - менеджер пакетов), он выводит URL-адрес репозитория / домашней страницы для каждого указанного пакета. Я хочу иметь возможность щелкнуть один из этих URL-адресов, чтобы быстро / легко открыть страницу и посмотреть, что изменилось в новой версии пакета.

Детали реализации

• Вероятно, не нужно поддерживать ничего, кроме текста, начинающегося с http:// или https:// .
• URL-адреса, занимающие несколько строк (из-за усечения по ширине окна), должны обрабатываться правильно.
• Вероятно, должно быть указание на то, что URL-адрес доступен для кликов, например, изменение курсора + подчеркивание при наведении курсора мыши.
• Для большинства других терминалов требуется щелчок Alt или Ctrl, я полагаю, чтобы защитить себя от случайных щелчков при копировании и так далее.

Для вдохновения вы можете взглянуть на что-то вроде терминала VS Code. Опять же, все это, вероятно, самоочевидно.

Растяжка ворот (рассматривается в # 204)

ИМО, он должен поддерживать все схемы для завершения, избегая дальнейших проблем, требующих добавления новых и повторного использования кода / библиотеки.

Одна вещь, которая может быть сложной для правильного понимания, - это обработка круглых скобок: большинство реализаций, которые я встречал, неправильно пропускают закрывающий символ круглой скобки ( ) ), если это последний символ в ссылке, нарушающий несколько ссылок Википедии. Вероятно, следует использовать какой-нибудь алгоритм сопоставления скобок, чтобы решить, является ли этот последний символ частью ссылки или нет.

РЕДАКТИРОВАТЬ: опечатка

большинство реализаций, которые я встречал, неправильно пропускают закрывающий символ круглой скобки ( ) ), если это последний символ в ссылке, нарушающий несколько ссылок Википедии

С другой стороны, URL-адреса часто заключаются в круглые скобки в текстовом потоке (см., Например, http://example.com/foobar) <- как здесь, так и в файлах Markdown.

В gnome-terminal мы обратились к этим двум противоречащим требованиям, разрешив скобки () и квадратные скобки [] если они встречаются в сбалансированных парах. Это было реализовано с использованием рекурсивного регулярного выражения. См. Gt 763980 .

Другой похожий сложный случай - конечный апостроф, см. Gt 448044 .

мы не можем понять это без опроса сервера

Ха-ха, это тоже возможно - хотя лично я бы на это не пошел. Я уверен, что вы разделяете мои опасения по поводу утечки данных, а также медлительности.

Это все догадки, идеального решения не существует (ну, есть №204, чтобы восполнить этот пробел). Мы обнаружили, что подходящие парни работают достаточно хорошо, мы не получали отчета с тех пор, как реализовали это. По крайней мере, это определенно оказалось лучше, чем всегда соответствовать парену или никогда не совпадать. Это было немного сложно реализовать, копаться в редко используемых и малоизвестных функциях регулярных выражений некоторых библиотек регулярных выражений (поэтому я не удивлен, что многие терминалы не беспокоятся об этом), но я думаю, что оно того стоило. :)

Я думаю, нам нужно определить путь к папкам и сделать их кликабельными.
Проще отлаживать код:

Элемент управления TeachingTip может использоваться для функции предварительного просмотра ссылки.

Для вдохновения вы можете взглянуть на что-то вроде терминала VS Code. Опять же, все это, вероятно, самоочевидно.

Почему бы просто не поделиться одним и тем же кодом?

Вероятно, не нужно поддерживать ничего, кроме текста, начинающегося с http: // или https: //.

Я думаю, вам стоит добавить обнаружение www. .

Почему бы просто не поделиться одним и тем же кодом?

Ну, он написан на TypeScript, диалекте javascript ... поэтому он не будет работать в нашем проекте C ++.

Не могу дождаться этой функции !! Мне нравится удерживать CTRL и видеть, как ссылка подчеркивается в ConEmu, а щелчок левой кнопкой мыши открывает ее в браузере по умолчанию. Надеюсь, простая реализация выделения URL-адресов с помощью регулярного выражения дойдет до конца года :)

Элемент управления TeachingTip может использоваться для функции предварительного просмотра ссылки.

Вы можете представить этот элемент управления, появляющийся над ссылкой, с Favicon, именем сайта и URL-адресом или описанием Bing для ссылки.

@mdtauk & @awarmfastbear - Вы имеете в виду, как всплывающее окно предварительного просмотра ссылки, которое мы проиллюстрировали в шипящем видео Терминала ?

На эту функцию намекали в этом шипящем ролике, когда вы указываете

@bitcrazed , это буквально первое предложение в этом выпуске, кстати;)

@mdtauk Согласен. Мы определенно не хотим без надобности заново изобретать колесо. Если мы сможем использовать стандартные элементы управления XAML для реализации подобных функций, мы это сделаем.

Если нет, мы будем работать с группами элементов управления XAML, чтобы выяснить, нужно ли вносить изменения в существующие элементы управления или требуется новый элемент управления с правильным поведением.

Однако, честно говоря, самая большая проблема здесь вряд ли будет заключаться в том, какой элемент управления использовать, а в том, как создать механизм расширяемости, который предоставляет все необходимые функции, оставаясь при этом достаточно быстрым, стабильным и безопасным.

Было бы замечательно, если бы вы могли поддержать https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

На одном из сеансов Ignite 2019 было указано, что это будет поддерживаться с помощью функции расширения. Итак, нам нужно дождаться завершения поддержки расширений.

@bitcrazed В https://github.com/pew/ternimal. Я определенно разделяю то же беспокойство по поводу того, что «интерактивные ссылки» приведут к большой задержке парсинга каждый раз, когда символы выводятся на экран, и сильно замедлят Windows Terminal, так как надлежащему парсеру придется повторно сканировать каждый символ, который подключен. к персонажу, который был выведен на экран, чтобы увидеть, образуют ли какие-либо из них действительные ссылки.

У меня есть идея: что, если ссылки вообще не анализируются и НЕ активируются, пока пользователь не удерживает Control (или, возможно, Alt) И не наводит указатель мыши на Терминал Windows. В этом сценарии код будет сканировать строку (с поддержкой строк, которые заключены в предыдущие / последующие строки) и искать URL-адрес или ПУТЬ ФАЙЛА точно на курсоре мыши. ЕСЛИ это так, затем выделите URL-адрес, покажите предварительный просмотр, сделайте его интерактивным (пока удерживается Ctrl) и т. Д.

Кроме того, если пользователь щелкает правой кнопкой мыши, выполните синтаксический анализ непрерывной последовательности символов в этом месте (поэтому остановитесь на пробеле до / после выбранной последовательности), тем самым выделив все слово. Затем займитесь парсингом ссылок. Если ссылка обнаружена, покажите пункт меню «Открыть ссылку».

Как в сценариях ctrl-and-hover, так и при щелчке правой кнопкой мыши, синтаксический анализатор идентичен:

• Получите наведенную «строку + столбец» курсора мыши.
• Если этот столбец пуст, ничего не делайте, так как сканировать нечего.
• Если этот столбец НЕ ЯВЛЯЕТСЯ пробелом, соберите все «связанные» символы до и после него, сканируя до тех пор, пока не встретите пробелы (новые строки, пробелы и т. Д.; Как вертикальные, так и горизонтальные пробелы). Результатом будет слово, ссылка или что-то еще.
• Выполните простой синтаксический анализ ссылки, чтобы определить, является ли это URL-адресом. Также выполните синтаксический анализ файловой системы, если что-то похоже на путь к локальному файлу (например, C:\Tools\foo.cpp:80 будет проанализирован слева направо и обнаружит, что C:\Tools\foo.cpp - это файл).
• Если обнаружен URL-адрес / путь к файлу, обработайте ссылку.

Эти два решения были бы САМЫМ высокопроизводительным ответом, и удерживание Ctrl (или, возможно, Alt) не имеет большого значения. Многие терминалы справляются с этим таким образом, например терминал macOS. В терминале macOS вы удерживаете Command + двойной щелчок, чтобы открыть ссылки, или, альтернативно, вы щелкаете правой кнопкой мыши, чтобы получить меню, которое «анализирует» выделенное слово / ссылку (если вы щелкнете правой кнопкой мыши ссылку, этот факт будет обнаружен и выделит всю ссылку), а затем выберите «Открыть ссылку».

Все альтернативы были бы расточительны и намного медленнее.

PS: В случае, если это полезно, терминал Alacritty определяет эти символы как «последовательность символов-разделителей ссылок»: ",│`|:\"' ()[]{}<>\t" , что может быть полезно для определения того, как разделять строки для определения путей, URL-адресов и т. Д. В выбранных / Последовательность зависших символов. Если бы я писал синтаксический анализатор, я бы использовал технику «получить полную последовательность непробельных символов», описанную выше, с последующим прохождением через «полосу окружающего мусора, такого как <> или () после этого, чтобы обнаружить последнюю ссылку.

Привет, @VideoPlayerCode - спасибо, что отправили сюда свои мысли.

Я согласен, только синтаксический анализ URL-адресов, когда пользователь нажимает клавишу / аккорд, позволит отложить сканирование регулярных выражений, но это все равно будет означать, что мы не можем раскрасить выделенные URL-адреса, встроенные в текст - то, что многие пользователи уже просили.

Кроме того, URL-адреса - это всего лишь один из класса текстовых шаблонов, которые мы хотим искать и идентифицировать: например, мне бы хотелось иметь возможность указать Терминалу рисовать красное поле с желтой заливкой под текстом, который соответствует указанный текстовый шаблон / регулярное выражение / и т. д. - представьте себе возможность выделять таким образом сообщения об ошибках в журнале веб-сервера по мере их поступления. 😁

Я почти уверен, что мы сможем найти стратегию, позволяющую довольно эффективно определять совпадения шаблонов / регулярных выражений. В итоге. Однажды

@bitcrazed

Я согласен, только синтаксический анализ URL-адресов, когда пользователь нажимает клавишу / аккорд, позволит отложить сканирование регулярных выражений, но это все равно будет означать, что мы не можем раскрасить выделенные URL-адреса, встроенные в текст - то, что многие пользователи уже просили.

Ах, я только что понял, что функция «всегда активный сканер» была представлена ​​в маркетинговом видео и ожидается от пользователей. Ой.

Кроме того, URL-адреса - это всего лишь один из класса текстовых шаблонов, которые мы хотим искать и идентифицировать: например, мне бы хотелось иметь возможность указать Терминалу рисовать красное поле с желтой заливкой под текстом, который соответствует указанный текстовый шаблон / регулярное выражение / и т. д. - представьте себе возможность выделять таким образом сообщения об ошибках в журнале веб-сервера по мере их поступления. 😁

Ого, мне нравится эта идея! Было бы здорово иметь возможность установить регулярное выражение в конфигурации пользователя и выбрать способ выделения совпадений.

Я почти уверен, что мы сможем найти стратегию, позволяющую довольно эффективно определять совпадения шаблонов / регулярных выражений. В итоге. Однажды

Что ж, если необходимо непрерывное сканирование ... вот несколько идей:

• При сканировании делайте только видимый в данный момент экранный буфер. Если экранный буфер начинается с непробельного символа, включите также текст, который был за пределами экрана до предыдущего пробела (например, если верхняя строка - hub.com/foo но на самом деле является продолжением https://git<wrap>hub.com/foo ).
• Выполнение регулярного выражения в этом буфере необходимо будет регулировать одним из четырех способов (или их комбинациями):
• О: Выполняйте сканирование только тогда, когда на экран ничего не было записано (нет нового текста / измененных символов) в течение разумного периода времени, например 300 мс. Это означает, что когда активна быстрая прокрутка журналов или активен «кот», они будут работать без ограничений.
• Или B: запустите его с пульсирующим интервалом, например 300 мс, где вы блокируете выполнение, выполняете быстрое сканирование, отмечаете выделение там, где это необходимо, а затем продолжаете выполнение (используя входящие данные stdout).
• Или C: сканирование в реальном времени при медленной прокрутке, но полное прекращение сканирования в реальном времени при очень высокой скорости вывода. Например, «cat 10mbfile.txt» отключит сканирование в реальном времени, поскольку терминал заметит безумную скорость вывода. И как только безумный вывод прекратится, выполните одноразовый проход через старый буфер вывода, который только что был передан в потоковом режиме. Мне больше всего нравится эта идея. И объедините это с техникой сканирования только видимого буфера экрана.
• Или D: сканировать все данные в режиме реального времени по мере их поступления (будет плохо для производительности) и кэшировать результаты. Всякий раз, когда в буфере добавляются строки или заменяются символы, сканировать / повторно сканировать только эти строки.
• Также учитывайте только вспомогательные ссылки, по крайней мере, для сканирования в реальном времени. Потому что настраиваемые регулярные выражения могут быть достаточно безумными, чтобы соответствовать всему буферу. Представьте себе, как вы даже НАЧИНАЕТЕ сопоставлять регулярное выражение, которое соответствует от слов «Результат журнала:» вплоть до строки с надписью «Конец журнала» в вашем примере «настраиваемого регулярного выражения». Это могут быть тысячи строк данных, которые должны совпадать. Черт возьми, это регулярное выражение даже не знает, как сопоставить что-либо, пока не увидит, что "Конец журнала" зажимается в конце сопоставления. Очень безумно ...
• Если вы поддерживаете только ссылки, вы можете оптимизировать как сумасшедший, сканируя только «http:» и «https:» (без учета регистра) с помощью довольно простого, оптимизированного сопоставления шаблонов, а затем выполняя сканирование «полного механизма регулярных выражений» _only_ в последовательности символов, разделенных пробелами, вокруг этого совпадения.
• Также будьте осторожны с людьми, которые бесконечно используют "кошку" на файлах с бегущими символами, так как это убьет производительность.
• Для методов A, B и C: когда пользователь прокручивает буфер назад, чтобы увидеть старый текст, он будет придирчивым и не будет ожидать, что ссылки «появятся» в поле зрения в течение заданного интервала импульсов. Так что выполняйте сканирование быстрее при прокрутке вручную с помощью полос прокрутки. Но ой, я едва могу представить, насколько грубым будет код для эффективного сканирования текущего / самомодифицирующегося текста в реальном времени.

Вкратце: О боже, удачи в удовлетворении ожиданий пользователей относительно безумной (с точки зрения плохой производительности) функции. Эта проблема похожа на попытку написать быстрое регулярное выражение для сканирования веб-страницы HTML, которая постоянно загружает все больше и больше данных и самомодифицирует старые данные ... 😛 Надеюсь, что по крайней мере часть этого может вдохновить некоторые мысли на возможное решение!

Спасибо, что поделились своими мыслями :) Рад, что эта функция вам нравится так же, как и мне;)

Какой бы механизм сканирования мы ни использовали, почти наверняка он будет:

1) Асинхронный
2) Эффективный
3) Настраиваемый

Вы попали в точку. ваши комментарии к perf - это основная проблема, связанная с этой функцией, и на которую нам нужно обратить пристальное внимание. Было просто невозможно спроектировать общее решение на основе старого движка консоли, но мы приближаемся к тому моменту, когда заново переделанный движок, лежащий в основе Терминала, в частности, должен предоставить нам доступ и функции, которые нам нужны.

Вот если бы у нас было больше разработчиков и / или достаточно мотивированных членов сообщества, у которых были бы навыки и время, чтобы помочь 😜

Как только у вас появятся очки расширения, я уверен, что нас найдется много, обладающих такими навыками. И мы очень постараемся найти время :) По крайней мере, рассчитывай на себя.

С нетерпением жду этого дня :)

Когда это произойдет, было бы здорово иметь возможность переопределить приложение по умолчанию для каждого профиля. Конечная мечта - иметь возможность использовать разные аккорды для запуска URL в разных браузерах.

Я полагаю, вы уже знаете, но есть некоторые риски безопасности, которые вызывали аналогичные проблемы в прошлом, в частности, у iTerm были проблемы с поиском DNS при наведении курсора на ссылки, чтобы выделить их перед нажатием. Это было довольно серьезной проблемой для аналитиков безопасности, исследующих живые атаки, но также вызывало проблемы, поскольку он отправлял запросы DNS для вещей, которые напоминали URL-адреса (включая конфиденциальную информацию - например, пароли) в открытом виде.

Я не буду заходить так далеко, чтобы утверждать, что это правильное или неправильное поведение, но определенно нужно иметь в виду при его реализации. Для справки:
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

Я пишу, чтобы почтительно просить, чтобы это началось с малого, учитывая более крупный запрос функции. Получение ссылок http (s): // для открытия в браузере по умолчанию, когда CTRL + щелчок по ним, было бы отличным началом! Многие инструменты командной строки выводят веб-ссылки, которые прямо сейчас необходимо скопировать и вставить в браузер. На мой взгляд, если бы у нас была только эта функциональность, этого могло бы хватить на некоторое время. Спасибо за внимание!

Мне нравится терминал Windows, но я ненавижу переключаться на другой терминал каждый раз, когда хочу нажимать ссылки. Это все.

Прыгаем на подножку здесь, чтобы попросить эту функцию. Начиная с macOS, я очень скучаю по быстрому способу щелкать URL-адреса без необходимости выполнять неудобный ритуал копирования / вставки.

Интерактивные ссылки есть в дорожной карте для V2.0: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

От имени некоторых подписчиков наблюдают за заметными изменениями / обновлениями; можем ли мы сейчас заблокировать / отключить эту проблему?

Дополнительные запросы (+1) не представляют ценности и загрязняют наши почтовые ящики. Если кто-то хочет внести свой вклад в это, он может сделать CR и сослаться на эту проблему. :)