@Tekbr 우리의 접근 방식에 어떤 문제가 있습니까?

@bpasero 나는 그것이 명확하지 않다고 생각합니다. 나는 더 잘 설명하려고 노력할 것이다. 영어 죄송합니다

버전 1.7의 새로운 기능을 즐겼지만 동시에 수직 및 수평 분할을 허용하는 것이 흥미로울 것입니다.

gif에서 볼 수 있듯이 세 개의 탭이 있습니다. 동시에 수직 분할, 수평 분할.

방향을 변경하기 위해 버튼을 클릭 (또는 단축키 사용)하면 조금 지루해집니다.

탭을 측면으로 드래그하는 것처럼 "Toggle Editor Group Layout"을 사용할 필요없이이 창의 하단 가장자리 근처에서 아래로 드래그하여 창을 조정합니다.

👍을 사용했지만이 사용 사례에 대한 구두 지원도 제공하고 싶었습니다. 저는 2x3 그리드에서 Sublime을 사용하는 다소 큰 모니터를 가지고 있습니다. 현재 VS Code에서는 불가능합니다. 수평과 수직 사이에서 선택해야하기 때문입니다.

마지막으로 # 1749를 구현 한 후 다른 편집기 ( Sublime Text, Atom, vim, Emacs, 전체 Visual Studio- 모두 그리드 레이아웃을 지원함) 에서처럼 워크 벤치를 유연하게 만드는 데 필요한 또 다른 단계입니다. 특히 큰 화면에서는 2x2 또는 1 + 2 그리드 레이아웃을 사용하는 것이 매우 유용합니다. 매우 큰 화면을 가진 일부 사람들은 훨씬 더 미친 레이아웃을 사용하는 경향이 있습니다. 이는 여러 관련 파일 (예 : C ++의 헤더 파일)이있는 프로젝트에서 작업 할 때 유용 할 수 있습니다.

VS 코드에서 이와 같은 것을 갖는 것이 매우 멋질 것입니다!

나는 수직과 수평으로 나눌 수 있고 이것은 정말로 여기에 빠졌다.

잘하면 구현 될 것입니다. 이것은 내가 지금 vscode에서 가진 유일한 주요 문제입니다.

+1

세 가지 이유로 VS Code를 통해 WebStorm을 사용합니다.

1) 가로로 분할 할 수 없습니다.
2) vim 에뮬레이션은 평범합니다 (하지만 어쨌든 감사합니다, 전혀 사용할 수 있습니다)
3) 키보드 매크로를 기록 할 수 없습니다.

VS Code는 정말 빠르며 JavaScript에 있다는 점이 마음에 듭니다. 그것은 많은 잠재력을 가지고 있습니다. 이러한 것들이 구현되면 내가 선택한 편집자가 될 것이라고 확신합니다.

명확하게하기 위해 다음은 WebStorm 메뉴의 스크린 샷입니다 (수평 분할이란 의미).

저에게 Atom은 완벽하게 ... 분할 상하 좌우 분할 ... 그리고 4 사분면으로 끝날 수 있습니다. 오른쪽에 2 개, 또는 원하는 경우 더 많이 ... 각각 고유 한 탭 세트가 있습니다. 새로 열린 파일은 열 때 포커스가있는 섹션으로 이동합니다. 현재 4K 모니터에서 세 가지 케이스를 모두 사용하고 있습니다.

왜 아직 구현되지 않았는지 궁금하거나 VS 팀이 수평 분할에 대해 정당한 이유가 있습니까?

@whitecolor VSCode에는 수평 분할이 있습니다. 'alt + shift + 1'을 눌러 활성화 할 수 있습니다 (수직 분할과 수평 분할 간 전환).

그러나 VSCode에서 가로 및 세로 창을 잘못 사용할 수있는 그리드 레이아웃이 필요하다는 데 확실히 동의합니다. 제 사무실에서 저는 VSCode를 지속적으로 사용하는 유일한 사람이며 뛰어난 이유 중 하나는 그리드 레이아웃 기능이 부족하기 때문입니다.

오른쪽 수직 수평으로 전환 할 수 있지만 둘 다 사용할 수는 없습니다. 다소 이상합니다.

이것을 고려할 것인가 아니면 그냥 잊어야 할 것인가?

솔직히 말해서 내가 지금 vscode에 대해 보는 유일한 나쁜 점이지만 매일 사용하고 싶고 할 수 없다는 것이 상당히 고통 스럽습니다.
나는 시간이 무한하지 않다는 것을 이해하지만 여기에서 많은 일이 일어나지 않으므로 이것을 올려서 짜증이 나는 경우 실례하지만이 토론을 계속 진행하고 싶습니다. :)

# 9443의 토론을 참조하십시오.

@kieferrm 이 문제를 사람들에게 추천하는 문제 # 9443을 닫았습니다. 그렇다면이 문제가 그리드 레이아웃 기능을 추적 할 _one_이라고 가정 할 수 있습니까?

@andradei 예.

또한 이것을 좋아할 것입니다. 임의의 그리드 분할은 내 워크 플로의 핵심입니다. 다른 곳에서는 놀랍기 때문에 코드로 전환하고 싶지만 계속해서 방해가됩니다. 😄

이것이 내 동료 중 일부가 vscode 열차에 있지 않은 가장 큰 이유입니다.

명확히. C-x-<n> 키 조합을 사용하여 버퍼 그리드를 지속적으로 재정의하는 것은 대부분의 emacs 사용자 워크 플로우의 필수적인 부분입니다. 가장 중요한 용도는 동일한 버퍼의 두 뷰를 얻기 위해 한 번 분할하고 참조를 위해 다른 부분으로 빠르게 이동 한 다음 곧바로 분할을 해제하는 것입니다.

Emacs에서 전환하려고하는데 그게 없으면 마이그레이션이 힘들어집니다.

와. 나는이 싫어. 새로운 소프트웨어를 시작하고 약간 놀아보고 짜증나는 것을 발견 할 때마다 문제를 열게됩니다.하지만 다음 버전에서 출시되도록 해결되었거나 완료되어야한다는 논의가 막 끝났습니다. .
어쨌든. React-Native를 가지고 놀다가, Android Studio 이후이 화면 분할이 정말 그리워요

수평 및 수직으로 나눌 수 있어야한다는 데 동의했습니다. 다른 형식보다 한 형식을 선택하는 것은 사용할 수 없습니다.

다음에서 페이지를 가져올 수 있습니다.
https://github.com/SublimeText/Origami

이것은 Sublime 또는 Atom을 떠났을 때 놓칠 수있는 유일한 기능 중 하나이며 VSCode를 사용하지 못하게합니다.

멀티 태스킹을하는 진지한 코더 나 작성자에게 이것은 최소한 플러그인에서 지원되어야하는 필수 기능입니다.

나는 항상 3 개의 창이 너무 얇고 짧아서 어떤 것도 명확하게 볼 수 없다고 느꼈고 그리드 레이아웃은 문제를 완화하는 좋은 방법입니다. 두 개의 참조 파일을 열어야 할 때 지금 vscode에서 사용할 수있게하는 것이 고통 스럽습니다.

여기에 그리드가 현재 우리가 가지고있는 것보다 훨씬 우수한 이유를 시각화하는 데 도움이되는 작은 그림이 있습니다 (아마도 이미 꽤 명확 할 것입니다).

이것이 미래의 로드맵에 포함되기를 바랍니다!

시간이 있으면 직접 할 수있을 정도로 너무 필요합니다. 이것이 없으면 많은 개발자가 VSCode를 사용할 수 없습니다. 이것이 곧 제공되지 않으면 개발자가 모든 텍스트 편집기에서 기대하는 기본 기능이기 때문에 계속 진행해야 할 것입니다.

👍

90 년대와 00 년대 초반의 구식 VIM에서, 14 년 동안 00 년대부터 VS, 수년간 Sublime 및 Atom w / VIM 플러그인에서 ... VSCode로 전환하고이 제한으로 심각한 장애물에 부딪 혔습니다. 진지하게, 30 분 안에 나는 이것을 쳤고 "잠깐, 진지하게 ... 그리드를 만들 수 없습니까?"

