Vscode: 開いているファイルの適切なタブ

+1

カスタム拡張機能を使用してタブを追加することは可能ですか？ 私はすぐにドキュメントを調べましたが、現在のAPIでそのタイプの機能を追加することは不可能であるように見えました

カスタム拡張機能を使用してタブを追加することは可能ですか？

いいえ、これは現在、拡張機能からは不可能です（http://code.visualstudio.com/docs/extensions/our-approachも参照してください）

+1

：+1：

：+1：

+1

タブは、崇高なものなどの他のテキストエディターは言うまでもなく、VisualStudioでも機能するデフォルトの方法です。

タブがない場合は、 Ctrl+Tabを使用して、開いたファイルの履歴をナビゲートしてみましたか？

はい。 ただし、ファイルを閉じた後でも、ファイルはCtrl+tabコンテキストのままです。 経験はSublime / Atomの経験と同じではありません。

@snehilmodaniそうですね、エクスプローラーの作業ファイルセクションにあるものだけがリストに表示されていると役に立ちますか？ 少なくとも作業ファイルリストを操作できますか？

それは素晴らしいことです！

補足：タブとしてファイル名を使用したレイアウトは、よりユーザーフレンドリーではありません。 それぞれが独自の開いたファイルのセットを持つタブの1つ以上のセクションを持つように拡張できます。 （ここでも、Sublime Textを参照として使用しています）

タブがあるかどうかは、セクションがあるかどうかとは無関係だと思います。 現在、VS Codeで最大3つのエディターを並べて開くことができるため、セクションがあります。 タブがないため、これらのセクションに複数のファイルを追加したり、空のセクションを作成したりすることはできません（これは別のUXディスカッションです）。

Ctrl + Tabに戻る：私たちチームは、最初から常にタブなしで作業してきました。実際、作業ファイルビューも長い間表示されておらず、実際、チーム内で使用している人はそれほど多くありません。 どのファイルを開いたり閉じたりしても、それほど重要ではないことがわかりました。 私たちの心は、最後に編集したファイルの時系列順に考えています。 したがって、Ctrl + Tabを押すと、通常、最後にいたファイルが表示されます。 私はそこにあるファイルの数を実際には見ていません。私は最大で上位5つのファイルにのみ興味があります。 このモデルの利点は、レイアウトとタブをまったく管理する必要がないことです。 ファイル間を移動している間、管理は自然に行われます。

作業ファイル用のファイルピッカーを追加することはできますが、人々が今日のようにCtrl + Tabを使用することを確信でき、問題が何であるかを学ぶことができるかどうかを聞くのは興味深いことです。

@bpasero ctrl+tabを試してみますが、前のファイルに移動するために使用できることに気付きました。これは、私が望んでいたもので、今まで調べていませんでした。 いいですね。

ちなみに、タブの代わりにctrl+tabを利用できるかどうかに関係なく、新しいVSコードユーザーはおそらくタブがないために延期されるので、市場シェアの理由だけで私はタブオプションを使用することをお勧めします。 他のすべてのエディターは（良くも悪くも）タブを使用し、タブがないと、VSコードにかなり不必要な参入障壁が生じます。 素晴らしいtypescriptサポートがあるため、タブのサポートに関係なくVSコードを使用していますが、それがなかった場合、最初の数回はそれを維持したかどうかわかりません。

はい、 Ctrl+Tabは、作業中のファイルの履歴をさかのぼることです。 Ctrlキーを押したまま、 Tab繰り返し押すと、1つのファイルを超えて戻ることができます。

Ctrl+tabは素晴らしいもので、私は完全にそれが好きです。 それはアトムでさえ見逃しているものです。

各セクションのタブと複数のファイルについて：Sublime Textでも、3つのエディターを並べて開くことができますが、セクションのタブ付きレイアウトを提供します。 雑然としていて、エディターのレイアウトを管理するのはかなりの作業になると思いますが、とにかく人々はそれに慣れています。
私はあなたが私たちの編集者との雑然としたレイアウトベースの相互作用を取り除くように私たちを説得しようとしている社会実験の一部になりたいです。

雑然としていて、エディターのレイアウトを管理するのはかなりの作業になると思いますが、とにかく人々はそれに慣れています。

以前は何かに慣れていて、それからもっと良いものに慣れたUXの例をもっと見つけることができると確信しています:)。 携帯電話のキーボードとスマートフォンのタッチ操作を考えてみてください。

私はあなたが私たちの編集者との雑然としたレイアウトベースの相互作用を取り除くように私たちを説得しようとしている社会実験の一部になりたいです。

はい、2016年のようなことをする必要があると思います。 @ stevencl fyi

各セクションのタブと複数のファイルについて：Sublime Textでも、3つのエディターを並べて開くことができますが、セクションのタブ付きレイアウトを提供します。

空のセクションを作成できるように、より安定したセクションを許可するオプションに同意しますが、このセクションのタブを表示できるのは、そこにあるファイルを視覚的に表したものにすぎず、ほとんどの場合、大きくなりすぎて最終的には表示されません。何かを見て。 これらを積極的に管理して閉じない限り、タブは開いているファイルのリストを表示するための良い方法ではないと思います。

これらを積極的に管理して閉じない限り、タブは開いているファイルのリストを表示するための良い方法ではないと思います。

実際に管理している人もいれば、右側に近いタブがある人もいます。

フィードバックをありがとうございました。

UXバックログ（＃1133）に問題があり、ワークスペース管理（開いているファイル、履歴などの管理）を改善します。これはその一部です。 私たちの意図は、開いているファイルと最近のファイルのリストの管理が簡単で簡単であり、ユーザーがVS Code UIに過度の注意を払うことなく、コードに集中できるようにエクスペリエンスを向上させることです。

私たちの仮説は、現在のシステムにはいくつかのラフエッジがあり（たとえば、エディターを閉じると実際にはエディターが閉じますが、代わりに同じエディターで以前に開いていたファイルを表示する必要があると思います）、これらのラフエッジを平滑化するとはるかに優れたエクスペリエンスの作成に役立ちます。

私たちは非常に定期的に製品のUX調査を行っています。 実際、それが私たちが製品の多くのUXを設計する方法です。 私たちは実際のフィードバックに基づいて設計を繰り返し、人々が製品で何をし、何をしたいのかを十分に理解して設計に情報を提供するようにします。

将来これらの研究に参加したい場合は（早くても1月中旬まで再び実行されることはありません）、私に知らせてください。あなたの名前をリストに追加します。

将来これらの研究に参加したい場合は（早くても1月中旬まで再び実行されることはありません）、私に知らせてください。あなたの名前をリストに追加します。

サインアップしてください！

これらを積極的に管理して閉じない限り、タブは開いているファイルのリストを表示するための良い方法ではないと思います。

タブ管理は、私の開発の無意識で抑制のない部分です。 VS-properには、邪魔にならない小さな目立たないタブがあります（vscodeには、タブがある場所を占めるファイル名がすでにあります）。 タブスパムの暴走が問題であることに同意します。これを革新して対処するのは良いことかもしれませんが、タブを使用するよりも優先度は低いと思います。 VSCodeは最小動作状態に到達する必要があります。 今はとても近づいていますが、まだ生産的に仕事ができていません。 確立されたパターンから始めると、おそらく私たちはより早く働くようになるでしょう。

誰もがWeb開発者であるとは限らないことを覚えておく価値があります。パターンとワークフローは、アプリケーションの言語とスタイルによってわずかに異なる傾向があることがわかりました。 ネイティブ開発者として、関連するファイルのセットを表示するのが一般的です。 cpp + h 、おそらくinl 、通常、1つのファイルだけを単独で操作することはありません。 コードの横に逆アセンブリビューが表示されることがよくあります。 私のエディター環境は2つのモニターにまたがっており、常に4つのファイルが表示されますが、それよりも制限の厳しい環境で作業するのに苦労します。
また、タブをつかんで小さなフローティングウィンドウにリッピングすることもできません。これは、一般的に参照ポイントとして使用される「常に上」に設定することが多く、コピーを頻繁に行うものです。から/へのペース。

たとえば、今、私はいくつかのレガシーコードをリファクタリングして単純化しようとしています。 私の現在のワーキングセットのファイルは... component.cpp、component.h、component.inl、componentimpl.cpp、componentimpl.h、icomponent.hです。 これは6つのファイルです。 そして、私は周辺の他のいくつかのファイルの時折の微調整から逃れることはできません。 そのスタイルのプロジェクト（2つのファイル間をめくる）で作業しているときは、ctrl-tabを自由に使用しますが、このコンテキスト/コードベースでは、タブなしでは作業できません。

レガシーコードのリファクタリングと保守は、新しいコードの作成とは非常に異なるワークフローを持っています（皆さんが行っていると思いますが、主にUXデザインのガイドラインとして使用しています）。

ここでの私のポイントは; すべてを再発明したいという現代の欲求があり、近年、UXデザインに大きな進歩が見られました。 vscodeはすでにこれらのいくつかを提示していますが、人々が何十年も働いてきた方法を変えることを決定するときは注意して適切な判断を下してください。 多くの確立されたデザインは、古くてよりトレンディになるために更新する必要があるためではなく、優れていて効率的であるために確立されています:)

これらのフォーカススタディに参加する機会をいただければ幸いです。

ここでの私のポイントは; すべてを再発明したいという現代の欲求があり、近年、UXデザインに大きな進歩が見られました。 vscodeはすでにこれらのいくつかを提示していますが、人々が何十年も働いてきた方法を変えることを決定するときは注意して適切な判断を下してください。

それは私の場合です。 実際、タブなしでは作業できません。 私は何年もの間タブシステムで働いています、そしてそれらなしで、私は本当に失われます。 これが、私が実際にコードを使用していない理由の1つです。

多くの確立されたデザインは、古くてよりトレンディになるために更新する必要があるためではなく、優れていて効率的であるために確立されています:)

：+1：

これまでのところ、どこかに「作業ファイル」のリストだけがあるのに比べて、タブの正当な理由はまだ聞いていません。 ファイルを取得して新しいウィンドウにドラッグできることは、タブシステムの利点ではないことは明らかです。これは、タブなしで使用できる機能です。

人々は本当にタブでファイルを開き、それらを移動し、最終的にそれらを閉じたいのですか？ これはあなたがそれに慣れているからですか、それとも実際にそうすることに価値がありますか？ 値は、後で何か新しいことを開始するために却下するアクティブな作業ファイルセットを設定できますか？ 別の表現方法では達成できないタブを持つことの何がそんなに良いのだろうか。 そして、私は誰もがタブに慣れているという議論を受け入れていません:)。 多くの人がファイルの保存に慣れていますが、それでも自動保存機能を備えたエディターがあり、人々はそれを気に入っているようです。

デフォルトではない場合でも、ユーザーにいくつかのオプションを使用してタブ機能をアクティブにする選択肢を与えることは、私にとってほぼ同じくらい良いことです。

たとえば、ユーザーが「作業ファイル」セクションを一番上に移動/ドラッグできるようにするのはどうでしょうか（たとえば、タブに変換する）。 繰り返しになりますが、ユーザーは自分の働き方を選択することができ、それは素晴らしいことだと思います。

私にとって、私が見逃しているのは、タブの動作ほどタブの外観ではありません。 （たとえば、Sublime TextをVS Codeのように見せることができ、代わりにタブバーを非表示にして、開いているファイルをサイドバーに表示できます...ただし、タブとまったく同じように動作します。）

VS Codeで最初に行うことは、ファイルを閉じるとアクティブなエディターのキーボードショートカットを閉じることです。これにより、ctrl + Wを押すと、作業ファイルのままにしてctrl + tabを乱雑にするのではなく、実際にファイルを閉じます。

しかし、それでも、ファイルを閉じるたびに空白の画面が表示され、まだ開いている最新の作業ファイルを表示するためだけにCtrl + Tabキーを押す必要があります（最後のファイルの場合は、次のようにする必要があるようです）。 ctrl + tabの後にEnterキーを押します。それが何であるかはわかりません）。 他のエディターでは、現在のファイルを閉じるとすぐに、最新または隣接する開いているファイル（タブ）のいずれかが表示されます。

さらに、作業ファイル間のctrl + tabは、通常は表示または配置された順序で動作するタブとは対照的に、最新の順序で機能しているように見えます。 （一部のエディターが両方をサポートしているのを見てきました。）

私は分割ウィンドウを使用しないので、これらの動作の違いのいずれかがそれと関係がある場合、それは私には失われます。 その角度から理解すればもっとよく理解できるかもしれませんが、それでも分割なしが最も一般的なユースケースではないでしょうか。

とにかく、VS Codeから離れて他のエディターに戻るのを妨げるのは、小さいながらも頻繁に発生するこのような摩擦です。 はい、VSCodeの動作は私が慣れているものとは異なると言えます。 しかし、私が_works_に慣れていて、VS Codeの動作が異なると摩擦が発生し、すぐに別のエディターを使用して対処する必要がなくなる場合、それは一種の大きな問題です。

はい、タブを表示せずにエディター領域がタブと同じように動作するモデルを見ることができます。 来年はこれを探求したいと思います。

ところで、エディタを閉じると、作業ファイルから次のエディタを開く拡張機能があります。 @kfranqueiroが示唆するように、それをキーバインディングの変更と組み合わせると、かなり近い私見になります。

リンクは次のとおりです： https ：

これまでのところ、どこかに「作業ファイル」のリストだけがあるのに比べて、タブの正当な理由はまだ聞いていません。 ファイルを取得して新しいウィンドウにドラッグできることは、タブシステムの利点ではないことは明らかです。これは、タブなしで使用できる機能です。

確かに、別の方法でそれを行うことは可能かもしれません...しかし、なぜですか？ 提供する重要な改善または革新がない限り。

人々は本当にタブでファイルを開き、それらを移動し、最終的にそれらを閉じたいのですか？

はい

これはあなたがそれに慣れているからですか、それとも実際にそうすることに価値がありますか？

部分的には習慣ですが、まだ誰もそれほど優れたものを提示していないためです。 人々が数十年前の習慣と戦い、再訓練することを主張するのであれば、イノベーションは大きな利点をもたらすはずです。

値は、後で何か新しいことを開始するために却下するアクティブな作業ファイルセットを設定できますか？

この文を正確に理解できるかどうかはよくわかりません。 複数の「作業ファイル」セットの観点から作業する代替案を説明しようとしていますか？ 想像するのは難しい。 それが普遍的に役立つかどうかはわかりません。 レガシー、メンテナンス、およびリファクタリングのタスクの場合、この方法で作業することは深刻な不利益になると思います。通常、ワーキングセットは事前にわからないため、作業中に出現します。 従来のモデルは、これらのワークフローですでに正常に機能しています。

別の表現方法では達成できないタブを持つことの何がそんなに良いのだろうか。

別の観点から; スペースの利用を検討してください。 コードウィンドウの上部にはすでにタブがあり、ファイル名があり、名前の周りにタブの長方形がありません（タブのように動作します。中クリックすると閉じます！）。 コードウィンドウの上のファイル名の右側には、現在空の無駄なスペースがあります（タブがあるべき場所）。
ワークスペースの左上には、「作業ファイル」リストがあります。 これは、存在する必要がないため、二重に無駄になっているスペースです。スペースは、タブが通常あるギャップに移動して、その無駄なスペースを埋めることができます。

また、スペースの使用率や習慣的な傾向よりも実際的な違いがあります。 バインドされているエディターウィンドウにタブを関連付けるのが好きです。 私は通常、少なくとも2つ、3つ、多くの場合4つのコードウィンドウを開いており（vs-proper）、それぞれに2つのタブが関連付けられています。 おそらく、一方のウィンドウにはwidget.cpp/.hがあり、もう一方のウィンドウにはgizmo.cpp/.h/.inlます。 これらのタブは、それらが接続されているコードウィンドウに論理的に関連付けられており、私はそれが楽しいと思います。

そして、私は誰もがタブに慣れているという議論を受け入れていません:)。 多くの人がファイルの保存に慣れていますが、それでも自動保存機能を備えたエディターがあり、人々はそれを気に入っているようです。

まあ、それを受け入れるかどうかにかかわらず、人々はそれが合理的で強力な議論であると感じています。 しかし、あなたがかなり良いことを考えているなら、私は私の判断を保留します。 どうしても、タブを有意義に改善できると思うなら、それを試してみてください。しかし、「トレンディな」革新だけのために頑固にそれを無理やり押し込まないでください;）..現状維持を排除するには、実質的に優れている必要があります。

現在の「作業ファイル」リストは間違いなく優れているとは言えません。 これは基本的にタブであり、垂直に配置されていますが、タブがバインドされているエディターウィンドウから切り離され、通常のタブの場所が空であるのにリストが無駄なスペースにあるという欠点があります。
また、「作業ファイル」リストの高さが動的であることが気に入らないため、プロジェクトツリーが垂直方向に移動します。「作業ファイル」の高さが固定され、垂直スクロールバーがあれば、さらに少なくしたいと思います。代わりに。

それは通常のタブよりも優れているわけではないので、適応する説得力のある理由はありません...私の意見では:)

+1 @TurkeyMan

VS Codeチームでは、最初（4年）からタブやファイルを使用せずに作業してきましたが、何も欠けていません。 したがって、個人的には、作業ファイルセクションが無駄なスペースであり、そのセクションを折りたたんでおくことに同意します。 ただし、自動保存を有効にして作業するため、通常はダーティファイルを気にしません。 作業ファイルは、主にダーティで無題のファイルを表示する場所を提供するために導入されました。 後で、別のUIの方法で、同様の表現であるため、従来のタブが欠落している人々を支援するのにも便利な場所であると判断しました。

ファイル情報とアクションを表示するために、エディターの上にスペースを予約します。 このスペースはタブに必要なスペースと同じであると主張する人もいるかもしれません。 しかし、タブに対する私の主張は、通常、水平方向のスペースでは作業ファイルのリストを表示するのに十分ではないということです。これは、すぐに次のようになるためです。

これは私たちが防ごうとしている悪夢です。必要なファイルを見つけるには、タブのリストを左右にスクロールする必要があります。 タブは、水平方向に表示できるよりも多くのタブを開いていない場合にのみ正常に機能します。 タブが小さくなり、ファイル名が非表示になったら、他のタブを閉じて、何が起こっているかを確認する必要があります。

さて、明らかに作業ファイルには、別の次元で同様の問題があります。 そのため、チームの私たちは通常、すべてにCtrl+Tabを使用し、何が開かれているかを気にしません。

要約すると、作業ファイルはタブを置き換えるための私たちの答えではなく、作業ファイルとCtrl+Tabの組み合わせです。 そして、私たちのチームは、 Ctrl+Tabだけを使用し、他には何も使用しないことにほぼ100％取り組んでいます。

あなたの画像は問題を不必要に誇張しているように見えます。 非現実的に狭いウィンドウ、斜めのタブエッジ、タブ内のテキストが多すぎる、右側のドット;）
vs-properはタブを美しく釘付けし、小さな目立たないタブで転がさない理由はありません。

該当する場合、私は非常に寛大なCtrl-Tabユーザーですが、アクティブに編集しているファイルが2つか3つ以下でない限り、Ctrl-Tabを使用することはできません。
この問題に関するあなたの意見はあなたの特定のプロジェクトにかなり偏っている可能性があり、それは言語の偏見を含むかもしれないと私は疑っています。 C / C ++では、 .hが存在することを受け入れると、通常の作業ファイル数は2倍または3倍になります。私の場合、多くの場合、 .cppごとに.inl補完されます。 Ctrl-Tabはこのシナリオではあまり効果的ではなく、代わりにCtrl-〜を使用する傾向があります（cpp / hを切り替えます。これも機能リクエストを投稿しました）。タブ管理と組み合わせて使用​​します。
または、Javaについて考えてみましょう。ここでは、どんなに小さくても、すべてのクラスが独自のファイルに存在する必要があります。

私の現在の日常では、数十のファイルのワーキングセットを持っていることがよくありますが、このように作業しているときはCtrl-Tabは役に立ちません。 最も実用的なワークフローは、2〜4個のエディターウィンドウと、ウィンドウごとに2つのタブです。 私はそれが好きなので、このレイアウトを選びませんでした。 これは、この特定のジョブにとって最も効率的なワークスペースレイアウトであるため、単に出現しただけです。

+ 1
私は通常、エディターを分割してタブを閉じる方が、10個以上の作業ファイルを使用するよりも少し直感的です。

また、私は通常、ファイルのサブセットのみに取り組んでおり、それらを手元に置いておきたいと思っています。 5/5は、個人的には10のリストよりも管理が簡単です。 私も継続的に積極的に移動しています。 タブは、開いているものが多すぎることを視覚的に示すという点でも役立ちます。@ bpaseroで示される「タブ地獄」です。

私は、タブが必ずしもウィンドウ管理の聖杯ではないことを認めます。 ただし、複数のファイルセットを処理する言語またはプロジェクトの場合、タブの管理はそれほど簡単ではありません。

簡単な例は、タブ付きの.cppと '.h'で、どちらもウィンドウの上部に焦点を合わせた2回のクリックですが、作業ファイルの場合は3〜4回のクリックで、作業ファイルを選択する必要があります。問題のエディタを選択してから、編集する新しいファイルを選択します。

タブとカスタムタブを使用すると、いくつかの興味深い拡張機能を簡単に追加することもできます。 例としては、コンソールまたはプロットタブがあります。 これらは、ファイルセレクタセクションに特別なエントリを必要とするか、現在のシステムを閉じるときに破棄する必要があります。 私は非常に定期的にプロットに戻ってくるので、ウィンドウを閉じると再プロットする必要があります。 または、コンソールが閉じられ、内部のデータが失われます。

ただし、適切な代替手段が利用できる場合は、喜んでテストします。 現在の画面の水平方向の領域は、現在のウィンドウ管理設計では利用されていない垂直方向の領域よりも大きいと感じています。 タブが各ウィンドウの現在の名前よりも垂直方向に大きい場合は嫌いですが。

タブの実装になぜこれほど多くの反発があるのか​​興味があります。 技術的には難しくはなく、すでに機能するファイルが実装されています。 なぜ両方ではなく、ユーザーに決定させるのですか？

これは、スペース対タブ、2.0のように聞こえます

タブの実装になぜこれほど多くの反発があるのか​​興味があります。 技術的には難しくはなく、すでに機能するファイルが実装されています。 なぜ両方ではなく、ユーザーに決定させるのですか？

これは、スペース対タブ、2.0のように聞こえます

完全に同意します。この機能をオプションとしてプッシュし（アンチタブの人々を満足させる場合はデフォルトでオフにします）、それが理にかなっているかどうかを際限なく理論化するよりも、統計/フィードバックを通じて使用状況を追跡する方がおそらくはるかに簡単です。

実際に何かをして謝罪するのではなく、これについて延々と理論を立てているように思えます。 ただし、バックログにはこれに対処するための項目があります（上記参照-＃1133）。 ローカリゼーションとアクセシビリティに懸命に取り組んでいるため、最近、これにかなりの時間を費やすことができませんでした。

上で述べたように、ファイルを管理するための現在のエクスペリエンスの問題を認識しており、エクスペリエンスを向上させるためにいくつかの変更を加えたいと考えています。

VS Codeの目標の1つは、UIとUXに変更を加えても、ユーザーがコードに集中できる軽量で強力なエディターであり続けることを保証することです。 これを実現する方法の1つは、製品に追加する新しいUIに細心の注意を払うことです。

タブの追加に関する私たちの懸念は、ユーザーがコードではなくUIに集中する必要があるという別の一連の問題を引き起こすことです。 たとえば、Visual Studioでの経験から、多くのユーザーは、不要になったファイルを含む多くのタブを開いてしまい、ワークスペースが乱雑になることがよくあります。 これにより、ユーザーがファイルやその他のコードアセットを探しているときにいくつかの問題が発生します。 これらの問題を解決するには、すべてのタブを閉じたり、このタブを除くすべてのタブを閉じたり、タブオーバーフローコントロールなどを実行できるUIがさらに必要です。この状況を回避し、作業中の設計がこれを実現するのに役立つことを願っています。

これはイデオロギー的な議論ではありません-私たちは本当に、軽量で強力な体験を提供すると信じている最小限の美学を維持しようとしています。 私たちは、製品に新しいUIとUXを導入することに非常に注意を払っています。

これに関する数回の設計と調査の後、タブを導入することになる可能性は十分にあります。 ただし、これは、ユーザーが操作するファイルとアセットを管理する方法を改善するための最良の方法であり、UIが乱雑になることはないという知識がある場合にのみそうします。

これが私たちの見解を説明するのに役立つことを願っています。 そして、私たちがへそを見つめているように見せて、これについて何もしていないことをもう一度お詫びします。

@stevenclに感謝します。少なくともレーダーに乗っており、ブレインストーミングが行われているのは良いことです。

タブの追加に関する私たちの懸念は、ユーザーがコードではなくUIに集中する必要があるという別の一連の問題を引き起こすことです。

しかし、今はコードではなくUIに焦点を当てる必要があると感じているので、この議論は両方の道を切り開きます。 :)

多くのユーザーは、多くの場合、不要になったファイルを含む多くのタブを開くことになります。

これを言うのは興味深いことです。なぜなら、ファイルを処理するポイントの一部は、一度により多くのファイルを開いたままにしておくことを奨励するという印象を受けたからです。 ここで説明することは、少なくともデフォルトのキーバインドでは、作業ファイルでも発生する傾向があります（そのため、アクティブなエディターを閉じて作業ファイルを完全に閉じるためにキーバインドを切り替えて

結局のところ、VSがタブの_動作_をオプションで複製することに成功した場合（＃1133の少なくとも1つが関連しているようです）、代わりにそれを横に保ちながら、それは十分なスタートかもしれません。 Ctrl +タブの順序がMRUであるか、表示の順序であるかは別のことです（Sublimeでは、異なるバインド可能なコマンドを介して両方を使用できます）。

@stevencl 、ご回答ありがとう

[...]ファイルを管理するための現在のエクスペリエンスの問題を認識しており、エクスペリエンスを向上させるためにいくつかの変更を加えたいと考えています。

私は確かにVSCodeの非常に明るい未来のように見えるものを楽しみにしています。 MicrosoftがVisualStudioのような強力なIDEをWindows以外の世界にもたらし、Electronを使用したアプリ開発の新しいパラダイムを採用していると聞いて興奮しました。 これまでのあなたの仕事に対する称賛！

VS Codeの目標の1つは、UIとUXに変更を加えても、ユーザーがコードに集中できる軽量で強力なエディターであり続けることを保証することです。

インターフェースを弱くしたり、遅くしたり、気を散らしたりするタブについて、説得力のある議論をする人はいないと思います。 実際、タブには、プロジェクトツリービューの上にある垂直方向のスペースよりもはるかに多くの水平方向のスペースがあります。 作業ファイルをそこに置いておくと、ウィンドウの左側が必要以上に雑然として見えます。

タブの追加に関する私たちの懸念は、ユーザーがコードではなくUIに集中する必要があるという別の一連の問題を引き起こすことです。

コードに焦点を当てることがすべてである場合、TextEditまたはメモ帳以外のものを使用する理由はありますか？ すべての目的と目的で機能がほとんどのエディターで同じであると規定すると、その機能に到達するために使用されるUI / Xとその品質は、製品が他とは一線を画すところです。

