Tidak.

Promo pemasaran lebih merupakan "apa yang akan datang" daripada "apa yang tersedia sekarang". Kami menghargai kesabaran Anda saat kami terus mengerjakan proyek ini :)

Juga untuk menautkan, #555

@tackyunicorn - video terminalnya aspiratif - tujuannya adalah untuk mengilustrasikan beberapa fitur utama yang sedang kami usahakan untuk dikirimkan di Terminal. Beberapa fitur yang diilustrasikan sudah ada di Terminal. Sebagian besar akan dikirimkan dalam v1.0 pada akhir 2019. Lainnya mungkin memerlukan lebih banyak waktu desain, pembuatan & pemanggangan, dan akan dikirimkan setelah v1.0.

Saat ini, host yang dapat diperpanjang dan ekstensi seperti "Pratinjau Tautan" belum dirancang atau diimplementasikan, dan kemungkinan akan dikirimkan setelah v1.0. Kami ingin meluangkan waktu & upaya untuk memastikan bahwa kami membangun fitur penting seperti itu "tepat" untuk meminimalkan gangguan di kemudian hari.

Kami sedang mengerjakan peta jalan masa depan kami dan akan berbagi dengan komunitas dalam beberapa minggu ke depan.

Ringkasan fitur/peningkatan baru

Deteksi URL dan buat agar dapat diklik (buka URL di browser default). Ini adalah fitur kenyamanan yang ada di banyak terminal lainnya.

Saya percaya nilainya sudah jelas, tetapi inilah contoh kasus penggunaan konkret terlepas dari: ketika saya menjalankan yarn outdated (Benang adalah manajer paket) itu menghasilkan repositori/URL beranda untuk setiap paket yang terdaftar. Saya ingin dapat mengklik salah satu URL tersebut untuk membuka halaman dengan cepat/mudah dan melihat apa yang telah berubah di versi baru paket.

Detail implementasi

• Mungkin tidak perlu mendukung apa pun selain teks yang dimulai dengan http:// atau https:// .
• URL yang menjangkau beberapa baris (karena terpotong oleh lebar jendela) harus ditangani dengan benar.
• Mungkin harus ada indikasi bahwa URL dapat diklik, misalnya perubahan kursor + garis bawah pada kursor mouse.
• Kebanyakan terminal lain memerlukan klik alt atau ctrl, saya kira untuk menjaga dari klik yang tidak disengaja saat menyalin dan sebagainya.

Anda dapat melihat sesuatu seperti terminal VS Code untuk mendapatkan inspirasi. Sekali lagi ini semua mungkin terbukti dengan sendirinya.

Tujuan peregangan (tercakup dalam #204)

IMO itu harus mendukung semua skema demi penyelesaian, menghindari masalah lebih lanjut yang meminta penambahan yang baru dan penggunaan kembali kode/perpustakaan.

Satu hal yang mungkin rumit untuk diperbaiki adalah penanganan tanda kurung: sebagian besar implementasi yang saya temui salah melewatkan karakter tanda kurung penutup ( ) ) jika itu adalah karakter terakhir dalam tautan yang memutus beberapa tautan Wikipedia. Mungkin harus digunakan beberapa algoritma pencocokan tanda kurung untuk memutuskan apakah karakter terakhir ini adalah bagian dari tautan atau tidak.

EDIT: salah ketik

sebagian besar implementasi yang saya temui salah lewati karakter kurung penutup ( ) ) jika itu adalah karakter terakhir dalam tautan yang memutus beberapa tautan Wikipedia