VSCode는 멋지게 만들어지고 있습니다. 그러나 어쨌든 나에게는 그리드 레이아웃이 필요합니다. 그리드를 사용하지 않으면 기본 편집기가됩니다.

MS는 # 1749에서 이유 (레이아웃 및 그룹화, 키 바인딩)로 언급했습니다.

그러나 "디자인 리뷰"로 충분합니다. 다른 모든 편집자들이 가지고있는 기능을 활성화하고이를 수행하십시오. 인프라와 탭 그룹 등을 깰 필요가있는 경우 주요 버전 범프를 만들고 모든 사람에게 이유를 알려주십시오. 끝난.

.NET Core는 MS가 더 이상 "역 호환성"시장에 있지 않으며 앞으로 제품을 발전시키고 단순화하기 위해 기능을 중단 할 의향이 있음을 이미 보여줍니다. VSCode가 동일한 패턴을 따르지 않고 다른 성숙한 편집자 수준으로 발전하기 위해 몇 가지 사항을 깨뜨릴 수없는 이유가 없습니다. 커뮤니티 표준에.

다음을 수행 할 수없는 것은 심각한 제한입니다.

:vs 
:vs 
:split

비 VIM 전문가로의 번역 : 그리드와 같은 편집기를 형성하기 위해 수직 및 수평으로 분할 할 수 없다는 것에 대한이 스레드와 # 1749의 폭언에 반향을 일으 킵니다.

너무 답답해서 조명 편집을 위해 VS 코드를 사용하고 하드 코어 그리드 편집을 위해 터미널로 드롭하는 경향이 있습니다.

4k 30 "또는 Macbook Pro 15"Retina에서 그리드 레이아웃 만 사용합니다.

창문을 분리하는 것도 큰 장점입니다. 하지만 지금은 여전히 ​​[n] vim을 사용해야합니다. 그래서 지금은 3 대의 모니터 3 개에 tmux를 사용하여 콘솔을 열고 단일 모니터에서 예쁘게 보이도록 단일 VScode 세션을 열었습니다. VSCode는 ' 수평 및 수직 분할의 그리드 레이아웃 '을 동시에 사용할 수 있습니다.

위의 의견에 약간 동의합니다. 망치로 들어가서하지는 않겠지 만. 키 바인딩이 걱정된다면 괜찮습니다. 시작할 바인딩없이 기능을 "사용 가능"하게합니다. 나중에 타협을 찾고 키맵을 재 작업 할 수있게되면 작업하십시오. 대부분의 편집기에서하는 것처럼 대부분의 사용자 지정 키맵을 가지고 있으므로 모두 서로 일관되게 유지되므로 어쨌든 중요하지 않습니다.

그러나 기능이 작동하고 사용 가능하고 문서화되어 있다면 사람들은 여전히 ​​앞으로의 추진력을 좋아할 것이라고 생각합니다. 별도의 PR을 작성하여 기존 워크 플로우 및 키맵에 통합하는 방법을 찾으십시오.

이것이 가까운 장래에 구현 될 것인지에 대한 업데이트가 있습니까?

나는 또한 숭고한 종이 접기를 확인하기 위해 이전의 권장 사항을 반영하고 싶습니다. ( read : steal ideas from ) Origami for sublime. 그것은 매우 강력하고 잘 디자인 된 / 직관적 인 키 바인딩 (기본 "코드"구조를 배운 후)을 가지고 있습니다. 여기에는 창을 가로 / 세로 임의로 분할하기위한 바로 가기, 창간에 파일 이동, 창간에 포커스 이동, 창 크기 조정, 빠르게 확장하는 단축키가 포함됩니다. 하나의 창을 편집기 크기의 일정 비율로 만듭니다.

그것은 나를 위해 지금까지 가장 가치있는 ST

그리드 레이아웃 지원이 부족하여 VSCode를 진지하게 시도하지 못합니다.

이 기능에 대한 업데이트를 기다리고 있습니다. 이것이 없으면 Atom에서 VS Code로 전환하는 것이 고통 스럽습니다.

이 기능이 필요합니다.

이것에 대한 업데이트가 있습니까? 적극적으로 작업하고있는 것이 아니라면 PR에 넣어 보는 것을 기쁘게 생각합니까 ??

이것은 매우 중요한 기능이며, 그 부재는 전환에 대해 저를 울타리에 두는 유일한 요소입니다.

VS 코드에는 이것이 필요합니다!

이 주제를 다루는 동안 분할을 프로그래밍 방식으로 제어하기위한 API를 요청하고 싶습니다. 패널의 크기를 조정하고 싶을 때마다 마우스를 사용해야한다면 다소 절망적 일 것입니다.

또한 꽤 멋진 플러그인을 허용 할 것이라고 생각합니다.

이 기능이 꼭 필요합니다 !! 제발 :)

@ atmd83 배후에서 작업중인 것이 없는 한, 이것은 누군가가 적극적으로 개발하고있는 것으로 보이지 않습니다. 이 문제와 관련된 풀 리퀘스트를 아직 보지 못했고 향후 마일스톤에 추가되지 않았습니다. 그래도 PR에 참여하고 싶다면 낭비가 아닐 것 같고 조만간 이것을 볼 수있는 최선의 기회 일 것입니다.

@ atmd83 이 스레드의 댓글과 반응을 기반으로이 기능을 구현하면 수천 명의 개발자로부터 영웅으로 환영받을 것이라고 말할 수 있습니다.

@pelotom @ atmd83 @JeremyKruman 나는이 일을 시도하는 것을

기여하고 싶다면 VSCode 핵심 팀 중 한 팀과 이야기하는 것이 좋습니다.

@Chillee 당신이 여기 에서 사용자 지정 CSS 및 JS를 VSCode에 삽입 할 수있는 확장을 찾았습니다.이 확장 기능은 특히이 기능이 절실한 사람들에게 임시 해결 방법을 제공 할 수 있습니다. 아직 플레이 할 시간이 너무 많지 않았지만 오늘 저녁 화면 왼쪽에 수직 편집기 1 개와 오른쪽에 수평 편집기 2 개를 배치하는 데 시간을 할애 할 계획입니다. 다른 사람들이 제안했듯이 말한 것보다 훨씬 쉬울 수 있지만 다른 사람이 조사하고 싶은 경우를 대비하여이 잠재적 인 옵션을 사람들의 관심을 끌고 싶었습니다 😃

VSCode를 사용하려는 사람들을 위해. 나는 작은 일이 있지만 특별한 것은 없습니다.

두 개의 별도 VSCode 창을 엽니 다. 창 중 하나에서 작업중인 프로젝트의 기본 폴더를 엽니 다. 다른 창에서 주 프로젝트 폴더의 하위 폴더 (예 : / src)를 엽니 다. 그런 다음이 두 개의 창을 나란히 놓고 각각의 레이아웃을 독립적으로 설정할 수 있습니다. 2 + 1 레이아웃 또는 2 + 2 레이아웃 등을 가질 수 있습니다. 수평 또는 수직.

주 폴더가 열려있는 창에서 변경하고 동일한 파일의 다른 창에서도 변경하면 변경 내용을 덮어 쓸 수 있습니다. 훌륭한 IDE를 사용하는 데 드는 비용이 적습니다. 앞으로 적절한 그리드 분할 기능이 추가되기를 바랍니다.

이것이 도움이되기를 바랍니다!

건배,
그렉

누구든지 관심이 있다면 이 요점 의 Greg와 유사한 레이아웃을 달성하는 내 사용자 정의 CSS를 찾을 수 있습니다. 약간 까다 롭지 만 (스크롤바 누락 등) 당분간 작업이 완료됩니다.

@JeremyKruman 적어도 마우스 휠을 사용하여 스크롤 할 수 있습니까?