たとえば、Visual Studioでの経験から、多くのユーザーは、不要になったファイルを含む多くのタブを開いてしまい、ワークスペースが乱雑になることがよくあります。 これにより、ユーザーがファイルやその他のコードアセットを探しているときにいくつかの問題が発生します。

これは、タブや作業ファイルリストの賛否両論ではないと私が考える議論です。 複数のファイルを操作する場合は、コードアセットを探すために常に焦点を絞る必要があります。

それでも、作業ファイルリストでは問題は解決しません。 作業ファイルが多すぎると、リストがスクロールし、リストを展開できません。 したがって、最終的にタブをスクロールする代わりに、作業ファイルリストをすばやく下にスクロールすることになります。

[...]私たちは、軽量でパワフルな体験を提供すると信じている最小限の美学を維持しようと真剣に取り組んでいます。 私たちは、製品に新しいUIとUXを導入することに非常に注意を払っています。

私はこのスタンスをある程度評価し、支持することができます。 コミュニティが声を上げたら、ユーザーの採用について話し始める必要があります。 3月のロードマップで、VS Codeの折りたたみの欠如を、ユーザー採用の懸念事項として位置付けたのはそのためではありませんか？ いくつかのことは、彼らがそうであるように、そして正当な理由があります。 WindowsのスタートメニューとOSXのドックが思い浮かびます。

[...]おへそを見つめているように見せて、これについて何もしていないことを改めてお詫びします。

それは間違いなく私の見解ではないので、心配する必要はありません。 すでに述べた理由により、これについての健全な会話は、VSCodeのUI / Xというより大きな目的を強化することしかできません。

また、チャイムを鳴らして、「へそ凝視」はまったく起きていないと思います。 この問題のタイミングは部分的に誤りです。11月19日は、12月、場合によっては1月のどこかにそれを置く時間がありません。 また、再び開始されたこの会話は、ユーザーが望んでいるため、タブをランダムに実装するよりも重要です。

作業ファイルのインターフェイスは理想的ではなく、垂直方向のスペースよりも水平方向のスペースが多いという点で、ianwesterfieldに同意する必要があります。 大量のファイルリストと切り替えられる多くのファイルは、作業ファイルの管理に関するvscodeの現在の弱点です。
16の異なるファイルをホッピングし始めて、それらが属する分割エディターを管理できることは、作業ファイルを打ち負かすのが難しいことです。とはいえ、作業ファイルリストを2つの異なるセクションに分割することは合理的な解決策です。

しかし、stevenclは私をとても幸せにする議論をしました。 「これに関する数回の設計と調査の結果、タブが導入される可能性は十分にあります。しかし、これがユーザーが作業するファイルとアセットを管理する方法を改善するための最良の方法であるという知識がある場合にのみそうします。で、しかしUIを乱雑にすることにはなりません。」 実際に新しいことを試すことで、改善がもたらされます。

分割ウィンドウを管理する簡単な方法は、すでに改善されています。 ウィンドウの管理は常に同じ場所にある可能性があるという点で、作業ファイルについて議論することができます。 2〜4分割を再配置する場合、タブの管理はより手間がかかります（高解像度画面+アトム=必要に応じて水平および垂直分割）。 したがって、作業ファイルのインターフェースを維持するが、それをもう少し複雑に拡張する可能な解決策があります。

おかげで、私はこの会話をする機会に感謝します。

@ianwesterfield 、あなたは作業ファイルについて@kfranqueiroが強調しています。 現在の経験は間違いなく望ましい経験ではありません。

タブが引き起こす可能性のあるUXの問題を見てきましたが、VisualStudioの設計に何年も取り組んできました。 @bpaseroが上記で説明した「タブ地獄」の問題を軽減するための試みである

ただし、これが必要になる位置には入らないようにしたいと思います。 そのため、私たちは設計をさらに深く掘り下げて、利用可能なオプションを見つけて、それを決定したいと考えています。 さっきも言ったように、タブになってしまうかもしれません。 そうすれば、ファイルやその他のコード資産を管理するための優れたエクスペリエンスを提供する、作成できる最善のアプローチであることがわかります。

VSCodeでファイルを管理する方法に関して現在抱えている問題のすべての洞察と説明に感謝します。

@stevencl 、プレビュータブに言及するのはおかしいです-私はそれが大好きです。 VS Code、Sublime、Atom、Brackets（拡張機能経由）などに、デフォルトでこのようなプレビュー機能があるのは素晴らしいことです。

マイクロソフトがこのプロジェクトをオープンにしておくことで、進行中の設計に関する議論に参加する機会を与えてくれたことを非常に嬉しく思います。 ユーザーがスタートメニューの再設計中にその声しか持っていなかった場合、Windows7以降の大規模なオンボーディングを最終的に取得するためにWindowsは別のリリースサイクルを必要としなかった可能性があります。

これに関する数回の設計と調査の後、タブを導入することになる可能性は十分にあります。 ただし、これは、ユーザーが操作するファイルとアセットを管理する方法を改善するための最良の方法であり、UIが乱雑になることはないという知識がある場合にのみそうします。

再浮上したと思われるこの号を開いたので、このコメントは非常に満足のいくものだと思います。 タブが表示されるのではないかと思いますが、新しいアイデアの探索を完全にサポートしており、コードはこれを行うための優れたプラットフォームです。 私はあなたたちがこれまでに行った仕事が大好きです。
とは言うものの、これを_使用_したいということを忘れないでください。プライマリエディターとして使用できるのは早ければ早いほどよいので、慣れ親しんだ（まだ軽量の）エクスペリエンスを提供していただければ幸いです。私たちは今、生産的に使用し、くつろいでいることができ、仕事を続けることができます。 その後、あなたは新しい地平を探求するために世界中でいつでも取ることができます:)
それは、私たちがフルタイムでそれを採用できる魔法のラインに到達するためのコードを熱心に待っているということです。 私にとって、タブは私の唯一のユーザビリティの不満であり、ネイティブのコンパイルとデバッグは私の唯一の技術的な不満です。

どうしようもなくビジュアルスタジオに夢中になっている、疲れて苦しんでいるWindowsユーザーは私だけではないと思います。 救いは私たちの手に負えない小さな問題と特徴のほんの一部であり、それは急速に進んでいます、そして私はそのような可視性で参加しそして見る機会に感謝しています。

悲しいことに、Windowsは、最高の開発環境を備えた最悪の開発プラットフォーム/エコシステムであり続けており、15年ほどそのようになっています。 本当に変だ。
理由はわかりませんが、私にとっては、開発環境（生産性）が私のバランスでエコシステムよりも優先されているようですが、それは苦痛なバランスであり、LinuxでVSを完全に使用できるときは泥の中の豚のように幸せになります-時間！ 私たちはとても近いです！
皆さんがこれを新しい領域を探索するための手段と見なしていることは知っていますが、それは完全にクールですが、短期的には、Linux（またはそのようにスイングする場合はosx）でVSが必要です。十年かそこら、そして私たちはついに、これらすべての年の後に、私たちの苦しみを終わらせることができます！ ;）
</dramatic_commentary>

TL; DR、探索は完全に素晴らしいです、そして私はあなたがあなたが作ることができる最高の最終製品にコミットしていると確信しています、しかしそれまでの間はおそらく安全でおなじみの解決策ですか？

タブの場合は+1。 質問-それでは、Visual Studioバンドルから削除してみませんか？ その後何が起こるか見てください...

タブは+1！ 将来のアップデートでこれを実装してください。

実行中の仮定は、「ほとんどの場合、[タブ]が大きくなりすぎて、何も表示されなくなる」というもののようです。 私はこの仮定に挑戦したいと思います。 私は現在興味のあるファイルの目に見えるインデックスとしてタブを使用しており、興味が時間とともに変化するにつれてそのインデックスを積極的に管理しています。 可視性は重要です。私は常に物理的なタブを参照して、自分の向きを変えています。 作業ファイルを使用すると、そのインデックスを表示および操作する機能が失われます。 たとえば、キーボードを使用して作業ファイルからファイルを削除する方法はないようです。 編集者と戦っているような気がします。 SublimeTextスタイルのタブを追加してください。

VS Codeがタブなしで正常に動作することに同意しますが（最初から非常に生産的に使用されています）、オプションとしてタブを使用し（デフォルトで無効になっている可能性があります）、ユーザーがタブを使用するかどうかを決定できるようにすることを提案する上記のコメントにも同意しますそうではありません。

誰もが違うので、そこにオプションがあると素晴らしいでしょう。 それらがなくても問題なく動作できますが、それらを追加してもかまいません。おそらく、VSフルを何年も使用して使用することになるでしょう。 彼らはすでにバックログにあるように聞こえますが-ありがとう！

タブの場合は+1。 ほぼ1年はVSCodeで動作し、私はそれがとても好きです。 ただし、特にデバッグや検索、またはgit leftセクションで作業する場合は、タブを見逃します。 タブは、以前に作業していたコードがどのファイルに含まれているかを考えないようにするのに役立ちます。 ユーザーはタブとその順序を管理し、作業中のソースコードに関連付けることができるタブの位置も念頭に置いていると思います。 分割されたエディタータブもこの意図を維持できます。

Ctrl +タブはキーアクションであり、タブは視覚的なアクションであり、はるかに高速です。

VSが「作業ファイル」の管理にそれほど苦手でなければ、私はおそらくタブなしで生きることができたでしょう。 私は実際に編集せずにファイルの内部を参照するためだけにファイルを開くことがよくありますが、VSはそれらのファイルを作業ファイルリストに配置しませんが、タブ付き環境では間違いなくタブを開きます。

これは、ファイルを閉じたり、新しい「機能している」ファイルにフォーカスしたりすると、ファイルエクスプローラーが最後の場所にとどまるのではなく、開いているファイルに移動するという事実と相まって、非常に混乱を招きます。

「タブなしで4年間使用している」ので、これらは問題ではないことを理解しています。したがって、Ctrl + Tabの範囲外のものは、プログラムの奇妙な使用方法と見なされます。

これは機能である必要があり、デフォルトでオンかオフかは関係ありません。 事実上すべてのテキストエディタ/ IDEはナビゲーションにタブを使用します。 より良い方法があると感じる人もいるかもしれませんが、私たちのほとんどにとって、タブは効率的で使いやすく、使い慣れています...そして明らかに私たちはそれらを愛しています！ 1つのリリースでVisualStudioからそれらを取り出して、それらがどれほど重要かを確認します...（Metroスタイルの壮大な開発者のメルトダウンの合図）短期リリースのタブを検討してください。 それは私たちの多くがVSCodeのフルタイムの採用を妨げている唯一のことです。

：+1：

私はタブではるかに生産的です！ 私はGoogleChromeを使用するのと同じようにAtomを使用します（最初のタブにはCtrl + 1、Ctrl + 5など。Ctrl+ Tab、Ctrl + Shift + tab）。

ファイルを操作すると生産性が低下し、使用した後はいつも少しイライラします。

したがって、タブを実装してください。

タブは非常に便利です、+ 1

：+1：

@MadSpindel 「ファイルを操作すると生産性が低下し、使用した後はいつも少しイライラします。」 1000％が同意します...誰かがポイントなどを作るためにタブを強制されていないようです。 気に入らない場合は、オプションにしてください。

Visual Studio Power Toolsには、タブを垂直に表示するオプションがあります。これは私が絶対に気に入っていることです。

：+1：そして私は@sitefinitysteveに同意します。 チームがタブを持たないと主張する場合は、少なくとも拡張APIを改善して、サードパーティが追加できるようにします。

ここでタブが重要になります。もう1つの不足している機能に少し戻る必要があります。

VSCodeは、Working Filesの非情報実装をダンプしてから、複数のプロジェクトを開くことができるようにする機能を追加する必要があります。 私は、クライアント側のコードを1つのプロジェクトに分割し、サーバー側のコードを別のプロジェクトに分割することで作業を行っています。 大画面で、2つのコーディングウィンドウを開き、1つのプロジェクトツリーを左端に配置します。 左側のウィンドウにクライアントコード、右側のウィンドウにサーバーコード。 現在、どちらのプロジェクトでも、複数のソースファイルに取り組んでいます。 そのような場合、それらを開いたそれぞれのプロジェクトウィンドウの上のタブとして参照したいと思います。クライアント側のプロジェクトに3つまたは4つのタブがあり、サーバー側のプロジェクトに3つ以上のタブがある場合があります。

組織は有機的です。 作業ツリー全体、複数のプロジェクトが左側に表示されます。 コードウィンドウによるプロジェクトの分離があり、それぞれのプロジェクトウィンドウの上のタブによって作業中または参照されているオープンソースファイルもあります。

これは私にとって不可欠なワークフローです。 私は現在Atomでこれを正確に行っていますが、VSCodeが好きで、そのフローがVSCodeで複製されることを望んでいます。 そのためには、VSCodeは、それぞれのウィンドウの上に複数のプロジェクトサポートとタブを実装する必要があります。 そうでなければ、それはただの小さな男の編集者であり、私はそれを信じていません。 お願いします。

@riclfはそれを見つけています。

私は通常、左から右にHTML、JS、CSSの3つの垂直列を開いています。

Sublimeでは、すべてのhtmlタブが最初の列の上にあり、すべてのJSファイルが2番目の列の上にあるタブなどがあります。タブにはコンテキストがあり、間違った列で間違ったファイルを開くことはありません。

これはVSCodeではほとんど不可能です。「横に開く」を2回使用するだけで、3つの列を開くことができます。ファイルを閉じると、列が完全に消えることがあります。その時点で、新しい列を開くことができますが、並べ替える必要があります。それら。 ファイルを開くと、カーソルが現在置かれている列で再び開かれるため、cssファイルを開く場合は、カーソルが3番目の列にあることを確認する必要があります。 それは絶対に腹立たしいです。

言うまでもなく、作業ファイルセクションは、フォルダツリーの垂直方向のスペースを取ります。これは私のラップトップの実際の問題です。

マイクロソフトチームへの質問。 分割ビューがある場合、「作業ファイル」内のファイルがどの列に関連付けられているかをどのように知る必要がありますか？ タブがそれぞれの列の上にある場合は簡単です。

ちょうど私の2c。

ワーキングファイルに慣れることで、認知的不快感はゼロでした。 私はタブよりもずっとそれらを愛しています。 VSCodeのUIは正しい方向に進んでいます。 私はオプトインタブに反対していませんが、オプトアウトタブに適合します。

作業ファイルは、より良いレイアウト（より多くのスクロールスペース）のタブです。 将来追加される可能性のある「ティアオフ」およびドラッグ機能がありません。

mvimユーザーとして、私は複数のTDDファイルのセットを開いて、それらの間をタブで移動しています。 たとえば、私は角度+テスト、サーバー+テスト、キュウリまたは動作+スクリプトです。 タブで1つのファイルにアクセスするのではなく、開いているファイルの組み合わせにアクセスしたい。 Typescriptプロジェクトでは3か月間VSCodeに切り替えました。これは、クラス最高の素晴らしいTypescriptサポートが実際にあったためです。 しかし、Typescript以外のプロジェクトに移動するとすぐに、その汎用検索、ナビゲーション、および置換機能をmvimと直接比較し、すぐに（つまり、即座に）以前のエディターに戻ったと言って申し訳ありません。 私は27インチのAppleCinemaディスプレイを持っており、可能であればより大きなディスプレイを使用します。タブやファイルペアをたくさん入れるスペースが十分にあり、エディターがそのスペースを使用することに制限される理由はありません。 。一度に1つのファイルだけを処理したくない-多くのファイルを開き、タブからタブへのフローを追跡したい。

2週間前にVisualStudioCodeをもう一度試してみました。 いくつかのファイルをいじくり回したとき、私は実際に嬉しい驚きを覚えました。 しかし、一握り以上のファイルを開いた状態で実際の（大規模な）プロジェクトに取り組み始めたとき、タブの欠如は非常に厄介になりました。 _Working Files_は私に合わず、速度が低下しました。 3日後、私はそれにとてもイライラしたので、SublimeTextに戻りました。 私は仕事で2つの24 "画面（Windows）、自宅で27" Macを持っており、20のタブを簡単に開いても、どのファイルがどれであるかを区別できます。 私の場合、タブ用の画面領域がたくさんあります。 _You_は、エディターで開かれているファイルのファイル名をすでに表示しています。 ファイル名の右側のすべてのスペースは未使用であり（ウィンドウの右側のアイコンを除く）、タブで埋めることができます（これはSublime Textも同様です）。 私は、ユーザーに_WorkingFiles_やファイルタブを操作するオプションを与えると言います。 今のところ、SublimeTextとVisualStudioEnterpriseの組み合わせに切り替えています。 タブが追加されたら、再考します。

Working Filesオプションの場合、ファイルを選択するためにサイドバーを切り替える必要があります（コードを拡大表示するためにサイドバーを非表示にしておくため）。 また、 Ctrl+PおよびCtrl+tabオプションもユーザーフレンドリーではありません。

私はあなたたちがそのために何か違うことを試みていることを知っています、しかしあなたがすでに提供したオプションはユーザーフレンドリーではありません。 ごめんなさい。

ユーザーが作業リストを強制的に使用する代わりにタブを使用できるように、この拡張機能を提供してください。 作業ファイル機能が非常に嫌いです。ファイルの切り替えが遅くなり、生産性が低下します。

私がVSCodeを初めて使用したとき、私は本当にタブを見逃していました。 それから私はctrl + tabを発見しました、そして私はもはやそれらを必要としません。

私はvscode（ほとんどの部分で素晴らしい）を私のプライマリエディターにしようと数ヶ月間努力してきましたが、タブの欠如は私を苛立たせ、私の生産性を傷つけ続けています（私は開いているタブのセットを積極的に管理している人の一人です他のエディターで）。 Ctrl + tabは、タブの代わりにはなりません。

vscodeチームがこれに偏っていることは明らかであり、現在、ユーザーが実際にはタブを必要としないことを「納得」させることを目指しています。 しかし、これはWindows 8から[スタート]メニューが削除されるのと同じタイプの考え方です（これがどのように終了したかは誰もが知っています）。

@peshoその通り！

コード折り畳みが終了したので、これはUserVoiceの最大の問題です。 コミュニティのフィードバックやユーザーエクスペリエンスのテストなどを引き続き検討しているため、社内でいくつかのオプションを検討しています。ここでの議論に感謝します。 非常に役立ちます。

おそらくそれが、私がほぼ1年前にvscodeを初めて開いて、数分のプレイの直後に閉じた唯一の理由です。 そして、あなたはまだタブを持っていません。 すぐに表示されるので、使用できます。 そのオープンソースであり、マイクロソフトの人々は、単に「このツールを社内で使用しているので、タブを必要としない」だけでなく、考えを変えて（今やろうとしていることですよね？）、コミュニティに耳を傾ける必要があります。

@pleerockタブがないのでIDEを試すつもりはありませんか？！ （Oo）weeeweweweweeeww。 タブは無意味であるため、タブを追加することは望んでいません。詳細に言うと、ウィンドウのクロムスペースに上部の幅を追加している間は、通常、値が追加されません。 代替案は、より多くのメタデータ、使いやすさ、およびより迅速なナビゲーションを提供します。

タブを使用して、開いたままにするファイルを選択します。 Ctrlキーを押しながらTabキーを押すか、「作業ファイル」かを問わず、ファイルを開いてコードを検索し、別のファイルに切り替えてそのコードを使用すると、最初のファイルに戻る方法がありません。エクスプローラーでファイルに移動します。

私は3つのエディターを持っていることを知っていますが、ルックアップコードのみのファイルで他の2つをオーバーライドしたくない場合があります。

ファイルを開いたときに別のファイル履歴に残っている場合は、タブがなくても問題ありません。 ファイルが5秒以上開かれている場合は、CTRL + Tabで入力する価値があります。

@ 4tronはい、私にとっては便利なIDEを使いたいからです。 タブを失うことは無意味で安全なスペースです（おそらくネットブックを使用していて、余分なピクセルが実際に少ないために十分なスペースがありません=））、他の人にとっては便利で生産性が向上します。 優れたソフトウェアはすべてカスタマイズ可能で、パネルを表示/非表示にする機能を備えている必要があります。 「スペースを節約する」ことは議論の余地がありません。 タブを導入し、タブを表示/非表示にする機能を追加します（誰かにとって本当に必要な場合=））。 新しいアメリカを開いたり、間違ったイノベーションを行ったりする必要はありません。Intellij、ビジュアルスタジオなど、UXを何年にもわたってより良くした最高のIDEから学ぶ必要があります。

それは本当に簡単です-それを[設定]タブにするか、タブなしにするだけです。 タブがオンの場合、作業ファイルはありません。タブがオフの場合、作業ファイルです。 それは天才でした！ ;）

私、私はタブの男です。 作業ファイルは非常に限られており、直感的ではなく、プロジェクトツリーの垂直方向のスペースを占有していることがわかりました。 ただし、複数のプロジェクトを開くことができなくても問題はありません。 :(

好みも大丈夫だと思います。

また、作業ファイルシステムを強化する方法も考えました。 履歴としてタブラインを使用する必要があります。
たとえば、左側のウィンドウで4つのファイルを開き、5番目のファイルを開いてタブ行から最も古い変更ファイルを作成すると、ファイルは消えて、作業ファイルでは「変更ファイル」としてのみ返されます。

また、スマートにすることもできます。システムは、最初に保存されたファイルや変更されていないファイルの消失を優先することもできます。

事実、タブの肥大化が問題になったとしても、タブは非常に実用的です。 タブの使用方法を検討する必要がありますが、タブの数を制限します。

通常、私は何日も編集していないタブを開いたままにします。 これは一般的にそれを膨満させる人です。

+1

私は4K画面を持っていて、水平方向にタブがないので、VsCodeが本当にオフになっています

ところで、私はタブだけでなく、タブのセットが欲しいことを明確にしたいと思います。 MacのフルスタックmvimTDD開発者として、私はコンテキストの観点から考えています。 html + css、angular +テスト、node +テスト、cucumber +テストステップ。 私は通常、次のコンテキストであるTDDスタイルに移行する前に、単一のコンテキストで数行のコードを処理します。 mvimを使用する場合、これらのコンテキストを非常にすばやく切り替えるだけでなく（Macターミナル、Mac Finder、SafariまたはChromeで使用するのと同じキーシーケンスを使用）、ペアのファイルを自動的に開くマクロの恩恵を受けます。角度ソースファイル、対応するテストを自動的に開くことができます。 これは非常に生産的な作業方法であり、キーボードに指を置いたままにします。

1つのタブを切り替えるだけで、「関連付けられた」ファイルを隣り合ったフレームで開くことができるIDEを見つけた場合、たとえばbutton.htmlを開くと、その横にあるbutton.jsとます。 3番目のフレームでは、別のIDEを二度と使用しません。

私はそれが決して起こらないことを知っています、しかしただ言ってください。

それでは、mvimを使用する必要があります。 http://www.vim.org/scripts/script.php?script_id=1567コマンド：AVは関連ファイルを開きます（関連する場合はA）。

@jtoseyが話しているのは、まさに私がここに来て言ったことです。 ペインを使用して、関連ファイルのセットを整理します。 ほとんどのタブ管理では、コンテキストを切り替えるときに、これらの関連ファイルを並べて表示します。

+1

ここでも同じですが、タブが大好きです。

AtomからVSCodeに切り替えたところ、しばらく作業した後、驚くほど整理されてクリーンに感じられることに気づきました。 理由？ タブの人口過多はありません！ タブが実際にないことが、このエクスペリエンスを非常にスムーズにしている理由です。 私の主なファイルナビゲーションは、任意のファイルにすばやくジャンプできるcommand-Pメニューです。

VSタブは完璧です。タブを持ってきてください。タブを別のウィンドウにドッキング解除するのもいいでしょう。
vscodeをありがとう:)

私は実際、VSCを汎用ファイルエディタにするのか、それとも単なるソースコードエディタにするのかについて非常に興味があります。

タブバーが絶対に要求される状況がいくつかあります。

1. 多くのタブをすばやく切り替えます。
   私によくある状況は、簡体字中国語とその従来の同等物を比較するなど、2つ以上のファイルをその形状で比較する必要があることです。 差分は文字が異なるため、問題は解決しません。 唯一の方法は、タブをすばやく切り替えて、眼球に単語がないかどうかを確認することです。 STとIを使用すると、Alt-NUMを使用してタブを切り替えることができますが、VSCで可能な唯一の方法は、複数のCtrl-Tabを使用するか、マウスをすばやく移動してクリックすることです。
2. 長くて入力しにくいファイル名。
   Ctrl-Pを使用してファイルを切り替えることは悪くありません。 しかし、長い共通の修正を共有するいくつかのファイル名はどうですか？ 英語以外の名前はどうですか？ Ctrl-Pで青年急着买房的原因（上）.mdと青年急着买房的原因（下）.mdを切り替えるのにどれくらいの時間を費やすか考えてみてください。

コードを書くときにどちらの状況にも遭遇しないと思いますが、汎用エディターとして、これは深刻な問題です。

@ msg7086ポイント1についてはよくctrl + pと入力してから、 .mdと入力すると、2つのオプションが残り、 ctrl + tabだけで1つを選択できます。欲しいです？ 問題を正しく理解しているかどうかわからない

@ 4tron返信ありがとうございます。 ただし、そのタイプのファイルが2つしかない場合にのみ、この方法は機能します。 実際には、人々はおそらく単一のディレクトリでそれらのファイルの束を操作しているでしょう。 イメージング私は、ファイル名として中国語、韓国語、アラビア語などのさまざまな文字を使用して、マークダウン形式で50件の投稿があるブログを書いています。 私が打った実際のシナリオは、実際にはCJK名の字幕ファイルで、すべてが*.assであるため、拡張機能によるCtrl + Pはうまく機能しません。

これを実装できれば本当にありがたいです

開発者はそれに慣れています、これを優先してください。

タブの場合は+1。 タブを実装してください。

タブは+1！

私もタブの追加に投票します。

+1

+1

+1

できるだけ早くタブが必要です。

タブが恋しいです。 私は彼らに手を差し伸べ続けています。2つまたは3つの異なる開いているドキュメントをすばやく参照するとよいでしょう。

大したことは何ですか？

• 作業ファイル領域の高さがロックされています。これは、タブが多すぎるのと同じ問題ですが、管理が面倒です（ここではマウスやスクロールホイールがありません）。 タブは簡単に削除でき、開いているファイルスタック内の次のドキュメントをユーザーに提供します。
• CodeのExplorer列はSublimesよりもはるかに幅が広く、スペースを節約するために2つのアプリを並べて実行するときに最小化する必要がある場合があります（たとえば、左側がUnity、右側がCode）。 タブが機能するためにスペースを節約する必要はありません。コードには、タブを配置できる空の領域がすでにあります。
• タブは使いやすさとスペースの節約のために勝ちます。UXの調査は必要ありません。 それらはすぐに使用でき、私たちは皆それらが好きです。

タブ付きのドキュメント管理を教えてください:)

+1、私。

+1

+1

VSCodeは優れたエディターであり、GitとNodejsの両方との優れた統合ポイントを備えています。 プライマリ開発IDEとして使用しない主な理由は、タブをサポートしていないためです。

こっちも一緒。 それは私がそれを使用することを妨げる唯一のことです。
Op do 10mrt。 2016 om 15:18 schreef Konrad Piascik < [email protected]

VSCodeは優れたエディターであり、Gitと
Nodejs。 主な開発IDEとして使用しない主な理由
タブをサポートしていないためです。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment-194867036 。

