Vscode: ملف التعشيش

تضمين التغريدة

السيناريو الأكثر مثالية لهذا هو أن أي شيء يبدأ بنفس النص كملف رئيسي ، مطروحًا منه الامتداد ، يتم تداخله ، مثل هذا ؛

File1.cs
--- File1.File2.cs
--- File1.File3.cs
------ File1.File3.File4.cs

لا توجد خطط في الوقت الحالي. سيغلق حتى نعيد النظر في هذا.

هذه ميزة مهمة للمشاريع الكبيرة. أنا أستخدم asp.net vNext لمشروع Angular والآن أتبع الهيكل تلقائيًا (عن طريق التسمية):

--app.component.ts
----app.component.ts.sass
----app.component.ts.html
--login.component.ts
----login.component.ts.sass
----login.component.ts.html

في VS Code Explorer حصلت على:

--app.component.ts
--app.component.ts.sass
--app.component.ts.html
--login.component.ts
--login.component.ts.sass
--login.component.ts.html

يعد إنشاء مجلدات لكل مكون حلاً سيئًا للمشروع الزاوي (ستحتاج إلى تغيير المراجع).

نحتاج إلى هذه الميزة للانتقال إلى رمز VS.

موافق ، على الأقل ts + js + map files (على سبيل المثال مثل webstorm)

سيكون من الرائع أن يكون لديك ملف تداخل في ts + js + map + style.

نقوم حاليًا بإخفاء ملفات .js و. map مما يجعل فحصها أمرًا مزعجًا. حتى مع وجود ts + css فقط ، لا يزال الشريط الجانبي منتفخًا.

أوافق أتمنى تداخل ملف مثل هذا (خاصة بالنسبة لـ ng2)

لغة البرمجة
--css
- ت
-- إلخ ...

الرجاء إعادة النظر في هذا! هذه قضية مهمة.

هناك العديد من الحالات التي تؤدي فيها الملفات التي تم إنشاؤها إلى تشويش مساحة العمل. مطبعي! المطبوع الذي تستخدمه أيضًا! هو مثال رئيسي. أو LESS / SASS -> css. أو اليشم -> Html

هناك خيار لإخفاء الملفات التي تم إنشاؤها بشكل مشروط. فمثلا:

"files.exclude": {
    "**/*.js": {"when": "$(basename).ts"}
}

يمكن تطبيق نفس المبدأ على ملفات css و map.

وأنا أستخدم هذا الخيار. تنشأ المشكلة عندما أرغب في رؤية ملف
الملفات المخفية. كما أنه ليس من الواضح ما إذا كانت الملفات المخفية موجودة بالفعل
هناك (أن الجيل يعمل ...) مما يجعلني أفتح المجلد
في المستكشف حيث لا يتم تجميع الملفات أيضًا ... شيء آخر هو ذلك
بعض زملائي غير مرتاحين لعدم رؤية نصف الملفات في
المشروع ونود استخدام نفس الإعدادات للفريق بأكمله.

لسبب ما ، اعتبر معظم المحررين الآخرين هذه الميزة مفيدة بدرجة كافية
تنفيذه فلماذا لا مقابل التعليمات البرمجية.

أود أن أشير إلى أن هذه ليست ميزة معقدة حقًا. انا
متأكد من أنه يمكن القيام به في يوم واحد. (كنت أفكر في إجراء سحب
طلب ولكنه قد يتطلب بعض التغييرات الصغيرة على البنية المحيطة
FileStat)

يوم الأحد ، 25 سبتمبر 2016 ، أندرو شيهان [email protected]
كتب:

هناك خيار لإخفاء الملفات التي تم إنشاؤها بشكل مشروط. فمثلا:

"files.exclude": {
"* _ / _. js": {"when": "$ (basename) .ts"}
}

يمكن تطبيق نفس المبدأ على ملفات css و map.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/6328#issuecomment -249392536 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABzUP4LXESXZpGtY1iFZJmmy9J10k4-Uks5qta2DgaJpZM4IdUnr
.

+1

أي امتداد قد يقوم بهذه المهمة؟

لماذا هذا مغلق؟ لم يتم تنفيذها وستكون ميزة رائعة.

تضمين التغريدة

لسبب ما ، اعتبر معظم المحررين الآخرين هذه الميزة مفيدة بدرجة كافية
تنفيذه فلماذا لا مقابل التعليمات البرمجية.

ربما لأنهم بحاجة إلى سبب لاستخدام الأشخاص للاستوديو المرئي الحقيقي :-)

هذا ما كان يجب أن يتم إغلاقه ، إعادة فتحه. على الرغم من أنه قد توجد تكرارات في هذه الأثناء.

stevenclchrisdiasseanmcbreenegamma معلوماتك نحن بحاجة الى بعض PM توجيه وإرشاد هنا إذا كنا نريد لتحويل ملف اكسبلورر إلى العرض المنطقي. تم إنشاء PR أولية بواسطة playerx في https://github.com/Microsoft/vscode/pull/13754

سنتان في الوقت الحالي: يجب أن نفكر في حل للسيناريوهات التي يرغب المستخدمون في حلها وأشعر أن دعم إظهار الملفات المماثلة في نفس المستوى أسفل ملف الجذر فقط لا يكفي. قد يرغب الناس في شيء قوي مثل مستكشف الحلول في VS.

bpasero ، اعتذاري ، لكن السؤال الذي طرحته غير صحيح. هناك نوعان مختلفان من الميزات:

N1. تحويل مستكشف الملفات إلى عرض منطقي
مثال: يمكنك ربط fileA ("directoryX / fileA") ، بـ fileB ، والذي يتم وضعه في الدليل Y.

N2. امنح مستكشف الملفات دعمًا لإظهار الملفات الحقيقية بطريقة أكثر أناقة ومنح المطورين القدرة على تمكين هذه الميزة ، على سبيل المثال:

الميزة N1 والميزة N2 ليسا متماثلين ، إنه جزء مهم للغاية هنا ، فهما لا يغطيان بعضهما البعض.

شكرا

playerx لقد طرحت مستكشف الحلول لأن وصف هذه المشكلة يشير إلى Visual Studio 2015 وعلى حد علمي لا يوجد سوى مستكشف الحلول.

بصرف النظر عن VS ، يضع مشروعنا جميع ملفات MAP و JS التي تم إنشاؤها في مجلد out ، وليس على نفس مستوى ملفات TS وأنا متأكد من أن هناك مشاريع أخرى تفعل الشيء نفسه. نقطتي هي أنني أتوقع تداخل هذه الملفات ضمن ملفات TS بنفس الطريقة التي تفعل بها ذلك عندما تكون على نفس المستوى.

بالنسبة لي ، لا يتعلق التداخل بتجميع الملفات ذات الامتداد نفسه معًا ، بل يتعلق بعرض الملفات معًا التي تنتمي منطقيًا إلى بعضها (ويعرف أيضًا باسم "الموارد المشتقة"). هل هذا منطقي؟

playerx N2 يبدو أفضل بكثير. بالنسبة لمستخدمي الزاوية 2 cli ، لا ينبغي أن يتطلب ذلك اصطلاح التسمية هذا. ربما يمكن أن يكون هناك بعض الأنماط القابلة للتكوين مثل تكوين إخفاء الملفات.

ينشئ Angular2 cli ملفات مثل هذا:

my.component.ts
my.component.html
my.component.scss / css / أقل

mbeckenbach مثال جيد ، شكرا

يعد تضمين ملفات

أريد أن أسأل الجميع ، دعنا نضع كل مثال عملي ممكن هنا (ليس من فضلك نظريًا) ، الذي سنستخدمه في الحياة اليومية ودعونا نتوصل إلى حل بناءً على تلك الأمثلة.

لنكن السؤال:
كيف تجعل المستكشف "أكثر ذكاء" لتصور صورة حقيقية لهيكل الملفات بطريقة أكثر أناقة؟

bpasero حسنا؟ ما زلت أحاول عدم خلط الميزة N1 والميزة N2.

السيناريو 1:
قبل:

my.component.ts
my.component.html
my.component.scss
my.component.spec.ts

بعد (الخيار 1):

my.component.ts
- my.component.html
- my.component.scss
- my.component.spec.ts

بعد (الخيار 2):

my.component.ts
- my.component.html
- my.component.scss
my.component.spec.ts

بعد (الخيار 3):