예, 스크롤은 마우스와 키보드를 통해 작동하며 스크롤바는 보이지 않습니다. 그것들은 어딘가에 있고, 내가 아직 다루지 않은 올바른 장소로 가져 가려면 적절한 스타일이 필요합니다.

@JeremyKruman Dude, 당신은 보스입니다!

이 기능의 구현 여부에 대한 업데이트가 있습니까?

이것은 여전히 ​​우리의 백 로그에 있습니다.

angular-cli 프로젝트와 함께 작동하는 확장을 만들 생각 중이었습니다. * .component.ts 파일을 열면 구성 요소와 관련된 템플릿 및 CSS 파일을 자동으로 감지하여 가로로 분할 된 화면에 배치합니다.

파일을 이동하는 것은 성가신 일이며 angular-cli 프로젝트에서는 구성 요소에서 템플릿으로 또는 그 반대로 많은 작업을 수행하는 경향이 있습니다.

불행히도 수평 분할은 지원되지 않으며 너무 많은 수직 분할은 사용할 수 없습니다.

TEMPLATE     | COMPONENT.TS
             | 
------------- 
STYLES       |
             |
------------------------------

참고로 Ember-CLI 세계의 @praveenpuglia 에는 해당

그리드 레이아웃이 올 때 나는 숭고한 것에서 전환합니다. 나는 내 눈을 믿을 수 없었다 .... 그렇지 않으면 아주 좋다!

@ peabnuts123 좋은 생각입니다. 나는 무언가를 찾고이 스레드를 따르도록 노력할 것이다.

@praveenpuglia 관련 항목 찾기 는 바로 가기 키 시나리오를 지원해야합니다. 불행히도 Angular에 대한 기본 제공 규칙 세트가 없기 때문에 기본적으로 작동하지 않습니다 (하지만 추가하고 싶습니다). 규칙 세트 설정에 도움이 필요하면 알려주세요.

여러 편집기를여시겠습니까?

그래, 그 옵션, @bonarja, 그리고 당신이 생각하는 이유를 이해하지만 그 도움의 솔루션이 될 수 있습니다, 나는 마크를 벗어났습니다 두려워. 사람들이이 기능을 요청하는 이유는 여러 인스턴스를 열 수 있다는 사실을 모르기 때문이 아닙니다. 여러 인스턴스를 사용하면 여러 버퍼 (예 : 명명 된 클립 보드)간에 공유되는 편집기 기능을 사용할 수 없거나 스크린 샷에서 별도의 편집기에 표시된 버퍼간에 이동할 수 없습니다 (예 : vim 모드 분할 명령 사용). ).

@coddingtonbear가 말한 것

@bonarja @coddingtonbear @alexriedl 이것은 나에게도 실제로 작동하지 않을 것입니다. 작업하는 동안 항상 버퍼를 분할, 전환, 닫고 배치를 변경하는 경향이 있기 때문입니다. 그리고 여러 창을 사용하는 것은 빠르고 지속적인 전환을 위해 너무 느리고 번거로울 것입니다.

VSCode에서 그리드보기가 필요한 다른 사람 😭

여기에 VSCode에서 그리드보기가 필요한 또 다른 사람이 있습니다 ... :)

VSCode에서도 그리드 레이아웃이 필요합니다.

... 그리고 이걸 정말 원해요

+1

이 대화 목록에있는 사람들은 +1하고 "이것도 원합니다"-ing,이 문제가 공개되도록 원본 게시물을 👍 확인하세요 (문제는 👍 s 수로 정렬 할 수 있음).

이 기능 (그리드 레이아웃)은 Atom에서 완전히 전환하는 것을 방해하는 유일한 요소입니다. 저는 VSCode를 좋아하고 빠르며 Typescript를 사용하여 플러그인을 작성할 수 있습니다. 놀랄 만한. 그러나이 기능은 너무나도 놓쳐서 VSCode를 완전히 수용하는 데 방해가됩니다.

이 기능 이전에 macOS Touch Bar 지원이 적용되었다는 사실에 놀랐습니다.

모든 노력에 다시 한 번 감사드립니다. 놀라운 앱입니다. 이 기능을 우선적으로 올리는 것을 고려하십시오.

(내지지를 보여주기 위해 이미 원본 게시물도 +1했습니다.)

아직 할당 된 사람이 없습니다. : / 우선 순위를 지정하십시오! vscode의 대량 채택을 늦추는 유일한 기능입니다.)

+1하고 댓글 달기-에디터 창을위한 그리드 레이아웃을 정말 좋아합니다. 특히 화면의 상단 절반에 전체 너비 편집기 1 개와 하단 절반에 절반 너비 편집기 2 개의 피라미드 레이아웃 👍

_VS Code_ 해커, 이것에 대한 업데이트가 있습니까? 부디.

+1

이 기능의 문제점이 무엇인지 정말 잘 모르겠습니다. 편집기는 두 옵션을 동시에 지원하는 것이 아니라 필요한 기능을 이미 지원합니다. 큰 모니터 (43 "4k 디스플레이)를 가진 저와 같은 사람들에게 이것은 신의 선물이 될 것입니다!

하오 하나는 문제가 구현하기 어렵다고 가정하지만 외부에서는 쉽게 나타날 수 있습니다. 그래도 우선 순위가 지정되지 않은 것이 슬프다. 이것은 장기적으로 vscode의 가장 많이 요청 된 기능이어야합니다.

얘들 아. 전에 제품 작업을 한 적이 없으십니까? 사용자가 정말로 원하기 때문에 상황이 나타나는 것이 아닙니다. 분명히 그들은 여러 폴더와 같이 (또는 고객 / 사용자에게 노출되지 않는 다른 이유로) 명백하게 더 높은 우선 순위를 갖는 작업을 수행하고 있습니다. github에서 👍 우선 순위로 정렬 할 수 있으며 실제로 가장 많이 요청 된 기능이 아니라는 것을 알 수 있습니다. 11. Chill :)

VIM과 Emacs는 모두 거의 20 년이 된 편집기이며 대부분의 전문 IDE 및 다른 전자 기반 편집기 인 Atom과 마찬가지로이를 지원합니다. 그러나 VSCode는 여전히 이것을 지원하지 않으며 아마도 최고의 편집기입니다. 이로 인해 VSCode를 단순한 메모장이 아닌 다른 용도로 사용할 수 없습니다. Visual Studio the IDE가이를 지원합니까?

편집 : 최신 편집기가 지원한다고 가정하는 기본 기능이므로 버그로 표시되어야합니다. Visual Studio IDE에서도이를 지원한다는 위의 의견을 확인했습니다. 사람들이 "완전한 경험"을 위해 Visual Studio IDE로 이동하도록 장려하기 위해 VSCode를 사용하여 사용자 경험을 억제하려는 의도적 인 선택입니까? 이 경우 VIM, Atom 및 IntelliJ를 고수하겠습니다.

그리드 레이아웃의 부족은 나에게도 실망 스럽습니다. 최근에 Visual Studio, Atom, Spacemacs 및 Vim을 사용했습니다. VS Code는 현재 제가 가장 좋아하는 프로그램이지만 수평 분할이 없다는 점이 심각한 단점입니다.

👍을 추가했습니다-워크 플로를 VS Code로 이동하는 중이며 지금까지 이것이 제가 만난 유일한 실제 문제입니다. (말하자면,이 에디터는 정말 대단합니다. 감사합니다!)

위의 몇 가지 의견을 반영하기 위해 제가 사용한 다양한 편집기 (및 플러그인) 중에서 제가 가장 좋아하는 접근 방식은 Sublime Text를위한 Origami 입니다.

+1

나를 위해 거래 차단기. 지금은 VS Code 포기.

이 기능을 정말 갖고 싶습니다. 지금은 여러 개의 창을 사용하고 있는데 그다지 좋지 않습니다. 이상적으로는 하나의 인스턴스 만 사용하여 코드를 관리해야합니다.

+1

이 토론과 관련이 있지만 아직 명시 적으로 언급 한 적이 없습니다. 3 개의 편집기 창 제한은 대형 (4k) 모니터에 충분하지 않습니다. 편집기보기 레이아웃을 더 유연하게 만들려면 생성 할 수있는 편집기 창 / 행 / 열 수에 대한 제한도 제거해야합니다.