実装がとても簡単なはずなので、この問題に多くの反発があるのを見るのは少し驚きです。 少なくとも、それをオプションにするか、拡張機能を介して利用できるようにします（ブラケットのように）。

これが追加される場合は、以下を追加してください。

1. GoogleChromeのような機能を閉じます。 （VSの標準バージョンにはこれがなかったのでいつもイライラしていました。）
   -「他のタブを閉じる」
   -「右側のタブを閉じる」。
2. タブを右または左に開くオプション。 （VSはある時点でデフォルトを変更しましたが、変更するオプションを追加しました）

タブは機能します。 彼らはいたるところにあり、人々はそれに慣れています。 現在のファイルのリストは直感的ではありません。 毎日VSCodeを使用して2か月経った今でも、ファイルを切り替える必要があるたびに、タブを探しています。 他のすべてのエディターがタブを使い続けるという事実は、別の何かが直感的になるための大きな障壁を生み出します。

私のチームでは、人々はそれについていつも不平を言っています。タイプスクリプトのサポートなしで崇高なものを使用してからVSCodeを使用することを好む人もいます。

私は、開いているファイルを処理する「より良い」方法を見つけるためのUX調査に反対していませんが、これをOfficeリボンの大失敗にしないでください。これは、正確に別の方法を発明するために5年と複数のリリースを要しました。同じこと。

-1

私がタブに反対している理由についてのいくつかのメモ：

• タブに費やす時間は、エディターに他の改善を加えることから奪われる時間になります。
• 私は自分自身をキーボードコマンドのようにすることを余儀なくされており、タブがないことは役に立ちました。 ですから、私自身はまだそこにいませんが、それはあなた自身のための良い観点から議論しています。
• 以前に関連して、これはGmailがいつ発売されたかを思い出させ、ラベルがフォルダよりも優れていることを人々に納得させなければなりませんでした。 一部の人々はそれを処理できず、まだAOL / ISPの電子メールアカウントを揺さぶっています。 MSはここで「これが物事を行うためのより良い方法だと思う」と言って立つべきだと思います。
• 何か提案するとしたら、タブがない理由と、タブなしでエディターをナビゲートする例を前もって説明します。

まあ、妥協点があります-設定/オプションでタブを表示するかどうか。

この開発者には複数のプログラマーがいると確信しているので、他の改善から時間がかかるとは思いません。 私もキーボードコマンドが大好きです。 それらが実装されている場合は、それらを使用しないでください。しかし、ワークフローでタブを好む人がそれらを使用できないようにするのはなぜですか。

とにかく、大したことはありません。 VSCが何をするかを決定するのを待つ間、私はAtomに戻りました。 複数のプロジェクトフォルダを開くことができることに加えて、大規模なプロジェクトのワークフローに不可欠なタブを見つけました。

私は自分自身をキーボードコマンドのようにすることを余儀なくされており、タブがないことは役に立ちました。 ですから、私自身はまだそこにいませんが、それはあなた自身のための良い観点から議論しています。

このスレッドの前半で提案した

電話を持って！ 答えが出ました！ パーフェクトだ！ 準備はいいですか？ タブは必要ありません。 エディターの上部にあるタブに水平に表示する簡単なオプションを使用して、作業ファイルを拡張してみましょう。 ウーフー！ タブを作成せずに問題が解決しました！

私は実際、現在の方法を好みます。開いているファイルのパネルと、側面に「作業ファイル」があるリストのようなファイルピッカーです。 Atomを使用していたとき、ファイルをすばやく見るたびに新しいタブが開き、数分以内にタブバーが役に立たないタブでいっぱいになるのが嫌でした。

だから私はこれで-1です。 しかし、私はまだウィンドウのドッキング解除を見たいと思います。

AtomからVSCodeに切り替えたところ、しばらく作業した後、驚くほど整理されてクリーンに感じられることに気づきました。 理由？ タブの人口過多はありません！ タブが実際にないことが、このエクスペリエンスを非常にスムーズにしている理由です。

この。 100％同意します。

私は実際、現在の方法を好みます。開いているファイルのパネルと、側面に「作業ファイル」があるリストのようなファイルピッカーです。 Atomを使用していたとき、ファイルをすばやく見るたびに新しいタブが開き、数分以内にタブバーが役に立たないタブでいっぱいになるのが嫌でした。

私はそれを理解し、それが私たちが作業ファイルの代わりではなく_追加の_機能を求めている理由です。 なぜ両方をエディターに含めることができなかったのか、私は一生理解できません。 私は真剣に意味します。 このスレッドで必要なタブの数を確認してください。 これは_ボタンを青にしたい_シナリオではありません。 これは、このテキストエディタでタブを必要としている大多数の人々の生産性の妨げになっています（ちなみに、これはAtomやSublimeよりも優れている途中です）。 両側で有効な引数を取得します。タブと作業ファイルをどちらかをオフにするオプションに含めることができない理由がわかりません。 誰もが勝ちます。

@ jayrosen1576多分問題は、それがどのように見えるべきかについて、誰も実際に詳細な提案をしなかったことです。

• タブバーをすべてのウィンドウの上に配置する必要がありますか？
• 複数のファイルを並べて開いている場合、または将来のリリースで水平方向に分割されている場合でも、タブをクリックするとどのように機能しますか？
• アクティブなファイルのタブは常に強調表示されますか？ デバッグコンソールがフォーカスされている場合はどうなりますか？
• タブ設定を有効にした場合、作業ファイルセクションは冗長であるため削除されますか？
• 異なるフォルダに重複するファイル名はどうですか？
• タブとパネルの重複した閉じるボタンはどうですか？
• パネルを閉じるとタブが閉じますか？
• Atom（urgh）のようにファイルを開くとすぐに、または作業ファイルのように編集したときにのみタブが表示されますか？

これらはすべて、開発チームが時間を費やさなければならない質問です。 そして、私が努力する限り、作業ファイルリストよりもエレガントで混乱しない実装を考えることはできません。

これがどのように見えるべきかについての提案です：

1）Atomをダウンロードする
2）Atomを開く
3）タブを見てください
4）VSCodeで実装する

@ jayrosen1576真剣に？ Atomの実装に関するいくつかの有効な懸念事項と、作業ファイルの概念がないためにAtomにはない問題について名前を付けました。

それからまた、あなたのプロフィール写真はすべてを言います。

• タブバーをすべてのウィンドウの上に配置する必要がありますか？
  A：はい。 Atomでタブを試す
• 複数のファイルを並べて開いている場合、または将来のリリースで水平方向に分割されている場合でも、タブをクリックするとどのように機能しますか？
  A：タブは各ペインの上部に表示されます。 Atomでタブを試してください。
• アクティブなファイルのタブは常に強調表示されますか？
  A：はい。 Atomでタブを試してください。
• デバッグコンソールがフォーカスされている場合はどうなりますか？
  A： 2つのファイルを並べて開いた状態でデバッグコンソールにフォーカスした場合と同じ結果になります。
• タブ設定を有効にした場合、作業ファイルセクションは冗長であるため削除されますか？
  A：作業ファイルを無効にした場合のみ（オプションとして）
• 異なるフォルダに重複するファイル名はどうですか？
  A：タブには部分的なパスが含まれています。 Atomでタブを試してください。
• タブとパネルの重複した閉じるボタンはどうですか？
  A：パネルには閉じるボタンがありません。 Atomでタブを試してください。
• パネルを閉じるとタブが閉じますか？
  A：はい。 Atomでタブを試してください。
• Atom（urgh）のようにファイルを開くとすぐに、または作業ファイルのように編集したときにのみタブが表示されますか？
  A：オプションを有効にした場合のみ（AtomのusePreviewTabs = falseはこれをオフにします）。 それ以外の場合は、ダブルクリックしてタブで開きます。 Atomでタブを試してください。

@felixfbeckerこの製品には含まれているため、オプションのタブがあり、

それはあなたがあなたの懸念への有効な答えに応えてプロフィール写真のように気さくに何かを持ち出すときあなたのキャラクターについてのボリュームを言います。

電話を持って！ 答えが出ました！ パーフェクトだ！ 準備はいいですか？ タブは必要ありません。 エディターの上部にあるタブに水平に表示する簡単なオプションを使用して、作業ファイルを拡張してみましょう。 ウーフー！ タブを作成せずに問題が解決しました！

@ jayrosen1576これは実際には完全な問題を解決するわけではありません。前に言ったように（そして文字通りあなたの直前のコメントで再び取り上げたので）、異なるのはタブの外観だけではなく、動作です。 ここでの最初のコメントで述べたように、Sublime Textでも代わりに「サイドバーのタブ」を取得できますが、それでも作業ファイルと同じではありません。 （IMOの方がいいです。）

@kfranqueiro私は完全に同意します。 私はただ卑劣でした。 このタブのことは本当にばかげた議論です。 VSCodeにAtomのタブのタブ機能があり、（デフォルトでも）非表示にするオプションがある場合は完璧です。 私たちは皆同じことを求めていると思います。 どちらかをオフにするオプションに両方を含めることができない理由がわかりません。

正直なところ、タブがテキストエディタに適しているかどうかを議論するのはばかげています。 これは新しい概念ではありません。 実装してオプションのままにしてください。 それを拡張にして、それをノーにします。 VS大文字メニューの選択のように、これが基本的な機能であり、それがないことは意味がないことに人々が気付くまで、1つの拡張機能があります。

@nvivo自分でそれを置くことはできませんでした。 この全体の議論はばかげているようです。

VS大文字メニューの選択と同じです。

@nvivoこの拡張機能を試しましたか？ メニューオプションはありませんが、いくつかのキーボードショートカットを設定できます。 かなりうまく機能します。

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

このディスカッションの人々が気に入らない場合は、先に進んでください。 このスレッドを読むことは完全に任意です！

もちろん、それを読むことはオプションですが、VS Codeにタブを追加することはオプションであり、それについて議論する必要があるという考えをサポートしているようです。 次の質問の簡単な投票。

タブがすぐに追加されない場合、VS Codeを引き続き使用しますか？ はい・いいえ

彼らがそれを追加しないならば、マイクロソフトがそれの潜在的なユーザーベースの大部分を失うであろうことを示すでしょう。 つまり、商業的な観点からは、機能自体を必要としない場合でも、それを行わないことは商業的な自殺になります。 エルゴ、この会話は気が散って不必要です。

そうは言っても、私たちはまだブラウザに拡張機能を入れていない同じ会社について話している。 だから私は何でも可能だと思います。

真面目な話として、タブを実装するための最良の方法について話し合う必要があります。 人々がこの機能を望んでいるかどうかについての疑問符はもうないので、会話をより建設的なものに移しましょう。

ブラウザ拡張？ アクティブ... NVM。

正直私はタブの理由がわかりません。 タブへの愛情はあまりにもひどいです。 実際の作業を実行するという点では、ショートカットは、正規表現による検索、より多くのメタデータ、はるかに優れた蒸気で裏打ちされた作業プロセスなど、必要なすべてを実行します。 それらは、私にはわからないが、なじみのあるものに対する基本的な難解な必要性を提供します。 これは、msがコミュニティに役立つかどうか、コミュニティが本当に変化しているかどうかを確認するための単なるプッシュであるように感じます。 vs号の大文字のテキスト全体ほど無意味ではありませんが。

以前に言われたことに関して。

「他の改善から時間がかかるとは思わない」

個人的には、たとえばテキストエディタウィンドウで拡張機能を作成して、タブが必要な人のために拡張機能を作成できるようにするなど、そうだと思います。 vscodeの全体的な考え方は、エンドユーザーが拡張機能を追加するか拡張することで、可能な限り最小限かつ軽量に保つことだと確信しています。

@ 4tron 、もちろん、ここでマイクロソフトをテストするための邪悪なコミュニティの陰謀があります！ いつもあるのではないですか？

タブに意味がある場合は、他のエディターがタブを使用しているのがわかります。 そして、それが複数のオープンコンテンツを整理するための本当に良い方法である場合、たとえばブラウザなど、複数のオープンコンテンツを整理する必要がある他の種類のソフトウェアもそれらを使用するでしょう。 しかしもちろん、意味がないので、そうではありません！ タブを使用するブラウザのように、人々がいつも使用しているものを想像できますか？ ナンセンス！

安全に遊ぼうと言います。 最初に待って、他の優れたエディターがこの新機能をサポートしているかどうかを確認して、実際には機能しないものに時間と労力を浪費しないようにします。 Visual Studio、Intellij、Eclipse、Atom、Sublime、MonoDevelop、Notepad ++、またはその他のかなりのユーザーベースを持つものを確認してみましょう。 これらのエディターの少なくとも_一部_がこの機能を他のものに置き換えることなく数年間サポートすると、これが便利な機能であることが示されます。

しかし、自分より先に進まないようにしましょう。 人々がその欲求を直接表現し、おそらく他の人々に投票させることができる問題追跡システムのようなものが必要です。そうすれば、これを無料で行わないようにすることができます。 リポジトリで最もリクエストの多い機能の1つになった場合にのみ、アクションを実行できます。 そうすれば、それがトレンドであるだけでなく、人々が日常業務に役立つと感じ、ここでもその機能を望んでいることがわかります。

しかし、その日まで、辛抱強く待ちましょう。 テキストエディタはまったく新しいものであり、実際にどのような機能が必要かは誰にもわかりません。

ゲヘヘ、陽気！

Op za 12mrt。 2016オム11時57分schreefナタンビボ[email protected]

@ 4tron https://github.com/4tron 、もちろん、の陰謀があります
ここでマイクロソフトをテストする邪悪なコミュニティ！ いつもあるのではないですか？

タブに意味がある場合は、他のエディターがタブを使用しているのがわかります。 そしてそれなら
複数のオープンコンテンツ、おそらく他の種類を整理するための本当に良い方法でした
のような複数のオープンコンテンツを整理する必要があるソフトウェアの
たとえば、ブラウザもそれらを使用します。 しかしもちろんそうではありません、
彼らは意味をなさないので！ 人々がすべてを使用するものを想像できますか
タブを使用するブラウザのような時間？ ナンセンス！

安全に遊ぼうと言います。 まず待って、他の優れたエディターがあるかどうかを確認しましょう
この新機能をサポートしているので、何かに時間と労力を無駄にすることはありません
それは実際には機能しません。 ビジュアルスタジオ、インテリジ、エクリプス、
アトム、サブライム、モノデベロップ、メモ帳++、またはその他の
かなりのユーザーベース。 これらのエディターの少なくとも_一部_がサポートすると
この機能を他のものに置き換えることなく、数年間、
次に、これが便利な機能であることが示されます。

しかし、自分より先に進まないようにしましょう。 私たちはのようなものを持っている必要があります
人々がその欲求を直接表現し、多分許可することができる問題追跡システム
他の人が投票するので、私たちは本当にこれをしていないことを確認できます
何もない！ それが最も要求されたものの1つになった場合にのみ行動を起こすことができます
リポジトリ内の機能。 そうすれば、それがトレンドだけではないことがわかります。
しかし、人々はそれが日常の仕事に役立つと感じ、ここでその機能を望んでいます
あまりにも。

しかし、その日まで、辛抱強く待ちましょう。 テキストエディタはまったく新しいものです
実際にどのような機能が必要かは誰にもわかりません。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment-195715795 。

@nvivo現在、ブラウザとテキストエディタを本当に比較していますか？ ここで皮肉を使いすぎていることを理解しています。それは素晴らしいことです。 私が言いたいのは、タブが役立つかどうかということではありません。 私はlightwieght /最小限のエディターのアイデアが好きです。 これは私の意見です。ユーザーの好みに基づいてエディターをユーザーが拡張できるという考えが好きです。 それが私がvscodeに取り組んでもらいたいことです。 次に、このディスカッションを「開発者がまだこれの拡張機能を作成していないのはなぜですか..タブが好きで、これでそれが欲しいので、多分私はすべきです、そしてvscodeはそうすることができます、今私はテキストエディタを持っていますそれは私のブラウザに似ています」

@ 4tron彼もテキストエディタをテキストエディタと比較しているように見えました。
彼らはvscodeを拡張可能にするのに素晴らしい仕事をしていると思いますが、私はタブがすぐに使える機能であるべきだと考えているキャンプにしっかりといます。 この概念「ああ、あなたはあなたが使う他のすべてのソフトウェアのようなタブが好きですか？グーグルの問題、適切なユーザー提供の拡張機能をインストールする方法を説明する推奨事項を見つけてください、そしてあなたは行ってもいいです！」 飛ばない。 ほとんどのユーザーはタブが存在することを期待していると思いますが、拡張機能をインストールすることでタブバーが見つかると思う人は非常に多いと思います。 これまでに他のソフトウェアが先行していないことは間違いありません。 なぜ人々はそうしようと思うのでしょうか？

@TurkeyMan
彼のレトリックは、ブラウザとの比較から始まりました。

ここでは開発者について話しています。 タブが欲しければ、彼らが主導権を握ると思います。 申し訳ありませんが、このアイデアに反対していますが、正当な理由のタブが表示されません。常にvsでalt + qが表示されます。付加価値が表示されません。 これは私の個人的な意見であり、タブがどのように役立つと思われるかを理解していないために開発者がくだらないかもしれません。 この会話は冗長であり、個人的には、vscodeがほぼ完全なカスタマイズ、さらにはビジネスベースのモデルのための分離されたシェルとして開かれることを望んでいます。 誰かがカスタマイズを集中的に強化して、たとえば、編集者がユーザーのコードベースのエコシステムに基づいて構築するDrupal開発やWordPress開発を行うことができます。 それも私には解決すべきより良い問題のようです。

すべてが拡張機能であるという欠点は、それらの間で奇妙な望ましくない相互作用が発生することです。 スマートファイルリオープナーの上ですでにGitHistoryを使用しているvsコードでは、奇妙なファイルクローズの問題が発生します。

タブと同じくらい基本的なものは、すぐに使えるはずです。 さて、他の人がこのスレッドで要求したように、タブのグループを開くか、タブ間の関係を作成することは、拡張機能が議論に入る場所です。

@ 4tron 、面白かったけど、その点で真面目なんだ。

外部コンパイラサービスは、テキストエディタでサポートするかどうかを決定できるものです。 統合されたタスクランナーは、機能を備えていると便利です。

タブはこのクラスにはありません。 タブは、ウィンドウ、ボタン、ファイルを開いたり保存したりするようなものです。 ここで決定することはありません。ただそこに置いて先に進むだけです。人々はそれを期待しています。 これは、プラグインでサポートされることを望んでいる高度なカスタム機能ではなく、_あらゆるOS_の標準UIです。 人々はそれに慣れており、他のすべての可能な編集者がそれらを追加するための請願を必要としなかった理由があります。

そして、これがタブが良いかどうかを議論するのが愚かである理由です。 VS CodeはUXの実験ではなく、すべてのプラットフォームに適した.NETエディターを使用するための試みです。 このいまいましいことを90％の人々に役立つようにすれば、あなたは成功するでしょう。

私は正直に代替案についてあなたの主張を理解しますが、あなたはあなたが非常に少数派であることを理解する必要があります。 これを求めているほとんどの人がマイクロソフトをテストしたい単なるトロールであると信じているのは妄想です。

msがタブに対するスタンスを変えるかどうかを確認するための呼び出しであるという点は、主にタブを含めることへの情熱のために、中途半端でした。 タブがなかったので、誰かがエディタを試してみなかったところまで。 私はこれを理解するのに苦労しています。 まだベータ版であることを忘れないでください。 うまくいけば、彼らはタブを追加するでしょう（オプションとしてお願いします）。

@ 4tron何度も試しましたが、vscodeは大規模なプロジェクトにうまく対応できないようで、タブがないことが私に当てはまる主な実用上の理由の1つであるため、定期的に使用していません。
少数のファイルを編集するときは、主にライトテキストエディターとして使用しますが、大きなプロジェクトの1つで作業したいときは、vscodeが機能しません。 タブが欠落していて、サブプロジェクト（またはVSが言うところの「ソリューション」）の概念がないという事実は、私が現在認識している唯一のブロッカーです。

ただし、プラグインを使用してすべてを追加するというこのアイデアについてコメントしたいと思います。 それは素晴らしい目標です。 優れた拡張フレームワークを持つことは重要ですが、彼らはそのアイデアに過度にコミットすることに注意する必要があると思います。
私はVSを使用していますが、MS製品に期待する非常に高いレベルの製品品質を備えているため、私はVSに夢中になっています。 私はそこにあるすべてのOSSの代替手段（および他のプロプライエタリツール）を試しましたが、それらはすべて、基本的なユーザビリティの面では不十分であるようです（特にデバッグエクスペリエンスに関して）。
vscodeの目的が、誰もが拡張機能を介して機能をランダムにハッキングする軽いシェルではないことを本当に望んでいます...その説明に適合する他のツールはすでにたくさんありますが、魅力的なツールはまだ他にありません。 私がvscodeに求めているのは、私が常にVSに求めていたものです。 プロのUXデザイナーによって使いやすさの観点からうまく設計され、クロスプラットフォームになること。

タブに反対している人はポイントを逃しているかもしれないと思います。 私（私たち）は、オールオアナッシングの解決策を望んでいません。 私たちが求めているのは、人気のあるAtomエディターのタブと同じように表示および動作するタブ（デフォルトでは非表示にできます）をオンにする簡単なオプションだけです。 あなたがそれらを気に入らなければ、あなたはそれらが存在することさえ決して知りません。 そうすれば、それらを有効にすることができます。 また、Atomとマルチペイン+タブのエクスペリエンスを使用したことがない場合は、議論を完全に無視する前に試してみることをお勧めします。 あなたはそれらが気に入らないかもしれませんが、あなたはそれらが私たちの多くにとって有用であることを認めなければなりません。 VS Codeの優れたnode.jsデバッグ機能がなければ、Atomを排他的に使用します。 作業ファイルは気にしません。 それらは便利だと思いますが、タブの代わりにはならず、同じことを行うための代替方法ではありません。 それは、_ホンダシビックを持っているのに、なぜピックアップトラックが必要なのですか？_と言っているようなものです。1200ポンドの竹の舌と溝の床をシビックの後ろに積み込んでみてください。理由がわかります。 どちらも車両ですが、目的は異なります。

前に言ったように、1つのリリースでVisual Studio、Edge、またはその他のMicrosoft製品からタブを取り出して、反応を確認します。 かわいくないでしょう。 私たちは皆、それを両方の方法で持つことができます。 タブは必須のエディタコンポーネントではなく、_オプション_である必要があります。 他のエディター開発により多くの時間を費やすことができますか？ 承知しました。 エディターの使用をブロックする重大なバグ修正と改善が常に最初に行われる必要

VSCodeがここ数か月でどのようになったかが気に入っており、利用可能な最高のエディターにしたいので、このトピックに取り組んでいます。 ここには否定的な余地はありません。 私たちは皆、開発者として何をしたいのか、何を望まないのかについて情熱を持っています。 誰も間違った意見を持っているわけではありませんが、反対意見はそのように尊重されなければならず、あなたがそれらが無効であると感じるので単に割り引かれるのではありません。

「タブへの情熱」はあまりないと思います。 @bpaseroが「タブは開いているファイルのリストを表示するのに良い方法ではないと思う」と「これまでのところタブの正当

私はこのすべての議論を見るのが面白くてイライラしています。仕事で毎日VSCodeを使用していて、MacとLinuxで優れた.NETエディターが欲しいので、少し腹を立てています。タブがたくさんありません。 「_すごい！これは実際にはもっと便利です_」という瞬間はありませんでしたが、ここでの応答は「_私たちが素晴らしいものを作成したことに気づかなかっただけです！時間をかけてそれに慣れてください！_」のようです。

VSCodeを数か月間毎日使用することで私が目にする実際の問題は次のとおりです。

• ウィンドウの閉じるアイコンをクリックしても意味がありませんが、ファイルはそのリストに保持します-実際に目覚めているファイルだけが表示されるリストを作成するには、そのリストを常に手動でクリーンアップする必要があります-とファイル私が一緒に仕事をしているのは、最後に開いたものでも、変更しているものでもありません。同時に開いたままにしておきたいものです。
• 保存されていないファイルを閉じて、マーカーでそのリストに含めることは私には意味がありません-1日に何度も何かをしますが、ファイルを閉じてVSコードが要求しなかったため、変更はアプリに反映されませんそれを保存するために私は時間を無駄にします
• ワンクリックでファイルを開きますが、ダブルクリックするだけでファイルを最近使用したセクションに配置します-そのため、そこに表示されないファイルを常に開きます-すると、筋肉の記憶でファイルのスペースを追加または削除するのが簡単になります次に、もう一度見ているファイルまでスクロールして、ダブルクリックします
• リストがいっぱいになると、スクロールバーにカーソルを合わせないとスクロールバーが表示されないのが面倒です。 さて、これはUIがエディターでどのように機能するかという理由で複雑です。 しかし、参照してください。私はプロジェクトを知っており、フォルダービューにはさらに多くのファイルが必要であることを知っています。 コードの構造も知っているので、エディターペインにはもっと何かがあるはずです。 しかし、最近のリストでは、私にはわかりません。 「いっぱいですか、それともそのファイルを開くのを忘れましたか？1分前にそのファイルを開きませんでしたか？もう一度そのファイルを開きましょう...」

さて、これのほとんどは「_oh」のような引数で解決されることがわかりますが、要点が欠けています。これは最近使用されたファイルリストであり、開いているファイルリストではありません。タブと比較しているので、より良いものがあります。開いているファイルを処理する方法。しばらくすると、..._ "

私は喜んで答えます：「_このすべては私には意味がなく、実際に私を非生産的にしています。何十年もの間どこでも機能する解決策がすでにあります。私は決してなかった何かを修正したくありません問題であり、正直なところ、この新しいソリューションがより良い代替手段であるとは考えていません。うまく機能する使い慣れたものを手に入れることができ、私たちは皆慣れていますか？ありがとうございます_」

私はこれらすべてが傲慢に聞こえることを知っています。 しかし、これはほとんどの人が考えていることだと思いますが、恥ずかしがり屋であるか礼儀正しくて言えません。

実験的なUIは代替手段として最適であり、私は2つを切り替えるオプションを持っていることにすべて賛成です。 しかし、これは現在、最も一般的で予想される他のオプションを妨げる強制的な実験です。 そして、Windows 8のスタートメニューのように、これがうまく終了する方法はありません。

「このすべてが私には意味がなく、実際に私を非生産的にしています。何十年もの間どこでも機能する解決策がすでにあります。私は決してなかったものを修正したくありません。問題、そして私は正直に言って、この新しい解決策をより良い代替案とは考えていません。私たちは、うまく機能する身近なものを手に入れることができ、私たちは皆慣れていますか？ありがとう」
..。
そして、Windows 8のスタートメニューのように、これがうまく終了する方法はありません。

私はこれ以上同意できませんでした。

コード折り畳みはかつて機能に最も投票されていたので、今はタブです。 vscodeチームは私たちに折りたたみを与えました。

マイクロソフトがオープンソースコミュニティに新たに参加したことを踏まえて、vscodeチームがトップユーザーのリクエストを含めたという素晴らしい実績を考えると、タブが実現しないとしたら、驚きと失望を覚えます。

@ianwesterfieldまさに、それは何千もの投票で最も要求された機能です。 それは起こりそうです。 この会話は無意味であり、「タブはどの程度正確に機能する必要がありますか？」に進む必要があります。

