Vscode: Tab yang tepat untuk membuka file

+1

Apakah mungkin menambahkan tab melalui ekstensi khusus? Saya dengan cepat melihat dokumen tetapi tampaknya tidak mungkin untuk menambahkan jenis fungsionalitas itu dengan API saat ini

Apakah mungkin menambahkan tab melalui ekstensi khusus?

Tidak, ini saat ini tidak dimungkinkan dari ekstensi (lihat juga http://code.visualstudio.com/docs/extensions/our-approach)

+1

: +1:

: +1:

+1

Tab adalah cara default untuk bekerja bahkan di Visual Studio, belum lagi editor teks lain seperti sublime.

Bagi mereka yang tidak memiliki tab, pernahkah Anda mencoba menggunakan Ctrl+Tab untuk menavigasi dalam riwayat file yang dibuka?

Iya. Tetapi file tetap dalam konteks Ctrl+tab bahkan setelah file ditutup. Pengalamannya tidak sama dengan Sublime / Atom.

@snehilmodani benar, apakah akan membantu jika daftar hanya menampilkan apa yang Anda miliki di bagian file kerja penjelajah? dapatkah Anda bekerja dengan daftar file kerja setidaknya?

Itu akan bagus!

Di samping catatan: Bukankah tata letak dengan nama file sebagai tab lebih ramah pengguna. Dapat diperluas untuk memiliki satu atau lebih bagian tab masing-masing dengan kumpulan file yang dibuka sendiri. (Sekali lagi saya menggunakan Sublime Text sebagai referensi di sini)

Saya pikir memiliki tab atau tidak tidak tergantung pada memiliki bagian. Hari ini Anda dapat membuka hingga 3 editor berdampingan di VS Code dan karenanya kami memiliki bagian. Karena kami tidak memiliki tab, kami tidak menambahkan banyak file ke dalam bagian ini dan Anda juga tidak boleh memiliki bagian kosong (yang merupakan diskusi UX terpisah).

Kembali ke Ctrl + Tab: Kami di tim selalu bekerja tanpa tab sejak hari pertama dan sebenarnya kami bahkan tidak memiliki tampilan file kerja untuk waktu yang lama dan pada kenyataannya tidak begitu banyak orang di tim yang menggunakannya. Kami menemukan bahwa bagi kami tidak masalah file mana yang Anda buka atau tutup. Pikiran kita agak memikirkan urutan kronologis file mana yang terakhir kita edit. Jadi ketika saya membuka Ctrl + Tab, biasanya akan menunjukkan kepada saya file-file yang terakhir saya simpan. Saya tidak benar-benar melihat jumlah file di sana, saya hanya tertarik pada 5 file teratas, maksimal. Keuntungan model ini adalah Anda tidak perlu mengelola tata letak dan tab sama sekali. Manajemen terjadi secara alami saat Anda menavigasi antar file.

Kita dapat menambahkan pemilih file untuk file yang sedang bekerja, tetapi akan menarik untuk mendengar jika orang dapat diyakinkan untuk menggunakan Ctrl + Tab seperti sekarang dan mempelajari apa masalahnya.

@bpasero Saya akan memberikan ctrl+tab kesempatan, saya baru menyadari ini dapat digunakan untuk pergi ke file sebelumnya yang merupakan sesuatu yang saya inginkan dan belum melihat sampai sekarang. Jadi itu bagus.

Ngomong-ngomong, terlepas dari apakah seseorang bisa mendapatkan / terbiasa dengan ctrl+tab sebagai alternatif tab, pengguna kode VS baru mungkin akan menunda oleh kurangnya tab, jadi jika hanya karena alasan pangsa pasar saya akan merekomendasikan memiliki opsi tab. Setiap editor lain menggunakan tab (untuk lebih baik atau lebih buruk), dan tidak membuatnya memperkenalkan penghalang entri yang agak tidak perlu ke kode VS. Saya menggunakan kode VS terlepas dari dukungan tab karena dukungan skrip yang luar biasa, tetapi jika bukan karena itu saya tidak tahu apakah saya akan menyimpannya beberapa kali pertama saya mencobanya.

Ya, Ctrl+Tab adalah tentang menavigasi kembali ke riwayat file yang sedang dikerjakan. Anda dapat menekan dan menahan tombol Ctrl dan menekan Tab berulang kali untuk kembali melampaui 1 file.

Ctrl+tab adalah hal yang luar biasa untuk dimiliki dan saya benar-benar penggemar itu. Itu adalah sesuatu yang bahkan Atom lewatkan.

Mengenai Tab dan beberapa file di setiap bagian: Bahkan di Sublime Text kita dapat membuka 3 editor secara berdampingan tetapi mereka masih menawarkan tata letak tab bagian. Saya setuju dengan Anda tentang kekacauan dan mengelola tata letak editor akan menjadi tugas yang cukup tetapi orang-orang sudah terbiasa dengan itu.
Saya ingin sekali menjadi bagian dari eksperimen sosial di mana Anda mencoba meyakinkan kami untuk menyingkirkan interaksi berbasis tata letak yang berantakan dengan editor kami.

Saya setuju dengan Anda tentang kekacauan dan mengelola tata letak editor akan menjadi tugas yang cukup tetapi orang-orang sudah terbiasa dengan itu.

Saya yakin kami dapat menemukan lebih banyak contoh UX di mana kami dulu terbiasa dengan sesuatu dan kemudian kami terbiasa dengan sesuatu yang jauh lebih baik :). Pikirkan interaksi sentuhan keyboard ponsel vs smartphone.

Saya ingin sekali menjadi bagian dari eksperimen sosial di mana Anda mencoba meyakinkan kami untuk menyingkirkan interaksi berbasis tata letak yang berantakan dengan editor kami.

Ya, saya pikir kita perlu melakukan sesuatu seperti ini 2016. @stevencl fyi

Mengenai Tab dan beberapa file di setiap bagian: Bahkan di Sublime Text kita dapat membuka 3 editor secara berdampingan tetapi mereka masih menawarkan tata letak tab bagian.

Saya setuju pada opsi untuk memungkinkan bagian yang lebih stabil sehingga kami dapat memiliki bagian kosong, tetapi dapat melihat tab di bagian ini hanyalah representasi visual dari file di sana yang dalam banyak kasus tumbuh begitu banyak sehingga Anda akhirnya tidak melihat apapun. Menurut saya tab bukanlah cara yang baik untuk menampilkan daftar file yang terbuka kecuali Anda mengelola hal-hal ini secara aktif dan menutupnya.

Menurut saya tab bukanlah cara yang baik untuk menampilkan daftar file yang terbuka kecuali Anda mengelola hal-hal ini secara aktif dan menutupnya.

Beberapa orang benar-benar mengelolanya dan untuk orang lain ada tab dekat di sebelah kanan.

Terima kasih banyak atas umpan baliknya.

Kami memiliki masalah pada backlog UX kami (# 1133) untuk meningkatkan manajemen ruang kerja (mengelola file terbuka, riwayat dll) yang mana ini akan menjadi bagian darinya. Tujuan kami adalah untuk meningkatkan pengalaman sedemikian rupa sehingga mengelola daftar file terbuka dan terbaru menjadi lugas dan mudah dan memungkinkan pengguna untuk fokus pada kode mereka, tanpa harus memberikan perhatian yang tidak semestinya pada VS Code UI.

Hipotesis kami adalah bahwa sistem saat ini memiliki beberapa sisi kasar (misalnya, menutup editor sebenarnya menutup editor, tetapi kami berpikir bahwa mungkin itu seharusnya menampilkan file yang sebelumnya terbuka di editor yang sama) dan bahwa menghaluskan tepi kasar ini akan membantu menciptakan pengalaman yang jauh lebih baik.

Kami melakukan studi UX pada produk secara sangat teratur. Faktanya, itulah cara kami mendesain banyak UX dalam produk. Kami mengulangi desain kami berdasarkan umpan balik nyata untuk memastikan bahwa kami menggunakan pemahaman yang baik tentang apa yang orang lakukan dan ingin lakukan dengan produk untuk menginformasikan desain kami.

Jika Anda ingin berpartisipasi dalam studi ini di masa mendatang (kami tidak akan menjalankan studi lagi hingga pertengahan Januari paling cepat) beri tahu saya dan saya akan menambahkan nama Anda ke daftar.

Jika Anda ingin berpartisipasi dalam studi ini di masa mendatang (kami tidak akan menjalankan studi lagi hingga pertengahan Januari paling cepat) beri tahu saya dan saya akan menambahkan nama Anda ke daftar.

Daftarkan aku!

Menurut saya tab bukanlah cara yang baik untuk menampilkan daftar file yang terbuka kecuali Anda mengelola hal-hal ini secara aktif dan menutupnya.

Manajemen tab adalah bagian yang tidak disadari dan tidak menghalangi perkembangan saya. VS-proper memiliki tab kecil yang tersembunyi, yang tidak mengganggu (vscode sudah memiliki nama file yang mengambil ruang di mana tab itu seharusnya). Saya setuju bahwa spam tab pelarian adalah masalah, mungkin bagus untuk berinovasi dan mengatasi hal ini, tetapi menurut saya itu prioritas yang lebih rendah daripada memiliki tab sama sekali. VSCode perlu mencapai status kerja minimum. Saat ini, saya merasa sudah sangat dekat, tetapi saya belum bisa bekerja secara produktif. Memulai dengan pola yang sudah mapan mungkin akan membuat kita bekerja lebih cepat.

Perlu diingat bahwa tidak semua orang adalah pengembang web, saya menemukan bahwa pola dan alur kerja cenderung sedikit berbeda untuk bahasa dan gaya aplikasi yang berbeda. Sebagai pengembang asli, biasanya satu set file terkait terlihat; cpp + h , mungkin juga inl , dan Anda biasanya tidak bekerja hanya pada satu file secara terpisah. Saya sering memiliki tampilan pembongkaran yang terlihat di sebelah kode. Lingkungan editor saya mencakup 2 monitor, dengan 4 file terlihat pada waktu tertentu, dan saya akan berjuang untuk bekerja di lingkungan yang lebih ketat daripada itu.
Saya juga rindu bisa mengambil tab dan merobeknya menjadi jendela mengambang kecil, yang sering saya atur ke 'selalu di atas', yang umumnya menggunakan titik referensi, atau sesuatu yang sering saya salin / pasing ke / dari.

Saat ini misalnya, saya mencoba memfaktor ulang dan menyederhanakan beberapa kode lama; kumpulan file saya saat ini adalah ... component.cpp, component.h, component.inl, componentimpl.cpp, componentimpl.h, icomponent.h. Itu 6 file! Dan saya tidak bisa lepas dari sesekali tweak dari beberapa file lain di pinggiran. Saya menggunakan ctrl-tab secara bebas ketika saya mengerjakan gaya proyek itu (membalik di antara 2 file), tetapi dalam konteks / basis kode ini, saya tidak dapat bekerja tanpa tab.

Memfaktorkan ulang dan memelihara kode lama memiliki alur kerja yang sangat berbeda dari menulis kode baru (yang saya bayangkan sedang Anda lakukan, dan sebagian besar digunakan sebagai pedoman untuk desain UX).

Maksud saya di sini adalah; ada keinginan modern untuk menemukan kembali segalanya, dan kami telah melihat kemajuan besar dalam desain UX dalam beberapa tahun terakhir; vscode sudah menyajikan beberapa di antaranya, tetapi berhati-hatilah dan terapkan penilaian yang baik saat memutuskan untuk mengubah cara orang bekerja selama beberapa dekade. Banyak desain yang mapan didirikan karena bagus dan efisien, bukan karena sudah tua dan perlu diperbarui agar lebih trendi :)

Saya sangat menghargai kesempatan untuk menjadi bagian dari studi fokus ini!

Maksud saya di sini adalah; ada keinginan modern untuk menemukan kembali segalanya, dan kami telah melihat kemajuan besar dalam desain UX dalam beberapa tahun terakhir; vscode sudah menyajikan beberapa di antaranya, tetapi berhati-hatilah dan terapkan penilaian yang baik saat memutuskan untuk mengubah cara orang bekerja selama beberapa dekade.

Ini kasus saya. Sebenarnya saya tidak bisa bekerja tanpa tab. Saya bekerja dengan sistem tab sejak bertahun-tahun, dan tanpa mereka, saya benar-benar tersesat. Ini adalah salah satu alasan saya tidak menggunakan Kode sebenarnya.

Banyak desain yang mapan didirikan karena bagus dan efisien, bukan karena sudah tua dan perlu diperbarui agar lebih trendi :)

: +1:

Sejauh ini saya belum mendengar alasan yang baik untuk tab dibandingkan dengan hanya memiliki daftar "file yang berfungsi" di suatu tempat. Mampu mengambil file dan menyeretnya ke jendela baru jelas bukan merupakan keuntungan dari sistem tab, ini adalah fitur yang dapat Anda miliki tanpa tab.

Apakah orang benar-benar ingin membuka file di tab, memindahkannya, dan akhirnya menutupnya? Apakah ini karena Anda sudah terbiasa dengannya atau apakah benar-benar ada manfaatnya? Apakah nilai dapat menyetel kumpulan file kerja aktif yang nanti Anda tutup untuk memulai sesuatu yang baru? Saya bertanya-tanya apa yang begitu baik memiliki tab yang tidak dapat Anda capai dengan cara representasi yang lain. Dan saya tidak menerima argumen bahwa setiap orang terbiasa dengan tab :). Banyak orang yang terbiasa menyimpan file dan masih ada editor dengan kemampuan simpan otomatis dan orang-orang sepertinya menyukainya.

Bahkan jika tidak secara default, memberi pengguna pilihan untuk mengaktifkan fitur tab melalui beberapa opsi akan hampir sama baiknya untuk saya.

Misalnya, bagaimana dengan membiarkan pengguna memindahkan / menyeret bagian "File yang berfungsi" ke atas (mengonversinya menjadi tab, katakanlah). Sekali lagi, pengguna dapat memilih bagaimana dia ingin bekerja dan menurut saya itu bagus!

Bagi saya, bukan penampilan tab melainkan perilaku mereka yang saya lewatkan. (Misalnya, Anda bisa membuat Sublime Text terlihat seperti VS Code di mana Anda dapat menyembunyikan tab bar dan menampilkan file yang terbuka di sidebar sebagai gantinya ... tetapi mereka masih berperilaku persis seperti tab.)

Hal pertama yang saya lakukan dengan VS Code adalah menukar file close-nya dan menutup pintasan keyboard editor aktif, sehingga ctrl + W benar-benar menutup file ketika saya menekannya, daripada tetap membiarkannya dalam file yang berfungsi dan mengacaukan ctrl + tab.

Namun demikian, setiap kali saya menutup file, saya disambut dengan layar kosong dan harus menekan tab ctrl + hanya untuk menampilkan file kerja yang masih terbuka (heck, saat itu yang terakhir, saya sepertinya juga perlu tekan enter setelah ctrl + tab; tidak yakin tentang apa itu). Di editor lain, saya akan langsung disambut oleh file (tab) yang terbaru atau yang berdekatan saat menutup yang sekarang.

Selain itu, ctrl + tab antara file yang berfungsi tampaknya berfungsi dalam urutan terbaru, berbeda dengan tab yang biasanya beroperasi sesuai urutan kemunculan atau susunannya. (Saya telah melihat beberapa editor mendukung keduanya.)

Saya tidak menggunakan jendela terpisah, jadi jika salah satu dari perbedaan perilaku ini ada hubungannya dengan itu, itu hilang pada saya. Mungkin aku akan memahaminya lebih baik jika aku memahaminya dari sudut itu, tetapi bukankah no-split masih menjadi kasus penggunaan yang paling umum?

Bagaimanapun, friksi kecil tapi sering seperti ini yang menjauhkan saya dari VS Code dan kembali ke editor lain. Ya, Anda dapat mengatakan bahwa VS Code beroperasi secara berbeda dari biasanya. Tetapi ketika apa yang saya gunakan untuk _works_, dan VS Code beroperasi secara berbeda menyebabkan gesekan yang sebaiknya saya gunakan editor yang berbeda untuk menghindari keharusan berurusan, itu semacam masalah besar.

Ya, saya dapat melihat model di mana area editor berperilaku mirip dengan tab tanpa menampilkan tab. Kami ingin mengeksplorasi tahun depan.

Btw ada ekstensi yang - setelah Anda menutup editor - membuka yang berikutnya dari file yang berfungsi. Jika Anda menggabungkannya dengan mengubah pengikatan kunci seperti yang disarankan

Ini tautannya: https://marketplace.visualstudio.com/items/bigous.file-smart-reopener-vscode

Sejauh ini saya belum mendengar alasan yang baik untuk tab dibandingkan dengan hanya memiliki daftar "file yang berfungsi" di suatu tempat. Mampu mengambil file dan menyeretnya ke jendela baru jelas bukan merupakan keuntungan dari sistem tab, ini adalah fitur yang dapat Anda miliki tanpa tab.

Tentu, itu mungkin untuk melakukannya dengan cara yang berbeda ... tapi mengapa? Kecuali jika Anda memiliki beberapa peningkatan atau inovasi yang signifikan untuk ditawarkan.

Apakah orang benar-benar ingin membuka file di tab, memindahkannya, dan akhirnya menutupnya?

Iya

Apakah ini karena Anda sudah terbiasa dengannya atau apakah benar-benar ada manfaatnya?

Sebagian karena kebiasaan, tetapi juga karena belum ada yang menyajikan sesuatu yang lebih unggul secara signifikan. Inovasi harus memberikan keuntungan yang signifikan jika itu akan memaksa orang untuk melawan dan melatih kembali kebiasaan lama mereka selama puluhan tahun.

Apakah nilai dapat menyetel kumpulan file kerja aktif yang nanti Anda tutup untuk memulai sesuatu yang baru?

Saya tidak begitu yakin saya memahami kalimat ini dengan tepat; apakah Anda mencoba menjelaskan alternatif di mana Anda bekerja pada istilah-istilah dari beberapa set 'file kerja'? Sulit dibayangkan. Saya tidak yakin itu akan berguna secara universal. Untuk tugas warisan, pemeliharaan, dan faktor ulang, saya pikir akan sangat merugikan untuk bekerja dengan cara ini, karena set kerja Anda biasanya tidak diketahui sebelumnya, melainkan muncul saat Anda bekerja. Model tradisional sudah berfungsi dengan baik dalam alur kerja ini.

Saya bertanya-tanya apa yang begitu baik memiliki tab yang tidak dapat Anda capai dengan cara representasi yang lain.

Dari perspektif yang berbeda; pertimbangkan pemanfaatan ruang. Ada _sudah ada_ tab di bagian atas jendela kode, di situlah nama file berada, hanya saja tidak ada persegi panjang tab di sekitar namanya (bahkan berperilaku seperti tab; jika Anda klik tengah, itu tertutup!). Di sebelah kanan nama file di atas jendela kode saat ini ada ruang kosong yang terbuang (di mana tab harus).
Di kiri atas ruang kerja adalah daftar 'file kerja'; ini adalah dua kali lipat ruang yang terbuang karena tidak perlu ada, ruangnya dapat dipindahkan ke celah di mana tab biasanya berada, mengisi ruang yang terbuang itu.

Saya juga menemukan perbedaan praktis lebih jauh daripada pemanfaatan ruang dan kecenderungan kebiasaan; Saya ingin memiliki tab yang terkait dengan jendela editor tempat mereka terikat. Saya biasanya memiliki setidaknya 2, 3, seringkali 4 jendela kode terbuka (dalam vs-proper), dan masing-masing memiliki beberapa tab yang terkait. Mungkin di satu jendela saya punya widget.cpp/.h , dan di jendela lain saya punya gizmo.cpp/.h/.inl . Tab ini secara logis terkait dengan jendela kode yang dilampirkan, dan menurut saya itu menyenangkan.

Dan saya tidak menerima argumen bahwa setiap orang terbiasa dengan tab :). Banyak orang yang terbiasa menyimpan file dan masih ada editor dengan kemampuan simpan otomatis dan orang-orang sepertinya menyukainya.

Terima atau tidak, orang menganggapnya sebagai argumen yang masuk akal dan kuat. Tapi saya akan menyimpan penilaian saya jika Anda memiliki sesuatu yang jauh lebih baik dalam pikiran. Dengan segala cara, jika Anda berpikir Anda dapat memperbaiki tab secara bermakna, cobalah, tetapi jangan memaksakannya karena inovasi 'trendi' saja;) .. Perlu lebih unggul secara substansial untuk mengeluarkan status quot .

Saya hanya dapat mengatakan bahwa daftar 'file kerja' saat ini pasti tidak lebih baik. Ini pada dasarnya adalah tab, hanya diatur secara vertikal, kecuali dengan kerugian bahwa tab terlepas dari jendela editor, mereka terikat, dan daftarnya tinggal di ruang yang terbuang sementara lokasi tab yang biasa kosong.
Saya juga tidak suka bahwa daftar 'file yang berfungsi' memiliki ketinggian dinamis, yang berarti pohon proyek bergerak secara vertikal, dan saya kira saya akan kurang menyukainya jika 'file yang berfungsi' memiliki tinggi tetap dan bilah gulir vertikal sebagai gantinya.

Hanya saja tidak lebih unggul dari tab biasa, dan karena itu tidak menawarkan alasan kuat untuk beradaptasi ... menurut saya :)

+1 @TurkeyMan

Di tim VS Code, kami telah bekerja tanpa tab dan tanpa file kerja sejak awal (4 tahun) dan kami tidak melewatkan apa pun. Jadi, secara pribadi saya setuju bahwa bagian file kerja adalah ruang yang terbuang dan saya membiarkan bagian itu ditutup. Namun, kami juga bekerja dengan penyimpanan otomatis diaktifkan dan biasanya tidak peduli dengan file kotor. File kerja diperkenalkan terutama untuk memberi file yang kotor dan tidak memiliki judul tempat untuk ditampilkan. Kemudian kami memutuskan bahwa itu juga merupakan tempat yang berguna untuk membantu orang-orang yang kehilangan tab tradisional karena merupakan representasi yang mirip, hanya dengan cara UI lainnya.

Kami menyediakan ruang di atas editor untuk menampilkan informasi file dan tindakan. Orang dapat berargumen bahwa ruang ini adalah ruang yang sama yang dibutuhkan untuk tab. Tetapi argumen saya terhadap tab adalah, biasanya ruang horizontal tidak cukup untuk menampilkan daftar file yang berfungsi karena Anda dengan cepat berakhir dengan ini:

Ini adalah mimpi buruk yang kami coba cegah: Anda perlu menggulir ke kiri dan kanan melalui daftar tab untuk menemukan file yang Anda inginkan. Tab hanya berfungsi dengan baik selama Anda tidak memiliki lebih banyak tab yang terbuka daripada yang dapat ditampilkan secara horizontal. Setelah tab menjadi cukup kecil sehingga nama file disembunyikan, Anda harus mulai menutup tab lain hanya untuk melihat apa yang sedang terjadi.

Sekarang, file kerja jelas memiliki masalah serupa, hanya di dimensi lain. Itulah mengapa kami dalam tim biasanya hanya menggunakan Ctrl+Tab untuk semuanya dan tidak peduli tentang apa yang dibuka atau tidak.

Untuk meringkas: file yang berfungsi bukanlah jawaban kami untuk mengganti tab, ini lebih merupakan kombinasi dari file yang berfungsi dan Ctrl+Tab . Dan tim kami kurang lebih 100% hanya menggunakan Ctrl+Tab dan tidak ada yang lain.

Gambar Anda tampaknya membesar-besarkan masalah secara tidak perlu; jendela sempit yang tidak realistis, tepi tab diagonal, terlalu banyak teks di tab, titik di sebelah kanan;)
vs-proper memaku tab dengan indah, dan tidak ada alasan untuk tidak menggulung dengan tab kecil yang tersembunyi seperti itu.

Saya adalah pengguna Ctrl-Tab yang sangat liberal saat itu berlaku, tetapi Anda tidak dapat menggunakan Ctrl-Tab kecuali Anda secara aktif mengedit tidak lebih dari 2 atau 3 file.
Saya memiliki kecurigaan bahwa pendapat Anda tentang masalah ini mungkin cukup bias terhadap proyek khusus Anda, dan itu mungkin termasuk bias bahasa. Dalam C / C ++, jumlah file yang berfungsi biasanya digandakan atau tiga kali lipat ketika Anda menerima ada .h , dan dalam kasus saya, seringkali .inl melengkapi setiap .cpp . Ctrl-Tab kurang efektif dalam skenario ini, dan Anda cenderung menggunakan Ctrl- ~ sebagai gantinya (beralih cpp / h; yang juga telah saya kirimkan permintaan fitur), sehubungan dengan manajemen tab.
Atau pertimbangkan Java, di mana setiap kelas - tidak peduli seberapa kecil - diharuskan untuk tinggal di filenya sendiri.

Dalam hari-hari saya saat ini, saya sering memiliki kumpulan file 10-an yang berfungsi, Ctrl-Tab tidak berguna bagi saya ketika saya bekerja dengan cara ini. Alur kerja paling praktis adalah 2-4 jendela editor, dan beberapa tab per jendela. Saya tidak memilih tata letak ini karena saya menyukainya; itu muncul begitu saja, karena ini adalah tata letak ruang kerja yang paling efisien untuk pekerjaan khusus ini.

+1
Saya biasanya meminta editor membagi dan menutup tab sedikit lebih intuitif daripada memiliki 10+ file yang berfungsi.

Saya juga biasanya hanya mengerjakan subset file dan ingin menyimpannya berguna. 5/5 lebih mudah dikelola daripada daftar 10 untuk saya pribadi. Saya juga aktif bergerak di antara mereka terus menerus. Tab juga membantu karena terdapat indikasi visual bahwa Anda membuka terlalu banyak - 'tab neraka' yang ditunjukkan oleh @bpasero.

Saya menerima bahwa tab tidak selalu merupakan cawan suci dari manajemen jendela. Namun, untuk bahasa atau proyek di mana beberapa set file akan dikerjakan, tab akan lebih mudah dikelola.

Contoh sederhananya adalah .cpp dan '.h' dengan tab akan menjadi dua klik yang difokuskan di bagian atas jendela sedangkan dengan file yang berfungsi akan menjadi 3-4 klik dengan file yang berfungsi yang mengharuskan Anda untuk memilih editor yang dimaksud dan kemudian pilih file baru untuk diedit.

Tab dan tab khusus juga memungkinkan beberapa ekstensi menarik ditambahkan dengan lebih mudah. Contohnya adalah konsol atau tab plot. Ini akan membutuhkan entri khusus di bagian pemilih file atau harus dibuang saat dekat dengan sistem saat ini. Saya secara teratur kembali ke plot saya sehingga menutup jendela akan mengharuskannya untuk plot ulang. Atau konsol akan ditutup dan data di dalamnya hilang.

Namun, jika alternatif yang cocok tersedia maka saya akan dengan senang hati mengujinya. Saya hanya merasa real estat horizontal pada layar saat ini lebih besar daripada real estat vertikal yang tidak dimanfaatkan oleh desain manajemen jendela saat ini. Meskipun saya tidak akan suka jika tab lebih besar secara vertikal daripada nama saat ini di setiap jendela.

Saya ingin tahu mengapa ada begitu banyak tekanan dalam mengimplementasikan tab. Secara teknis ini tidak sulit dan sudah ada file kerja yang diimplementasikan; mengapa tidak keduanya dan biarkan pengguna memutuskan?

Ini terdengar hampir seperti spasi v. Tab, 2.0

Saya ingin tahu mengapa ada begitu banyak tekanan dalam mengimplementasikan tab. Secara teknis ini tidak sulit dan sudah ada file kerja yang diimplementasikan; mengapa tidak keduanya dan biarkan pengguna memutuskan?

Ini terdengar hampir seperti spasi v. Tab, 2.0

Sepenuhnya setuju, mungkin jauh lebih mudah untuk mendorong fitur sebagai opsi (default mati jika itu membuat orang anti-tab senang), dan melacak penggunaan melalui statistik / umpan balik daripada berteori tanpa henti, apakah itu masuk akal atau tidak.

Saya menyadari sepertinya kita telah berteori tanpa henti tentang ini daripada benar-benar melakukan sesuatu dan meminta maaf untuk itu. Namun, kami memiliki item untuk mengatasi ini di backlog kami (direferensikan di atas - # 1133). Kami hanya belum dapat menghabiskan banyak waktu untuk ini baru-baru ini karena kami telah bekerja keras untuk pelokalan dan aksesibilitas.

Seperti yang saya sebutkan di atas, kami menyadari masalah dengan pengalaman saat ini untuk mengelola file dan memiliki sejumlah perubahan yang ingin kami lakukan untuk meningkatkan pengalaman.

Salah satu tujuan kami dengan VS Code adalah saat kami membuat perubahan pada UI dan UX, kami memastikan bahwa VS Code tetap menjadi editor yang ringan dan kuat yang memungkinkan pengguna untuk fokus pada kode mereka. Salah satu cara kami mencoba untuk mencapai ini adalah dengan sangat berhati-hati dengan UI baru yang kami tambahkan ke produk.

Perhatian kami dengan menambahkan tab adalah hal itu memperkenalkan serangkaian masalah lain yang akhirnya mengharuskan pengguna untuk fokus pada UI alih-alih kodenya. Pengalaman kami dengan Visual Studio misalnya telah menunjukkan kepada kami bahwa banyak pengguna sering berakhir dengan banyak tab terbuka yang berisi file yang tidak lagi mereka perlukan dan akhirnya mengacaukan ruang kerja mereka. Ini menyebabkan beberapa masalah saat pengguna mencari file dan aset kode lainnya. Untuk mengatasi masalah tersebut diperlukan lebih banyak UI yang memungkinkan orang untuk menutup semua tab, menutup semua tab kecuali tab ini, kontrol tab overflow, dll. Kami ingin menghindari situasi ini dan berharap desain yang sedang kami kerjakan akan membantu kami mencapai hal ini.

Ini bukanlah debat ideologis - kami benar-benar berusaha mempertahankan estetika minimal yang kami yakini memberikan pengalaman yang ringan dan kuat. Kami hanya sangat berhati-hati dalam memperkenalkan UI dan UX baru ke dalam produk.

Sangat mungkin bahwa setelah beberapa putaran desain dan penelitian tentang ini, kami akhirnya memperkenalkan tab. Namun kami hanya akan melakukannya dengan pengetahuan bahwa ini adalah cara terbaik untuk meningkatkan cara pengguna mengelola file dan aset tempat mereka bekerja, tetapi tidak berakhir dengan mengacaukan UI.

Saya harap ini membantu menjelaskan pandangan kami tentang ini. Dan saya minta maaf lagi karena membuatnya terlihat seperti sedang memandangi pusar dan tidak melakukan apa-apa tentang ini.

Terima kasih @stevencl , ada baiknya setidaknya ada di radar dan ada beberapa curah pendapat yang sedang berlangsung.

Perhatian kami dengan menambahkan tab adalah hal itu memperkenalkan serangkaian masalah lain yang akhirnya mengharuskan pengguna untuk fokus pada UI alih-alih kodenya.

Saya merasa seperti saya perlu fokus pada UI daripada kode sekarang, jadi argumen ini memotong dua arah. :)

banyak pengguna sering kali berakhir dengan banyak tab terbuka berisi file yang tidak lagi mereka perlukan

Sangat menarik Anda mengatakan ini, karena saya mendapat kesan bahwa bagian dari fungsi file _was_ untuk mendorong lebih banyak file tetap terbuka sekaligus. Apa yang Anda jelaskan di sini cenderung terjadi dengan file yang berfungsi juga, setidaknya dengan keybindings default (dan itulah mengapa saya bermain dengan mengganti keybindings untuk menutup editor aktif dan menutup file yang berfungsi sepenuhnya).