my.component.html
- my.component.ts
- my.component.scss
my.component.spec.ts

السيناريو 2:
قبل:

webpack.config.js
webpack.config.commin.js
webpack.config.dev.js
webpack.config.prod.js

بعد:

webpack.config.js
- webpack.config.commin.js
- webpack.config.dev.js
- webpack.config.prod.js

playerx إضافة واحدة: يقوم أيضًا بإنشاء هذا الملف: my.component.spec.ts

لقد قمت بإخفاء ملفات المواصفات لأنني لا أقوم باختبار الوحدات التجريبية للمشاريع. :-)

شكرًا ، السيناريو 1 المحدث ، يرجى تحديد الخيار الذي ستختار استخدامه بعد ذلك

السيناريو 1 الخيار 1 يناسب الأفضل في رأيي.

1. يمكن أن يوجد مكون زاوية 2 بدون ملف html (قوالب مضمنة)
2. سيسمح بأسماء ملفات إضافية مثل my.component.animations.ts على سبيل المثال إذا قرر الفريق الزاوي استخراج المزيد من الأجزاء في عدة ملفات يومًا ما

السيناريو 1 ، الخيار 1 قدم! +1 بسبب اصطلاحات تسمية angular2

seveves ، أريد بالتأكيد الحصول على هذه الميزة ولكن يجب أن أقول إن اصطلاحات تسمية Angular 2 سيئة للغاية. لا ينبغي أن يعتمد دعم هذه الميزة على دليل نمط تعسفي محدد لإطار العمل الذي يملي اصطلاحات التسمية بناءً على الحاجة إلى بيئة عمل مطور ضمن أدوات إنشاء ما قبل ES Module التي لم تعد ذات صلة بإطار العمل الذي يستخدمها. مرة أخرى ، أريد أن أرى دعمًا لهذه الميزة ولكن أعتقد أن هذا هو السبب الخطأ.

aluanhaddad - لا تخرج عن الموضوع كثيرًا هنا ، ولكن هل لديك مثال على ما يمكن أن يكون

تتم تسمية جميع الملفات بنفس الاسم خارج الامتداد (ملف + .spec) ، والذي من الواضح أنه ليس خاصًا بالزاوية 2. السؤال المطروح هو ما هو ترتيب أولوية الامتدادات ذات الملفات ذات الأسماء المتشابهة: والتي تعتبر أولية للمجموعة تحتها.

أعتقد أنه مع هذا السيناريو (أنواع جانب العميل) ، ستكون الأولوية: TS ، JS ، HTML ، [أنواع الأنماط]. سيكون لديك دائمًا ملف TS أو JS ، لكن ليس بالضرورة نموذجًا أو نمطًا

سيكون هذا أنيقًا حقًا !!

playerx علق في أكتوبر 15 2016 • edited

للاقتراح:

N1. تحويل مستكشف الملفات إلى عرض منطقي
مثال: يمكنك ربط fileA ("directoryX / fileA") ، بـ fileB ، والذي يتم وضعه في الدليل

أنا متأكد من أن هذا متاح في أي نظام تشغيل حالي ؛ لقد دعمت الويندوز "الوصلات" لعدد قليل من الإصدارات الآن ، وحتى لديها أمر MKLINK الآن.

بالنظر إلى ذلك ، لا أرى حاجة فعلية لخيار N1 ، وأود أن أوصي بتعليق ciel (تم التعليق عليه في 13 مايو 2016) للتداخل على أساس التمديد.

ماذا عن استخدام مجموعة قواعد قابلة للتكوين بشكل أو بآخر مثل:

"*.component.ts": [  
   "$(basename).component.html",  
   "$(basename).component.spec.ts",  
   "$(basename).component.js",  
   "$(basename).component.js.map",  
   "$(basename).component.spec.js",  
   "$(basename).component.spec.js.map"
]

هناك خيار آخر وهو استخدام أنماط RegEx بدلاً من ذلك.

سيؤدي هذا إلى تداخل الملفات المطابقة للأنماط بالترتيب المحدد بواسطة الأنماط. هذا يفتح مجموعة واسعة من خيارات التكوين ، ولا يقتصر على اصطلاح Angular 2 (لا يقتصر حتى على ts / js / html) ويوفر إمكانية التنبؤ والاتساق.

أعتقد أن تقديم طرق عرض الحل كما هو الحال في Visual Studio يضيف تعقيدًا غير ضروري إلى VSCode ويجعله يفقد تجربة التحرير خفيفة الوزن.

aluanhaddad - لا تخرج عن الموضوع كثيرًا هنا ، ولكن هل لديك مثال على ما يمكن أن يكون

حقًا ، لن أغير كثيرًا من وجهة نظر منطقية

my.component.html
- my.component.ts
- my.component.scss
my.component.spec.ts

قد يصبح

my.html
- my.ts
- my.scss
my.spec.ts

😆
لأنه من الواضح أنه مكون ...

كنت أعترض على اصطلاحات تسمية Angular 2 الخاصة بجون بابا. أعترض على تسميته للمكونات والأنابيب والخدمات والوحدات وبقية الهراء الزائد. لقد توصل إلى تلك الاصطلاحات لـ Angular 1 عندما كان يستخدم تكوينات Grunt لتجميع الوحدات النمطية المغلفة يدويًا IIFE ووحدات التحكم والخدمات والتوجيهات (كل هذه كانت فكرة جيدة في ذلك الوقت). كان يكفي لتمكين التجميع ومهام Grunt الأخرى لتحميل جميع ملفات .module أولاً حتى لا تنفجر البرامج النصية التي سجلت وحدات التحكم والخدمات وما إلى ذلك عند التحميل.

ومع ذلك ، كان دليل أسلوب Angular 1 الخاص به لا تشوبه شائبة تقريبًا من جميع النواحي الأخرى ، وكانت هذه السيناريوهات ذات صلة في ذلك الوقت ، لكن دليل أسلوب Angular 2 (الرسمي) فظيع. ثم مرة أخرى ، من يمكنه كتابة دليل أسلوب أنيق لشيء قبيح بطبيعته؟

أعتقد أن File Nesting أمر لا بد منه في التطوير الحديث ، وخاصة تطوير الويب ...

من فضلك ، من فضلك ... فكر في دعمها.

يبدو أن ما نريده حقًا هنا هو نظام عرض منطقي مخصص بجوار المستكشف المادي.

لنتخيل أن لدينا مشروع بهيكل (معقد عن قصد):

- app
    - logic
        - helpers
            - {helper}.ts
            - {helper}.spec.ts
        - component-logic
            - {component-name}.ts
            - {component-name}.spec.ts
        - viewmodels
            - {viewmodel-name}.ts
            - {viewmodel-name}.spec.ts
    - views
        - {viewmodel-name}.html 
        - {shared-view-name}.html
    - styles
        - {some-common-style-file}.scss
        - {viewmodel-name}.scss
        - {shared-view-name}.html

نحتاج إلى مستكشف منطقي يتيح لنا تحديد كيفية تجميع الملف وكيفية عرضه. قد تكون المجموعات متداخلة لذلك ينتهي بنا الأمر بالحصول على طريقة عرض غير مرتبطة ببنية المجلد. دعونا نتخيل مثل هذا العرض المنطقي التكوين:

{
    "name": "Components",
      "root": "Defines groups to be displayed on the top of the tree",
    "root": ["viewmodelsDirectory", "helpersDirectory"],
    "groups": [{
        "name": "viewmodelsDirectory",
        "displayAs": "viewmodels",
        "groups": ["viewmodel"]
    }, {
        "name": "helpersDirectory",
        "displayAs": "viewmodels",
        "groups": ["helper"]
    }, {
        "name": "viewmodel",
          "headGroup": "Which file is on the top of the group. If omitted then this group displays as directory",
        "headGroup": "viewmodel",
        "pattern": "app\/viewmodel\/(*+)\.html",

          "files": "For each path that match pattern we build a file group",
        "files": [{
            "name": "viewmodel",
              "displayAs": "Pattern explaining how to display this entry. Might accept placeholders like {fileName}, {filesGroupName}, {fileNameWithExtension}, {Extension}",
            "displayAs": "{fileName}",
            "pattern": "app\/viewmodels\/\1\.ts",
            "optional": false
        }, {
            "name": "logic",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/logic\/component-logic\/\1-logic\.ts",
            "optional": false
        }, {
            "name": "view",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/views\/\1\.html",
            "optional": false
        }, {
            "name": "style",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/styles\/\1\.csss",
            "optional": true
        }]
    }, {
        "name": "helper",
        "headGroup": "helper",
        "pattern": "app\/logic\/helpers\/(*+)\.ts",
        "files": [{
            "name": "helper",
            "displayAs": "{fileName}",
            "pattern": "app\/viewmodels\/\1\.ts",
            "optional": false
        }]
    }]
}