以前、タブのほぼ完全な実装の存在についてコメントしました：Atom。 それらは整理が簡単で、2つのタブが同じファイル名を持っている場合に部分的なファイルパスを適切に表示し、複数の水平および/または垂直ペインを持つウィンドウで非常にうまく機能します（これはVSCodeのもう1つの必要な機能だと思います）。 VSCodeがAtomと同じタブ機能を持っていれば、それは誰もが求めているものの99％をカバーすると思います。 また、Atomも電子ベースであるため、実装はVSCodeでも同様に機能します。 私は何のコピーキャットソリューションでもありませんが、彼ら（Atom）はタブを実装する素晴らしい仕事をしており、彼らが持っているものはその点で優れたソリューションです。

@ jon64digitalたぶん私だけかもしれませんが、この会話が進化するのを妨げているのは欲求不満の感覚だと思います。 このリクエストは、3月31日の反復で6,000以上の投票と漠然とした言葉での参照があっても、バックログでまだ割り当てられていません。

ドキュメント管理、編集者のスタック動作を改善します

それは、タブの動作は言うまでもなく、タブの存在を繰り返し正当化する必要があるように感じます。 少なくとも、養子縁組の障害を

そのことを念頭に置いて、少なくとも誰かに割り当てれば、 @ waderyanが以前に言ったことで思います。

編集おそらく、VS Codeチームからのこのコミットメントの欠如は、誤解です。3月の反復計画はすべて1月7日以降更新されていません。

@ jayrosen1576同意します-そして、カバーされないユーザーリクエストの1％は、拡張子を介して対処できると思います（たとえば、タブグループ内のリレーションを持つファイルを開くなど）。

@ jayrosen1576アトムでは、ファイルをリンクして、（たとえば）最初のフレームでtoolbar.html、2番目のフレームでtoolbar.js、3番目のフレームでtoolbar.cssを開く分割ビューを作成できますか？

これは単なる例ですが、絶対に理想的です。 上記の誰かがVimでこれができると言っていましたが、私はvimをチェックして、いくつかの理由でそれに熱心ではありませんでしたが、タブのことは素晴らしいですね。

@ jon64digital Atomはデフォルトでこれを行いません、そして私はこれまでにこれを行う拡張機能（vimに触発された拡張機能でさえ）を知りませんが、これは私が前回の投稿で言及した拡張機能のユースケースです。

編集上記の@jtoseyによるコメントを参照してください（この投稿の約9日前）。

個人的には、これが煩わしいと感じました。 半分の時間、ビューは気にしません。コントローラー、モデル、クライアント側のJSだけです。 JSを開くたびにビューが開くと、おそらく気が狂ってしまうでしょう。

しかし、繰り返しになりますが、それは拡張機能の美しさです。それが気に入らない場合は、オフにすることができます。

UXに非常に強い影響を与えるこのような機能リクエストに取り組むとき、私たちは通常、実際の実装がどのように見えるべきかを議論するために、最初にUXミーティングにかなりの時間を費やします。 かなり前からアジェンダのドキュメント管理を

GAリリースの月末以降にこのアイテムを取り上げ、ドキュメント管理が将来どのように機能するかについての議論を開始します。 私たちは物事がどのように機能するかという現在の方法にいくつかの欠陥を見て、それを改善する必要があることを知っています。 タブがなくても、今日のUXの動作があまり直感的ではないことがいくつかあると思います（クローズエディターとクローズファイル、サイドエディターは他のエディターとは異なる動作をしているという事実、作業ファイル、クイック開くなど）。

タブの概念はよく理解されていますが、既存のドキュメント管理にタブを追加するだけで、そこでの概念を再検討する必要はないと考えています。

将来、ドキュメント管理がどのように機能するかについてはかなりの議論があると思います。必要に応じて、概念を見直していくつもりだと思います。

@bpaseroは別の問題のコードを

@bpasero議論されていることと、私たちが投稿した問題の可能な解決策として考えているアプローチのいくつかについて詳しく説明していただければ幸いです。

PS VSCodeでそれが可能かどうかはわかりませんが、Roslyn、TypeScriptなどの一部のチームはデザインノートを共有しています。これにより、それらの動作と今後の予定について多くのコンテキストが提供され、コミュニティが新しいディスカッションに開かれます。このようなことは可能ですか？

@bpaseroは、コミュニティがタブを追加しようとする試みを真剣に検討します。 やってみてもかまいませんが、努力が妨げられても時間を無駄にしたいとは思わない

あなたのチームは、このモグラヒルを山にしたことでベーパーロック現象に陥っていると思います。

意味：タブは、ドキュメント管理のより広い概念の構成要素であり、同義ではありません。 vscodeのドキュメント管理の他の領域を扱うためにすでに提出された他の問題があります。

UXのアイデアについては、オープンな問題ですでに説明しています（https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Auxを参照）。同じことを行うと思います。ドキュメント管理とタブ用。

また、これらの改善を拡張機能を介して行うのではなく、VSCodeワークベンチのコアコンセプトとして使用したいと思います。

チームでUXディスカッションを開始したら、コミュニティにも参加したいと思います。次に、現在の設計に見られる欠陥と、改善する予定の内容についても話し合います。

@bpaseroどうもありがとうございました、それが私が知りたかったすべてです。 :)

@bpaseroすごい。 皆さんが製品に多大な努力を払っていることを私は知っています、そして私たちは皆それを本当に感謝しています。 私たちの多くは、UIにタブがないことに不満を感じていると思います。タブに大きく依存しており、作業方法を完全に変更することは実際には選択肢ではないからです。 私たちはこれが世の中で最高のエディターであることを望んでおり、それを達成するのに本当に近いです。

このスレッド全体を読まずに、私はこれに大きな：+1：を与えます。

私は何年もSublimeに使用していて、タブが大好きです。 作業ファイルがギャップの一部を埋めているようですが、完全ではありません。 理由を完全に説明することはできませんが、タブを教えてください！

+1

非常に必要です。

+1

私は開発中にさまざまな種類のファイルを扱っているので、ある種類のファイルの右側にタブグループを作成し、他の種類のファイルの左側に別のタブグループを作成することがよくあります。 たとえば、分度器/ webdriverjsコードで作業するときは、右側のすべての「ページオブジェクト」と左側のすべての「仕様」を、個別に論理的にグループ化しておくのが好きです。 同様に、フロントエンドのもので作業するときは、すべてのjs / tsファイル用に右側にタブグループを保持し、htmlとcss用に左側に別のタブグループを保持します。

これらはほんの2つの例ですが、私はほぼすべてのプロジェクトである程度これを常に行っており、この戦略は長年の開発に役立っており、非常に役立ちます。

コードでは確かに複数のペインを使用できますが、グローバルファイルリストアプローチではファイルタイプを区別するのが難しくなるため、表示したいファイルのリストをスクロールするのに多くの時間を浪費していることに気付きます。 さらに、右側のペインで1つのファイルだけを（本能的に）閉じようとすると、ペイン全体が消えます。これは、特に16年以上通常のVSを使用した後、ペインが残りの部分で開いたままになることを期待するように訓練された後、非常にイライラします。表示されるファイル。

コードにタブグループがないことは非常に残念であり、あなたの意見では「より良い」または「タブの正当な理由がない」という理由で、人々が特定の方法で作業することを強制または納得させるべきではないと思います。 はいあります。 たぶん、あなたはそれらを最善の方法で使用しないか、それらが有用であると感じないかもしれませんが、タブグループのような基本的なものを使用し、本当に感謝する私たちがたくさんいます。

私の理解では、コードはすでにタブグループをサポートしているAtomに基づいています。 この機能を削除するには、多くの余分な作業が必要になるように思われますが、それは私にはあまり意味がありません。 少なくとも、ユーザーが希望するエクスペリエンスを選択できるようにして、自分に最適な方法でコードを使用できるようにします。

タブグループをVSCodeに戻してください。

たぶん、作業ファイルリストのファイル名の周りにボックスを描くと、機能的に左側のタブと同等であることがわかります... :-)

@ChrisMiami ：そうでないことを除い

笑

2016年3月17日木曜日午前4時59分ケネスG.フランケイロ<
[email protected]>は書いた：

@ChrisMiami https://github.com/ChrisMiami ：そうでない場合を除く
https://github.com/Microsoft/vscode/issues/224#issuecomment-166931316 。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

@kfranqueiroは、適切なタブソリューションを待っている間、 ctrl + wおよびctrl + shift + wを通常のタブの実装に近づけるために使用するキーバインディングを採用

@ nub340 VSCodeはAtomに基づいていませんが、Atomに取り組んでいるのと同じグループによって作成されたElectronに基づいています。

+1追加してください!!!

また、これは他の点では優れたエディターにはまったく欠けている機能だと思います。

オプションとしてタブを追加するか、タブ機能のためにサードパーティのプラグインを許可してください。

VSCについて（ばかげた名前の後に）最初に私を驚かせたのは、タブを持たないことがいかに素晴らしいかということでした。

現在、8つのファイルを開いています。ファイル名がタブに表示されないため、タブは無意味です。

私はCTRL + TABを_adore_し、「作業ファイル」リストを表示します。

タブを追加する必要がある場合は、オプションにしてください。

@leegee彼らは「無意味」ではありません、あなたは彼らの必要がないだけです。 さまざまな種類のプロジェクトに取り組んでいる人々は、あなたとは異なるユースケースを持っているかもしれないと思いましたか？

タブに投票した何千人もの人々に与えてください、私はこのあたりの唯一の「無意味な」ことはあなたのコメントだと思います:)

@ jon64digital ：プロジェクトがタブの見通しについてユーザーからの一般的なコメントを求めているのを見ました-私はそれを私たち自身の意見を表明する必要があることを意味すると解釈しました。 私は今、あなたの意見を表明し、あなたの失礼な人身攻撃を避けるために、最初にあなたに電子メールを送るべきだったことに気づきました。 謝罪いたします。

@ jon64digital @leegeeは、彼らは一般的にではなく、彼にとって無意味だと言った。 私はタブを完全にサポートしていますが、タブを使用しない場合はオフにできるオプションであることに同意します。 個人的な攻撃に頼るのではなく、議論を民事に保ちましょう。 誰も間違った意見を持っていません。 彼らはまさにその...意見です。

@ jayrosen1576彼はコメントを編集しました。 もしそれがもともと「私にとって無意味だ」と言っていたら、もちろん私は自分がしたことを言っていなかっただろう。 また、彼のコメントに反対票を投じた他の2人は、彼がコメントを編集する前にそうしました。

私は誰もが意見を述べる権利があることに完全に同意しますが、ワークフローにタブを必要としない人が何人かいるようです。彼らは-1を入力するか、MSに機能が必須ではないか、何らかの方法でリソースをより重要な機能からそらすことになります。 何人の人がタブを欲しがっているのかがわかるので、これは利己的で少し未熟だと思います。

とにかく、誰かがこれを個人攻撃と見なした場合は、お詫び申し上げます。 その後、スマイリーを入れました。

どちらかといえば、この議論は、開発者がIDEを使用できる方法がたくさんあり、それらすべてがユースケースに対して完全に有効であることを示していると思います。 「正しい」方法は1つではなく、結局のところ、それは仕事を成し遂げるための単なるツールです。 タブが好きな開発者もいるので、ファイルのように任意にグループ化できます。また、単一のMRUリストが完全に適切であると考える開発者もいます。 次に、すべてにメモ帳を使用する人がいます。私たちは皆、パンジーの集まりです。

真剣に私は、タブがVisual Studioの重要な部分であるため、そのユーティリティに慣れてきて、単一のMRUリストをオプション（オプトインまたはオプトアウト）にする開発者がたくさんいると感じています。 VSCodeがすべての人にとってさらに用途が広いというすでに素晴らしいツールになります。

@ nub340まさに！ タブは常に開発者/ユーザーとしての経験の一部であったため、私たちの中にはタブが好きな人もいます。個人的には、作業中のファイルを一番上に表示するのが好きです。作業中のファイルよりもタブに固有の利点はありませんが、それが私たちはそれが好きです。

同意しました。強制するのではなく、オプションとして使用したいと思います。
6:22エヤルSolnikで火、2016年3月22日には[email protected]
書きました：

@ nub340 https://github.com/nub340まさに！ タブが好きな人もいます
彼らは常に開発者/ユーザーとしての私たちの経験の一部でした、個人的に私は好きです
私が作業しているファイルを一番上に表示するには、固有のものはありません
作業ファイルよりもタブの方が有利ですが、それが私たちの一部の好みです。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

Vic-20にはタブがありませんでした。

この議論から生まれる1つのことは、何でも（作られた）ということです
利用可能で、カスタマイズ可能である必要があります。

@ glennblock 、 @ leegeeええ、それは間違いなくオプションであるはずですが、作業ファイルはそれを望まない人たちのために同じ扱いを受けるべきではありませんか？ ただし、別の機能リクエストでそれについて議論するのがおそらく最善です。 :)

私はこのテキストをここに投稿しました： https ：

この議論にも有効です。 @bpaseroの反応を見てうれしいです。

この機能が欲しいです。 議論の終わり。 あなたの意見をファック@bpasero私はあなたが正しいと思うものとそうでないものを気にしません。 タブ＃224についても同じです。 あなたはあなたの解決策がより良いことを私たちに納得させようとしています。 もう一度あなたの解決策を性交します。 私たちは皆違ったやり方で物事を行い、誰もあなたの考えを気にしません。 typescriptとangular2が強力にサポートされているため、vscodeを使用しています。 それ以外の場合は、通常のエディターにあるSublimeText、Atom、Bracketsなどの機能が不足しているため嫌いです

ハハ@PeterMtj 、私たち全員が考えていることを言ってくれてありがとう:)

@bpaseroには、自分で使用しない機能や個人のワークフローに合わない機能に投票して信用を落とす習慣があるようです。

人々は主にMicrosoftソフトウェアを使用する必要がありますが、それが好きなことはめったにありません。Microsoftのスタッフが彼のような態度をとっているのを見ると、SublimeTextのようなまともなソフトウェアを設計できない理由がわかります。 私はVSCodeで一生懸命努力しましたが、アンインストールに非常に近づいています。

@PeterMtj真剣に？ それはあなたが物事にアプローチする方法ですか？ 人々を呪う？ あなたが彼を尊重していないなら、あなた自身を尊重してください！

@ jon64digital彼は投票するか、個人的な意見を言うことができます。

「いいえ」は専門家ではなく、私の意見ではかなり失礼だという彼の最初の回答にも同意しませんが、人々の意見に関係なく、コミュニティはより良くなり、文明を維持できると思います。

人々は主にMicrosoftソフトウェアを使用する必要がありますが、それが好きなことはめったにありません。Microsoftのスタッフが彼のような態度をとっているのを見ると、SublimeTextのようなまともなソフトウェアを設計できない理由がわかります。 私はVSCodeで一生懸命努力しましたが、アンインストールに非常に近づいています。

編集：人々はマイクロソフト製品を使用する必要はありません！ 私は確かにそれをする必要はありません、そして人々がそれを好きだからめったにそうしないと言って、それはただのごみ話です！ マイクロソフトはいくつかの優れた製品と優れたテクノロジーを製造しており、私はそれらが行うすべてのことのファンではありませんが、確かにいくつかのことを正しく行っています！ 誰もVSCodeの使用を強制することはなく、誰かがVSCodeの使用を強制した場合は、独自のツールを選択する必要があるため、解雇される必要があります。 雇用主が気にかけるべき唯一のことは、それがどのように行われるかではなく、あなたの仕事です！

これを炎上戦争に変えず、建設的にしてください！

@eyalsk

私は炎上戦争を始めようとしたり、ゴミを話したりしていませんでしたが、私は100％私が言ったことを支持します。 MSはこれまで、自社の製品をOSと相互に結び付けて、ソフトウェアを単独で使用するのに十分ではないことを知っているため、人々にソフトウェアの使用を強制してきました。 職場でMSOfficeを使用しなければならない人はたくさんいますが、他に選択肢がなく、片手でInternet Explorerを自発的に使用する人の数を数えることができたため、以前はVisualStudioを使用する必要がありました。 これらの慣行のために、彼らは独占禁止法訴訟の対象にさえなりました。したがって、誰もMSソフトウェアを使用させていないというのはナイーブです。

最近、物事は正しい方向に進んでおり、プラットフォームにとらわれず、ソフトウェアの相互運用性を他の人とより良くしようとしています。 MSには、優れたソフトウェアを作成し、人々が望むものを提供しようとしている優秀な人々がいると確信していますが、bpaseroは明らかにその1つではありません。 彼の心を閉ざした態度は彼らの功績ではなく、 @ PeterMtjがそのように彼を呼んだのは面白いと

ここには長いスレッドがあり、何百人もの人々がMSにコードエディタに何を求めているかを正確に伝えています。 彼らが私たちが何を望んでいるのかわからないわけではありません。 次に、ここにMSの従業員がいて、「いいえ、基本的にすべて間違っています」と言っています。 それは彼らの聴衆と正確に調和していない会社の絵を描きませんか？

ちょうど私の2c。

@ jon64digital

私は炎上戦争を始めようとしたり、ゴミを話したりしていませんでしたが、私は100％私が言ったことを支持します。 MSはこれまで、自社の製品をOSと相互に結び付けて、ソフトウェアを単独で使用するのに十分ではないことを知っているため、人々にソフトウェアの使用を強制してきました。

それはあなたの偏見の仮定であり、私はそれを尊重しますが、いくつかのアップル、オラクル、グーグルを挙げれば、世界中の他の企業についてまったく同じことを言うことができます...

職場でMSOfficeを使用しなければならない人をたくさん知っています。

人々はMSOfficeの使用を強制されていません。それは雇用主の決定です。LibreOfficeは優れた製品であり、非常に優れた代替手段です。

他に選択肢がなかったので、以前はVisualStudioを使用する必要がありました。

なぜあなたに選択肢がなかったのかわかりませんが、今日は間違いなく選択肢があります！ 人々が.NET開発にVisualStudioを多用した場合でも、常に選択肢がありました。SharpDevelop、Vim、Notepad ++を使用しました。複数のエディターを使用しても問題はありませんでした。とにかく、デザイナーのファンではありません...

C / ++の場合、VC ++を使用しない限り、エディターとIDEからさらに多くのサポートがあります:)

その上、なぜ一部の人々がXによって作られた特定のテクノロジーのスタックに自分自身をロックしているのか理解できませんでした。マイクロソフト以外にも多くのテクノロジーがあります。

片方の手の指でInternetExplorerを自発的に使用する人の数を数えることができました。

確かに、Internet Explorerはバージョン9までは非常に悪かったのですが、それ以降はかなり改善されています。私はFireFoxユーザーですが、Microsoftを過去に判断するのではなく、彼らが誰であるかを判断します。プレゼントとかっこいい！

これらの慣行のために、彼らは独占禁止法訴訟の対象にさえなりました。したがって、誰もMSソフトウェアを使用させていないというのはナイーブです。

誰も誰かに何かを使わせているわけではなく、ほとんどの人のことは知りませんが、私はナイーブとはほど遠いです。

雇用主がMSテクノロジーの使用を選択した場合、あなたは確かに_強制_されますが、これもMicrosoftの責任ではありません。MSテクノロジーの使用を選択した場合、それを選択し、それについて不平を言うのは少しばかげています。同等のテクノロジーがあります。マイクロソフトのものと同じくらい良いので、人々は確かに選択肢があります。

最近、物事は正しい方向に進んでおり、プラットフォームにとらわれず、ソフトウェアの相互運用性を他の人とより良くしようとしています。 MSには、優れたソフトウェアを作成し、人々が望むものを提供しようとしている優秀な人々がいると確信しています。

丁度！ デザインの観点からは、欲しいものを提供するのは良いことではないと思いますが。 :)

しかし、bpaseroは明らかにそれらの1つではありません。 彼の心を閉ざした態度は彼らの功績ではなく、 @ PeterMtjがそのように彼を呼んだのは面白いと

私たちは彼らの意見に基づいて人々を定義する必要はないと思います、確かにこの種の意見ではなく、大人であることは人々をいかなる種類の個人的な攻撃に対しても脆弱にしません、人を誓うことは不快であり、落胆すべきです、大人として行動するということは、怒りを抑え、不快感を与えることなく誰かや何かについて意見を書くことができるということです。

ここには長いスレッドがあり、何百人もの人々がMSにコードエディタに何を求めているかを正確に伝えています。 彼らが私たちが何を望んでいるのかわからないわけではありません。 次に、ここにMSの従業員がいて、「いいえ、基本的にすべて間違っています」と言っています。 それは彼らの聴衆と正確に調和していない会社の絵を描きませんか？

それは公正な点と不満です、私は他のことを言っていません！ しかし、 @ bpaseroは、UXに取り組むと、この問題にも取り組むとすでに述べています。「チームでUXの議論を始めたら、コミュニティも参加させたいと思います。次に、現在の設計に見られる欠陥についても話し合います。そして私たちが改善しようとしていること。_」

@eyalskはい、それはまさに私がこれにアプローチする方法であり、私はそれを取り戻すことはありません。 私は彼を人として怒らせなかった。 私はこれとタブの彼のくだらない代替案についての彼の意見を怒らせた。 それは大きな違いです。 表示されない場合は、もう一度考えてみてください。

@ jon64digitalは@bpaseroの態度についてせよ、@ bpaseroはおそらく彼の態度でコミュニティとコミュニケーションをとるべきではありません。 それが私の意見です。

マイクロソフトが私たちを助けていないことを理解してみてください。 私たちはマイクロソフトの製品を使用し、フィードバックを提供して、適切な製品を作成できるように支援しています。 これは、タブの防御についての議論ではなく、タブがどのように機能するかについての議論である必要があります。 Vscodeはコミュニティ向けであり、それは私たちです。極端な場合、画面の中央に赤い恐竜が必要な場合は、理由を疑うことなく実行する必要があります。 私たちは皆、私たち自身の理由があります。 そうでなければ、vscodeはコミュニティにとって役に立たない。 それが私がそれを見る方法です。

@PeterMtj同意しないことに同意する必要があると思います。 :)

私は飛び込んで、この問題のいくつかの追加の背景を提供したいと思いました。 私たちは、コードの主要なマイルストーンのまとめについてです。 過去6か月間の私たちの主な焦点は、アクセシビリティとローカリゼーションのサポートでした。 これにより、タブのフィードバックに積極的に取り組むためのUI領域のサイクルがなくなりました。 3月の計画（＃3555）のチェックボックスのほとんどがチェックされたので、ゆっくりと再び調べ始めています。 4月には、このトピックについて詳しく説明します。 @bpaseroはUXの開発において重要な役割を果たし、これが次の大きな進化となるでしょう。

皆さんの情熱とフィードバックに感謝し、VSCodeを最高の製品にするお手伝いをします。

アクセシビリティの追加のためのTIA-私たちにとって大きな違いを生むでしょう
ハーフブラインド

2016年3月26日土曜日、01：38 Erich Gamma、 notifications @ github.comは次のように書いています。

私は飛び込んで、この問題のいくつかの追加の背景を提供したいと思いました。
私たちは、コードの主要なマイルストーンのまとめについてです。 私たちの主な焦点
過去6か月間は、アクセシビリティとローカリゼーションのサポートでした。 この
タブのフィードバックに積極的に取り組むためのUI領域のサイクルが残っていません。
これで、3月の計画のほとんどのチェックボックス（＃3555
https://github.com/Microsoft/vscode/issues/3555）がチェックされ、
ゆっくりと再び見上げ始めます。 4月には、このトピックについて詳しく説明します。
@bpasero https://github.com/bpaseroは、
私たちのUXの開発とこれは次の主要な進化になります。

皆さんの情熱とフィードバックに感謝し、VSCodeを
それができる最高の製品。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

@egamma本当にありがとうございました。あなたは素晴らしい仕事をしていると思います！ しかし、 @ bpaseroによる最初の応答は人々を苛立たせたように感じます。彼が単に「いいえ」と言うのではなく、タブを選択すべきではないと彼が考える理由について洞察を与えれば、これは回避できたはずです。

とにかく、現在に焦点を当てましょう、// build /イベントの前に新しいビルドはありますか？ ：D

@eyalsk 「いいえ」のコメントは、現在の拡張APIを使用してタブを実装することができないという点で、実際には@inakianduagaからの最初の返信を参照していると

@Tyriar 、お

とにかく、現在に焦点を当てましょう、// build /イベントの前に新しいビルドはありますか？ ：D

新しいビルドのビットは、インサイダーチャネル（リリースノート）ですでにあなたを待っています。それを使用して、フィードバックをお寄せください。

@egammaありがとう！ ;）

私たちはこの経験に基づいて設計作業を開始しており、可能な限りコミュニティに参加したいと考えています。 フィードバックをお待ちしておりますので、定期的に設計に関するディスカッションを行います。 ほとんどの場合、これらは1対1のセッションであり、私たちが取り組んでいることを共有し、それらについてあなたと話し合います。

最初のセッションは今週の水曜日に行われます。 興味のある方はこちらからサインアップしてください： https ：

驚くばかり！
2016年4月4日月曜日午前3時54分スティーブンクラーク[email protected]
書きました：

私たちはこの経験に基づいて設計作業を開始しており、
できる限りコミュニティを巻き込みます。 通常のデザインを実行します
フィードバックを得るために進行中のディスカッション。 ほとんどの場合、これらは
私たちが取り組んでいることを共有し、議論する1対1のセッションになります
あなたと一緒に。

最初のセッションは今週の水曜日に行われます。 次の場合はこちらからサインアップしてください
あなたが興味を持っている：
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

この問題に関連して調査している新しいデザインについてのフィードバックをお待ちしております。 興味のある方は、上記の@stevenclのコメントのリンクからサインアップしてください！

午前3時と午前4時のみ？ 他にない？ 水曜日の午前3/4をPSTにすることはできません。

8:14ブラッドGashlerで月、2016年4月4日には[email protected]
書きました：

私たちが模索している新しいデザインへのフィードバックをお待ちしております
この問題に関連しています。 興味のある方は、上のリンクからサインアップしてください
上記のスティーブンのコメント！

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

PSTに合わせたタイミングがあればいいのですが、私も含めてたくさん参加できます

{モバイル}

2016年4月4日月曜日の午前8時50分-0700に、「GlennBlock」 [email protected]は次のように書いています。

午前3時と午前4時のみ？ 他にない？ 水曜日の午前3/4をPSTにすることはできません。

8:14ブラッドGashlerで月、2016年4月4日には[email protected]

書きました：

私たちが模索している新しいデザインへのフィードバックをお待ちしております

この問題に関連しています。 興味のある方は、上のリンクからサインアップしてください

上記のスティーブンのコメント！

—

あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください

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

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

はい、お願いします。 私は会話の一部になりたいと思っています。

申し訳ありませんが、これらの時間はすべての人にとって便利ではないことを私は知っています。 将来的には、定期的に開催する予定であるため、さまざまなタイムゾーンでセッションをスケジュールする方法を検討します。

今週、別の時間に追加のスケジュールを立ててみませんか？ これは
関心の高いホットトピック。

2016年4月4日月曜日午前9時44分スティーブンクラーク[email protected]
書きました：

申し訳ありませんが、これらの時間はすべての人にとって便利ではないことを私は知っています。 将来的には
さまざまなタイムゾーンでセッションをスケジュールする方法を検討します
定期的に開催する予定です。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