Ketika datang ke sana, jika VS berhasil secara opsional mereplikasi _behavior_ tab (yang sepertinya setidaknya salah satu hal di # 1133 terkait) sambil tetap menyimpannya di samping, itu mungkin awal yang cukup baik . Perintah Ctrl + tab menjadi MRU vs. urutan tampilan adalah hal lain (Sublime memungkinkan keduanya melalui perintah yang dapat diikat berbeda).

@stevencl , terima kasih atas tanggapan Anda. Saya ingin mengomentari beberapa poin Anda:

[...] kami menyadari masalah dengan pengalaman saat ini untuk mengelola file dan memiliki sejumlah perubahan yang ingin kami lakukan untuk meningkatkan pengalaman.

Saya pasti menantikan apa yang tampaknya menjadi masa depan yang sangat cerah untuk VS Code. Saya sangat senang ketika saya mendengar Microsoft membawa IDE yang kuat seperti Visual Studio ke dunia di luar Windows, dan untuk merangkul paradigma baru pengembangan aplikasi dengan Electron. Kudos untuk pekerjaan Anda sampai saat ini!

Salah satu tujuan kami dengan VS Code adalah saat kami membuat perubahan pada UI dan UX, kami memastikan bahwa VS Code tetap menjadi editor yang ringan dan kuat yang memungkinkan pengguna untuk fokus pada kode mereka.

Saya rasa tidak ada orang yang dapat memberikan argumen yang meyakinkan untuk tab yang membuat antarmuka lemah, lamban atau mengganggu. Nyatanya, ada lebih banyak ruang horizontal untuk tab daripada ruang vertikal di atas tampilan pohon proyek. Memiliki file yang berfungsi di sana, bagi saya, membuat bagian kiri jendela terlihat jauh lebih berantakan daripada yang seharusnya.

Perhatian kami dengan menambahkan tab adalah hal itu memperkenalkan serangkaian masalah lain yang akhirnya mengharuskan pengguna untuk fokus pada UI alih-alih kodenya.

Apakah ada alasan untuk menggunakan apa pun selain TextEdit atau Notepad jika itu semua tentang fokus pada kode? Menetapkan fungsionalitas itu, untuk semua maksud dan tujuan, sama di sebagian besar editor, UI / X digunakan untuk mencapai fungsionalitas itu dan kualitasnya benar-benar di mana produk membedakan dirinya sendiri.

Pengalaman kami dengan Visual Studio misalnya telah menunjukkan kepada kami bahwa banyak pengguna sering berakhir dengan banyak tab terbuka yang berisi file yang tidak lagi mereka perlukan dan akhirnya mengacaukan ruang kerja mereka. Ini menyebabkan beberapa masalah saat pengguna mencari file dan aset kode lainnya.

Berikut adalah argumen yang menurut saya tidak penting untuk atau bertentangan dengan tab atau daftar file yang berfungsi; saat bekerja dengan lebih dari satu file, Anda harus selalu memutuskan fokus untuk mencari aset kode.

Meski begitu, daftar file kerja masih belum menyelesaikan masalah. Terlalu banyak file yang berfungsi menyebabkan daftar bergulir dan daftar tidak dapat diperluas. Jadi alih-alih akhirnya menggulir tab, Anda akan lebih cepat menggulir ke bawah daftar file yang berfungsi.

[...] kami benar-benar berusaha untuk mempertahankan estetika minimal yang kami yakini memberikan pengalaman yang ringan dan kuat. Kami hanya sangat berhati-hati dalam memperkenalkan UI dan UX baru ke dalam produk.

Saya dapat menghargai dan mendukung pendirian ini sampai taraf tertentu. Ketika komunitas mengangkat suaranya, Anda harus mulai berbicara tentang adopsi pengguna. Bukankah itu sebabnya Anda menempatkan kurangnya pelipatan VS Code sebagai perhatian adopsi pengguna dalam peta jalan Anda untuk bulan Maret? Beberapa hal memang demikian adanya dan untuk alasan yang baik. Start Menu di Windows dan dok di OSX muncul dalam pikiran.

[...] Sekali lagi saya minta maaf karena membuatnya terlihat seperti sedang memandangi pusar dan tidak melakukan apa-apa.

Itu jelas bukan pendapat saya, jadi jangan khawatir. Untuk alasan yang sudah saya nyatakan, percakapan yang sehat tentang ini tentu saja hanya dapat meningkatkan tujuan yang lebih besar yaitu UI / X VS Code.

Saya juga ingin ikut campur dan hanya mengatakan bahwa saya pikir saya tidak merasa "menatap pusar" sama sekali. Waktu untuk masalah ini sebagian salah - 19 November tidak memberikan waktu untuk meletakkannya di mana pun di bulan Desember dan mungkin Januari tergantung pada seberapa jauh hal-hal yang direncanakan ke depan. Juga - percakapan yang telah dimulai lagi ini lebih penting daripada sekadar menerapkan tab secara acak karena pengguna menginginkannya.

Saya harus setuju dengan ianwesterfield karena antarmuka file yang berfungsi tidak ideal dan ada lebih banyak ruang horizontal daripada ruang vertikal. Daftar file besar-besaran dan banyak file yang dialihkan adalah kelemahan vscode saat ini dalam hal mengelola file yang berfungsi.
Ketika Anda mulai melompati sekitar 16 file yang berbeda, maka dapat mengelola editor terpisah mana yang menjadi miliknya adalah file yang berfungsi akan sulit untuk mengalahkan tab. Oleh karena itu, membagi daftar file yang berfungsi menjadi dua bagian yang berbeda akan menjadi solusi yang masuk akal.

Namun, stevencl membuat argumen yang membuat saya sangat senang. "Sangat mungkin bahwa setelah beberapa putaran desain dan penelitian tentang hal ini, kami akhirnya memperkenalkan tab. Namun kami hanya akan melakukannya dengan pengetahuan bahwa ini adalah cara terbaik untuk meningkatkan cara pengguna mengelola file dan aset tempat mereka bekerja. dengan, tetapi tidak berakhir dengan mengacaukan UI. " Dengan benar-benar mencoba hal-hal baru, perbaikan bisa datang.

Cara yang lebih mudah untuk mengelola jendela terbelah sudah menjadi perbaikan. Saya dapat membuat argumen untuk file kerja yang mengelola jendela SELALU dapat berada di lokasi yang sama. Mengelola tab lebih mudah saat Anda ingin mengatur ulang 2-4 pemisahan (layar resolusi tinggi + atom = pemisahan horizontal dan vertikal bila diperlukan). Jadi ada solusi yang memungkinkan yang membuat antarmuka file yang berfungsi tetapi memperluasnya menjadi sedikit lebih kompleks.

Terima kasih, saya menghargai kesempatan untuk melakukan percakapan ini.

@ianwesterfield , Anda benar tentang file yang berfungsi dan telah menyoroti salah satu masalah yang ingin kami disoroti oleh

Setelah mengerjakan desain Visual Studio selama beberapa tahun meskipun saya telah melihat masalah UX yang dapat disebabkan oleh tab. Saya menghabiskan 18 bulan mengerjakan pengalaman tab pratinjau di Visual Studio yang merupakan upaya untuk mengurangi masalah 'tab hell' yang dijelaskan @bpasero di atas.

Kami ingin mencoba menghindari posisi di mana hal ini menjadi perlu. Jadi kami ingin melanjutkan penyelaman mendalam desain kami untuk menemukan opsi yang tersedia bagi kami dan kemudian menetapkannya. Seperti yang saya katakan sebelumnya, mungkin saja kita berakhir dengan tab. Jika ya, kita akan tahu bahwa itulah pendekatan terbaik yang dapat kita buat yang akan memberikan pengalaman hebat dalam mengelola file dan aset kode lainnya.

Terima kasih atas semua wawasan dan deskripsi masalah yang Anda alami saat ini dengan cara kami mengelola file di VS Code.

@stevencl , Lucu sekali Anda harus menyebutkan tab pratinjau - Saya menyukainya. Sangat bagus bagaimana VS Code, Sublime, Atom, Brackets (melalui ekstensi), dll. Memiliki fitur pratinjau seperti ini secara default.

Saya sangat senang Microsoft telah memberi kami kesempatan untuk berpartisipasi dalam diskusi desain yang sedang berlangsung dengan tetap membuka proyek ini. Jika pengguna hanya memiliki suara itu selama mendesain ulang Start Menu, Windows mungkin tidak memerlukan siklus rilis lain untuk akhirnya mendapatkan posting on-boarding besar-besaran Windows 7.

Sangat mungkin bahwa setelah beberapa putaran desain dan penelitian tentang ini, kami akhirnya memperkenalkan tab. Namun kami hanya akan melakukannya dengan pengetahuan bahwa ini adalah cara terbaik untuk meningkatkan cara pengguna mengelola file dan aset tempat mereka bekerja, tetapi tidak berakhir dengan mengacaukan UI.

Sejak saya membuka terbitan ini, yang sepertinya muncul kembali, saya hanya ingin menambahkan bahwa menurut saya komentar ini cukup memuaskan. Saya agak curiga tab akan muncul, tetapi saya sepenuhnya mendukung eksplorasi ide-ide baru, dan kode adalah platform yang bagus untuk melakukan ini. Saya suka pekerjaan yang telah kalian lakukan sejauh ini.
Karena itu, perlu diingat bahwa kami ingin _menggunakan_ ini, dan semakin cepat saya dapat menggunakannya sebagai editor utama saya semakin baik, jadi saya akan sangat menghargai jika Anda dapat memberi kami pengalaman yang familier (masih ringan) yang kita dapat menggunakan secara produktif dan merasa seperti di rumah sekarang, dan kita dapat melanjutkan pekerjaan kita. Kemudian Anda dapat meluangkan waktu di dunia untuk menjelajahi cakrawala baru :)
Hanya saja kami dengan sabar menunggu kode untuk mencapai garis ajaib di mana kami dapat mengadopsinya secara penuh. Bagi saya, tab adalah satu-satunya keluhan kegunaan saya, kompilasi dan debugging asli adalah satu-satunya masalah teknis saya.

Saya tidak berpikir saya satu-satunya pengguna windows yang kelelahan dan menderita yang sangat kecanduan studio visual. Keselamatan hanyalah beberapa masalah kecil dan fitur di luar jangkauan kami, ini berkembang dengan cepat, dan saya bersyukur atas kesempatan untuk berpartisipasi dan menonton dengan visibilitas seperti itu.

Sayangnya, Windows tetap menjadi platform / ekosistem dev terburuk, dengan lingkungan dev terbaik, dan sudah seperti itu selama 15 tahun. Sangat aneh.
Saya tidak tahu mengapa, tetapi bagi saya, lingkungan dev (produktivitas) mengalahkan ekosistem dalam keseimbangan saya, tetapi ini adalah keseimbangan yang menyakitkan dan saya akan bahagia seperti babi di lumpur ketika saya dapat menggunakan VS di linux penuh -waktu! Kami sangat dekat!
Saya tahu kalian melihat ini sebagai kendaraan untuk menjelajahi wilayah baru, dan itu sangat keren, tetapi dalam jangka pendek, kami benar-benar hanya ingin VS di linux, (atau osx, jika Anda mengayun ke sana), seperti yang kami impikan untuk sebuah dekade atau lebih, dan akhirnya kita bisa, setelah bertahun-tahun, mengakhiri penderitaan kita! ;)
</dramatic_commentary>

TL; DR, penjelajahan benar-benar hebat dan saya yakin Anda berkomitmen pada produk akhir terbaik yang dapat Anda buat, tetapi solusi akrab yang aman untuk sementara mungkin?

1 untuk tab. Pertanyaannya- mengapa Anda tidak menghapusnya dari Visual Studio Bundle? Lihat apa yang terjadi kemudian ...

1 untuk tab! Harap terapkan ini di pembaruan mendatang.

Asumsi yang berjalan tampaknya bahwa "[tab] dalam banyak kasus tumbuh begitu banyak sehingga Anda akhirnya tidak melihat apa pun". Saya ingin menantang asumsi ini. Saya menggunakan tab sebagai indeks yang terlihat dari file yang saat ini saya minati, dan saya secara aktif mengelola indeks tersebut saat minat saya berubah seiring waktu. Visibilitas itu penting: Saya mengacu pada tab fisik secara konstan untuk mengubah orientasi diri. Dengan Working Files, saya kehilangan kemampuan saya untuk melihat dan memanipulasi indeks itu. Misalnya, tampaknya tidak ada cara untuk menghapus file dari Working Files melalui keyboard. Rasanya seperti melawan editor. Harap tambahkan tab Sublime Text-style.

Meskipun saya setuju VS Code berfungsi dengan baik tanpa tab sekarang (telah menggunakannya sejak awal dengan cukup produktif), saya juga setuju dengan beberapa komentar di atas yang menyarankan memiliki tab sebagai opsi (mungkin dinonaktifkan secara default) dan membiarkan pengguna memutuskan apakah mereka menginginkannya atau tidak.

Setiap orang berbeda jadi memiliki pilihan di sana akan sangat bagus. Meskipun saya dapat bekerja dengan baik tanpa mereka, saya tidak keberatan menambahkannya dan mungkin akan menggunakannya beberapa - bertahun-tahun menggunakan VS penuh. Sepertinya mereka sudah ada di backlog - terima kasih!

1 untuk tab. Hampir 1 tahun bekerja dengan VSCode dan saya sangat menyukainya. Tetapi masih kehilangan tab, terutama saat bekerja dengan debug atau pencarian, atau bagian kiri git. Tab membantu untuk tidak memikirkan file mana yang berisi kode, yang telah Anda kerjakan sebelumnya. Saya yakin pengguna mengelola tab dan urutannya untuk diingat juga posisi tab, yang dapat dikaitkan dengan kode sumber tempat mereka bekerja. Tab editor yang terpisah juga dapat mempertahankan maksud ini.

Ctrl + tab adalah aksi kunci, dan tab adalah aksi visual, yang Jauh Lebih Cepat.

Saya mungkin bisa hidup tanpa tab ... jika VS tidak terlalu buruk dalam mengelola "file yang berfungsi". Saya sangat sering membuka file hanya untuk merujuk ke dalamnya, tanpa benar-benar mengeditnya, tetapi VS tidak menempatkan file tersebut dalam daftar file kerja saya, sedangkan saya pasti akan membuka tab di lingkungan tab.

Hal ini dikombinasikan dengan fakta bahwa ketika Anda menutup file / memfokuskan yang baru "berfungsi", file explorer BERGERAK ke file yang terbuka alih-alih tetap di lokasi terakhir Anda membuat pengalaman yang sangat membingungkan.

Saya memahami bahwa itu bukan masalah bagi Anda karena "Anda telah menggunakannya tanpa tab selama 4 tahun", jadi apa pun yang berada di luar cakupan Ctrl + Tab dipandang sebagai cara aneh dalam menggunakan program ini.

Ini harus berupa fitur dan apakah aktif atau tidak aktif secara default tidak relevan. Hampir setiap editor teks / IDE menggunakan tab untuk navigasi. Mungkin beberapa orang merasa bahwa ada cara yang lebih baik tetapi bagi kebanyakan dari kita tab itu efisien, mudah digunakan dan familiar ... dan jelas kita menyukainya! Keluarkan dari Visual Studio untuk satu rilis untuk melihat betapa pentingnya mereka ... (isyarat kehancuran pengembang epik bergaya Metro) Harap pertimbangkan tab untuk rilis jangka pendek. itu satu-satunya hal yang menahan banyak dari kita kembali dari adopsi penuh waktu VSCode.

: +1:

Saya jauh lebih produktif dengan tab! Saya menggunakan Atom karena saya menggunakan Google Chrome (Ctrl + 1 untuk tab pertama, Ctrl + 5 dll. Ctrl + Tab, Ctrl + Shift + tab).

Mengerjakan file membuat saya kurang produktif dan saya selalu merasa sedikit frustrasi setelah menggunakannya.

Jadi tolong, terapkan tab.

Tab akan sangat berguna, +1

: +1:

@MadSpindel "File yang

Visual Studio Power Tools memiliki opsi untuk menampilkan tab secara vertikal, yang sangat saya sukai.

: +1: dan saya setuju dengan @sitefinitysteve. Jika tim bersikeras untuk tidak memiliki tab, maka paling tidak tingkatkan API ekstensi agar dapat ditambahkan oleh pihak ketiga.

Di sinilah pentingnya tab - kita harus mundur sejenak ke fitur lain yang hilang:

VSCode perlu membuang implementasi non-informasional dari File Kerja, dan kemudian menambahkan fitur untuk memungkinkan pembukaan beberapa proyek. Saya melakukan pekerjaan saya dengan memisahkan kode sisi klien saya menjadi satu proyek dan kode sisi server saya menjadi proyek lain. Pada layar besar saya ingin dua jendela pengkodean terbuka, dengan satu pohon proyek di paling kiri. Kode klien di jendela kiri, kode server di jendela kanan. Sekarang, dalam salah satu proyek saya akan mengerjakan banyak file sumber. Dalam kasus-kasus tersebut saya ingin mereferensikannya sebagai tab di atas jendela proyek masing-masing tempat mereka dibuka. Saya mungkin memiliki 3 atau 4 tab pada proyek sisi klien dan 3 atau lebih tab pada proyek sisi server.

Organisasi itu organik. Seluruh pohon kerja, banyak proyek, ditampilkan di sebelah kiri. Saya memiliki pemisahan proyek dengan jendela kode dan saya juga memiliki file sumber terbuka yang sedang dikerjakan, atau dirujuk, oleh tab di atas jendela proyek masing-masing.

Ini adalah alur kerja penting bagi saya. Saat ini saya melakukan hal ini di Atom tapi saya suka VSCode dan ingin melihat aliran itu direplikasi di VSCode. Untuk melakukannya, VSCode perlu mengimplementasikan beberapa dukungan proyek dan tab di atas jendela masing-masing. Kalau tidak, itu hanya editor orang kecil, dan saya tidak percaya itu. Silahkan.

@riclf sudah tepat.

Saya biasanya memiliki 3 kolom vertikal terbuka, HTML, JS dan CSS dari kiri ke kanan.

Di Sublime saya memiliki semua tab html saya di atas kolom pertama, semua file JS sebagai tab di atas kolom kedua, dll. Tab tersebut memiliki konteks dan saya tahu saya tidak akan membuka file yang salah di kolom yang salah.

Ini hampir tidak mungkin di VS Code, saya dapat membuka 3 kolom hanya dengan menggunakan "buka ke samping" dua kali, dan kolom dapat hilang sama sekali jika file ditutup, di mana saya dapat membuka yang baru tetapi harus menyusun ulang mereka. Jika saya membuka file, file akan terbuka kembali di kolom tempat kursor berada, jadi jika saya membuka file css, saya harus memastikan kursor saya ada di kolom ketiga. Ini benar-benar menyebalkan.

Belum lagi bagian Working files mengambil ruang vertikal di pohon folder saya, yang merupakan masalah nyata di laptop saya.

Pertanyaan untuk tim microsoft. Jika Anda memiliki tampilan terpisah, bagaimana cara mengetahui kolom mana yang terkait dengan file di "file kerja"? Ini sederhana ketika tab berada di atas kolomnya masing-masing.

Hanya 2c saya.

Saya tidak mengalami ketidaknyamanan kognitif saat membiasakan diri dengan Working Files. Saya lebih menyukainya daripada tab. UI VSCode berada di jalur yang benar. Saya tidak menentang tab opt-in, tetapi akan melempar fit pada tab opt-out.

File Kerja adalah tab dalam tata letak yang lebih baik (lebih banyak ruang gulir). Mereka kehilangan fitur "sobek" dan seret, yang dapat ditambahkan di masa mendatang.

Sebagai pengguna mvim, saya memiliki beberapa set file TDD yang terbuka, dan tab di antara mereka. Misalnya, I tes + sudut, tes + server, mentimun atau skrip + perilaku. Saya tidak ingin membuka tab untuk mengakses satu file, tetapi kombinasi dari file yang terbuka. Saya beralih ke VSCode selama 3 bulan untuk proyek Typecript, karena itu benar-benar memiliki dukungan Typecript terbaik di kelasnya / luar biasa. Namun, segera setelah saya pindah ke proyek non-Typecript, saya menemukan bahwa saya membandingkan kemampuan pencarian, navigasi, dan substitusi untuk keperluan umum secara langsung dengan mvim dan dengan menyesal saya katakan bahwa saya dengan cepat (yaitu, langsung) kembali ke editor saya sebelumnya. Saya memiliki layar Apple Cinema 27 "dan akan mendapatkan tampilan yang lebih besar jika memungkinkan. Saya memiliki banyak ruang untuk banyak tab dan dan pasangan file, dan tidak memiliki alasan kuat untuk dibatasi dalam menggunakan ruang itu oleh editor saya Saya tidak ingin berurusan dengan hanya satu file pada satu waktu - Saya ingin membuka banyak, dan melacak aliran dari tab ke tab.

Saya mencoba Visual Studio Code lagi dua minggu lalu. Saya benar-benar terkejut ketika hanya menyia-nyiakan beberapa file. Tetapi ketika saya mulai mengerjakan proyek (besar) aktual dengan lebih dari beberapa file yang dibuka, kurangnya tab menjadi sangat mengganggu. _Working Files_ tidak cocok untuk saya dan memperlambat saya. Setelah 3 hari saya sangat kesal sehingga saya kembali ke Sublime Text. Saya memiliki dua layar 24 "di tempat kerja (Windows), Mac 27" di rumah dan dapat dengan mudah membuka 20 tab dan masih dapat membedakan file mana. Dalam kasus saya, banyak ruang layar untuk tab. _You_ sudah menampilkan nama file dari file yang dibuka di editor. Semua ruang di sebelah kanan nama file tidak digunakan (kecuali untuk ikon di sebelah kanan jendela) dan dapat diisi dengan tab (yang juga dilakukan Sublime Text). Saya katakan memberi pengguna opsi untuk bekerja dengan _Working Files_ dan / atau tab file. Untuk saat ini, saya beralih kembali ke kombinasi Sublime Text dan Visual Studio Enterprise. Saat tab ditambahkan, saya akan mempertimbangkan kembali.

Untuk opsi Working Files , saya harus beralih bilah samping (karena saya menyembunyikannya untuk tampilan kode yang diperluas) untuk memilih file. Dan opsi Ctrl+P dan Ctrl+tab juga tidak ramah pengguna.

Saya tahu kalian mencoba sesuatu yang berbeda untuk itu, tetapi opsi yang sudah Anda berikan tidak ramah pengguna. Maaf.

berikan ekstensi untuk ini, sehingga pengguna memiliki kesempatan untuk menggunakan tab alih-alih dipaksa menggunakan daftar kerja. Saya sangat membenci fitur file yang berfungsi, itu menyebabkan saya berpindah file dengan lambat dan mencuri produktivitas saya

Ketika saya baru mengenal VS Code, saya sangat merindukan tab. Kemudian saya menemukan ctrl + tab dan saya tidak lagi membutuhkannya.

Saya telah mencoba membuat vscode (yang luar biasa di sebagian besar) editor utama saya selama beberapa bulan, tetapi kurangnya tab terus mengganggu saya dan mengganggu produktivitas saya (saya salah satu dari mereka yang secara aktif mengelola kumpulan tab terbuka di editor lain). Ctrl + tab bukanlah pengganti tab.

Jelas bahwa tim vscode memiliki bias terhadap hal ini, dan saat ini bertujuan untuk "meyakinkan" pengguna bahwa mereka tidak benar-benar membutuhkan tab. Tetapi ini adalah jenis pemikiran yang sama yang mengarah pada penghapusan menu Start dari Windows 8 (kita semua tahu bagaimana ini berakhir).

@pesho Persis!

Sekarang setelah melipat kode, ini adalah masalah teratas di User Voice. Kami menimbang sejumlah opsi secara internal saat kami terus menimbang umpan balik komunitas, pengujian pengalaman pengguna, dll. Terima kasih semua untuk diskusi di sini. Sangat membantu.

mungkin itu satu-satunya alasan mengapa saya membuka untuk pertama kalinya vscode hampir setahun yang lalu dan menutupnya setelah beberapa menit bermain. dan Anda masih tidak memiliki tab. Semoga segera muncul, jadi saya bisa menggunakannya. Open source-nya, dan orang-orang dari Microsoft perlu mengubah pikiran mereka (itulah yang sedang mereka lakukan sekarang, bukan?) Dan mendengarkan komunitas, bukan hanya "kami menggunakan alat ini secara internal dan kami tidak memerlukan tab bla bla"

@pleerock Anda bahkan tidak akan mencoba IDE karena tidak memiliki tab ?! (Oo) weeeweweweweeeww. Mereka tidak ingin menambahkan tab karena tab tidak ada gunanya, bertele-tele mereka umumnya tidak menambahkan nilai sambil menambahkan wieght atas pada ruang chromes windows. Alternatifnya memberikan lebih banyak metadata, kemudahan penggunaan dan navigasi yang lebih cepat.

Dengan tab saya memilih file mana yang tetap terbuka. Baik itu tab CTRL + atau "File yang berfungsi", jika saya membuka file untuk mencari beberapa kode ke dalamnya, beralih ke yang lain untuk menggunakan kode tersebut, saya tidak punya cara untuk kembali ke file pertama saya karena harus kembali arahkan ke file di explorer.

Saya tahu saya memiliki 3 editor, tetapi terkadang saya tidak ingin menimpa 2 editor lainnya dengan file hanya kode pencarian.

Jika ketika saya membuka file, file tersebut tetap berada di histori file yang berbeda, maka saya baik-baik saja tanpa tab. Mungkin jika file telah dibuka lebih dari 5 detik itu layak masuk di CTRL + Tab.

@ 4tron ya itu untuk saya, karena saya ingin menggunakan IDE yang nyaman bagi saya. bagi seseorang yang kehilangan tab tidak ada gunanya dan mengamankan ruang mereka (mungkin mereka menggunakan netbook dan tidak memiliki cukup ruang untuk piksel tambahan yang sangat sedikit =)), bagi orang lain itu nyaman dan meningkatkan produktivitas mereka. Setiap perangkat lunak yang baik harus dapat disesuaikan dan memiliki kemampuan untuk menyembunyikan / menampilkan panel. "menghemat tempat" tidak membantah. Perkenalkan tab + tambahkan kemampuan untuk menampilkan / menyembunyikannya (jika benar-benar dibutuhkan untuk seseorang =)) cara terbaik untuk melakukannya. Tidak perlu membuka Amerika baru atau melakukan inovasi yang salah, perlu belajar dari IDE terbaik di sini yang menjadikan UX selama bertahun-tahun lebih baik dan lebih baik, seperti intellij, studio visual, dan lainnya

Ini sangat sederhana - cukup jadikan Preferensi- tab atau tanpa tab. Saat tab aktif, tidak ada File yang Bekerja, saat Tab mati, File Bekerja. Itu Jenius! ;)

Saya, saya seorang pria tab. Saya menemukan Working Files sangat terbatas dan tidak intuitif, serta mengambil ruang vertikal di Project Tree. Tetapi tidak masalah jika kita tidak dapat memiliki lebih dari 1 Proyek yang terbuka. :(

Saya pikir preferensi juga harus baik-baik saja.

Saya juga memikirkan cara untuk meningkatkan sistem file yang berfungsi. Anda harus menggunakan garis tab sebagai historis.
Sebagai contoh, jika Anda membuka 4 file di jendela kiri, dan kemudian membuka file kelima yang membuat file terlama yang dimodifikasi dari baris tab, file tersebut akan menghilang dan kembali sebagai hanya "file yang dimodifikasi" di file kerja.

Anda juga dapat membuatnya cerdas, sistem juga dapat memprioritaskan penghapusan file yang disimpan terlebih dahulu dan file yang tidak dimodifikasi.

Faktanya adalah bahwa tab sangat praktis, bahkan jika tab membengkak adalah masalah. Anda harus memikirkan cara menggunakan tab tetapi membatasi jumlahnya.

Biasanya saya membuka tab yang belum saya edit selama berhari-hari. Ini biasanya yang membuatnya kembung.

+1

Saya memiliki layar 4K dan tidak memiliki tab untuk secara horizontal benar-benar mematikan saya dari VsCode

BTW, saya ingin mengklarifikasi bahwa saya tidak hanya ingin tab, saya ingin sekumpulan tab. Sebagai full stack mvim TDD developer di Mac, saya pikir dari segi konteks. html + css, tes + sudut, tes + node, ketimun + langkah tes. Saya biasanya bekerja dalam satu konteks untuk beberapa baris kode sebelum pindah ke konteks berikutnya, gaya TDD. Saat menggunakan mvim, saya tidak hanya beralih di antara konteks ini dengan sangat cepat (menggunakan urutan tombol yang sama yang saya gunakan untuk Terminal Mac, Mac Finder dan Safari atau Chrome), tetapi saya mendapatkan keuntungan dari makro yang secara otomatis membuka file yang dipasangkan, sehingga dari sebuah file sumber sudut, saya dapat secara otomatis membuka tes yang sesuai. Ini adalah cara yang sangat produktif untuk bekerja, dan menjaga jari saya tetap di atas keyboard.

Jika saya menemukan IDE yang memungkinkan saya untuk membuka file "terkait" dalam bingkai di samping satu sama lain, hanya dengan beralih satu tab, misalnya ketika saya membuka button.html, itu akan membuka button.js di sebelahnya dan button.scss di frame ketiga, saya tidak akan pernah menggunakan IDE lain lagi.

Aku tahu itu tidak akan pernah terjadi, tapi katakan saja.

Nah, kalau begitu, Anda harus menggunakan mvim! http://www.vim.org/scripts/script.php?script_id=1567 Perintah: AV membuka file terkait (A untuk yang terkait).

Apa yang dibicarakan @jtosey adalah apa yang ingin saya katakan di sini. Saya menggunakan panel untuk mengatur satu set file terkait. Sebagian besar manajemen tab melibatkan mendapatkan file terkait tersebut di samping satu sama lain ketika saya mengganti konteks.

+1

Sama di sini, pasti suka tab.

Saya baru saja beralih ke VSCode dari Atom dan memperhatikan betapa luar biasa terorganisir dan bersihnya setelah bekerja dengannya untuk sementara waktu. Alasannya? Tidak ada populasi tab yang berlebihan! Kurangnya tab yang sebenarnya membuat pengalaman ini begitu mulus. Navigasi file utama saya adalah menu perintah-P yang memungkinkan saya melompat cepat ke file apa pun.

Tab VS sempurna, harap bawa tab, melepas tab ke jendela terpisah juga bagus!
Terima kasih untuk vscode :)

Saya sebenarnya cukup penasaran apakah Anda ingin menjadikan VSC sebagai editor file tujuan umum, atau hanya editor kode sumber.

Ada beberapa situasi di mana bilah tab benar -

1. Beralih di antara banyak tab dengan cepat.
   Situasi umum bagi saya adalah saya perlu membandingkan 2 file atau lebih menurut bentuknya, seperti untuk membandingkan antara bahasa China yang disederhanakan dan padanan tradisionalnya. Perbedaan tidak akan menyelesaikan masalah karena mereka adalah karakter yang berbeda. Satu-satunya cara adalah dengan cepat beralih di antara tab untuk melihat apakah ada kata yang hilang dari bola mata Anda. Menggunakan ST dan saya dapat berpindah tab menggunakan Alt-NUM, tetapi di VSC satu-satunya cara yang mungkin adalah menggunakan beberapa Ctrl-Tab, atau mouse bergerak dan mengklik dengan cepat.
2. Nama file yang panjang dan sulit diketik.
   Menggunakan Ctrl-P untuk beralih antar file tidaklah buruk. Tetapi bagaimana dengan beberapa nama file yang memiliki perbaikan umum yang lama? Bagaimana dengan beberapa nama yang tidak dalam bahasa Inggris? Pertimbangkan berapa banyak waktu yang akan Anda habiskan pada Ctrl-P untuk beralih antara 青年急着买房的原因（上）.md dan 青年急着买房的原因（下）.md ?

Saya akan mengatakan, tidak ada situasi yang akan Anda hadapi saat menulis kode, tetapi sebagai editor tujuan umum, ini adalah masalah serius.

@ msg7086 Saya tidak yakin tentang poin satu tetapi untuk poin kedua tidak bisakah Anda ctrl + p dan kemudian ketik .md meninggalkan Anda dengan dua opsi dan kemudian hanya ctrl + tab untuk memilih yang Anda ingin? Tidak yakin saya memahami masalahnya dengan benar

@ 4tron Terima kasih atas jawabannya. Namun, metode Anda hanya berfungsi jika saya hanya memiliki 2 file dengan jenis itu. Pada kenyataannya, orang mungkin akan bekerja dengan banyak file tersebut dalam satu direktori. Imaging Saya sedang menulis blog yang memiliki 50 posting dalam format penurunan harga, dengan karakter yang berbeda dalam bahasa Cina atau Korea atau Arab dll sebagai nama file. Skenario sebenarnya yang saya pukul sebenarnya adalah beberapa file subtitle dengan nama CJK, di mana semuanya adalah *.ass , sehingga Ctrl + P dengan ekstensi tidak berfungsi dengan baik.

Sangat menghargai jika ini bisa dilaksanakan

Pengembang sudah terbiasa dengannya, jadikan ini prioritas .

1 untuk tab. Harap terapkan tab.

1 untuk tab!

Saya memilih untuk menambahkan tab juga.

+1

+1

+1

Kami membutuhkan tab ASAP.

Saya merindukan tab. Saya terus meraihnya, alangkah baiknya jika ref dua atau tiga dokumen terbuka yang berbeda dengan cepat.

Apa masalahnya?

• Area file yang berfungsi terkunci pada ketinggian, masalah yang sama seperti terlalu banyak tab, kecuali itu rumit untuk dikelola (tidak ada mouse atau roda gulir di sini). Tab dapat dibuang dengan mudah, memberikan pengguna dokumen berikutnya dalam tumpukan file yang terbuka.
• Kolom Penjelajah dalam Kode jauh lebih lebar daripada Sublimes, terkadang seseorang ingin meminimalkannya saat menjalankan dua aplikasi secara berdampingan untuk menghemat ruang (Unity di kiri, Kode di kanan misalnya). Tab tidak memerlukan penghematan ruang untuk bekerja, Kode sudah memiliki area kosong yang bagus untuk dituju.
• Tab menang untuk kemudahan penggunaan dan penghematan ruang, tidak perlu penelitian UX. Mereka cepat digunakan dan kita semua menyukainya.

Tolong beri kami manajemen dokumen tab :)

+1, saya.

+1

+1

VSCode adalah editor hebat dan memiliki titik integrasi yang bagus dengan Git dan Nodejs. Alasan utama saya tidak menggunakannya sebagai IDE pengembangan utama saya adalah karena tidak mendukung tab.

Sama disini. Itu SATU hal yang menahan saya dalam menggunakannya.
Operasi 10 mrt. 2016 pada 15:18 skema Konrad Piascik < [email protected]

VSCode adalah editor hebat dan memiliki titik integrasi yang bagus dengan Git dan
Nodejs. Alasan utama saya tidak menggunakannya sebagai IDE pengembangan utama saya
karena tidak mendukung tab.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -194867036.

Agak mengherankan melihat begitu banyak tekanan balik pada masalah ini karena seharusnya sangat mudah diterapkan. Setidaknya jadikan itu opsi atau tersedia melalui ekstensi (seperti yang dilakukan Brackets).

Jika ini ditambahkan, HARAP tambahkan yang berikut ini:

1. Tutup fungsionalitas seperti Google Chrome. (Selalu kesal karena versi standar VS tidak memiliki ini.)
   - " Tutup tab lain "
   - " Tutup tab di sebelah kanan ".
2. Pilihan untuk membuka tab ke kanan atau kiri. (VS mengubah default di beberapa titik, tetapi kemudian menambahkan opsi untuk mengubah)

Tab berfungsi. Mereka ada dimana-mana, orang sudah terbiasa. Daftar file saat ini tidak intuitif. Setelah 2 bulan menggunakan VS Code setiap hari, saya masih harus membuka tab hampir setiap kali saya perlu berpindah file. Fakta bahwa setiap editor lain di luar sana akan terus menggunakan tab menciptakan penghalang besar untuk sesuatu yang berbeda menjadi intuitif.

Di tim saya, orang-orang selalu mengeluh tentang hal itu, sampai-sampai beberapa orang lebih suka menggunakan sublime tanpa dukungan skrip apapun daripada menggunakan VS Code.

Saya tidak menentang penelitian UX untuk menemukan cara yang "lebih baik" dalam menangani file terbuka, tetapi tolong jangan menjadikan ini kegagalan pita Office lagi, yang membutuhkan setengah dekade dan beberapa rilis untuk menemukan cara lain untuk melakukan persis hal yang sama.