+1. 이 작업이 완료 될 때까지 Atom으로 다시 전환했습니다. IntelliJ 팩, Sublime, Atom, Visual Studio 등이이를 지원합니다.
특히 2560 x 1080 화면에서 가장 먼저 찾은 것입니다. 사용자 지정 그리드는 나에게 가장 적합합니다.

이 문제가 아직 해결되지 않았다 니 믿을 수 없습니다. 코드 편집기에게는 정말 필수입니다! : /

나를 위해 +1. 나는 차세대 개념과이 편집기의 순수한 굉장함 때문에 vscode로 돌아 왔지만, 몇 시간 후에 숭고한 + 종이 접기로 돌아 왔습니다. 왜냐하면 저는 4k 모니터에서 작업하고 보통 다양한 레이아웃 설정. 안타깝게도 3 탭 제한은 현재 제게 거래를 방해하는 요소입니다.

이것을 착륙시키고 싶다면 원래 PR 코멘트를 확인하십시오. vscode 팀은 반응 정렬 을 사용하여 기능의 우선 순위를 지정합니다.

이 기능이 떨어지면 결코 뒤돌아 보지 않을 것입니다. 그동안 환상적인 편집자에게 감사드립니다!

그리드가 없다는 점을 제외하고는 VSCode를 좋아합니다! 그리드 부탁드립니다 :)

편집자 창을 분할해야합니다 !!!!
그리드 레이아웃이 가장 좋습니다!

우리 모두이 쪼개지는 것을 원한다는 것에 동의했습니다. 그래서 다음은?

Microsoft 팀의 누군가가 이것이 작동하지 않는 이유를 알려줄 때까지 기다리십니까? 그리고 / 또는 필요한 기술을 가진 사람이 PR을 만들 수 있습니다. 코드베이스에 익숙하다면 기능을 구현하기가 특히 어려울 것이라고 믿을 수는 없지만 Line of JS / TS를 작성하거나 코드베이스를 살펴본 적이 없으므로 완전히 틀릴 수 있습니다.

이것의 개발 속도를 높이십시오! 나는 그것을 위해 1 년 이상 기다렸고, 너무 기본적인 것이 내장되어 있지 않고 최악의 것은 아직 시작되지 않았다는 것을 믿을 수 없다. 최신 애플리케이션 개발에 매우 ​​중요합니다. 멋진 편집기에 감사드립니다.하지만 많은 사람들이 수평 + 수직 분할 (또는 그리드) 기능 없이는 메인 스트림 편집기로 사용할 수 없습니다.

이 기능을 지원하기 위해 시간을 내십시오. 화면 분할 방법에 대해 거의 무한한 관용도를 제공하는 Sublime Text와 같은 환경에 익숙한 개발자는 VSCode 로의 마이그레이션이 매우 매력적이지 않다고 생각합니다. (나 자신을 위해 말하기 : 대부분의 팀은 VSCode를 사용하지만 개인적으로 수평 + 수직 분할이 없어서 사용할 수 없다는 것을 알게 되었기 때문에 지금은 Sublime을 계속 사용하고 있습니다.)

여기에서 더 많은 지원을 받으세요! 이 기능이 구현되어 정말 기쁩니다. 저는 저를 포함하여이 사건을 지켜 보는 사람들의 절반이 이것을 구현할 기회에 뛰어들 것이며 확실히 그렇게 할 수있는 기술과 자격을 가지고있을 것이라고 확신합니다. VSCode가 최적화되고 능률적이며 잘 채택 되었기 때문에 우선 순위를 지정하는 데 시간이 너무 오래 걸리는 것을 이해하지 못하지만 지금은 PR이 7 개만 할당되지 않은 상태입니다.

그동안 저는 Sublime에 계속 노력할 것이며, VSCode를 사용하면 전자 런타임을 살해하지 않고도 전체 모니터를 코드에 효율적으로 사용할 수있을 때 다시 시도 할 수 있기를 기대합니다.

현실로 만들어주세요

@kieferrm : 왜 아직 컷이 안

찬성 투표가 충분하지 않습니까?

그렇게 생각하지 마십시오. 상위 5 개 문제입니다. "플로팅 창"에만 더 많은 업 보트가 있고 할당되지 않았습니다 (# 10121, 드래그 앤 드롭 사용과 관련됨).
나는 그저 약간의 작업이 아니라이 문제는 어느 시점에서 중간에 해결되었다고 생각합니다 (수평 및 수직 분할이 있지만 동시에 둘다는 아닙니다.)
우리는 고해상도 모니터를위한 조합이 필요합니다. :)

곧 이것을 보게되어 기쁩니다.

이 얼마나 기괴한 음모 반응입니다. VS Code가 구현하는 모든 것을 감안할 때 그리드 레이아웃이 VS Studio의 잠식으로 인해 Microsoft가 추가하기를 거부하는 한 가지라는 것은 의심 스럽습니다.

우리가 음모를 시작하기 전에 풀 요청이 설명없이 즉시 거부되는 것을 보자.

우리가 음모를 시작하기 전에 풀 요청이 설명없이 즉시 거부되는 것을 보자.

그러나 그의 의견은 즉석에서 삭제되었습니다 ... 음모 이론을 없애는 가장 좋은 방법은 아닙니다.

@MikeGitb @ Justus-Maier 이 의견 에 따르면 ' 권장 투표가 충분하지 않음'이 해당 될 수 있습니다.

이 문제를 처음 읽는 분들께 :

개발자는 이 문제의 중요성을 알고 있지만 이 필터 를 사용하여 어떤 기능이 최우선 순위인지 결정합니다. 이 기능을 개발하려면 👍로 원래 문제 를 찬성하세요.

개발자는이 문제의 중요성을 알고 있지만이 필터를 사용하여 어떤 기능이 최우선 순위인지 결정합니다. 이 기능을 개발하려면 👍로 원래 문제를 찬성하세요.

그것은 자주 반복되는 자제이지만 더 많은 찬성표를 가진 4 개의 문제 중 어느 것도 그 의제에 해당되지 않는다는 점에 유의하십시오.

@aberonni @egamma @bpasero 개발자의 응답 부족으로 여기에 커뮤니케이션 문제가 발생하고 있으며 기자 / 댓글 작성자는 참여 부족으로 좌절감을 느끼고 있습니다. 개발자가 상세하고 심층적 인 응답 만 할 수 있다면 많은 걱정을 덜어 줄 것입니다.

@alxgrtnstrngl 이 기능에 대한 불안은 실제로 꽤 높지만, 다음 큰 도전을하기 전에 실제로 무엇을하고 있는지 알지 못한 채 개발자에게 너무 요구해서는 안됩니다.

이 기능도 기대합니다. 그러나 나에게 VSCode는 그것 없이도 여전히 Atom보다 훨씬 우수합니다.

👍

+1

1 년 이상 진행되지 않았기 때문에 오늘 VSCode를 종료합니다. 진심으로 실망했습니다.

저는 최소화 된 코드를 좋아합니다. 재사용을 위해 그리드 뷰는 모든 범위에서 개발하고 유용하고 간단하며 모니터 공간을 사용하는 데 많은 도움이됩니다.

영어 죄송합니다 ... : P ...이 기능이 곧 출시되기를 바랍니다 ...

이 문제는 @egamma에 의해 2018 년 1 월 반복 계획 에서 제기되었습니다.

"우리는이 기능이 많은 찬성표를 가지고 있다는 것을 알고 있지만 더 많은 표를 얻은 다른 사람들이 있습니다. 지금 제가 말할 수있는 것은이 기능이 우리의 레이더에 있다는 것입니다."

개발자가 고려해야 할 문제에 대해 몇 표가 필요한지 설명해 줄 수 있습니까?
이것은 정말 유용한 기능이며 우리 모두는 그것을 많이 그리워합니다.