ご存知のとおり、表示されるタイムスロットは、まだ利用可能なタイムスロットです。 私はその日の後半にスロットを開いていましたが、それらは非常に迅速に取得されました。

私が言ったように、私たちは将来、異なるタイムゾーンでセッションをスケジュールしようとします。

すべての関心に感謝します。

なるほど、すぐにいっぱいになったと思います（これは良いことです）
11:30スティーブン・クラークの月、2016年4月4日には[email protected]
書きました：

ご存知のとおり、表示されるタイムスロットは
まだ利用可能です。 私はその日の後半にスロットを開いていましたが、それらは取られました
かなり早く。

私が言ったように、私たちはさまざまなタイムゾーンでセッションをスケジュールしようとします
未来。

すべての関心に感謝します。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

セッションを記録できますか/記録できますか？

2016年4月4日月曜日午前11時32分グレンブロックグレン。 [email protected]は書いた：

なるほど、すぐにいっぱいになったと思います（これは良いことです）
11:30スティーブン・クラークの月、2016年4月4日には[email protected]
書きました：

ご存知のとおり、表示されるタイムスロットは
まだ利用可能です。 私はその日の後半にスロットを開いていましたが、それらは取られました
かなり早く。

私が言ったように、私たちはさまざまなタイムゾーンでセッションをスケジュールしようとします
未来。

すべての関心に感謝します。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

私がサインアップすることができたので、私が以前にこれを見ていたらよかったのに。 価値があるので、タブを実装しないでください。 私はvimからTextMate、Sublime、Atom、そして今ではVS Code（途中で多くのIDEを使用）に進んだので、タブについて多くの経験を積んでいます。 私にとって、彼らは人々が使用し、決して通り過ぎない松葉杖です。 大規模なプロジェクトで開いている多くのタブを管理することは、私が必要としないもう1つの雑用を追加するフラストレーションの練習です。 いくつかを閉じるのを忘れると、すぐに絶望的になります。 これに決して遭遇しない規律を持っているあなたのそれらの少数に、称賛。 しかし、なぜ不必要な仕事に精神的なエネルギーを費やすのでしょうか？

さらに重要なことに、タブを使用すると、（ほとんどのコード開発では）関数、クラス、名前空間（シンボル）に焦点を当てる必要があるときに、ファイルの観点から考えるようになります。 ほとんどの場合、ファイルは実装の詳細であり、ナビゲーションを支配するべきではありません。 VS Codeには、新しくてより良いものを提供する本当の機会があると思います。

これは私の好みであり、多くの人がタブをオプションにすることを求めている理由を理解しています。 これは妥当な妥協案のように思えるかもしれませんが、2つの異なるナビゲーションワークフローを適切にサポートすることは困難です。 Atomのタブプラグインをオフにしてみて、開発者がタブがそこにあることを期待しているために機能しない、または機能しないものがいくつあるかを確認してください。 したがって、私自身の利己的な理由から、VS Code開発者には、タブ（またはファイル）ベースではないナビゲーションに集中してもらいたいと思います。

同上@indiejames

タブを実装する場合は、多くのファイルに対して複数の行をサポートしてください。 タブバーにスクロールバーがあるのは嫌いです。 私のお気に入りのタブの実装はTabsStudioです。 同じベース名のファイルを自動的にグループ化する方法も参照してください。

私のワークフローは、必要に応じてSublimeで作業しているときにタブを開きます。 たくさんのタブを開いたままにせず、「すべて閉じる」を使用して物事をきれいな状態に戻すことがよくあります。

私は複数のIDEとテキストエディタで30年以上開発してきました。 私はタブを松葉杖とは見ていません。これは便利な整理ツールです。 はい、タブが無数にあると制御不能になる可能性がありますが、私はそうではありません。

ファイルなどに焦点を当てるタブに関しては、コードはファイル内に存在し、ファイルは整理に使用され、VSコードはコードのフォルダーとファイルの管理を中心に構築されています。

私は完全にタブを持たないことを好む人がいるかもしれません、そして私はそこにあるものを取り除くと言っているわけではありませんが、サポートされているタブワークフローがあるといいでしょう。
2016年4月5日火曜日午前7時32分にエラー[email protected]は次のように書いています。

タブを実装する場合は、多くのファイルに対して複数の行をサポートしてください。 嫌い
タブバーにスクロールバーがあります。 私のお気に入りのタブの実装はタブです
スタジオhttps://tabsstudio.com/。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

「ユーザーが製品を誤用しやすくする」というのは、この機能をサポートしないというひどい理由です。 このツールは、ワークフローを_指示_するのではなく、ワークフローを_促進_するためのものです。 ユーザーが快適なワークフローを見つけられない場合、そのユーザーは、なじみのないパラダイムに適応するのではなく、可能な場合は別のツールを選択する可能性が高くなります。

私は現在、いくつかの密接に関連するファイルに取り組んでおり、それらの間を行ったり来たりしています。 切り替える必要があるたびに、サイドバーまたはドロップダウンから選択する必要があります。これには、タブの3〜4倍の時間がかかります。

@indiejames

ただし、2つの異なるナビゲーションワークフローを適切にサポートすることは困難です。 Atomでタブプラグインを回してみて、開発者がタブがそこにあることを期待しているために、どのように機能しないか、うまく機能しないかを確認してください。 したがって、私自身の利己的な理由から、VS Code開発者には、タブ（またはファイル）ベースではないナビゲーションに集中してもらいたいと思います。

2つの異なるナビゲーションワークフローまたは2つ以上のワークフローをサポートすることはそれほど難しくありません。本当に難しいのは、デザインを正しくすることです。

タブや作業ファイル、または別のワークフローを本当にサポートしたい場合は、数ステップ前に戻る必要があります。ズームアウトしてナビゲーションをゼロから再設計し、ワークフローを人々が選択できる戦略にします。

ユースケースや、人々がタブや別のワークフローをどのように操作しているかを考慮せずに、エディターにタブを表示するためだけに拡張機能を作成すると、実際のメリットが得られないため、失敗する可能性が高くなります。

コードナビゲーションとファイルナビゲーションには違いがあります。コードを作成するときは、必ず
ファイルではなくシンボルについて考えますが、コードはファイル内に存在し、場合によってはそれも処理する必要があります。たとえば、多くのタブを開かないのですが、複数のプロジェクトで作業している場合、通常、関連するプロジェクトごとに1つのファイルを開きます。ホットキーを多用しますが、タブは常に上部にあり、エディターを見ると常にそこにあるため、おそらく心理的ですが、集中するのに役立ちます。

タブに関するあなたの経験は残念であり、私はあなたの経験をまったく過小評価していません。あなたがどのように働いているかはわかりませんが、私たちの多くはそれを気に入って大成功を収めています。

ある経験が他の経験よりも優れているとは思いませんが、異なる経験やハイブリッドさえも役立つ可能性があり、編集者は私の経験を尊重し、それに反しないようにする必要があります。

他のコミットメントのためにミーティングを行うことができない私たちにとって、フィードバックを提供できることは非常に役に立ちます。
たぶん、会議が1日目に終わったら、会議のビデオを投稿して（関係者全員の許可を得て）、他の人が会議の残り時間内に表示してコメントできるようにしますか？

明らかにそれは長い期間ではありえませんが、うまくいけばいくつかの異なる視点が追加されて、より多くのフィードバックが害になることはありません。

ワークフローがJavaScript開発者のワークフローとは異なるため、Python開発者とc / c ++開発者の一部が会議に参加することを本当に望んでいます。

時間を割いて私と話してくれてありがとうスティーブン！
このコミュニティとの関わりは本当に励みになり、私は楽しんでいます
vscode開発に続いて！

2016年4月6日19：41、Michael Wallace Louwrens < [email protected]

書きました：

他の人のせいで打ち合わせができない私たちにとってはとても助かります
フィードバックを提供できるようにするというコミットメント。
たぶん、初日に会議が終わったら、ビデオを投稿してください
他の人が表示およびコメントできる会議（関係者全員の許可を得て）
会議の残り時間内に？

明らかにそれは長い期間ではありえませんが、より多くのフィードバックが害になることはありません
うまくいけば、いくつかの異なる視点が追加されました。

私は本当にいくつかのPython開発者とc / c ++開発者が会議に参加することを望んでいます
彼らのワークフローはJavaScript開発者のワークフローとは異なります

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

@TurkeyManに感謝し

参加できなかった方は定期的に運営しておりますので、後日参加する機会もございます。

今週の会話はすべて1対1の会話で、その間に各個人が経験した問題の詳細について話し合います。 これにより、解決する必要のある問題をより深く理解することができます。

設計モックアップをレビューする次の週には、グループディスカッションと1対1ディスカッションを行う方法を探します。 また、後で会議のビデオを録画して投稿する方法についても検討します。

@stevenclは、参加できないがフィードバックの提供に関心がある私たちのために、セッションの要約（またはさらに良いことに録音）を投稿することができます。

+1
7:36ピーター・ペトロフの水、2016年4月6日には[email protected]
書きました：

@stevenclhttps ：//github.com/stevencl要約を投稿することは可能ですか
できない私たちのためのセッション（またはさらに良いことに、録音）の
参加しますが、フィードバックの提供に引き続き関心があります。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

コードエディタ内でのファイルナビゲーションへの期待を少しでも取り入れたいと思います。 私は何週間もVScodeに慣れて、Sublimeに戻り続けようとしています。 これが私が期待することです：

1. マウスレスナビゲーション
2. 開いているファイルのセット内を前後に移動する機能
3. 簡単にファイルを閉じる

これまでのところ、残念ながらVScodeは3つすべてで失敗することがわかりました。 ファイルを閉じると、実際には閉じず、単に編集できなくなるため、ワークスペースは直感的ではありません。 ファイルを閉じることは、作業中のファイルのセットからファイルを削除するという精神的な活動です。

VScodeでは、_頭の中で_開いているファイル内を移動すると、以前は捨てられていたと思っていた「ゴミ」に遭遇し続けます。 これは非常に気が散り、ワークスペースで20のファイルが開かれ、最終的にはそれを追跡できなくなり、すべてを閉じるだけになります。

キーボードを使用して、開いているファイルをすばやく切り替えることができません。ファイルは、_頭の中で_リンクリストを形成します。 それらを開く順序は、閉じる順序と同じくらい重要です。そのリストでファイル名を1つずつ読み取ってから、どのファイル名にタブを付けるかを判断する必要があるため、Ctrl + Tabは役に立たないことがわかります。 フラッシュ中にコンテンツを認識するか、目的のファイルが「リスト」のどこにあるかを知るだけで、開いている5〜8個のファイルを適切なファイルにすばやく切り替えることができます。

それが理にかなっていることを願っています。 私はワークフローを可能な限り最適化し、キーボードを使用し、マウスを使用しないようにしています。これは、すべてが大幅に遅くなるためです。 VScodeでは、他のエディター（textmate、vim、sublime、flash、eclipseなど）よりもこれに苦労しています。

繰り返しになりますが、今週行われる会議の記録は利用できません。各会議は1対1の会話であり、各人が作業方法の詳細とVSCodeで発生する特定の問題について話し合うためです。 これらの会話の間、私たちはどんなデザインについても詳細には立ち入りません。

ただし、その後の数週間は、VS Codeでのドキュメント管理を改善するための設計について話し合う会議を記録し、利用できるようにする機会を探します。 来週のいつか、次のデザインディスカッションに参加するための別の招待状を探してください。

すべてのフィードバックと、VSCodeがどのように機能するかまたは機能しないかの詳細に感謝します。

誰もそれについて言及していないようで、私はこれについて一人ではないと思うからです。私にとって、エディターのタブはすべて空間記憶に関するものです。つまり、私はどこにいて、私の周りのものはどこにあるのでしょうか。

私たちは現実の世界に住んでいます。 私たちは自分の周りの空間を理解して直感的に理解するように進化し、考えずにそれを行います。 これが、キーボードを見ずに入力できる理由です。キーがどこにあるかを「知っている」だけで、すばやく入力できます。 タブを使用すると、私たちが生まれたデフォルトの問題のウェットウェアを起動でき、ファイルが画面の「どこ」にあるかがわかり、日常的に使用する本能のため、考えずにファイルに焦点を合わせることができます。 エディターのタブを介して「ファイルを置く」ので、次にチャンネルを変更する必要があるときにテレビのリモコンを置いた場所を思い出すのとまったく同じ方法で「ファイルを置いた場所」を思い出すことができます（私はもうテレビを持っていたと仮定して）

私にとって、時間順に並べられたファイル履歴は、この直感的な空間の理解に完全に反します。 「main.java」またはキーボードのTキーが特定の位置にあることがわかっている場合は、物理的および意図的に移動しない限り、移動させたくありません。 それが自然に動くなら、私は立ち止まって考え、それを見つける必要があります。 自分で家の中を動き回る車輪付きのテレビのリモコンや、各文字を最近使用した頻度に基づいてキーを再配置したキーボードを想像してみてください。 それは混乱だろう！ :-)

私はVSCodeが本当に好きですが、タブがないために個人的にイライラして遅くなっています。 良い仕事を続けてください-私はあなたが思いついたものを見るのを楽しみにしています！

@ matt1
あなたが説明しているのは、まさにタブを非常に制限するものです（私にとって）。 タブは、物理ファイルキャビネット内のファイルに配置される物理タブのメタファーであり、すべて同じ制限があります。 自分で並べ替えて表示可能なタブの限られたスペースを管理する必要がある物理的なものよりも、いくつかのキーを入力して情報にジャンプできる自動化されたファイルキャビネットが必要です。

私は興味があります-マウス/トラックパッドを使用してタブをナビゲートしますか、それとも他のエディターでキーの組み合わせを使用しますか？
キーボードショートカットを排他的に使用している場合は、おそらく私が知らないタブワークフローがいくつかあります
のと私はそれを見たいです。 しかし、多くの人がマウス/トラックパッドを使用しているのではないかと思います。コンテキストスイッチがどれほど非生産的であり、キーから手を離すのがどれほど遅くなっているのかを理解していません。 習得と理解は簡単ですが、キーの組み合わせを使用するよりも強力で生産的ではありません。 マウスで「タブに手を伸ばす」ことに気付いた場合、それは直感的であり、空間感覚を利用している可能性がありますが、速度が低下しています。 物理的な動きに失われる時間はそれほど多くありませんが、コンテキストスイッチ自体です。

これらは私の意見であり、ほとんどの人が同意しないことを理解していますが、それはVisual Studio_Code_です。 コーダー/開発者向け。 そして、開発者はずっと前に、ほとんどの（すべてではない）ものに対してシェル> guiであり、デスクトップの比喩は習得は簡単ですが、かなり制限されていることに気づきました。

では、「タブなしでは生きていけない」と言っている人が、他のワークフローを検討していない可能性はありますか？ もしそうなら、見返りがあなたの生産性を向上させるのであれば、それを試す価値はありませんか？

タブなしで作業しようとして、タブを適応させることができない、またはタブが生産性を高めると正直に感じることができない人にとって、これは単なる正直な意見の相違であると認めることができます。 しかし、「彼らは30年間働いてきた」という理由で、物理的な比喩を主張する人々には。 本当に_another_TextMate / Sublime / Atomが必要ですか？ 封筒を動かそうとすべきではありませんか？

私がここで少数派にいることは間違いありません（しかし、それは私を誤解させません）ので、これが私がするつもりの最後のコメントです。 気軽に積み上げてください:)

VS Codeをチェックして、Sublimeの無料の代替品になるかどうかを確認することにしましたが、タブ付きのドキュメントがなければ、初心者ではありません。 VS Codeを単一インスタンスで設定し、複数のドキュメントを開いて、それらを簡単に切り替えることができることは、テキストエディタの基本的な要件です。 Explorerを開いたままにしておくことは回避策ですが、VS、ブラウザ、Sublimeなどのように上部のタブの代わりに左側のタブを使用するのは不自然ではありません。Ctrl-Tabにはいくつかの問題があります。1つはキーボードを見て手を動かさなければならないことです。 （マウス以外の場合）もう1つは、直感的ではないということです。 タブのないエディターがBloatedNotepad以上のものであると示唆する人は、コンパイラー入力として複数のファイルを含むものをデバッガーがステップスルーするときに必要となるような、複数のドキュメントの本格的な編集を行ったことがないことは明らかです。

@indiejames
タブは私にとって生産性に関するものではありません。 その認知について。

私は個人的に、生のタイピング速度が私の生産性の制限要因であったことを知りませんでした。 プログラミングには思考と考慮が必要です。私たちが_思考_に費やす時間を考えると、数回のクリックは私にとって物事の壮大な計画では問題ではありません。

@indiejames ctrl +（shift +）tabを使用して、必ずしもマウスではなく、タブ間を移動します。 作業ファイルに関する私の最大の不満の1つは、 @ matt1と同じです。つまり、ctrl + tabが最近使用された順序で動作するという事実です。 最後と最後から2番目に見たファイルを必ずしも覚えているわけではありませんが、ファイルを開いた/配置した順序を確認/記憶するのは非常に簡単です。SublimeTextは、デフォルトでctrl +（shift +）tabをMRUに設定します。注文; MRUと表示順序の両方のコマンドがあるため、常に変更します。

当時、一部のWebブラウザー（おそらくOperaが事前に点滅していましたか？）がデフォルトでctrl + tabにMRUを使用していたことを覚えています。おそらく、OSがアプリに対してそれを行うので、ブラウザーもそれを行う可能性があると考えています。 しかし、それはひどく直感的ではないことがわかり、実際に切り替えたいものを見つけるために特別な注意を払う必要がありました...これにより、プロセスが_遅くなります_。

クイックオープンを排他的に使用するという議論は、作業ファイルを使用するVS Codeの場合と同様に、タブを使用するSublimeTextでも同様に機能します。 タブはそのワークフローをまったく禁止しません。

VS Codeの現在の作業ファイルアプローチを好む人にとって、次のワークフローではなく、実際に作業ファイルのリスト内のファイルをクリックすることを好む人はどれくらいいますか？

• Ctrl + E / ⌘ + Eを使用して、最近のファイルをすばやく開きます。
• Ctrl + Tabを使用して最近のファイルを切り替える

ちなみに、タブを好む人にとっては、

@ bgashler1
私はキーボードショートカットが好きです。 そうではありませんが、私は最速のタイピストになることができますが、マウス/トラックパッドを動かすよりも気が散らないことがわかったためです。

「作業ファイルとタブなし」の群集の多くが欠落しているのは、私たちの多くがタブを使用する方法だと思います。 たとえば、MVCアプリケーション（Web、モバイル、またはデスクトップ）で作業する場合、モデルファイル、ビューファイル、コントローラーファイルの特定の順序で1つ以上の垂直ペイン（VSCodeも必要）にタブが表示される傾向があります。 。 したがって、私が頻繁に開くセットアップは次のようになります。

左ペイン

モデル1ファイル（タブ）| 1つのファイルを表示（タブ）| コントローラ1ファイル（タブ）

右ペイン

モデル2ファイル（タブ）| 2ファイルを表示（タブ）| コントローラ2ファイル（タブ）

この設定により、比較のために作業している両方のコンポーネントのモデルファイルをすばやく選択したり、UI / UXハットをオンにしたときにファイルを表示したりできます。 これは、特に他のファイル（CSS、dbスクリプトなど）も開いている場合は、作業ファイルでは効率的に実行できません。 私は大量のUI / UXを行っていますが、これははるかに一般的な方法です。 私が厳密にJavaバックエンド開発者またはDBAであった場合、いいえ、これは要件ではありません。 しかし、私たちの大多数のフルスタックWebおよびモバイル開発者にとって、タブ（およびタブ付きの垂直/水平ペイン）がないことは極端な障害です。 短期的にはVSCodeの期限を迎えていますが、この機能が不足しているため、深刻な懸念を抱いています。 タブが役に立たず、作業ファイルリストが革新的ではないことを誰も私たちに納得させることはできません（Adobe Bracketsにも作業ファイルリストがあり、2012年から存在しています）。

繰り返しますが、これはオールオアナッシングの問題ではありません。 デフォルトでオフになっている場合でも、オプションとして他のエディターに存在するのと同じ機能を要求しているだけです。 VSCodeがAtomとまったく同じようにタブ/ウィンドウペインを実装する場合、タブ関連のグリップの99.99％を解決します。 実装するのは簡単な作業ではないことはわかっていますが、この機能がバックログに残るのではなく、正しく実行されるまでもう少し長く（数年ではなく数か月）待つことに満足していると思います。

ちょうど私の2¢...

私はこれのほとんどをすでに@ bgashler1に伝えましたが、私にとって理想的な振る舞いを説明するためにここに少し書きます。

1. キーバインディングは、作業ファイルを閉じて、作業ファイルリストとMRU（最近使用された）スタックから削除する必要があります。 これを実現するために、次のキーバインドがあります。

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

1. エディター内のファイルは「スタック」する必要があります。これにより、1つのファイルを閉じると、MRUスタックの最後のファイルが表示されます。
2. ctrl + shift + tは、最後に閉じたタブを復元する必要があります。 このキーバインディングはvscodeのworkbench.action.tasks.testと競合しますが、タブ付き環境では非常に標準的なホットキーです。 ここでコマンドの機能リクエストを作成しましたhttps://github.com/Microsoft/vscode/issues/3989
3. ctrl + tabおよびctrl + shift + tabは、「プレビュー」されたファイルではなく、「作業ファイル」リスト内のファイルのみを回転する必要があります（エクスプローラーをシングルクリックしてから移動します）。
4. 作業ファイルをエディターの上部に配置したい。 この理由は次のとおりです。
   
   
   
   • 開いているサイドバーに関係なく、作業ファイルを視覚的に確認できるようにしたい。 関連： https ：
   
   
   • 20年近くにわたってプログラミングを行ってきましたが、エディターの上で作業ファイルを探していました。 壊すのは難しい習慣です。
   
   

@bpasero

ちなみに、タブを好む人にとっては、タブを製品に追加することを検討しているので、フィードバックは非常に役に立ちました。 共有し続けてくれてありがとう！

VSCodeではCtrl + Tabを頻繁に使用しますが、ファイルの他にUIの他の部分に移動したり、パッケージコンソールマネージャーに移動したりできるため、VisualStudioのエクスペリエンスは非常に優れていると思います。ソリューションエクスプローラーなど...

@Tyriar素晴らしいポイント！

【哲学警告！】

ctrl+tab 、現状の「作業ファイル」の概念よりもはるかに便利なのはなぜですか？ これが重要な質問です。 個人的には、2つの問題があると思います。

まず、 ctrl+tabはキーボードショートカットであり、キーボードショートカットは無意識のうちにキャレットに関連付けられています-ユーザーは、 ctrl+tabが現在のエディターで、キャレットが現在配置されているファイルを変更することを期待しています。正確にそれが何をするか。 これは、特定のエディターに関連付けられていない「作業ファイル」やナビゲーターとは異なり、1つを除くすべてのエディターから水平方向に離れており、_最新の_エディターに関連付けられています。通常はマウスで使用されます。 キーボードで使用しても、ファイルを選択するまでにキャレットから離れています。

次に、 ctrl+tabは、最近見たファイルを新しいものから順に表示します。 「作業ファイル」には、ダブルクリックまたは変更を加えたファイルのみが表示され、わざわざ開いた順序で表示されます。 基準と順序は任意であり、プログラマーの考え方とは関係ありません。呼び出し元と関数、クラスとコンシューマーの間を行き来します。

（意見。マイレージは異なる場合があります。）

編集：私のポイントはこれです：1つの機能が機能する理由と機能しない理由を理解することは、機能を修正するか、より良い機能を設計するのに役立ちます。 現状では、作業ファイルはそうではありません。

@Tyriar ：個人的には、シングルクリックしたファイルが作業ファイルに表示されないという事実は本当に嫌いです。 最近使用したスタックで見たすべてのファイルが必要です。読み取り専用の外部ファイルも必要です。 理由で開けました。 私がそれらを使い終わったら、それらはすぐにリストから消えてしまいます。 せいぜい、シングルクリックとダブルクリックを同じように動作させるオプションがあるはずです。

私は、この問題の文脈で、私が崇高なものから欠けていたもののほとんどを取得する方法を理解しました：

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

@stephenmartindale誰かが「プレビューファイル」を無効にする機能リクエストをまだ行ったかどうかは

@stephenmartindaleは、読み取り専用ファイルを含め、「プレビューファイル」を固定して開いたままにする方法を検討しています。

多くの場合、ユーザーは複数のファイルを開くまで、探しているファイルがわからないため、「プレビューファイル」を保持したいと思います（これにより、関係のない開いているファイルの数が望ましくなくなる可能性があります）。

ここでのSublimeの流れが大好きです。 シングルクリックでファイルにジャンプし、
ダブルクリックすると開いたままになります。
午前11時49分AMブラッドGashlerで土、2016年4月9日には[email protected]
書きました：

@stephenmartindalehttps ：//github.com/stephenmartindale私たちが探している
「プレビューファイル」を固定して開いたままにする方法に。

多くの人が知らないので、「プレビューファイル」を保持したいと思います。
いくつか開くまで、どのファイルを探しているか（
望ましくない量の開いているファイルが乱雑になります）。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

@Tyriar、@ bgashler1、@stevencl私はそれがフィードバックを収集するには、タブや作業ファイル用の2件の新しい記事を持っている方が良いと思います。

私の意見ですが、ここで両方の機能について説明するよりもはるかに良いと思います。これは十分な長さです。 :)

👎これを行わないでください。少なくともオプションにしてください。 クリーンなタブフリーUIは、VSコードで最も気に入っているものの1つです。

@tobicoそれは全部か

次に、Ctrl + Wで現在のエディターだけでなく、対応する開いている作業ファイルも閉じる必要があります。 私にとって、それは現在の実装における最大の欠点です。 それと、Ctrl + Tabで、作業ファイル内のファイルだけでなく、最近のすべてのファイルが一覧表示されるという事実。 考え直してみると、3つ目の注意点は、シングルクリックではファイルが作業ファイルとして開かないが、編集すると開くということです。

+1

@csholmqこれを今すぐ実行できます。https： //github.com/Microsoft/vscode/issues/224#issuecomment-207507479のカスタムキーバインディングを参照して

@Tyriarそれは私の警告のほとんどすべてに対処します。 ありがとう！

3分以内に、VS Codeの使用を停止し、Atomに戻りました。 タブも行きません。 申し訳ありませんが、私のワークフローは私に掘り下げられました。 4年前の簡単な世論調査では、UIの回答がはるかに速くなったに違いありません。 しかし、壊れていないものを修正するには、Microsoftの傲慢さも残してください。

@zunamaタブと改善されたドキュメント管理を必要としているユーザーのことを忘れていません。 1.0になった今、これらの懸念に対処することは私たちの最優先事項の1つです。 すぐに素晴らしいことがVSCodeに登場します。

Web開発者として、タブは私にとって重要です。 デスクトッププログラマー（一度に主に単一のファイルに焦点を合わせる）とは異なり、私たちは常にウィンドウとマウスの使用を同時に切り替えます（たとえば、Photoshopから画像をスライスし、すぐにエディターに戻ります。またはブラウザーでデバッグして、別のファイルに戻って修正します）。 タブを使用すると、ターゲットファイルにすばやく移動できます。 ショートカットを使用すると、さらに2つのステップがあります。 サイドバーの「作業ファイル」を使用すると、メインコード領域のスペースが少なくなります（Photoshopとエディターまたはブラウザーを並べて配置するため）。 エディターのHeightはそれほど必要ありません。 いつでもあと数行覚えることができますね。