Di sisi lain, URL sering diapit dalam tanda kurung dalam aliran teks (lihat misalnya http://example.com/foobar) <- seperti di sini, dan juga dalam file penurunan harga.

Di gnome-terminal kami menangani dua persyaratan yang bertentangan ini dengan mengizinkan tanda kurung () dan tanda kurung siku [] selama keduanya muncul dalam pasangan seimbang. Ini diimplementasikan menggunakan ekspresi reguler rekursif. Lihat gt 763980 .

Kasus rumit serupa lainnya adalah apostrof tambahan, lihat gt 448044 .

kami tidak dapat mengetahuinya tanpa melakukan polling pada server

Haha, ini juga kemungkinan – saya pribadi tidak akan melakukannya. Saya yakin Anda berbagi kekhawatiran saya tentang kebocoran data serta kelambatan.

Ini semua dugaan, tidak ada solusi yang sempurna (well, ada #204 untuk mengatasi kesenjangan ini). Kami menemukan parens yang cocok berfungsi dengan cukup baik, kami belum menerima laporan sejak kami menerapkannya. Setidaknya itu pasti ternyata lebih baik daripada selalu cocok dengan induknya atau tidak pernah cocok. Agak sulit untuk diterapkan, menggali fitur regex yang jarang digunakan dan hampir tidak dikenal dari perpustakaan regex tertentu (jadi saya tidak terkejut bahwa banyak terminal tidak peduli dengan itu), tetapi saya pikir itu sepadan. :)

Saya pikir kita perlu mendeteksi jalur folder dan membuatnya dapat diklik juga.
Lebih mudah untuk men-debug kode:

Kontrol TeachingTip dapat digunakan untuk fitur Pratinjau Tautan

Anda dapat melihat sesuatu seperti terminal VS Code untuk mendapatkan inspirasi. Sekali lagi ini semua mungkin terbukti dengan sendirinya.

Mengapa tidak berbagi kode yang sama saja?

Mungkin tidak perlu mendukung apa pun selain teks yang dimulai dengan http:// atau https://.

Saya pikir Anda harus menambahkan deteksi www. .

Mengapa tidak berbagi kode yang sama saja?

Yah, itu ditulis dalam TypeScript, dialek javascript ... jadi itu tidak akan bekerja di proyek C++ kami.

Tidak sabar untuk fitur ini!! Saya senang bisa menahan CTRL dan melihat tautan digarisbawahi di ConEmu di mana mengklik kiri membukanya di browser default. Semoga implementasi regex sederhana dari penyorotan URL berhasil sebelum akhir tahun :)

Kontrol TeachingTip dapat digunakan untuk fitur Pratinjau Tautan

Anda dapat membayangkan kontrol ini muncul di atas tautan, dengan Favicon, Nama Situs, dan deskripsi URL atau Bing untuk tautan tersebut

@mdtauk & @awarmfastbear - Maksud Anda seperti pop up pratinjau tautan yang kami ilustrasikan di video mendesis Terminal ?

Fitur tersebut diisyaratkan dalam gulungan mendesis saat Anda menunjukkan @bitcrazed - Komentar saya lebih tentang menggunakan kontrol XAML standar untuk mengimplementasikannya, dan tidak melakukannya dengan cara yang tidak konsisten dengan UI Windows. Anggap saja sebagai serangan pre-emptive

@bitcrazed itu adalah kalimat pertama dari masalah ini, btw ;)

@mdtauk Setuju. Kami pasti tidak ingin menemukan kembali roda yang tidak perlu. Jika kami dapat menggunakan kontrol XAML standar untuk mengimplementasikan fitur seperti ini, kami akan melakukannya.

Jika tidak, kami akan bekerja dengan tim kontrol XAML untuk mencari tahu apakah perubahan pada kontrol yang ada perlu dilakukan, atau jika kontrol baru dengan perilaku yang benar diperlukan.

Sejujurnya, tantangan terbesar di sini tidak mungkin adalah kontrol mana yang digunakan, itu adalah bagaimana membangun mekanisme ekstensibilitas yang memberikan semua fitur yang diperlukan, sambil tetap cukup cepat, stabil, dan aman.

Akan sangat bagus jika Anda dapat mendukung https://Gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

Pada salah satu sesi Ignite 2019, diindikasikan bahwa ini akan didukung melalui fitur ekstensi. Jadi, kita perlu menunggu dukungan ekstensi dilakukan.

@bitcrazed Saat ini, Terminal Windows sangat cepat pada benchmark "Mode pelangi" di https://github.com/pew/ternimal. Saya benar-benar memiliki kekhawatiran yang sama bahwa "tautan yang dapat diklik" akan memperkenalkan banyak latensi penguraian setiap kali karakter ditulis ke layar, dan sangat memperlambat Terminal Windows, karena pengurai yang tepat harus memindai ulang setiap karakter yang terhubung ke karakter yang ditulis ke layar, untuk melihat apakah ada di antara mereka yang membentuk tautan yang valid.