ضمن هذا العرض ، يجب عرض ملفاتنا على النحو التالي:

- viewmodels
    - {viewmodel-name}
        - view
        - style
        - logic
- helpers
    - {helper}

لاحظ أنه في المثال الحالي يتم إخفاء ملفات المواصفات تمامًا. وهي مصنوعة لجعل المستخدم يركز على الكود. في مثل هذه الحالة ، سيكون لدى المستخدم وجهة نظر منطقية منفصلة تقدم له اختبارات الوحدة بالطريقة التي يحبها. يجب أن يكون قابلاً للتكوين على مستوى مساحة العمل والمستخدم والامتداد. يجب أن يكون المستخدم قادرًا على التبديل السريع بين طرق العرض من اختصارات الواجهة ولوحة المفاتيح.

هذه مجرد مسودة ولكن آمل أن تقدم الفكرة بوضوح.

ما زلت آمل حقًا أن يعمل هذا. إنه أمر مهم جدًا للتنظيم.

هذا أيضًا ينطبق بشكل متزايد على Aurelia أيضًا. هيكل مشابه جدًا للزاوية 2+. ستؤدي إضافة تداخل ملف (قابل للتكوين) إلى قطع مجلد موسع بالكامل src مع العناصر الفرعية المطوية في أحد مشاريعنا المتوسطة بطول 2/3.

@ RichiCoder1 نعم بالفعل ، ولحسن الحظ ، تستخدم Aurelia اصطلاحات تسمية منطقية وغير زائدة عن الحاجة :)
هل قمت بفحص امتداد aurelia vscode والأمر Open-Related-File الخاص به . لا تتعلق حقًا بالتداخل ولكنها مفيدة جدًا.

أود أيضًا إعادة تسمية مجموعة في عملية إعادة تسمية واحدة.

لقد أصبح هذا أمرًا مهمًا للغاية عندما تبدأ العمل على تطبيق زاوي ضخم ، يرجى مراعاة ذلك لإحضار vscode ، مقابل الحصول عليه بالفعل ، إذا لم يكن كذلك ، فيرجى تقديم تجربة مماثلة لتداخل الملفات لدينا في مقابل

يا رجل ، هذا من شأنه أن يجعل تطبيق Angular الذي أعمل عليه أقل تشويشًا ومنفرجة. أتمنى مخلصًا أن تفكروا بجدية في ذلك يا رفاق.

كما قلت في عدد آخر ..

أكبر سبب أريد هذا هو الزاوية ، حيث لدي العديد من الملفات المسماة المتشابهة معًا ؛

/app
.../home.ts
.../home.component.ts
.../home.template.html
.../home.styles.scss
.../home.component.spec.ts
.../nav.ts
.../nav.component.ts
.../nav.component.spec.ts
.../nav.template.html
.../nav.styles.scss

إذا كان يمكن أن يعشش هؤلاء ، فسيكون رائعًا.

أقوم أيضًا بعمل نمط الأوامر / الوسيط ، وبالتالي ينتهي بي الأمر بملفات تشبه ...

/src/
.../Identity/
....../CreateUserRequest.cs
....../CreateUserRequest.Handler.cs
....../ConfirmUserExistsRequest.cs
....../ConfirmUserExistsRequest.Handler.cs
....../ConfirmUserValidationRequest.cs
....../ConfirmUserValidationRequest.Handler.cs

يصبح الأمر مطولًا جدًا وستجعل هذه الميزة يومي.

هذا هو السبب الوحيد الذي يجعلني ما زلت أستخدم WebStorm ...

نعم ، نحن أيضًا.

في 2 حزيران (يونيو) 2017 ، الساعة 10:10 صباحًا ، كتب MigFerreira [email protected] :

هذا هو السبب الوحيد الذي يجعلني ما زلت أستخدم WebStorm ...

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

سؤال غبي: هل يمكن لشخص ما تقديم لقطة شاشة كيف تبدو؟ لا أستطيع أن أتخيل ما هو المعنى وراء ذلك.

آه ، حسنًا ، شكرًا.

أصبح هذا الآن أكبر ميزة مفقودة بالنسبة لنا. لدي زملاء في العمل لن يستخدموها بسبب عدم وجود هذه الميزة. إنه ألم حقيقي عندما تحاول العثور على ملف معين عندما يكون للعديد منهم أسماء متشابهة. لقد حاولنا إضافة المزيد من المجلدات الفرعية لكل مكون (Angular) ، ولكن هذا ليس حلاً مثاليًا وقمنا بالعودة إلى مجرد سرد كافة المكونات ضمن مجلدات الميزات (والميزات الفرعية).

أقوم بتقديم TypeScript و Angular لمشروع Dojo كبير ، ويمكنني القول أن هذه الميزة ستصبح مهمة جدًا لمستخدمي VSCode في فريقنا في الأشهر العديدة القادمة.

أنا أعمل حاليًا على مشروع Angular وستكون القدرة على تجميع الملفات ذات الصلة إضافة ممتازة إلى منتج ممتاز بالفعل. مع نمو مشروع Angular ، تزداد صعوبة التنقل ويعوق الإنتاجية حاليًا.

مكرر من # 13754:

IMO ، الحل الأكثر أناقة هو ترك الأمر للمشروع. كما في .vscode/settings.json أو ربما project.json . استخدم شيئًا مثل صيغة استبعاد الملف. سيسمح هذا بالتخصيص لكل مشروع أو لكل مجلد. يمكن لمشرفي الإطار / الأداة ، أو VSCode ، أو جهة خارجية توزيع مجموعات الأنماط لمهام سير عمل معينة.

بهذه الطريقة ، لا يفترض VSCode أي شيء ولا يتسبب في حدوث مشكلات لأحد. يمكن أن يكتشف المرشحين المحتملين للتداخل ، وينبثق تنبيه يسأل ، "يبدو أن لديك ملفات يجب أن تتداخل. هل تريد تطبيق أحد ملفات التعريف الافتراضية المتداخلة؟"

إذا أراد المطورون تداخلًا منطقيًا ، فيمكنهم الحصول عليه. إذا كانوا لا يريدون ذلك ، فهم لا يضيفون الإعدادات.

لالتقاط my-component.A.B تحت my-component.ts (AngularJS 2):

"files.nest": {
    "**/*.*.*": {"when": "$(basename).ts"}
}

لالتقاط my-component.dev.ts تحت my-component.ts :

"files.nest": {
    "**/*.*.ts": {"when": "$(basename).ts"}
}

أو للملفات التي تم إنشاؤها (باستخدام هيكل التنقل Aurelia حيث يتم إنشاء الملفات في dist/ ):

// TypeScript => ES5
"files.nest": {
    "dist/src/**/*.js": {"when": "src/$(dir)/$(basename).ts"}
}

// ESNext => ES5
"files.nest": {
    "dist/src/**/*.js": {"when": "src/$(dir)/$(basename).js"}
}

// Less => CSS
"files.nest": {
    "dist/src/**/*.css": {"when": "src/$(dir)/$(basename).less"}
}

// Mappings
"files.nest": {
    "dist/src/**/*.map": {"when": "src/$(dir)/$(basename)"}
}

باستخدام بعض النحو المحدد جيدًا مثل هذا ، يمكنني إضافة أي مخطط متداخل أريده ، طالما أنه ليس معقدًا بشكل مفرط. يعتمد المثال الأخير على معالجة gulp للمسارات ( $(path) = المسار الذي يبدأ بالكرة الأرضية الأولى).

أود الحصول على بعض المعلومات أو التعليقات حول ما إذا كان هذا قيد النظر أم لا. كما هو الحال الآن ، لن أستخدم VS Code لأي مطور Angular أو Aurelia حتى تكون ميزة مضمنة.

threedaysmore لا يوجد ما يشير إلى أن فريق VSCode يفكر في الأمر حقًا (كما هو الحال في ، فقد انخفض إلى نهاية التراكم). يعالجها PR # 13754 ولكن يبدو أن playerx قد أسقطها ، مؤقتًا على الأقل.