また、トップタブは人間の目に適しています。 トップタブのタイトルとメインの市外局番を同時にスキャンできます。 しかし、メインコードと一緒に左のworking filesを読むことはできません。 自分で試してみてください。 さらに、タブは幅が広く、マウスの動きに適しています。 （あなたがそれに焦点を合わせなくても、それはより予測可能です）

+1/0

+1

私の個人的な意見ですが、-1、+ 1の投稿はやめてください...この機能が好きか嫌いかを提案する以外に、リアクション/絵文字を使用できるものは、あなたの経験について何も述べていません。すでに投稿を書いている場合は、それが役立つことを確認してください！ あなたは物事とそれらをどのように機能させたいかについてあなた自身の防腐剤を持っていると確信しています！ それ以外の場合は、絵文字を使用してください。

メタ：
@eyalskこの例では、議論が進行中であるため、実際には冗長に見えます。 しかし、あなたが牽引力を得たい問題については、本当に「あなたの反応を追加する」は同等ですか？ それは、問題がホットトピックであることを示すのではなく、コメント操作に警告するだけではありませんか？ つまり、問題にタグ付けされている開発者に警告しますか、それとも問題を変更済みとして設定しますか？

@csholmq正しく表示されているかどうかはわかりませんが、リアクション/絵文字ではなく、+ 1、-1しか含まれていない投稿を参照していました。値が追加されないため、より意味のある入力が可能です。 + 1、-1 ...で投稿を書く代わりに書かれています。私の意見ですが、これを変更して、投稿で強調します。

@zunamaより良い代替案を探すのは傲慢ではありません。 「壊れていない」というのは、新しいものを探すことに反対する有効な議論ではありません。 それはほとんどそれに対する議論です（多分もっと良いものがありますか？）。 このディスカッションで気づいたのですが、 VS Codeを今日完全に使用したい場合は、現在の「古い考え方」のユーザーベースを満足させ、後で革新することを目指す必要があります。 人々は待つのがあまり得意ではなく、なぜこれまたはそれが優れているのかを議論しようとする時間を節約できるからです。

コメントに戻る：何か正しいことをしたいのなら、3分もかからずにやめます。 あなたは有用な批評についてのあなたの見解を列挙し、可能な改善を探します。 3分の視点は、偏っているため、デザインにとって役に立たず、危険です。

あなたが革新したいとき、世論調査は機能しません。 例：

これらのナビゲーションスタイルのうち、あなたにとって最も生産的なものはどれですか？

• 何か。 （もっと良いかもしれない何か新しいことを試してください）
• タブ。 （あなたが愛することを学んだ古き良きワークスタイル）。

もちろん、タブが勝ちます。 しかし、おそらく他のアイデアが新しい標準ナビゲーションUIへの道を開く可能性があります。

正直なところ、私にとってVS Codeの特徴の1つは、タブがないことでした。 私は（最初は）彼らが行方不明であることにさえ気づいていませんでした！ とても興味深い視点でした。

タブを使用するときはいつでも、タブが散らかって見つけられなくなります。 タブのリストに特定のファイルがすぐに表示されない場合、最初の反応はそのファイルを再度開くことです。 。 。 そして、それがすでに開かれていることがわかりました。 もちろん、タブの順序はその過程でひどく混乱します。 これは、Visual Studio2015で私に起こることです。

すべてが同じである世界では、アイデンティティを持っていることはさわやかです。

PS。 ただし、作業ファイルのセクションにはあまり感心していません。 私は主に、保存が必要なファイルをすばやく表示するために使用します。

PSS。 アイデア-ある日vscodeにタブがある場合、開くタブの最大数を制限するのが最善かもしれません。つまり、新しいタブが開かれたときに最も古いタブを自動的に閉じますか？

@RussBazタブの数は

tabs.autoClose = "not-visible"、 "off"、 "time"、xここで、xは数値です

それは奇妙な考えです。 私が16個のタブが好きで、4個が好きなら、それは簡単です。 あなたは4つのタブを使用し、私は16を使用します！ なぜあなたのやり方は私のやり方よりも優れている、またはその逆だと言うのですか。 とにかくこれは何ですか？ [オプション] / [設定]でタブがアクティブ化/非アクティブ化されている限り、タブに関する会話でさえ意味がありません。 タブが欲しくない人、素晴らしい！ それらが欲しい人は、小さなチェックボックスをチェックしてください！ 本当に、あなたのやり方が私のものよりも優れている、または私があなたよりもよく知っているということである必要はありません。
+1
;）

ユースケースの例：私は現在、アトムで常に6つのタブを切り替えています。

より深いセクションで作業する必要がある場合、それは約10になります。 全部使ってます！ したがって、閉じて再度開くのは面倒です。 その場所に大量のファイルを配置することもできますが、モジュールのすべての部分を1つのファイルに含めると、ファイル内の6k行に膨れ上がるため、処理するのがはるかに困難になります。

@Measuring私はあなたに賛成と反対です。 革新が必要なものがありますが、最初に質問する必要があります。タブを削除することでワークフローを改善できるかどうか。 私にとって、開発に使用するすべてのエディターにはタブインターフェイスがあります。これは、開発者がファイルの正確な名前やファイルを開く順序を覚えていなくても、一度に5〜10個のファイルで作業するのが一般的だからです。私は尋ねなければなりません、この新しいインターフェースはどのようにそれをより良くしたのですか？ それはどのように革新的ですか？ 最初に、彼らがそれをどのように使用するかを尋ね、次に、どうすればそれをより良くすることができるかを尋ねます。

3分間の問題については、コードはSublime（私の好みの選択）またはAtom（私が試しているもの）とそれほど変わらないと思いますが、最初からそれを操作したり表示したりするのに苦労しています誰かがファイル間で何かを機能させるために必要なことを効率的に行ったら、今は自分のニーズに合ったものを使用し、準備ができたらコードをいくつかのバージョンで調べます。 それは「昔ながらの」考え方ではなく、私の仕事の効率です。

タブをタブなしに切り替えることを好む私たちに尋ねることは、同じくらい良いことです
タブを好まない人にタブに切り替えるように頼む。 私たち二人ともしたくない
他の方法に切り替えます。

「MacvsWindows」、「AndroidvsIPhone」タイプで停止できますか
どちらの方法が良いかについての議論：「タブvsタブなし」？ どちらも良いです
さまざまな人が自分の好みを持っています。

最善の解決策は、可能な設定としてタブを追加することだと思います
オプションで有効にします。 その後、両方の群衆が喜んでいます。

あなたがオンにすることができるオプションとして両方の方法を持つことに反対している人はいますか？
あなたの好みに応じてオフ？

私はそれがこれらの2つのオプションに帰着すると思います：

1）設定としてタブを追加します。 それが好きな人にはオン、好きな人にはオフ
しないでください。

2）タブをオフにするオプションがある場合でも、タブを追加しないでください。

オプション2を有効にするオプションがあるのに、なぜオプション2に投票するのでしょうか。
オフ？
2016年4月15日19:32、「JamesMcLaughlin」 [email protected]
書きました：

@Measuringhttps ：//github.com/Measuring私はあなたに同意します。
革新が必要なものがありますが、最初に尋ねなければならないのは何ですか
ワークフローについては、タブを削除することで改善できますか。 私にとっては、すべて
私が開発に使用する単一のエディターには、タブインターフェイスがあります。
開発者が一度に5〜10個のファイル間で動作するのは一般的です
ファイルの正確な名前やファイルを開く順序を覚えておく
それで、私は尋ねなければなりません、この新しいインターフェースはどのようにそれをより良くしたのですか？ どうですか
それは革新的ですか？ 最初に彼らがそれをどのように使用するかを尋ね、次に私がどのように作ることができるかを尋ねます
それはより良いです。 3分間の問題については、コードは
SublimeやAtomとそれほど違いはなく、最初から正しければI
それを使って作業したり、誰かに必要なことを効率的に示したりするのに苦労している
ファイル間で何かを機能させるには、機能するものを使用します
今の私のニーズにより良く、今後いくつかのバージョンのコードを調べてください
準備ができたら。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

@ tones411タブを追加すると作業ファイルの使用

_私はそれを十分に強調することはできません_しかし、私の意見では、議論は単にタブを追加してそれを1日と呼ぶことではなく、ワークフローを正しくすることであり、何度も言いました。つまり、カスタマイズのための適切なオプションが必要です。統合され、疎外されておらず、オプションであると感じるために！ 作業ファイルについても同じことが言えます。

一部の人々は、Vimバッファーのようなものを持ちたいと思うかもしれず、タブも作業ファイルもまったく持ちたくないかもしれません。

たぶん、VimバッファーのようなものをVSCodeのサーフェスとして使用して、コマンドを使用してファイルを管理し、その上に、タブ、作業ファイル、または明日の別のものなど、各ワークフローの基盤を築くことができます。

よく言われます。 これは宗教的な議論になりました。 これから明らかです
ここには情熱を持っている人がたくさんいる長い糸
タブを付けて、それらが必要であると信じる/ワークフローを容易にします。 がある
タブが必要であり、それらが障害であると信じていない他の人。

同意しないことに同意しましょう、それは問題ありません。 タブがオプションである限り
それらを望まない人よりもそれらを使用する必要はありません。

個人的には便利だと思いますが、誰かを止めるつもりはありません
それが彼らのために働くならば、働くファイルを使うことから。 それは私にはうまくいきません。
金、2016年4月15日には22:07でtones411 [email protected]書きました：

タブをタブなしに切り替えることを好む私たちに尋ねることは、同じくらい良いことです
タブを好まない人にタブに切り替えるように頼む。 私たち二人ともしたくない
他の方法に切り替えます。

「MacvsWindows」、「AndroidvsIPhone」タイプで停止できますか
どちらの方法が良いかについての議論：「タブvsタブなし」？ どちらも良いです
さまざまな人が自分の好みを持っています。

最善の解決策は、可能な設定としてタブを追加することだと思います
オプションで有効にします。 その後、両方の群衆が喜んでいます。

あなたがオンにすることができるオプションとして両方の方法を持つことに反対している人はいますか？
あなたの好みに応じてオフ？

私はそれがこれらの2つのオプションに帰着すると思います：

1）設定としてタブを追加します。 それが好きな人にはオン、好きな人にはオフ
しないでください。

2）タブをオフにするオプションがある場合でも、タブを追加しないでください。

オプション2を有効にするオプションがあるのに、なぜオプション2に投票するのでしょうか。
オフ？
2016年4月15日19:32、「JamesMcLaughlin」 [email protected]
書きました：

@Measuringhttps ：//github.com/Measuring私はあなたに同意します。
革新が必要なものがありますが、最初に尋ねなければならないのは何ですか
ワークフローについては、タブを削除することで改善できますか。 私にとっては、
すべて
私が開発に使用する単一のエディターには、タブインターフェイスがあります。
開発者が一度に5〜10個のファイル間で動作するのは一般的です
ファイルの正確な名前や開かれた順序を覚えている
それら
それで、私は尋ねなければなりません、この新しいインターフェースはどのようにそれをより良くしたのですか？ どうやって
です
それは革新的ですか？ 最初に、彼らはそれをどのように使用するかを尋ね、次に、どうすればよいかを尋ねます
作る
それはより良いです。 3分間の問題については、コードを想定します
です
SublimeやAtomとそれほど違いはなく、最初から正しい場合
私
それを使って作業したり、誰かに必要なことを効率的に示したりするのに苦労している
何かを機能させるためにファイル間で、それから私は何かを使用します
動作します
今の私のニーズにより良く、今後いくつかのバージョンのコードを調べてください
準備ができたら。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

+1

メインエディターとしてコードに切り替えてから、このスレッドをこの1か月ほどフォローしていて、ファイルナビゲーションの動作に常に悩まされています。 私は、作業ファイルのセクションに慣れるのに時間を費やしました。これは、多かれ少なかれ後から考えたものであり、Ctrl + Tab、およびCtrl + Pです。 私はコードに非常に満足しており、それは簡単に私のお気に入りのエディターですが、これらのファイルナビゲーションオプションはあまりにもよく考えられておらず、そもそもそれらがどのように考えられていたかを理解するのは難しいです。

これらのほとんどは言及されていますが、ここに私の不満があります：

エディターウィンドウを閉じても実際にはWFからファイルが閉じられないため、WFリストは基本的に役に立ちません。 実際にファイルを_2回_閉じ、マウスを使用して閉じる必要があります（Ctrl + W _and_ WFパネルからファイルを閉じます）。 ファイルを開いたままにしておきたい場合は、Ctrl + Wを押さなかったでしょう。Ctrl+ Wを押してファイルを「開いた」ままにしておく（WFに表示）のはどういう意味ですか。 はい、これは再割り当てできますが、WFのデフォルトの動作について話しています）。

WFまたはツリービューでファイルをクリックすると、少なくとも半分の時間、不要なエディタウィンドウでファイルが開きます。 左側のパネルがアクティブな2パネルのエディターがある場合、「横に開く」とすると、_new_パネルではなく、_right_パネルで開き、3列の場合は常に既存のパネルで開きます。 ここでの問題は、「私が置いた場所に物が留まらない」ということです。 現在のUI状態に基づいて物事をどこに置くべきかを編集者が決定し、アプリケーションの他の部分でUI状態が変化したときにそれらを変更するのではなく、物事をどこに置きたいかを編集者に伝えることを期待しています。 以前に開いたファイルに_戻る_ことはそのようなPITAです。

ファイルのシングルクリックとダブルクリックは、UIがまったく同じであると動作が完全に異なります。 シングルクリックでファイルプレビューが一時的に開きますが（後で削除するために2回閉じる必要があるため、WFにロードしたくない場合）、別のファイルで「プレビュー」エディターをロードします（前述の現在の実装では避けられません）上記）はフォルダツリーを新しい場所にジャンプし、前の「プレビュー」ファイルをロードすると、ツリービューでフォルダに再度移動する必要があります。 この動作のために、_まったく同じフォルダ_に6回続けて移動するのにどれだけの時間を費やしたかを認めたくありません。

私の意見では、ファイルをシングルクリックまたはダブルクリックすると_まったく同じ動作_が得られるはずですが、WF / Ctrl + Tabに表示されないシングルクリックの「プレビュー」が本当に必要な場合は、_明らかなUIマーカー_が必要です。アクティブなエディタウィンドウはプレビューであり、置き換えると消えます。

フォルダツリーは、クリックしたすべてのファイルの場所にジャンプしないか、デバッグ中はライブラリフォルダ内のすべてのフォルダをジャンプする必要があります。 特定のフォルダに移動したい場合は、そのフォルダに移動します。移動したら、そのフォルダはそのままであると思います。 これは、タブスレッドではそれほど関連性がないように見えるかもしれませんが、実際には関連性があります。

これらの絶対にばかげたエディターパネル、WF、およびフォルダービューの動作が存在する唯一の理由は、_タブがないため_です。 タブを追加し（エディターパネルが分割されている場合は特定のパネルにドッキングされます）、デフォルトで_常にすべてを新しいタブで開く_という通常のエディターの動作に設定されている場合、その動作は必要ありません。 ツリーをナビゲートする方法とタブを積み重ねる方法を決めて、「より良い方法」を見せようとするのをやめましょう（実際に、より良い方法がない限り、毎日6か月の作業を行った後、次のことができます）。現在の方法は私にとっては良くないことを絶対に確信して言ってください）。

あなたはそれでいる間や、神の愛のために、私は複数のウィンドウで同じディレクトリからファイルを表示させてください！ 他のすべてのタブベースのソフトウェアが何年もの間持っていたシンプルでエレガントなソリューションがあります-タブを新しいウィンドウにドラッグします-真剣にこれは革命的なものではありません。 「1つのフォルダーは1つのインスタンスのみを取得する」動作を維持する場合は、パネルを新しいウィンドウにフロートさせます（メインウィンドウによって制御/接続されたままです）。

あなたたちはこのエディターで素晴らしい仕事をしました、そして私はそれを使い続けます。 私たちが見ることができる場合：

1. タブ
2. WFを無効にする
3. フォルダツリーの自動ナビゲートを停止します
4. タブをフローティングエディターパネルにリッピングします（メインインターフェイスの他のエディターパネルとすべて同じ動作を共有します）

それなら、VSCodeははるかに遠くまで行くと思います。 素晴らしい編集者であり、残りの部分を活用するために欠点を我慢したいと思っていますが、他の多くの人がこれらのいくつかの基本的な機能を待っています。

UI / UXテスト、またはユーザーフィードバック/入力のために行うことは何でもお手伝いしたいと思います。 私が奉仕できるかどうか教えてください。

ありがとうございました！

@anyongあなたの洞察に感謝します！

ポイント3については、知っているかどうかはわかりませんが、現在これをカスタマイズすることもできます。

"explorer.autoReveal": false

workbench.files.action.showActiveFileInExplorerもバインドするので、必要に応じてエクスプローラーでランダムなファイルにアクセスできます。

@Tyriarどのバージョンを参照しているかは情報を

：+1：

：+1：

@bpaseroタブの長所/短所に関するこのボードの最初のいくつかのメッセージを読みました。 また、MSFTチームのスタンスも理解しています。チームは同じコーディングスタイルで団結し、 ctrl+tabや作業ファイルセクションに関して同じ反射神経のセットを開発しました。 それは良いことです。 一般的に、すべてのチームメンバーは物事の流れが均一です。 しかし、私たちはそのチームの一員ではなく、同じ反射神経のセットを開発したいとも思っていません。 私たちの既存の反射神経は、理想的には、強制的に排除されて置き換えられるのではなく、満たされるべきです。 エディターはユーザーを支援する必要があります。

UXの定義に適応するか、VSCodeの使用を停止する必要があります。 適応するものもあれば、適応しないものもあります。 テーブルに置かれる良いものと悪いもののバランスがすべてです。 そうは言っても、MSFTチームはタブの重要性を大幅に過小評価しており、社内で開発された反射神経を大幅に過大評価していると思います。

チームと担当者は、本当に1つの簡単な決定を下す必要があります。VSCodeはヒューマンコンピューターインタラクションの実験なのか、それとも_開発者が望むものを提供

@Tyriar ：v.1.0.0-insiderでautoReveal設定を試しましたが、私にも何もしませんでした。 エクスプローラーは、私が望まないときでもジャンプします。最も苛立たしいのは、go-to-definitionを使用して別の場所に完全にスクロールし、別のファイルを開くときです。

これは私が私の設定ファイルに入れたものです： "explorer.autoReveal": false,

@anyong @stephenmartindaleそうですね、この設定がどれほど新しいかわかりませんでした。 次のInsiderビルドで利用できるようになるはずです。

よく言った@stephenmartindale。 タブがない場合は、独自のバージョンのAlt-Tabを備えたnotepad.exeだけです（上記で何度も述べたように、壊れています）。 「WorkingFiles」をサイドタブのように使用しようとしていますが、1週間後には、Sublimeに戻る準備がほぼ整いました。特に、サイドバーを常に表示する方法がないという問題があります。アプリで他に何が起こっているかは関係ありません。 「VisualStudio ...」という名前で、少なくともVisual Studioエディターの基本機能（タブ、およびそれらのタブを独自のウィンドウにドラッグする機能）を期待していました。 なぜ彼らがその機能を削除したのかは説明できません。 たぶん、数か月後にもう一度チェックして、ビルドにプレアルファタグを付けるのに十分な距離に達しているかどうかを確認します。 今のところ、これはUIの実験にすぎません。唯一の問題は、すでに失敗しているのか、それとも失敗の危機に瀕しているのかということです。

これまでの259件のコメントのほとんどが述べているように、Sublime Textでの操作と同様に、VSCodeでタブを表示したいと思います。 私も、この1つの不足している機能がなければ、喜んで切り替えます。 奇妙に聞こえるかもしれませんが、同じウィンドウで少なくとも4つのドキュメントを開いて、それらをすばやく切り替えることができるようにする必要があります。

ああ、MicrosoftがVSCodeをSublimeTextとあまり比較したくないのであれば、見た目も動作もそれに似た製品を作るべきではありませんでした。 タブをGUIから遠ざけることは、SublimeTextとの比較を思いとどまらせる方法ではありません。 これは、これらの比較をMicrosoftにとって不利にする方法です。

@SturmB Sublimeは存在する唯一のエディターではなく、AtomがSublimeではないのと同じように、VSCodeをさらに別のSublimeコピーキャットにしたとは思いませんが、すべてのエディターが機能を共有しています。これは良いことです。 ！

VSCodeは非常に異なるため、Sublimeのようには機能しません。VSCodeはコードエディターとIDEの中間を目指していますが、Sublimeはその主張をしていません。そのため、VSCodeには、さまざまな人々のより多くの人々がいます。 Vim to VisualStudioを使用します。

タブの追加はまったく問題ではありません。人々はタブを追加する必要があると言い続けています。今ではタブが重要であることを理解していると確信していますが、本当の問題はデザインを正しくし、エクスペリエンスが素晴らしいと感じられるようにすることです。みんな、タブが好きな人と嫌いな人。

さて、機能、特にエディターでのエクスペリエンスの中核となる機能を設計するとき、いくつかのことをハックしてまとめて、数日後に多くの人ががっかりするという発表を返すことはできません。 良いことには時間がかかります！ これも違いはありません。 :)

私は作業ファイルの概念が好きです。 多くのファイルが開いていると、タブは適切に拡大縮小されません。 何が起こっても、作業ファイルを管理し続けてください！

@helmbold私は本当に興味があります-_どのように_それらを効率的に使用しますか？ 私は_試してみました_が、WFという混乱を理解する方法がわかりません。 （また、この問題のどこかで、チームは、作業ファイルは実際には単なる後付けであり、計画された機能ではないと述べました。）

@eyalsk ：

本当の問題は、デザインを正しくし、タブが好きな人も嫌いな人も、誰にとっても素晴らしい体験ができるようにすることです。

ここのほとんどの人は、まさにこの理由でタブが設定によって制御されることを望んでいると言っています。 そうは言っても、数年前のタブの初期の反復中の一部のソフトウェアは使い勝手がよくありませんでしたが、最近では通常はかなり良いものです。 コードには、Sublime、Atom、およびタブを「正しく」作成するために探すブラウザーなどの非エディターがあります。

タブ付きソフトウェアでは見たことがなく、「タブが多すぎる」という問題を軽減できると思う機能の1つは、複数のタブを選択して新しいウィンドウにドラッグする方法です。

結局のところ、長く似た名前の何百ものファイルを管理するためのヒューマンコンピュータインターフェイスは常に不足しているでしょう-それは私たちが働くように設計されている方法ではなく、それは私たちが働くことを余儀なくされている方法ですソフトウェア工学の現状。

@anyong確かに！ オプションの追加はまったく問題ではありません。つまり、どのオプションが冗長で、どのオプションが実際に役立つかを自問するときに問題が発生します。最初からタブを念頭に置いて設計されたプログラムは、複数のユーザーにとって非常に簡単です。理由はありますが、主にタブは後付けではないため、また、ナビゲーションストーリーがプログラムごとに一般的に異なるため、あるエディタを別のエディタと比較したり、タブを備えた別のプログラムと比較したりすることはできません。異なるプログラムは、異なることに焦点を当てることを目的としています。物事。

Sublime / Atomまたは別のプログラムにタブがあり、それがうまく機能するからといって、そこで機能するすべてのものを取り込んでプログラムに組み込むことができるとは限りません。それは、物事がどのように機能するかではなく、実際、物事が失敗する可能性がある方法です。 パッケージ全体が成功するので、そこで成功します。

さて、エディターに新しい種類のユーザーエクスペリエンスを追加するには、「作業ファイル」などの既存の機能を含むナビゲーションストーリー全体を再評価する必要があります。特に、各ユーザーが選択したエディターのように機能することを期待している既存の消費者がいる場合はそうです。そして、あなたはそれらの多くがそれがどのように働くべきかについて高い基準を持っていることを投稿から知ることができます。 :)

：+1：

@ bpasero 、 @ bgashler1と私は、ドキュメント管理を改善するためのUXデザインに取り組み始めました。 私たちはこの問題に関するすべてのフィードバックを注意深く監視しており、あなた自身のユニークな経験と視点についての詳細を知るために、すでに少数のあなたに話しかけています。

私たちは今、あなたのフィードバックを得るために私たちの初期のデザインをあなたと共有したいと思います。 4月21日木曜日の午後4時BSTにGoogleハングアウトを開催します。 参加したい場合は、その時点で次のリンクをクリックしてください： https ：

これは私たちの最初のパブリックデザインミーティングであり、私たちはそれを楽しみにしています。

私はVSCodeを排他的に使用していて（WebStormから来ました）、タブを見逃していません。 最初はそう思っていましたが、画面上で物事を配置したりグループ化したりする方法を考える必要がなく、より少ないスペースでより多くを見ることができたので、ワーキングファイルがより好きになりました。 現在、私は主にCTRL + TABを使用しています。

従来のタブは、公式の_extension_またはオプトインの_option_である必要があると思います。 個人的には、タブ以外のものが現在のエクスペリエンスを向上させることを望んでいます。

CTRL + TABに欠けているのは、アクティブなエディターペインのコンテキストです。 2つのエディターペインを並べて開いている場合、 CTRL + TABで、アプリケーション全体で開いているすべてのファイルではなく開いているファイルにフィルターされたファイル履歴を表示したいと思います（それはまだ存在する必要がありますが）。 また、エディタペインの上部にあるファイル名の上または近くのどこかをクリックすると、そのエディタペインで開いたファイルのドロップリストが表示される可能性があります（CTRL + TABと同じ）。

良い仕事を続けてください。

もう1つの提案..サイドバーが非表示になっている場合の作業ファイルのリストを表示するには、より適切なデフォルトのキーコンボがあると便利です。 私は最近、CTRL + K CTRL + Pが私が望むものを示していることを発見しましたが、CTRL + TABよりも引き上げるのが難しいです。 CTRL + TABで提案したように、[作業ファイル]ポップアップは、アクティブなエディターペインに基づくコンテキストの恩恵を受ける可能性があります。 アクティブなエディタペインで開かれた作業ファイルのリストが他のファイルの上に表示されるように並べ替えることができます。

@RyanEwenあなたは以前はショートカットユーザーではなかったと思いますか？ Intellij Ideaプラットフォームには同じショートカットがあり、タブをどこにでも配置できるため（上​​、下、左、右、なし）。 左/右に配置すると、VSCodeの作業ファイルと同様に機能します。 いくつかの実験をするのは素晴らしいことです。 CTRL + TABコンボとトップタブを使用してWebStormに戻り、必要がないか、または唯一の回避策として受け入れるように強制されているかどうかを確認します。 WebStormのCTRL + Eも、フィルタリング（検索するタイプ）機能を備えた最近のファイルです。

タブにノーと言った人は、ワークフローでマウスを使用していたかどうかについても言及してください。

：+1：

@KayLeungWebStormでCTRL + Eを使用しましたが、タブがあったので、マウスを使用してタブを頻繁に使用できるようにしました。 最近、VSCodeにアクセスできなかったときにタブ付きエディター（Koding.io）を使用しましたが、タブの設定/配置を見逃していないと内密に言うことができます。 ただ歴史を持っていることに比べて退屈なようです。 エディターを使用してファイルを切り替えるだけでなく、物事をどのようにレイアウトし、どのファイルを開くかを予測することに常に夢中になっていることに気づきました。 これはおそらく、タブの問題というよりも部分的に「私」の問題だと私は知っています。 少しOCDだと思います。