Saya punya ide: Bagaimana jika tautan tidak diuraikan sama sekali dan TIDAK dapat diklik SAMPAI pengguna menahan Kontrol (atau mungkin Alt) DAN mengarahkan mouse mereka ke Terminal Windows. Dalam skenario itu, kode akan memindai baris (dengan dukungan untuk baris yang dibungkus pada baris sebelumnya/berikut), dan mencari URL atau PATH FILE persis di kursor mouse. JIKA demikian, sorot URL, tampilkan pratinjau, buat agar dapat diklik (selama Ctrl masih ditahan), dll.

Selanjutnya, jika pengguna mengklik kanan, lakukan penguraian urutan karakter yang tidak terputus di tempat itu (jadi berhenti di spasi sebelum/sesudah urutan yang diklik), sehingga menyorot seluruh kata. Kemudian lakukan penguraian tautan. Jika tautan terdeteksi, tampilkan item menu "Buka Tautan".

Dalam skenario ctrl-and-hover dan klik kanan, parsernya identik:

• Dapatkan "baris + kolom" yang melayang dari kursor mouse.
• Jika kolom itu adalah spasi, jangan lakukan apa pun, karena tidak ada yang perlu dipindai.
• Jika kolom itu BUKAN spasi putih, kumpulkan semua karakter "terhubung" sebelum dan sesudahnya, dengan memindai hingga Anda menemukan spasi putih (baris baru, spasi, dll; spasi putih vertikal dan horizontal). Hasilnya akan berupa kata, atau tautan, atau apa pun.
• Lakukan penguraian tautan sederhana, untuk mendeteksi apakah itu URL. Lakukan juga penguraian sistem file, jika sesuatu terlihat seperti jalur file lokal (misalnya C:\Tools\foo.cpp:80 akan diuraikan dari kiri ke kanan dan mendeteksi bahwa C:\Tools\foo.cpp adalah file).
• Jika jalur URL/file terdeteksi, tangani tautannya.

Kedua solusi ini akan menjadi jawaban berkinerja paling tinggi, dan menahan Ctrl (atau mungkin Alt) bukanlah masalah besar. Banyak terminal menanganinya seperti itu, seperti terminal macOS. Di terminal macOS, Anda menahan Command + Klik dua kali untuk membuka tautan, atau sebagai alternatif Anda klik kanan untuk mendapatkan menu yang "mem-parsing" kata/tautan yang disorot (jika Anda mengklik kanan sebuah tautan, fakta itu terdeteksi dan menyoroti seluruh tautan), lalu pilih "Buka Tautan".

Semua alternatif akan boros dan jauh lebih lambat.

PS: Jika ini membantu, terminal Alacritty mendefinisikan karakter ini sebagai "pemisah tautan urutan karakter": ",│`|:\"' ()[]{}<>\t" , yang mungkin berguna untuk menentukan cara membagi string untuk mendeteksi jalur, URL, dll, di klik / urutan karakter melayang. Jika saya menulis parser, saya akan menggunakan teknik "dapatkan urutan karakter non-spasi lengkap" yang saya jelaskan di atas, diikuti dengan melewati "strip yang mengelilingi sampah seperti <> atau () setelah itu, untuk mendeteksi tautan terakhir.

Hai @VideoPlayerCode - terima kasih telah mengirimkan pemikiran Anda di sini.

Saya setuju, hanya penguraian untuk URL ketika pengguna menekan kunci/akor yang memungkinkan adalah menunda pemindaian regex, tetapi itu masih berarti kami tidak dapat mewarnai URL sorotan yang disematkan dalam teks - sesuatu yang telah diminta oleh banyak pengguna.

Selain itu, URL hanyalah salah satu dari kelas pola teks yang ingin kita cari dan identifikasi: Misalnya, saya ingin memiliki kemampuan untuk memberi tahu Terminal untuk menggambar kotak merah dengan isian kuning di bawah teks yang cocok pola teks/regex/etc yang ditentukan. - bayangkan dapat menyorot pesan kesalahan dengan cara ini di log server web saat streaming. 😁

Saya cukup yakin kami akan dapat menemukan strategi untuk dapat mengidentifikasi kecocokan pola/regex dengan cara yang cukup berkinerja. Pada akhirnya. Suatu hari

@bitcrazed

Saya setuju, hanya penguraian untuk URL ketika pengguna menekan kunci/akor yang memungkinkan adalah menunda pemindaian regex, tetapi itu masih berarti kami tidak dapat mewarnai URL sorotan yang disematkan dalam teks - sesuatu yang telah diminta oleh banyak pengguna.