@pallapo 참조
https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Afeature-request+sort%3Areactions-%2B1-desc
이 작업은 투표 수로 5 번입니다.

나는 이것이 기능이 정확히 얼마나 많은 표를 가지고 있는지의 문제라고 솔직히 의심합니다. 또한 예상되는 필요한 노력과 시너지 효과 / 의존성을 고려해야합니다. 그리고 투표는 어쨌든 기능이 커뮤니티에 얼마나 중요한지에 대한 매우 대략적인 지표 일뿐입니다 (예 :보고 싶은 기능의 우선 순위를 다른 기능보다 우선 할 수 없습니다).

즉, 이것이 구현하기에 문제가있는 기능이라는 사실에 놀랐습니다.

@MikeGitb 정확합니다. 모든 것이이 하나의 기능이 VSCode의 현재 아키텍처에서 큰 변화를 의미 할 것이라는 것을 나타 내기 때문에 때가되면이 기능에 집중하고 다른 중요한 기능을 옆에 두어야한다고 생각합니다. 이 기능이 바로 지금 작동하더라도, 이것이 모든 실습 방식이 아니라면 다음 릴리스주기 또는 다음 릴리스주기에 출시 될 것 같지 않습니다.

이것이 구현 될 때까지 다중 창은 더 넓은 화면 또는 4K를 가진 사람들에게 도움이 될 것이라고 생각합니다.

이것에 대해 일하십시오 !!! 이것은 우리가 모두 거대한 모니터를 사용하기 때문에 VSCODE를 사용하는 것을 막는 유일한 방법입니다! 포 호의 !!

나는 이것이 현재 활성화되어 있다는 것을 알기 전에 이것에 대한 게시물을 작성했습니다. VSCode 팀에서 이것이 사용자에게 더 나은 편집기를 만들기위한 시간의 가치 사용이라고 생각하는지 여부에 대한 업데이트가 있습니까? 이것은 큰 화면에서 코딩하지 않거나 랩톱에서 코딩하고 파일을 전체 너비로보고 싶지만 한 번에 두 개 또는 세 개의 파일을 열어야하는 많은 사람들에게 유익한 기능입니다.

13 인치 MacBook pro 또는 15 인치 Lenovo 노트북에서 코딩 할 때 이동하고 싶지만 다른 모니터에 연결할 수 있도록 책상에 머무르는 경향이 있습니다. 이것은 거의 모든 다른 경쟁자들이 가지고있는 기능이며 Sublime, Atom, Vim 등에서 전환 할 때 여기에있는 많은 사람들이 놓친 기능인 것 같습니다.

Atom Editor는 대부분의 사람들 (나를 포함하여)이 VScode에서 원하고이 스레드에서 언급하는 Dock 의 개념을 도입했습니다.

또한 여기에 GIF로 트윗을 만들었습니다 ➡️ 귀하의 우려를 표명하기 위해 리트 윗 😄

저는이 기능을 Atom에서 매일 사용합니다. 여기에 2 개의 코드 파일이 열려 있고 linter 및 오류 패널이 열려 있고 2 개의 터미널이 열려있는 저의 인위적인 데모 gif가 있습니다. 앞서 언급 한 모든 항목은 편집기의 어느 곳에서나 드래그 및 배치 할 수 있습니다 🔥 ✌️

git diff 뷰어도 UI의 어느 곳에서나 드래그 할 수 있습니다.

예, @cliffordfajardo가 게시 한 내용이 구현되기를 바랍니다. 매우 강력하고 직관적입니다. 물론 탭을 자신의 창으로 드래그 할 수 있다면 그것은 놀랍습니다. 멀티 모니터 편집 및 디버깅이 있습니다.

내가 궁금한 것은 VS Code 개발자가 아직 ✅ Support Grid Layout 확인란을 선택하지 않은 이유는 무엇입니까? 진지하게, 이것은 사소한 변화가 아니므로 아직 여기에없는 것도 당연합니다. :)

이는 <C-w>w 및 <C-w>s 의 Vim 키 바인딩이 올바르게 작동하는 데 필수적입니다.

necrobump에 대해 죄송 합니다만, 3840 픽셀 너비의 디스플레이를 가지고 있고 3 개를 제한으로하여 실제로 1920 개의 와이드 픽셀 디스플레이에만 해당하므로 적어도 4 개를 나란히두고 싶습니다.

한 번에 4 개의 창을 볼 수있는 기능입니다. 상단에 2 개의 창이 있고 하단에 2 개의 창이 있습니다. Atom 및 Sublime Text에서 쉽게 수행됩니다. 이 기능이 없기 때문에 VS Code를 사용하지 않습니다.

이 @aberonni를 봐 주셔서 감사합니다

나는 '터미널 탭 버그'에서 이것에 대해 약간 언급했지만 편집자가 탭으로 가득 찬 창 (이 스레드 / 원자 / 숭고한 방식) 대신 창으로 가득 찬 탭 (터미널이하는 방식)을 사용하는 데 관심이있는 사람은 누구입니까? 에 관한 것입니다?

창으로 가득 찬 탭 을 사용하면 일부 레이아웃으로 정렬 된 파일 그룹을 열 수 있습니다. 그런 다음 탭, 다른 파일 그룹을 유사하거나 다른 레이아웃으로 변경할 때.

Linux 터미널 클라이언트 'Tilix'와 같은 여러 레이아웃을 가진 다중 패널 터미널과 똑같기를 바랍니다. 드래그 투 사이드 기능이지만 각 패널에 상단, 하단, 왼쪽 및 오른쪽을 추가합니다. 터미널도 마찬가지입니다. 창 작업 창 편집기의 왼쪽 상단에있는 버튼으로 새보기를 추가하고보기간에 전환 할 수 있습니다. https://youtu.be/XzHE_BcSRbA?t=312

Tho는 여러보기를 숨기는 대신 탭으로 바꾸고 (가급적이면 레이블을 지정할 수있는 기능 포함) 각 창에는 자체 헤더가 있습니다. 또는 확장 할 때 각보기 레이아웃의 미리보기를 표시하는 축소 가능한 사이드 바로 만듭니다. 또는 버튼을 클릭하면 미리보기가 표시되고 전환 할 수있는 Tilix처럼 괜찮습니다. 업다운 내비게이터를 추가하여 이들 사이를 전환 할 수 있습니다.

터미널은 왜 3 개 이상을 나란히 놓고 싶은지 모르겠지만 여러 뷰의 메뉴를 선택할 수있는 버튼 대신 탭이 있으면 좋을 것입니다. 터미널이 독립적이고 편집기 뷰에 대해 별도의 UI 구성 요소로 작동하는 경우 가장 좋습니다.

터미널, 왜 3 개 이상을 나란히 놓고 싶어하는지 정말 모르겠어요

초광각 모니터에서 전체 화면 모드.

그러나 여러보기의 메뉴를 선택할 수있는 버튼 대신 탭이 있으면 좋을 것입니다.

네, 그게 다른 스레드입니다.

터미널이 독립적이고 편집기 뷰에 대해 별도의 UI 구성 요소로 작동하는 경우 가장 좋습니다.

나는 이것에 대해 앞뒤로 간다 (구성 가능한 것들에 대해 예). 메인 에디터 영역의 분할 창이 터미널 (때로는 큰 터미널을 원할 때도 있음)이 될 수 있고, 프로젝트 전체에 유용한 일을하기 때문에 항상 거기에있는 것이 멋질 것이라고 생각합니다. 항상보고 싶어요.

예, 지진 콘솔 스타일, 상단, 측면 및 하단의 옵션이 있거나 뷰에서 패널 유형으로 사용할 수 있습니다. 또한 구성 가능하지만 단축키는 단일 키 여야한다는 것을 알고 있습니다. 그것에 대해 생각해야 할 수도 있습니다. 가능하다면 f12를 사용하고 싶습니다.

Sublime Text에서 Origami가 작동하는 방식보다 훨씬 나아질 수 없다고 생각합니다 : https://github.com/SublimeText/Origami . 오른쪽 클릭으로 어떤 방향 으로든 창을 추가 / 제거하고 레이아웃을 저장할 수 있습니다. 매우 유용합니다.