WebStormを使用したとき、私はネズミでした。 キーショートカットを使用して、最近の未開封のファイルをあちこちで検索しましたが、既に開いているファイルのタブに移動しました。 特定のタブに簡単に/直感的にキーボード操作できるとは感じませんでした。タブを配置したいという欲求があったため、最終的にはマウスに手を伸ばすことができました。 タブが不足していると、無意識のうちに（そして私の場合は痛みを伴わずに）キーボードファーストのワークフローに入ることができました。

Adobe Bracketsを試したところ、作業ファイルのリストがペインごとに分割されています。 左ペインと右ペインがある場合、VSCodeのように1つではなく、サイドバーに2つの作業ファイルのリスト（「左」と「右」）があります。 悪い解決策ではありません。 （アクティブなエディターペインに基づいてCTRL + TABにコンテキストを追加するという他の提案に加えて）そのようなことを気にしないでください。

@RyanEwenあなたは非常に良い点を述べました。 IDEの開いているインスタンスに対して常に2つのペインを使用します。 4つの開いているペインに対して、2つの画面に2つの開いているインスタンスがある場合があります。 私はそれに指を完全に置くことができませんでしたが、あなたはそうしました。 2つ（またはそれ以上？）の開いているペインがあるときに単一のリストがあるのは、現在の作業ファイルの実装の問題であり、私には使用できなくなっています。 ここで具体的にしていただきありがとうございます。

私たち（私自身、@ bpaseroと@ bgashler1）は、英国夏時間の午後4時に、タブと作業ファイルの最新のデザインを共有することをお知らせします。

午後4時BSTにこのリンクに参加してください： https ：

ハングアウトに参加することを計画していた人へのリマインダー-現在オンになっているので、上のリンクをクリックしてください。 これまでのところ5人までです。

本当にそこにいたかったのですが、午前11時で、仕事中に参加できません。 誰かが後で書面で共有するものがあると思いますか？ ：D

簡単な概要：

1. タブと作業ファイル（「オープンエディター」に名前が変更されました）はまったく同じように動作します。ビジュアルを上（タブ）にするか左（オープンエディター）にするかによって異なります。
2. タブは上部のパネルごとに視覚的にグループ化され、開いているエディターはヘッダー「左」、「右」の下にグループ化されます
3. ファイルをシングルクリックしてプレビュータブを開きます（または「エディターを開く」）。 ファイルをダブルクリックするか、ファイルを編集するか、タブ自体をダブルクリックして永続化します
4. 上記のオプションのいずれかを使用してデバッグ中のファイルを永続化しない限り、デバッガーはすべてのファイルをプレビューファイルとして開きます
5. タブ/開いているエディターはパネル間でドラッグできます
6. パネルをドラッグして、タブのグループ全体を移動できます

見た目はとても良く、個人的には（上記の私の投稿を読んだ場合は非常にプロタブグループから）、新しい「OpenEditors」に公正なショットを与えることができれば幸いです。

開発者のためのフォローアップの考え：

1. タブ/エディターを開くフローはまったく同じであるため、次のようなことができるはずです。エクスプローラーが開いているときに開いているエディターを表示し、エクスプローラーが閉じているときにタブを表示します。 コードの水平方向の領域を増やし、タブへのアクセスを維持できます。 タブの非表示/表示のショートカットがあると仮定すると、これはそれとCTRL + Bを同時に押すのと同じです-それが機能する場合、それは設定のオプションであるはずです： autoShowTabsWhenExplorerClosedか何か。 さらにタブを表示する必要がある場合は、シェブロンをクリックするか、Ctrlキーを押しながらBキーを押して左側のパネルにタブを表示します。 それが「混乱」するかどうかはわかりませんが、開いているエディターとタブが常にまったく同じで同じ順序である限り、非常にうまく機能すると想像できます。
2. 以前に閉じたタブがCTRL + Tab +何かビューの1つで利用可能であるとおっしゃったと思いますが、以前に閉じたタブを（次の順序で）単に再度開くCTRL + SHIFT + T（タブを閉じる）ショートカットについて考えましたかそれらは閉じられました）？

参加できたのはここ15分くらいでした。 録音されましたか？

私はタブが
デフォルトになります。 あなたが軽量を維持し続けることを願っています
VS Codeの環境と、プログレッシブワークフローの調査。

ありがとう、

ジェームズ

木曜、11時07 AMで2016年4月21日、anyongに[email protected]書きました：

ハングアウトに参加することを計画していた人へのリマインダー-今はそうです
上のリンクをクリックしてください。 これまでのところ5人までです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

良いアイデアがあったようですね。 これが実際に動作するのを楽しみにしています。

FWIW（そしてそれがまだ関連している場合）私はまだUIにタブを持たない方が良いと思います_デフォルトで_。 サイドバーが表示されていない場合、またはCTRL + TABをクリックしてファイルのリストを表示できる、すっきりとしたエディターヘッダーは、私が本当に望んでいるものです:)

本日はご参加いただき、フィードバックをいただきました皆様、ありがとうございました。 ここでメモを取り、GitHubの問題を継続的にフォローしています。 みんなの話を聞いています。

@indiejamesと@RyanEwenはい、メモを取りました。まもなく投稿します。 デフォルトの動作についてはまだ決定していません。 ただし、作業ファイル、タブ、またはその両方を使用するかどうかを簡単に選択できるソリューションを提案しています。

@ bgashler1あなたは、作業ファイル、タブ、またはその両方が必要かどうかを人々が選択できるソリューションを検討していると述べていますが、どれも必要ありませんか？ それはオプションですか？ 私が取り組んでいるプロジェクトと言語によって異なりますが、PowerShellのようなスクリプトには最適なものはありません。 :)

本日はお時間を割いてご意見をお寄せいただき、誠にありがとうございました。 @anyongは、私たちが提示した内容をすでに要約した素晴らしい仕事をしましたが、以下にいくつかの詳細といくつかのスクリーンショットを追加します。

ビジュアルデザイン

まず、この画像は、VSCodeでタブがどのように見えるかを示しています。

私たちは、軽量で邪魔にならない外観を目指しています。これは、VSCodeの他の部分とうまく調和するものです。 軽いテーマでどのように見えるかはまだ作成していません。

上の画像でわかるように、タブには名前の左側に閉じるボタンがあります。 ファイルに保存されていない変更が含まれている場合、閉じるボタンがある場所にダーティインジケーターが表示されます。

タブにカーソルを合わせると、タブ内のファイルのフルパスを含むツールチップが表示されます。

プレビュータブ

プレビュータブと開いているタブを明確に区別するために、次のワイヤーフレームのようにタブのタイトルをイタリック体で示しています。

プレビュータブを完全に開いたタブに昇格させるためのアクションについて説明しました。

• タブ内のコンテンツの編集
• エクスプローラーでファイルをダブルクリックする
• タブグループのプレビュータブをダブルクリックします

オーバーフロー

アクティブなタブの右側にタブが開きます。 タブグループ内のすべてのタブを表示するのに十分なスペースがない場合は、タブをオーバーフローさせます。 タブ内のファイルの名前を切り捨てて、タブを増やすためのスペースを増やすことはありません。

オーバーフローがあるときはいつでもシェブロンを表示します。 そのシェブロンをクリックすると、タブグループ内のすべてのタブを一覧表示するクイックオープンダイアログが表示され、ユーザーは表示したいタブを見つけることができます。

現在オーバーフローしているタブをクリックすると、そのタブが表示されます。

タブのナビゲート

次のコマンドを使用すると、ユーザーはタブ間を移動できます。

• Ctrl-Tabは、アクティブなタブグループ内のすべてのタブのリストを表示します。
  
• Ctrl Alt Tabは、すべてのタブグループ内のすべてのタブのリストを表示します
  
• クイックオープンは、すべてのタブの線形履歴を表示します
  

作業ファイル

これが実際に何であるかをよりよく反映するために、作業ファイルの名前を開いているエディターに変更しました。

開いているエディターのリストは、タブと同じように機能します。 それらをタブとして視覚化するのではなく、エクスプローラーにリストするだけです。

ファイルが2つ以上のエディターグループで開かれている場合、開いているエディターリストに次のように表示されます。

ユーザーが開いたエディターは、開いているエディターのリストに表示されます。 たとえば、diffエディタは次のように表示されます。

各グループには、プレビュータブが1つだけ含まれています。

アクティブなエディターグループの右上にあるシェブロンは、エディターのスタックがあるかどうかを示します。

この場合、エディターを閉じると、エディターを完全に閉じるのではなく、スタック内でその下にあるエディターが表示されます。

エディターを閉じると（たとえば、Ctrl-Wを使用して）、開いているエディターのリストからエディターも削除されます。

@stevencl

プレビュータブと開いているタブを明確に区別するために、次のワイヤーフレームのようにタブのタイトルをイタリック体で示しています。

イタリック体にするだけでなく、タブの色を暗くして_本当に_はっきりさせるオプションがあれば素晴らしいかもしれません。

以前に書いたように、タブを持たない、またはエディターを開くオプションがあるかどうかも知りたいので、これは、PowerShellなどのスクリプトを実行する人々にとって便利なシナリオになる可能性があります。

@eyalskディスカッションで、タブと開いているエディターは、どちらか/両方/なしで個別に有効または無効にする必要があると述べられました。

@anyongありがとう！ :)

Ctrl-Tabは、アクティブなタブグループ内のすべてのタブのリストを表示します。

最終的に！ タブであろうとなかろうと、これは私が待ち望んでいた動作です！ ファイル履歴で迷子になることはもうありません。

エディターを閉じると（たとえば、Ctrl-Wを使用して）、開いているエディターのリストからエディターも削除されます。

すごい！ これにより、より直感的に感じられ、_作業ファイル_の乱雑さが解消されることを願っています。

ここで、 https：//github.com/Microsoft/vscode/issues/5554が閉じるのを待ちます。

うーん、これが考慮されたかどうかはわかりませんが、今考えたところ、複数のモニターがサポートしています！ Visual Studioで、タブを別のモニターにドラッグして、新しいタブウィンドウ/ビューを作成できます。このようなものが検討されていますか？ 新しいVSCodeプロセスを作成し、プロセス間通信を介してプロセス間でタブをドラッグすることでこれを実現できると思います。同じことがオープンエディターにも当てはまります。アイデアです:)

「プレビュータブ」をオプションにすることはできますか。つまり、永続的なタブに自動昇格し、コンテンツが消えないようにするオプションがあります。 一時的なタブを視覚的に区別する方法について話し合っていることは知っていますが、率直に言って、ファイル間をすばやく移動する（特にGo-To-Definitionなど）ために時間がない私のような人には機能しません。タブを視覚的に調べて、タブがどのように動作するかを調べます。ファイルをどのように開いたか、またはたまたま編集したかどうかを覚えていません。ファイルがランダムに消えたように見えると、本当に戸惑います。 （ランダムではないことはわかっていますが、ランダムである可能性もあります。）

私は通常、作業単位が完了するまで開いているタブに自分自身を埋めてから、コミットすると同時にそれらをすべて閉じます。

@eyalskに感謝し

@stevenclドラッグすると、そのファイルが開いた状態で（おそらく同じフォルダーも開いた状態で）新しいvscodeウィンドウが開いただけで

@Tyriarに感謝し

@stevencl将来的に追加するにはさらに多くの作業が必要になるのではないかと心配しているので、インフラストラクチャを改善するときは、必ずバックログに残してください。 ;）

タブをお願いします

これを見るのは素晴らしい。 軽量の提案が大好きで、作業ファイルのエクスペリエンスを壊さない方法を見つけています。

それを試してみるのを楽しみにしています。 聞いてくれてありがとう。

@stevenclそれは両方の

Open Editorsは3つ以上のエディターグループをサポートしますか？ 左と右よりも複雑な場合、どのように名前を付けるのか疑問に思います。

はい、これは引き続きサポートされます。

差出人：Maxime Quandallemailto：[email protected]
送信済み：22/04/2016 23:09
宛先：Microsoft / vscodemailto：[email protected]
Cc：Steven Clarkemailto：[email protected]; Mentionmailto：[email protected]
件名：Re：[Microsoft / vscode]開いているファイルの適切なタブ（＃224）

ドラッグアンドドロップによるペインの再配置は、 @ stevenclプロポーザルの下でも可能でしょうか？

あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

@stevencl数日前の議論からあなたが概説したことは

@ jayrosen1576水平分割は、この号https://github.com/Microsoft/vscode/issues/1749でキャプチャされています。興味を示すために、必ず：+1：を実行してください。

良い仕事をしている人は、ワイヤーフレームが本当にうまくいくように見えます。

ねえ@stevencl
素晴らしい仕事をありがとう、そしてこれが左の閉じるボタンについての私の2セントです。
開いているファイルが多く、タブが縮小されている場合、各タブの小さなスペースは、閉じるボタンを表示するのに十分であり、タブを選択する代わりに誤って閉じるのを容易にします。

ダーティインジケータアイコンはファイルのステータスのみを示すため、左側にとどまることができますが、閉じるボタンを右に移動すると、ファイル名を簡単に認識でき、誤って閉じるアクションを防ぐことができます。

@stevenclモックアップは見栄えがよく、機能の説明は

@hsynタブは縮小せず、オーバーフロータブはシェブロンオーバーフローボタンから利用できることを理解していました。 閉じるボタンは問題になりません。

アクティブなタブの右側にタブが開きます。 タブグループ内のすべてのタブを表示するのに十分なスペースがない場合は、タブをオーバーフローさせます。 タブ内のファイルの名前を切り捨てて、タブを増やすためのスペースを増やすことはありません。

私はそれに同意しません。 画面が2〜3列に分割されている場合、最大で1〜2個のタブが表示され、残りはオーバーフローします。 ブラウザの機能を実行してください。私たちは毎日ブラウザを使用しており、直感的で慣れています。 確立されたパターンを使用することをお勧めします。そのうちのいくつかは、10年以上にわたって進化しています。 穀物に逆らうな。

私はそれに同意しません。 画面が2〜3列に分割されている場合、最大で1〜2個のタブが表示され、残りはオーバーフローします。 ブラウザの機能を実行してください。私たちは毎日ブラウザを使用しており、直感的で慣れています。 確立されたパターンを使用することをお勧めします。そのうちのいくつかは、10年以上にわたって進化しています。 穀物に逆らうな。

一部のブラウザは、タブの縮小を組み合わせて実行しますが、特定のしきい値を超えてタブをオーバーフローさせます。 Firefoxはそれを行います。 iOS Safariもそうしている（またはしている）ことは間違いない。

十分な数のタブが開いていて、各タブに数文字がほとんど表示されない場合（実際には、通常はそれほど多くのタブを開いていませんが）、オーバーフローよりも特に使い勝手がよくありません。

@alexgorbatchev私は間違いなくあなたがどこから来たのか

しかし、開発者のために私にアイデアを与えてくれました-ここでの本当の問題は、すべてのファイル名が非表示になっていると20個のタブを使用できないことはわかっていますが、少なくとも20個のタブが開いていることを知っています。 「必要に応じてファイルがどこにあるかはわかっているが、ファイルが消えただけではない」というある種の感覚。 現在非表示になっているタブの_数_を示すインジケーターだけを修正するために必要なのは、余分な水平方向のスペースを占有しないように、インジケーターをオーバーフローシェブロンの上の小さな円にすることです。

みんな、ありがとう。 モックアップには表示しませんでしたが、必要に応じてタブを縮小し、ファイル名と閉じるボタンのみが表示されるようにすることを目的としています。 @anyongが言及している理由により、ファイル名が互いに区別できないほどに縮小したいとは思わない。 コードエディタの複数のタブが類似した名前を持つことは、ブラウザのタブが類似した名前を持つことよりもおそらく一般的であると考えられます（たとえば、同じプレフィックスを持つファイル名が多数ある可能性があります）。 したがって、コードエディタでタブを縮小すると、ブラウザとは異なる結果になると考えられます。

タブがダブルシェブロンでオーバーフローコントロールにあることを示すつもりですが、オーバーフローするタブの数でバッジを配置することも興味深いアイデアです。 数字が単にオーバーフロータブがあることを示しているという意図ですか、それとも実際のオーバーフロータブの数が重要ですか？

@stevenclをクリアしていただきありがとうございます。

タブ内のファイル名で覚えておくべき1つのエッジケースは、異なるフォルダー（index.js、README、LICENSE、package.jsonなど）から開かれた同じ名前の複数のファイルです。

私はおそらくタブをまったく使用しないでしょうが、それも指摘する価値があると思います
ブラウザは通常、タブにサイトのファビコンを表示します。
タブがそのポイントを超えて縮小した場合でも、識別が容易になります
読みやすいです。 ソースファイルには、それらを明確にするためのファビコンがありません。
そして、スティーブンが指摘するように、ファイル名はソースコードでよく似ています。

12:16の木、2016年4月28日には、スティーブン・クラーク[email protected]
書きました：

みんな、ありがとう。 モックアップには表示しませんでしたが、意図は
必要に応じて、タブを縮小して、
ファイルと閉じるボタンが表示されます。 理由@anyong
https://github.com/anyongの言及、私たちは縮小したくないと思います
ファイル名が互いに区別できないポイント。 我々が考えます
コードエディタの複数のタブが持つのがおそらくより一般的であること
ブラウザのタブに類似した名前を付けるよりも類似した名前（例：
同じプレフィックスを持つファイル名が多数存在する可能性があります）。 したがって、私たちは
コードエディタでタブを縮小すると、
ブラウザ。

タブがダブルでオーバーフローコントロールにあるときを表示するつもりです
シェブロンですが、あふれているタブの数でバッジを配置することは
面白いアイデアも。 数字が単にそれを示しているという意図ですか
オーバーフロータブがありますか、それとも実際のオーバーフロータブの数が重要ですか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

@alexgorbatchevに感謝します。 このような場合に明確にするために、ファイルへのパスを表示する方法についていくつかのアイデアがあります。 たとえば、上記の忠実度の高いモックアップでは、ファイル名の下にファイルへのパスが表示されます。 ただし、これは1つのアイデアにすぎず、パスが長い場合は機能しない可能性があります。 もう1つは、パスをステータスバーに配置することです。 探索することがたくさんあります...

@stevencl

数字が単にオーバーフロータブがあることを示しているという意図ですか、それとも実際のオーバーフロータブの数が重要ですか？

開いている（ただし表示されていない）タブの実際の数を表示すると、問題が解決すると思います。 本質的に、人々はこれを見ることに慣れています（まあ、少なくとも私自身のために話す）：

だから彼らは直感的に「たくさんのタブを開いている」対「2つか3つのタブを開いている」という考えを持っています

「20」を示すバッジは、20個の小さな/役に立たない縮小されたタブを示すよりもはるかに小さいです（基本的に余分なスペースはありません）が、それでも（a）非表示のタブがあり、（b）正確にどのようにあるかをすぐに知ることができます多くあります。

私はこのスレッドを初めて使用しますが、完全なVS2015ユーザーとしての2pは次のとおりです。

作業ファイルが私に合わないので、vscodeにタブがあることを楽しみにしています（ただし、ctrl-f4を押しても、想定していたようにそのセットから削除されないことがわかりました）。

プレビュータブの大ファン、それが入ってくるのを見てうれしい。

アクティブなタブの右側に新しいタブが開く理由について知りたい。 「Webブラウザだから」または「崇高だから」が答えだと思いますが、特にタブが左から（右のシェブロンに）隠れてオーバーフローした場合は、直感に反しているように見えます。

VSに従ってタブの右クリックメニューが表示されることを期待しています...「すべて閉じる」（グループの場合）最も重要なのは、「これ以外のすべてを閉じる」に煩わされないことです。 ここでは、変更されたすべてのファイル用のVSスタイルの保存ボックスが役立ちます。

左側の閉じるボタンは私には奇妙です-私はそれがいくつかのmac / linuxの慣習だと思います-しかし、タブの「中央のボタンクリック」がエディターを閉じる限り（該当する場合は保存を求めます）、気になりません。 大量のファイルを連続してすばやく閉じることが左側にある理由はわかりますが、とにかく中クリックの方が適しています（ただし、スクロールホイールのないMacやノートブックではそうではないでしょうか？）。

シェブロンファイルピッカーは、ファイルにすばやくジャンプするための入力を許可する必要があります。 シェブロンを表示するのに十分なファイルを開くことを個人的に計画しているわけではありません（そして、そうするときは間違いなくctrl-pを使用します）が、それは起こります。

シェブロン番号-これは、このグループの_hidden_​​タブ/ファイル/エディターの数ですか、それとも表示されているファイルを含む_all_の数ですか？ 特に、タブ行から何かがオーバーフローしたときにシェブロン（したがってカウント）のみを表示する場合は、非表示のアイテムのみを議論します。

少し関連したメモですが、ctrl-f4（またはctrl-w？間違えない限り、Windows以外のバージョンのctrl-f4のようです）の場合、タブが消えると、エディタで、保存/破棄を求めて、ctrl-tab / ctrl-alt-tab / workingファイルから削除する必要があります...この機能を有効にするために現時点で実行できるキーバインドの変更があることがわかりますが、タブベースのインターフェイスで、タブの存在がファイル/エディタの「現在」-/オープン性に直接関係していない理由を確認してください。

皆さんがvscodeで行っていることを愛し、それは素晴らしく見えます☺

提案されているようにファイル履歴を使用してみましたが、1か月後、タブが必要なくなったように感じました。 VSでは、たくさんのタブを開いているのは本当に面倒です。 数が多すぎると嫌いで、非表示のタブの小さなドロップダウンに移動します。 VSでもファイル履歴を実際に使いたいと思います。

作業ファイルに関しては、すべてがそこにあるのは本当に迷惑だと思います。 決して開けずに閉じたままにしておくのは面倒です。 私が役立つと思うのは、保存されていない新しいファイル、または保存されていないファイルを表示することだけだと思います。 それはすぐに大きくなりすぎて、私も気にすることができません。 ただし、これをどのように修正できるかはわかりません。 たぶん、保存されていないファイルだけを表示しますが、それはいくつかの奇妙な副作用をもたらすでしょう。

とにかく、私は今ファイル履歴の信者です。 :)

shift+cmd+[とshift+cmd+]を使用して、履歴を行き来する機能を追加できれば、本当にすばらしいと思います。 これらは、他のアプリケーションのタブをナビゲートし、それらを使用して履歴をナビゲートできるようにするためのデフォルトのショートカットです。少なくとも、私を信者にするのに大いに役立つと思います。

編集：基本的にこれを実装することで達成しました

  { "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" }

カスタムキーバインディングとして

コードセクションを新しいウィンドウに分割できると便利だと思います。 しかし、それが可能かどうかはわかりません。

@JoshCloseそれは完全に可能ですが、エディター自体のプロセス間通信のインフラストラクチャが不足しているため、2つのインスタンスが通信し、最初にこのためのプロトコルが必要なことをすべて実行します。

...タブには、名前の左側に閉じるボタンが含まれています

慣習を破る特別な理由はありますか？ LTRを読み取る場合、最も重要な情報はファイル名であり、閉じるボタンではありません。 右に移動すると、閉じるボタンをデフォルトで非表示（およびホバー時に表示）にするのも簡単になります。 後の段階で、ユーザーはファイル名の左側にファイルアイコンを配置することもできます。

プレビュータブを完全に開いたタブに昇格させるためのアクションについて説明しました...

最初の2つのオプションでおそらく十分だと思います。 タブをダブルクリックすると、将来的に他のことに役立つ可能性があります。

このような場合に明確にするために、ファイルへのパスを表示する方法についていくつかのアイデアがあります。

タブにカーソルを合わせたときに、ツールチップを（相対パスとともに）表示するだけではどうでしょうか。 これにより、デザインがすっきりし、タブの高さを低くする必要がなくなります。

オーバーフローがあるときはいつでもシェブロンを表示します...

Firefoxはタブオーバーフローを適切に処理します–最大タブ幅、左右のスクロールボタン、すべてのタブを一覧表示するドロップメニュー（現在表示されているタブがマークされている）などがあります。

タブの閉じるボタンがプラットフォームの規則と一致していれば、本当に素晴らしいでしょう。OSXの左側、Windowsの右側。

しばらくVSCodeを使用した後、私は_WorkingFiles_モードが大きく成長したと思います。

ここにいくつかの理由があります：

1. 直感に反するように聞こえますが、使用していないファイル（ctrl-w）を閉じても、作業ファイルから削除されません。 関連ファイル（または子クラス）を操作しているときに、最近閉じたファイル（Reactプロジェクト内）を何度も再度開くので、これは非常に良いことです。 したがって、ファイルを閉じる必要があると_感じた_場合、ファイルを閉じたはずの時間に1対1でマップされません。
2. workbench.files.action.closeFileによって提供される明示的なForce-Closeが好きです。
3. workbench.files.action.closeFileをCtrl + k Ctrl + wに再マップしました。これは、 Ctrl + kwよりも（わずかに）少ない労力で済むためです。
4. エディターのトップバーに完全なファイル名とパスが表示されます->これは、類似または同じ名前（ index.js ？）のファイルのみを含む深くネストされたプロジェクト（私のように）では非常に重要です区別する方法はパスによるものです。
5. タブのノイズが少ない=禅！

ですから、ある意味で、タブのことを紹介する場合は、現在のフローを_削除しないでください_と言いたいのです。

@kumarharshなぜ彼らはそれを削除するのでしょうか？ どちらかといえば、彼らはおそらくあなたのためにそれを改善するでしょう！ :)

ダーティインジケーターがCLOSEアイコンに置き換わった場合、変更を保存したくない場合、どうすればファイルを閉じることができますか？ ctrl-wは引き続き利用できますか？

ダーティインジケーターがホバー時に閉じるボタンに変わるだけではありませんか？
それはかなり一般的な解決策です...

23:28の水曜日、2016年5月4日には、rojorojo [email protected]は書きました：

汚れたインジケーターがCLOSEアイコンに置き換わった場合、どうすればよいでしょうか
変更を保存したくない場合は、ファイルを閉じますか？ ctrl-wはまだ
利用できますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

@rojorojo @anyongも提案したことを行っているので、問題はありません。 はい、Ctrl + Wは引き続き使用できます。

すべてのフィードバックをありがとう。

今月末に、最新のデザインに関するUX調査を実施しています。 5月25日または26日に1時間の余裕があり、調査に参加したい場合は、 https ： ください。

残念ながら、私は日中（英国夏時間）の時間しか提供できず、夕方にはセッションを実行できません。

試してみることができるいくつかの実用的なビットと、まだ示していないいくつかのデザインワイヤーフレームがあることを望んでいます。

待ってください、私は現在のUIの動作が大好きです、構成はありますか？

3週間前、私は本当にタブが欲しかった。 タブがなかったので、しばらくの間VSCへの切り替えを延期しました。 VSCを使用して数週間過ごしたので、タブすら必要ありません。 この時点で、彼らは私の邪魔になると思います。

これが構築されるとき、それがオプションであり、それを望む私たちが現在の環境で継続できることを願っています。