Ahh, saya baru menyadari bahwa fitur "scanner selalu aktif" dihadirkan dalam video pemasaran dan diharapkan oleh pengguna. Ups.

Selain itu, URL hanyalah salah satu dari kelas pola teks yang ingin kita cari dan identifikasi: Misalnya, saya ingin memiliki kemampuan untuk memberi tahu Terminal untuk menggambar kotak merah dengan isian kuning di bawah teks yang cocok pola teks/regex/etc yang ditentukan. - bayangkan dapat menyorot pesan kesalahan dengan cara ini di log server web saat streaming. 😁

Wah, saya suka ide itu! Mampu mengatur regex di konfigurasi pengguna dan memilih cara menyorot kecocokan akan sangat fantastis.

Saya cukup yakin kami akan dapat menemukan strategi untuk dapat mengidentifikasi kecocokan pola/regex dengan cara yang cukup berkinerja. Pada akhirnya. Suatu hari

Nah, jika perlu ada pemindaian terus menerus... berikut beberapa idenya:

• Saat melakukan pemindaian, lakukan hanya buffer layar yang terlihat saat ini. Jika penyangga layar dimulai dengan karakter non-spasi, sertakan juga teks yang berada di luar layar hingga spasi putih sebelumnya (seperti jika baris teratas adalah hub.com/foo tetapi sebenarnya merupakan kelanjutan dari https://git<wrap>hub.com/foo ).
• Menjalankan regex pada buffer itu perlu dibatasi dengan salah satu dari empat cara (atau kombinasi semuanya):
• J: Hanya lakukan pemindaian setiap kali tidak ada yang ditulis ke layar (tidak ada teks baru/karakter yang diubah) untuk waktu yang wajar, seperti 300 ms. Itu berarti bahwa ketika log bergulir cepat atau "kucing" aktif, mereka akan berjalan tanpa hambatan.
• Atau B: Jalankan pada interval yang berdenyut seperti 300ms, di mana Anda memblokir eksekusi, lakukan pemindaian cepat, tandai sorotan jika diperlukan, lalu lanjutkan eksekusi (menggunakan data stdout yang masuk).
• Atau C: Pindai secara waktu nyata saat pengguliran lambat, tetapi hentikan sepenuhnya pemindaian waktu nyata saat tingkat keluaran sangat tinggi. Misalnya "cat 10mbfile.txt" akan menonaktifkan pemindaian waktu nyata karena terminal akan melihat tingkat keluaran yang gila. Dan segera setelah output gila berhenti, lakukan satu kali melewati buffer output lama yang baru saja dialirkan. Saya paling suka ide ini. Dan menggabungkannya dengan teknik hanya memindai buffer layar yang terlihat.
• Atau D: Pindai semua data secara langsung saat masuk (akan payah untuk kinerja), dan simpan hasilnya. Setiap kali baris ditambahkan atau karakter diganti dalam buffer, pindai/pindai ulang hanya baris tersebut.
• Pertimbangkan juga hanya tautan pendukung, setidaknya untuk pemindaian waktu nyata. Karena regexp khusus benar-benar bisa menjadi cukup gila sehingga mereka akan cocok dengan seluruh buffer. Bayangkan bagaimana Anda akan MULAI untuk mencocokkan regexp yang cocok dari kata "Log Result:" hingga baris yang bertuliskan "End of Log", dalam contoh "regexp khusus" Anda. Itu bisa berupa ribuan baris data yang seharusnya cocok. Heck, regexp itu bahkan tidak akan tahu cara mencocokkan apa pun sampai ia melihat "End of Log" menjepit di akhir pertandingan. Sangat gila...
• Jika Anda hanya mendukung tautan, Anda dapat mengoptimalkan seperti orang gila dengan hanya memindai "http:" dan "https:" (tidak peka huruf besar/kecil) dengan pencocokan pola yang cukup sederhana dan dioptimalkan, lalu melakukan pemindaian "mesin regexp penuh" _only_ pada urutan karakter yang dibatasi spasi di sekitar kecocokan itu.
• Juga berhati-hatilah dengan orang yang melakukan "cat" pada file yang memiliki karakter berjalan tanpa henti, karena itu akan mematikan kinerja.
• Untuk metode A, B, dan C: Saat pengguna menggulir mundur di buffer untuk melihat teks lama, mereka akan pilih-pilih dan tidak akan mengharapkan tautan untuk "muncul" selama interval pulsa yang dibatasi. Jadi lakukan pemindaian lebih cepat saat menggulir secara manual dengan bilah gulir. Tapi aduh, saya hampir tidak bisa membayangkan betapa kasarnya kode untuk memindai teks yang mengalir/memodifikasi diri secara realtime dengan cara yang berkinerja baik.

Singkatnya: Ya ampun, semoga berhasil memenuhi harapan pengguna dari fitur yang cukup gila (dengan cara kinerja yang buruk). Masalah ini seperti mencoba menulis regexp cepat untuk memindai halaman web HTML yang terus-menerus mengunduh lebih banyak data dan memodifikasi sendiri data lama... Semoga setidaknya beberapa dari ini dapat menginspirasi beberapa pemikiran untuk solusi akhirnya!

Terima kasih telah berbagi pemikiran Anda :) Senang Anda menyukai fitur ini seperti saya;)