한 가지 다른 참고 사항 : Sublime에서는 동일한 파일의 완전히 별도의 창을 열 수도 있습니다. 예를 들어 특정 창은 한 모니터에서 열고 다른 창은 별도의 모니터에서 열 때 사용합니다. (하지만 완전히 별개의 기능 일 수 있습니다)

코드의 모든 것이 단지 탭 (터미널, 문제, 출력 디버그 콘솔 등)이고 탭이 원자와 같은 모든 위치 (위, 아래, 나란히 등)에 자유롭게 배치 / 분할되는 경우 선호됩니다.

코드의 모든 것이 탭 (터미널, 문제, 출력 디버그 콘솔 등)이면 더 좋을 것입니다.

바로 그거죠! 이것은 VIM 또는 Emacs와 같은 편집기의 주요 기능 중 하나로서이를 강력하게 만드는 __a 일반적인 접근 방식입니다 __.

저는 한때 매우 관련이있는 것을 요청했지만 특정 사용 사례에 초점을 맞추 었습니다 : # 30987. VSCode 팀이 그 유용성 가치를 완전히 이해하지 못한 것 같습니다 (cc

바로 그거죠! 이것은 VIM 또는 Emacs와 같은 편집기의 주요 기능 중 하나로서 창에 대한 일반적인 접근 방식입니다.

emacs 터미널 에뮬레이터는 환상적입니다. 키 입력으로 빠르게 탐색하고 버퍼의 어느 곳에서나 텍스트를 추가하거나 삭제할 수 있습니다. (물론 사악한 모드에서)

나는 몇 달 전에 스페이스 맥에서 한 달을 보냈고 버퍼 멀티플렉싱과 터미널 에뮬레이션을 좋아했습니다. Emacs는 내가 vscode에서 매일 사용하는 도구를 놓치고 있습니다.
vscode로 다시 전환했을 때 3 개의 열린 파일과 터미널 멀티플렉싱을위한 tmux로 돌아 왔습니다.

그것은 내가 emacs 기능을 원할 때마다 조금 울게 만든다. 나는 마이크로 소프트가 이것을 구현할 수 있다고 생각하지만,이 스레드를 따라 몇 달 후에 나는 희망을 잃기 시작했다.

좋은 소식. 그리드 레이아웃을 2018 년 2 월 반복 계획으로 만들었습니다.

https://github.com/Microsoft/vscode/issues/43361

작업대

🏃 알림 UI # 22388 @bpasero 개선
💪 Investigate는 편집자를위한 그리드 레이아웃 지원 # 14909 @stevencl @bpasero @Tyriar @joaomoreno

Emacs는 내가 vscode에서 매일 사용하는 도구를 놓치고 있습니다.

정확히, 최신 언어 기능의 훌륭한 통합이 제가 VSCode를 사용하는 주된 이유입니다. 불행히도 아무도 Emacs에 그것을 제공하지 않습니다.

여전히 VSCode에서의 생산성은 이러한 제한된 창 처리로 인해 순전히 고통받습니다.

WOOO 이제 숭고한 텍스트에서 VSCode로 이동할 계획이 있습니다 !!!
감사합니다 ~ Chuck Norris ~ Microsoft!

"조사"란 문제를 분석 한 후 실제로 구현할 목표를 설정한다는 의미입니까? 권리?

이 항목은 2 월 26 일 기준으로 2 월 반복 계획에서 연기 된 것 같습니다. 다음주기를 바랍니다.

지금 막 매우 긴 .tex 파일을 작업하는 동안 갑자기이 격자 레이아웃이 아직없는 문제에 부딪 혔습니다. 나는 키가 큰 .tex 파일 창을 LEFT 그룹에서 2 개의 수직으로, RIGHT 그룹에서 단일 PDF 파일로 나눌 수 있기를 바랬습니다. VS Code 팀에서 논문 작성에 VS Code를 사용하는 것은 우리에게 좋을 것입니다. 그리드 레이아웃 c (~ _ ~)에 대한 기능 요청을 승인 해주세요. "

저는 VS 코드를 좋아하지만이 기능이 없기 때문에 Sublime이 정말 그리워집니다. 바라건대 이것은 더 많은 사랑을 얻고 곧 나올 것입니다!

이것은 최대 열 / 행 수를 제한하지 않고 구현해야합니다. 현재 3 개 열 제한은 나에게 의미가 없습니다.

미안하지만 이것은 단지 조사입니다!
" Investigate는 편집자를위한 그리드 레이아웃 지원 # 14909 @stevencl @bpasero @Tyriar @joaomoreno"

@pallapo "조사"는 여전히 앞으로 나아가고 있음을 나타냅니다. 이 티켓에서 공식적인 움직임을 보는 것은 매우 좋습니다. 감사합니다, 팀!

@joshjensen 맞아요!

@fabiospampinato에 동의합니다. UI가 허용하는 한 어떤 뷰포트를 두 방향으로 나눌 수있는 옵션은이를 구현하는 강력한 방법 인 것 같습니다. 윈도우가 충분히 일반적인 경우에는 여러 도구를 빌드하는 데 사용할 수 있습니다 ( 위에서 참조한 Atom의 Docks 기능과 유사).

이 Microsoft VS 팀에 대해 뭔가를 할 시간입니다 👍 😄

원자를 완전히 뒤로 놔두려고하는데 이것은 큰 문제가 나를 방해하고 있습니다. 나는 VS Code에 대한 다른 모든 것을 좋아합니다. Microsoft가 곧 수직 및 수평 분할을 허용하기를 바랍니다!

"이것은 내가 VSCode를 풀 타임으로 사용하지 못하게하는 유일한 방법입니다"라는 감정에 +1을 추가합니다.

@elleryfamilia 동시에 두 가지를 모두 할 수 있는지 신경 쓰지 않는다면 수직 또는 수평을 활성화하는 단계입니다.

• 보기> 편집기 그룹 레이아웃 메뉴 전환.
• 보기 : 명령 팔레트에서 편집기 그룹 수직 / 레이아웃 명령 전환 (⇧⌘P (Windows, Linux Ctrl + Shift + P))
• 편집자 열기 도구 모음의 토글 버튼입니다.
• ⌥⌘0 (Windows, Linux Shift + Alt + 0) 키보드 단축키.

그러나 네, 파일을 왼쪽과 오른쪽 위 아래 어디로 든 드래그 할 수있는 능력이 있으면 vscode가 사실상 저에게 타의 추종을 불허합니다.

Vim에서 VS Code로 전환하려고 시도했습니다. 중대한 좌절. 특히 각 분할에 명시 적으로 번호가 지정되어 있기 때문에 키 바인딩을 사용하여 분할간에 왼쪽 또는 오른쪽으로 건너 뛰는 방법을 찾을 수없는 경우 특히 눈에 띕니다. 내 Vim + iTerm 설정에서 vim 분할과 터미널 분할 사이를 원활하게 위아래로 이동할 수 있으며 VS Code에서 복제하는 것은 거의 불가능합니다.

편집자뿐만 아니라 모든 것이 탭이라는 언급은 그리드 레이아웃 시스템에도 큰 차이를 만들 것입니다. 터미널 탭, 편집기 탭, 디버그 탭 등이 있으면 엄청날 것입니다 ... 심지어 사이드 바 탭도 좋을 수도 있지만 물론 대대적 인 개편이 될 것입니다. 나는 이것이 확실한 견인력을 얻길 바랍니다. 편집자간에 상대적으로 탐색하기위한 몇 가지 핵을 알아 내지 않는 한 VS 코드를 오래 사용하지 않을 수 있습니다.

네, 이것은 중요한 것입니다. 화면이 항상 당신이 생각하는대로는 아닙니다. 저는 여러 대의 세로 모니터를 사용하고 초광각 모니터를 사용하는 경우 사람들이 어쨌든 3 개 이상의 열을 원하는 이유가 있습니다.