لقد أنشأت المزيد من العلاقات العامة المحدثة: # 32061. أنا أبحث عن مساعدة لأن تعاملي مع بعض الأشياء (أي نموذج الشجرة) هو عربات التي تجرها الدواب.

+1

+1

+1

لست متأكدًا من كيفية إظهار أنني مهتم بهذه الميزة. لا يبدو أن +1 طريقة جيدة جدًا لأنها سترسل سلسلة رسائل غير مرغوب فيها (ويعطيه الأشخاص إبهامًا لأسفل). ما هي الطرق الموصى بها لإعطاء 1+ أو "أرغب في استخدام هذه الميزة" لمشكلة جيثب ، فقط لإظهار اهتمامي؟

فقط أضف إبهامًا لتعليق المؤلف الأول ، للإشارة / زيادة أهمية هذه الميزة

bpasero أغلقت طلب السحب # 32061: "شكرًا للعلاقات العامة ، لكننا لا نقبله لهذه المساحة الكبيرة." (تم الاعتراف بأن طلب السحب الخاص بي كان جنينيًا جدًا).

هل يمكن للمشرف أو أي شخص آخر التوسع في هذا على الإطلاق؟ أو تقديم أي إرشادات حول كيفية تنفيذ ذلك كطلب سحب أو تمديد؟

@ firelizzard18 كنت أرغب بشدة في استخدام هذه الميزة ، وقضيت بعض الوقت في العمل عليها وحصلت على نفس التعليقات. أعتقد أن هناك سببًا لعدم رغبتهم في هذه الميزة ، لكنهم لا يخبروننا :)

تضمين التغريدة
أعتقد أن هذه الميزة تستحق المزيد من التوجيه منك (من المساهمين) ، وكيف يمكن القيام بها ، وكما ترى ، هناك أشخاص يمكنهم قضاء وقتهم في تحقيق ذلك.

سيكون من الرائع أن يكون لديك ملف متداخل في VS Code أيضًا.
لقد غيرت مؤخرًا من VS 2017 إلى VS Code للبرمجة Angular / الواجهة الأمامية لتطبيق ASP.NET Core ، بسبب دعم / تكامل Angular بشكل أفضل. إنه يعمل بشكل أفضل ، لكني أفتقد تداخل الملفات بشدة. :-(

يرجى إضافة ميزة تداخل الملفات إلى VS Code أو إعطاء الآخرين إمكانية تطوير امتداد!

https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/
أو
https://marketplace.visualstudio.com/items؟itemName=MadsKristensen.FileNesting

bpasero أشعر بالفضول لمعرفة ما إذا كان بإمكاننا الحصول على أي تحديثات بشأن هذا من الفريق؟ كان هناك الكثير من النشاط من عدة أشخاص على مدار عدة سنوات ؛ تم إغلاقه وإعادة فتحه ورفض العديد من التطبيقات بأقل قدر من التوجيه. هل ما زالت هذه الوظيفة مطلوبة؟

هناك حالات استخدام قوية لمجتمعات React و TypeScript ، وكانت مشاعر المطور إيجابية باستمرار (والتي أود التأكيد عليها شخصيًا أيضًا). شكرا لك مرة أخرى

develleoper أعتقد أنهم جعلوا توقعاتهم واضحة تمامًا. يريدون أن يكون قابلاً للتخصيص بالكامل ليتم قبوله. ليس من المنطقي السماح بأي شيء لا يمنحك التحكم الكامل في مستكشف الملفات. الجزء الصعب هو أنه يجب عليك السماح بإنشاء / تحريك الملف بينما قد يكون الهيكل في IDE الخاص بك مختلفًا تمامًا عن الهيكل المادي. أعتقد أيضًا أنهم يتوقعون السماح بالتبديل بين طرق عرض متعددة (على سبيل المثال: يمكن أن يكون لديك سياق ملف وسياق اختبارات الوحدة. اكتب اختبارات في أحدهما ثم انتقل إلى آخر لإرضائها).

أنا متأكد تمامًا من أنهم على دراية بحالات الاستخدام ، ولكن إذا نظرت إلى خريطة الطريق ، فربما ترى أن خططهم أكثر طموحًا وفائدة من هذه الخطة ، ولهذا (أعتقد) سبب قرارهم ترك هذه الخطة للمجتمع .

أعتقد أنك أكثر من موضع ترحيب لمنحها فرصة - فرصة عمل رائعة في Micro $ في كثير من الأحيان تنتظر الشخص الشجاع ؛)

"Micro $ oft" LUL - أنا مندهش من أن المراهقين ذوي الخبرة المحدودة يتابعون هذا الموضوع على الإطلاق.

_Anway_، develleoper - لوحتهم الخاصة على الجانب ، لذلك عندما يتم إصدار ذلك قريبًا ، من المحتمل أن يقوم بعض صانع الإضافات بعمل امتداد لإظهار شجرة ملف منطقي بدلاً من شجرة فعلية .

waynebloss IMO ، لا ينبغي ترك هذه الميزة كامتداد محتمل يتطلب لوحة جديدة. لن يتطلب هذا الأسلوب إعادة تطبيق شجرة الملفات بكل ميزاتها الحالية فحسب ، بل يتطلب أيضًا تحديثها بأي ميزات مستقبلية تتم إضافتها. نعم ، يمكن تقسيم كود شجرة الملف الحالي إلى امتداد ، لكن هذا لا يقلل من عبء الصيانة لتتبع تحديثات الوظائف المستقبلية.

على الأقل ، يمكن أن تمنح شجرة الملف نفسها نقاط قابلية للتمدد كافية لتنفيذ ذلك. (من المحتمل أن تكون إضافة ذلك وبناء امتداد لاستخدامه لهذه الميزة عملًا مبدئيًا أقل على أي حال.)

وافقت RoyTinker - كنت أفكر في أن اللوحة الجديدة ستكون مجرد حل بديل حتى يتم دعم تداخل الملفات رسميًا.

Wayofthesin لست متأكدًا على الإطلاق مما تحاول الوصول إليه. لا أعتقد أن أي شخص يتساءل بجدية عما إذا كان المجتمع يريد هذه الميزة ، حيث أوضحنا بشكل واضح أننا نفعل ذلك. وما هو واضح بنفس القدر ، إذا قرأت التاريخ بالفعل ، هو أن المجتمع قد حاول تنفيذ ذلك وقال المطورون "لا". قدم playerx طلب سحب وقيل له "لا". لقد قدمت طلب السحب الخاص به واندمجت في أحدث فرع رئيسي في تلك المرحلة ، وقمت ببعض التعديلات ، وقدمت ذلك. وقيل "لا".

لذلك يجب أن يكون واضحًا تمامًا أن المجتمع يريد ذلك وليس للمطورين أي مصلحة في قبول مساهمة المجتمع من أجل ذلك.

develleoper وغيرها، وأعتقدbpasero الصورة تعليقات علىplayerx الصورة PR تخبرنا الكثير عن مكان الفريق VSCode يريد أن يذهب مع هذا: https://github.com/Microsoft/vscode/pull/13754

أفهم من تعليقاته أن @ bpasero :

• يريد نهجًا شاملاً يلبي احتياجات جميع المجموعات التي تريد رؤية منطقية من نوع ما
• يفكر في تداخل الملفات كعرض منطقي (على عكس طريقة عرض نظام الملفات المادية)
• يعتقد أن وجهة النظر المنطقية يجب أن تكون منفصلة عن العرض المادي لنظام الملفات

في رأيي ، على الرغم من أن تداخل الملفات _is_ يعد تغييرًا منطقيًا للعرض ، فإن إخفاء الملفات أيضًا مدعوم حاليًا في شجرة الملفات ويمكن تكوينه عبر الإعدادات. يبدو لي أن تداخل الملفات هو مجرد شكل آخر من أشكال إخفاء الملفات ، إلا أنه يوفر طريقة للكشف عن تلك الملفات.

جانبا ، يدعم Atom الآن تداخل الملفات عبر حزمة عرض الشجرة الخاصة بهم - راجع https://github.com/atom/tree-view/issues/572

@ firelizzard18 لقد رأيت طلب السحب الخاص بك. أنا فقط علقت أفكاري. # 32061.