-1

Beberapa catatan mengapa saya menentang tab:

• Setiap waktu yang dihabiskan untuk tab akan menyita waktu untuk membuat perbaikan lain pada editor.
• Saya telah memaksa diri saya untuk menjadi lebih dari sekadar komando keyboard dan tidak memiliki tab telah membantu. Jadi saya berdebat dari sudut pandang ini untuk kebaikan Anda sendiri meskipun saya sendiri belum sampai di sana.
• Terkait dengan sebelumnya, ini mengingatkan saya ketika Gmail keluar dan saya harus meyakinkan orang bahwa label lebih unggul dari folder. Beberapa orang tidak bisa memprosesnya dan masih mengguncang akun email AOL / ISP mereka. Saya pikir MS harus mengambil sikap di sini dengan mengatakan "kami hanya berpikir ini adalah cara yang lebih baik untuk melakukan sesuatu."
• Jika saya menyarankan sesuatu, itu akan menjadi penjelasan dimuka mengapa tab tidak ada bersama dengan contoh menavigasi editor tanpa mereka.

Nah, ada kompromi- Buat tab terlihat atau tidak di Preferensi / Opsi.

Saya tidak berpikir itu membutuhkan waktu dari perbaikan lain karena saya yakin mereka memiliki lebih dari satu programmer di dev ini. Saya suka menjadi komando keyboard juga. Jika mereka diimplementasikan, jangan gunakan mereka tapi mengapa menghalangi mereka yang lebih suka tab dalam alur kerja mereka untuk memilikinya.

Pokoknya, bukan masalah besar. Saya telah pindah kembali ke Atom sementara saya menunggu VSC untuk memutuskan apa yang akan dilakukannya. Saya menemukan tab penting untuk alur kerja dalam proyek besar, bersama dengan kemampuan untuk membuka lebih dari satu Folder Proyek.

Saya telah memaksa diri saya untuk menjadi lebih dari sekadar komando keyboard dan tidak memiliki tab telah membantu. Jadi saya berdebat dari sudut pandang ini untuk kebaikan Anda sendiri meskipun saya sendiri belum sampai di sana.

Seperti yang saya sarankan sebelumnya di utas ini , itu _behavior_ yang hilang yang sama pentingnya, jika tidak lebih, daripada komponen visual. Saya semua menggunakan pintasan keyboard seperti ctrl + [shift +] tab atau bahkan ctrl + P untuk menavigasi ke file (termasuk yang terbuka), tetapi perilaku Working Files dan cara mengelola jendela editor (dan fakta bahwa itu ctrl + tab dalam urutan MRU) menurut saya sangat menggelegar.

Pegang teleponnya! Saya mendapat jawabannya! Itu sempurna! Siap? Kami tidak _membutuhkan_ tab. Mari kita perpanjang file yang berfungsi dengan opsi sederhana untuk menampilkannya di tab secara horizontal di bagian atas editor! Woo hoo! Masalah diselesaikan tanpa membuat tab!

Saya sebenarnya lebih suka seperti sekarang - panel untuk file yang terbuka dan pemilih file seperti daftar dengan "file yang berfungsi" di sampingnya. Dulu ketika saya menggunakan Atom, saya benci bahwa setiap kali saya melihat file dengan cepat, itu akan membuka tab baru, dan dalam beberapa menit bilah tab saya penuh dengan tab yang tidak berguna.

Jadi saya -1 dalam hal ini. Tapi saya masih ingin melihat jendela yang terlepas.

Saya baru saja beralih ke VSCode dari Atom dan memperhatikan betapa luar biasa terorganisir dan bersihnya setelah bekerja dengannya untuk sementara waktu. Alasannya? Tidak ada populasi tab yang berlebihan! Kurangnya tab yang sebenarnya membuat pengalaman ini begitu mulus

ini. 100% setuju.

Saya sebenarnya lebih suka seperti sekarang - panel untuk file yang terbuka dan pemilih file seperti daftar dengan "file yang berfungsi" di sampingnya. Dulu ketika saya menggunakan Atom, saya benci bahwa setiap kali saya melihat file dengan cepat, itu akan membuka tab baru, dan dalam beberapa menit bilah tab saya penuh dengan tab yang tidak berguna.

Saya mengerti dan itulah mengapa kami meminta fitur _additional_ bukan pengganti untuk file yang berfungsi. Saya tidak bisa seumur hidup saya mengerti mengapa keduanya tidak bisa dimasukkan dalam editor. Maksud saya serius. Lihat berapa banyak tab keinginan di utas ini! Ini bukan _Hei, saya ingin tombol-tombolnya menjadi skenario biru. Ini tentang hambatan produktivitas bagi sebagian besar orang yang menginginkan tab di editor teks ini (yang sedang dalam perjalanan menjadi lebih unggul dari Atom dan Sublime). Saya mendapatkan argumen yang valid di kedua sisi. Saya hanya tidak mengerti mengapa tab dan file yang berfungsi tidak dapat disertakan dengan opsi untuk mematikan keduanya. Semua orang menang.

@ jayrosen1576 Mungkin masalahnya adalah tidak ada yang benar-benar membuat proposal mendalam tentang bagaimana seharusnya terlihat

• haruskah bilah tab berada di atas semua jendela?
• Bagaimana cara mengklik tab bekerja ketika Anda memiliki banyak file yang terbuka berdampingan, atau di rilis mendatang, bahkan terbagi secara horizontal?
• Akankah tab file aktif selalu disorot? Bagaimana jika konsol debug difokuskan?
• Jika Anda mengaktifkan pengaturan tab, apakah bagian file kerja akan dihapus karena berlebihan?
• Bagaimana dengan nama file duplikat di folder yang berbeda?
• Bagaimana dengan tombol tutup duplikat dari tab dan panel?
• Akankah menutup panel menutup tab?
• Akankah tab muncul segera setelah Anda membuka file seperti di Atom (urgh) atau hanya saat Anda mengedit suka dengan file kerja?

Ini semua adalah pertanyaan yang harus diluangkan waktu oleh tim pengembangan. Dan sekeras yang saya coba, saya tidak dapat memikirkan implmentasi yang lebih elegan daripada daftar file yang berfungsi dan tidak membingungkan.

Inilah proposal bagaimana seharusnya terlihat:

1) Unduh Atom
2) Buka Atom
3) Lihat tab
4) Terapkan di VSCode

@ jayrosen1576 serius? Saya menyebutkan beberapa masalah yang valid dengan implementasi Atom dan juga masalah yang tidak dimiliki Atom karena tidak memiliki konsep file yang berfungsi.

Kemudian lagi, foto profil Anda menunjukkan segalanya.

• haruskah bilah tab berada di atas semua jendela?
  A: Ya. Coba tab di Atom
• Bagaimana cara mengklik tab bekerja ketika Anda memiliki banyak file yang terbuka berdampingan, atau di rilis mendatang, bahkan terbagi secara horizontal?
  J: Tab muncul di bagian atas setiap panel. Coba tab di Atom.
• Akankah tab file aktif selalu disorot?
  A: Ya. Coba tab di Atom.
• Bagaimana jika konsol debug difokuskan?
  J: Hasil yang sama seperti saat konsol debug difokuskan sekarang dengan dua file dibuka berdampingan.
• Jika Anda mengaktifkan pengaturan tab, apakah bagian file kerja akan dihapus karena berlebihan?
  A: Hanya jika Anda menonaktifkan file yang berfungsi (sebagai opsi)
• Bagaimana dengan nama file duplikat di folder yang berbeda?
  J: Tab menyertakan jalur parsial. Coba tab di Atom.
• Bagaimana dengan tombol tutup duplikat dari tab dan panel?
  J: Panel tidak memiliki tombol tutup. Coba tab di Atom.
• Akankah menutup panel menutup tab?
  A: Ya. Coba tab di Atom.
• Akankah tab muncul segera setelah Anda membuka file seperti di Atom (urgh) atau hanya saat Anda mengedit suka dengan file kerja?
  J: Hanya jika Anda mengaktifkan opsi untuk melakukannya (usePreviewTabs = false di Atom menonaktifkannya). Jika tidak, klik dua kali akan membukanya di tab. Coba tab di Atom.

@felixfbecker Karena produk ini mengusung moniker Visual Studio, maka harus ada tab opsional, dan tab tersebut harus berperilaku seperti pada produk Visual Studio lainnya.

Dikatakan banyak tentang karakter Anda ketika Anda mengemukakan sesuatu yang sepele seperti gambar profil sebagai tanggapan atas jawaban yang valid untuk kekhawatiran Anda.

Pegang teleponnya! Saya mendapat jawabannya! Itu sempurna! Siap? Kami tidak membutuhkan tab. Mari kita perpanjang file yang berfungsi dengan opsi sederhana untuk menampilkannya di tab secara horizontal di bagian atas editor! Woo hoo! Masalah diselesaikan tanpa membuat tab!

@ jayrosen1576 Ini tidak benar-benar menyelesaikan masalah sepenuhnya, karena seperti yang saya katakan sebelumnya (dan muncul lagi di komentar sebelum komentar Anda), bukan hanya tampilan visual tab yang berbeda - ini adalah perilakunya. Seperti yang saya katakan di komentar pertama saya di sini, Anda bisa mendapatkan "tab di sidebar" juga di Sublime Text, tetapi itu masih tidak sama dengan file yang berfungsi. (IMO lebih baik.)

@kfraniro Saya setuju. Saya hanya bersikap snarky. Hal tab ini adalah argumen yang sangat konyol. Jika VSCode hanya memiliki kemampuan tab dari tab Atom dengan opsi untuk menyembunyikannya (bahkan secara default) itu akan sempurna. Saya pikir kita semua meminta hal yang sama. Saya hanya tidak mengerti mengapa keduanya tidak dapat disertakan dengan opsi untuk mematikan keduanya.

Sejujurnya, membahas apakah tab adalah pilihan yang baik untuk editor teks itu bodoh. Ini bukan konsep baru. Cukup terapkan dan biarkan opsional. Jadikan itu perpanjangan dan biarkan tidak. 1 ekstensi sejauh ini hingga orang menyadari bahwa ini adalah fungsi dasar dan tidak masuk akal untuk tidak memilikinya, sama seperti pilihan menu huruf besar VS.

@nvivo Tidak bisa meletakkannya sendiri. Seluruh diskusi ini sepertinya bodoh.

seperti pilihan menu huruf besar VS.

@nvivo Sudahkah Anda mencoba ekstensi ini? Tidak ada opsi menu tetapi Anda dapat mengatur beberapa pintasan keyboard. bekerja dengan cukup baik.

https://marketplace.visualstudio.com/items?itemName=wmaurer.change-case

Jika Anda tidak suka diskusi ini teman-teman, lanjutkan saja. Membaca utas ini sepenuhnya opsional!

Tentu saja membacanya adalah opsional, tetapi keberadaannya tampaknya mendukung gagasan bahwa menambahkan tab ke VS Code adalah opsional dan bahwa kita harus memperdebatkannya. Jajak pendapat sederhana dengan pertanyaan berikut.

Apakah Anda akan terus menggunakan VS Code jika tab tidak segera ditambahkan? Ya Tidak

Akan menunjukkan bahwa Microsoft akan kehilangan sebagian besar basis pengguna potensial itu jika mereka tidak menambahkannya. Artinya, dari sudut pandang komersial, bahkan jika mereka tidak membutuhkan fitur itu sendiri, itu akan menjadi bunuh diri komersial jika mereka tidak melakukannya. Ergo, percakapan ini mengganggu dan tidak perlu.

Karena itu, kami berbicara tentang perusahaan yang sama yang masih belum memasukkan ekstensi ke browser mereka. Jadi saya rasa semuanya mungkin.

Dalam keseriusan, satu-satunya percakapan sekarang adalah tentang cara terbaik untuk menerapkan tab. Tidak ada lagi tanda tanya apakah orang menginginkan fitur tersebut, jadi mari kita lanjutkan percakapan ke sesuatu yang lebih konstruktif.

Ekstensi browser? Aktif ... NVM.

Kejujuran saya tidak melihat alasan untuk tab. Cinta tab terlalu sial. Dalam hal menyelesaikan pekerjaan yang sebenarnya, pintasan melakukan semua yang diperlukan, dengan pencarian dengan regex, lebih banyak metadata, dan proses kerja berlapis uap yang jauh lebih baik. Mereka menyediakan kebutuhan esoterik dasar untuk, entahlah, sesuatu yang familiar. Saya merasa ini hanyalah dorongan untuk melihat apakah ms akan melayani komunitas, untuk melihat apakah mereka benar-benar berubah. Meskipun tidak ada gunanya semua teks huruf besar dalam masalah vs.

Dalam hal apa yang dikatakan sebelumnya.

"Saya tidak berpikir itu membutuhkan waktu untuk perbaikan lainnya"

Secara pribadi menurut saya memang demikian, seperti misalnya membuat kemampuan untuk ekstensibilitas pada jendela editor teks, sehingga ekstensi dapat dibuat untuk siapa saja yang menginginkan tab. Saya cukup yakin seluruh gagasan vscode adalah membuatnya seminimal dan seringan mungkin, dengan pengguna akhir menambahkan ekstensi atau memperluasnya.

@ 4tron , tentunya ada persekongkolan dari komunitas jahat untuk menguji microsoft disini! Bukankah selalu ada satu?

Jika tab masuk akal, kami akan melihat editor lain menggunakannya. Dan jika itu adalah cara yang sangat bagus untuk mengatur beberapa konten terbuka, mungkin jenis perangkat lunak lain yang memiliki kebutuhan untuk mengatur beberapa konten terbuka, seperti misalnya, browser misalnya, akan menggunakannya juga. Tapi tentu saja tidak, karena tidak masuk akal! Dapatkah Anda membayangkan sesuatu yang digunakan orang sepanjang waktu seperti browser menggunakan tab? Omong kosong!

Saya katakan mari bermain aman. Mari kita tunggu dulu dan lihat apakah beberapa editor bagus lainnya mendukung fitur baru ini sehingga kita tidak membuang waktu dan tenaga untuk sesuatu yang sebenarnya tidak berfungsi. Mari kita periksa studio visual, intellij, eclipse, atom, sublime, monodevelop, notepad ++ atau lainnya yang memiliki basis pengguna yang cukup banyak. Setelah setidaknya _some_ editor ini mendukung fitur ini selama beberapa tahun tanpa menggantinya dengan fitur lain, maka akan ada indikasi bahwa ini adalah fitur yang berguna.

Tapi jangan terlalu terburu-buru. Kita perlu memiliki sesuatu seperti pelacak masalah di mana orang dapat mengungkapkan keinginan itu secara langsung dan mungkin membiarkan orang lain memilih, jadi kita benar-benar dapat memastikan bahwa kita tidak melakukan ini tanpa alasan! Kami hanya dapat mengambil tindakan jika ini menjadi salah satu fitur yang paling banyak diminta di repositori. Kemudian kita akan tahu bahwa ini bukan hanya tren, tetapi orang-orang menganggapnya berguna untuk pekerjaan sehari-hari mereka dan menginginkan fitur itu juga di sini.

Tapi sampai hari itu, mari kita tunggu dengan sabar. Editor teks adalah hal baru dan tidak ada yang benar-benar tahu fitur seperti apa yang dibutuhkan.

Ghehehe, kocak!

Op za 12 mrt. 2016 om 11:57 schreef Natan Vivo [email protected]

@ 4tron https://github.com/4tron , tentunya ada konspirasi dari
komunitas jahat untuk menguji microsoft di sini! Bukankah selalu ada satu?

Jika tab masuk akal, kami akan melihat editor lain menggunakannya. Dan jika itu
adalah cara yang sangat bagus untuk mengatur beberapa konten terbuka, mungkin jenis lainnya
perangkat lunak yang memiliki kebutuhan ini untuk mengatur beberapa konten terbuka, seperti
katakanlah, browser misalnya, akan menggunakannya juga. Tapi tentu saja tidak,
karena tidak masuk akal! Dapatkah Anda membayangkan sesuatu yang digunakan semua orang
waktu seperti browser menggunakan tab? Omong kosong!

Saya katakan mari bermain aman. Mari kita tunggu dulu dan lihat apakah ada editor bagus lainnya
mendukung fitur baru ini sehingga kami tidak membuang waktu dan tenaga untuk sesuatu
itu sebenarnya tidak berhasil. Mari kita periksa studio visual, intellij, eclipse,
atom, sublime, monodevelop, notepad ++ atau lainnya yang memiliki file
basis pengguna yang cukup besar. Setidaknya satu_ dari editor ini mendukung
fitur ini selama beberapa tahun tanpa menggantinya dengan yang lain,
maka akan ada indikasi bahwa ini adalah fitur yang berguna.

Tapi jangan terlalu terburu-buru. Kita perlu memiliki sesuatu seperti file
issue tracker dimana orang dapat mengungkapkan keinginan itu secara langsung dan mungkin membiarkan
orang lain memilih, jadi kami benar-benar dapat memastikan bahwa kami tidak melakukan ini
tidak ada! Kami hanya dapat mengambil tindakan jika itu menjadi salah satu yang paling banyak diminta
fitur dalam repositori. Maka kita akan tahu bahwa ini bukan hanya tren,
tetapi orang-orang menganggapnya berguna untuk pekerjaan sehari-hari mereka dan menginginkan fitur itu di sini
terlalu.

Tapi sampai hari itu, mari kita tunggu dengan sabar. Editor teks adalah hal baru
dan tidak ada yang benar-benar tahu fitur seperti apa yang dibutuhkan.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -195715795.

@nvivo Apakah Anda benar-benar sedang membandingkan browser dengan editor teks saat ini? Saya memahami penggunaan sarkasme Anda yang berlebihan di sini, dan itu bagus. Poin yang saya coba buat bukanlah tentang apakah tab berguna atau tidak. Saya suka ide editor lightwieght / minimal. Ini hanya pendapat saya, saya suka ide editor yang dapat diperluas untuk pengguna berdasarkan preferensi pengguna mereka. Itulah yang saya ingin vscode bekerja. Kemudian kita dapat memindahkan diskusi ini ke "Mengapa belum ada pengembang yang membuat ekstensi untuk ini .. oh mungkin saya harus karena saya suka tab dan saya ingin melakukannya di sini, dan vscode dapat melakukannya jadi yay, sekarang saya memiliki editor teks yang mirip dengan browser saya "

@ 4tron Sepertinya dia juga membandingkan editor teks dengan editor teks.
Saya pikir mereka melakukan pekerjaan yang hebat dalam membuat vscode dapat diperluas, tetapi saya sangat mendukung yang menganggap tab harus menjadi fitur out-of-the-box. Gagasan ini "Oh, Anda menyukai tab seperti semua perangkat lunak lain yang Anda gunakan? Google masalahnya, temukan saran yang menjelaskan cara memasang ekstensi kontribusi pengguna yang sesuai, dan Anda siap melakukannya!" tidak terbang. Saya membayangkan sebagian besar pengguna hanya mengharapkan tab ada, dan saya sangat meragukan ada banyak orang yang mengira Anda akan menemukan bilah tab dengan memasang ekstensi. Saya cukup yakin itu tidak didahului oleh perangkat lunak lain mana pun. Mengapa orang berpikir untuk melakukan itu?

@TurkiMan
Retorikanya dimulai dengan perbandingan dengan browser.

Kami berbicara tentang pengembang di sini. Saya pikir mereka akan memiliki inisiatif jika mereka menginginkan tab. Saya minta maaf saya menentang gagasan ini, tetapi saya tidak melihat tab alasan yang valid, saya alt + q dalam vs sepanjang waktu. Saya hanya tidak melihat nilai tambah apa pun. ini adalah pendapat pribadi saya, dan mungkin im crap dev karena tidak memahami bagaimana tab seharusnya berguna. Saya pikir percakapan ini bertele-tele dan secara pribadi saya ingin melihat vscode dibuka sebagai shell terisolasi untuk kustomisasi hampir lengkap dan bahkan model berbasis bisnis yaitu. di mana seseorang dapat meningkatkan kustomisasi ke tingkat yang terfokus untuk mengatakan pengembangan drupal atau pengembangan wordpress di mana editor membangun didasarkan pada ekosistem basis kode pengguna. Itu juga saya sepertinya masalah yang lebih baik untuk dipecahkan.

Kelemahan dari segala sesuatu yang menjadi ekstensi adalah Anda berakhir dengan interaksi aneh yang tidak diinginkan di antara mereka. Dalam kode vs, sudah menggunakan GitHistory di atas Smart File Reopener menyebabkan masalah penutupan file yang aneh.

Sesuatu yang mendasar seperti tab harus di luar kotak. Sekarang, seperti yang diminta orang lain di utas ini, membuka grup atau membuat hubungan antar tab adalah tempat ekstensi harus masuk ke dalam diskusi.

@ 4tron , Itu lucu, tapi saya benar-benar serius.

Layanan kompilator eksternal adalah sesuatu yang mungkin Anda putuskan atau tidak untuk dukung di editor teks. Pelari tugas terintegrasi adalah fitur yang bagus untuk dimiliki.

Tab tidak ada di kelas ini. Tab seperti jendela, tombol, dan membuka serta menyimpan file. Tidak ada keputusan yang harus diambil di sini, biarkan saja mereka di sana dan lanjutkan, orang-orang mengharapkannya. Ini bukan hal kustom tingkat lanjut yang hanya ingin didukung oleh sedikit orang dengan plugin, mereka adalah UI standar di _ OS apa pun di mana pun_. Orang-orang sudah terbiasa dengannya, dan ada alasan mengapa setiap editor yang memungkinkan tidak memerlukan petisi untuk menambahkan mereka.

Dan inilah mengapa mendiskusikan apakah tab bagus atau tidak itu bodoh. VS Code bukanlah eksperimen UX, ini merupakan upaya untuk memiliki editor .NET yang bagus untuk semua platform. Jadikan benda sialan ini bermanfaat bagi 90% orang dan Anda akan berhasil.

Sejujurnya saya mengerti maksud Anda tentang alternatif, tetapi Anda hanya perlu memahami bahwa Anda adalah minoritas yang sangat kecil. Percaya kebanyakan orang yang menanyakan ini hanyalah troll yang ingin menguji microsoft hanya delusi.

Poin tentang itu adalah panggilan untuk melihat apakah ms akan mengubah pendiriannya pada tab, setengah hati, terutama karena hasrat untuk memasukkan tab. Sampai-sampai seseorang tidak mau mencoba editor karena tidak ada tab. Saya berjuang untuk memahami ini. Jangan lupa bahwa ini masih dalam Beta. Jadi mudah-mudahan mereka akan menambahkan tab (sebagai opsional).

@ 4tron Saya mencobanya berkali-kali, dan saya tidak menggunakan vscode secara teratur karena tampaknya tidak berskala untuk proyek besar dengan baik, dan tab yang hilang adalah salah satu alasan praktis utama yang tampaknya benar bagi saya.
Saya terutama menggunakannya sebagai editor teks ringan saat saya mengedit sejumlah kecil file, tetapi segera setelah saya ingin mengerjakan salah satu proyek besar kami, vscode tidak berfungsi. Tab yang hilang, dan fakta bahwa tidak ada gagasan tentang sub-proyek (atau 'solusi' seperti yang dikatakan VS) adalah satu-satunya pemblokir yang saat ini saya ketahui.

Saya hanya ingin mengomentari gagasan menambahkan semuanya dengan plugin ini. Itu tujuan yang bagus; memiliki kerangka kerja ekstensi yang bagus itu penting, tetapi saya pikir mereka perlu berhati-hati tentang komitmen berlebihan pada gagasan itu.
Saya menggunakan VS, dan sementara itu membuat saya gila, saya menemukan bahwa saya terikat padanya karena memiliki tingkat kualitas produk yang sangat tinggi yang saya harapkan dari produk MS. Saya telah mencoba setiap alternatif OSS di luar sana (dan alat berpemilik lainnya), dan mereka semua sepertinya gagal dalam kegunaan dasar (terutama dalam hal pengalaman debugging).
Saya sangat berharap bahwa maksud dari vscode bukanlah menjadi cangkang ringan yang diretas semua orang secara acak melalui ekstensi ... sudah ada banyak alat lain yang sesuai dengan deskripsi itu, saya belum menemukan satu pun yang menarik. Apa yang saya inginkan dari vscode adalah apa yang selalu saya harapkan dari VS; untuk dirancang dengan baik dari sudut pandang kegunaan oleh desainer UX profesional, dan menjadi CROSS PLATFORM.

Saya pikir mereka yang menentang tab mungkin kehilangan intinya. Saya (kami) tidak menginginkan solusi semua atau tidak sama sekali. Yang kami minta hanyalah opsi sederhana untuk mengaktifkan tab (tab dapat disembunyikan secara default) yang terlihat dan berperilaku seperti yang ada di editor Atom populer. Jika Anda tidak menyukai mereka, Anda tidak akan pernah tahu bahwa mereka ada. Jika Anda melakukannya maka mereka dapat diaktifkan. Dan bagi mereka yang belum pernah menggunakan Atom dan pengalaman multi-panel + tab, saya sarankan Anda mencobanya sebelum benar-benar mengabaikan argumen untuk mereka. Anda mungkin tidak menyukainya, tetapi Anda harus mengakui bahwa mereka _are_ berguna bagi banyak dari kita. Jika bukan karena kemampuan debug node.js yang sangat baik dari Kode VS, saya akan menggunakan Atom secara eksklusif. Saya tidak keberatan dengan file kerja. Saya pikir mereka bisa berguna, namun, mereka tidak membuat pengganti yang baik untuk tab dan sebenarnya bukan cara alternatif untuk melakukan hal yang sama. Ini seperti mengatakan _Anda memiliki Honda Civic, mengapa Anda menginginkan truk pickup? _ Coba muat 1200 lbs lidah bambu dan lantai alur ke bagian belakang Civic Anda dan Anda akan tahu alasannya. Keduanya adalah kendaraan tetapi memiliki tujuan yang berbeda.

Seperti yang saya katakan sebelumnya, perhatikan Visual Studio, Edge atau produk Microsoft lainnya untuk satu rilis dan lihat reaksinya. Ini tidak akan cantik. Kami _can_ semua memiliki keduanya. Kami meminta agar tab menjadi _optional_ bukan komponen editor yang diperlukan. Bisakah waktu dihabiskan dengan lebih baik untuk pengembangan editor lain? Tentu. Perbaikan bug kritis dan peningkatan yang memblokir penggunaan editor harus selalu diutamakan. Namun, saya yakin ada banyak fitur yang ditambahkan yang tidak mencapai tingkat perbaikan atau perbaikan kritis. Jadi jika waktu dihabiskan untuk itu maka harus ada waktu yang disisihkan untuk fitur yang diminta sebagian besar di utas ini.

Kami menyukai VSCode dalam beberapa bulan terakhir dan kami terlibat dalam topik ini karena kami ingin menjadi editor terbaik yang tersedia. Tidak ada ruang untuk hal-hal negatif di sini. Kami semua bersemangat tentang apa yang kami inginkan / tidak inginkan sebagai pengembang. Tidak ada yang memiliki opini yang salah tetapi opini yang berlawanan harus dihormati seperti itu dan tidak hanya diabaikan karena Anda merasa mereka tidak valid.

Saya tidak berpikir ada banyak "gairah untuk tab". Yang terjadi adalah setelah @bpasero menyatakan "Menurut saya tab bukanlah cara yang baik untuk menampilkan daftar file yang terbuka " dan " Sejauh ini saya belum mendengar alasan yang baik untuk tab ", orang akan lebih vokal mencoba untuk membenarkan permintaan ke pelaku proyek utama.

Saya sangat frustrasi melihat semua diskusi ini, dan saya sedikit tersinggung karena saya menggunakan VS Code setiap hari dalam pekerjaan saya dan saya ingin memiliki editor .NET yang bagus di mac dan linux, dan saya sangat merindukan tab, dan saya tidak mengerti momen "_wow! ini sebenarnya lebih berguna_", tetapi respons di sini tampaknya "_Anda hanya tidak menyadari bahwa kami telah menciptakan sesuatu yang luar biasa! beri waktu dan biasakanlah! _".

Berikut adalah beberapa masalah aktual yang saya lihat dengan menggunakan VS Code setiap hari selama beberapa bulan:

• tidak masuk akal bagi saya mengklik ikon tutup di jendela tetapi menyimpan file dalam daftar itu - saya harus terus membersihkan daftar itu secara manual untuk memiliki daftar di mana saya hanya melihat file yang sebenarnya saya gunakan - dan file Yang saya kerjakan bukanlah yang terakhir saya buka atau yang saya ubah, itu yang ingin saya tetap buka pada saat yang sama
• tidak masuk akal bagi saya untuk menutup file yang belum disimpan dan memasukkannya ke dalam daftar itu dengan penanda - berkali-kali dalam sehari saya melakukan sesuatu, dan perubahan tidak tercermin dalam aplikasi karena saya menutup file dan kode VS tidak bertanya saya untuk menyimpannya, yang membuat saya membuang waktu
• satu klik membuka file, tetapi hanya klik dua kali untuk meletakkan file di bagian yang baru-baru ini digunakan - jadi, saya terus-menerus membuka file yang tidak muncul di sana - dan kemudian memori otot saya merasa lebih mudah untuk menambah atau menghapus spasi di file kemudian gulir ke file yang saya lihat lagi dan klik dua kali
• Saya merasa menjengkelkan karena Anda tidak dapat melihat scrollbar setelah daftar terisi kecuali Anda mengarahkan kursor ke atasnya. Nah, ini rumit karena begitulah UI bekerja di editor. Tapi lihat, saya tahu proyeknya dan saya tahu pasti ada lebih banyak file di tampilan folder. Saya juga tahu struktur kodenya, jadi saya tahu pasti ada sesuatu yang lebih di panel editor. Tetapi dengan daftar terbaru, saya tidak tahu. "Apakah penuh atau apakah saya lupa membuka file itu? Bukankah saya membuka file itu 1 menit yang lalu? Izinkan saya membuka file itu lagi ..."

Sekarang, saya melihat bahwa sebagian besar masalah ini akan diselesaikan dengan argumen seperti "_oh, tetapi Anda tidak mengerti, ini adalah daftar file yang baru-baru ini digunakan, bukan daftar file yang terbuka. Anda membandingkannya dengan tab, dan ada yang lebih baik cara menangani file yang terbuka. Setelah beberapa waktu Anda mulai ..._ "

Yang dengan senang hati saya jawab: "_Semua hal ini tidak masuk akal bagi saya dan sebenarnya membuat saya tidak produktif. Sudah ada solusi yang berhasil di mana-mana selama beberapa dekade. Saya tidak ingin memperbaiki sesuatu yang tidak pernah masalah, dan sejujurnya saya tidak melihat solusi baru ini sebagai alternatif yang lebih baik. Bisakah kita memiliki sesuatu yang familier yang berfungsi dan kita semua terbiasa? Terima kasih_ "

Saya tahu semua ini terdengar arogan. Tapi saya yakin ini adalah apa yang kebanyakan orang pikirkan tetapi terlalu malu atau terlalu sopan untuk dikatakan.

UI eksperimental sangat bagus sebagai alternatif dan saya semua memiliki opsi untuk beralih di antara keduanya. Tetapi saat ini ini adalah eksperimen paksa yang mencegah opsi lain, yang paling umum dan diharapkan. Dan sama seperti Start Menu Windows 8 tidak ada cara ini berakhir dengan baik.

Yang dengan senang hati saya jawab: "Semua ini tidak masuk akal bagi saya dan sebenarnya membuat saya tidak produktif. Sudah ada solusi yang berhasil di mana-mana selama beberapa dekade. Saya tidak ingin memperbaiki sesuatu yang tidak pernah masalah, dan sejujurnya saya tidak melihat solusi baru ini sebagai alternatif yang lebih baik. Bisakah kita memiliki sesuatu yang familier yang berfungsi dan kita semua terbiasa? Terima kasih "
...
Dan sama seperti Start Menu Windows 8 tidak ada cara ini berakhir dengan baik.

Saya sangat setuju.

Karena code folding pernah menjadi fitur yang paling banyak dipilih, jadi sekarang adalah tab . Tim vscode memberi kami pelipatan.

Saya akan terkejut dan kecewa jika tab tidak pernah membuahkan hasil mengingat rekam jejak yang bagus dari tim vscode yang memasukkan permintaan pengguna teratas sehubungan dengan partisipasi menyegarkan Microsoft dalam komunitas open source.

@ianwesterfield Tepatnya, ini adalah fitur yang paling banyak diminta dengan ribuan suara. Itu akan terjadi. Percakapan ini tidak ada gunanya dan perlu beralih ke "Bagaimana tepatnya tab bekerja?"

Saya berkomentar sebelumnya tentang keberadaan implementasi tab yang hampir sempurna: Atom. Mereka mudah diatur, memiliki tampilan yang tepat dari jalur file parsial jika dua tab memiliki nama file yang sama dan bekerja sangat baik di jendela dengan beberapa panel horizontal dan / atau vertikal (yang menurut saya merupakan fitur lain yang dibutuhkan dari VSCode). Jika VSCode memiliki fitur tab yang sama dengan Atom, saya pikir itu akan mencakup 99% dari apa yang diminta semua orang. Dan karena Atom juga berbasis elektron, implementasi dapat berfungsi sama baiknya di VSCode. Saya bukan untuk solusi copy-cat apa pun, namun mereka (Atom) telah melakukan pekerjaan yang hebat dalam menerapkan tab dan apa yang mereka miliki adalah solusi yang sangat baik dalam hal itu.

@ jon64digital Mungkin hanya saya, tapi menurut saya yang mencegah berkembangnya percakapan ini adalah rasa frustrasi. Permintaan ini masih belum ditetapkan di backlog, bahkan dengan 6k + suara dan referensi kata yang samar-samar di iterasi 31 Maret:

Meningkatkan manajemen dokumen, perilaku penumpukan editor

Rasanya kita masih harus berulang kali membenarkan keberadaan tab, apalagi perilakunya. Setidaknya, saya kira, referensi tersebut adalah salah satu dari tiga referensi untuk Menghilangkan Penghalang Pandang Adopsi , tetapi sekarang sudah 12 Maret ...