VSCode가 화면 사용 방법에 대한 개인적인 생각을 기반으로 제한을 구현할 이유가 없습니다.

이 일이 나올 때까지 나는 Atom을 사랑했습니다. 나는 일반적으로 가로 분할이있는 두 세로 모니터에 아톰 프로젝트를 가지고 있으며, 초광각에 대해 여러 개의 3-4 세로 분할을 사용합니다.

실제로 5 분 동안 내가 할 수없는 방법이 없다고 생각했습니다. "grrr 왜 거기로 내려 가지 않겠 어!" :-피

이것을 구현하려면 +100!

Investigate 지원 그리드 레이아웃 편집자 작업이 Deferred Items 로 옮겨진 것 같습니다.
나는 거의 매일이 문제 페이지를 방문하여 상태를 확인합니다.
사실 에디터를 열고 창을 나눌 때마다 희망이 있으면 가서 확인합니다.

나는 편집자를 바꾸는 것을 싫어한다. VS Code는 모든면에서 완벽하다. 모든 대단함에 감사드립니다 !!
그러나 전환을 진지하게 고려하기 시작하면 현재 레이아웃으로 여러 파일을 작업하는 것은 매일 고통 스럽습니다.
이보다 더 많은 표를 얻은 확장 프로그램 및 기타 문제를 설치 한 후 다시로드해야하는 것보다 훨씬 더 고통 스럽습니다.
전혀 비판적이지 않지만 이것은 내가 사용한 최고의 오픈 소스 제품입니다.

커뮤니티에 더 많은 정보를 제공해 주시면 감사하겠습니다. 이것이 가능할까요? 더 많이 알 때까지 얼마나 기다려야합니까? 이것은 대다수의 사용자에게 중요하지 않으며 우선 순위가 낮습니까?
우리가 결정하고 진행할 수 있도록 알려주십시오.

연기 된 게 보이지 않아요-# 47369

3 월에 연기 된 손가락은 다음 반복을 위해 교차했습니다.

네, 이것도 기다리고 있습니다. Visual Studio에서도 약간의 번거 로움으로이를 수행 할 수 있습니다 (파일을 드래그하여 별도의 창을 시작합니다. 다시 분할 할 수 있음 = 여러 분할로 여러 창을 가질 수 있음).

여러 파일을보아야 할 때 절대적으로 필요합니다. 많은 사람들이 그것을 요청했고 더 많은 의지를 가지고 있습니다. 제발, 제발, 제발, 구현하십시오. 큰 화면에서 매우 유용합니다.

4 월 동안 "진행 중"것 같다 # 47369

@RayBenefield 가 설명하는대로 분할 간 탐색은 키를 workbench.action.navigateUp|Down|Left|Right 에 바인딩하여 수행 할 수 있습니다.

@bpasero look 1.23 내부자 릴리스 및 창 레이아웃 없음 (# 14909). 4 월에 업데이트되지 않는다는 뜻인가요?

변수, 감시 및 호출 스택 패널이 너무 작습니다!
변수 값을 검사해야하는 경우 아무것도 보이지 않으면 항상 왼쪽 패널의 크기를 조정해야합니다.
디버그 패널 방향을 수평 상태로 설정하십시오 !!!

: +1 : 50 센트라는 위대한 말로 Patiently Waiting .

하지만 구현하기가 그렇게 어려운지 모르겠습니다 .... 비주얼 스튜디오 프로페셔널에 문제가 있다고 생각합니다. 그리드 에디터 레이아웃이 지원되지 않습니다 ....

49599 Slay Ben, 죽여라. 2018 년에 VSCode를 유일한 편집기로 만들 마지막 누락 된 부분입니다. ssh를 제외하고. VSViCode 2k19?

와. 이 문제에 대한 모든 의견을 살펴 보았습니다. 나는 그리드가없는 레이아웃에 거의 익숙해졌고 이것이 그렇게 뜨거운 주제라는 것을 깨닫지 못했습니다. 끝까지 건너 뛰는 사람에게는 최신 업데이트에 포함되어 있지 않지만 문제 # 47369에 따르면 이와 유사한 것을 생성하는 중입니다.

다음을 포함하기 위해 5 월 업데이트를 위해 손가락을 건너 봅시다 : crossed_fingers :

@elebumm 실제로 풀 리퀘스트 가 있습니다.

또한 내부자를 위해 6 월 에 출시 할 계획이라고 명시되어 있습니다.

현재 계획은이 기능을 이번 달 (5 월) 마지막 게임 주 동안 테스트 할 수 있도록 한 다음 6 월 초 내부자에게 제공하는 것입니다. 이는 6 월 말 출시를 위해 안정 상태에 있음을 의미합니다.

그들은 심지어 그것을 보여주는 애니메이션을 게시했습니다.

@skreborn 희망이 사실입니다. 수직 분할이 3 개 뿐인 모니터 2 개를 사용하는 것은 매우 비현실적입니다 ...

@ psychosis448 사실입니다. 여기 WIP PR의 gif가 있습니다.

🤞 GIF를 보는 것은 정말 기쁨을 가져다줍니다.
방금 모든 댓글을 읽고이 사람들이 확실히 열심히 일하고 있음을 깨달았습니다.
나는 이것이 쉬운 일이 아니라는 것을 알고 있으며, 이것을 밀어 붙인 것에 대해 감사의 말을하고 싶었습니다.

대단히 감사합니다 !

나는 파티에 늦었다는 것을 알고 있으며 이것이 그리드 레이아웃 문제의 범위를 벗어난 것 같지만 VS Code 팀이 지켜보고있는 경우 : 터미널 창, 특히 이 그리드 레이아웃에 어떻게 든 적합합니다. * NIX의 많은 사용자는 vim 또는 다른 콘솔 편집기와 함께 screen 또는 tmux를 사용합니다. 다른 사람들은 기본적으로 동일한 효과를 위해 그래픽 편집기에서만 타일링 창 관리자를 사용합니다.

그렇게 큰 변화를 일으키고 적어도이 아이디어의 논리적 확장을 염두에두고 새로운 기능을 설계하지 않는 것은 부끄러운 일입니다.

이 기능을 구현하는 데 시간이 너무 오래 걸립니다 ..... 아직 준비되지 않았습니다 ...
포커스 창을 전체 화면으로 전환하는 기능이 있기를 바랍니다.

• https://atom.io/packages/maximize-panes(atom )
• https://packagecontrol.io/packages/MaxPane(sublimetext )

분할 H와 V는 요즘 필수입니다.

Advanced Coders는 그 멋진 팬시 Apple Mac을 터치로 사용하지 않습니다.

2 x 4K 모니터를 사용합니다.

그리고 8k 모니터는 올해 궤도에 올랐습니다.

1 x 모니터 40 "해상도 4k 60hz, https://prnt.sc/jm3rap의 예. 프로젝트의 비주얼은 훌륭합니다.

Atom이 매우 느립니다. 최대한 빨리 수정하세요.

감사.

오, 60hz? 신과 같은 코더는 120hz를 사용합니다. 이 제품을 사용할 수 없습니다.
이러한 추가 새로 고침은 우수한 커서 이동 속도를 위해 필요합니다.

@phoenixsampras 스크린 샷에 민감한 부분이

@phoenixsampras @michaelduminy IP와 적어도 DB 암호 ... 나는 그것을 삭제하는 것이 좋습니다 🤦‍♂️

편집 : 이제 아이러니 @michaelduminy 😅 ...

이 기능은 다음 주 ( 6 월 말의 안정적인 릴리스를 위해) 내부 빌드에 적용되지만, 이제 더 많은 사람들이 사용해 볼 수있는이 기능을 테스트하기위한 사용자 지정 내부자 빌드가 있습니다.

• macOS : 다운로드
• Windows : 다운로드
• Linux : 다운로드

참고 : 이러한 빌드를 실행하려면 먼저 실행중인 VSCode Insiders 빌드를 모두 닫아야합니다.

피드백은 매우 환영합니다. 이상적으로는 구독자에 대한 알림 수를 줄이기 위해 여기에 댓글이 아닌 개별 문제로 환영합니다. 먼저 workbench-grid 레이블이 query

새로운 기능에 대한 실제 문서는 아직 없습니다. 단, 이번 마지막 게임 주간에 살펴본 테스트 계획 항목을 제외하고는 https://github.com/Microsoft/vscode/issues/50458입니다.

간략한 개요 :

• 편집기는 수직 및 수평으로 분할 할 수 있습니다 (예 : 드래그 앤 드롭을 통해 또는 편집기 도구 모음의 분할 작업에서-다른 방향으로 분할하려면 Alt 키를 누르고 있음).
• workbench.editor.closeEmptyGroups 설정을 사용하면 그룹의 마지막 편집기를 닫을 때도 닫아야하는지 구성 할 수 있습니다.
• "열린 편집기"보기는 더 이상 위치 (왼쪽 / 가운데 / 오른쪽)를 기준으로 그룹을 표시하지 않지만 생성 순서대로 번호가 표시됩니다.

특히 다음과 같은 미해결 문제를 중심으로이 경험을 조정할 계획입니다.

• 2x2 그리드 # 50770에 새시 연결
• 2가 겹치는 곳에서 새시를 드래그하여 양방향 크기 조정 허용 # 50769
• Grid : "중앙 편집기 레이아웃"구현 # 50936

특히 Vim에서 온 사람들에게 관련된 것은 열린 파일이 편집기에 묶여 있다는 사실입니다.

파일을 닫지 않고 편집기를 닫는 방법이 있습니까? 그래서 우리는 기능과 같은 vim-buffer를 가질 수 있습니까?

이 구현은 활동 표시 줄에도 적용됩니까? 바를 바닥에 붙여도 되나요?

이는 공용 IP가 아닌 내부 IP 범위입니다. 자세한 내용은
https://en.wikipedia.org/wiki/Private_network에서

2018 년 5 월 28 일 13:47, Lucas Andión Montáns [email protected]
썼다 :

@phoenixsampras https://github.com/phoenixsampras @michaelduminy
https://github.com/michaelduminy IP 및 최소한 DB 암호 ...
아래로 내려가는 것이 좋습니다 🤦‍♂️

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/vscode/issues/14909#issuecomment-392577362 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AB37QPG3mjlaU8bbCEuA7e1h190rdZj2ks5t3DgYgaJpZM4KoZDu
.

-
친애하는,
CP

@bpasero 그래도 실제로 어떻게 설치합니까?

@dnutels 압축 을

@bpasero 방금 게시 한 빌드를 시도했는데 완벽하게 작동했습니다. 감사합니다!

제한없는 멋진 기능! 좋은 일 @bpasero

감사합니다! 굉장합니다! 나는이 문제를 수년 동안 지켜왔다. 축하합니다 !! '이것 없이는 VSCode를 사용하지 않겠습니다!'라는 끔찍한 댓글을 통해 작업 해주신 모든 분들의 정말 노력과 인내에 감사드립니다.

@bpasero 잘 작동하지만 분할을 시작하는 영역이 약간 작다고 생각합니다. 새 레이아웃에서 "출력"및 터미널과 같은 패널을 지원할 계획입니까?

훌륭하게 작동합니다. 감사합니다 @bpasero !!! 🍾를 어디로 보내야합니까? :)