RoyTinker علق جيدًا ماذا يتوقعون. يمكنك التحدث عن إنشاء العلاقات العامة ولكن بقدر ما أستطيع أن أرى حتى التوقع الأول من bpasero قد تم تحقيقه:

بصرف النظر عن VS ، يضع مشروعنا جميع ملفات MAP و JS التي تم إنشاؤها في مجلد خارجي ، وليس على نفس مستوى ملفات TS وأنا متأكد من أن هناك مشاريع أخرى تفعل الشيء نفسه. نقطتي هي أنني أتوقع تداخل هذه الملفات ضمن ملفات TS بنفس الطريقة التي تفعل بها ذلك عندما تكون على نفس المستوى.

كإضافة إضافية أود أن أضيف: لا تفكر في المستكشف الافتراضي مثل مستكشف الملفات. قد يرغب شخص ما في إجراء تداخل للكائنات التي تم تصديرها ضمن ملف نصي.

أعتقد أن هذا سبب عدم قبولهم للعلاقات العامة. إنهم ليسوا مهتمين بالتصحيح على الكود الموجود. إنهم يبحثون عن حل مرن ليس فقط قابل للتكوين ولكن قابل للتمديد أيضًا. يبدو أنه ليس لديهم فكرة عن ذلك بأنفسهم لكنهم يعرفون إلى حد كبير ما لا يريدون.

المشكلة التي أراها هي أننا نحاول تخمين سبب عدم قبولهم للعلاقات العامة وليس هناك إجابة وتوجيه واضحين. جميع التعليقات التي قدمتها يا رفاق هي تفسيراتك لما

الكثير من المحادثات ولا يزال الصمت من المساهمين ، أعتقد أن هذا ليس جيدًا للمنتج نفسه.

Wayofthesin ، ضرب playerx الظفر على رأسه: كلانا واضح في حقيقة أن bpasero يريد شيئًا أكثر مما نقدمه ولكن bpasero فشل في تقديم ملاحظات كافية bpasero علاقاتي العامة بتعليق غامض للغاية. فيplayerx الصورة الحالة، علقbpasero، "نحن في نهاية اللعبة حاليا، وسوف تكون قادرة على العودة إلى هذه الشهر المقبل فقط"، وليس لديه تعليقات أخرى في العام الماضي ونصف.

العلاقات العامة الخاصة بي كانت عملاً قيد التقدم. أردت توجيهات من المطورين حول كيفية المضي قدمًا. وبدلاً من ذلك ، تلقيت ردًا خفيًا وأغلقت العلاقات العامة الخاصة بي.

تعليقي ، الذي أشرت إليه في مراجعتك للعلاقات العامة الخاصة بي ، اقترحت خطة لمعالجة مشكلاتbpasero مع (عدم وجود) عمومية نهج playerx . في العلاقات العامة الخاصة بي ، بدأت العمل على تنفيذ بعض وليس كل هذا ، لأنني كنت في منطقة غير مألوفة للغاية وأردت التوجيه قبل المضي قدمًا.

أنا فقط أمزح. أراد رفع المزاج قليلا. الرجاء التحقيق في هذا. من الصعب حقًا العمل مع هذا النوع من عرض المشروع. انها ليست صعبة ولكن غير فعالة.

+1 ، موافق ، هذه الميزة مفيدة جدًا لتطوير تطبيق wechat mini أيضًا

هل هذا صعب جدا لفعله؟ يحتاج حوالي 2 مليون عضو في مجتمع Java إلى هذه الميزة في أسرع وقت ممكن. من فضلك....!!!

يبدو أن VS Code لديه بعض الدعم لتداخل الملفات الافتراضية في عرض الشجرة. تضمن سجل التغيير للإصدار 1.29 هذه النقطة:

يبدو أن هذا يشير إلى أنه تم إنشاء أساس لتجميع الملفات.

MortenChristiansen mmm ... يبدو أنها ليست نفس الميزة '

كاقتراح ، يحتوي Visual Studio 2017 على ميزة لتداخل الملفات عبر ملف تكوين

• https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/

كمثال:

{
  "help": "https://go.microsoft.com/fwlink/?linkid=866610",
  "root": true,

  "dependentFileProviders": {
    "add": {
      "addedExtension": {},
      "pathSegment": {
        "add": {
          ".*": [
            ".js",
            ".css",
            ".html",
            ".htm",
            ".less",
            ".scss",
            ".coffee",
            ".iced",
            ".config",
            ".cs",
            ".vb",
            ".json"
          ]
        }
      },
      "extensionToExtension": {
        "add": {
          ".js": [
            ".coffee",
            ".iced",
            ".ts",
            ".tsx",
            ".jsx",
            ".vue"
          ],
          ".css": [
            ".less",
            ".scss",
            ".sass",
            ".styl",
            ".vue"
          ],
          ".html": [
            ".md",
            ".mdown",
            ".markdown",
            ".mdwn"
          ],
          ".map": [
            ".js",
            ".css"
          ],
          ".svgz": [
            ".svg"
          ],
          ".designer.cs": [
            ".resx"
          ],
          ".cs.d.ts": [
            ".cs"
          ],
          ".ts": [
            ".vue"
          ],
          ".scss": [
            ".vue"
          ],
          ".sass": [
            ".vue"
          ]
        }
      },
      "fileToFile": {
        "add": {
          ".bowerrc": [
            "bower.json"
          ],
          ".npmrc": [
            "package.json"
          ],
          "npm-shrinkwrap.json": [
            "package.json"
          ],
          "yarn.lock": [
            "package.json"
          ],
          ".yarnclean": [
            "package.json"
          ],
          ".yarnignore": [
            "package.json"
          ],
          ".yarn-integrity": [
            "package.json"
          ],
          ".yarnrc": [
            "package.json"
          ]
        }
      },
      "fileSuffixToExtension": {
        "add": {
          "-vsdoc.js": [
            ".js"
          ]
        }
      },
      "allExtensions": {
        "add": {
          ".*": [
            ".tt"
          ]
        }
      }
    }
  }
}

نتوء 🏗

سيكون مفيدًا للملفات التي تم إنشاؤها تلقائيًا في dart أيضًا.

سيكون هذا مفيدًا لملحقات Salesforce أيضًا. تحتوي مشاريعنا على ملف *.meta.xml مرتبط بكل ملف تعليمات برمجية ، لذا فهو يجعل شجرة الملفات لدينا ضعف الطول بشكل فعال. نود أن نضع ملف البيانات الوصفية هذا تحت الملف المصدر.

لا أعتقد أن جمع متطلبات / احتياجات المستخدمين حول ميزة التداخل يمثل مشكلة.
لا أعتقد أن تطبيقه يمثل مشكلة. ربما بعض التبرعات ستساعد على تنفيذه بشكل أسرع في الإصدارات الرسمية؟

يحدق في ملفاتي ،
كتابة ، وشبكة ، وأنماط مكدسة بدرجة عالية.
سيكون التعشيش لطيفا.

آسف شباب. لا يبدو أنهم مهتمون بهذا على الإطلاق.

يا رجل ، أود أن أرى هذا أيضًا.

غريب - سلوك هذه الميزة محدد جيدًا ومن الواضح أنه مطلوب بشدة.

+1 تعال يا رفاق

هذا لا يحدث يا رفاق ، لذا من المحتمل أن أغلق المشكلة.

أوضحisidorn أنهم غير مهتمين به ولا يحاولون القيام بذلك. وهو أمر مؤسف. هذا كل ما يمنعني من استخدام VSC الآن. تطبيق Angular هو مجرد مطول وفوضوي بدون تداخل الملفات.

أعتقد أنني ما زلت عالقًا مع WebStorm في الوقت الحالي.

أقترح إبقاء هذه المشكلة مفتوحة وقد نعالجها في المستقبل القريب.

isidorn ، بالنظر إلى "ليس المستقبل القريب" ، هل أنت قادر على تقديم إرشادات حول كيفية تنفيذ ذلك؟ أود أن أجربها ، لكنني لم أتلق أي ردود فعل على MR الخاص بي.

2019 ، أي شيء جديد يا شباب؟

بصفتي مطور جافا ، هذا هو الشيء الرئيسي الذي يمنعني من الهجرة بشكل كامل إلى vscode.