Dengan pemikiran itu, saya pikir jika mereka setidaknya menugaskannya kepada seseorang, kita bisa tenang dengan apa yang dikatakan @waderyan sebelumnya dan mungkin kemudian percakapan bisa mulai berkembang.

EDIT Mungkin kurangnya komitmen dari tim VS Code adalah kesalahpahaman - setelah semua rencana iterasi bulan Maret belum diperbarui sejak 7 Januari.

@ jayrosen1576 Saya setuju - dan saya pikir 1% dari permintaan pengguna yang tidak akan tercakup kemudian dapat ditangani melalui ekstensi (misalnya membuka file dengan relasi dalam grup tab, dll.).

@ jayrosen1576 Apakah atom memungkinkan Anda untuk menautkan file sehingga Anda dapat memiliki tampilan terpisah yang (misalnya) membuka toolbar.html di bingkai pertama, toolbar.js di bingkai kedua dan toolbar.css di bingkai ketiga?

Ini hanyalah sebuah contoh tetapi akan sangat ideal. Seseorang di atas mengatakan bahwa Vim dapat melakukan ini tetapi saya memeriksa vim dan tidak tertarik padanya karena sejumlah alasan, tetapi tab kedengarannya luar biasa.

@ jon64digital Atom tidak melakukan ini secara default, dan saya tidak mengetahui ekstensi apa pun hingga saat ini yang melakukannya (bahkan ekstensi yang diilhami vim), tetapi ini adalah kasus penggunaan ekstensi yang saya maksud di posting terakhir saya.

EDIT mengacu pada komentar oleh @jtosey di atas (sekitar 9 hari sebelum posting ini).

Secara pribadi saya bisa melihat ini menjadi gangguan. Separuh waktu saya tidak peduli dengan tampilan - hanya controller, model, dan JS sisi klien. Saya mungkin akan menjadi gila jika tampilan dibuka setiap kali saya membuka JS.

Tapi sekali lagi, itulah keindahan dari sebuah ekstensi - jika saya tidak menyukainya, saya dapat mematikannya.

Saat mengerjakan permintaan fitur seperti ini yang memiliki dampak yang sangat kuat pada UX, pertama-tama kami biasanya meluangkan waktu dalam rapat UX untuk membahas bagaimana implementasi sebenarnya seharusnya terlihat. Kami memiliki manajemen dokumen yang lebih baik dalam agenda kami untuk beberapa waktu tetapi hal-hal lain di daftar GA kami memiliki prioritas yang lebih tinggi (Aksesibilitas misalnya).

Kami akan mengambil item ini setelah GA rilis akhir bulan dan memulai diskusi tentang bagaimana pengelolaan dokumen harus bekerja di masa depan. Kami memang melihat beberapa kekurangan dengan cara kerja saat ini dan tahu bahwa kami perlu memperbaikinya. Kami berpikir bahwa bahkan tanpa tab, ada beberapa hal yang tidak terlalu intuitif dalam cara UX berperilaku saat ini (Editor Tutup vs. Tutup File, fakta bahwa editor samping berperilaku berbeda dibandingkan dengan editor lain, file yang berfungsi dan quick terbuka, dll.).

Meskipun konsep tab dipahami dengan baik, kami tidak berpikir bahwa kami dapat dengan mudah menambahkan tab di atas pengelolaan dokumen yang ada tanpa mengunjungi kembali konsep kami di sana.

Saya pikir kami akan memiliki beberapa diskusi tentang bagaimana manajemen dokumen harus bekerja di masa depan dan saya pikir kami siap untuk merombak konsep seperti yang kami anggap perlu.

@bpasero setelah meninjau kode untuk masalah lain, saya tidak mengerti mengapa tidak mungkin untuk menambahkan tab atau konsep apa yang harus Anda ubah dengan melakukannya. Mungkin akan sangat membantu jika Anda bisa mencerahkan kami, atau apakah ini referensi ke garis pemikiran dalam posting asli Anda?

@bpasero Sangat menyenangkan jika Anda menjelaskan lebih lanjut tentang apa yang didiskusikan dan apa saja pendekatan yang Anda lihat sebagai solusi yang mungkin untuk masalah yang kami posting.

PS Saya tidak yakin apakah itu mungkin dengan VSCode tetapi beberapa tim seperti Roslyn, TypeScript dan beberapa lainnya membagikan catatan desain mereka, ini memberikan banyak konteks tentang bagaimana mereka bekerja dan apa yang akan datang selanjutnya, itu juga membuka komunitas untuk diskusi baru, apakah sesuatu seperti ini mungkin?

@bpasero apakah tim akan secara serius mempertimbangkan upaya komunitas untuk menambahkan tab. Saya tidak keberatan mencoba, tetapi saya tidak berpikir ada orang yang mau membuang waktu mereka jika ada upaya yang diblokir

Saya pikir tim Anda terkunci karena telah membuat sarang tikus mondok ini ke gunung.

Artinya: Tab adalah konstituen, tidak identik dengan, konsep manajemen dokumen yang lebih luas. Ada masalah lain yang telah diajukan berkaitan dengan area lain dari manajemen dokumen vscode.

Kami sudah mendiskusikan ide UX kami melalui masalah di tempat terbuka (lihat https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aux), saya akan menganggap kami akan melakukan hal yang sama untuk manajemen dokumen dan tab.

Saya juga berpikir kami tidak ingin perbaikan ini dilakukan melalui ekstensi melainkan menjadikannya sebagai konsep inti di meja kerja VS Code.

Begitu kami memulai diskusi UX dalam tim, kami ingin melibatkan komunitas juga dan kami juga akan mendiskusikan kekurangan yang kami lihat dalam desain kami saat ini dan apa yang kami rencanakan untuk ditingkatkan.

@bpasero terima kasih banyak, hanya itu yang ingin saya ketahui. :)

@bpasero Mengagumkan. Saya tahu kalian berusaha keras untuk produk ini dan kami semua sangat menghargainya. Saya pikir banyak dari kita hanya merasa frustrasi dengan kurangnya tab di UI karena kita sangat bergantung pada mereka dan sepenuhnya mengubah cara kita bekerja bukanlah suatu pilihan. Kami ingin ini menjadi editor terbaik di luar sana dan hampir menyelesaikannya.

Tanpa membaca seluruh utas ini saya memberikan besar: +1: pada ini.

Saya telah menggunakan Sublime selama bertahun-tahun dan menyukai tab. Saya melihat bahwa file yang berfungsi mengisi beberapa celah, tetapi tidak sepenuhnya. Saya tidak bisa menjelaskan sepenuhnya mengapa, tapi tolong beri saya tab saya!

+1

Amat sangat diperlukan.

+1

Saya mengerjakan banyak jenis file yang berbeda selama pengembangan jadi saya sering suka membuat grup tab di sisi kanan untuk satu jenis file dan grup tab lain di sebelah kiri untuk jenis file lainnya. Misalnya, saat mengerjakan kode busur derajat / webdriverjs, saya ingin menyimpan semua "Objek Halaman" di sebelah kanan dan semua "spesifikasi" di sebelah kiri, dikelompokkan secara terpisah dan logis. Demikian pula saat mengerjakan hal-hal front-end, saya akan menyimpan grup tab di sebelah kanan untuk semua file js / ts dan satu lagi di sebelah kiri untuk html dan css.

Ini hanyalah dua contoh, tetapi saya melakukan ini SEMUA waktu di hampir setiap proyek sampai batas tertentu dan strategi ini telah membantu saya dengan baik selama bertahun-tahun pengembangan dan saya merasa sangat membantu.

Meskipun Kode memungkinkan saya memiliki banyak panel, pendekatan daftar file global membuatnya lebih sulit untuk membedakan antara jenis file dan oleh karena itu saya mendapati diri saya membuang banyak waktu untuk menggulir daftar file yang ingin saya lihat. Selain itu, ketika saya (secara naluriah) mencoba menutup hanya satu file di panel kanan, seluruh panel menghilang yang sangat membuat frustrasi, terutama setelah menggunakan VS biasa selama lebih dari 16 tahun yang telah melatih saya untuk mengharapkan panel tetap terbuka dengan sisa file terlihat.

Kurangnya grup tab di Code sangat mengecewakan dan menurut saya orang tidak harus dipaksa atau diyakinkan untuk bekerja dengan cara tertentu karena "lebih baik" atau "tidak ada alasan yang baik untuk tab". Ya ada. Mungkin Anda tidak menggunakannya dengan cara terbaik atau merasa tidak berguna, tetapi ada banyak dari kita yang melakukannya dan akan sangat menghargai sesuatu yang mendasar seperti grup tab.

Pemahaman saya adalah bahwa Kode didasarkan pada Atom yang sudah memiliki dukungan grup tab. Tampaknya akan membutuhkan banyak pekerjaan tambahan untuk menghapus fungsi ini, yang tidak masuk akal bagi saya. Setidaknya izinkan pengguna untuk memilih pengalaman mana yang mereka inginkan sehingga mereka dapat menggunakan Kode dengan cara yang paling sesuai untuk mereka.

Harap bawa grup tab kembali ke VS Code.

Mungkin jika Anda menggambar kotak di sekitar nama file dalam daftar Working Files, orang akan melihat bahwa fungsinya sama dengan tab di sisi kiri ... :-)

@ChrisMiami : kecuali tidak . (Saya berpotensi bersedia untuk menerimanya jika memang begitu.)

LOL

Pada Kamis, 17 Maret 2016 jam 4:59 AM Kenneth G. Franqueiro <
[email protected]> menulis:

@ChrisMiami https://github.com/ChrisMiami : kecuali tidak
https://github.com/Microsoft/vscode/issues/224#issuecomment -166931316.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

@kfranqueiro sambil menunggu solusi tab yang tepat, Anda mungkin tertarik untuk mengadopsi keybindings yang saya gunakan yang membawa ctrl + w dan ctrl + shift + w lebih dekat ke implementasi tab biasa.

@ nub340 VSCode tidak berbasis Atom tetapi Electron yang dibuat oleh grup yang sama yang bekerja pada Atom.

+1 Silakan tambahkan !!!

Saya juga berpikir ini adalah fitur yang sangat hilang di editor yang hebat.

Harap tambahkan tab sebagai opsi, atau izinkan plugin pihak ketiga untuk fungsionalitas tab.

Hal pertama yang mengejutkan saya tentang VSC (setelah nama yang konyol) adalah betapa _besar_ _not_ memiliki tab.

Saat ini saya memiliki 8 file yang terbuka - tab tidak ada gunanya bagi saya, karena nama file tidak akan ditampilkan di tab.

Saya _adore_ CTRL + TAB, dan daftar 'file kerja'.

Jika Anda harus menambahkan tab, jadikan itu opsional.

@leegee Mereka tidak "tidak berguna", Anda hanya tidak membutuhkannya. Apakah Anda menganggap bahwa orang yang mengerjakan jenis proyek yang berbeda mungkin memiliki kasus penggunaan yang berbeda dengan Anda?

Berikan ribuan orang yang telah memilih tab, saya pikir satu-satunya hal yang "tidak berguna" di sini adalah komentar Anda :)

@ jon64digital : Saya melihat bahwa proyek tersebut meminta komentar umum dari pengguna tentang prospek tab - Saya mengartikannya bahwa kami harus mengungkapkan pendapat kami sendiri. Sekarang saya menyadari bahwa saya seharusnya mengirimi Anda email terlebih dahulu, sehingga saya dapat mengungkapkan pendapat Anda, dan menghindari ejekan ad-hominem Anda yang tidak sopan. Permintaan maaf saya.

@ jon64digital @leegee mengatakan mereka tidak ada gunanya _untuk him_, tidak secara umum. Saya sepenuhnya mendukung tab tetapi saya setuju bahwa tab harus menjadi opsi yang dapat dimatikan bagi yang tidak menggunakannya. Mari kita jaga agar diskusi tetap sopan dan tidak menggunakan serangan pribadi. Tidak ada yang memiliki opini yang salah. Mereka hanya itu ... opini.

@ jayrosen1576 Dia telah mengedit komentarnya. Jika awalnya mengatakan "tidak ada gunanya bagi saya" maka tentu saja saya tidak akan mengatakan apa yang saya lakukan. Saya juga berasumsi bahwa dua orang lain yang memberi suara negatif pada komentarnya melakukannya sebelum dia mengeditnya.

Saya sangat setuju bahwa setiap orang berhak untuk memberikan pendapat, tetapi tampaknya ada beberapa orang di sini yang tidak memerlukan tab dalam alur kerja mereka yang berusaha untuk menyangkal mereka yang menginginkannya dengan menempatkan -1 atau memberi tahu MS bahwa fitur tersebut adalah tidak diperlukan atau akan dengan cara tertentu mengalihkan sumber daya dari fitur yang lebih penting. Mengingat bahwa mereka dapat melihat berapa banyak orang yang menginginkan tab, saya merasa ini egois dan sedikit tidak dewasa.

Bagaimanapun, saya minta maaf jika ada yang melihat ini sebagai serangan pribadi. Aku tersenyum setelah itu.

Jika ada yang menurut saya diskusi ini hanya menggambarkan bahwa ada banyak cara pengembang dapat menggunakan IDE dan semuanya valid untuk kasus penggunaannya. Tidak ada cara yang "benar" dan pada akhirnya itu hanya alat untuk menyelesaikan pekerjaan. Beberapa pengembang menyukai tab sehingga mereka dapat secara sewenang-wenang mengelompokkan seperti file dan yang lainnya menemukan satu daftar MRU yang sangat memadai. Kemudian Anda memiliki orang-orang yang hanya menggunakan notepad untuk semuanya dan kami semua adalah sekelompok pansy ha-ha.

Serius, saya hanya merasa bahwa karena tab telah menjadi bagian penting dari Visual Studio selama ini, ada banyak pengembang yang telah terbiasa dengan utilitas mereka dan oleh karena itu membuat daftar MRU tunggal opsional (baik ikut serta atau keluar) akan membuat alat yang sudah luar biasa bahwa VS Code bahkan lebih serbaguna, untuk semua.

@ nub340 tepatnya! beberapa dari kita menyukai tab karena mereka selalu menjadi bagian dari pengalaman kita sebagai pengembang / pengguna, secara pribadi saya suka melihat file yang saya kerjakan di bagian atas, tidak ada keuntungan yang melekat pada tab daripada file yang berfungsi, tetapi begitulah cara beberapa kami menyukainya.

Setuju, saya ingin itu sebagai pilihan, bukan dipaksakan.
Pada Selasa, 22 Mar 2016 pukul 06.22 Eyal Solnik [email protected]
menulis:

@ nub340 https://github.com/nub340 tepatnya! beberapa dari kita menyukai tab karena
mereka selalu menjadi bagian dari pengalaman kami sebagai pengembang / pengguna, secara pribadi saya suka
untuk melihat file yang saya kerjakan di atas, tidak ada yang melekat
keuntungan untuk tab daripada file yang berfungsi tetapi itulah yang sebagian dari kita menyukainya.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

Kami tidak memiliki pengawasan tentang Vic-20 ....

Satu hal yang keluar dari diskusi ini adalah apa pun yang (dibuat)
tersedia, itu harus dapat disesuaikan.

@glennblock , @leegee ya itu pasti harus menjadi pilihan tetapi bukankah file yang berfungsi mendapatkan perlakuan yang sama untuk mereka yang tidak menginginkannya? namun, mungkin yang terbaik adalah mendiskusikannya dalam permintaan fitur lain. :)

Saya telah memposting teks ini di sini: https://github.com/Microsoft/vscode/issues/101

Ini juga berlaku untuk diskusi ini. Saya akan senang melihat tanggapan @bpasero .

Saya ingin fitur ini. Akhir dari diskusi. Persetan pendapat Anda @bpasero Saya tidak peduli apa yang Anda anggap benar dan apa yang tidak. Hal yang sama tentang tab # 224. Anda mencoba meyakinkan kami bahwa solusi Anda lebih baik. Sekali lagi persetan dengan solusi Anda. Kita semua melakukan sesuatu secara berbeda dan tidak ada yang peduli dengan apa yang Anda pikirkan. Saya menggunakan vscode hanya karena dukungan yang bagus dari skrip skrip dan angular2. Kalau tidak, saya benci karena tidak memiliki fitur yang dimiliki editor normal misalnya SublimeText, Atom, Brackets

Haha @PeterMtj , terima kasih telah mengatakan apa yang kita semua pikirkan :)

@bpasero tampaknya memiliki kebiasaan untuk menolak dan mendiskreditkan fitur apa pun yang tidak akan dia gunakan secara pribadi dan tidak sesuai dengan alur kerja pribadinya.

Orang-orang menggunakan perangkat lunak Microsoft terutama karena mereka harus melakukannya, jarang karena mereka menyukainya, dan ketika Anda melihat bahwa staf Microsoft memiliki sikap seperti itu, itu menunjukkan mengapa mereka tidak dapat merancang perangkat lunak yang layak seperti Sublime Text. Saya telah mencoba sekuat tenaga saya dengan VS Code tetapi saya hampir mencopotnya.

@Petertj Serius? itulah cara Anda mendekati sesuatu? mengutuk orang? jika Anda tidak menghormatinya, hormati diri Anda sendiri!

@ jon64digital Dia dapat memilih atau mengatakan pendapat pribadinya dan itu bagus! kita tidak perlu menjadi pribadi dan tentu saja tidak mengutuk orang karena pendapat mereka!

Saya juga tidak setuju dengan tanggapan awalnya, mengatakan "Tidak" tidak profesional dan cukup kasar menurut saya, tetapi saya pikir komunitas dapat berbuat lebih baik dan tetap beradab terlepas dari pendapat orang.

Orang-orang menggunakan perangkat lunak Microsoft terutama karena mereka harus melakukannya, jarang karena mereka menyukainya, dan ketika Anda melihat bahwa staf Microsoft memiliki sikap seperti itu, itu menunjukkan mengapa mereka tidak dapat merancang perangkat lunak yang layak seperti Sublime Text. Saya telah mencoba sekuat tenaga saya dengan VS Code tetapi saya hampir mencopotnya.

Sunting: Orang tidak harus menggunakan produk Microsoft! Saya tentunya tidak harus melakukan itu dan mengatakan bahwa orang-orang jarang melakukannya karena mereka menyukainya, itu hanya omong kosong! Microsoft membuat beberapa produk hebat dan teknologi hebat dan saya jauh dari penggemar segala sesuatu yang mereka lakukan tetapi mereka pasti melakukan beberapa hal dengan benar! tidak ada yang memaksa siapa pun untuk menggunakan VSCode dan jika seseorang memaksa Anda untuk menggunakan VSCode maka dia harus dipecat karena Anda harus memilih alat Anda sendiri! satu-satunya hal yang harus dipedulikan oleh majikan adalah pekerjaan Anda, bukan bagaimana hal itu dilakukan!

Mari kita tidak mengubah ini menjadi perang api dan membuatnya tetap konstruktif, tolong!

@tokopedia

Saya tidak mencoba memulai perang api, atau membicarakan sampah, tetapi saya 100% mendukung apa yang saya katakan. MS secara historis mengikat produk mereka sendiri ke OS mereka dan satu sama lain untuk memaksa orang menggunakan perangkat lunak mereka karena mereka tahu itu tidak cukup baik untuk berdiri sendiri. Saya tahu banyak orang yang harus menggunakan MS Office di tempat kerja, saya harus menggunakan Visual Studio sebelumnya karena saya tidak punya pilihan lain dan saya bisa menghitung jumlah orang yang secara sukarela akan menggunakan Internet Explorer dengan satu jari. Mereka bahkan telah menjadi subjek tuntutan anti-trust karena praktik-praktik ini, jadi mengatakan bahwa tidak ada yang membuat siapa pun menggunakan perangkat lunak MS adalah naif.

Banyak hal telah bergerak ke arah yang benar baru-baru ini dan mereka menjadi lebih agnostik platform dan mencoba membuat interop perangkat lunak mereka lebih baik dengan orang lain. Saya yakin ada orang-orang baik di MS yang mencoba membuat perangkat lunak hebat dan memberi orang apa yang mereka inginkan, tetapi bpasero jelas bukan salah satunya. Sikapnya yang berpikiran tertutup bukanlah penghargaan untuk mereka dan saya pikir itu lucu bahwa @PeterMtj memanggilnya seperti itu. Kita semua adalah orang dewasa di sini dan tidak ada yang boleh tersinggung dengan kata-kata sumpah serapah. Itu hanya sebuah kata.

Anda mendapat untaian panjang di sini dengan ratusan orang memberi tahu MS PERSIS apa yang mereka inginkan dari editor kode. Bukannya mereka tidak tahu apa yang kita inginkan. Kemudian kami memiliki karyawan MS di sini yang mengatakan "tidak, pada dasarnya Anda salah". Bukankah itu menggambarkan sebuah perusahaan yang tidak sepenuhnya selaras dengan audiens mereka?

Hanya 2c saya.

@ jonk

Saya tidak mencoba memulai perang api, atau membicarakan sampah, tetapi saya 100% mendukung apa yang saya katakan. MS secara historis mengikat produk mereka sendiri ke OS mereka dan satu sama lain untuk memaksa orang menggunakan perangkat lunak mereka karena mereka tahu itu tidak cukup baik untuk berdiri sendiri.

Itu hanya asumsi bias Anda dan saya menghormatinya, tetapi kami dapat mengatakan hal yang persis sama tentang perusahaan lain di dunia untuk menyebutkan beberapa Apple, Oracle, dan Google ...

Saya tahu banyak orang yang harus menggunakan MS Office di tempat kerja,

Orang tidak dipaksa untuk menggunakan MS Office, itulah keputusan pemberi kerja, Libre office adalah produk yang hebat dan alternatif yang cukup baik.

Saya harus menggunakan Visual Studio sebelumnya karena saya tidak punya pilihan lain

Saya tidak tahu _mengapa_ Anda tidak punya pilihan tetapi Anda pasti punya pilihan hari ini! Saya selalu punya pilihan bahkan ketika orang banyak menggunakan Visual Studio untuk pengembangan .NET Saya menggunakan SharpDevelop, Vim dan Notepad ++, saya tidak pernah mengalami masalah dalam menggunakan beberapa editor, saya bukan penggemar desainer ...

Untuk C / ++ Anda memiliki lebih banyak dukungan dari editor dan IDE kecuali Anda menggunakan VC ++ :)

Selain itu, saya tidak pernah mengerti mengapa beberapa orang mengunci diri mereka pada tumpukan teknologi tertentu yang dibuat oleh X, ada banyak teknologi di luar sana selain Microsoft.

Saya dapat menghitung jumlah orang yang secara sukarela menggunakan Internet Explorer dengan satu jari.

Anda benar Internet Explorer sangat buruk hingga versi 9 tetapi mereka telah meningkat cukup banyak sejak itu dan meskipun saya pengguna FireFox, saya tidak menilai Microsoft untuk masa lalu mereka, saya menilai mereka untuk siapa mereka saat ini dan itu terlihat bagus!

Mereka bahkan telah menjadi subjek tuntutan anti-trust karena praktik-praktik ini, jadi mengatakan bahwa tidak ada yang membuat siapa pun menggunakan perangkat lunak MS adalah naif.

Tidak ada yang membuat siapa pun menggunakan sesuatu dan saya tidak tahu tentang kebanyakan orang tetapi saya jauh dari naif, saya hanya masuk akal.

Jika atasan Anda membuat pilihan untuk menggunakan teknologi MS, maka Anda pasti _forced_ tetapi sekali lagi itu bukan kesalahan Microsoft, jika Anda membuat pilihan untuk menggunakan teknologi MS maka Anda memilihnya dan mengeluhkannya agak konyol, ada teknologi setara yang sebagus Microsoft sehingga orang pasti punya pilihan.

Banyak hal telah bergerak ke arah yang benar baru-baru ini dan mereka menjadi lebih agnostik platform dan mencoba membuat interop perangkat lunak mereka lebih baik dengan orang lain. Saya yakin ada orang baik di MS yang mencoba membuat perangkat lunak hebat dan memberikan apa yang mereka inginkan,

Persis! meskipun menurut saya memberi orang apa yang mereka inginkan itu tidak baik dari sudut pandang desain. :)

tapi bpasero jelas bukan salah satunya. Sikapnya yang berpikiran tertutup bukanlah penghargaan untuk mereka dan saya pikir itu lucu bahwa @PeterMtj memanggilnya seperti itu. Kita semua adalah orang dewasa di sini dan tidak ada yang boleh tersinggung dengan kata-kata sumpah serapah. Itu hanya sebuah kata.

Menurut saya kita tidak perlu mendefinisikan orang berdasarkan pendapat mereka, tentu saja bukan pendapat semacam ini dan menjadi dewasa tidak membuat orang rentan terhadap serangan pribadi dalam bentuk apa pun, mengumpat seseorang tidak menyenangkan dan harus berkecil hati, Bertindak sebagai orang dewasa berarti Anda dapat mengendalikan amarah Anda dan menulis opini Anda tentang seseorang atau sesuatu tanpa menyinggung perasaan.

Anda mendapat untaian panjang di sini dengan ratusan orang memberi tahu MS PERSIS apa yang mereka inginkan dari editor kode. Bukannya mereka tidak tahu apa yang kita inginkan. Kemudian kami memiliki karyawan MS di sini yang mengatakan "tidak, pada dasarnya Anda salah". Bukankah itu menggambarkan sebuah perusahaan yang tidak sepenuhnya selaras dengan audiens mereka?

Itu poin dan keluhan yang adil, saya tidak mengatakan sebaliknya! tetapi @bpasero telah menyatakan bahwa setelah mereka akan mengerjakan UX, mereka akan mengatasi masalah ini juga "_Setelah kami memulai diskusi UX dalam tim, kami ingin melibatkan komunitas juga dan kami juga akan mendiskusikan kekurangan yang kami lihat dalam desain kami saat ini dan apa yang kami rencanakan untuk ditingkatkan._ "

@eyalsk Ya, itulah cara saya mendekati ini dan saya tidak akan

@ jon64digital benar tentang sikap @bpasero . Saya tidak tahu harus berpikir apa tentang dia. Mungkin dia hanya ingin berhenti bekerja dengan mengatakan Anda salah dan itu tidak diperlukan. Dengan cara apa pun @bpasero mungkin seharusnya tidak berkomunikasi dengan komunitas dengan sikapnya. Itu pendapat saya.

Cobalah untuk menyadari bahwa Microsoft tidak membantu kami. Kami membantu Microsoft dengan menggunakan produknya dan dengan memberikan umpan balik sehingga mereka dapat membuat produk yang layak. Ini seharusnya bukan diskusi tentang mempertahankan tab, tetapi tentang bagaimana tab harus bekerja sehingga bersifat alami dengan vscode. Vscode adalah untuk komunitas, itulah kami dan dalam kasus ekstrim jika kita semua ingin dinosaurus merah di tengah layar, mereka harus melakukannya tanpa mempertanyakan alasan. Kita semua punya alasan masing-masing. Jika tidak, vscode tidak berguna untuk komunitas. Begitulah cara saya melihatnya.

@PeterMtj Saya kira kita harus setuju untuk tidak setuju. :)

Saya ingin terjun dan memberikan beberapa latar belakang tambahan untuk masalah ini. Kami baru saja menyelesaikan tonggak utama Kode. Fokus utama kami dalam 6 bulan terakhir adalah dukungan untuk aksesibilitas dan lokalisasi. Hal ini membuat kami tidak memiliki siklus di area UI untuk bekerja secara aktif pada masukan Tab. Sekarang sebagian besar kotak centang pada rencana Maret (# 3555) dicentang, kami perlahan mulai mencari lagi. Pada bulan April kami akan meningkatkan topik ini. @bpasero memainkan peran kunci dalam pengembangan UX kami dan ini akan menjadi evolusi besar berikutnya.

Terima kasih semuanya atas semangat dan masukan Anda, membantu kami membuat VS Code menjadi produk terbaik.

TIA untuk tambahan aksesibilitas - akan membuat perbedaan besar bagi kami
setengah buta

Pada Sabtu, 26 Mar 2016, 01:38 Erich Gamma, [email protected] menulis:

Saya ingin terjun dan memberikan beberapa latar belakang tambahan untuk masalah ini.
Kami baru saja menyelesaikan tonggak utama Kode. Fokus utama kami
dalam 6 bulan terakhir adalah dukungan untuk aksesibilitas dan lokalisasi. Ini
tidak meninggalkan kami siklus di area UI untuk secara aktif bekerja pada masukan Tab.
Sekarang sebagian besar kotak centang pada rencana Maret (# 3555
https://github.com/Microsoft/vscode/issues/3555) dicentang, kami siap
perlahan mulai mencari lagi. Pada bulan April kami akan meningkatkan topik ini.
@bpasero https://github.com/bpasero memainkan peran kunci dalam
pengembangan UX kami dan ini akan menjadi evolusi besar berikutnya.

Terima kasih semuanya atas semangat dan masukan Anda, membantu kami membuat VS Code the
produk terbaik.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

@egamma Saya sangat berterima kasih kepada Anda dan tim Anda untuk semuanya, saya pikir Anda melakukan pekerjaan dengan baik! tapi saya merasa tanggapan pertama yang dibuat oleh @bpasero membuat orang jengkel dan ini bisa dihindari jika dia memberikan wawasan tentang mengapa menurutnya tab seharusnya tidak menjadi pilihan daripada hanya mengatakan "Tidak".

Oya, fokus ke saat ini, apa ada build baru sebelum // build / event? : D

@eyalsk Saya yakin komentar "Tidak" sebenarnya mengacu pada balasan pertama dari @inakianduaga , karena tidak mungkin menerapkan tab menggunakan API ekstensi saat ini. Saya pikir ini disalahpahami dengan mengatakan bahwa tab tidak akan pernah terjadi, namun masalahnya mungkin akan ditutup jika itu masalahnya.

@Tyriar , terima kasih gotcha! :)

Oya, fokus ke saat ini, apa ada build baru sebelum // build / event? : D

Bit untuk build baru sudah menunggu Anda di saluran orang dalam ( catatan rilis ), silakan gunakan dan beri kami umpan balik.

@egamma terima kasih! ;)

Kami memulai pekerjaan desain berdasarkan pengalaman ini dan ingin melibatkan komunitas sebanyak yang kami bisa. Saya akan menjalankan diskusi desain reguler saat kami membuat kemajuan untuk mendapatkan umpan balik Anda. Paling sering ini akan menjadi sesi satu lawan satu di mana kami membagikan apa yang sedang kami kerjakan dan mendiskusikannya dengan Anda.

Sesi pertama akan berlangsung Rabu ini. Silakan daftar di sini jika Anda tertarik: https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

Hebat!
Pada hari Senin, 4 Apr 2016 jam 3:54 Steven Clarke [email protected]
menulis:

Kami memulai pengerjaan desain pada pengalaman ini dan ingin melakukannya
libatkan komunitas sebanyak yang kami bisa. Saya akan menjalankan desain biasa
diskusi saat kami membuat kemajuan untuk mendapatkan umpan balik Anda. Paling sering ini akan
jadilah sesi satu lawan satu di mana kami berbagi apa yang sedang kami kerjakan dan diskusikan
mereka bersamamu.

Sesi pertama akan berlangsung Rabu ini. Silakan daftar di sini jika
Anda tertarik:
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

Kami menantikan masukan Anda tentang desain baru yang sedang kami jelajahi terkait masalah ini. Jika Anda tertarik, silakan daftar melalui tautan di komentar @stevencl di atas!

3 dan 4 pagi saja? Tidak ada waktu lain? Saya tidak bisa membuat jam 3/4 pagi PST pada hari Rabu.

Pada hari Senin, 4 Apr 2016 jam 8:14 Brad Gashler [email protected]
menulis:

Kami menantikan masukan Anda untuk desain baru yang sedang kami jelajahi
terkait dengan masalah ini. Jika Anda tertarik, silakan daftar melalui tautan di
Steven komentar di atas!

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

Alangkah baiknya kalau punya timing sesuai PST, banyak (termasuk saya) bisa ikut

{Seluler}

Pada hari Sen, 4 Apr 2016 pukul 08.50 -0700, "Glenn Block" [email protected] menulis:

3 dan 4 pagi saja? Tidak ada waktu lain? Saya tidak bisa membuat jam 3/4 pagi PST pada hari Rabu.

Pada hari Senin, 4 Apr 2016 jam 8:14 Brad Gashler [email protected]

menulis:

Kami menantikan masukan Anda untuk desain baru yang sedang kami jelajahi

terkait dengan masalah ini. Jika Anda tertarik, silakan daftar melalui tautan di

Steven komentar di atas!

-

Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub

https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub

Ya silahkan. Saya pasti ingin menjadi bagian dari percakapan.

Maaf, saya tahu waktu ini tidak cocok untuk semua orang. Di masa mendatang kami akan mencari cara untuk menjadwalkan sesi di zona waktu yang berbeda karena kami berencana untuk mengadakannya secara teratur.

Mengapa tidak menjadwalkan tambahan minggu ini pada waktu yang berbeda? Ini adalah sebuah
topik hangat dengan banyak minat.

Pada hari Senin, 4 Apr 2016 jam 9:44 Steven Clarke [email protected]
menulis:

Maaf, saya tahu waktu ini tidak cocok untuk semua orang. Di masa depan kami
akan mencari cara untuk menjadwalkan sesi di zona waktu yang berbeda seperti yang kita lakukan
berencana untuk mengadakannya secara teratur.

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

Sekadar info, slot waktu yang Anda lihat hanyalah slot yang masih tersedia. Saya memiliki slot yang terbuka di kemudian hari tetapi itu diambil cukup cepat.

Seperti yang saya katakan, kami akan mencoba menjadwalkan sesi di zona waktu berbeda di masa mendatang.

Terima kasih atas perhatiannya.

Saya mengerti, saya rasa mereka langsung terisi (yang bagus)
Pada hari Senin, 4 Apr 2016 jam 11:30 Steven Clarke [email protected]
menulis:

Asal tahu saja, slot waktu yang Anda lihat hanyalah slot yang ada
masih ada. Saya memiliki slot terbuka di kemudian hari tetapi itu sudah diambil
cukup cepat.