내가 알아 차린 유일한 것.
처음에 대칭 2 x 2 그리드가있는 전체 페이지가있는 경우.
편집기의 크기를 화면의 절반으로 만 조정하고 다시 전체 화면으로 만듭니다. 열린 섹션의 비율이 유지되지 않습니다.
첫 번째 열은 매우 좁습니다.
수동 크기 조정과 Magnet을 사용하여 이것을 알았습니다.
중요하지는 않지만 가지고 있으면 좋습니다. 😄

VSCode 팀은 훌륭합니다! 고마워요 고마워요 고마워요 🍾🍾🍾

이 기능으로 vscode에서 3 방향 diff가 가능합니까?

혹시 어떤 창으로도 확장 할 수 있습니까? 사이드 바를 전혀 없애고 터미널, 코드 개요, 탐색기, 문제 목록 등 필요한 모든 창에서 나만의 타 일식 UI를 구성 할 수 있습니다.
이 경우 사이드 바는 사용 가능한 창과 자동 숨기기에 대한 일종의 팔레트 역할을 할 수 있습니다.

graet job
고마워, 고마워 !!!!

편집자 이외의 다른 UI 요소에 대한 그리드 지원에 관심이있는 사람들은 좋아요를 눌러야합니다.

• 왼쪽 및 오른쪽 사이드 바 / 멀티 사이드 바 # 26777
• 워크 벤치 # 11472 어디에서나 편집기,보기 및 패널을 도킹 할 수 있습니다.
• 동시에 여러 패널 표시 허용 (분할 창) # 11889

그리드 레이아웃에 대한 토론 중 @bpasero, 아마도이 주제 :
https://github.com/Microsoft/vscode/issues/16927

내가 거기에 썼 듯이 이와 유사한 기능 :
Atom-> https://github.com/santip/maximize-panes
SublimeText-> https://github.com/jisaacks/MaxPane

이것은 훌륭합니다! 조만간 Stable 빌드에 들어가기를 바랍니다! 👍

집을 떠나는 것을 싫어하는 사람들을 위해 그리드 창 작업에 대한 키보드 단축키를 고려하십시오.

터미널이 그리드 시스템의 일부가 될 수 있다면 어떤 그리드에서도 터미널을 배열 할 수 있다면 좋을 것입니다! https://twitter.com/_rctl/status/1004704690586705921

@eighteyes 나는 모두 키 바인딩을 할당 할 수있는 그리드의 일부로 추가되는 ~ 35 개의 새 명령을 계산하고 있으므로 어느 것이 누락되었는지 알려 주시면 추가 할 수 있습니다.

이것은 굉장합니다 ! VSC 팀이이 작업을 수행하고이를 실현할 수 있다는 것은 환상적입니다. 안정적인 출시를 기다릴 수 없습니다. 시간이 지남에 따라 팀이 터미널, 자식 창 등으로 분할 할 수있는 능력을 익힐 것이라고 확신합니다. 지금은 이것이 다가오고 있으며 단순히 황홀하다고 불평 할 수 없습니다. 감사합니다! 🥇

VS Code 팀에게 : 기능이 준비 될 때 알림을 받으려면 Github에서이 문제를 구독해야한다는 VS Code 릴리스 노트를 입력했습니다. "이 기능은 6 월 초에 참가자 릴리스에서 사용할 수 있습니다. 이 문제가 발생할 때 알림을 받으려면 문제 14909를 구독하세요. " 이론상 멋진 아이디어! 최소한의 작업으로 기존 도구를 활용하고 사용자는 이미 Github 사용 방법을 알고 있습니다.하지만 실제로는이 문제로 인해 많은 소음이 발생하고 다른 사람들도 마찬가지라고 생각합니다. 나는 지난 24 시간 이내에 구독했고 처음에 구독하고 싶게 만든 릴리스와 관련이없는 Github를 통해 이미 12 개 정도의 알림을 받았습니다. 이 건설적인 비판이 도움이되기를 바랍니다! 그러나 저는 확실히이 문제를 구독 취소 할 것이며, 새로운 기능을 구독하는 다른 방법이 해결되기를 바랍니다. 진심으로 당신의 것 : 임의의 사람.

@sdegutis https://tellmewhenitcloses.com

링크에 대한 최고 @pelotom 감사합니다!

기능이 내부자 ( 다운로드 )에 도착했기 때문에이를 닫습니다. 이 마일스톤에 대해 아직 계획된 작업에 대해이 쿼리 를 볼 수 있습니다 (예 : "중앙 편집기 레이아웃"을 올바르게 지원하기 위해).

계속해서 문제 나 피드백을보고하십시오 (중복을 확인한 후).

사람들이받는 알림 수를 줄이기 위해이 문제를 읽기 전용으로 표시하겠습니다.