في مشاريع جافا الخاصة بي ، تشغل الدلائل الفارغة لمساحات أسماء حزم جافا نصف (أو أكثر) من المساحات المتاحة في المستكشف. يجب علي دائمًا التمرير لأعلى / لأسفل في المستكشف وهو نوع من مضيعة للوقت عندما يتعين عليك القيام بذلك عدة مرات لكل تكرار dev. تعمل العديد من IDEs لتطوير Java على طي هذه الأدلة الفارغة في اسم حزمة واحد ، مما يسهل على المطورين إلقاء نظرة على بنية الحزمة بأكملها.

هل هذا شيء يمكن تنفيذه في vscode ولكن ليس له الأولوية بسبب المهام الأخرى ذات الأولوية الأعلى؟ أم أن هذا غير ممكن للتنفيذ بسبب القيود في بنية vscode الأساسية؟

أي تمديد لأداء هذا؟ إنها ميزة مطلوبة بشدة!

تم فتحه منذ أكثر من 3 سنوات ... لا يبدو أنهم سيفعلون ذلك ... جارٍ تثبيت Webstorm الآن ...

هذا والمسافة البادئة مع لصق بعض الأشياء الأساسية جدًا التي تشعر أنها ستتم معالجتها ، ربما يكون هذا هو ما تحصل عليه مقابل البرامج المجانية ومفتوحة المصدر. ليست جيدة ... لأنه لا يوجد جلد في اللعبة.

نعم - استجابة مخيبة للآمال للغاية (أو عدم وجود) من فريق تطوير ممتاز.

لقد قمت بعمل تداخل مخصص ، لكن طلب السحب الخاص بي لن يتم دمجه. نظرًا لأن فريق VS code لديه خطط أخرى ولا يريد إجراء تغييرات على هذا الجزء من الكود. بالنسبة لي ، هذه الميزة مهمة أيضًا ، لذلك قمت بإنشاء Vs Code مخصص (يعمل متجر الإضافات) ، يمكنك تجربته https://github.com/floatas/vscode/releases/tag/1.37 سوف نرى كيف يسير التقدم في هذا المشكلة ، أنا أفكر في عمل شيء مشابه لـ VsCodium (يبني تلقائيًا مع محدث) ولكن مع تغييراتي.

فقط أضف هذا التكوين إلى إعداداتك. json:

    "files.nesting.enabled": true,
    "files.nesting.rules": {
        "(?<basename>.*)\\.ts$": [
            "$(basename)\\.spec\\.ts$",
        ],
        "(?<basename>.*)\\.html$": [
            "$(basename)\\.css$",
            "$(basename)\\.scss$"
        ]
    },

يلزم إعادة تشغيل رمز Vs عند تمكين التداخل.

floatas شكرا على التعليمات البرمجية الخاصة بك! ما رأيك في عمل تمديد؟

@ e-belair للأسف لا يمكن إنشاء امتداد. API لهذه الميزة غير متوفر.

ستكون ميزة تداخل الملفات حلوة جدًا! أتمنى أن يحدث هذا :)

floatas أين العلاقات العامة؟

tariqporter # 72160