Seperti yang saya katakan, kami akan mencoba menjadwalkan sesi di zona waktu yang berbeda
masa depan.

Terima kasih atas perhatiannya.

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

Dapatkah Anda / apakah Anda merekam sesi?

Pada hari Senin, 4 Apr 2016 jam 11:32 Glenn Block glenn. [email protected] menulis:

Saya mengerti, saya rasa mereka langsung terisi (yang bagus)
Pada hari Senin, 4 Apr 2016 jam 11:30 Steven Clarke [email protected]
menulis:

Asal tahu saja, slot waktu yang Anda lihat hanyalah slot yang ada
masih ada. Saya memiliki slot terbuka di kemudian hari tetapi itu sudah diambil
cukup cepat.

Seperti yang saya katakan, kami akan mencoba menjadwalkan sesi di zona waktu yang berbeda
masa depan.

Terima kasih atas perhatiannya.

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

Seandainya saya telah melihat ini sebelumnya sehingga saya bisa mendaftar. Untuk apa nilainya, saya harap Anda tidak pernah menerapkan tab. Saya telah berkembang dari vim ke TextMate ke Sublime ke Atom dan sekarang ke VS Code (dengan banyak IDE di sepanjang jalan), jadi saya memiliki BANYAK pengalaman dengan tab. Bagi saya mereka adalah penopang yang digunakan orang dan tidak pernah bisa lewat. Mengelola banyak tab terbuka pada proyek besar adalah latihan frustrasi yang menambah satu tugas lagi yang tidak saya perlukan. Lupakan untuk menutup beberapa dan dengan cepat menjadi tidak ada harapan. Kepada beberapa dari Anda yang memiliki disiplin untuk tidak pernah mengalami ini, pujian. Tetapi mengapa menghabiskan energi mental untuk tugas yang tidak perlu?

Lebih penting lagi, menurut saya tab menyebabkan orang berpikir dalam istilah FILES, ketika (untuk sebagian besar pengembangan kode) mereka harus berfokus pada fungsi, kelas, ruang nama - simbol. File adalah detail implementasi dalam banyak kasus yang seharusnya tidak mendominasi navigasi Anda. Saya pikir VS Code memiliki peluang nyata untuk memberikan sesuatu yang baru dan lebih baik.

Saya menyadari bahwa ini hanyalah preferensi SAYA, dan saya mengerti mengapa banyak orang meminta tab menjadi opsional. Ini mungkin tampak seperti kompromi yang masuk akal, tetapi akan sulit untuk mendukung dua alur kerja navigasi yang berbeda dengan baik. Coba matikan saja plugin tab di Atom dan lihat berapa banyak hal yang tidak berfungsi atau bekerja dengan buruk karena pengembang mengharapkan tab ada di sana. Jadi untuk alasan egois saya sendiri, saya ingin pengembang VS Code fokus pada navigasi yang bukan berbasis tab (atau bahkan file).

Ditto @indiejames

Jika Anda menerapkan tab, dukung beberapa baris untuk banyak file. Saya benci memiliki scrollbar di bilah tab saya. Penerapan tab favorit saya adalah Tabs Studio . Lihat juga bagaimana file dengan nama dasar yang sama dapat dikelompokkan bersama secara otomatis.

Alur kerja saya, saya membuka tab saat saya bekerja di Sublime sesuai kebutuhan. Saya tidak membiarkan banyak tab terbuka dan saya sering menggunakan "tutup semua" untuk mengembalikan semuanya ke daftar yang bersih.

Saya telah mengembangkan lebih dari 30 tahun di berbagai IDE dan editor teks. Saya tidak melihat tab sebagai penopang, itu adalah alat organisasi yang berguna. Ya, mereka bisa lepas kendali jika Anda memiliki banyak tab, tetapi saya tidak ....

Dalam hal tab yang condong ke fokus pada file dan semacamnya, kode hidup dalam file, dan file ARE digunakan untuk organisasi, dan kode VS dibuat untuk mengelola folder dan file kode.

Saya benar-benar mendapatkan beberapa mungkin lebih suka tidak memiliki tab dan saya tidak mengatakan untuk menyingkirkan apa yang ada di sana tetapi memiliki alur kerja tab yang didukung akan menyenangkan.
Pada Selasa, 5 Apr 2016 jam 7:32, pemberitahuan [email protected] menulis:

Jika Anda menerapkan tab, dukung beberapa baris untuk banyak file. Aku benci
memiliki scrollbar di bilah tab saya. Penerapan tab favorit saya adalah Tab
Studio https://tabsstudio.com/.

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

"Ini mempermudah pengguna untuk menyalahgunakan produk" adalah alasan yang buruk untuk tidak mendukung fitur. Alat tersebut ada untuk _fasilitasi_ alur kerja, bukan untuk _ mendiktekan_ alur kerja tersebut. Jika pengguna tidak dapat menemukan alur kerja yang nyaman, pengguna tersebut lebih cenderung memilih alat lain di mana mereka bisa, daripada beradaptasi dengan paradigma yang tidak biasa.

Saat ini saya sedang mengerjakan beberapa file yang terkait erat, berpindah-pindah di antara mereka. Setiap kali saya perlu beralih, saya harus memilih dari sidebar atau drop down, yang memakan waktu 3-4 kali lebih lama dari sebuah tab.

@indiejames

tetapi akan sulit untuk mendukung dua alur kerja navigasi yang berbeda dengan baik. Coba saja mematikan plugin tab di Atom dan lihat bagaimana hal-hal tidak bekerja atau bekerja dengan buruk karena pengembang mengharapkan tab ada di sana. Jadi untuk alasan egois saya sendiri, saya ingin pengembang VS Code fokus pada navigasi yang bukan berbasis tab (atau bahkan file).

Tidak terlalu sulit untuk mendukung dua alur kerja navigasi yang berbeda atau bahkan lebih dari dua, yang sangat sulit adalah mendapatkan desain yang tepat!

Jika Anda benar-benar ingin mendukung tab dan file kerja atau alur kerja lain, Anda perlu mundur beberapa langkah, melakukan zoom out dan mendesain ulang navigasi dari awal, menjadikan alur kerja sebagai strategi yang dapat dipilih orang.

Membuat ekstensi hanya untuk memiliki tab di editor tanpa mempertimbangkan kasus penggunaan dan bagaimana orang bekerja dengan tab atau alur kerja lain hanya kehilangan penyebab yang tidak memberikan manfaat nyata dan kemungkinan besar gagal.

Ada perbedaan antara navigasi kode dan navigasi file, ketika Anda membuat kode, Anda pasti perlu
berpikir tentang simbol daripada file tetapi kode tinggal dalam file dan terkadang Anda perlu menanganinya juga misalnya saya tidak membuka banyak tab tetapi ketika saya mengerjakan banyak proyek, saya biasanya memiliki satu file per proyek terbuka yang terkait, saya sering menggunakan tombol pintas tetapi karena tab selalu di atas, dan ketika saya melihat editornya, tab itu selalu ada, mungkin psikologis tetapi itu hanya membantu saya fokus.

Pengalaman Anda dengan tab sangat disayangkan dan saya tidak meremehkan pengalaman Anda sama sekali, saya tidak tahu bagaimana Anda bekerja tetapi banyak dari kita menyukainya dan menggunakannya dengan sukses besar.

Saya tidak berpikir bahwa satu pengalaman lebih baik dari yang lain tetapi memiliki pengalaman yang berbeda atau bahkan campuran dapat membantu dan editor harus menghormati pengalaman saya, bukan menentangnya.

Akan sangat membantu bagi kami yang tidak dapat hadir karena ada komitmen lain untuk dapat memberikan umpan balik.
Mungkin, setelah rapat selesai pada hari pertama, poskan video rapat (dengan izin semua pihak yang terlibat) yang dapat dilihat dan dikomentari oleh orang lain dalam sisa waktu rapat?

Jelas ini tidak bisa menjadi waktu yang lama tetapi lebih banyak umpan balik tidak ada salahnya dengan mudah-mudahan beberapa sudut pandang yang berbeda ditambahkan.

Saya sangat berharap beberapa Python devs dan c / c ++ devs akan hadir dalam rapat karena alur kerja mereka berbeda dengan alur kerja developer JavaScript

Terima kasih Steven telah meluangkan waktu untuk berbicara dengan saya!
Keterlibatan dengan komunitas ini sangat menggembirakan, dan saya menikmatinya
mengikuti pengembangan vscode!

Pada 6 April 2016 pukul 19:41, Michael Wallace Louwrens < [email protected]

menulis:

Akan sangat membantu bagi kami yang tidak dapat membuat pertemuan karena orang lain
komitmen untuk dapat memberikan umpan balik.
Mungkin, setelah rapat selesai pada hari pertama, poskan video a
pertemuan (dengan izin semua yang terlibat) yang dapat dilihat dan dikomentari oleh orang lain
dalam sisa waktu rapat?

Jelas ini tidak bisa menjadi waktu yang lama tetapi lebih banyak umpan balik tidak ada salahnya
semoga beberapa sudut pandang yang berbeda ditambahkan.

Saya sangat berharap beberapa Python devs dan c / c ++ devs akan ada dalam pertemuan tersebut sebagai
alur kerjanya berbeda dengan alur kerja pengembang JavaScript

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

Terima kasih @TurkeyMan , senang mengobrol dengan Anda hari ini.

Untuk semua orang yang belum dapat berpartisipasi, kami akan menjalankannya secara rutin sehingga akan ada kesempatan untuk berpartisipasi di kemudian hari.

Percakapan yang kami lakukan minggu ini semuanya adalah percakapan 1: 1 di mana kami membahas detail masalah yang dialami setiap individu. Ini memungkinkan kami untuk mendapatkan pemahaman yang lebih dalam tentang masalah yang perlu kami selesaikan.

Dalam minggu-minggu berikutnya ketika kami akan meninjau maket desain, kami akan mencari cara untuk melakukan diskusi kelompok serta diskusi 1: 1. Kami juga akan melihat bagaimana kami dapat merekam dan memposting video pertemuan sesudahnya.

@stevencl apakah mungkin untuk memposting ringkasan sesi (atau bahkan lebih baik, rekaman) bagi kita yang tidak dapat berpartisipasi, tetapi masih tertarik untuk memberikan umpan balik.

+1
Pada Rabu, 6 Apr 2016 pukul 7:36 Peter Petrov [email protected]
menulis:

@stevencl https://github.com/stevencl apakah mungkin untuk memposting ringkasan
sesi (atau bahkan lebih baik, rekaman) bagi kita yang tidak mampu
untuk berpartisipasi, tetapi masih tertarik untuk memberikan masukan.

-
Anda menerima ini karena Anda disebutkan.

Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

Saya ingin memanfaatkan ekspektasi saya tentang navigasi file dalam editor kode. Saya sudah mencoba membiasakan diri dengan VScode selama berminggu-minggu sekarang dan terus kembali ke Sublime. Inilah yang saya harapkan:

1. navigasi tanpa mouse
2. kemampuan untuk menavigasi maju dan mundur dalam kumpulan file yang terbuka
3. tutup file dengan mudah

Sejauh ini saya menemukan VScode sayangnya gagal untuk saya pada ketiganya. Ruang kerja tidak intuitif karena ketika saya menutup file, file tidak benar-benar tertutup, tidak lagi dapat diedit. Menutup file adalah aktivitas mental untuk menghapusnya dari kumpulan file yang saya kerjakan.

Di VScode, ketika saya menavigasi di dalam file yang dibuka _ di kepala saya_ saya terus menemukan "sampah" yang saya pikir sebelumnya dibuang. Ini sangat mengganggu dan saya akhirnya memiliki file 20-ish dibuka di ruang kerja dan akhirnya tidak dapat lagi melacaknya dan menutup semuanya.

Saya tidak dapat menggunakan keyboard untuk dengan cepat beralih di antara file yang dibuka, yang _di kepala saya_ membentuk daftar tertaut. Urutan yang saya buka sama pentingnya dengan urutan yang saya tutup. Saya menemukan Ctrl + Tab tidak berguna karena saya harus membaca nama file satu per satu dalam daftar itu dan kemudian mencari tahu ke tab mana. Saya dapat lebih cepat untuk membalik 5-8 file yang dibuka ke file yang benar dengan hanya mengenali konten saat berkedip atau dengan hanya mengetahui di mana dalam "daftar" file yang saya inginkan berada.

Saya harap itu masuk akal. Saya mencoba untuk mengoptimalkan alur kerja saya sebanyak mungkin, menggunakan keyboard dan menghindari mouse karena itu sangat memperlambat segalanya. Saya berjuang dengan ini di VScode lebih dari yang saya miliki sebelumnya di editor lain (textmate, vim, sublime, flash, eclipse, dll ...)

Sekadar untuk mengulangi, rekaman pertemuan apa pun yang terjadi minggu ini tidak akan tersedia karena setiap pertemuan adalah percakapan 1: 1 di mana setiap orang membahas detail cara kerja mereka dan masalah spesifik yang mereka hadapi dengan VS Code. Selama percakapan ini kami tidak akan membahas detail tentang desain apa pun.

Namun dalam minggu-minggu berikutnya kami akan mencari peluang untuk merekam dan menyediakan pertemuan di mana kami membahas desain untuk meningkatkan manajemen dokumen di VS Code. Carilah undangan lain dari saya pada minggu depan untuk berpartisipasi dalam diskusi desain putaran berikutnya.

Terima kasih atas semua umpan balik dan detail tentang bagaimana VS Code bekerja atau tidak untuk Anda.

Hanya karena tampaknya tidak ada yang menyebutkannya dan saya curiga saya tidak sendirian dalam hal ini: bagi saya tab di editor adalah tentang memori spasial - yaitu di mana saya, dan di mana hal-hal di sekitar saya?

Kita hidup di dunia fisik. Kami telah berevolusi untuk memahami dan membuat intuisi tentang ruang di sekitar kami dan kami melakukannya tanpa berpikir. Inilah mengapa kami dapat mengetik tanpa melihat keyboard - kami "hanya tahu" di mana tombol tersebut berada dan dapat mengetik dengan cepat. Dengan tab, perangkat basah bawaan bawaan tempat kami lahir dapat bekerja dan kami tahu "di mana" file berada di layar dan kami dapat mengasahnya tanpa berpikir karena nalurinya yang kami gunakan setiap hari. Saya "meletakkan file" seolah-olah melalui tab di editor, dan dapat mengingat "di mana saya meninggalkannya" dengan cara yang persis sama seperti yang saya ingat di mana saya meletakkan remote TV saya saat saya perlu mengganti saluran ( dengan asumsi saya punya TV lagi)

Bagi saya, riwayat file berurutan waktu benar-benar bertentangan dengan pemahaman intuitif tentang ruang ini. Jika saya tahu bahwa "main.java" atau tombol T pada keyboard saya berada dalam posisi tertentu, saya tidak ingin tombol itu bergerak kecuali saya secara fisik & sengaja memindahkannya. Jika itu bergerak sendiri, saya perlu berhenti dan berpikir dan menemukannya. Bayangkan remote TV dengan roda yang bergerak sendiri di sekitar rumah Anda sendiri, atau keyboard yang mengatur ulang tombol berdasarkan seberapa baru Anda menggunakan setiap huruf! Ini akan menjadi kekacauan! :-)

Saya sangat suka VSCode, tetapi secara pribadi saya frustrasi & diperlambat oleh kurangnya tab. Pertahankan kerja yang baik - saya berharap untuk melihat apa yang Anda hasilkan!

@ nugrohoim
Apa yang Anda gambarkan persis apa yang membuat tab begitu membatasi (bagi saya). Tab adalah metafora untuk tab fisik yang ditempatkan pada file dalam lemari file fisik, dan memiliki semua batasan yang sama. Saya lebih suka memiliki lemari file otomatis di mana saya dapat mengetik beberapa kunci dan melompat ke informasi saya daripada yang fisik di mana saya harus menyortir sendiri dan mengelola ruang terbatas untuk tab yang terlihat.

Saya penasaran - apakah Anda menavigasi tab menggunakan mouse / trackpad atau menggunakan kombinasi tombol di editor lain?
Jika Anda menggunakan pintasan keyboard secara eksklusif maka mungkin Anda memiliki beberapa alur kerja tab yang tidak saya sadari
dari dan saya ingin melihatnya. Saya menduga, bagaimanapun, bahwa banyak orang menggunakan mouse / trackpad - tidak menyadari betapa tidak produktifnya pengalih konteks itu dan betapa memperlambat mereka untuk melepaskan tangan mereka dari tombol. Mudah dipelajari dan mudah dipahami, tetapi kurang kuat / produktif dibandingkan menggunakan kombinasi tombol. Jika Anda menemukan diri Anda "meraih tab" dengan mouse, itu mungkin intuitif dan mungkin memanfaatkan indra spasial Anda, tetapi memperlambat Anda. Tidak begitu banyak waktu yang hilang karena gerakan fisik, tetapi dalam konteksnya sendiri.

Saya menyadari ini hanya pendapat saya dan kebanyakan orang tidak setuju dengan mereka, tetapi Visual Studio _Code_. Untuk pembuat kode / pengembang. Dan pengembang sudah lama menyadari bahwa shell> gui untuk sebagian besar (tidak semua) hal, dan metafora desktop, meskipun mudah dipelajari, cukup membatasi.

Jadi, mungkinkah _hanya mungkin_ bahwa beberapa dari Anda yang mengatakan "Saya tidak dapat hidup tanpa tab" belum mempelajari alur kerja lainnya? Jika demikian, bukankah ada gunanya mencobanya jika hasilnya akan meningkatkan produktivitas Anda?

Bagi Anda yang telah mencoba bekerja tanpa tab dan tidak dapat beradaptasi atau secara jujur ​​merasakan tab membuat Anda lebih produktif, saya dapat menerima bahwa ini hanyalah ketidaksepakatan yang jujur. Tetapi bagi mereka yang memperdebatkan metafora fisik karena "mereka telah bekerja selama 30 tahun!" Saya akan bertanya apakah kita benar-benar membutuhkan _another_ TextMate / Sublime / Atom? Bukankah kita harus mencoba memindahkan amplopnya?

Saya yakin saya termasuk minoritas di sini (tapi itu tidak membuat saya salah), jadi ini adalah komentar terakhir yang akan saya buat. Jangan ragu untuk menumpuk :)

Memutuskan untuk memeriksa VS Code untuk melihat apakah itu bisa menjadi pengganti gratis untuk Sublime, tetapi tanpa dokumen tab, ini bukan pemula. Mampu mengatur VS Code dalam satu instance, membuka banyak dokumen, dan dengan mudah beralih di antara mereka adalah persyaratan dasar dari editor teks apa pun. Menjaga Explorer tetap terbuka adalah solusi, tetapi bukan hal yang aneh untuk memiliki tab kiri daripada tab atas seperti di VS, browser, Sublime, dll. Ctrl-Tab memiliki beberapa masalah, salah satunya harus melihat keyboard dan menggerakkan tangan (untuk sesuatu selain mouse), yang lainnya adalah tidak intuitif. Siapa pun yang menyarankan bahwa editor tanpa tab adalah lebih dari BloatedNotepad jelas tidak pernah melakukan pengeditan serius pada banyak dokumen, seperti yang diperlukan ketika debugger-melangkah melalui sesuatu yang memiliki lebih dari 1 file sebagai input kompiler.

@indiejames
Tab bukanlah tentang produktivitas bagi saya. Ini tentang kognisi.

Saya pribadi tidak pernah menemukan bahwa kecepatan mengetik mentah pernah menjadi faktor pembatas dalam produktivitas saya. Pemrograman membutuhkan pemikiran dan pertimbangan - beberapa klik bukanlah masalah dalam skema besar bagi saya mengingat berapa banyak waktu yang kita habiskan untuk _pikir_.

@indiejames Saya menggunakan tab ctrl + (shift +) untuk bernavigasi di antara banyak tab, tidak harus mouse. Salah satu keluhan terbesar saya dengan file yang berfungsi adalah sama dengan @ matt1 - fakta bahwa ctrl + tab beroperasi dalam urutan yang paling terakhir digunakan. Saya tidak terlalu ingat file apa yang saya lihat terakhir dan kedua dari terakhir, tetapi sangat mudah bagi saya untuk melihat / mengingat urutan apa yang saya buka / atur. Sublime Text juga mengatur default ctrl + (shift +) tab ke MRU memesan; Saya selalu mengubahnya, karena memiliki perintah untuk MRU dan urutan yang terlihat.

Saya ingat kembali pada hari itu beberapa browser Web (mungkin Opera pre-blink?) Menggunakan MRU untuk ctrl + tab secara default juga, mungkin membayangkan bahwa karena OS melakukannya untuk aplikasi, browser mungkin juga melakukannya; Saya merasa sangat tidak intuitif, dan harus memberikan perhatian ekstra untuk menemukan apa yang sebenarnya ingin saya alihkan kembali ke ... yang, coba tebak, membuat proses _slower_.

Argumen menggunakan buka cepat secara eksklusif juga berfungsi dengan baik di Sublime Text dengan tab seperti halnya di VS Code dengan file yang berfungsi. Tab sama sekali tidak melarang alur kerja itu.

Bagi mereka yang lebih suka pendekatan File Kerja saat ini dalam VS Code, berapa banyak dari Anda yang sebenarnya lebih suka mengklik file dalam daftar File Kerja dibandingkan dengan alur kerja berikut?

• menggunakan Ctrl + E / ⌘ + E untuk membuka file terbaru dengan cepat.
• menggunakan Ctrl + Tab untuk mengganti file terbaru

Omong-omong, bagi mereka yang lebih suka tab , umpan balik Anda sangat membantu saat kami menyelidiki cara menambahkannya ke produk. Terima kasih banyak telah terus berbagi!

@bayu_joo
Saya lebih suka pintasan keyboard. Bukan berarti saya bisa menjadi juru ketik tercepat, tetapi karena menurut saya tidak terlalu mengganggu maka saya harus menggerakkan mouse / trackpad.

Menurut saya, apa yang banyak dari kerumunan "File yang Bekerja dan Tidak Ada Tab PERNAH" hilang adalah _way_ di mana banyak dari kita menggunakan tab. Misalnya, ketika saya mengerjakan aplikasi MVC (web, seluler atau desktop) saya cenderung memiliki tab di satu atau lebih panel vertikal (yang juga membutuhkan VSCode) dalam urutan tertentu: Model file, View File, Controller file . Jadi pengaturan yang sering saya buka terlihat seperti ini:

Panel Kiri

Berkas Model 1 (tab) | Lihat 1 File (tab) | Pengontrol 1 File (tab)

Panel Kanan

Berkas Model 2 (tab) | Lihat 2 File (tab) | Pengontrol 2 File (tab)

Pengaturan ini memungkinkan saya untuk dengan cepat memilih file Model untuk kedua komponen yang saya kerjakan untuk perbandingan atau Melihat File ketika saya menggunakan topi UI / UX saya. Ini benar-benar TIDAK DAPAT dilakukan secara efisien dengan file kerja, terutama jika Anda memiliki file lain yang terbuka juga (mis. CSS, skrip db, dll). Saya melakukan banyak UI / UX dan sejauh ini praktik umum. Jika saya benar-benar pengembang backend Java atau DBA, maka tidak, ini bukan persyaratan. Tetapi bagi sebagian besar dari kita pengembang web & seluler tumpukan penuh, tidak memiliki tab (dan panel vertikal / horizontal bertab) adalah penghalang yang ekstrem. Sementara saya membuat karena dengan VSCode dalam jangka pendek, saya memiliki keraguan serius untuk bertahan karena kemampuan yang hilang ini. Tidak ada yang dapat meyakinkan kami bahwa tab tidak berguna dan daftar file yang berfungsi bukanlah inovasi (Adobe Brackets juga memiliki daftar file yang berfungsi dan sudah ada sejak 2012).

Sekali lagi, ini bukanlah masalah semua atau tidak sama sekali. Kami hanya meminta kemampuan yang sama yang ada di editor lain sebagai opsi meskipun kapabilitas itu dimatikan secara default. Jika VSCode mengimplementasikan tab / panel jendela persis seperti yang dilakukan Atom, itu akan menyelesaikan 99,99% keluhan terkait tab kami. Saya tahu ini bukan tugas yang sepele untuk diterapkan, namun saya pikir banyak dari kita akan puas menunggu sedikit lebih lama (berbulan-bulan, bukan bertahun-tahun) agar fitur ini dilakukan dengan benar daripada tertinggal di backlog.

Hanya 2 ¢ saya ...

Meskipun saya sudah mengkomunikasikan sebagian besar hal ini ke @ bgashler1 , saya akan menulis sedikit di sini untuk menjelaskan perilaku ideal saya.

1. Keybindings harus menutup file yang berfungsi, menghapusnya dari daftar file kerja dan tumpukan MRU (yang terakhir digunakan). Saya memiliki keybindings berikut untuk mencapai ini:

json { "key": "ctrl+shift+w", "command": "workbench.files.action.closeAllFiles" }, { "key": "ctrl+w", "command": "workbench.files.action.closeFile" },

1. File di editor harus "ditumpuk", sehingga saat Anda menutup satu file, file terakhir dalam tumpukan MRU akan ditampilkan.
2. ctrl + shift + t akan mengembalikan tab yang terakhir ditutup. Pengikatan kunci ini bertentangan dengan workbench.action.tasks.test di vscode tetapi ini adalah tombol pintas yang sangat standar di lingkungan bertab. Saya membuat permintaan fitur untuk perintah di sini https://github.com/Microsoft/vscode/issues/3989
3. ctrl + tab dan ctrl + shift + tab hanya boleh memutar melalui file dalam daftar "file kerja", bukan file yang "dipratinjau" (satu klik di penjelajah dan kemudian keluar).
4. Saya ingin file kerja saya diletakkan di bagian atas editor. Alasannya adalah:
   
   
   
   • Saya ingin dapat melihat file kerja saya secara visual, terlepas dari sidebar mana yang telah saya buka. Terkait: https://github.com/Microsoft/vscode/issues/3360
   
   
   • Selama hampir 2 dekade saya telah memprogram, saya telah melihat di atas editor untuk file kerja saya. Ini kebiasaan yang sulit dihentikan.
   
   

@bpasero

Omong-omong, bagi mereka yang lebih suka tab, umpan balik Anda sangat membantu saat kami menyelidiki untuk menambahkannya ke produk. Terima kasih banyak telah terus berbagi!

Saya menggunakan Ctrl + Tab cukup banyak di VSCode tetapi menurut saya pengalaman di Visual Studio jauh lebih baik karena selain file saya juga dapat menavigasi ke bagian lain dari UI, saya menggunakannya untuk menavigasi ke Manajer Konsol Paket, Penjelajah Solusi dll ...

@Tyriar Poin bagus!

[Peringatan Filsafat!]

Mengapa ctrl+tab jauh lebih berguna daripada konsep 'file yang bekerja', seperti berdiri? Inilah pertanyaan intinya. Secara pribadi, saya pikir ada dua masalah yang sedang dimainkan.

Pertama, ctrl+tab adalah pintasan keyboard dan pintasan keyboard secara tidak sadar terkait dengan tanda sisipan - pengguna mengharapkan bahwa ctrl+tab akan mengubah file di editor saat ini, tempat tanda sisipan saat ini ditempatkan, dan itu tepatnya apa yang dilakukannya. Ini tidak seperti 'file yang berfungsi' atau navigator yang tidak terkait dengan editor tertentu - mereka secara horizontal menjauhi semua kecuali satu editor dan terkait dengan editor _most recent_ - dan biasanya digunakan dengan mouse. Bahkan jika Anda menggunakannya dengan keyboard, Anda telah keluar dari tanda sisipan pada saat Anda memilih file.

Kedua, ctrl+tab menunjukkan _semua_ file yang Anda lihat, baru-baru ini, dalam urutan kronologis terbalik. 'File kerja' hanya menampilkan file yang Anda klik dua kali atau membuat perubahan dan dalam urutan saat Anda ingin membukanya. Kriteria dan urutannya sewenang-wenang dan tidak ada hubungannya dengan cara berpikir programmer - berpindah-pindah antara pemanggil dan fungsi, kelas dan konsumen.

(Opini. Jarak tempuh dapat bervariasi.)

EDIT: Maksud saya adalah ini: memahami mengapa satu fitur berfungsi dan satu tidak akan membantu memperbaiki fitur atau merancang yang lebih baik. Seperti berdiri, file yang bekerja tidak.

@Tyriar : Secara pribadi, saya sangat benci fakta bahwa file yang diklik tidak muncul di Working Files. Saya ingin SEMUA file yang saya lihat di tumpukan yang baru saja saya gunakan - bahkan hanya baca, yang eksternal. Saya membukanya karena suatu alasan. Jika saya sudah selesai dengan mereka, mereka akan segera hilang dari daftar. Paling-paling, harus ada opsi untuk membuat klik tunggal dan klik dua kali berperilaku sama.

Saya menemukan cara untuk mendapatkan sebagian besar dari apa yang saya lewatkan dari luhur dalam konteks masalah ini:

[
  { "key": "cmd+w", "command": "workbench.files.action.closeFile" },
  { "key": "cmd+shift+]", "command": "workbench.files.action.openNextWorkingFile" },
  { "key": "cmd+shift+[", "command": "workbench.files.action.openPreviousWorkingFile" }
]

@phenmartindale Saya tidak yakin apakah ada yang telah melakukan permintaan fitur untuk menonaktifkan 'file pratinjau' belum.

@stephenmartindale kami sedang mencari cara untuk menyematkan "file pratinjau" agar tetap terbuka — termasuk file hanya-baca.

Kami ingin menyimpan "file pratinjau", karena sering kali orang tidak tahu file apa yang mereka cari sampai mereka membuka beberapa (yang dapat mengakibatkan jumlah file terbuka yang tidak diinginkan menjadi tidak relevan).

Saya sangat menyukai aliran Sublime di sini. Satu klik Anda melompat ke file,
klik dua kali itu tetap terbuka.
Pada hari Sabtu, 9 April 2016 pukul 11:49 Brad Gashler [email protected]
menulis:

@stephenmartindale https://github.com/stephenmartindale kami mencari
menjadi cara untuk menyematkan "file pratinjau" agar tetap terbuka.

Kami ingin menyimpan "file pratinjau", karena sering kali orang tidak tahu
file apa yang mereka cari sampai mereka membuka beberapa (yang bisa
menghasilkan jumlah kekacauan file yang tidak diinginkan).

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

@Tyriar , @ bgashler1 , @stevencl Saya pikir lebih baik memiliki dua posting baru untuk tab dan file kerja untuk mengumpulkan umpan balik.

Pendapat saya saja, tetapi saya rasa akan jauh lebih baik daripada membahas kedua fitur di sini, yang ini cukup lama. :)

👎 Tolong jangan lakukan ini, atau setidaknya menjadikannya opsional. UI bebas tab yang bersih adalah salah satu hal yang paling saya sukai tentang kode VS.

@tobico Tidak harus semua atau tidak sama sekali ... Anda tahu, sejauh yang saya ketahui, saya ingin file dan tab yang berfungsi menjadi opsional namun tidak terpisahkan bagi orang-orang yang ingin memiliki pengalaman itu.

Saya ingin kedua bahwa Ctrl + W harus menutup tidak hanya editor saat ini, tetapi juga file kerja terbuka yang sesuai. Bagi saya itulah kelemahan terbesar dalam implementasi saat ini. Itu dan fakta bahwa Ctrl + Tab mencantumkan semua file baru

+1

@csholmq Anda dapat melakukannya sekarang, lihat keybindings kustom di https://github.com/Microsoft/vscode/issues/224#issuecomment -207507479

@Tyriar Itu membahas hampir semua peringatan saya. Terima kasih!

Dalam 3 menit, saya berhenti menggunakan VS Code dan kembali ke Atom. Tidak ada tab, tidak boleh pergi. Maaf, alur kerja saya telah dibor ke dalam diri saya. Saya berani bertaruh jajak pendapat cepat 4 tahun yang lalu akan mendapatkan jawaban UI Anda lebih cepat. Tapi biarkan juga kesombongan Microsoft untuk memperbaiki sesuatu yang tidak rusak.

@zunama kami tidak melupakan pengguna yang menginginkan tab dan pengelolaan dokumen yang lebih baik. Sekarang kami 1.0, itu salah satu prioritas tertinggi kami untuk mengatasi masalah ini. Hal-hal luar biasa akan segera hadir di VS Code.

Sebagai pengembang web, Tab penting bagi saya. Tidak seperti pemrogram desktop (yang terutama berfokus pada satu file pada saat itu), kami selalu beralih antar jendela & menggunakan Mouse pada saat yang sama (misalnya, Mengiris gambar dari Photoshop, dan kemudian segera kembali ke editor. Atau debugging di browser, dan pergi kembali ke file lain untuk melakukan perbaikan). Dengan tab, kita dapat menavigasi ke file target dengan cepat. Dengan pintasan, tersedia 2 langkah lagi. Dengan "file kerja" sidebar, itu lebih sedikit ruang di area kode utama (karena kami menempatkan Photoshop & Editor atau browser berdampingan). Height dalam editor kurang diperlukan. Anda selalu dapat menghafal beberapa baris lagi, bukan?

Selain itu, Tab Atas lebih baik untuk mata manusia. Anda dapat memindai judul tab atas dan kode area utama secara bersamaan. Tetapi Anda tidak dapat membaca sisa working files dengan kode utama bersama-sama. Cobalah sendiri. Selain itu, Tab lebih lebar, lebih baik untuk pergerakan mouse. (Bahkan Anda tidak akan fokus padanya, itu lebih dapat diprediksi)

+1/0

+1

Hanya pendapat pribadi saya tapi tolong, berhenti melakukan -1, +1 posting ... maksud saya selain menyarankan Anda suka atau tidak suka fitur ini sesuatu yang reaksi / emotikon dapat digunakan karena tidak mengatakan apa-apa tentang pengalaman Anda dan sebagainya jika Anda sudah menulis posting, pastikan itu berguna! Saya yakin Anda memiliki bahan pengawet sendiri pada benda-benda dan cara kerja yang Anda inginkan! jika tidak, gunakan saja emotikon.