垂直タブが本当に好きな人（ワイドスクリーンディスプレイでのスケーリングと動作がはるかに優れている）として、私は疑問に思っています。なぜタブと「オープンエディタ」の両方が必要なのですか。 後者が基本的にタブ動作の「作業ファイル」である場合、それが私が必要/望んでいるすべてです。

タブがオプションであることを確認するために投票を追加したいと思います。 私はエディタータブが本当に嫌いで、ウィンドウの左側にあるパネルを好みます。 欲しい人のために追加することは理解していますが、無理に押し込まないでください。 それらを持たないことは、私がこのエディターについて好きなことの1つです。

私の2セント：閉じるボタンは必要ありません。 私にとって、それらは時々欲求不満を引き起こす（誤ってクリックする）不動産の無駄です。 誤って1px左にクリックしすぎるよりも、誤ってミドルクリックする方がはるかに困難です。

また、汚れた指標は不動産の無駄だと思います。 Sublime Textでは、タブのフォントの色を変更するだけで「dirty」を設定します。 過去にもイタリック体にしましたが、プレビューをイタリック体にする予定があるようです。

境界線の左側が広すぎます

@ be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

人々は私はあなたがおそらくそれをすべて読んでませんでしたが、周りの記事を読んでくださいので、それは長いスレッドのことを理解してここに。 タブはオプションになります。開発者は、あなたが提起しているポイントをすでに非常によく認識しています。

ポスターになる可能性があります：スレッドを調べて、問題がすでに解決されているかどうかを確認してください-投稿するたびに、100人の人があなたの：+1：ありがとうメールを受け取ります

@anyongただし、「Open editor」は、2つの列を開くと、既存の作業ファイルリストを2つに分割します。 すべてのエディター列に「作業ファイル」が1つしかないという考えが大好きです。
これもオプションにしてください。

@ be5invis唯一の違いは、視覚的な区切り文字があることです。 ファイルをドラッグして、好きなエディタで開くことができます。

@anyong非表示にできますか？ また、一方のエディター列で「セパレーター」とCtrl-Tabを非表示にすることを選択した場合、もう一方の列で開いているファイルに切り替えることはできますか？ con-tabbersが望んでいるのは、既存の動作を完全に維持することです。

上記にリンクしたコメントからの@ be5invis ：

Ctrl Alt Tabは、すべてのタブグループ内のすべてのタブのリストを表示します

そうです、必要に応じて、現在のCtrl + Tabの動作を維持するようにキーバインディングを設定できます。

@anyongいいですね。
それでも、「左/右」インジケーターを非表示にして、リストを1つのように見せることはできますか？

それは@stevenclの質問になります

わーい！ 私たちはすぐにタブを取得することを願っています！

すばらしいニュース..タブを取得しています..しかし、「作業ファイル」フォルダを失いたくありません。タブと一緒に保管しますか？

驚くばかり！ タブグループ

@ be5invisそうです、エディターを分割したら、開いているエディターリストに複数のエディターグループを表示するつもりです。 ただし、複数のファイルを操作できるようにするために、これを行う必要はありません。 エディターを分割して、一度に複数のファイルを表示します。 いつでも1つのエディターを表示したままにしておくと、複数のファイルを開いたままにすることができます。 たとえば、このスクリーンショットでは

2つのファイルを開いていますが、エディターを分割していないため、そのうちの1つしか表示していません。 開いているエディターリストには両方のファイルが表示され、そこで、または右上のオーバーフローコントロールを介してファイルを操作できます。 （ここにはタブが表示されていないことに注意してください。これはタブなしのオプションです。）

これを行った理由は、現在の作業ファイル設定で2つのエディターで開いているファイルを管理するときに混乱が生じる可能性があるためです。 たとえば、現在の製品の以下のスクリーンショットでは、作業ファイルリストのファイルapp.jsを閉じるとどうなりますか。 両方のエディターを閉じるか、どちらか一方だけを閉じる必要があります。 そして、それらのうちの1つだけの場合、どれですか？

あいまいさや不確実性を避けたいので、各エディターグループで開いているファイルについてより明確にすることを選択しました。

また、新しい動作をより適切に反映していると感じたため、作業ファイルの名前を開いているエディターに変更したのもそのためです。

Go To Definition（F12）オプションを拡張する必要があります（定義はプロジェクト内の別のページにあります））崇高なテキストのように？VSコードをインストールしてから長い間この問題に直面していますか？これに関するヘルプはありますか？

@ vinod-a-ext-「定義に移動」で直面している問題を説明する新しい問題を開いてください。

@stevencl
VSCodeの定義の問題に移動します
https://github.com/Microsoft/vscode/issues/6238

@stevencl私の意見では、「開いているエディター」でラベルを非表示にして、さまざまなパネルを表す線を引くだけです。 パネルを閉じると、2つのリストを自然にマージできます。

提案をありがとう、私たちは間違いなくこれのためのさまざまな視覚的治療法を探求します。

日付：2016年5月10日火曜日04:06:34 -0700
差出人： [email protected]
宛先： [email protected]
CC： [email protected]; 言及@ noreply.github.com
件名：Re：[Microsoft / vscode]開いているファイルの適切なタブ（＃224）

@stevencl私の意見では、「開いているエディター」でラベルを非表示にして、さまざまなパネルを表す線を引くだけです。 パネルを閉じると、2つのリストを自然にマージできます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

興味があります。このようなモックアップを生成するためにどのプログラムを使用しました

これらのモックアップにはPowerPointを使用しました。 私たちの意図は、ビジュアルデザインではなく、インタラクションフローに焦点を当てることでした。そのため、PowerPointのツールはその詳細レベルで正常に機能します。 PowerPointで操作を行うと、一連の画面を簡単につなぎ合わせて、流れをよりよく感じることができます。

日付：2016年5月10日火曜日05:03:55 -0700
差出人： [email protected]
宛先： [email protected]
CC： [email protected]; 言及@ noreply.github.com
件名：Re：[Microsoft / vscode]開いているファイルの適切なタブ（＃224）

興味があります。このようなモックアップを生成するためにどのプログラムを使用しましたか

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

4月のリリースノートを見た後、ここに来ました。 長い間スレッドが開いていますが、元のデザインでは+1です。つまり、タブはありません。 最初は気になりましたが、その後、その背後にある哲学を理解し、理解するようになりました...今、Atomとタブスパムについて考えると...震えます。 それはさておき、私は開発者からの関与と思慮深いコメントとフィードバックが大好きです。

これを試すのを楽しみにしています。 私が見たいのは、複数の関連ファイルを1つのタブに結合することです（このVSプラグインと同様）

これは、一般的に関連ファイルがあるAngular2開発で整理された状態を維持するのに非常に役立ちます。

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

「作業ファイル」フォルダに使用していた@lucidtechに同意し

@corehに同意します。タブを閉じるボタンの位置は、プラットフォームの規則と一致する必要があります。 VisualStudioからVisualStudio Codeに移動するときに、閉じるボタンの場所を変更するのは、かなり苛立たしいコンテキストスイッチになります。

私の2セント：Atom、Sublime、またはその他の流行に敏感なエディターのいずれかでコードを_love_する理由の1つは、Webブラウザーの「タブ」の概念で靴べらをしようとしないことです。 Visual Studio、IDEA、Eclipseなどの従来のIDEもすべてこれを行います。 一方、コードには「フレームとバッファー」アプローチがあり、Emacs（およびVimもそうだと思います）に見られるものと似ています。

必然的に、タブベースのエディターでは、フォルダーフォブが非常に小さくて読めないタブでエディターフレームがひどくスパムされる結果を処理する必要があります。 さらに、Ctrl /⌘-PIに相当するこのようなエディターを使用すると、最初にファイルに移動したときに表示していたフレームのアーティファクトとして、別のフレームにワープすることになります。 同じファイルを別のフレームで表示するには、不格好な「タブの分割」操作を実行する必要があります。これは、これらのエディターの多くでフレームの分割と組み合わされる傾向があります。 _Tabsは、ファイルバッファの状態をディスプレイ上の特定のフレームと緊密に結合します。_

感情的な訴えを許すなら、VSCodeをさらに別のタブ付きエディターに変えないでください。

UXの観点からは、Atomや他のエディターの動作に合わせてタブを盲目的に実装するのではなく、（単に快適な親しみやすさ以外に）人々がタブを必要とする理由を理解し、より革新的なソリューションがあるかどうかを確認することが有益だと思います。彼らのニーズは可能です。 私は確かに、現在のワークスペース体制が進化し続ける可能性があることに同意します。他の誰かが同じ（タブベースの「リップアウト」に相当する）プロジェクトで別のウィンドウを開いてマルチヘッドディスプレイをより有効に活用することに言及したように思い浮かびます！

編集：19日前に電話に出られなかったのはとても悲しいことです。 それを知っていたら参加していたでしょう。 1.1.0のリリースノートからのみわかりました。 :(

タブは私にとって必須であり、関連ファイル用の角度2.0のグループ化されたタブなどの別の提案も素晴らしいアイデアです。 機能が構成可能であれば、好みが異なる人も喜ぶでしょう。 いつ試すことができますか!!! ???

@orospakr 、メニューオプションからSublimeのタブをオフにすることができます。 参考までに。

@orospakr

人々が（単に快適な親しみやすさ以外に）タブを必要とする理由を理解し、彼らのニーズに対するより革新的な解決策が可能かどうかを確認することは有益です。

人々が親しみやすさ以外にタブを必要とする理由については、たくさんのフィードバックがあります。もちろん、親しみやすく、慣れている場合は、すでに機能しているものがあるところで創造性を発揮して革新することは意味がありません。

彼らは「作業ファイル」で革新を試みましたが、一方のグループはそれを気に入り、もう一方のグループはそれを嫌いました。今日、私たちはタブを求めています！ 同じ症候群が再び起こることを望んでいないと思います...

それを行う正しい方法は、人々が最初に探している体験を取得し、次にアルファビルド中および/またはオプションとして追加の機能、革新、または実験を行うことです。

このタブ/「エディターを開く」または明日はオプションにしました。そのため、ユーザーはエクスペリエンスにオプトインするか、オプトアウトすることができる必要があります。

私はここでゲームに少し遅れていることを知っていますが、このセクションに関して：

プレビュータブを完全に開いたタブに昇格させるためのアクションについて説明しました。

タブ内のコンテンツの編集
エクスプローラーでファイルをダブルクリックする
タブグループのプレビュータブをダブルクリックします

上記のリストに「ブックマークの追加」を含めていただきたいと思います。
大きなファイルにブックマークを追加してから、うっかりして別のファイルをクリックして作業ファイルを閉じるのは非常にイライラします。

すぐに閉じる予定のファイルにブックマークを追加した可能性はほとんどありません。

できるだけ多くのコメントを調べてキーワードを検索しましたが、これについては言及されていませんでした。

タブに関する限り、まず、_ありがとうございます！_タブがないことは、VSCodeについて私が嫌う唯一のことの1つです。

タブ間のナビゲーションをカスタマイズできるようにしたいと思います。 たとえば、iTermがcmd + left押してタブを切り替える方法が大好きで、エディターでもこれを実行したいと思っています。

素晴らしい編集者に感謝します<3

タブは私にとって必須です...タブができるまでSublimeに切り替えます。 PS私はあなたの態度に非常に失望しています。 あなたはUXの感覚を持っていないようですが、これはUXを改善するために行われたと主張しています。 あなたのペルソナは何ですか？ ユーザーインタビューはどこにありますか？ 証明する。

@asadighi投稿する前にコメントを読んだこともありますか？ チームは広範なインタビューを行い、タブを正しくするためにさらに多くのことを行っています。 彼らはコミュニティに非常に敏感で、優れたエディターを（無料で）作成しています。 Sublimeの次のリリースを待って頑張ってください。

あなたの以前のコメントはあなたの偏見を物語っています。 私の異議は、彼らが最初から持っていた態度にあります。 ユーザーインタビューは、人々がそのような欠陥のために製品をバッシングし始める前に行われるべきです。 非常に興味深いことに、より良いUXの名の下にこの欠陥を修正するために投資することをためらうことがわかります。 この問題は11月から公開されており、そのほとんどの時間、ほとんどの回答は、あなたがどのように仕事をすべきかをあなたよりよく知っていることに沿っています。

@asadighiそれはすべてあなたの頭の中にあり、あなたのナンセンスなショーはあなたのコメントにあります、それを止めてください。

@muellerkyle ：+1：使用するブックマーク拡張機能に対して問題を作成する必要があります。

この機能を楽しみにしています

+1！

毎日、Eclipse、PhpStorm、Notepad ++、VSCodeを切り替えています。 何だと思いますか、 CTRL+W私を狂わせます。

私はこのパーティーに遅れていますが、タブはオプションになりますか？ 私は以前はそれらを見逃したと思っていましたが、今はそうではありません。 それらを隠す方法があるかどうかだけ興味があります。 タブやタブを使用したい人を嫌うことはありません。表示/非表示を切り替える方がいいと思います。 それはすべて素晴らしい仕事を続けています。 vscodeが大好きです。

@jamesmeneraはい、オプションになりますが、作業ファイル（開いているエディター）もオプションになります。

余談ですが、これらのモックアップ写真を作成するために使用したプログラムを教えてください。

@ ciel 、 @ stevenclは、PowerPointを使用したと書いています。

個人的には、WireframeSketcherが大好きですが、PowerPointも機能します。 :)

@jamesmeneraが述べたように、私はタブとサイドバーが本当に恋しいですが、Working Filesが好きな人がたくさんいるので、オプションにする必要があります。

@ kadza93タブと作業ファイルの両方がオプションになります...何回書き込むのだろうか。

検索して「オプション」という単語を探すのは本当に簡単です。実際に投稿するよりも、見つけるのにかかる時間が短くなります。

@eyalskなぜ炎なのかしら！ 私は自分の必要性を表現するためにここにいます、そして私がタブのための多くの必要性を見ることができる限り、他の人が言ったことを支持しそしてそれに同意することによって私は何か間違ったことをしていますか？ ちなみに、検索機能のヒントをありがとう、私は自分の意見を表明したい長いスレッドでそれをもっと使うべきです、そして誰かがすでに私のように表現したなら私はそれをスキップします。

それはあなたの投稿からわずか3アップでした...

このスレッドに続いて、将来のリリースのためにタブについてすでにいくつかの決定がなされているように思えます（タブはオプションで、アイコンが表示される場所、キーの組み合わせなど）。 私が間違っていない場合、人々が指摘できるこれらの決定のリストはありますか？

@jtloweただし、GitHubに固定されたコメントのように、それを明確にする簡単な方法はありません。 人々は新しいコメントをし、それは重要なものを埋めます。 GitHubは、コメントが多すぎてページ内での検索が困難な場合にも、コメントの折りたたみを行います。

おそらく、管理者は、問題ページの上部（OPの問題本体の下）に「現在のステータス：開発中」バナーを配置できますか？

これはgithubの適切な機能であるはずです---ここの代替テキストのようなものが示唆しています： https ：

@ kadza93私はあなたを炎上させませんでした...しかし何でも。

私は自分の必要性を表現するためにここにいます、そして私がタブのための多くの必要性を見ることができる限り、他の人が言ったことを支持しそしてそれに同意することによって私は何か間違ったことをしていますか？

いいえ、何も悪いことはしていませんが、有用なものも何も書いていません。絵文字/反応機能は、この理由のために特別に存在します。

ちなみに、検索機能のヒントをありがとう、私は自分の意見を表明したい長いスレッドでそれをもっと使うべきです、そして誰かがすでに私のように表現したなら私はそれをスキップします。

ええ...あなたは多くの意味を持っています、私は確認された何かについて意見を表明することを意味します！ 親指を立てたのと同じ人に返信したので、検索する必要すらありませんでした。

一般的に、長い投稿でありそうな一般的な単語を検索するのは常識です。

本当に開発者はFAQと詳細から取られた新しい問題を開く必要があります
このスレッドで最も一般的なポイントとこの問題を閉じます。 人
この号を購読すると、毎日数十通のメールが届きます。
同じ「賛成」/「反対」のコメント。
2016年5月18日午前1時51分、「KumarHarsh」 [email protected]は次のように書いています。

おそらく、管理者は「現在のステータス：開発中」バナーを置くことができます
問題ページの上部（OPの問題本体の下）？

これはgithubの適切な機能である必要があります--- alt-textのようなもの
ここで提案します： https ：

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

@anyongええ私は完全に同意します！ 議論することは何もありません。 tabsとopen editorsが公開されたら、これらの機能に関するフィードバックのために2つの別々の問題を作成する必要があります。

@eyalskは、コミュニティが作成した問題の更新を処理する方法をまだ実験中です。 これを行う方法はたくさんありますが、GitHubに固定されたコメント機能がないと、すべての方法が悪いです。 統合端末の問題https://github.com/Microsoft/vscode/issues/143#issuecomment-213581854はこれまでのところ問題なく、スレッドの途中で大きな更新が行われています。議論の必要性が少ないことと関係があると思います。だからそれは埋められていません。

@Tyriarええと、投稿を参照できるので、新しい投稿を作成し、それらを閉じて古い投稿を参照することはできませんか？ これがRoslynに取り組んでいる人たちのやり方だと思います。そして、彼らは今後のリリースのすべての機能を要約した投稿を持っていますが、それでも私はあなたに同意します。ピン留めされたコメントは非常に役立ちます。

このマイルストーンでタブとエディターグループのデザインの実装に取り​​組んでおり、次のマイルストーンでも引き続き実装します。

ここ数日、UX調査に参加してくれたすべての人に感謝します。 エクスペリエンスを改善するのに役立つ素晴らしいフィードバックをいくつかいただきました。

• オーバーフローアイコンを再設計する
• クイックオープンのファイルを固定するかプレビューするかを選択するための設定を提供します
• プレビューされたファイルを固定されたファイルに変換するコマンドを追加します

申し訳ありませんが、それを見逃した場合は、タブを有効にするにはどうすればよいですか？ 私が持っているように、最新のインサイダービルドで利用できますか？タブの痕跡はありません。 エクスプローラーにも「作業ファイル」が表示されますが、＃6536に記載されているように「開いているエディター」に置き換える必要があるようです。

@lllopoまだ利用できません。 スタック/オープンエディターはv1.3.0に統合され、デイリービルドが利用可能になった来週インサイダーで利用できるようになります。

+1

+1

👎

ここで何が起こっているのですか、なぜタブを使用するオプションを私たちに与えることに抵抗するのですか？ 😕
私を含むタブが好きな人はたくさんいるので、私たちにPERIODオプションを教えてください！

@aminroostaマジで…読めない？ あなたは盲目ですか？

面白いことに、ここで何が起こっているのかを尋ねています...そして、実際にタブが来て実装に取り​​組んでいることを確認したときに、実際にそれを拒否するか、あなた自身の言葉で「抵抗する」と仮定します！

この世界の何人かの人々！ 信じられない！

@eyalsk
私は最初の20から30のコメントを読むのに25分を費やしました。
私は疲れてコメントを残しましたが、それは今では私の側の間違いのようです。

申し訳ありません。

マイクロソフトのR＆Dが革新を試みたことを非難することはできません。 タブシステムには短所があります。

UIデザインは、あらゆる形態のデザインに似ています。 90％がユーザーが待つものを作り、10％が新しいものを作り、新しい革新的でユーザーフレンドリーなシステムを作ろうとしています。

今日の新しいテキストエディタに必要と思われるすべてのユーザーフレンドリーなシステムは、以前に実験され、物議を醸しています。

@aminroostaヒントをかかります。

これは非常に長いフィードなので、これは良い提案です。

10:42エヤルSolnikの日、2016年6月5日には[email protected]
書きました：

@aminroostahttps ： //github.com/aminroostaヒントをお伝えします
あなたは長い投稿を読んでいて、元の投稿を読んでから、
最新の更新では、下から上にスクロールするのに1分ほどかかります。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/224#issuecomment -223826495、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
。

個人的には、Ctrl + Tabのアプローチが好きです。 私の個人的な経験から、タブを10個以上同時に開いていると、タブがすぐに乱雑になる可能性があります。 「作業ファイル」を削除するか、少なくともオプションとして残しておくといいでしょう。 私はそれを使用しません、そしてそれは私にとって混乱を追加します。 おかげでここからCtrl + Tabを使用します！

@adred Working files （現在はOpen editorsと呼ばれています）とTabsは、私が知る限りオプションになります。

@bpasero

このスレッドを_お願い_して、このスレッドの重要な部分をコピーして新しいスレッドを開くことができますか？ すべてを読むことができない（長すぎると言うべきです）人々から毎日寄せられ、同じ質問を何度も繰り返して、タブのリリースが公開ビルドにヒットしたら、私たちは行くつもりですこのスレッドでさらに多くのスパムを参照してください。

タブ関連の出来事について最新情報を入手したいのですが、このスレッドは現在それを行う場所ですが、同じコメントに対して1日に何度もスパムメールを何度も受け取るのは非常に面倒です。

トーンと感謝をお詫びします。

+1が多すぎるので少し多いです。

2016年6月6日月曜日の午前2：16-0700に、「anyong」 [email protected]は次のように書いています。

@bpasero

このスレッドを_お願い_して、このスレッドの重要な部分をコピーして新しいスレッドを開くことができますか？ すべてを読むことができない（長すぎると言うべきです）人々から毎日寄せられ、同じ質問を何度も繰り返して、タブのリリースが公開ビルドにヒットしたら、私たちは行くつもりですこのスレッドでさらに多くのスパムを参照してください。

タブ関連の出来事について最新情報を入手したいのですが、このスレッドは現在それを行う場所ですが、同じコメントに対して1日に何度もスパムメールを何度も受け取るのは非常に面倒です。

トーンと感謝をお詫びします。

あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

更新テキストへのコメント@https：//code.visualstudio.com/updates#_workbench

テキストは私には不明瞭で、更新されたスタックはすでにここにあると実際に思っていました（そしてタブは後で来るでしょう）。 更新後、更新されたスタックが表示されず、テキストを数回読み直す必要がありました。

私には、タブはより多くの反復を必要とする（つまり、_this_更新にタブがない）と言っていますが、5月にエディターのスタックを管理する方法が大幅に進歩しました（したがって、タブがないにもかかわらず、この更新ではスタックが更新されますか？）そして、6月のリリースブランチにはさらに多くの作業が必要です（スタックをさらに改善するためですか？）。

ですから、私のように混乱しているかもしれない人にとっては、更新されたスタックは実際にはこの更新には含まれ

@RyanEwenに同意します。 私はオープンな開発とコミュニケーションの量に本当に感謝していますが、公式の「リリースノート」の一部であるこれらの発表は本当に混乱しています。

たぶん、これは実際のリリースノートと「現在取り組んでいること」などに分割できます。

この問題をロードマップにリンクすることは良い考えではありません。最初から読んだ場合、現在の状況（マイルストーン以上）が明確にわからないためです。 やるべき仕事はまだありますが、現在の状態は大丈夫です：+1：

ええ、彼らは問題を要約し、次にこれらの要約へのリンクを持っているべきです。そうすれば人々はそれが議論された後に現在の計画を知ることができます。

ディスカッションへのリンクは長くなる傾向があり、人々はほとんどすべてを読まないとアイデアを得ることができないため、悪いですが、そうでなければそれを行うことはおそらく不可能です。

1.2のリリースノートを読み始めたとき、最初に探したのは_タブ機能_でした。 彼らが現在の状況をそこに置いてくれたことに感謝します。 しかし、私も混乱しました。 最初は着陸したと思っていたのですが、着陸しなかったと思いましたが、かなりの進歩がありました。 その場合、そのアイテムはリリースノートの下部にあり、ディスカッションまたはマイルストーン（どちらも機能の進捗状況を証明します）へのリンクと、_ "のような小さなメモが付いているはずです。タブの実装に向けた進捗状況」_。

この些細なことに関係なく。 リリースの素晴らしい仕事。 VS Codeは、驚くべき開発サイクルを備えた優れた製品です。

VSCodeが1.3.0に更新されました-インサイダー。 最近のファイルがなくなったようです。 今それをする方法はありますか？

リリースノートへのフィードバックに感謝し、混乱して申し訳ありません。 作業が安定していないことを明確にするためにドキュメントに変更を加えましたが、インサイダーリリースでタブ作業をプレビューできます。

完了した作業について話しますが、安定したビルドではないセクションを最後に用意することをお勧めします。そのバケットに収まる作業がさらにある場合は、来月それを行います。

@JoshCloseは、この単一のスレッドではなく個々の問題を優先してこの問題をまもなくロックするため、この問題の新しい問題を開いてください。 THX。

まず、タブについてのあなたの考え、好き、嫌いについてもう一度皆さんに感謝します。 このスレッドで見たフィードバック（ポジティブとネガティブの両方）は、VSCodeの将来について人々がどれほど情熱を持っているかを実際に示しています。

私たちはこの問題の有用性を使い果たしたことに誰もが同意できると思います。その結果、私は会話をロックするつもりです。 この問題は、タブ付き/タブなしのオプションが出荷されるまで開いたままにします。これは、 2016年6月の反復の終わりまでに行う予定です。

VS Codeチームはこの問題の更新を投稿する可能性がありますが、追加のタブデザインやディスカッションのために新しい問題が作成されることを期待する必要があります。 クエリを簡単にするために、 tabsラベルで問題にマークを付けます。 あなたも新しいタブ固有の問題を開くことができます。私たちは一緒に可能な限り最高の体験を構築するので、特定の問題に関するフィードバックをお待ちしています。

もう一度ありがとう、インサイダーリリースをインストールしてください！

https://github.com/Microsoft/vscode/issues/6605には、キーバインディングで使用するために追加または変更されたすべてのコマンド識別子が記載されています。 スタックモデルはVSCodeのUIに対する非常に大きな変更であるため、エディターまたはグループに関連するすべてのコマンドを再検討することにしました。

夜間のインサイダービルド（http://code.visualstudio.com/Download#insiders）でタブを有効にできるようになったことをお知らせします。 関連する設定はworkbench.editor.showTabsです。 エディタースタック、プレビューエディター、およびタブの概念の詳細については、リリースノートを参照してください。

月末まで（そしておそらくそれ以降）、この分野でまだいくつかの作業が計画されているので、インサイダーからのフィードバックを喜んで収集します。 タブを使用しているときに問題を見つけたら、自由に問題を開いてください。

ありがとう！

@bpaseroが述べたように、夜間のインサイダービルドでタブを有効にできるようになりました。

これを試し、フィードバックを共有するために30分を割くことができる場合は、 https ： ください。

残念ながら、私は来週の月曜日と火曜日の時間帯（私はスコットランドのエジンバラにいます）の時間帯しか提供できません。

tl; dr; workbench.editor.showTabs: trueビルドされた

今週は通常のエンドゲームテストで6月のマイルストーンを締めくくります。 タブはテスト計画（https://github.com/Microsoft/vscode/issues/7854）にあり、週の間にある程度の報道があります。 6月のタブの修正と、6月以降のフィードバックに基づく改良を行う予定です。 ただし、作業の大部分は完了しているので、この問題を閉じます。

このワークアイテムの説明から、 @ TurkeyManは、タブを用意し、タブをワークベンチから移動して新しいウィンドウ内で開く方法を求めています。 後者は、行ったタブ作業とは関係がないため、 https：//github.com/Microsoft/vscode/issues/8171に抽出しました。

試してみながら、タブに表示される問題を引き続き報告してください。 インサイダービルドのテストにご協力いただきありがとうございます。