floatas (https://github.com/microsoft/vscode/issues/6328#issuecomment-524030094)

نظرًا لأن فريق VS code لديه خطط أخرى ولا يريد إجراء تغييرات على هذا الجزء من الكود.

سيكون هذا هو # 41627 ، والذي سيتم العمل عليه أولاً كجزء من إعادة كتابة treeview ، والتي من المحتمل أن تجعل هذا التنفيذ أسهل بعد ذلك.

أعتقد أن VS Code رائع ولكن هذه ميزة أساسية يجب أن تفتقر إليها.

نتطلع إليها أيضا

أنا في حاجة إليه

مجرد فضول إذا كان هناك أي تحديث على هذا؟ سيكون من الرائع أن تضطر إلى تنظيف منظر الشجرة!

لا تزال تستخدم VS لنظام التشغيل Mac فقط بسبب هذه الميزة مع تطبيقات Blazor. لماذا كل هذه المقاومة من الفريق؟

هل هناك مشكلة في تتبع تنفيذ واجهات برمجة تطبيقات التمديد المطلوبة لجعل ذلك ممكنًا من خلالها؟

بعد 4 سنوات ولم يحدث تقدم في هذه القضية؟ س س ..
هذا أمر محير للعقل أن نكون صادقين ...

لا أستطيع التفكير في أي IDE استخدمته ولا يدعم هذا بطريقة أو بأخرى ، ولا يمكنني التفكير في أي مشاريع على أي منصة عملت عليها حيث لن يكون هذا مفيدًا ... oO .. هذا لدرجة أنني افترضت للتو أن هذا كان معطى في أي IDE ... لا أعتقد ذلك ...

هل يحاول الفريق فقط دفع الناس نحو المنافسين؟ ...
كنت سأحب استبدال WebStorm بـ VSCode ، لكن أعتقد أن هذا لا يحدث. ومن ثم فنحن لسنا قريبين من استبدال VS أو IDEA: S ...

اوه حسنا...

jeme هل تتخيل أن مضايقة المطورين سيكون لها أي تأثير؟ أعلم أنني إذا كنت مشرفًا ، فسأتجاهل بشكل قاطع أي تعليقات معادية. إذا كنت تريد بالفعل أن تكون بنّاءً وليس مجرد حشرة ، فجرب "هذه الميزة مهمة جدًا بالنسبة لي وتمنعني من استخدام هذه الأداة."

@ firelizzard18 ، فستفقد فرصة توفير قاعدة عملاء هناك حاجة ماسة إليها. إن تعلم الاستماع إلى جميع العملاء هو حقًا سمة رائعة يجب امتلاكها ، والارتقاء فوق الحرية إذا جاز التعبير. إذا قرأت التعليقات هنا ، فهناك الكثير من الأشخاص الذين يتصرفون بالطريقة التي تقول إنها يجب أن تجعلهم يستمعون. ومع ذلك ، فهم لا يستمعون وبعد 4 سنوات ستزداد الإحباطات بشكل كبير خاصة إذا كان شخص ما يريد حقًا التبديل ولكن لا يمكنه رؤية طريقة لأن المشروع كبير جدًا بحيث لا يمكن دمج الملفات معًا. أعتقد حقًا أن الكود المرئي هو برنامج مجاني ولا أحد يهتم حقًا بجعل هذا أولوية. وهذا ما نحصل عليه نحن المستخدمين للمطالبة بالبرمجيات الحرة. لا يوجد أي شيء في اللعبة بالنسبة لهم لفعل أي شيء. أنا أدفع مقابل IDE إذا كان ذلك يعني أن أشياء مثل هذه ستوضع في مكانها الصحيح. مرة أخرى لا يزال يستخدم Webstorm (التي دفعت ثمنها). يجب عليهم حقًا أن يخرجوا ويقولوا إننا لن نفعل ذلك ، لذلك نغلق التذكرة وننتهي من ذلك.

إذا قرأت التعليقات هنا ، فهناك الكثير من الأشخاص الذين يتصرفون بالطريقة التي تقول إنها يجب أن تجعلهم يستمعون.

وهل تعتقد أن كونك عدائيًا سيغير الأشياء؟

ما أقوله هو أن رجل الأعمال الجيد لا يهتم بكيفية وصول الرسالة إلى الاستماع إليه. لذلك لن تكون رجل أعمال جيد إذا تجاهلت تلك التعليقات. إذا سبق لك العمل على خط دعم العملاء لأي شركة تقنية ، فستفهم ذلك.

أخيرًا ، نهايتي العامة ، إذا قرأتها كانت تقول ، في كلتا الحالتين ، لا يهم (من خلال التعليقات السابقة كونها لطيفة) أو ليست لطيفة (التعليق الذي تحاضر فيه) لن يفعلوا ذلك لأنهم ليس له جلد في اللعبة فهو مجاني. حقًا هي نقطة خلافية ويجب عليهم إغلاق التذكرة.

هل يمكننا تركيز قسم التعليقات على الحلول والأفكار الممكنة ، بدلاً من الشكوى من سبب عدم حل هذه المشكلة بعد؟ هناك طريقة لإبلاغك بتأثير هذه المشكلة عن طريق استخدام التصويت على وصف المشكلة .

شكرا لك

هناك علاقات عامة مفتوحة لهذا (# 13754) ...
إذا أعلن شخص ما رسميًا عن شوكة وأنشأ موقعًا ثابتًا أساسيًا به ثنائيات لنظامي التشغيل windows apple و linux ... ربما ينقض عليه 1000 مطور زاوي بين عشية وضحاها ، وإذا كان هناك زر تبرع صغير في مكان ما ، فيمكنك أيضًا جني بعض المال على هذا الجهد.
أنا شخصياً لست بحاجة إلى هذه الميزة في الوقت الحالي ، لكن VSCode يخضع لترخيص MIT ، ويريد المجتمع حقًا ميزة ، وقد عمل بعض أعضاء المجتمع بجد لتنفيذ هذه الميزة.
لذا...

ربما يمكنهم إصلاح # 75181 أيضًا! يجب ألا يؤدي عرض لوحة Explorer ببساطة إلى فتح أي علامات تبويب للملفات.

BrunnerLivio أنت تشتكي من الشكوى مضحك للغاية ؛). بدأ هذا لأن شخصًا ما أراد تصحيح أو فرض سلوكه الأخلاقي على شخص آخر حول كيفية تعبير شخص ما عن استيائه أو حاجته أو تصويته. انت تفعل نفس الشيء مرة أخرى ، إنها مجانية ، هذه المشكلة لن تذهب إلى أي مكان. لم يحدث ذلك لمدة 4 سنوات. الجميع يتحدث عن "هم" هذه مجانية. هم الناس في هذا المنتدى هو ما أدركته ، منذ حوالي عام. وأنا أعمل كثيرًا للحصول على الوقت لإجراء هذا التحسين وأفضّل الدفع مقابل IDE ، وهو ما أفعله باستخدام Webstorm.

أنا شخصياً أعتقد أنه سيكون من الجيد الحصول عليها ولكني لن أزعج أي شخص بشأنها
نظرًا لأنه مجاني بشكل أساسي ، فليس الأمر كما لو أن أي شخص يحملهم بموجب اتفاقية مستوى الخدمة أو يدفع أموالًا مقابل الدعم. بما أن كلمة "زبون" تعني منتجًا تم شراؤه

لذا فإن البدائل

1. يقوم شخص ما بتقسيم المصدر ، وإضافة الميزات ، وإصدار طلب سحب ، ثم مطالبتهم بتضمينه
2. كخيار آخر ، يمكنك تجربة Visual Studio 2019 Community وهو أيضًا مجاني (ولكن ليس مفتوح المصدر) نظرًا لأنه يحتوي على تداخل
3. استخدم شيئًا آخر حتى تتم إضافته

أعتقد أن أحد البدائل الأخرى:

أنشئ امتدادًا يحاكي شجرة المستكشف باستخدام زر ولوحة الشريط الجانبي الخاصين به واستخدمه.

وفعلت ذلك.

pt.، 7.02.2020، 02:15 użytkownik Hecatron [email protected]
نابيساł:

أنا شخصياً أعتقد أنه سيكون من الجيد الحصول عليها لكنني لن أزعج أي شخص
تخطى
نظرًا لأنه مجاني في الأساس ، فليس الأمر كما لو أن أي شخص يحتجزهم
لاتفاقية مستوى الخدمة أو دفع الأموال للحصول على الدعم. منذ كلمة
يشير "العميل" إلى منتج تم شراؤه

لذا فإن البدائل

1. شخص ما لتفكيك المصدر ، وإضافة الميزات ، وإصدار سحب
   اطلبها ، ثم اطلب منهم تضمينها
2. كخيار آخر ، يمكنك تجربة Visual Studio 2019 Community وهو
   أيضًا مجاني (ولكن ليس مفتوح المصدر) نظرًا لأن هذا يحتوي على تداخل
3. استخدم شيئًا آخر حتى تتم إضافته

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/vscode/issues/6328؟email_source=notifications&email_token=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63L
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ACJ4R3YUKMXFVOO5NSXSQ6DRBSY3TANCNFSM4CDVJHVQ
.

بعض التقدم لهذا !! اعتقد انه من الضروري جدا في vscode !!

VS Code هو منتج مجاني و Visual Studio الإصدار الكامل هو منتج مدفوع

GeorgeTarazi بناءً على تعليقك ، سأفترض أنك لم تستخدم VSCode مطلقًا أو أنك لم تستخدم Visual Studio مطلقًا. لأنه إذا كنت قد استخدمت كلاهما ، فستعرف أنهما منتجان مختلفان تمامًا. لا يعد Visual Studio بأي حال من الأحوال "الإصدار الكامل" من VSCode.

لا أحد يريد أن يتم إعلامك باستمرار بآرائك خارج الموضوع. ربما ينبغي على المشرفين على المستودع النظر في قفل المناقشة حول هذه المشكلة في الوقت الحالي.

أنا شخصياً وجدت أن إصدار Visual Studio 2019 Community (المجاني) جيد بما يكفي لكل ما أحتاج إلى القيام به
مقارنة بإصدارات Pro / Enterprise القديمة السابقة.
هذا منطقي عندما تنظر إليه من وجهة نظر MS تحاول دفع dotnet كبديل مفتوح المصدر لجافا على سبيل المثال.
على الرغم من أنك ستظل بحاجة إلى ترخيص لاستخدام Studio 2019 من منظور تجاري.

أنا أستخدم كلاً من Studio 2019 و VSCode على الرغم من حالات الاستخدام المختلفة. أفضل VScode ل python ، Studio 2019 الذي أفضله لـ dotnet.
VSCode إذا كنت أعمل على شيء مفتوح المصدر وما إلى ذلك.
لا يتم مشاركة برنامج التحويل البرمجي likley على الأقل ليس مع dotnet لأن هذه أداة خارجية منفصلة راجع للشغل.
تمت كتابة كلاهما أيضًا بلغات مختلفة ، ربما يكون VSCode - Javascript و Studio 2019 مزيجًا من C # و CPP.

أعتقد أن السبب وراء عدم نقل الميزة حتى الآن هو الأثير

1. إنهم يهدفون إلى تنفيذ بعض الميزات الأخرى أولاً مثل شيء متعلق بالامتدادات أو التبعية المطلوبة أولاً
2. فريق مختلف ، مستوى مختلف من الموارد
3. يلزم الكتابة من الألف إلى الياء ، ولا يمكن نسخ اللصق بين اللغات المختلفة.

georgebatalinski أتفق مع معظم ما تقوله. ومع ذلك ، سأقول إنني أجد الكود المرئي مفيدًا للزاوية أكثر من الاستوديو المرئي ، لقد خرج على وجه التحديد عن طريقه ليكون أكثر ملاءمة للمطورين للمنتجعات الصحية الأمامية. أنا أستخدم منتجات VS منذ التسعينيات ، لذا ربما أكون أكبر منك ؛) أعود إلى أيام vb حتى Qbasic. أنا شخصياً تعبت من لي شيء ، أعطني ذلك مجانًا. يسعدني أن أدفع مقابل الكود المرئي للحصول على هذه الميزة المضافة على وجه الخصوص. لكن مرة أخرى ، ما زلت لا أستخدم VC لأنني أشعر أن هذه الميزة ضرورية فقط للتطبيقات ذات الحجم الأكبر في عيني.

هل سيتم تنفيذ هذه الميزة؟
أجده مفيدًا جدًا عند العمل مع مشاريع الويب ، حيث يوجد الكثير من الملفات التي تم إنشاؤها والتي تشوش مساحة العمل (لكن في بعض الأحيان تحتاج إلى النظر إليها ، لذا فإن الاختباء ليس حلاً).

لماذا لا تترك للمستخدم خيار تعطيله / تمكينه واختيار الامتدادات التي تقوم بتشغيله ؟! :-)
يبدو أنه سهل التنفيذ ....

@ funder7 ليس قريبا جدا. أعرب المطورون عن أن لديهم وجهة نظر أيديولوجية مختلفة حول كيفية عمل VS Code ، لذا فهذه ليست أولوية بالضبط.

شكرًا tmarkovski ، أنا أستخدم هذا الآن لإزالة الملفات التي تم إنشاؤها rm -f *.js *.map ... بالمناسبة اكتشفت هذه الميزة في IntelliJ Idea ، إنها سهلة للغاية عند العمل مع المشاريع المعقدة.
إذا لم يكن ذلك في طريقة المطور لرؤية التطبيق ، على الأقل سأبقيه معطلاً بشكل افتراضي ، لكن أترك للمستخدم النهائي خيار تمكينه.
لقد ذكرت فكرة لأن هذا النوع من الميزات بالنسبة لي هو ما يصنع الفرق بين البرنامج الثانوي والبرامج المفضلة لديك.