Meta:
@eyalsk Dalam contoh ini, pembahasan sedang berlangsung sehingga memang terkesan mubazir. Tetapi untuk isu-isu yang ingin Anda tarik, apakah benar-benar setara dengan "Tambahkan reaksi Anda"? Bukankah itu hanya mengingatkan op komentar daripada menunjukkan bahwa masalahnya adalah topik hangat? Yaitu apakah itu memberi tahu pengembang yang diberi tag ke masalah atau menyetel masalah sebagai diubah?

@csholmq Saya tidak tahu apakah saya mendapatkan Anda dengan benar tetapi saya tidak mengacu pada reaksi / emotikon tetapi pada pos yang tidak berisi apa-apa selain +1, -1 di dalamnya, itu tidak menambah nilai, masukan yang lebih bermakna bisa telah ditulis alih-alih menulis postingan dengan +1, -1 ... hanya pendapat saya, saya akan mengubah dan menekankan hal ini di postingan saya.

@zunama Bukan arogansi mencoba mencari alternatif yang lebih baik. "Tidak rusak" bukanlah argumen yang valid untuk tidak mencari barang baru. Ini cukup banyak argumen untuk itu (mungkin ada sesuatu yang lebih baik?). Meskipun saya perhatikan dalam diskusi ini bahwa jika VS Code ingin digunakan sepenuhnya hari ini, itu harus bertujuan untuk menyenangkan basis pengguna 'pola pikir lama' saat ini dan berinovasi nanti. Karena orang-orang tidak pandai menunggu dan menghemat waktu Anda untuk mencoba berdebat mengapa ini atau itu lebih baik.

Kembali ke komentar Anda: Jika Anda ingin melakukan sesuatu dengan benar, Anda tidak meluangkan waktu 3 menit dan berhenti. Anda menghitung sudut pandang Anda tentang kritik yang berguna dan mencari kemungkinan perbaikan. Sudut pandang 3 menit tidak berguna - dan berbahaya - untuk desain Anda karena bias.

Jajak pendapat tidak akan berhasil jika Anda ingin berinovasi. Contoh:

Manakah dari gaya nagtivasi berikut yang paling produktif untuk Anda?

• Sesuatu. (Coba sesuatu yang baru yang mungkin lebih baik)
• Tab. (Gaya kerja lama yang baik yang Anda pelajari untuk dicintai).

Tentu saja tab akan menang. Tapi mungkin ide lain bisa membuka jalan ke UI navigasi standar baru.

Sejujurnya, salah satu fitur penting dari VS Code bagi saya adalah tidak adanya tab. Saya bahkan tidak menyadari (pada awalnya) bahwa mereka hilang! Itu adalah sudut pandang yang sangat menarik.

Setiap kali saya menggunakan tab, tab selalu berantakan dan tidak mungkin ditemukan. Ketika saya tidak dapat langsung melihat file tertentu di daftar tab, reaksi pertama saya adalah membukanya kembali. . . dan kemudian saya akan mengetahui bahwa itu sudah dibuka. Tentu saja urutan tab menjadi kacau balau dalam prosesnya. Inilah yang terjadi pada saya di Visual Studio 2015.

Di dunia yang semuanya sama, rasanya menyegarkan memiliki identitas.

PS. Saya tidak terlalu terkesan dengan bagian file kerja. Saya kebanyakan menggunakannya untuk melihat file mana yang perlu disimpan dengan cepat.

PSS. Ide - jika ada tab dalam kode vs suatu hari, maka mungkin yang terbaik adalah membatasi jumlah maksimum tab yang dibuka, yaitu menutup tab terlama secara otomatis saat baru dibuka?

@RussBaz Saya tidak berpikir bahwa membatasi jumlah tab adalah ide yang baik karena nomor itu dapat berubah dari pengguna ke pengguna tetapi mungkin ini bisa menjadi opsi seperti ini:

tabs.autoClose = "tidak terlihat", "mati", "waktu", x dengan x adalah angka

Itu ide yang aneh. Jika saya suka 16 tab dan Anda suka 4, itu sederhana. ANDA menggunakan 4 tab dan saya akan menggunakan 16! Mengapa mengatakan cara Anda lebih baik dari saya, atau sebaliknya. Tentang apa sebenarnya ini? Bahkan percakapan tentang tab tidak ada gunanya selama tab diaktifkan / dinonaktifkan di Opsi / Preferensi. Mereka yang tidak menginginkan tab, HEBAT! Mereka yang menginginkannya, centang kotak kecil! Sungguh, tidak harus cara Anda lebih baik dari cara saya, atau bahwa saya lebih tahu daripada Anda.
+1
;)

Contoh kasus penggunaan: Saat ini saya beralih di antara 6 tab secara konstan di atom.

Itu tumbuh menjadi sekitar 10 ketika saya perlu mengerjakan bagian yang lebih dalam. Saya menggunakan semuanya! Jadi menutup dan membuka kembali akan merepotkan. Saya dapat memiliki file besar di tempatnya tetapi itu akan jauh lebih menyakitkan untuk ditangani karena itu akan membengkak menjadi 6k baris dalam sebuah file jika saya memasukkan setiap bagian dari modul ke dalam satu file.

@Mengukur Saya setuju dan tidak setuju dengan Anda. Ada beberapa hal yang perlu diinovasi tetapi yang pertama harus ditanyakan, bagaimana dengan alur kerja yang dapat kita perbaiki dengan menghapus tab. Bagi saya, setiap editor yang saya gunakan untuk pengembangan memiliki antarmuka tab karena biasanya developer bekerja antara 5-10 file pada satu waktu tanpa mengingat nama persis file atau urutan pembukaannya. Jadi Saya harus bertanya, bagaimana antarmuka baru ini membuatnya menjadi lebih baik? Bagaimana ini inovatif? Pertama tanyakan, bagaimana mereka menggunakannya, lalu tanyakan, bagaimana saya bisa membuatnya lebih baik.

Adapun masalah tiga menit, saya akan berasumsi bahwa Kode tidak jauh berbeda dari Sublime (pilihan saya lebih disukai) atau Atom (apa yang saya coba), tetapi jika sejak awal saya kesulitan untuk bekerja dengannya atau menunjukkan seseorang secara efisien apa yang perlu mereka lakukan di antara file untuk membuat sesuatu bekerja, maka saya akan menggunakan sesuatu yang bekerja lebih baik untuk kebutuhan saya sekarang dan melihat ke dalam Code beberapa versi di jalan ketika sudah siap. Ini bukan pola pikir 'sekolah lama' melainkan efisiensi dengan pekerjaan saya.

Menanyakan kepada kita yang lebih suka tab untuk beralih ke tanpa tab sama baiknya
meminta mereka yang lebih suka tanpa tab untuk beralih ke tab. Kami berdua tidak mau
beralih ke metode lain.

Bisakah kita berhenti sekarang dengan jenis 'Mac vs Windows', 'Android vs IPhone'
perdebatan tentang cara mana yang lebih baik: 'Tab vs No Tabs'? Keduanya bagus
dan orang yang berbeda memiliki preferensinya sendiri.

Saya pikir solusi terbaik adalah menambahkan tab sebagai preferensi yang bisa
diaktifkan secara opsional. Kemudian kedua orang itu senang.

Adakah orang yang menentang kedua metode sebagai opsi yang dapat Anda aktifkan atau
off tergantung pada preferensi Anda?

Saya pikir itu tergantung pada dua opsi ini:

1) Tambahkan tab sebagai preferensi. Aktif untuk yang suka dan off untuk yang
jangan.

2) Jangan tambahkan tab sama sekali, meskipun saya memiliki opsi untuk mematikannya.

Mengapa Anda bahkan memilih opsi 2 ketika Anda memiliki opsi untuk mengubahnya
mati?
Pada tanggal 15 Apr 2016 19.32, "James McLaughlin" [email protected]
menulis:

@Measuring https://github.com/Measuring Saya setuju dan tidak setuju dengan Anda.
Ada beberapa hal yang perlu diinovasi, tetapi yang pertama harus ditanyakan, apa
tentang alur kerja dapat kita perbaiki dengan menghapus tab. Bagi saya, setiap
editor tunggal yang saya gunakan untuk pengembangan memiliki antarmuka tab karena itu
umum untuk file berkembang untuk bekerja antara 5-10 file sekaligus
mengingat nama persis file atau urutan pembukaannya
masuk Jadi saya harus bertanya, bagaimana antarmuka baru ini membuatnya menjadi lebih baik? Bagaimana
itu inovatif? Pertama tanyakan, bagaimana mereka menggunakannya, lalu tanyakan, bagaimana saya bisa membuatnya
itu lebih baik. Adapun masalah tiga menit, saya akan menganggap Kode itu
tidak jauh beda maka Sublime atau Atom dan kalo langsung dari awal saya
berjuang untuk bekerja dengannya atau menunjukkan kepada seseorang secara efisien apa yang perlu mereka lakukan
antara file untuk membuat sesuatu bekerja, maka saya akan menggunakan sesuatu yang berfungsi
lebih baik untuk kebutuhan saya sekarang dan lihat Kode beberapa versi di masa mendatang
jika sudah siap.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

@ tones411 Beberapa orang akan memilih opsi 2 hanya karena mereka berpikir bahwa penambahan tab akan merusak pengalaman mereka dengan file yang berfungsi.

_Saya tidak bisa cukup menekankannya_ tetapi menurut saya diskusi tidak boleh hanya tentang menambahkan tab dan menyebutnya sehari tetapi mendapatkan alur kerja yang benar dan saya mengatakannya berkali-kali, artinya, perlu opsi yang tepat untuk penyesuaian, perlu untuk merasa terintegrasi dan tidak terasing dan masih opsional! hal yang sama berlaku untuk file kerja.

Beberapa orang mungkin ingin memiliki sesuatu seperti buffer Vim dan tidak ingin memiliki tab atau file yang berfungsi sama sekali.

Mungkin sesuatu seperti buffer Vim dapat digunakan sebagai permukaan untuk VSCode di mana kita dapat menggunakan perintah untuk mengelola file dan di atasnya meletakkan fondasi untuk setiap alur kerja apakah itu tab, file kerja atau hal lain besok.

Kata yang bagus. Ini telah berubah menjadi debat agama. Jelas dari ini
benang panjang yang ada banyak orang di sini yang bersemangat untuk memilikinya
tab dan yakin mereka dibutuhkan / memfasilitasi alur kerjanya. Ada
orang lain yang tidak percaya tab itu perlu dan itu adalah penghalang.

Mari kita setuju untuk tidak setuju, itu bagus. Selama tab bersifat opsional
daripada mereka yang tidak menginginkannya tidak harus menggunakannya.

Saya pribadi percaya mereka berguna, tetapi saya tidak akan menghentikan seseorang
dari menggunakan file kerja jika itu berhasil untuk mereka. Itu tidak berhasil untuk saya.
Pada hari Jumat, 15 Apr 2016 pukul 22.07 tones411 [email protected] menulis:

Menanyakan kepada kita yang lebih suka tab untuk beralih ke tanpa tab sama baiknya
meminta mereka yang lebih suka tanpa tab untuk beralih ke tab. Kami berdua tidak mau
beralih ke metode lain.

Bisakah kita berhenti sekarang dengan jenis 'Mac vs Windows', 'Android vs IPhone'
perdebatan tentang cara mana yang lebih baik: 'Tab vs No Tabs'? Keduanya bagus
dan orang yang berbeda memiliki preferensinya sendiri.

Saya pikir solusi terbaik adalah menambahkan tab sebagai preferensi yang bisa
diaktifkan secara opsional. Kemudian kedua orang itu senang.

Adakah orang yang menentang kedua metode sebagai opsi yang dapat Anda aktifkan atau
off tergantung pada preferensi Anda?

Saya pikir itu tergantung pada dua opsi ini:

1) Tambahkan tab sebagai preferensi. Aktif untuk yang suka dan off untuk yang
jangan.

2) Jangan tambahkan tab sama sekali, meskipun saya memiliki opsi untuk mematikannya.

Mengapa Anda bahkan memilih opsi 2 ketika Anda memiliki opsi untuk mengubahnya
mati?
Pada tanggal 15 Apr 2016 19.32, "James McLaughlin" [email protected]
menulis:

@Measuring https://github.com/Measuring Saya setuju dan tidak setuju dengan Anda.
Ada beberapa hal yang perlu diinovasi, tetapi yang pertama harus ditanyakan, apa
tentang alur kerja dapat kita perbaiki dengan menghapus tab. Bagi saya,
setiap
editor tunggal yang saya gunakan untuk pengembangan memiliki antarmuka tab karena itu
umum untuk file berkembang untuk bekerja antara 5-10 file sekaligus
mengingat nama persis file atau urutan pembukaannya
mereka
masuk Jadi saya harus bertanya, bagaimana antarmuka baru ini membuatnya menjadi lebih baik? Bagaimana
adalah
itu inovatif? Pertama tanyakan, bagaimana mereka menggunakannya, lalu tanyakan, bagaimana saya bisa
membuat
itu lebih baik. Adapun masalah tiga menit, saya akan menganggap Kode itu
adalah
tidak jauh berbeda maka Sublime atau Atom dan jika benar dari awal
saya
berjuang untuk bekerja dengannya atau menunjukkan kepada seseorang secara efisien apa yang perlu mereka lakukan
antara file untuk membuat sesuatu bekerja, maka saya akan menggunakan sesuatu itu
bekerja
lebih baik untuk kebutuhan saya sekarang dan lihat Kode beberapa versi di masa mendatang
jika sudah siap.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

+1

Saya telah mengikuti utas ini selama ~ sebulan terakhir atau lebih sejak saya beralih ke Kode sebagai editor utama saya dan saya terus-menerus terganggu oleh perilaku navigasi file. Saya telah menghabiskan waktu _ mencoba_ untuk membiasakan diri dengan bagian File Kerja, yang Anda akui lebih-atau-kurang merupakan renungan, dan Ctrl + Tab, dan Ctrl + P. Saya sangat senang dengan Code dan ini adalah editor favorit saya, tetapi opsi navigasi file ini dipahami dengan sangat buruk sehingga sulit untuk memahami bagaimana mereka dipikirkan.

Sebagian besar telah disebutkan, tetapi inilah keluhan saya:

Daftar WF pada dasarnya tidak berguna, karena menutup jendela editor sebenarnya tidak menutup file dari WF. Saya harus benar-benar menutup file _twice_, dan menggunakan mouse untuk melakukannya (Ctrl + W _and_ tutup file dari panel WF). Jika saya ingin membiarkan file terbuka, saya tidak akan menekan Ctrl + W - bagaimana masuk akal untuk menekan Ctrl + W dan membiarkan file "terbuka" (terlihat di WF). Ya, ini dapat dialihkan, tetapi saya berbicara tentang perilaku default WF).

Mengklik file di WF atau tampilan hierarki membuka file ke jendela editor yang tidak diinginkan setidaknya separuh waktu. Jika Anda memiliki editor dua panel dengan panel kiri aktif, "buka ke samping" akan membukanya di panel _right_, bukan panel _new_, dan dengan 3 kolom itu akan selalu terbuka di panel yang ada. Masalahnya di sini adalah bahwa "sesuatu tidak tinggal di tempat saya meletakkannya." Saya berharap untuk memberi tahu editor saya di mana saya menginginkan sesuatu, bukan editor saya untuk memutuskan di mana hal-hal harus didasarkan pada status UI saat ini dan kemudian mengubahnya saat status UI berubah di bagian lain dari aplikasi. Mendapatkan _back_ ke file yang sebelumnya dibuka adalah PITA semacam itu .

File dengan mengklik satu kali dan mengklik dua kali memiliki _perilaku yang sangat berbeda_ dengan _ UI yang sama persis. Satu klik membuka pratinjau file untuk sementara (karena ketika saya tidak ingin memuatnya ke WF karena akan memerlukan dua penutupan untuk dihapus nanti), tetapi memuat editor "pratinjau" dengan file lain (tidak dapat dihindari dengan implementasi saat ini seperti yang disebutkan di atas) akan melompati pohon folder ke tempat baru, dan memuat file "pratinjau" sebelumnya berarti saya harus menavigasi lagi ke folder dalam tampilan hierarki. Saya bahkan tidak ingin mengakui berapa banyak waktu yang saya habiskan untuk menavigasi ke folder yang sama persis_ 6 kali berturut-turut karena perilaku ini.

Menurut pendapat saya, mengklik satu atau dua kali file seharusnya memberi saya _perilaku yang sama persis_, tetapi jika Anda benar-benar menginginkan satu klik "pratinjau" yang tidak muncul di WF / Ctrl + Tab, harus ada _panda UI yang jelas_ yang jendela editor aktif adalah pratinjau dan akan hilang saat Anda menggantinya.

Pohon folder harus _not_ melompat ke lokasi setiap file yang saya klik, atau saat saya melakukan debug, melompat melalui setiap folder di folder perpustakaan saya. Jika saya ingin menavigasi ke folder tertentu, saya akan menavigasi ke sana, dan setelah saya selesai melakukannya, saya berharap itu tetap seperti itu. Ini mungkin tampak tidak terlalu relevan di utas tab, tetapi memang demikian.,

Satu-satunya alasan mengapa panel editor, WF, dan perilaku tampilan folder yang sangat konyol ini ada adalah _ karena tidak ada tab_. Jika Anda menambahkan tab (digalangkan ke panel tertentu jika panel editor terpisah), dan secara default ke perilaku editor normal yaitu _selalu membuka semuanya di tab baru_, tidak ada perilaku itu yang diperlukan. Biarkan saya memutuskan bagaimana saya ingin menavigasi pohon saya dan bagaimana saya ingin menumpuk tab saya, dan berhenti mencoba menunjukkan kepada saya "cara yang lebih baik" (kecuali Anda benar-benar _memiliki_ cara yang lebih baik - setelah ~ 6 bulan bekerja sehari-hari, saya bisa katakan dengan kepastian mutlak bahwa cara saat ini _tidak_ lebih baik bagi saya).

Dan sementara Anda melakukannya, demi kasih Tuhan TOLONG izinkan saya melihat file dari direktori yang sama di lebih dari satu jendela! Ada solusi sederhana dan elegan, yang dimiliki oleh setiap perangkat lunak berbasis tab lainnya selama bertahun-tahun - seret tab tersebut ke jendela baru - serius, ini bukan hal yang revolusioner. Jika Anda ingin mempertahankan perilaku "satu folder hanya mendapat satu contoh", buat panel mengapung ke jendela baru (yang masih dikontrol oleh / dilampirkan ke jendela utama).

Kalian telah melakukan pekerjaan luar biasa dengan editor ini dan saya akan terus menggunakannya. Jika kita bisa melihat:

1. Tab
2. Nonaktifkan WF
3. Hentikan pohon folder navigasi otomatis
4. Ripoff tab ke panel editor mengambang (yang memiliki perilaku yang sama seperti panel editor lain di antarmuka utama)

Maka saya pikir VS Code akan pergi jauh, jauh, jauh. Editor hebat, dan saya bersedia menanggung kerugian untuk memanfaatkan sisanya, tetapi banyak, banyak lagi yang hanya menunggu beberapa fitur dasar ini.

Saya akan sangat senang membantu dengan pengujian UI / UX atau apa pun yang Anda lakukan untuk masukan / masukan pengguna. Beri tahu saya jika saya bisa membantu.

Terima kasih!

@anyong terima kasih atas wawasan Anda!

Untuk poin 3, tidak yakin apakah Anda mengetahuinya tetapi Anda dapat menyesuaikannya saat ini juga dengan:

"explorer.autoReveal": false

Saya mengikat workbench.files.action.showActiveFileInExplorer juga sehingga saya bisa mendapatkan file acak di explorer jika perlu.

@Tyriar Saya tidak yakin versi mana yang Anda maksud, tetapi saya mengetahui informasi terbaru tentang Insider dan opsi itu belum melakukan apa pun.

: +1:

: +1:

@bpasero Saya telah membaca beberapa pesan pertama di papan ini mengenai keuntungan / kerugian tab. Saya juga memahami sikap Tim MSFT dalam hal ini: tim ini bersatu di bawah gaya pengkodean yang sama dan mengembangkan kumpulan refleks yang sama tentang ctrl+tab dan / atau bagian file kerja. Itu hal yang bagus. Semua anggota tim memiliki aliran seragam dalam melakukan sesuatu, secara umum. Namun, kami bukan bagian dari tim itu, kami juga tidak ingin mengembangkan refleks yang sama. Refleks kita yang ada, idealnya, terpenuhi, tidak dipaksakan dan diganti. Editor harus membantu pengguna.

Kami harus menyesuaikan dengan definisi Anda tentang UX, atau berhenti menggunakan VSCode. Beberapa akan beradaptasi, beberapa tidak. Adalah semua tentang keseimbangan antara hal-hal baik dan buruk yang diletakkan di atas meja. Karena itu, saya pikir tim MSFT sangat meremehkan pentingnya tab, dan terlalu melebih-lebihkan refleks yang dikembangkan di rumah.

Tim dan orang-orang yang bertanggung jawab benar-benar perlu membuat satu keputusan sederhana: apakah VS Code merupakan eksperimen Interaksi Manusia-Komputer atau seharusnya merupakan IDE yang

@Tyriar : Saya mencoba pengaturan autoReveal di v.1.0.0-insider dan itu juga tidak bermanfaat bagi saya. Penjelajah masih melompat-lompat ketika saya tidak menginginkannya - yang paling menjengkelkan, ketika itu menggulir sepenuhnya ke tempat yang berbeda ketika saya menggunakan go-to-definition dan itu membuka file lain.

Ini yang saya masukkan ke file preferensi saya: "explorer.autoReveal": false,

@anyong @stephenmartindale Anda benar, saya tidak menyadari betapa baru pengaturan ini. Ini harus tersedia pada build Insiders berikutnya.

Kata @fenmartindale. Tanpa tab yang kita miliki hanyalah notepad.exe dengan versi Alt-Tab-nya sendiri (yang seperti yang disebutkan di atas, rusak). Saya telah mencoba menggunakan "Working Files" seolah-olah itu adalah tab samping, tetapi setelah seminggu saya cukup siap untuk kembali ke Sublime dan masalahnya, terutama bahwa tidak ada cara untuk membuat sidebar itu selalu tidak ada peduli apa lagi yang terjadi di aplikasi. Dengan nama "Visual Studio ..." Saya mengharapkan setidaknya fitur dasar editor Visual Studio (tab, dan kemampuan untuk menyeret tab tersebut ke jendela mereka sendiri). Mengapa mereka menghapus fungsionalitas itu tidak dapat dijelaskan. Mungkin saya akan memeriksanya kembali dalam beberapa bulan dan melihat apakah mereka sudah cukup jauh untuk meletakkan tag pra-alfa pada bangunan. Saat ini ini tidak lebih dari eksperimen UI, satu-satunya pertanyaan adalah apakah itu sudah gagal atau apakah itu tertatih-tatih di ambang kegagalan?

Seperti yang telah dinyatakan oleh sebagian besar 259 komentar sebelumnya, saya sangat ingin melihat tab di VS Code, mirip dengan cara mereka beroperasi di Sublime Text. Saya juga akan dengan senang hati beralih jika bukan karena fitur yang hilang ini. Meski kedengarannya aneh, saya memang membutuhkan kemampuan untuk memiliki setidaknya empat dokumen terbuka di jendela yang sama sehingga saya dapat beralih di antara mereka dengan cepat.

Oh, dan jika Microsoft tidak terlalu ingin VS Code dibandingkan dengan Sublime Text, maka mereka seharusnya tidak membuat produk yang terlihat dan bertindak sangat mirip dengannya. Menjauhkan tab dari GUI bukanlah cara untuk mencegah perbandingan dengan Sublime Text; ini adalah cara untuk membuat perbandingan tersebut kurang menguntungkan bagi Microsoft.

@SturmB Sublime bukan satu-satunya editor yang ada dan saya rasa mereka tidak membuat VSCode menjadi peniru Sublim lainnya, seperti Atom bukan Sublime tetapi semua editor berbagi fitur yang merupakan hal yang baik, itulah cara Anda mendapatkan pilihan !

VSCode sama sekali tidak bertindak seperti Sublime karena mereka sangat berbeda, VSCode bertujuan untuk menjadi jalan tengah antara editor kode dan IDE sedangkan Sublime tidak membuat klaim itu, oleh karena itu, VSCode memiliki audiens orang yang lebih banyak, mulai dari orang-orang yang menggunakan Vim ke Visual Studio.

Menambahkan tab bukanlah masalah sama sekali, orang terus mengatakan bahwa mereka perlu menambahkan tab dan saya yakin sekarang mereka memahami bahwa tab itu penting tetapi masalah sebenarnya adalah mendapatkan desain yang benar dan memastikan pengalamannya terasa menyenangkan. semua orang, mereka yang menyukai tab dan mereka yang membencinya.

Sekarang, ketika Anda mendesain fitur, terutama fitur yang merupakan inti dari pengalaman di editor, Anda tidak bisa begitu saja meretas beberapa hal dan menggabungkannya lalu kembali dengan pengumuman bahwa setelah beberapa hari akan membuat banyak orang kecewa! hal baik membutuhkan waktu! dan ini tidak berbeda. :)

Saya suka konsep file kerja. Tab tidak dapat diskalakan dengan baik saat banyak file terbuka. Apa pun yang terjadi, pertahankan kontrol file yang berfungsi!

@helmbold Saya benar-benar ingin tahu - _bagaimana_ Anda menggunakannya secara efisien? Saya sudah _tried_ dan saya tidak tahu bagaimana memahami kekacauan yang ada di WF. (Juga, di suatu tempat dalam masalah ini, tim mengatakan bahwa file yang berfungsi benar-benar hanya renungan, bukan fitur yang direncanakan.)

@eyals :

masalah sebenarnya adalah mendapatkan desain yang benar dan memastikan pengalamannya terasa menyenangkan bagi semua orang, mereka yang menyukai tab dan mereka yang membencinya.

Hampir semua orang di sini mengatakan mereka berharap tab akan dikontrol oleh pengaturan untuk alasan ini. Meskipun demikian, meskipun beberapa perangkat lunak selama iterasi awal tab bertahun-tahun yang lalu tidak terlalu bagus untuk digunakan, belakangan ini biasanya cukup bagus. Kode memiliki Sublime, Atom, dan non-editor seperti browser yang harus dicari untuk membuat tab "benar."

Salah satu fitur yang saya ingin lihat yang belum pernah saya lihat di perangkat lunak tab dan yang menurut saya akan mengurangi beberapa masalah dengan "terlalu banyak tab" adalah cara untuk memilih dan menyeret banyak tab ke jendela baru.

Pada akhirnya, antarmuka manusia-komputer untuk mengelola ratusan file dengan nama panjang yang tampak mirip akan selalu kurang - bukan itu cara kami dirancang untuk bekerja, hanya cara kami dipaksa untuk bekerja karena keadaan rekayasa perangkat lunak saat ini.

@anyong pasti! menambahkan opsi tidak menjadi masalah sama sekali, maksud saya masalah dimulai ketika Anda bertanya pada diri sendiri opsi apa yang berlebihan dan opsi apa yang sebenarnya berguna, program yang dirancang dengan tab dalam pikiran sejak awal membuatnya sangat mudah untuk beberapa alasan tetapi terutama karena tab bukan renungan, juga, tidak mungkin untuk membandingkan satu editor dengan yang lain atau bahkan dengan program lain yang memiliki tab terutama karena cerita navigasi umumnya berbeda dari program ke program, program yang berbeda bertujuan untuk fokus pada yang berbeda sesuatu.

Hanya karena Sublime / Atom atau program lain memiliki tab dan berfungsi dengan baik, tidak berarti Anda dapat mengambil semua hal yang berfungsi di sana dan memanggangnya ke dalam program Anda, bukan begitu cara kerjanya, sebenarnya itulah yang _can_ gagal! itu berhasil di sana karena seluruh paket membuatnya berhasil.

Sekarang, menambahkan pengalaman pengguna jenis baru ke editor agak mengharuskan Anda mengevaluasi ulang seluruh kisah navigasi termasuk fitur yang ada seperti "file yang berfungsi", terutama bila Anda memiliki konsumen yang sudah ada di mana setiap orang mengharapkannya berfungsi seperti editor pilihan mereka dan Anda dapat mengetahui dari postingan bahwa banyak dari mereka memiliki standar tinggi tentang cara kerjanya. :)

: +1:

@bpasero , @ bgashler1 dan saya sudah mulai mengerjakan desain UX untuk meningkatkan manajemen dokumen. Kami memperhatikan semua masukan tentang masalah ini dengan cermat dan telah berbicara dengan beberapa dari Anda untuk mendapatkan detail selengkapnya tentang pengalaman dan perspektif unik Anda sendiri.

Sekarang kami ingin membagikan desain awal kami dengan Anda untuk mendapatkan tanggapan Anda. Kami akan menyelenggarakan Google Hangout pada Kamis 21 April pukul 16.00 BST. Jika Anda ingin bergabung dengan kami, silakan klik tautan ini saat itu: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme

Ini akan menjadi pertemuan desain publik pertama kami dan kami menantikannya.

Saya telah menggunakan VSCode secara eksklusif (berasal dari WebStorm) dan saya belum kehilangan tab. Awalnya saya berpikir bahwa saya akan melakukannya, tetapi saya mulai lebih menyukai Working Files karena saya dapat melihat lebih banyak dalam ruang yang lebih sedikit dan tanpa harus memikirkan tentang cara mengatur atau mengelompokkan berbagai hal di layar. Sekarang saya terutama menggunakan CTRL + TAB.

Saya pikir jika ada tab tradisional harus menjadi _extension_ resmi atau keikutsertaan _option_. Secara pribadi saya mengharapkan sesuatu selain tab untuk meningkatkan pengalaman saat ini.

Apa yang saya temukan kekurangan CTRL + TAB adalah konteks panel editor aktif. Jika saya memiliki 2 panel editor yang terbuka berdampingan maka saya ingin melihat CTRL + TAB menampilkan riwayat file yang difilter ke file yang telah dibuka di panel editor aktif daripada semua file yang dibuka di aplikasi secara keseluruhan ( meskipun itu masih perlu ada juga). Juga, mungkin mengklik di suatu tempat di / dekat nama file di bagian atas panel editor dapat menampilkan daftar file yang dibuka di panel editor itu (sama seperti CTRL + TAB).

Pertahankan kerja bagus.

Satu saran lain .. Alangkah baiknya memiliki kombo tombol default yang lebih baik untuk melihat daftar File yang Bekerja saat sidebar disembunyikan. Saya baru saja menemukan bahwa CTRL + K CTRL + P menunjukkan apa yang saya inginkan tetapi lebih sulit untuk menariknya daripada CTRL + TAB. Seperti yang saya sarankan dengan CTRL + TAB, popup File Kerja bisa mendapatkan keuntungan dari beberapa konteks berdasarkan panel editor aktif. Mungkin itu bisa diurutkan sehingga daftar File Kerja yang telah dibuka di panel editor aktif berada di atas sisanya.

@RyanEwen Saya rasa Anda bukan pengguna jalan pintas sebelumnya? Karena platform Intellij Idea memiliki shortcut yang sama dan mampu menempatkan Tab dimanapun (Atas, Bawah, Kiri, Kanan, Tidak Ada). Ketika ditempatkan di Kiri / Kanan, ini bekerja mirip dengan File Kerja di VSCode. Akan sangat bagus untuk melakukan beberapa percobaan. Kembali ke WebStorm menggunakan kombinasi CTRL + TAB dengan Tab teratas untuk melihat apakah Anda tidak membutuhkannya atau dipaksa untuk menerimanya sebagai satu-satunya solusi. CTRL + E di WebStorm juga merupakan File Terbaru dengan fitur pemfilteran (ketik untuk mencari).

Siapa pun yang mengatakan tidak pada Tab, harap sebutkan juga jika Anda menggunakan MOUSE dalam alur kerja Anda.

: +1:

@KayLeung Saya telah menggunakan CTRL + E di WebStorm, tetapi karena ada tab, saya akan membiarkan diri saya menggunakannya menggunakan mouse lebih sering daripada tidak. Saya baru-baru ini menggunakan editor tab (Koding.io) ketika saya tidak memiliki akses ke VSCode dan secara rahasia dapat mengatakan bahwa saya tidak ketinggalan mengatur / mengatur tab. Sepertinya membosankan dibandingkan hanya memiliki sejarah. Saya menemukan diri saya selalu terjebak dalam bagaimana saya ingin hal-hal ditata dan memprediksi file apa yang akan dibuka daripada hanya menggunakan editor dan membalik-balik file. Saya tahu, ini mungkin sebagian merupakan masalah "saya" daripada masalah tab. Sedikit OCD, kurasa.

Saya adalah seorang mouser ketika saya menggunakan WebStorm. Saya menggunakan pintasan tombol untuk mencari file terbaru dan yang belum dibuka di sana-sini, tetapi mengarahkan ke tab untuk apa yang sudah dibuka. Saya tidak merasa saya bisa keyboard ke tab tertentu dengan mudah / intuitif, dan ada keinginan untuk mengatur tab yang juga menyebabkan saya meraih mouse saya pada akhirnya. Kurangnya tab secara tidak sadar (dan tanpa rasa sakit - dalam kasus saya) membantu saya menyelinap ke alur kerja yang mengutamakan keyboard.

Saya baru saja mencoba Adobe Brackets, dan daftar File Kerja mereka dibagi berdasarkan panel. Jika Anda memiliki panel Kiri dan Kanan maka ada 2 daftar file yang berfungsi ("Kiri" dan "Kanan") di sidebar, bukan satu seperti di VSCode. Bukan solusi yang buruk. Tidak keberatan dengan hal seperti itu (selain saran saya yang lain untuk menambahkan konteks ke CTRL + TAB berdasarkan panel editor aktif).

@RyanEwen Anda telah membuat poin yang sangat bagus. Saya selalu bekerja dengan 2 panel untuk setiap instance terbuka dari IDE saya. Saya mungkin memiliki 2 instance terbuka di 2 layar, untuk 4 panel terbuka. Saya tidak bisa menjelaskannya, tetapi Anda melakukannya. Memiliki satu daftar ketika ada dua (atau lebih?) Panel terbuka, apakah masalah dengan implementasi File Kerja saat ini yang membuatnya tidak dapat digunakan untuk saya. Terima kasih telah spesifik di sini.