Apa pun mekanisme pemindaian yang kami gunakan, cukup yakin itu akan menjadi:

1) Tidak sinkron
2) Efisien
3) Dapat Dikonfigurasi

Anda memukul paku di kepala tho re. komentar Anda tentang perf - ini adalah perhatian utama dari fitur seperti ini dan yang perlu kita perhatikan. Tidaklah mungkin untuk merekayasa solusi umum di atas mesin Konsol yang lama, tetapi kami mendekati titik di mana mesin yang baru diarsitektur ulang yang mendasari Terminal secara khusus akan memberi kami akses dan fitur yang kami butuhkan.

Sekarang, jika saja kita memiliki lebih banyak pengembang dan/atau anggota komunitas yang cukup termotivasi dengan keterampilan dan waktu untuk membantu

Saat Anda memiliki poin ekstensi, saya yakin ada banyak dari kita di luar sana dengan keterampilan. Dan kami akan berusaha sangat keras untuk meluangkan waktu :) Hitung diri saya setidaknya.

Menunggu hari itu :)

Ketika ini mendarat, akan sangat bagus untuk dapat mengganti aplikasi default berdasarkan per profil. Impian utamanya adalah dapat menggunakan akord yang berbeda untuk meluncurkan URL di browser yang berbeda.

Saya membayangkan Anda sudah mengetahuinya, tetapi ada beberapa risiko keamanan yang telah menyebabkan masalah serupa di masa lalu, terutama iTerm memiliki masalah dalam melakukan pencarian DNS saat mengarahkan kursor ke tautan untuk menyorotnya sebelum mengklik. Ini adalah masalah yang cukup besar bagi analis keamanan yang menyelidiki serangan langsung, tetapi juga menyebabkan masalah karena mengirimkan pencarian DNS untuk hal-hal yang menyerupai url (termasuk info sensitif - misalnya kata sandi) dalam teks biasa.

Saya tidak akan mengatakan perilaku ini benar atau salah, tetapi pasti sesuatu yang perlu diingat ketika menerapkan ini. Sebagai referensi:
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

Saya menulis untuk meminta dengan hormat agar ini dimulai dari yang kecil dengan memperhatikan permintaan fitur yang lebih besar. Mendapatkan http(s):// tautan untuk dibuka di browser default, saat CTRL+mengkliknya, akan menjadi awal yang baik! Begitu banyak alat baris perintah yang mengeluarkan tautan web yang saat ini harus disalin dan ditempelkan ke browser. Jika kami hanya memiliki fungsi itu, itu bisa cukup untuk waktu yang cukup lama, menurut saya. Terima kasih atas pertimbangan Anda!

Saya suka terminal windows, tetapi saya benci beralih ke terminal yang berbeda setiap kali saya ingin mengklik tautan. Itu saja.

Melompat pada kereta musik di sini untuk meminta fitur ini. Berasal dari macOS, saya sangat merindukan cara cepat untuk mengklik URL tanpa harus melalui ritual salin/tempel yang canggung.

Tautan yang dapat diklik ada di peta jalan untuk V2.0: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

Atas nama beberapa pelanggan yang menonton ini untuk perubahan / pembaruan penting; dapatkah kami mengunci/membisukan masalah ini untuk saat ini?

Permintaan tambahan, +1, tidak memberikan nilai dan membawa lebih banyak polusi ke kotak masuk kami. Jika seseorang ingin berkontribusi untuk ini, mereka dapat membuat CR dan referensi masalah ini. :)