في الواقع لقد وجدت هذا

        "**/*.js": {
            "when": "$(basename).ts"
        },

يخفي الملفات التي تم إنشاؤها ، ولكنها تختفي بعد ذلك ولا تلاحظ وجودها: /

لقد مرت أكثر من 4 سنوات ، وهو خلود في أرض البرمجيات ، وما زلت لا توجد خطط لتنفيذ ذلك؟ هذا ضخم للإنتاجية عن طريق تقليل العبء الذهني عند المسح من خلال هيكل شجرة ملف ضخم. يسمح بملفات واجهة Typescript المنفصلة دون ظهور عبء الملفات الإضافية في المستكشف.

أي تقدم لهذه الميزة؟

أي تقدم لهذه الميزة؟

تم إغلاق مشكلة مكررة بواسطة أحد أعضاء فريق vscode الأسبوع الماضي ، لذا فهم على دراية بها ولكنهم اختاروا تجاهلها.
تكافح حقا لمعرفة السبب.

تكافح حقا لمعرفة السبب.

لأنها ليست أولوية بالنسبة لهم. كفريق ، قرروا إعطاء الأولوية لأشياء أخرى. يمكنك أن تختلف مع قراراتهم ، ولكن كل هذا النحيب "OMG وعديم الجدوى.

لأنها ليست أولوية بالنسبة لهم. كفريق ، قرروا إعطاء الأولوية لأشياء أخرى. يمكنك أن تختلف مع قراراتهم ، ولكن كل هذا النحيب "OMG _whhhhhy_" هو بغيض ولا طائل من ورائه.

بالنسبة لي ، من غير المجدي أن يقرر أحد المطورين كيف يجب على شخص آخر كتابة التعليمات البرمجية الخاصة به. لهذا السبب تحتوي التطبيقات عادةً على عرض "تفضيلات" ، حيث يمكنك ضبط البيئة كما تريد. نظرًا لأننا نتحدث عن أداة مستخدمة طوال اليوم لأغراض العمل ، فلا يبدو لي أنه من الغباء طلب ميزة تجعل قائمة الملفات أكثر قابلية للقراءة.

يسأل المستخدمون عن الميزات كيف يتحسن VSCode ، وربما إذا طلب عدد كافٍ من الأشخاص هذه الميزة ، فسيحدث ذلك بالفعل. لكن الشكوى لا طائل من ورائها.

يجب أن تحتوي على ميزة لمساحات العمل الكبيرة.

لقد كنت ألقي نظرة أخرى على هذا مؤخرًا ، مما يمكنني جمعه ، كان هناك بعض طلبات السحب في الماضي والتي لم تذهب بعيدًا

• https://github.com/microsoft/vscode/pull/13754
• https://blog.floatas.net/blog/visual٪20studio٪20code٪20file٪20nesting/

لكنني بدأت أعتقد أنه من الممكن تنفيذ هذا كملحق بناءً على ما رأيته هنا

• https://code.visualstudio.com/api/extension-guides/tree-view
• https://github.com/fernandoescolar/vscode-solution-explorer

لقد قمت بالتنقيب في بعض الامتدادات الأخرى على vscode ولكن لم أجد أي شيء
أعتقد أن ما نحتاجه هو أن يقوم شخص ما بكتابة امتداد يمكنه إظهار نفس الشيء مثل نافذة مستكشف الملفات الافتراضية ولكن مع إضافة التداخل ، بشكل مثالي مع دعم قراءة ملفات .filenesting.json المستخدمة بالفعل في Visual Studio 2019 (ليس الشفرة)

• https://docs.microsoft.com/en-us/visualstudio/ide/file-nesting-solution-explorer؟view=vs-2019

جافا سكريبت ليست لغتي الأولى ، لذا لست متأكدًا مما إذا كنت سأتمكن من فعل شيء بنفسي
على الرغم من أنني أعتقد أن هناك واجهة برمجة تطبيقات إضافية مكشوفة للقيام بذلك ، على الأقل في علامة تبويب مستكشف منفصلة في اليسار

مرحبًا grbd ، أعتقد أن "الخطاف" لهذا التطوير سيكون النقطة التي يتعامل فيها مستكشف الملفات مع المجلدات: سيُظهر ذلك كيفية عرض الملفات المتداخلة. ثم يجب أن يمتد هذا الثور إلى الملفات ، بدلا من الدلائل فقط.
سيكون من الجيد إضافة إعداد لمعرفة امتدادات الملفات التي يجب تضمينها في وضع العرض الجديد.
لم أقم مطلقًا بتطوير أي شيء لـ vscode ، لذلك لا يمكنني إعطائك معلومات أخرى ... يبدو أن تطوير الامتدادات فكرة جيدة ، وربما بمجرد استخدامها واختبارها جيدًا ، ربما يتم نقلها إلى التعليمات البرمجية المصدر للتطبيق الرئيسي.

كنقطة انطلاق ، من المحتمل أن ألقي نظرة على vscode-solution-explorer وانسخها / ألصقها
نظرًا لأنه يفعل شيئًا مشابهًا بالفعل في عرض الملفات في الدلائل الفرعية المشابهة لمستكشف الملفات الرئيسي
الاختلاف هو أن النية هي محاكاة طريقة عرض VStudio 2019 بدلاً من القيام بتداخل الملفات.

سيكون الإعداد لمعرفة امتدادات الملفات التي يجب تضمينها شيئًا مثل .filenesting.json كما ذكرت أعلاه ، أو بعض الملفات الأخرى ذات الصلة بـ json.

تكافح حقا لمعرفة السبب.

لأنها ليست أولوية بالنسبة لهم. كفريق ، قرروا إعطاء الأولوية لأشياء أخرى. يمكنك أن تختلف مع قراراتهم ، ولكن كل هذا النحيب "OMG _whhhhhy_" هو بغيض ولا طائل من ورائه.

أنت تدرك أنك في مشكلة _ طلب الميزة ، أليس كذلك؟ قد تكون على حق في أي مكان آخر ، ولكن هذا هو المكان الصحيح _ الواقعي _ لطلبه والتحدث عنه (ليس أنينًا لا طائل من ورائه). لن تكون أبدًا أولوية إذا اعتقدوا أن الناس سعداء ولا يحتاجون إليها.

سأشرح لماذا أحتاج إلى "مجلدات افتراضية": أنا أعمل مع قاعدة بيانات C تم تكوينها من خلال makefile ، والتي لا يمكنني المخاطرة بتغييرها. ومع ذلك ، فإن الكود عبارة عن فوضى ، ولدي قواعد أكواد أخرى للحفاظ عليها مع نفس المشكلة.

أحتاج إلى ترتيب الملفات تقريبًا في أدلة افتراضية للحفاظ على سلامة عقلي ، ويمكنني القيام بذلك في: Code :: BLocks و Programmers Notepad (نعم). لكن لا يمكنني في VS Code.

هذا _يجب_الأشخاص الذين لا يتحكمون في كيفية تنظيم ملفاتهم في مجلدات ، وهو أمر شائع في العديد من المؤسسات. هذا ليس عن "جعلها أجمل".

النتيجة: أنا أقل إنتاجية بكثير باستخدام VS Code. أتمنى أن أتمكن من استخدامه ، لكنه مجرد سير عمل أبطأ.

آمل أن يغير الفريق رأيهم ، لا أعتقد أنه يجب التعامل مع هذا بواسطة مكون إضافي ، على الرغم من أنه يمكن ذلك من الناحية الفنية. لا أريد الاعتماد على موفر مكون إضافي لمثل هذه الحاجة الأساسية ، واستثمار الوقت في شيء قد ينهار.

أفهم أنها ليست أولوية ، أنا فقط أطلب ذلك ، إذا كنت تريد أن يتمكن المزيد من المستخدمين من استخدام كود VS وأن يكونوا منتجين ، أن تفكر فيه في المستقبل.

grbd أود المساعدة ، لكن يبدو أن هذا يتطلب الكثير من العمل ، لست متأكدًا مما إذا كان لدي الكثير من الوقت.
لقد قمت بتحديث شوكة تداخل الملفات المخصصة لتتوافق مع سيد اليوم. إذا احتاج أي شخص إلى نقطة بداية مع تداخل الملفات ، فأضف أيضًا ثنائيات لتجربتها.
https://github.com/floatas/vscode