Sebagai pengingat bahwa kami (saya sendiri, @bpasero dan @ bgashler1) akan membagikan desain terbaru kami untuk tab dan file yang berfungsi hari ini pada pukul 16.00 Waktu Musim Panas Inggris.

Bergabunglah dengan kami di tautan ini pada pukul 4 sore BST: https://hangouts.google.com/call/u3wnrhjja5h47ovt7piatelkxme. Kami akan sangat senang mendengar tanggapan Anda.

Pengingat bagi siapa saja yang berencana untuk bergabung dengan hangout - sekarang sudah aktif, jadi klik tautan di atas. Hanya ~ 5 orang sejauh ini.

Saya ingin sekali berada di sana tetapi sekarang jam 11 pagi dan saya di tempat kerja tidak dapat bergabung. Saya berasumsi seseorang akan memiliki beberapa hal untuk dibagikan secara tertulis setelahnya? : D

Gambaran singkat:

1. Tab dan file kerja (berganti nama menjadi "editor terbuka") berperilaku persis sama, tergantung apakah Anda ingin visual di atas (tab) atau ke kiri (editor terbuka)
2. Tab dikelompokkan berdasarkan panel secara visual di bagian atas, editor terbuka dikelompokkan bersama di bawah tajuk "Kiri", "Kanan"
3. Satu klik file untuk membuka tab pratinjau (atau "editor terbuka"); klik dua kali file, edit file, atau klik dua kali tab itu sendiri untuk bertahan
4. Debugger membuka semua file sebagai file pratinjau kecuali Anda mempertahankan file yang sedang di-debug dengan mengambil salah satu opsi di atas
5. Tab / editor terbuka dapat diseret antar panel
6. Panel dapat diseret untuk memindahkan seluruh grup tab

Terlihat sangat bagus, dan secara pribadi (dari grup yang sangat pro-tab jika Anda membaca posting saya di atas), saya pikir saya akan dengan senang hati memberikan kesempatan yang adil untuk "Open Editor" yang baru.

Pikiran tindak lanjut untuk devs:

1. Karena alur tab / editor terbuka persis sama, seharusnya mungkin untuk melakukan sesuatu seperti ini: tampilkan editor terbuka saat penjelajah terbuka, dan tampilkan tab saat penjelajah ditutup. Kami dapat meningkatkan real estat horizontal untuk kode dan mempertahankan akses tab. Dengan asumsi ada pintasan tab sembunyikan / tampilkan, ini akan setara dengan menekan itu dan CTRL + B pada saat yang sama - jika berhasil, itu harus menjadi opsi dalam pengaturan: autoShowTabsWhenExplorerClosed atau sesuatu. Jika kita perlu melihat lebih banyak tab, kita dapat mengklik chevron, atau cukup CTRL + B untuk melihat tab di panel kiri. Saya tidak yakin apakah itu akan "membingungkan" sama sekali, tetapi selama editor dan tab terbuka selalu persis sama dan dalam urutan yang sama, saya dapat membayangkan bahwa itu akan bekerja dengan sangat baik.
2. Saya pikir Anda menyebutkan bahwa tab yang sebelumnya ditutup tersedia di salah satu tampilan CTRL + Tab + sesuatu, tetapi pernahkah Anda memikirkan tentang pintasan CTRL + SHIFT + T (batalkan tutup tab) yang hanya akan membuka kembali tab yang sebelumnya ditutup (dalam urutan yang mereka tutup)?

Saya hanya bisa bergabung selama 15 menit terakhir atau lebih. Apakah itu direkam?

Saya kecewa (tapi tidak terkejut) melihat bahwa tab cenderung
menjadi default. Harapan Anda akan terus menjaga yang ringan
lingkungan VS Code dan untuk mengeksplorasi alur kerja progresif.

Terima kasih,

James

Pada Kamis, 21 Apr 2016 pukul 11:07, anyong [email protected] menulis:

Pengingat untuk siapa saja yang berencana bergabung dengan hangouts - sekarang jadi
klik link di atas. Hanya ~ 5 orang sejauh ini.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

Sepertinya ada beberapa ide bagus. Saya berharap untuk melihat ini beraksi.

FWIW (dan jika masih relevan) Saya masih berpikir lebih baik tidak memiliki tab di UI _ secara default_. Header editor bersih yang bagus yang dapat diklik untuk melihat daftar file jika sidebar tidak terlihat, atau CTRL + TAB, adalah yang saya harapkan :)

Terima kasih untuk semua orang yang dapat hadir dan memberi kami umpan balik hari ini. Kami telah membuat catatan dan terus mengikuti masalah GitHub di sini. Kami mendengarkan semua orang.

@indiejames dan @RyanEwen ya kami mencatat, dan akan segera kami posting. Kami belum memutuskan secara pasti tentang perilaku default. Namun, kami mengusulkan solusi yang akan memudahkan untuk memilih apakah Anda ingin menggunakan file, tab, atau keduanya yang berfungsi atau tidak.

@ bgashler1 Anda menyebutkan bahwa Anda sedang mencari solusi yang akan memungkinkan orang untuk memilih apakah mereka menginginkan file yang berfungsi, tab atau keduanya bagaimana dengan tidak ada? apakah itu pilihan? tergantung pada proyek dan bahasa yang saya kerjakan, tidak ada yang bisa bagus untuk skrip seperti PowerShell. :)

Terima kasih kepada semua orang yang telah meluangkan waktu untuk bergabung dengan panggilan hari ini dan memberikan umpan balik, kami sangat menghargainya. @anyong telah melakukan pekerjaan yang bagus sudah merangkum apa yang kami sajikan tetapi saya akan menambahkan beberapa detail lagi di bawah dan beberapa tangkapan layar.

Desain visual

Pertama, gambar ini menunjukkan bagaimana menurut kami tab mungkin terlihat di VS Code:

Kami bertujuan untuk mendapatkan tampilan yang ringan, tidak mengganggu, sesuatu yang cocok dengan VS Code lainnya. Kami belum menggambarkan seperti apa tampilannya dalam tema terang.

Seperti yang Anda lihat pada gambar di atas, tab berisi tombol tutup di sebelah kiri nama. Ketika file berisi perubahan yang belum disimpan, kami menunjukkan indikator kotor di mana tombol tutup berada.

Mengarahkan kursor ke tab akan menampilkan keterangan alat dengan jalur lengkap untuk file tersebut di tab.

Pratinjau tab

Untuk membedakan dengan jelas tab pratinjau dari tab yang terbuka, kami memiringkan judul pada tab seperti pada gambar rangka berikut.

Kami membahas tindakan untuk mempromosikan tab pratinjau ke tab terbuka penuh:

• Mengedit konten di dalam tab
• Mengklik dua kali file di explorer
• Mengklik ganda tab pratinjau di grup tab

Meluap

Tab terbuka di sebelah kanan tab aktif. Jika tidak ada cukup ruang untuk menampilkan semua tab dalam grup tab, kami melimpahkan tab. Kami tidak memotong nama file di dalam tab untuk memberi lebih banyak ruang untuk lebih banyak tab.

Kami menampilkan chevron setiap kali ada luapan. Mengklik tanda pangkat itu akan menampilkan dialog buka cepat yang mencantumkan semua tab di grup tab, memungkinkan pengguna menemukan tab yang ingin mereka lihat.

Mengklik tab yang sedang meluap akan menampilkan tab tersebut.

Menavigasi tab

Perintah berikut memungkinkan pengguna untuk menavigasi di antara tab:

• Ctrl-Tab menampilkan daftar semua tab di dalam grup tab aktif:
  
• Ctrl Alt Tab menampilkan daftar semua tab di dalam semua grup tab
  
• Buka cepat menunjukkan riwayat linier semua tab
  

File kerja

Kami mengganti nama file kerja menjadi editor terbuka untuk lebih mencerminkan apa ini sebenarnya.

Daftar editor terbuka berfungsi sama dengan tab. Kami hanya mencantumkannya di penjelajah daripada memvisualisasikannya sebagai tab.

Jika sebuah file terbuka di dua atau lebih grup editor, kami menunjukkan ini di daftar editor terbuka:

Setiap editor yang dibuka pengguna akan muncul di daftar editor terbuka. Misalnya, editor diff muncul seperti ini:

Setiap grup hanya berisi satu tab pratinjau.

Tanda pangkat di kanan atas grup editor aktif menunjukkan apakah ada tumpukan editor atau tidak.

Dalam kasus ini, menutup editor akan menampilkan editor di bawahnya dalam tumpukan, daripada menutup editor sepenuhnya.

Menutup editor (misalnya dengan Ctrl-W) juga menghapus editor dari daftar editor terbuka.

@tokopedia

Untuk membedakan dengan jelas tab pratinjau dari tab yang terbuka, kami memiringkan judul pada tab seperti pada gambar rangka berikut.

Selain memiringkannya, akan sangat bagus jika ada opsi untuk meredupkan warna tab agar _ benar-benar_ jelas.

Seperti yang saya tulis sebelumnya, saya juga ingin tahu apakah ada opsi untuk tidak memiliki tab atau editor terbuka sama sekali, ini bisa menjadi skenario yang berguna bagi orang-orang yang melakukan skrip misalnya PowerShell.

@eyalsk disebutkan dalam diskusi bahwa tab dan editor terbuka harus diaktifkan atau dinonaktifkan secara independen untuk salah satu / keduanya / tidak ada.

@anyong terima kasih! :)

Ctrl-Tab menampilkan daftar semua tab di dalam grup tab aktif:

Akhirnya! Tab atau tidak, inilah perilaku yang saya tunggu-tunggu! Tidak ada lagi tersesat dalam riwayat file saya.

Menutup editor (misalnya dengan Ctrl-W) juga menghapus editor dari daftar editor terbuka.

Bagus! Mudah-mudahan ini akan terasa lebih intuitif dan membantu membersihkan kekacauan di _Working files_.

Sekarang saya hanya akan menunggu https://github.com/Microsoft/vscode/issues/5554 ditutup.

Hmm saya tidak tahu apakah ini dianggap tetapi saya baru saja memikirkannya, banyak monitor suppot! dalam Visual Studio Saya dapat menyeret tab ke monitor lain dan membuat jendela / tampilan tab baru, apakah hal seperti ini sedang dipertimbangkan? Saya membayangkan itu mungkin untuk mencapai ini dengan membuat proses VSCode baru dan menyeret tab antar proses melalui komunikasi antar proses, hal yang sama berlaku untuk editor terbuka, hanya sebuah ide, :)

Tolong, tolong, bisakah Anda menjadikan "tab pratinjau" opsional - yaitu memiliki opsi untuk membuat promosi otomatis apa pun menjadi tab permanen dan tidak akan pernah ada barang yang menghilang. Saya tahu Anda sedang mendiskusikan cara untuk secara visual membedakan tab yang sementara tetapi, terus terang, itu tidak akan berhasil untuk orang-orang seperti saya yang menavigasi antar file begitu cepat (terutama dengan Go-To-Definition et al.) Sehingga tidak ada waktu untuk periksa secara visual tab untuk mengetahui bagaimana mungkin perilakunya, saya tidak ingat bagaimana saya membuka file atau apakah saya kebetulan telah mengeditnya dan saya merasa sangat membingungkan ketika file menghilang secara acak. (Saya tahu itu tidak acak tetapi mungkin juga.)

Saya biasanya mengubur diri saya di tab terbuka sampai saya menyelesaikan satu unit pekerjaan dan kemudian menutup semuanya pada saat yang sama saya pergi untuk berkomitmen.

Terima kasih @eyalsk , ya kami mempertimbangkannya. Pada akhirnya kami ingin dapat mendukung ini, tetapi pekerjaan yang diperlukan untuk berbagi konteks di antara beberapa proses cukup signifikan dan karenanya tidak mungkin terjadi saat kami mengerjakan sisa UX manajemen dokumen. Itu pasti sesuatu yang ingin kami lakukan.

@stevencl Saya akan senang jika menyeret baru saja membuka jendela vscode baru dengan file itu terbuka (mungkin dengan folder yang sama juga terbuka).

Terima kasih @Tyriar , kami akan terus menyelidiki ini. Jika ada cara agar kami dapat membuatnya bekerja dengan baik, kami ingin sekali dapat melakukannya.

@stevencl Saya hanya khawatir akan membutuhkan lebih banyak pekerjaan untuk menambahkannya di masa mendatang jadi _when_ Anda meningkatkan infrastruktur pastikan untuk menyimpannya di backlog Anda! ;)

tab silakan

Senang melihat ini. Suka proposal ringan dan bahwa Anda sedang menemukan cara untuk tidak merusak pengalaman file kerja.

Berharap untuk mencobanya. Terima kasih untuk mendengarkan.

@stevencl Sepertinya yang terbaik dari kedua dunia. Tampak luar biasa! Tab muncul seperti yang saya harapkan agar sesuai dengan UI lainnya, dan sepertinya saya akan mendapatkan apa yang saya inginkan dengan perubahan Working Files :)

Akankah Open Editor mendukung lebih dari 2 grup editor? Hanya ingin tahu bagaimana Anda menamainya jika lebih rumit dari Kiri dan Kanan.

Ya, ini akan tetap didukung.

Dari: Maxime Quandallemailto: [email protected]
Dikirim: 22/04/2016 23:09
Kepada: Microsoft / vscodemailto: [email protected]
Cc: Steven Clarkemailto: [email protected]; Mentionmailto: [email protected]
Subjek: Re: [Microsoft / vscode] Tab yang sesuai untuk file yang terbuka (# 224)

Akankah reposisi panel dengan seret & lepas masih dapat dilakukan di bawah proposal @stevencl ?

Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

@stevencl Saya pikir apa yang Anda uraikan dari diskusi beberapa hari yang lalu sangat bagus. Inilah yang kita semua tunggu-tunggu tentang tab. Beberapa editor lain yang saya gunakan juga menerapkan konfigurasi panel horizontal maupun vertikal. Ini memungkinkan Anda untuk membuka dua file berdampingan di bagian atas dan satu atau dua file dibuka di bawahnya. Meskipun ini bukan fitur kritis, saya sering melewatkan fitur ini saat mengembangkan aplikasi web & aplikasi seluler front end. Alasannya adalah sebagian besar yang saya kerjakan adalah MVC atau turunannya sehingga memiliki model, view, controller dan beberapa file UI (css, Js, dll) yang terbuka pada saat yang sama adalah keuntungan yang sangat besar. Apakah ada rencana untuk memasukkan ini juga? Atom melakukan ini dengan sangat baik yang merupakan editor terakhir yang saya gunakan sebelum VSCode. Sayangnya itu sangat kurang di area lain yang VSCode unggul, oleh karena itu saya satu-satunya penggunaan VSCode. Jika tidak dalam rilis yang direncanakan dengan tab & perubahan manajemen dokumen, ini akan menjadi peningkatan besar di masa depan.

@ jayrosen1576 Pemisahan horizontal https://github.com/Microsoft/vscode/issues/1749 , pastikan untuk: +1: untuk menunjukkan minat Anda.

Kerja bagus, kawan-kawan, bingkai kawatnya terlihat seperti akan bekerja dengan sangat baik.

Hai @evencl
Terima kasih atas kerja bagusnya dan ini 2 sen saya tentang tombol tutup di sebelah kiri.
Saat ada banyak file yang terbuka dan tab semakin menyusut, ruang kecil untuk setiap tab hanya akan cukup untuk menampilkan tombol tutup yang akan memudahkan untuk menutup tab secara tidak sengaja daripada memilihnya.

Ikon indikator kotor masih dapat berada di kiri karena tidak hanya menunjukkan status file, tetapi memindahkan tombol tutup ke kanan akan memudahkan kita mengenali nama file dan akan mencegah tindakan penutupan yang tidak disengaja.

@stevencl Mock-up tampak hebat dan deskripsi fungsinya terdengar tepat. Kesan awal saya, adalah bahwa tabnya agak besar ... mungkin lebih besar dari yang seharusnya, dan tampaknya menyia-nyiakan ruang. Saya memahami trade-off antara presentasi penuh gaya dan fungsionalitas, tapi ini adalah alat pengembang, desain praktis mengalahkan gaya yang pasti. Saya yakin Anda telah bereksperimen dengan kalibrasi ini, jadi saya berharap untuk mencobanya!

@hsyn menurut pemahaman saya bahwa tab tidak akan menyusut, dan tab overflow akan tersedia dari tombol luapan chevron. Tombol tutup seharusnya tidak menjadi masalah.

Tab terbuka di sebelah kanan tab aktif. Jika tidak ada cukup ruang untuk menampilkan semua tab dalam grup tab, kami melimpahkan tab. Kami tidak memotong nama file di dalam tab untuk memberi lebih banyak ruang untuk lebih banyak tab.

Saya tidak setuju dengan itu. Jika layar terbagi menjadi 2-3 kolom, Anda akan menampilkan paling banyak 1-2 tab dan mengisi sisanya. Tolong, lakukan apa yang dilakukan browser, kami menggunakannya setiap hari dan intuitif dan kami terbiasa. Saya mendorong Anda untuk menggunakan pola yang sudah mapan, beberapa di antaranya telah berkembang selama lebih dari satu dekade sekarang. Jangan melawan arus.

Saya tidak setuju dengan itu. Jika layar terbagi menjadi 2-3 kolom, Anda akan menampilkan paling banyak 1-2 tab dan mengisi sisanya. Tolong, lakukan apa yang dilakukan browser, kami menggunakannya setiap hari dan intuitif dan kami terbiasa. Saya mendorong Anda untuk menggunakan pola yang sudah mapan, beberapa di antaranya telah berkembang selama lebih dari satu dekade sekarang. Jangan melawan arus.

Beberapa browser melakukan kombinasi tab menyusut tetapi kemudian meluap melebihi ambang tertentu. Firefox melakukannya; cukup yakin iOS Safari melakukan (atau melakukannya) juga.

Ketika cukup banyak tab terbuka sehingga Anda hampir tidak dapat melihat beberapa huruf di masing-masing tab (meskipun dalam praktiknya saya biasanya tidak memiliki banyak yang terbuka), itu tidak lebih berguna daripada overflow.

@alexgorbatchev Saya pasti mendapatkan dari mana Anda berasal, tetapi ini adalah sesuatu yang mereka jelaskan dalam panggilan konferensi beberapa hari yang lalu - dari perspektif lain, memiliki banyak tab yang terbuka dan tidak dapat membaca nama salah satu dari mereka adalah bukan solusi yang baik juga. The "overflow" adalah semacam kompromi antara tidak ada tab sama sekali dan tab "gaya Chrome" standar yang menyusut terlupakan. Memaksa tab untuk setidaknya menampilkan nama file berarti tab yang terlihat setidaknya akan berguna.

Tapi Anda memang memberi saya ide untuk para pengembang - saya pikir masalah sebenarnya di sini adalah, sementara kami tahu kami tidak dapat menggunakan 20 tab ketika semua nama file disembunyikan, setidaknya kami _tahu_ bahwa ada 20 tab yang terbuka dan itu memberi kami perasaan tertentu "Saya tahu di mana file saya jika saya membutuhkannya, mereka tidak hilang begitu saja." Semua yang diperlukan untuk memperbaikinya adalah indikator yang menunjukkan _number_ dari tab yang saat ini tersembunyi, indikatornya bisa berupa lingkaran kecil di atas chevron luapan agar tidak mengambil ruang horizontal tambahan.

Terimakasih semuanya. Kami tidak menampilkannya di mockup tetapi niat kami adalah ketika diperlukan, kami akan mengecilkan tab sehingga hanya nama file dan tombol tutup yang terlihat. Untuk alasan yang disebutkan @anyong , kami tidak berpikir kami ingin menciut ke titik di mana nama file tidak dapat dibedakan satu sama lain. Kami berpikir bahwa mungkin lebih umum untuk banyak tab dalam editor kode memiliki nama yang mirip daripada tab browser yang memiliki nama yang mirip (misalnya, mungkin ada banyak nama file dengan awalan yang sama). Oleh karena itu, kami berpikir bahwa menyusutkan tab di editor kode memiliki konsekuensi yang berbeda dengan di browser.

Kami bermaksud untuk menunjukkan kapan tab berada dalam kontrol luapan dengan chevron ganda tetapi menempatkan lencana dengan jumlah tab yang meluap juga merupakan ide yang menarik. Apakah maksud bahwa angka tersebut hanya menunjukkan bahwa ada tab luapan atau apakah jumlah tab luapan sebenarnya penting?

Terima kasih telah menyelesaikannya @stevencl.

Satu kasus tepi yang perlu diingat dengan nama file di tab adalah beberapa file dengan nama yang sama dibuka dari folder yang berbeda (index.js, README, LICENSE, package.json, dll).

Saya mungkin tidak akan menggunakan tab sama sekali, tetapi saya pikir itu juga layak untuk ditunjukkan
browser biasanya menampilkan favicon untuk situs di tab yang
membuatnya lebih mudah untuk diidentifikasi bahkan saat tab menyusut melebihi batasnya
itu bisa dibaca. File sumber tidak boleh memiliki favicon untuk membedakannya,
dan, seperti yang ditunjukkan Steven, nama file seringkali serupa dalam kode sumber.

Pada Kamis, 28 Apr 2016 pukul 12.16, Steven Clarke [email protected]
menulis:

Terimakasih semuanya. Kami tidak menunjukkannya di mockup tetapi niat kami adalah
bahwa bila diperlukan, kita akan mengecilkan tab sehingga hanya nama saja
file dan tombol tutup terlihat. Untuk alasan @anyong
https://github.com/anyong menyebutkan, kami rasa kami tidak ingin menyusut
titik di mana nama file tidak dapat dibedakan satu sama lain. Kami pikir
yang mungkin lebih umum dimiliki banyak tab dalam editor kode
nama yang mirip daripada tab browser yang memiliki nama yang mirip (mis.,
mungkin ada banyak nama file dengan awalan yang sama). Demikianlah yang kami pikirkan
menyusutkan tab di editor kode memiliki konsekuensi yang berbeda dengan di
browser.

Kami bermaksud untuk menunjukkan kapan tab berada dalam kontrol luapan dengan ganda
chevron tetapi menempatkan lencana dengan jumlah tab yang meluap adalah
ide yang menarik juga. Apakah maksud bahwa nomor tersebut hanya menunjukkan itu
ada tab luapan atau apakah jumlah tab luapan sebenarnya penting?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

Terima kasih @alexgorbatchev. Kami memiliki beberapa ide tentang cara menampilkan jalur ke file agar dapat menghilangkan keraguan dalam kasus ini. Dalam mockup kesetiaan tinggi yang ditunjukkan di atas misalnya, kami menunjukkan jalur ke file di bawah nama file. Ini hanya satu ide dan mungkin tidak berhasil ketika jalannya panjang. Cara lainnya adalah menempatkan jalur di bilah status. Banyak hal untuk dijelajahi ...

@tokopedia

Apakah maksud bahwa angka tersebut hanya menunjukkan bahwa ada tab luapan atau apakah jumlah tab luapan sebenarnya penting?

Saya akan berpikir menunjukkan jumlah tab yang sebenarnya terbuka (tetapi tersembunyi dari pandangan) akan menyelesaikan masalah. Pada dasarnya, orang terbiasa melihat ini (yah, setidaknya berbicara untuk diri saya sendiri):

jadi mereka secara intuitif memiliki gagasan tentang "Saya punya banyak tab yang terbuka" vs. "Saya punya 2 atau 3 tab terbuka"

Lencana yang menunjukkan "20" jauh lebih kecil (tidak ada real estat tambahan, pada dasarnya) daripada menunjukkan 20 tab menyusut kecil / tidak berguna, tetapi masih memungkinkan saya untuk segera mengetahui bahwa (a) tab tersembunyi ada di sana dan (b) bagaimana tepatnya banyak disana.

Saya baru mengenal utas ini tetapi 2p saya sebagai pengguna VS2015 penuh:

Menantikan untuk memiliki tab di vscode, karena file yang berfungsi tidak pernah cocok dengan saya (meskipun sekarang saya melihat bahwa menekan ctrl-f4 tidak menghapus dari set itu seperti yang saya asumsikan).

Penggemar berat tab pratinjau, senang melihatnya masuk.

Penasaran mengapa tab baru akan terbuka di sebelah kanan tab aktif. Saya berharap 'karena browser web' atau 'karena luhur' adalah jawabannya, tetapi tampaknya berlawanan dengan intuisi saya, terutama jika tab meluap dengan bersembunyi dari kiri (ke chevron di sebelah kanan).

Saya berharap untuk melihat menu klik kanan untuk tab sesuai VS ... 'Tutup semua' (untuk grup) yang paling penting, tidak repot tentang 'Tutup semua kecuali ini'. Kotak penyimpanan gaya VS untuk semua file yang dimodifikasi akan berguna di sini.

Tombol tutup di sebelah kiri aneh bagi saya - saya menganggap itu adalah konvensi mac / linux - tetapi selama 'klik tombol tengah' pada tab menutup editor (prompt untuk menyimpan jika ada), maka tidak perlu repot. Saya dapat melihat mengapa di sebelah kiri menutup sekumpulan file dengan cepat secara berurutan, tetapi klik tengah lebih baik untuk itu (meskipun mungkin tidak untuk Mac atau notebook tanpa scrollwheel?).

Pemilih file Chevron harus memungkinkan pengetikan untuk lompat cepat ke file. Bukannya saya pribadi berencana untuk membuka cukup file untuk menampilkan chevron, (dan ketika saya melakukannya, saya pasti akan menggunakan ctrl-p) tetapi itu terjadi.

Nomor Chevron - apakah ini jumlah _hidden_ ​​tab / file / editor dalam grup ini, atau _all_ termasuk file yang terlihat? Saya hanya akan memperdebatkan item yang tersembunyi, terutama jika Anda hanya menampilkan chevron (dan dengan demikian hitungannya) ketika sesuatu meluap dari baris tab.

Pada catatan yang sedikit terkait, jika saya ctrl-f4 (atau ctrl-w? Tampaknya ctrl-f4 versi non-windows kecuali jika saya salah), saya berharap jika tab menghilang, itu menutup editor dan harus meminta untuk menyimpan / membuang dan menghapusnya dari ctrl-tab / ctrl-alt-tab / file yang berfungsi ... Saya dapat melihat ada beberapa perubahan keybind yang dapat saya lakukan saat ini untuk mengaktifkan fungsi ini, tetapi saya kesulitan untuk lihat mengapa dalam antarmuka berbasis tab keberadaan tab tidak terkait langsung dengan 'saat ini' - / keterbukaan file / editor.

Menyukai apa yang Anda semua lakukan di vscode, itu terlihat luar biasa ☺

Saya mencoba menggunakan riwayat file seperti yang disarankan, dan setelah sebulan saya tidak merasa perlu tab lagi. Di VS, memiliki banyak tab terbuka benar-benar mengganggu. Saya benci jika ada terlalu banyak dan dipindahkan ke dropdown kecil tab tersembunyi. Saya pikir saya benar-benar ingin menggunakan riwayat file di VS sekarang juga.

Mengenai file yang berfungsi, saya merasa sangat menjengkelkan karena semuanya ada di sana. Sangat menjengkelkan sampai-sampai saya tidak pernah membukanya dan tetap menutupnya. Satu-satunya hal yang menurut saya berguna adalah melihat file baru yang belum disimpan, atau file apa pun yang belum disimpan. Dengan cepat menjadi terlalu besar untuk saya bahkan pedulikan. Tidak yakin bagaimana ini bisa diperbaiki. Mungkin hanya menampilkan file yang belum disimpan, tetapi itu akan memiliki beberapa efek samping yang aneh.

Bagaimanapun, saya percaya riwayat file sekarang. :)

Saya pikir akan sangat keren jika kita bisa menambahkan kemampuan untuk bolak-balik dalam sejarah menggunakan shift+cmd+[ dan shift+cmd+] . ini adalah cara pintas default untuk menavigasi di sekitar tab di aplikasi lain dan dapat menggunakannya untuk menavigasi riwayat, saya pikir akan sangat membantu saya setidaknya menjadi orang yang beriman.

Sunting: pada dasarnya mencapai ini dengan menerapkan

  { "key": "shift+cmd+[", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+]", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+[", "command": "workbench.action.quickOpenNavigateNext", "when": "inQuickOpen" },
  { "key": "shift+cmd+]", "command": "workbench.action.quickOpenNavigatePrevious", "when": "inQuickOpen" }

sebagai pengikatan kunci khusus

Mampu merobek bagian kode ke jendela baru akan berguna menurut saya juga. Tidak yakin apakah hal itu mungkin.

@JoshClose sangat mungkin tetapi mereka kekurangan infrastruktur untuk komunikasi antar-proses untuk editor itu sendiri sehingga untuk dua contoh untuk berkomunikasi dan melakukan apa pun yang mereka butuhkan untuk memiliki protokol untuk ini terlebih dahulu.

... tab berisi tombol tutup di sebelah kiri nama

Apakah ada alasan khusus untuk melanggar konvensi? Saat membaca LTR, informasi terpenting adalah nama file, bukan tombol tutup. Memindahkannya ke kanan juga akan mempermudah untuk membuat tombol tutup tersembunyi secara default (dan ditampilkan saat mengarahkan kursor). Pada tahap selanjutnya, pengguna mungkin juga ingin memiliki ikon file di sebelah kiri nama file.

Kami membahas tindakan untuk mempromosikan tab pratinjau ke tab terbuka penuh ...

Saya pikir dua opsi pertama mungkin sudah cukup. Mengklik dua kali tab mungkin berguna untuk hal lain di masa mendatang.

Kami memiliki beberapa ide tentang cara menampilkan jalur ke file agar dapat menghilangkan keraguan dalam kasus ini.

Bagaimana dengan hanya menampilkan tooltip (dengan jalur relatif) saat mengarahkan kursor ke tab? Ini akan membuat desain tidak terlalu berantakan, dan tabnya tidak harus setinggi itu.

Kami menampilkan chevron setiap kali ada luapan ...

Firefox menangani tab overflow dengan baik - ia memiliki lebar tab maksimal, tombol gulir kiri / kanan, daftar menu drop-menu semua tab (dengan tab yang saat ini terlihat ditandai), dll.

Akan sangat menyenangkan jika tombol tutup tab cocok dengan konvensi platform: Di sebelah kiri pada OS X, di sebelah kanan pada Windows.

Setelah menggunakan VSCode untuk beberapa waktu sekarang, saya pikir mode _Working Files_ telah berkembang pada saya, banyak!

Berikut beberapa alasannya:

1. Meskipun kedengarannya berlawanan dengan intuisi, menutup file yang tidak saya gunakan (ctrl-w) tidak akan mengeluarkannya dari File yang Bekerja. Ini sangat bagus karena sering kali saya menemukan diri saya membuka kembali file yang baru saja ditutup (dalam proyek React) saat bekerja dengan file terkait (atau kelas anak). Jadi, ketika saya _ merasa_ ingin menutup file tidak memetakan satu-ke-satu waktu ketika saya _harus_ menutupnya.
2. Saya suka Force-Close eksplisit, yang ditawarkan oleh workbench.files.action.closeFile .
3. Saya telah memetakan ulang workbench.files.action.closeFile ke Ctrl + k Ctrl + w karena ini membutuhkan (sedikit) usaha yang lebih sedikit daripada Ctrl + kw ,
4. Saya dapat melihat nama file lengkap dan jalur di bilah atas editor -> Ini sangat penting dalam proyek yang sangat bersarang (seperti yang saya miliki) yang memiliki file dengan nama yang mirip atau sama ( index.js ?) Dan hanya cara untuk membedakannya adalah dengan jalur.
5. Sedikit suara tab = Zen!

Jadi, dengan cara saya mencoba mengatakan bahwa tolong _jangan hapus_ arus saat ini jika Anda memperkenalkan tab.

@kumarharsh mengapa mereka menghapusnya? jika ada, mereka mungkin akan memperbaikinya untuk Anda! :)

Jika indikator kotor menggantikan ikon TUTUP, bagaimana kita dapat menutup file jika kita tidak ingin menyimpan perubahan kita? Apakah ctrl-w masih tersedia?

Tidak bisakah indikator kotor berubah menjadi tombol tutup saat melayang?
Itu solusi yang cukup umum ...

Pada Rabu, 4 Mei 2016 pukul 23.28, rojorojo [email protected] menulis:

Jika indikator kotor menggantikan ikon TUTUP, bagaimana kita bisa melakukannya
tutup file jika kita tidak ingin menyimpan perubahan kita? Akankah ctrl-w masih ada
tersedia?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

@rojorojo kami melakukan apa yang juga disarankan @anyong , jadi Anda tidak akan mengalami masalah. Dan ya, Ctrl + W akan tetap tersedia.

Terima kasih atas semua masukannya.

Kami menjalankan studi UX pada desain terbaru kami pada akhir bulan ini. Jika Anda memiliki waktu luang satu jam pada tanggal 25 atau 26 Mei dan ingin berpartisipasi dalam studi ini, silakan daftar di sini: https://calendly.com/stevencl/vs-code-docmgmt/

Sayangnya saya hanya dapat menawarkan waktu pada siang hari (Waktu Musim Panas Inggris) dan tidak dapat menjalankan sesi pada malam hari.

Kami berharap memiliki beberapa bit kerja yang dapat Anda coba, serta beberapa wireframe desain yang belum kami tunjukkan.

Tunggu, saya suka perilaku UI saat ini, apakah akan ada konfigurasinya?

Tiga minggu lalu saya sangat menginginkan tab. Saya bahkan menunda beralih ke VSC untuk sementara waktu karena tidak memiliki tab. Sekarang saya telah menghabiskan beberapa minggu menggunakan VSC, saya bahkan tidak ingin tab. Pada titik ini saya pikir mereka akan menghalangi jalan saya.

Saya berharap saat ini dibangun bisa menjadi pilihan sehingga bagi kita yang menginginkannya dapat melanjutkan di lingkungan saat ini.

Sebagai seseorang yang sangat menyukai tab vertikal (skalanya jauh lebih baik dan bekerja lebih baik pada tampilan layar lebar), saya bertanya-tanya: Mengapa Anda membutuhkan tab dan "editor terbuka". Jika yang terakhir pada dasarnya adalah "file kerja" dengan perilaku tab maka hanya itu yang saya perlukan / inginkan.

Saya ingin menambahkan suara saya untuk memastikan tab tersebut opsional. Saya sangat tidak menyukai tab editor dan lebih menyukai panel di sisi kiri jendela. Saya mengerti menambahkannya untuk orang-orang yang menginginkannya, tapi tolong, jangan paksa mereka pada kami. Tidak memilikinya adalah salah satu hal yang saya _suka_ tentang editor ini.

Dua sen saya: Saya tidak pernah ingin tombol tutup; bagi saya, itu adalah pemborosan real estat yang terkadang menyebabkan frustrasi (klik tidak sengaja). Jauh lebih sulit untuk mengklik tengah secara tidak sengaja daripada mengklik 1px secara tidak sengaja terlalu jauh ke kiri.

Saya juga berpikir indikator kotor adalah pemborosan real estat. Di Sublime Text, saya mengkonfigurasi "dirty" untuk hanya mengubah warna font tab. Sebelumnya, saya juga telah membuatnya menjadi miring tetapi sepertinya Anda memiliki rencana untuk mencetak miring pratinjau.

Sisi kiri perbatasan terlalu lebar

@ be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

Teman-teman, saya mengerti bahwa ini adalah utas yang panjang jadi Anda mungkin tidak membaca semuanya, tetapi harap baca posting di sini . Tab akan bersifat opsional, pengembang sudah sangat, sangat menyadari poin yang Anda kemukakan.

Calon pengepos: lihat utas ini untuk melihat apakah masalah Anda sudah diatasi - setiap kali Anda mengeposkan, ada ratusan orang yang menerima email dengan: +1: Terima kasih

@anyong Namun "Open editor" memisahkan daftar file kerja yang ada menjadi dua bagian jika Anda membuka dua kolom. Saya menyukai gagasan bahwa hanya ada satu "file yang berfungsi" untuk semua kolom editor.
Jadikan ini opsional juga.

@ be5invis Satu-satunya perbedaan adalah adanya pemisah visual. Anda masih dapat menyeret file dan membukanya di editor apa pun yang Anda suka.

@anyong Bisakah saya menyembunyikannya? Dan jika saya memilih untuk menyembunyikan "pemisah", dan Ctrl-Tab dalam satu kolom editor, dapatkah saya beralih ke file terbuka di kolom lain? Apa yang diinginkan para penipu adalah mempertahankan sepenuhnya perilaku yang ada.

@ be5invis dari komentar yang saya

Ctrl Alt Tab menampilkan daftar semua tab di dalam semua grup tab

Jadi ya, Anda masih dapat mengatur pengikatan kunci untuk mempertahankan perilaku Ctrl + Tab saat ini jika Anda mau.

@anyong Itu bagus.
Tapi tetap, dapatkah saya menyembunyikan indikator "kiri / kanan" dan membuat daftar terlihat seperti satu kesatuan?

Itu akan menjadi pertanyaan untuk @stevencl

Yay! Saya harap kita segera mendapatkan tab!

Kabar Baik .. kami Mendapatkan Tab..Tapi kami tidak ingin kehilangan Folder 'Working Files'. Simpan bersama dengan tab?

Hebat! Grup Tab

@ be5invis Anda benar, kami bermaksud menampilkan beberapa grup editor dalam daftar editor terbuka setelah Anda memisahkan editor. Tetapi Anda tidak perlu melakukan ini untuk dapat bekerja dengan banyak file. Anda akan membagi editor untuk melihat lebih dari satu file sekaligus. Jika Anda membiarkan satu editor terlihat setiap saat, Anda masih dapat membuka banyak file. Misalnya, di tangkapan layar ini

Saya memiliki dua file yang terbuka tetapi saya hanya melihat salah satunya karena saya belum membagi editor. Daftar editor terbuka menampilkan file dan saya dapat berinteraksi dengannya di sana atau melalui kontrol luapan di kanan atas. (Dan perhatikan bahwa tidak ada tab yang ditampilkan di sini - ini adalah opsi tanpa tab.)

Alasan kami melakukan ini adalah karena ada potensi kebingungan saat mengelola file yang terbuka di dua editor dalam pengaturan file kerja saat ini. Misalnya, pada tangkapan layar di bawah ini dari produk saat ini, apa yang akan terjadi ketika saya menutup file app.js dalam daftar file yang berfungsi. Haruskah kedua editor menutup atau hanya salah satunya. Dan jika salah satunya, yang mana?

Kami ingin menghindari ambiguitas dan ketidakpastian, jadi kami memilih untuk lebih eksplisit tentang file yang terbuka di setiap grup editor.

Itu juga mengapa kami mengganti nama file kerja menjadi editor terbuka karena kami merasa itu mencerminkan perilaku baru dengan lebih baik.

Go To Definition (F12) opsi perlu ditingkatkan (Bahkan Definisi ada di halaman lain dengan dalam proyek)) seperti teks luhur? Saya menghadapi masalah ini sejak lama saya menginstal kode VS? Ada bantuan dalam hal ini?

@ vinod-a-ext - buka edisi baru yang menjelaskan masalah yang Anda hadapi dengan Go To Definition.

@tokopedia
Pergi ke Masalah Definisi di VS Code
https://github.com/Microsoft/vscode/issues/6238

@stevencl Pendapat saya adalah Anda dapat menyembunyikan label di "editor terbuka", dan cukup menggambar garis untuk mewakili panel yang berbeda. Setelah panel ditutup, dua daftar dapat digabungkan secara alami.

Terima kasih atas sarannya, kami pasti akan menjelajahi perawatan visual yang berbeda untuk ini.

Tanggal: Sel, 10 Mei 2016 04:06:34 -0700
Dari: [email protected]
Kepada: [email protected]
CC: [email protected]; [email protected]
Subjek: Re: [Microsoft / vscode] Tab yang sesuai untuk file yang terbuka (# 224)

@stevencl Pendapat saya adalah Anda dapat menyembunyikan label di "editor terbuka", dan cukup menggambar garis untuk mewakili panel yang berbeda. Setelah panel ditutup, dua daftar dapat digabungkan secara alami.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

Saya penasaran, program apa yang Anda gunakan untuk membuat mock up, seperti ini

Kami menggunakan PowerPoint untuk maket ini. Tujuan kami adalah untuk fokus pada aliran interaksi, bukan desain visual sehingga alat di PowerPoint berfungsi dengan baik untuk tingkat detail tersebut. Melakukan berbagai hal di PowerPoint juga memungkinkan kita untuk dengan mudah merangkai urutan layar untuk merasakan aliran yang lebih baik.

Tanggal: Sel, 10 Mei 2016 05:03:55 -0700
Dari: [email protected]
Kepada: [email protected]
CC: [email protected]; [email protected]
Subjek: Re: [Microsoft / vscode] Tab yang sesuai untuk file yang terbuka (# 224)

Saya penasaran, program apa yang Anda gunakan untuk membuat mock up, seperti ini

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

Baru datang ke sini setelah melihat catatan rilis April. Thread terbuka untuk waktu yang lama - tetapi saya +1 untuk desain aslinya - yaitu tidak ada tab. Awalnya itu mengganggu saya - tetapi kemudian saya semakin menghargai dan memahami filosofi di baliknya ... Sekarang ketika saya memikirkan Atom dan tab spam ... Saya menggigil. Selain itu - Saya suka keterlibatan dan komentar bijaksana serta umpan balik dari pengembang.

Menantikan untuk mencobanya. Satu hal yang ingin saya lihat adalah menggabungkan beberapa file terkait ke dalam satu tab (mirip dengan plugin VS ini )

Ini akan sangat berguna untuk tetap teratur dalam pengembangan Angular 2, di mana Anda biasanya memiliki file terkait:

• widget.component.css
• widget.component.html
• widget.component.ts
• widget.component.spec.ts

Setuju dengan @lucidtech kami biasa menggunakan Folder 'File yang berfungsi'. Saya pikir tab dapat digabungkan bersama dengan opsi hebat ini?

Saya setuju dengan @coreh bahwa lokasi tombol tab tutup harus sesuai dengan konvensi platform. Ini akan menjadi sakelar konteks yang agak membuat frustasi jika lokasi tombol tutup berubah ketika saya pindah dari Visual Studio ke Visual Studio Code.

Dua sen saya: Salah satu alasan mengapa saya _love_ Code over Atom, Sublime, atau editor hipster lainnya, ahem, adalah karena ia tidak mencoba untuk membungkam dalam konsep "tab" browser web. IDE tradisional seperti Visual Studio, IDEA, dan Eclipse semuanya melakukan ini juga. Kode, di sisi lain, memiliki pendekatan "bingkai dan penyangga", mirip dengan apa yang akan Anda temukan di Emacs (dan Vim, juga, saya percaya).

Tak pelak, di editor berbasis tab mana pun saya merasa berkewajiban untuk bekerja dengan hasil di bingkai editor saya yang dibombardir secara mengerikan dengan tab yang fobs foldernya sangat kecil sehingga tidak dapat dibaca. Selanjutnya, ketika saya menggunakan editor yang setara dengan Ctrl / ⌘-PI akhirnya melengkung ke bingkai lain sebagai artefak dari bingkai mana pun yang saya lihat ketika saya pertama kali menavigasi ke file. Untuk melihat file yang sama di bingkai lain, Anda harus melakukan operasi "tab terpisah" yang kikuk yang juga sering kali digabungkan dengan bingkai pemisahan di banyak editor ini. _Tabs secara erat memasangkan status buffer file dengan bingkai yang diberikan pada tampilan._

Jika Anda memaafkan daya tarik emosional, harap _please_ jangan mengubah VS Code menjadi editor tab lainnya.

Menurut saya, dari perspektif UX, daripada menerapkan tab secara membabi buta agar sesuai dengan perilaku Atom atau editor lain, akan bermanfaat untuk mengetahui _why_ orang menginginkan tab (selain hanya keakraban yang nyaman) dan melihat apakah solusi yang lebih inovatif untuk kebutuhan mereka mungkin. Saya tentu setuju rezim ruang kerja saat ini dapat terus berkembang: seperti yang disebutkan orang lain untuk membuka jendela terpisah dalam proyek yang sama (setara dengan "ripout" berbasis tab) untuk memanfaatkan tampilan multi-head yang lebih baik!

edit: sangat sedih bahwa saya melewatkan panggilan 19 hari yang lalu. Saya akan bergabung jika saya tahu tentang itu. Hanya ditemukan dari catatan rilis 1.1.0. :(

Tab adalah suatu keharusan bagi saya dan saran lain untuk misalnya tab angular 2.0 yang dikelompokkan untuk file terkait juga merupakan ide bagus. Jika fiturnya dapat dikonfigurasi maka mereka yang preferensinya berbeda akan senang juga. Kapan kita bisa mencoba !!! ???

@orospakr , Anda dapat mematikan tab di Sublime melalui opsi menu. FYI saja.

@tokopedia

akan menjadi pelajaran untuk mencari tahu mengapa orang menginginkan tab (selain hanya nyaman akrab) dan melihat apakah solusi yang lebih inovatif untuk kebutuhan mereka mungkin.

Ada banyak umpan balik tentang mengapa orang menginginkan tab selain keakraban, belum lagi bahwa jika sudah familiar dan orang merasa nyaman dengannya maka tidak masuk akal untuk menjadi kreatif dan berinovasi sesuatu yang sudah ada yang berhasil.

Mereka mencoba berinovasi dengan "file kerja" dan satu kelompok menyukainya, yang lain tidak menyukainya dan di sini kita hari ini meminta tab! Saya tidak berpikir bahwa Anda ingin sindrom yang sama terjadi lagi ...

Cara yang tepat untuk melakukannya adalah dengan mendapatkan pengalaman yang dicari orang terlebih dahulu, lalu memiliki fitur tambahan, inovasi, atau eksperimen selama pembuatan alfa dan / atau sebagai opsi.

Dalam kasus ini tab / "editor terbuka" atau besok sesuatu yang lain mereka menjadikannya opsional dan begitulah seharusnya orang-orang perlu memiliki kemampuan untuk ikut serta ke pengalaman atau menyisih darinya.

Saya tahu bahwa saya sedikit terlambat untuk permainan di sini, tetapi sehubungan dengan bagian ini:

Kami membahas tindakan untuk mempromosikan tab pratinjau ke tab terbuka penuh:

Mengedit konten di dalam tab
Mengklik dua kali file di explorer
Mengklik ganda tab pratinjau di grup tab

Saya ingin meminta agar "Menambahkan bookmark" dimasukkan dalam daftar di atas.
Saya merasa sangat frustasi untuk menambahkan bookmark ke file besar dan kemudian secara tidak sengaja mengklik file lain, menutup file yang berfungsi.

Sangat tidak mungkin bahwa saya telah menambahkan bookmark ke file yang ingin segera saya tutup.

memeriksa komentar sebanyak yang saya bisa, mencari kata kunci dan tidak menemukan ini disebutkan.

sejauh tab pergi, pertama, _terima kasih! _ ketidakhadiran mereka adalah satu-satunya hal yang saya tidak suka tentang VS Code.

Saya ingin sekali melihat navigasi antar tab dapat disesuaikan; sebagai contoh, saya suka cara iTerm beralih antar tab dengan menekan cmd + left , dan akan sangat senang melakukannya di editor saya juga.

terima kasih untuk editor yang hebat <3

Tab adalah suatu keharusan bagi saya ... Beralih kembali ke Sublim sampai Anda memiliki tab. PS Saya sangat kecewa dengan sikap Anda; Anda tampaknya tidak memahami UX, namun mengklaim ini dilakukan untuk meningkatkan UX. Apa persona Anda? Di mana wawancara pengguna Anda? Buktikan itu.

@asadighi apakah Anda membaca komentar sebelum memposting? Tim telah melakukan wawancara ekstensif dan melakukan lebih banyak untuk mendapatkan informasi yang benar. Mereka sangat responsif terhadap komunitas dan menghasilkan editor hebat (gratis). Selamat mencoba rilis Sublime selanjutnya.

Komentar Anda sebelumnya menunjukkan bias Anda. Keberatan saya adalah pada sikap yang mereka miliki sejak awal. Wawancara pengguna harus dilakukan SEBELUM orang mulai menyalahkan produk karena cacat tersebut. Cukup menarik, Anda dapat melihat keraguan untuk berinvestasi untuk memperbaiki kekurangan ini atas nama UX yang lebih baik. Masalah ini telah dibuka sejak November dan untuk sebagian besar waktu itu sebagian besar tanggapan sejalan dengan kami tahu lebih baik daripada Anda bagaimana Anda harus melakukan pekerjaan Anda.

@asadighi Itu semua ada di kepala Anda dan omong kosong Anda muncul di komentar Anda, hentikan.

@muellerkyle : +1: Anda harus membuat masalah terhadap ekstensi bookmark yang Anda gunakan.

Saya menantikan fitur ini

+1!

Setiap hari, saya beralih antara Eclipse, PhpStorm, Notepad ++ dan VSCode. Coba tebak, CTRL+W membuatku gila.

Saya terlambat ke pesta ini, tetapi apakah tab akan menjadi opsional? Saya dulu berpikir saya merindukan mereka tetapi sekarang tidak. Hanya ingin tahu apakah akan ada cara menyembunyikannya. Tidak ada kebencian terhadap tab dan orang yang ingin menggunakannya, anggap saja saya lebih suka toggle untuk ditampilkan / sembunyikan. Itu semua pertahankan kerja bagusnya. Saya suka vscode.

@jamesmenera ya, ini akan menjadi opsional tetapi begitu juga file kerja (editor terbuka).

Sebagai tambahan, maukah Anda membocorkan program apa yang Anda gunakan untuk membuat gambar mockup itu?

@ciel , @stevencl menulis bahwa mereka menggunakan PowerPoint untuk itu.

Secara pribadi, saya suka WireframeSketcher untuk melakukannya tetapi PowerPoint juga dapat berfungsi. :)

Seperti yang disebutkan @jamesmenera, saya sangat merindukan tab dan sidebar tetapi saya dapat melihat bahwa banyak orang menyukai pendekatan Working Files sehingga harus opsional.

@ kadza93 tab dan file kerja akan menjadi opsional ... Saya ingin tahu berapa kali saya akan menulisnya.

Sangat mudah untuk melakukan penelusuran dan mencari kata "opsional", Anda tidak perlu waktu lama untuk menemukannya daripada benar-benar menulis postingan tentangnya!

@eyalsk Aku heran kenapa nyala! Saya di sini untuk mengungkapkan kebutuhan saya dan sejauh yang saya bisa melihat kebutuhan banyak tab, jadi dengan mendukung apa yang dikatakan orang lain dan menyetujuinya, saya melakukan sesuatu yang salah? Ngomong-ngomong, terima kasih atas tip tentang fungsionalitas pencarian, saya harus menggunakannya lebih banyak pada utas panjang di mana saya ingin mengungkapkan pendapat saya dan jika seseorang sudah mengungkapkan pendapat yang mirip dengan saya, saya hanya akan melewatkannya.

Itu hanya 3 naik dari pos Anda ...

Mengikuti utas ini, bagi saya sepertinya sudah ada beberapa keputusan yang dibuat pada tab untuk rilis mendatang (tab bersifat opsional, tempat ikon akan ditampilkan, kombo kunci, dll.). Jika saya tidak salah, apakah ada daftar keputusan yang dapat ditunjuk orang?

@jtlowe tidak ada cara mudah untuk membuatnya jelas seperti komentar yang disematkan di GitHub. Orang membuat komentar baru dan mengubur hal-hal penting. GitHub juga melakukan pelipatan komentar ketika ada terlalu banyak komentar yang membuat pencarian di halaman lebih sulit.

Mungkin admin dapat memasang spanduk "STATUS SAAT INI: DALAM PENGEMBANGAN" di bagian atas halaman terbitan (di bawah badan terbitan OP)?

Ini harus menjadi fitur yang tepat di github --- sesuatu seperti yang disarankan teks alternatif di sini: https://xkcd.com/979/

@ kadza93 Aku tidak

Saya di sini untuk mengungkapkan kebutuhan saya dan sejauh yang saya bisa melihat kebutuhan banyak tab, jadi dengan mendukung apa yang dikatakan orang lain dan menyetujuinya, saya melakukan sesuatu yang salah?

Tidak, Anda tidak melakukan kesalahan apa pun tetapi Anda juga tidak menulis sesuatu yang berguna, fitur emotikon / reaksi ada khusus untuk alasan ini.

Ngomong-ngomong, terima kasih atas tip tentang fungsionalitas pencarian, saya harus menggunakannya lebih banyak pada utas panjang di mana saya ingin mengungkapkan pendapat saya dan jika seseorang sudah mengungkapkan pendapat yang mirip dengan saya, saya hanya akan melewatkannya.

Ya ... Anda masuk akal, maksud saya mengungkapkan pendapat tentang sesuatu yang telah dikonfirmasi! dan Anda bahkan tidak perlu mencarinya karena saya membalas orang yang sama dengan yang Anda jempol.

Secara umum, masuk akal untuk mencari kemungkinan kata-kata umum dalam posting yang panjang.

Benar-benar pengembang sebaiknya membuka masalah baru dengan FAQ dan detail yang diambil dari
poin paling umum di utas ini dan tutup masalah ini. Orang-orang
berlangganan masalah ini mendapatkan lusinan email setiap hari untuk
sama dengan komentar "suka" / "tidak suka".
Pada 18 Mei 2016 1:51 AM, "Kumar Harsh" [email protected] menulis:

Mungkin admin dapat memasang spanduk "STATUS SAAT INI: DALAM PENGEMBANGAN"
bagian atas halaman masalah (di bawah badan masalah OP)?

Ini harus menjadi fitur yang tepat di github --- sesuatu seperti teks alternatif
di sini menyarankan: https://xkcd.com/979/

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

@anyong ya saya sangat setuju! tidak ada yang perlu didiskusikan dan setelah tabs dan open editors ditayangkan, mereka harus membuat dua masalah terpisah untuk umpan balik tentang fitur ini.

@eyalsk kami masih bereksperimen dengan cara menangani pembaruan pada masalah yang dibuat oleh komunitas. Ada banyak cara untuk melakukan ini tetapi semuanya buruk tanpa fitur komentar yang disematkan di GitHub. Masalah terminal terintegrasi https://github.com/Microsoft/vscode/issues/143#issuecomment -213581854 sejauh ini baik-baik saja dengan pembaruan besar di tengah utas, saya rasa itu ada hubungannya dengan sedikit kebutuhan untuk diskusi jadi belum terkubur.

@Tyriar , Anda dapat mereferensikan postingan, jadi tidak bisakah Anda membuat postingan baru dan membuat referensi ke postingan lama dengan menutupnya? Saya pikir begitulah cara orang-orang yang bekerja di Roslyn melakukannya dan kemudian mereka memiliki posting yang merangkum semua fitur untuk rilis mendatang tetapi saya setuju dengan Anda, komentar yang disematkan bisa sangat berguna.

Kami telah berupaya menerapkan desain untuk tab dan grup editor dalam pencapaian ini dan akan terus melakukannya di pencapaian berikutnya

Terima kasih kepada semua orang yang berpartisipasi dalam studi UX beberapa hari terakhir ini. Kami mendapat beberapa umpan balik yang bagus dari Anda yang telah membantu kami meningkatkan pengalaman:

• Mendesain ulang ikon luapan
• Berikan pengaturan untuk memilih apakah file dari buka cepat disematkan atau dipratinjau
• Tambahkan perintah untuk mengubah file yang dipratinjau menjadi file yang disematkan

Maaf, jika saya melewatkannya, tapi bagaimana cara mengaktifkan tab? Apakah mereka tersedia dalam insider build terbaru, seperti yang saya miliki, tetapi tidak ada jejak tab di sana. Saya juga masih melihat 'file yang berfungsi' di explorer, meskipun tampaknya itu harus diganti dengan 'Editor Terbuka' seperti yang dinyatakan dalam # 6536.

@lllopo mereka belum tersedia. Tumpukan / editor terbuka digabungkan untuk v1.3.0 dan akan tersedia di Insiders minggu depan saat build harian tersedia.

+1

+1

👎

Apa yang terjadi di sini, mengapa Anda menolak memberi kami opsi untuk menggunakan tab? 😕
Begitu banyak orang menyukai tab termasuk saya, beri kami PERIOD pilihan sialan!

@aminroosta Serius ... kamu tidak bisa membaca? Apakah kamu buta?

Lucunya Anda bertanya apa yang terjadi di sini ... dan kemudian melanjutkan dan menganggap mereka benar-benar menolaknya atau dengan kata-kata Anda sendiri "menolak" padahal sebenarnya mereka mengkonfirmasi tab datang dan bekerja untuk menerapkannya!

Beberapa orang di dunia ini! luar biasa!

@tokopedia
Saya menghabiskan 25 menit membaca 20 sampai 30 komentar pertama.
Saya lelah dan meninggalkan komentar yang sekarang tampaknya menjadi kesalahan dari pihak saya.

Maaf soal itu.

Kami tidak dapat menyalahkan R&D Microsoft untuk mencoba berinovasi. Sistem tab memiliki kekurangan.

Desain UI seperti semua bentuk desain. 90% membuat apa yang ditunggu pengguna, 10% membuat hal-hal baru, mencoba membuat sistem baru yang revolusioner dan ramah pengguna.

semua sistem yang user friendly dilihat sebagai harus ada di editor teks baru hari ini telah bereksperimen dan kontroversial sebelumnya.

@aminroosta Saya akan memberi Anda tip, ketika Anda membaca posting yang panjang, baca posting asli dan kemudian untuk mendapatkan update terbaru menghabiskan waktu sekitar satu menit untuk menggulir dari bawah ke atas.

Itu saran yang bagus karena ini umpan yang SANGAT panjang.

Pada hari Minggu, 5 Juni 2016 pukul 10.42 Eyal Solnik [email protected]
menulis:

@aminroosta https://github.com/aminroosta Saya akan memberikan tip, kapan
Anda membaca posting yang panjang, membaca posting asli dan kemudian mendapatkan
pembaruan terkini menghabiskan waktu sekitar satu menit untuk menggulir dari bawah ke atas.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/vscode/issues/224#issuecomment -223826495,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
.

Secara pribadi saya suka pendekatan Ctrl + Tab. Dari pengalaman pribadi saya, tab dapat menjadi berantakan dengan cepat jika Anda memiliki 10+ tab yang dibuka secara bersamaan. Saya akan mengatakan hapus "file kerja" atau setidaknya biarkan sebagai opsi. Saya tidak menggunakannya dan itu menambah kebingungan bagi saya. Saya akan menggunakan Ctrl + Tab mulai dari sini terima kasih!

@adred Baik Working files (sekarang disebut Open editors ) dan Tabs akan menjadi opsional sejauh yang saya tahu.

@bpasero

Dapatkah Anda _please_ mengunci utas ini dan membuka utas baru dengan bagian penting utas ini disalin ke dalamnya? Masih ada komentar yang datang setiap hari dari orang-orang yang tidak bisa membaca semuanya (seharusnya memberi tahu Anda bahwa ini terlalu panjang), dan menanyakan pertanyaan yang sama berulang kali, dan begitu rilis tab mengenai publik, kami akan melakukannya. melihat lebih banyak spam di utas ini.

Saya ingin tetap up-to-date tentang kejadian yang berhubungan dengan tab, dan utas ini saat ini adalah tempat untuk melakukannya, tetapi sangat menjengkelkan untuk mendapatkan email berisi spam beberapa kali sehari untuk komentar yang sama berulang kali.

Maaf atas nada & terima kasih.

Ada begitu banyak +1 sehingga sedikit banyak.

Pada hari Senin, 6 Juni 2016 pukul 02.16 -0700, "anyong" [email protected] menulis:

@bpasero

Dapatkah Anda _please_ mengunci utas ini dan membuka utas baru dengan bagian penting utas ini disalin ke dalamnya? Masih ada komentar yang datang setiap hari dari orang-orang yang tidak bisa membaca semuanya (seharusnya memberi tahu Anda bahwa ini terlalu panjang), dan menanyakan pertanyaan yang sama berulang kali, dan begitu rilis tab mengenai publik, kami akan melakukannya. melihat lebih banyak spam di utas ini.

Saya ingin tetap up-to-date tentang kejadian yang berhubungan dengan tab, dan utas ini saat ini adalah tempat untuk melakukannya, tetapi sangat menjengkelkan untuk mendapatkan email berisi spam beberapa kali sehari untuk komentar yang sama berulang kali.

Maaf atas nada & terima kasih.

Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

Hanya mengomentari teks pembaruan @ https://code.visualstudio.com/updates#_workbench

Teksnya tidak jelas bagi saya dan saya benar-benar berpikir bahwa tumpukan yang diperbarui sudah ada di sini (dan tab itu akan muncul nanti). Setelah memperbarui, saya tidak melihat tumpukan yang diperbarui dan harus membaca ulang teks beberapa kali.

Bagi saya dikatakan bahwa Tab akan membutuhkan lebih banyak iterasi (jadi tidak ada tab dalam pembaruan _this_), tetapi pada bulan Mei Anda membuat kemajuan besar tentang cara mengelola tumpukan editor (jadi meskipun tidak ada tab, tumpukan _are_ diperbarui dalam pembaruan ini?) dan bahwa ada lebih banyak pekerjaan yang harus dilakukan untuk cabang rilis bulan Juni (untuk meningkatkan tumpukan lebih jauh?).

Jadi bagi siapa saja yang mungkin bingung seperti saya .. sepertinya tumpukan yang diperbarui sebenarnya tidak ada dalam pembaruan ini. Saya kira ini hanya pratinjau dari kedua tab dan tumpukan yang akan datang.

Saya setuju dengan @RyanEwen. Saya sangat menghargai perkembangan terbuka dan jumlah komunikasi, tetapi pengumuman ini sebagai bagian dari "Catatan Rilis" resmi benar-benar membingungkan.

Mungkin ini bisa dibagi menjadi catatan rilis yang sebenarnya, dan 'apa yang sedang kami kerjakan sekarang' atau semacamnya.

Menghubungkan masalah ini dalam Roadmap bukanlah ide yang baik karena jika Anda membacanya dari pertama kali Anda tidak akan mendapatkan gambaran yang jelas tentang status saat ini (lebih dari Milestone). Masih ada pekerjaan yang harus diselesaikan tetapi keadaan saat ini baik-baik saja: +1:

Ya, mereka harus meringkas masalah dan kemudian memiliki tautan ke ringkasan ini sehingga orang akan mengetahui rencana saat ini setelah dibahas.

Menghubungkan ke diskusi itu buruk karena mereka cenderung panjang dan orang tidak bisa mendapatkan ide tanpa membaca hampir semuanya tapi entahlah mungkin tidak mungkin bagi mereka untuk melakukannya sebaliknya.

Ketika saya mulai membaca catatan rilis untuk 1.2, hal pertama yang saya cari adalah _ Fitur Tab_. Saya menghargai bahwa mereka menempatkan status saat ini di sana. Tapi saya juga jadi bingung. Pada awalnya saya pikir itu mendarat, daripada yang saya sadari tidak, tetapi banyak kemajuan dibuat. Dalam hal ini, rasanya item tersebut harus berada di bagian bawah catatan rilis dengan tautan ke diskusi atau tonggak sejarah (keduanya membuktikan kemajuan dalam fitur) bersama dengan catatan kecil yang mengatakan sesuatu seperti _ "Lihat kemajuan menuju implementasi Tab "_.

Terlepas dari hal kecil ini. Kerja bagus saat rilis. VS Code adalah produk hebat dengan siklus pengembangan luar biasa.

VSCode baru saja diperbarui menjadi 1.3.0-insider. File terbaru sepertinya hilang. Apakah ada cara untuk melakukannya sekarang?

Terima kasih atas umpan balik pada catatan rilis dan maaf atas kebingungannya. Saya telah membuat modifikasi pada dokumen untuk memperjelas bahwa pekerjaan tidak dalam Stabil, tetapi Anda dapat melihat pratinjau tab bekerja di Insiders Release .

Memiliki bagian menjelang akhir di mana kita berbicara tentang pekerjaan yang diselesaikan tetapi tidak dalam versi stabil adalah ide yang bagus dan kita akan melakukannya bulan depan jika kita memiliki lebih banyak pekerjaan yang sesuai dengan kelompok itu.

@JoshClose tolong buka masalah baru untuk ini karena saya akan segera mengunci masalah ini demi masalah individu alih-alih utas tunggal ini. Terima kasih.

Pertama, izinkan saya berterima kasih sekali lagi kepada semua orang atas pikiran, suka, dan tidak suka Anda tentang tab. Umpan balik yang kami lihat di utas ini (baik positif maupun negatif) benar-benar menunjukkan betapa bersemangatnya orang-orang tentang masa depan VS Code.

Saya pikir semua orang dapat setuju bahwa kami telah kehabisan utilitas masalah ini dan sebagai hasilnya saya akan mengunci percakapan. Kami akan membiarkan masalah ini terbuka hingga kami mengirimkan dengan opsi untuk tab / tanpa tab, yang kami rencanakan untuk dilakukan pada akhir iterasi Juni 2016 .

Sementara tim VS Code _may_ memposting pembaruan dalam masalah ini, Anda harus berharap bahwa kami akan membuat masalah baru untuk desain atau diskusi tab tambahan. Kami akan menandai masalah dengan label tabs agar lebih mudah untuk melakukan kueri. Anda juga dapat membuka masalah khusus tab baru dan kami menantikan umpan balik Anda tentang masalah tertentu, karena bersama-sama kami membangun pengalaman terbaik.

Sekali lagi terima kasih, sekarang buka dan instal Insiders Release !

https://github.com/Microsoft/vscode/issues/6605 mendokumentasikan semua pengenal perintah yang ditambahkan atau diubah untuk digunakan dengan keybindings. Karena model tumpukan adalah perubahan besar pada UI VS Code, kami memutuskan untuk mengunjungi kembali semua perintah yang berhubungan dengan editor atau grup.

Kami dengan senang hati mengumumkan bahwa Anda sekarang dapat mengaktifkan tab di nightly insider builds kami (http://code.visualstudio.com/Download#insiders). Pengaturan terkait adalah workbench.editor.showTabs . Silakan merujuk ke catatan rilis kami untuk detail lebih lanjut tentang konsep tumpukan editor, editor pratinjau, dan tab.

Masih ada beberapa pekerjaan yang direncanakan di bidang ini hingga akhir bulan (dan mungkin setelahnya) jadi kami dengan senang hati mengumpulkan umpan balik dari orang dalam. Jangan ragu untuk membuka masalah saat Anda menemukannya saat menggunakan tab.

Terima kasih!

Seperti yang telah disebutkan @bpasero, Anda sekarang dapat mengaktifkan tab di insider nightly build kami.

Jika Anda telah mencobanya dan dapat meluangkan waktu 30 menit untuk membagikan umpan balik Anda, silakan mendaftar untuk mengobrol di sini: https://calendly.com/stevencl/vs-code-tabs/

Sayangnya saya hanya dapat menawarkan slot waktu pada siang hari waktu saya (saya di Edinburgh, Skotlandia) Senin dan Selasa minggu depan.

tl; dr; aktifkan tab di dalam VS Code yang dibangun dengan workbench.editor.showTabs: true

Kami menutup pencapaian bulan Juni selama minggu ini dengan pengujian permainan akhir seperti biasa. Tab ada dalam paket pengujian (https://github.com/Microsoft/vscode/issues/7854) dan akan mendapat perlindungan selama seminggu. Kami masih berharap untuk melakukan perbaikan pada tab untuk bulan Juni dan kemungkinan perbaikan berdasarkan pos umpan balik bulan Juni. Sebagian besar pekerjaan telah selesai, jadi saya akan menutup masalah ini.

Dari deskripsi item kerja ini, @TurkeyMan meminta untuk memiliki tab dan cara untuk memindahkan tab keluar dari meja kerja untuk dibuka di dalam jendela baru. Saya telah mengekstrak yang terakhir ke https://github.com/Microsoft/vscode/issues/8171 karena tidak terkait dengan pekerjaan tab yang kami lakukan.

Silakan lanjutkan untuk mengajukan masalah pada tab seperti yang Anda lihat saat mencobanya. Terima kasih telah membantu dalam menguji insiders build!