탭은 원래 고려되었지만 하단에 탭이있는 경우 혼란을 야기하고 vscode가 덜 "가벼워진"느낌을 줄 수 있기 때문에 팀에 의해 광범위하게 패닝되었습니다. focusNext 및 focusPrevious 터미널에 대한 키 바인딩이 없으면 드롭 다운을 사용하는 것이 고통스럽기 때문에 탭이 없어 매우 실망 할 것입니다.

또한 분할보기를 고려한 다음 tmux 와 같은 응용 프로그램이 통합 터미널에서 실행되어 유사한 결과를 얻을 수 있으므로 우선 순위가 지정되지 않았습니다. 이후이 항목에서 피벗했으며 터미널을 분할 할 수 있기를 원합니다. 나는 특히 tmux 의 키 바인딩을 배우고 싶지 않으며, 내 워크 플로우의 일부는 한 번에 여러 터미널을 표시하는 것입니다. 일반적으로 오류를 모니터링하는 watch 명령과 수동 빌드 또는 시작 명령입니다. # 7504에서 터미널 분할을 추적합시다.

@stevencl @ bgashler1 터미널의 focusNext 및 focusPrevious 작업에 대한 합리적인 기본 키 바인딩을 찾을 수 없다는 점을 다시 한번 염두에 두십시오 (ctrl + shift + j / k 바인딩).

이 문제의 맥락에서 이것을 고려해야합니다 : https://github.com/Microsoft/vscode/issues/9659

나는 탭 디자인 내의 탭을 정말로 경계합니다. 탭을 표시하기 위해 사용 가능한 모든 공간을 사용하게됩니다. :-)

여기서 큰 소리로 생각하면 터미널 분할을 허용하면 탭을 표시해야합니까? 터미널을 분할하고 축소하는 작업을 노출했지만 실제 탭을 표시 할 필요가 없다면 충분할까요?

아마도 탭 / 다중 터미널을 통해 2-3 분할 터미널을 사용하는 것을 볼 수 있습니다. 분할 터미널 및 탭 터미널을 관리하는 것은 매우 혼란스럽고 키 바인딩이 부족하여 거의 사용하지 못할 것입니다.

터미널을 분할하는 문을 열면, 예를 들어 하나의 터미널과 하나의 디버그 repl을 분할한다는 것은 무엇을 의미할까요? 동일한 UX 상호 작용입니까?

@bpasero 분할하여 측면에 새 터미널을 만드는 것을 의미하므로 예는 동일합니다.

상호 작용을 단순화하기 위해 항상 드롭 다운을 사용하거나 터미널을 분할하도록 설정할 수 있습니다. 이렇게하면 기존의 모든 명령이 여전히 잘 작동합니다. 언제든지 하나 또는 모든 터미널을 표시하도록 선택하면됩니다.

탭을 도입하고 터미널로 분할하는 것에 대한 두려움은 편집자 그룹처럼 보일 수 있다는 것입니다. 사용자가 편집기를 터미널로 드래그하거나 터미널을 편집기 그룹으로 드래그 할 수 없다는 사실에 실망하지 않기를 바랍니다. * 또한이 기능을 도입하면 창 관리에 왜 특별한 수평이 있는지 등의 미끄러운 경사가있을 수 있습니다. 처음에 이와 같은 것을위한 패널. 사용자 정의 UI에서 많은 기능을 복제하는 대신 터미널을 원하는 곳에 두지 않는 이유는 무엇입니까?

* 아마도 x 축에서 드래그를 잠 그거나 영역 외부로 드래그하려고 할 때 커서를 비활성화하여 제한 사항을 알릴 수 있지만,이 기능이 작동 할 것으로 예상하는 사람들을 피하는 것은 어렵습니다.

에디터 그룹의 수평 분할을 도입 할 때, 우리가 부과하는 제약 중 하나는 에디터 그룹이 수평 분할 또는 수직 분할 만 가능하다는 것입니다. 따라서 사용자가 수평 편집기 그룹과 놀랍도록 유사한 패널 (하지만 정확히 같은 방식으로 작동하지는 않음)을 수직 편집기 그룹 아래에 배치하는 것은 기이 할 수 있습니다.

수요일에 UX 동기화 중에 이에 대해 더 이야기해야합니다. 이것과 관련된 가로 레이아웃과 관련하여 지난번에 보여주지 않은 디자인이 있습니다.

터미널을 편집기 탭과 정렬하여 터미널이 편집기 파일의 언어를 자동으로 반영하도록하는 옵션은 어떻습니까?

터미널을 열면 활성 (현재 선택된) 편집기 언어에 대해 미리 구성된 셸이 자동으로로드됩니다. settings.json 파일에서 여러 터미널 셸이 지원되어야합니다.

편집기가 분할되는 방식은 중요하지 않습니다. 터미널은 항상 선택된 (활성) 편집기의 셸을 표시합니다. 이것은 간단하고 간단합니다. 이 방법을 사용하면 터미널을 분할 할 필요가 없으며 탭 터미널이 필요하지 않습니다. 터미널은 지금처럼 계속 나타납니다.

언어에 사용할 수있는 여러 셸이 있거나 하나의 편집기 탭에 대해 노드 셸 및 git 셸과 같은 구성을 실행하려는 경우 하나의 창 내에서 셸을 선택할 수 있습니다. 이것은 하위 컨텍스트를 의미하는 하드 탭으로 표시되지 않는다는 점을 제외하면 탭 터미널과 비슷합니다. 이것은 탭처럼 실질적인 느낌이 들지 않습니다. 해당 컨텍스트는 현재 선택한 편집기의 터미널 창에 있습니다.

터미널의 오른쪽 상단에있는 간단한 하이퍼 텍스트 문자열 (각 셸당 하나씩)은 현재 선택된 편집기에 대해 열려있는 (인스턴스화 된) 셸을 표시합니다. 사용자는 노드라고 할 수있는 하이퍼 텍스트 문자열을 클릭하여 선택하거나 키 바인딩을 사용하여 순환 할 수 있습니다. 기존 드롭 다운 메뉴, + 및 휴지통을 대체합니다. 쉘은 소문자로 표시 될 수 있습니다.

간단한 하이퍼 텍스트 문자열이 표시되거나 아이콘 만 표시 될 수 있지만 문자열이 더 좋을 수 있습니다. 이것은 현재 VSCode에서 사용되는 번거로운 드롭 다운 목록을 대체하고 셸을 한 눈에 보여줍니다.

현재 편집기에서 다른 언어 (예 : Ruby)를 사용하는 편집기로 포커스를 전환하면 터미널이 터미널에 IRB 인스턴스를 표시합니다. 사용자가 현재 셸의 다른 인스턴스를 열려면 해당 셸의 하이퍼 텍스트 위로 마우스를 가져 가서 나타나는 + 를 클릭하기

셸 위로 마우스를 가져 가면 해당 문자열에 대한 셸 내용을 보여주는 피크를 표시 할 수도 있습니다. 그러나 사용자가 키 바인딩을 사용하여 전환 / 순환하는 경우 확인하는 것이 더 쉬울 수 있습니다.

사용자에게 git 셸과 같이 편집기와 관련이없는 셸을 추가하는 옵션을 제공하려는 경우 +를 클릭하면 settings.json 파일에 등록 된 셸 메뉴가 표시 될 수 있습니다. 각 하이퍼 텍스트 문자열 옆에 마우스 오버시 나타나는 - 는 물론 옵션을 표시하지 않습니다. 현재 셸 인스턴스를 닫습니다.

사용자가 셸 유형을 변경하려는 경우 셸을 종료 한 다음 (기본값으로 폴백) 셸 이름을 입력하여 새 셸을 시작할 수 있습니다. 셸을 나타내는 하이퍼 텍스트 문자열은 새 셸을 반영하도록 변경됩니다.

git 셸의 경우 git 셸이 항상 편집기의 언어 셸로 열리도록 지정하는 옵션을 사용자에게 제공하여 git이 해당 파일 위치의 컨텍스트에 있도록하는 것이 논리적 일 수 있습니다. 동일한 git 위치에서 여러 파일이 열려있는 경우 모든 편집기의 모든 git 셸 인스턴스에 최신 업데이트 또는 명령이 반영됩니다.

settings.json 파일은 사용자가 각 terminal.internal.shell에 대해 특정 언어 확장자 (.js, .cs, .rb)를 입력하도록 요구할 수 있습니다. 파일과 논리적으로 일치하는 항목이 있습니다. settings.json에 지정되지 않은 모든 파일 유형에 대해 기본 셸을 구성 할 수 있습니다.

각 편집기에 대해로드 된 셸 인스턴스는 해당 편집기가 열려있는 동안 지속됩니다. 편집기 (파일)가 닫히 자마자 연결된 터미널 쉘도 닫힙니다.

나는 이것이 매우 직관적이면서도 VSCode를 현재보다 더 강력하게 만드는 간단한 구현이라고 생각합니다. 사용자가 언어 편집기간에 컨텍스트를 전환 할 때 터미널에 대해 생각할 필요가 없습니다. 터미널은 항상 선택된 편집기에 마지막으로 사용 된 관련 기록 등을 포함하여 마지막으로 실행 된 셸 및 코드를 표시합니다.

@ nick-walt는 어떤 사람들에게는 더 직관적 일 수 있지만 다른 사람들에게는 전혀 직관적이지 않습니다. 그것은 사람들이 다소 혼란스러워하고 그들의 껍질이 어디로 갔는지 궁금하게 만들 것입니다. 또한 내 요구 사항은 한 번에 2 개의 셸을 표시하는 것입니다. 하나는 내가 오류를 추적하는 감시 작업을위한 것이고 다른 하나는 시작 작업, git, 빌드 등을위한 것입니다.

여러 터미널 구성이 이전에 등장했지만 대부분의 경우 다른 셸에서 셸을 실행할 수있을 때 (cmd 내에서 powershell, ruby, node 등을 열 수 있음) 추가 복잡성의 가치가 있는지 확신 할 수 없습니다.

헉
좋은 고민이긴하지만 고려하면 상당히 쉽게 해결할 수 있다고 생각합니다.

방향 감각 상실 방지
기본 상태 인 구성되지 않은 새 설치에서 터미널은 익숙한 방식으로 작동 할 수 있습니다. 이렇게하면 예기치 않은 동작으로 인한 방향 감각 상실을 방지 할 수 있습니다.

터미널 분할
터미널 창을 분할해도 모델은 변경되지 않습니다. 터미널 창에서 한 번에 둘 이상의 셸을 보는 방법 일뿐입니다. 창을 주 창 밖으로 끌어서 다른 모니터에서 전체 화면으로 이동할 수 있습니다. 그런 다음 사용자는 터미널이 열린 쉘 사이에서 수직 또는 수평으로 자동으로 균등하게 분할하도록 지시 할 수 있습니다. 하나의 터미널, 여러 개의 쉘-모두 현재 선택된 편집기와 컨텍스트에서.

보고있다
다른 편집기로 전환하는 동안 우리가보고있는 셸 인스턴스를 놓치지 않으려면 구성 가능한 줄 수를 표시하는 감시 기능이이 문제를 해결할 수 있습니다. 오류가 발생하면 빠른 스크롤로 인해 사용자가 놓친 경우 아이콘으로 표시 될 수도 있습니다. 이것은 VSCode의 오류 창에서 이미 수행되었습니다. 감시자 패널은 표시 전용 일 수 있으며 그 위로 마우스를 가져 가면 더 큰 샘플이 표시 될 수 있습니다.

복잡성 부담없는 정교함
상황에 맞는 터미널을 사용하면 모든 편집자에 대해 많은 셸을 사용할 수있는 기능이 부담 스럽거나 부담스럽지 않습니다. 올바른 모델이 주어지면 UI / UX 담당자는 우아하게 작동 할 수 있습니다.

귀하의 우려 사항이 완전히 해결 될 수 있다고 생각합니다.

어떤 터미널이 사용되는지에 따라 다릅니다. 한 번의 명령을 실행하는 데 사용되는 경우 어떤 식 으로든 여러 터미널이 거의 필요하지 않습니다.

서빙, 구축, 시청, 테스트 등과 같은 여러 백그라운드 작업을 동시에 실행하는 데 사용하려면 여러 터미널이 필요합니다.

따라서이 경우 어떤 터미널이 열려 있고 무엇을 실행 중인지 (아마도 실행 상태와 함께) 빠른 개요를 볼 수 있습니다. 명명 / 만든 탭 없이 어떻게 할 수 있는지 잘 모르겠습니다.

와이드 스크린에는 적어도 하나 이상의 터미널에 사용할 수있는 공간이 있기 때문에 분할 보기도 필요합니다.

또 하나의 질문은 태스크 러너와 함께 사용하는 것입니다. 현재 한 번에 하나의 작업 만 실행하는 데 사용됩니다. 그러나이 https://github.com/Microsoft/vscode/issues/981 은 다중 백그라운드 작업을 지원할 것이라고 가정합니다.

Jetbrains Webstorm currenlty에는 이러한 기능이 있습니다. 여러 작업 (grunt / gulp / npm을 통해 정의 됨)과 여러 터미널 (이름이 지정된 탭 포함)을 실행할 수 있습니다. 또한 한쪽에는 실행중인 작업이 표시되고 다른쪽에는 터미널이 표시되는 분할보기를 사용할 수도 있습니다. (화면 부착)

뿡 빵뀨

좋습니다. 따라서 모든 시나리오와 공통성을 나열하면 VSCode가 너무 무거워지지 않고 다양한 사용을 처리 할 수있는 우아함으로 필요한 기능을 추출 할 수 있습니다.

피로없는 많은 탭
편집기의 컨텍스트에 바인딩 된 터미널을 사용하면 사용성 연결 해제 문제 (예 : 어떤 탭이 어떤 편집기에 연결되는지)가 발생하면 터미널 / 에디터 컨텍스트 내에서 쉘 이름을 지정하는 하이퍼 텍스트 문자열 인 '소프트 탭'을 사용할 수 있습니다. 사용자가 탭 사냥을하지 않고 더 많은 탭을 사용할 수 있으며, 컨텍스트 / 연관 피로가 머릿속을 추적하는 것을 피할 수 있습니다.

명명 된 쉘
터미널 창 내에서 쉘 인스턴스의 이름을 보여주는 간단한 하이퍼 텍스트 문자열의 아이디어로 대체 생성 및 이름 지정의 가능성이 있습니다. 따라서 사용자에게는 settings.json에 구성된 단일 셸이 있으며 'cmd'일 수 있습니다.

일단 셸에 있으면 'powershell'또는 'bash'와 같은 다른 셸로 이동할 수 있으며 터미널 헤더의 'cmd'라는 하이퍼 텍스트 문자열은 사용자가 이동 한 셸을 반영하도록 변경할 수 있습니다.

또는 사용자는 터미널 창에서 "새로 만들기"로 인식하는 명령을 사용하여 스타터 'cmd'셸에서 추가 셸 인스턴스를 만들 수 있습니다.".

아이디어는 명명 된 셸이 연결 해제 된 탭이 아니라 부모 편집기 내의 셸이라는 사실을 UI에 암시하는 것입니다. 나는 '탭'이라는 용어를 사용하여 다른 것과는 분리 된 분리되고 독립적 인 쉘을 나타냅니다. 하드 탭이 글로벌이고 소프트 탭이 편집기 컨텍스트 내에있는 모드 일 수 있습니다.

하드 탭 / 소프트 탭 모드가 포함 된 경우 편집자를 표시하는 탭과 같이 하드 탭에 하드 보더가있을 수 있습니다. 이름의 동작은 소프트 탭과 동일합니다.

중요한 것은 확립 된 UI / UX 모델을 유지하는 것입니다. 우리는 모두 단일 앱 내에서 여러 UI 구현에서 모델이 분리되는 많은 경우를 보았습니다. 사실, 마이크로 소프트는 이것에 능숙합니다 (그리고 최근에는 애플). '위원회 별 디자인'의 전형적인 사례 다.
설립

간단한 단일 셸 사용자
그러나 사용자가 단순하고 단일 터미널 / 쉘을 실행하려는 경우이를 달성하는 방법이 없으며 중요한 것은 구성이 간단하다는 것입니다. 고려 매트릭스의 또 다른 사용 시나리오 일뿐입니다.

탭이 추가 될 예정이라면 통합 터미널의 단일 인스턴스를 비활성화 / 강제하는 구성 옵션을 갖고 싶습니다. 이러한 _advanced_ 기능이 필요한 경우 일반적으로 선택한 (외부) 터미널을 사용합니다.

나는 또한 터미널 분할 (더 고급 분할)과 같은 것을 고려할 것이므로 모든 실행중인 (아마도 두 개 이상) 중요한 터미널은 눈 앞에 부분적으로 출력됩니다.

파일 탭과 같은 위치에 터미널 탭을 표시하는 것은 어떻습니까?
UI를 오염시키지 않으며 기능적으로 손실되지 않습니다.

@cescoferraro 나는이 아이디어를 좋아한다. 그러나 VS Code는 수평뿐만 아니라 수직 분할 탭보기도 지원해야합니다. 그렇지 않으면 공간을 낭비하지 않고 여러 터미널을 볼 수있는 조건을 실제로 충족하지 못할 것입니다.

@Phisherman 오해 하지 마십시오. 나는 분할 터미널을 좋아합니다.
저는 Intellij에서 큰 화면과 많은 메모리 설정으로 많이 사용합니다.
결정이 무엇이든간에 가능한 한 빨리 VSCode를 유지하기 위해 많은 메모리를 사용한다면 플러그 가능해야합니다.

npm / gulp 작업을 선택할 수있는 확장 프로그램을 작성했습니다. 터미널 (작업 이름 포함)을 실행하고 거기에서 실행하고 언제든지 클릭 할 수있는 상태 표시 줄에 항목을 배치합니다. 실행중인 프로세스 상태의 기본 추적을 수행합니다.

가능한 "탭"위치를 표시하기 위해 teminal의 맨 아래에있을 수 있습니다.

@whitecolor : open_mouth : 이것은 새로운 터미널 API를 사용하고 있습니까? 굉장합니다!

@Tyriar 그래, 당신이 작업하고있는 사람 : wink :

@whitecolor 에서 언급했듯이 WebStorm에는 터미널 탭이 있으므로 IDE의 접근성이 향상됩니다. 이 WebStorm 외에도 시작할 항목을 시각적으로 식별하는 데 도움이되는 탭의 이름을 변경할 수 있습니다.

WebStorm이하지 않는 것은 열린 터미널 탭의 수를 저장하지 않는다는 것입니다.
개발할 때 일반적으로 동일한 탭 (서버, 감시자, 백엔드 ...)이 필요합니다. 탭의 수와 이름을 저장할 수 있다면 멋질 것입니다.

@whitecolor 그것에 대해

• vscode가 다시 시작되면 표준 터미널이 생성되며 여기에 상태 표시 줄 항목을 연결할 수 없습니다.
• 확장 프로그램은 사용자가 터미널을 처분 할 때 인식하지 못하므로 상태 표시 줄 항목은 적어도 다시 클릭 할 때까지 계속 유지됩니다. # 10925
• (버그) 단말기를 폐기하면 패널 # 11275가 표시됩니다.
• 또한 v1.6.0에서는 터미널이 기본적으로 숨겨 질 가능성이 높으므로 생성 직후에 Terminal.show 를 호출해야합니다. # 11384

@Tyriar 공유해 주셔서 감사합니다.

1) 예, 그다지 중요하지 않습니다. 내 확장 프로그램은 실제로 "새 터미널 열기"명령을 추가하고 새 이름이 지정된 터미널을 열 수 있습니다. 보통 표준을 닫고 생성 된 것을 사용합니다.하지만 액세스 권한이 있으면 좋을 것입니다. 패널에있는 모든 기존 터미널.
2) 예 확장은 터미널 상태를 알지 못하지만 terminal._id 의 자식 프로세스를 PID로 추적하므로 터미널이 사용자에 의해 언제 폐기되는지 알 수 있습니다 (자식 프로세스가 0이 됨). 그래서 앞으로이 프로세스 ID를 _remove_하지 말라고 요청하는 것은 이것이 공개되어야하는지 확실하지 않습니다). 따라서 실행중인 자식 프로세스의 양도 추적하고 개수가 감소하면 문제가 있거나 작업 실행이 완료되었음을 의미 할 수 있습니다.이 터미널은 매우 유용합니다.
3) 그래서 현재 dispose를 사용하지 않습니다.

실제로 부족한 것은 프로세스 출력에 대한 액세스이며, 이는 더 유용한 분석 (예 : 일부 오류 / 예외 출력 추적)을 만들고 사용자에게 터미널을 보여줄 수 있도록합니다.

확장 프로그램은 실제로 게시 할 준비가되었습니다. 아마도 며칠 후에이 작업을 수행 할 것입니다.

@whitecolor는 현재 API를 통해 생성 된 터미널에만 액세스 할 수 있지만, 이는 변경해야 할 매우 매력적인 경우입니다.

Sneaky sneaky peeking at terminal._id : wink : 아마 조만간 변경되지는 않겠지 만들을 수있는 이벤트가 추가 되 자마자 공식 안정적인 API가 될 것이므로 확실히 활용해야합니다. 하위 프로세스 추적 및 출력은 # 11422에서 살펴볼 것입니다 (주제에 대한 일부 토론을 위해 링크 된 문제를 따를 수 있습니다).

명명 된 터미널 명령을 사용하면 # 10023에 대한 해결 방법도 제공됩니다. : smiley :

수고하셨습니다. 사용해 볼 수 있기를 기대합니다!

@whitecolor FYI, 그래서 거짓말을했고 terminal._id 는 아마도 v1.6에서 PID가 아닌 임의의 ID로 변경 될 것입니다. 터미널 패널과 프로세스를 더 분리하기 위해 거대한 리팩터링을 진행 중이며 (따라서 기존 # 11275 패널 없이도 존재할 수 있습니다) 불행히도 거기에 둘 수 없다고 생각합니다.

@whitecolor 내일의 내부자에서 window.onDidCloseTerminal (# 10925)를 사용해 볼 수 있습니다. PID를 추적하는 것보다 쉬울 것입니다.

InteliJ처럼보고 싶었습니다. 이 때까지 다음과 같은 개인 키빙을 추가합니다.

[
    {
        "key": "ctrl+pageup",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },{
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }
] 

탭 사이를 탐색하는 동일한 키보드 단축키이지만 커서가 터미널에 초점이 맞춰져 있으면 터미널 사이를 전환합니다.

터미널 탭의 분할보기는 매우 유용합니다.

현재 서버 인스턴스로 개념 증명을 수행하고 다른 콘솔 터미널을 통해 요청을 실행하려고합니다.

이것에 대한 진전이 있습니까?

안녕하세요.
tmux 는 해결책이 될 수 있지만 VSCode 통합 터미널 내에서 작동하지 않습니다 (마지막 Windows에서).

@MeirionHughes 는 https://github.com/Microsoft/vscode/issues/7504 기능에 대한 문제입니다

@Tyriar 당신은이 문제가 세 번째 이미지에서 명시 적으로 보여주는 것처럼 분할을 요구한다고 말할 수 있습니다. 게다가이 문제는 112 👍 :)

@MeirionHughes 의 첫 번째 댓글 (내)은 다음과 같이 말합니다.

# 7504에서 터미널 분할을 추적합시다.

그 이유는 두 가지 다른 기능에 대한 논의가 서로에게 잡음을 일으키지 않기 때문입니다.

오 얘들 아, pls는 정말 중요한 UI 기능으로 도움이되며 때로는 콘솔을 전환하기 위해 crz 핸들 드롭 다운을 만듭니다. 감사합니다.)

cycle terminal 키 바인딩에 +1.

@whitecolor _darn! _ 통합 터미널 내의 tmux 이 내 자신의 영리한 해결 방법이라고 생각했지만, 저를 이겼습니다. 나를 위해 잘 작동하지만 ( mouse mode ) 창은 잘 작동합니다.

tmux에서 마우스 모드가 잘 작동합니다.

어쨌든 이것은 큰 추가라고 생각합니다

정말 유용 할 것 같아요. 그러나 나는 그것이 터미널에 국한되어서는 안된다고 생각하지 않고 "문제", "출력"등의 탭도 포함해야하므로 "터미널", "문제"및 편집기를 하나의보기에서 열 수 있습니다.

또한 터미널을 순환하기 위해 키 바인딩에 +1 만 할 것입니다. 특히 트랙 패드가있는 랩톱에서 작은 드롭 다운을 클릭하기 위해 마우스를 사용하는 것이 싫습니다.

터미널을 순환하는 키 바인딩을 주시면 분할 / 탭 없이도 할 수있을 것 같습니다.

@ psimoneau22 이것은 내가 사용하는 키 바인딩입니다.

{ "key": "ctrl+shift+j",    "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",    "command": "workbench.action.terminal.focusPrevious" },

곧 분할을 검토 할 예정입니다.

이 편집기가 얼마나 훌륭하고 강력한 지 믿을 수 없습니다. 이것은 코딩 세션 중에 vscode를 열고 다른 것은 아무것도없는 강력한 추가 기능입니다.

TL; DR; 몇 시간 동안 tmux를 선택하십시오.

터미널의 tmux에 만족합니다 (마우스 모드는 매력처럼 작동합니다). 배우는 데 하루가 걸렸습니다. 나는 몇 번 전에 그것을 가지고 놀았지만 어제 보스처럼 그것을 설정했습니다. 터미널 창을 시작하는 iTerm에서 tmux -CC 만 수행합니다. 그런 다음 vscode 터미널에서 tmux a 을 (를) 수행하여 해당 세션에 연결합니다. 이것은 영구 터미널 세션을 가져 와서 vscode를 다시 시작할 때 항상 세션별로 돌아갈 수 있습니다 (Vscode 업데이트, 확장 설치). 이것은 터미널에 탭이나 분할을 갖는 것보다 훨씬 더 나은 기능입니다. Vscode 빛을 유지하십시오. Atom은 배울 수있는 교훈입니다. TMUX FTW :)

이 동일한 접근 방식은 Mac / cygwin / windows에서도 작동했으며 Vscode가 실행되는 거의 모든 곳에서 작동합니다.

TL; DR;

드롭 다운 대신 통합 터미널에 대한 탭이 있으면 좋을 것입니다. 앞으로이 기능을 볼 기회가 있습니까?

단축키 ctrl + shift + ` 및 ctrl + `를 고려하면 이러한 설정이 더 합리적이라고 생각합니다.

  {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious"
    }

@leocaseiro @Tyriar @ psimoneau22 Mac을 사용하지 않는 한 '언제'옵션을 ctrl + shift + left 및 ctrl 와 같이 추가하는 것이 좋습니다. shift + right 는 편집기에서 텍스트 청크를 선택하는 데 사용됩니다.

    {
        "key": "ctrl+shift+j",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+k",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

또는

    {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

여기에이 매우 바람직한 기능에 대한 내 2ct가 있습니다 (일부 요점이 이미 언급 된 경우 죄송합니다)

사용 사례
첫 번째 경우에 여러 터미널을 사용하는 이유는 일반적으로 다음 중 하나입니다.

• 두 개의 디렉토리에서 병렬로 작업해야하며 cd 항상 앞뒤로 작업하고 싶지 않습니다.
• 두 개의 다른 터미널로 작업해야합니다 (예 : bash vs powershel vs cmd 또는 로컬 vs 원격 / ssh)
• 두 개의 다른 프로그램의 출력을 병렬로 모니터링하고 싶습니다.

세 번째 경우에만 터미널의 분할보기가 필요합니다. 대부분의 다른 경우에는 가능한 한 많은 공간을 사용하는 하나의 터미널을 선호합니다.

UI
현재 탭 (예 : 디버깅, 출력, 터미널 ...)을 확장하고 추가 "터미널 1, 터미널 2, 터미널 3 ....)

탭 vs 드롭 다운

• 모든 사용 가능 탭이 표시됩니다.
• 뚜렷한 시각적 위치 (예 : 세 번째 탭)로 표시되는 경우 어떤 터미널이 어떤 용도로 사용되는지 기억하는 것이 더 쉽습니다.

tl; dr

@MikeGitb에 강력하게 동의하며 항상 한 번에 두 개 이상의 터미널을 사용합니다. 현재 VS 코드의 터미널 드롭 다운은 열린 탭을보기가 어렵습니다. 통합 터미널 용 탭이 있으면 정말 멋질 것입니다. 감사.

미친 아이디어 하나 : 터미널에 일반 편집기 탭과 동일한 상태를 부여하지 않는 이유는 무엇입니까? 동시에 몇 줄 이상을 보려는 경우 특히 유용합니다.

하나의 미친 아이디어

미친 것이 아닙니다. 이것이 vim / neovim이 작동하는 방식입니다.

미친 것이 아닙니다. 이것이 vim / neovim이 작동하는 방식입니다.

다른 많은 IDE와 마찬가지로;).

죄송합니다. 그 인트로는 실제로 아이러니하게 의미가 있습니다.

@Tyriar 코드와 함께 터미널의 수직 이동을 허용하는 기능이 있습니까? 아니면 허용되지 않습니까?

https://github.com/Microsoft/vscode/issues/2806 에서 다루는 @ajrator

터미널에 편집기 탭과 동일한 상태를 제공하는 것은 완전히 행복 할 것입니다. ComEmu와 HyperTerminal은 모두 현재 사용을 방해하는 심각한 문제가 있습니다 (ConEmu에는 유지 관리자가 XP 지원을 유지하기를 원하기 때문에 수정할 수없는 대비 문제가 있습니다. HyperTerminal은 할 수 없습니다.) PowerShell 및 기타 기본 사항에서 Ctrl + C). 작동하는 탭 터미널로 vscode를 사용하는 것은 환상적입니다.

또한 드롭 다운 대신 통합 터미널의 탭보기를 게시 할 때도 계속 지켜보고 있습니다.

드롭 다운 메뉴는 사용하기가 조금 불편합니다. 또한 둘 이상의 열린 터미널이 있으면 좋을 것입니다.

탭 지원을 기다리는 동안 tmux 를 사용 해보고 싶은 사람들을 위해 설정을 시작하는 요지를 만들었습니다. 기본적으로 마우스 지원이 활성화되어 있으며 간단한 바인딩을 사용하여 터미널을 분할합니다.
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

감사합니다 @cybertim , 훌륭한 파일! 이미 tmux를 사용했지만이 파일은 편리합니다.

제가 개인적으로 창 내의 다른 위치에있는 여러 터미널에 대해 매우 예리한 이유는 VSCode 내에서 환경과 같은 RStudio / Jupyter Lab을 구현하는 길을 이끌 수 있기 때문입니다.

개인적으로 모든 것이 탭이되고 패널을 수직 및 수평으로 무한 분할 할 수있는 기능을 제공하고 싶습니다. 그런 다음 터미널, 탐색기 및 검색과 같은 가장 일반적인 도구를 유지하기 위해 탭을 고정하는 기능을 제공 할 수도 있습니다.

이전 편집기에는 상단의 긴 도구 모음을 따라 저장, 실행 취소, 다시 실행 버튼이 있습니다. VSCode에는 없습니다. 그 이유는 무엇입니까? 사람들이 키보드를 사용할 것으로 예상되기 때문입니다. 우리는 프로그래머입니다. 이전 터미널, 다음 터미널 모두 바로 가기 키에 바인딩 할 수 있습니다. 사용하십시오. 나는 우리가이 문제를 종결하고 중요한 것으로 넘어 간다고 말한다.

다음으로, 여전히 탭을 원하십니까? 창? 분할?

여기에 많은 사람들이 VScode에 과잉 인 기능을 요청하고 있다고 생각합니다. 그들이 단지 tmux를 시도 한다면, 그들은 이것을 요구하지 않을 것입니다. 터미널이 우리에게 주어졌습니다. tmux를 사용하여 탭을 지원합니다. tmux를 배우려면 최대 몇 시간이 걸립니다. 탭, 창, 분할 등이 있으므로 VSCode를 다시 시작해야하는 경우 다시 시작한 후 tmux -a 를 입력하여 tmux 세션으로 바로 돌아갈 수 있습니다. 마우스 모드를 켠 후 (구성에서 한 줄만) 창 크기를 조정하고 탭을 클릭하여 해당 탭으로 이동할 수도 있습니다. VSCode에서이 기능에 반대합니다. 성능이 저하 될뿐입니다. VSCode를 가능한 한 가볍게 유지하십시오-우리는 다른 Atom을 원하지 않습니다. tmux가 무거운 작업을하게하십시오! 아래에서 볼 수 있듯이 분할이 있고 하단을 자세히 보면 python & fish 라는 두 개의 탭이 있습니다. 그리고 네, 왼쪽 하단에서 Google 명령 줄에서 googler 를 사용합니다. : D

@piggyslasher 이 기능이 어떻게 vscode를 느리게 만들 수 있는지 모르겠습니다.
Vscode는 이미 둘 이상의 터미널 인스턴스를 지원합니다. 이 기능은 드롭 다운 선택기를 탭 기능을 사용하기에 더 좋은 것으로 변경하는 것입니다.

이 기능을 사용하면 tmux와 함께 하나의 터미널 인스턴스 / 탭을 계속 사용할 수 있으며 지금과 비교하여 성능 변화를 기대할 수 없습니다.

Vscode는 다중 플랫폼 편집기입니다. 사람들에게 tmux를 사용하라고 말하는 것은 그 사람들을 tmux를 사용할 수있는 환경으로 제한하는 것입니다. 또한 tmux는 이처럼 간단한 기능에 대해 완전히 과잉 인 큰 학습 곡선을 가지고 있습니다.

@piggyslasher 의 제안은 'tmux'방식으로 생각하면 흥미 롭습니다.

이것은 제가 오랫동안 생각해 왔던 것입니다. Tmux에는 tabs 있으며 각 tab 는 원하는만큼 panes 로 분할 할 수 있습니다. 대조적으로 편집자에게는 panes 있고 각 pane 에는 tabs 가있을 수 있습니다.

나는 '이 터미널 레이아웃이 관련되어 있으며 관련 터미널의 다른 탭으로 전환합니다'와 같기 때문에 tmux 방식을 선호합니다.

반응 / 각도 개발과 같은 경우 각 구성 요소에 대해 JS / HTML / CSS / Test 'pane'이 열려 있고 작업중인 모든 구성 요소에 대해 'tab'이 있으면이 기능이 유용하다는 것을 알 수 있습니다.

플러그인에서 이와 같은 일을 할 수 있는지 궁금합니다. Sublime 용 Origami 는 가깝지만 '창으로 가득 찬 탭'이 아니라 '탭으로 가득 찬 창'입니다.

탭 및 기타 UI 메커니즘을 통해 콘솔 관리를 도입하는 범위와 규모에 대해 많은 우려가 있습니다. 해결중인 문제가 매우 명확하게 정의되면 범위 및 규모 파열 및 사용자 기대 문제가 진행되고 있음을 지적하고 싶습니다. 솔루션의 우아함으로 인해 완화됩니다. 문제를 매우 명확하게 정의하면 솔루션이 더 명확해질 것이며 논리는 UI와 UX 전체에서 일관 될 가능성이 더 높습니다. 아시다시피, 우리 모두가 사용하고 만드는 것을 즐기는 "그냥 작동한다"는 감각.

또한이 스레드에서 제공되는 다양한 솔루션과 확인 된 우려 사항 (아마 들여 쓰기 된 글 머리 기호 / 숫자)에 대한 글 머리 기호 또는 번호가 매겨진 목록을 갖는 것이 좋습니다. 이와 같은 스레드는 중앙, 큐레이팅 된 위치 또는 초기 게시물에서 이러한 항목을 업데이트하지 않고도 원을 그리며 이동할 수 있습니다.

모든 사람들이 현재 존재하는 것 이상으로 어떤 형태의 콘솔 관리가 필요하다는 데 동의하는 것 같습니다. 스케일 문제를 해결하기위한 제안 : 사용자가 콘솔을 편집기 또는 편집기 그룹에 연결할 수있는 옵션을 제공하십시오. 콘솔이 분리되도록 허용하되 설정에서 사용자 정의 기본값을 지정하십시오. 콘솔을 에디터 컨텍스트에 연결하면 과도한 콘솔 생성을 줄이는 데 도움이됩니다. 또한 다른 편집기를 선택하면 한 편집기의 콘솔이 숨겨 지므로 UI ​​복잡성이 낮아집니다. 콘솔이 편집자와 관련이 없으면 일이 손에 닿지 않을 수 있으며 사람들은 어떤 콘솔이 무엇을하고 있는지 잊어 버릴 것입니다.

파일의 이름과 위치를 기반으로 (또는 파일 속성의 다른 더 안정적이고 고유 한 식별자를 기반으로) 편집기에 대해 정의 된 콘솔을 앱에 저장할 수 있도록 사용자 구성 가능 설정을 추가하는 것이 좋습니다. 시스템 수준).

이 수준의 개선이 IDE 수준에 가까워지고 있다고 말할 수 있지만 제작자는 VSCode가 IDE의 장점 중 일부를 편집기 공간으로 가져 왔다고 이미 말했습니다. 무겁거나 복잡하지 않고 뛰어난 UX를 가져 오는 동시에 작동하는 콘솔 솔루션을 도입 할 수 있습니다.

이것이 말이되지 않거나 내가 명백한 것을 말하면 알려주세요.

@ nick-walt는 다음과 같이 말합니다.

사용자가 콘솔을 편집기 또는 편집기 그룹에 연결할 수있는 옵션을 제공합니다.

터미널이 셸 인스턴스를 특정 열린 파일과 연결하는 기능을 제안하고 있습니까?

당신이 그것을 지나치게 복잡하게 만드는 것처럼 들립니다. 물론 상자 밖에서 계속 생각하되, 유사한 기능에 대해 본 것에서 vscode 팀은 이와 같은 작은 기능의 영향을 최소화하기를 좋아합니다. 그래서 나는 그들이 사람들을 행복하게 만드는 가장 간단한 (여전히 효과적이지만) 해결책을 찾고있을 것입니다.

이 문제의 가장 기본적인 점은 드롭 다운 메뉴가 사물 사이를 전환하는 데 적합하지 않고 탭이 꽤 좋은 대안이라는 것입니다. 따라서 대부분의 항목이 탭을 사용하는 이유 : 편집기, IDE, 브라우저 등. 여기 모든 사람들이 동의 할 것이라고 생각합니다. 본질적으로 모든 형태의 탭이 드롭 다운보다 선호됩니다.

쉘 인스턴스간에 전환하는 방법의 가장 기본적인 부분 외에도 동시에 둘 이상의 인스턴스를 표시 할 수있는 방법도 있습니다. 맨 아래에있는 터미널 섹션의 창을 통해 또는 터미널 탭을 어떤 방식 으로든 편집기 탭과 교환 할 수 있도록하거나 다른 솔루션을 사용합니다. 이 부분은 더 복잡하며 어느 길로 가야할지에 대한 합의가 거의 없을 것입니다. 특히 @sorahn 이 방금 탭 내부 창과 탭 내부 창에 대해 지적한 점을 고려할 때.

개인적으로 드롭 다운을 제거하고 (정말 좋지 않기 때문에) 탭으로 교체하고, 나중에 고급 항목에 대해 걱정할만큼 충분한 지원이 있다고 생각합니다.

1 년 전 @ bgashler1이 이렇게 말했습니다.

탭을 도입하고 터미널로 분할하는 것에 대한 두려움은 편집자 그룹처럼 보일 수 있다는 것입니다. 사용자가 편집기를 터미널로 드래그하거나 터미널을 편집기 그룹으로 드래그 할 수 없다는 사실에 실망하지 않기를 바랍니다. * 또한이 기능을 도입하면 창 관리에 왜 특별한 수평이 있는지 등의 미끄러운 경사가있을 수 있습니다. 처음에 이와 같은 것을위한 패널. 사용자 정의 UI에서 많은 기능을 복제하는 대신 터미널을 원하는 곳에 두지 않는 이유는 무엇입니까?

그렇다면 현재로서는 혼동을 피하기 위해 편집기 탭과 눈에 띄게 다른 탭을 고려하는 것이 최선일까요?

동의합니다. 탭은 다른 콘솔을 선택하는 데 매우 좋은 솔루션입니다.

콘솔과 편집기를 연결하는 기능을 활성화하는 방법은 사용자 설정을 변경하는 것 뿐이라고 생각합니다. 활성화되면 편집기가 선택된 상태에서 콘솔을 열면 연결이 생성 될 수 있습니다. 저것과 같이 쉬운.

UI는 애플리케이션 상단에서 새 편집기 (파일)를 선택하면 편집기가 변경됨에 따라 하단의 콘솔 탭이 변경 될 가능성이 높습니다. 매우 간단하고 직관적입니다.

다음과 같은 일부 사용자 컨텍스트를 기반으로 개별 콘솔을 둘 이상의 편집기와 연결하는 기능을 추가하는 경우에만 더 복잡해질 것이라고 생각합니다.

• 디렉토리 위치
• 계획
• 파일 유형 (파일이 같은 위치에있을 수 있음)
• 편집기 그룹화 (사용자 정의)
• 다른 추상화

이 경험은 컨텍스트에서 선택된 편집기에 상관없이 지정된 콘솔이 동일하게 유지되는 것입니다 (또는 사용자가 모든 편집기가 모든 콘솔을 사용할 수 있기를 원하기 때문에 동일하게 유지됨).

UI가 표시되는 방식은 복잡성을 피하고 직관적이고 빠르고 사용하기 쉬운 느낌을 유지하기 위해 창의성을 발휘해야하는 부분입니다. 좋은 UI 디자인으로 복잡성은 기능을 만드는 팀에게만 존재합니다. :)

콘솔 탭과 편집기의 연결을 강화하기 위해 콘솔 탭이 포함 된 창에 편집기 이름이 명확하게 표시됩니다.

그리고 각 탭은 터미널 1, 터미널 2 등을 표시하는 대신 Git, Node, CMD, Powershell ...과 같은로드 된 콘솔 유형을 자동으로 표시 할 수 있습니다 (@Perkovec에 의해 표시됨 ). 이것은 응용 프로그램에 의해 자동으로 생성됩니다.

이를 통해 사용자는 해당 git 또는 powershell 프롬프트를 찾는 탭을 탐색하지 않고도 원하는 콘솔을 직접 선택할 수 있습니다.

다른 옵션은 애플리케이션 코어에 기본 탭 엔진을 제공하고 사용자가 콘솔 관리에 더 많은 기능을 추가하기 위해 선택한 확장을 추가 할 수 있도록하는 것입니다. 어느 시점에서 많이 사용되는 기능을 핵심 앱으로 롤링 할 수 있습니다.

내가 올바르게 이해한다면 터미널을 편집기 창과 연결하는 것에 엄격히 반대합니다. 대부분의 경우 편집기 탭과 터미널 사이에 고정 된 관계가 없으며 그렇게 할 때 확실히 1 : 1 매핑이 아닙니다 (일반적으로 1 : N도 아님).

@MikeGitb 사용자 기본 설정의 가중치에 따라 편집기와 콘솔 설정의 기본 연결이 활성화되거나 비활성화 될 수 있다고 생각합니다.

어떤 사람들은 그들이 무엇을하고 있고 어떤 콘솔을 사용하는지에 따라 두 가지를 혼합하고 싶을 수도 있습니다. 이것은 제작자가 해결해야 할 UI / UX 문제를 개선 한 것입니다. 모든 UI / UX 챌린지와 동일합니다.

상황 별 편집기 / 콘솔 UX의 사용 사례는 다음과 같습니다.

• 컨텍스트 없음 (특정 편집기와 관련된 콘솔 없음)
• 혼합 된 컨텍스트 (일부 콘솔은 연관되고 일부는 아님)
• 모든 컨텍스트 (편집기와 관련된 모든 콘솔)

BTW, 저는 콘솔 탭 확산 (및 원치 않는 혼란 / 오버 헤드)을 최소화하기위한 옵션으로 편집기와 콘솔의 연결을 제안합니다. 상황 별 편집기 / 콘솔 UX를 사용하면 다른 컨텍스트의 편집기를 선택하자마자 연결된 콘솔이 숨겨 질 가능성이 높습니다. 사용자는 항상 선택한 편집기와 관련된 내용 만보고 있습니다.

평소처럼 UI 구현은 이런 종류의 것을 만들거나 깨뜨릴 것입니다. VSCode 팀은 이미 UI로 매우 놀라운 작업을 수행했으며 복잡하고 과부하 된 느낌을주지 않고는보다 정교한 콘솔 관리 경험을 구현하는 방법을 알아낼 수 없다고 생각할 이유가 없습니다.

우리 모두가 이전에 경험 한 것처럼, 점점 더 새로운 소프트웨어로 인해 사용자에게 훨씬 더 높은 수준의 복잡성과 정교함을 노출시키면서 경험을 더 쉽고 단순하게 만드는 것은 매우 가능합니다.

사용 사례를 이해하기 위해 : 프로젝트 / 디렉토리가 아닌 특정 파일에 바인딩 된 터미널에서 수행하는 작업의 종류를 물어봐도 될까요?

내 일반적인 사용 사례는 git을 사용하고, 프로젝트를 컴파일하고, 바이너리를 실행하고, 일부 추적 출력을 보는 것입니다. 이들 모두는 현재 열려있는 파일과 독립적이지만 주로 C ++ 프로젝트 또는 단일 파일 편집에 사용하고 있으므로 다른 영역에는 다른 워크 플로가 필요할 수 있습니다.

거의 모든 사람들이 편집기 탭과는 독립적으로 터미널 인스턴스를 사용합니다. 이러한 기능은 확장 기능으로 더 나을 것입니다.

예, 확장 기능으로 콘솔 경험을 확장하는 데 동의합니다. 아마도 개발 단계까지이 영역을 여는 가장 좋은 방법 일 것입니다.

모두가 빌드 할 수있는 VScode에서 콘솔 엔진을 만드는 것은 흥미로운 실험이 될 것입니다.

다음은 Cloud9 IDE의 작동 방식에 대한 클립입니다.

우리 중 많은 사람들이 찾고있는 것처럼 보입니다. 모든 새 탭은 편집기 또는 터미널이 될 수 있으며 모든 탭을 수평 또는 수직으로 이동 및 분할 할 수 있습니다.

@plmrry 멋지네요! 그 방향으로 뭔가가 정말 좋을 것입니다.

@plmrry 우리가 그와 같은 매우 유연한 창 시스템을 가질

편집기 탭에 여러 터미널이 있고 일부는 전경에, 일부는 배경에있는 경우 특정 터미널 명령이 수행하는 작업에 대한 질문은 명확하지 않으며 직관적이지 않습니다.

터미널 명령이 마지막으로 초점을 맞춘 것을 대상으로 할 수 있습니까? cmd + shift + t가 마지막으로 닫은 탭을 대상으로하는 것과 같은 방식으로

@btoo 그것은 아마도 그런 세상에서 할 일입니다. 그것은 VS Code가 작동하는 방식에있어서 매우 급진적 인 변화입니다.

나는 PHPstorm에서 왔고 터미널 탭이 없다는 것은 정말 실망 스럽습니다. 모든 Brainstorm 제품에는 터미널 탭이 있으며 매우 유용한 기능입니다.

실제로 유용한 기능입니다. 개발자에게 추가 해달라고 요청 합니다. 이렇게하면 동시에 2 개 이상의 항목을 모니터링해야하는 작업이 더 쉬워집니다. 듭니다.

+1
터미널의 탭은 선택하는 것보다 UX 친화적이며 많은 공간을 차지하지 않습니다.

+1

이것은 한 번에 둘 이상의 화면을 볼 수 있기 때문에 여전히 iterm 및 cmder 분할 화면을 사용하는 이유 중 일부입니다. vscode는 현재 한 번에 여러 개를 실행할 수 있으므로 동시에 둘 다 표시 할 수있는 기능이 추가됩니다 (가로로 분할 되든 탭이 성능을 방해하지 않아야 함).

성능 문제가있을 경우 npm을 한 탭에서 서버를 실행하고 다른 탭에서 mongod를 실행하면 vscode가 중지됩니다 (또는 누군가가 실행해야 할 여러 명령이 무엇이든간에).

이것에 대한 작은 업데이트 : 나는 현재 터미널을 액세스 가능하게 만드는 데 소비되고 있습니다 (https://github.com/Microsoft/vscode/issues/8339). 그 후 내가 작업 할 다음 주요 부분은 아마도 터미널 분할 (https://github.com/Microsoft/vscode/issues/7504)은이 문제에서 분리되었습니다 (그리고이 문제를지지하는 많은 사람들이 정말로 원하는 것입니다). 이것은 로드맵 https://github.com/Microsoft/vscode/wiki/Roadmap#terminal에 있습니다.

@AnthonyMichaelc 다중 표시에 대한 성능 문제가 없으며 최근 개선 사항 이후 터미널이 매우 빠릅니다.

(분할)은 아마도 찬성하는 많은 사람들이 정말로 원하는 것입니다.

@Tyriar 분할이 아닌 탭을 원하기 때문에 탭을 upvoted했습니다. 나는 다른 사람들의 대부분이 그들이 투표 한 것을 의미한다고 생각 합니다. 수직 또는 수평으로 좁은 터미널은 나를 위해 그것을하지 않습니다.

... 나는 그 모든 것을 읽었고이 아이디어를 놓쳤다는 것을 믿을 수 없습니다.

새 터미널을 열 때 기존 탭 표시 줄에 추가 탭을 추가하지 않는 이유는 무엇입니까?
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
... 또한, 디버그 콘솔은 실제로 디버거를 사용하지 않는 경우별로 유용하지 않습니다.

(그리고 많은 사람들이 이것을 정말로 원하는 것 같습니다)

이 항목 만 붙여 넣겠습니다 .... (이 항목의 첫 번째 게시물)

@ericblade 의 의견 외에도 동시에 최소 2 개의 패널 (문제, 출력, 콘솔, 터미널 등)을 보도록 해주세요!
예를 들어 서버를 디버깅하는 동안 다른 서비스 또는 파일 감시자가 항상보기를 전환하지 않고 내 클라이언트를 빌드하는 출력을 관찰하고 싶습니다. 키보드 단축키를 통해서도 마찬가지입니다.
분할 터미널 (Windows에서도;)을 시작으로 기꺼이 환영하지만 왼쪽 / 중간 / 오른쪽 패널에 배치 할 수있는 유연한 탭은 UI를 어지럽히 지 않고 vscode의 "관찰 데크"를 상당히 개선 할 것입니다.

@PixelT 인용하는 게시물의 첫 번째 이미지는 제목이 말한대로 탭이 추가 된 것입니다. 별도의 PR을 제출하고 분할을 위해 여기에 연결 하시겠습니까?

@mikemaccana 다시 한 번 내 게시물을 이해하고 읽으십시오. 이해하지 못하는 것을 보았 기 때문에 + 아무것도 제거하지 않았습니다. :]

@PixelT 맞습니다 . 사진을 삭제했다고 잘못 생각했습니다. 죄송합니다. 즉, 제목과 첫 번째 제안은 분할이 아닌 탭이며 분할에 대한 별도의 문제가 좋을 것입니다.

@mikemaccana 분할 : https://github.com/Microsoft/vscode/issues/7504

탭이 있지만 기본적으로 해제 할 수있는 옵션이 있습니까?

분할 미리보기가 Insiders에 도착했습니다. https://github.com/Microsoft/vscode/issues/7504#issuecomment -365683609에서 전체 업데이트를 확인

나는 이것이 확실히 올바른 방향으로 나아가는 단계라고 생각합니다. 나는 누군가가 왜 내가 15 개의 터미널을 넣을 수 없는지 불평 할 것이라고 확신하지만 나를 위해 이것을 가지고 있고 좋을 것입니다. 평균 스택과 같은 작업을 수행하는 경우 nodemon 및 mongo 등에 대한 이중 터미널 하나를 가질 수 있으며 ng serve 및 생성 명령을 실행하기 위해 다른 터미널 쌍을 열 수 있습니다.

이제 안정된 vscode 버전에이 옵션이 있고 모든 꿈을 기다려 왔던 그리드 레이아웃을 갖는 다른 기능 요청이 진정한 하하가 될 것입니다.

참고 : opt / alt + cmd / ctrl을 빠르게 앞뒤로 전환하려고하면 몇 분 동안 만 사용했을 때 초점이 약간 뒤처진 것처럼 보였습니다. (그냥 나일지도 몰라)

안녕하세요.

나는 누군가가 왜 내가 15 개의 터미널을 넣을 수 없는지 불평 할 것이라고 확신하지만 나를 위해 이것을 가지고 있고 좋을 것입니다.

계획은 실제로 원하는만큼 허용하는 것이지만 지금까지 n = 2에 대한 문제 만 해결했습니다.

그리드 레이아웃

우리는이 문제를 지금 적극적으로 논의하고 있으며 2 월의 반복 계획 https://github.com/Microsoft/vscode/issues/43361 에도 자리를 잡았습니다.

참고 : opt / alt + cmd / ctrl을 빠르게 앞뒤로 전환하려고하면 몇 분 동안 만 사용했을 때 초점이 약간 뒤처진 것처럼 보였습니다. (그냥 나일지도 몰라)

아직 보지 못했지만 속도가 느린 지 계속 살펴 보겠습니다.

안녕하세요.

평균 스택과 같은 작업을 수행하는 경우 nodemon 및 mongo 등에 대한 이중 터미널 하나를 가질 수 있으며 ng serve 및 생성 명령을 실행하기 위해 다른 터미널 쌍을 열 수 있습니다.

여러 터미널과 편집기를 동시에 사용하는 것은 매우 편안합니다. 일상 생활에서 첫 번째 터미널은 개발 서버용이고 두 번째는 단위 테스트 용이며 때로는 세 번째는 git 용입니다.

VSC를 터미널 탭 중 하나로 열어 Windows 용 cmder 터미널에서 이것을 보관하는 해키 방법이 있습니다. (여기) Visual Studio Code에 대한 기본 솔루션을 기다릴 수 없습니다. 이 방법.

@Tyriar 내가 볼 수 있듯이,이 topis는 터미널의 탭 에 관한 것입니다.

@PixelT 는 분명히 관련이 있습니다. 이 문제에서 많은 사람들이 분할이 당분간 해결되는 여러 터미널을 동시에 볼 수 있다고 언급 했으므로 유용하다고 생각합니다.

나는 당신과 동의 할 수 없습니다-이 주제는 주로 터미널에서 탭을 원하는 사람들을 관찰하고 토론합니다.

터미널 탭 및 분할은 오늘날 거의 모든 최신 IDE의 표준입니다.

내부자 빌드로 전환하여 이것을 테스트하고 놀랍게 작동합니다. 감사합니다. @Tyriar !

여전히 터미널의 탭에 대해서는 아무 일도 일어나지 않습니다 ... 😕

@PixelT 듀얼 터미널이있는 내부 버전을

@Morkowski 나는 당신이 한 일을 봅니다. 그래, 나는 창문과 osx 랩톱을 가지고 있으므로 Windows 컴퓨터에서 cmder를 사용하고 osx 컴퓨터에서 iterm을 사용하고 그리드 내부에 적어도 2 ~ 3 개를 만듭니다. 평균 스택 응용 프로그램에서 작업 할 때 레이아웃 및 4입니다.

@Tyriar 약간의 피드백- Maximize Panel Size 또는 Restore Panel Size 버튼 (또는 키보드 단축키)을 사용하여 콘솔의 크기를 조정할 때 콘솔 창의 너비가 잊혀지고 각 창의 너비가 동일한 금액으로 재설정하십시오.

마우스를 사용하여 콘솔을 위 / 아래로 크기를 조정할 때 너비가 기억됩니다.

마찬가지로 왼쪽 막대를 숨기거나 표시 할 때 너비가 잊혀집니다.

마지막으로 창을 추가하거나 제거 할 때 너비를 잊어 버립니다.

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

@jamesjryan https://github.com/Microsoft/vscode/issues/45074에서 언급 한 처음 2 개에 대해 최신 내부자에서 수정 된 문제가있었습니다.

마찬가지로 왼쪽 막대를 숨기거나 표시 할 때 너비가 잊혀집니다.

최신 정보를 재현 할 수 없습니다. 문제가 보이면 문제를 생성 해주세요.

마지막으로 창을 추가하거나 제거 할 때 너비를 잊어 버립니다.

예 이것은 설계된대로입니다 🙂

누군가가 여기서 다시 터미널 탭이 아닌 분할 터미널에 대해 쓰고 있습니다. 이 티켓에서 알림을받을 때 우리가보고 싶은 것이 아닙니다.

7504

@Tyriar 업데이트-설명대로 작동합니다. 감사합니다!

@KillyMXI 그것은 최종 목표를 향해 진행되고 있으며 현재 형태에서도 매우 유용한 구현입니다.

@isidorn 우리가 처음에 이와 같은 것을 어떻게 지원할 것인지에 대해 생각해

나는 때때로 큰 타이틀을 처리하는 방법을 정말로 모른다. 그리고 다른 것과 명확하게하기 위해 여기서 터미널을 말할 필요가있다. 즉, 이것은 (두 개의 탭, 하나는 분할되어 있음)이있는 일반적인 설정이며 다른 패널 제목을 숨기지 않고도 최대화하면 내 노트북 ​​화면에 쉽게 맞습니다.

최종 게임은 사용자가 원하는 곳에 터미널을 배치 할 수있는 유연성을 제공한다고 생각하지만, 이것이 좋은 임시 방편 솔루션일까요?

@jamesjryan 탭을 향한 진행으로 Tyriar의 솔루션을 볼 수 없습니다. 나에게 완전히 직교하는 것처럼 보입니다.

주변에 유용한 것들이 많이 있지만 적절한 장소가 있습니다. 분할 터미널의 적절한 장소는 다른 티켓입니다.

마지막으로 탭으로 돌아갑니다.

비슷한 것이 위에서 제안되었습니다. 실제로 : https://github.com/Microsoft/vscode/issues/10546#issuecomment -359632932
드롭 다운을 터미널 목록으로 대체 할 때 가장 분명한 점입니다.

나는 노력했을 것입니다

• 터미널 탭을 오른쪽에 맞 춥니 다.
• 또는 터미널 앞에 수직선을 추가하십시오.
• 또는 오른쪽에 정렬하고 왼쪽 항목에 가까워지면 수직선을 표시합니다.

차라리 모든 탭에 "터미널"이라는 단어를 넣는 것을 피하고 싶습니다. 그것이 무엇인지 충분히 분명해질 것입니다.
또는 "터미널 :"이라는 단어를 일종의 시각적 구분 기호로 사용할 수 있습니다.

Problems   Output   Debug Console                  Terminals:  Git   Bash, Bash   +   []   ^

그래서 이것이 제가 여기서 바라는 최종 결과입니다.

https://atom.io/packages/terminal-tab 에서

간단하고 이해하기 쉬우 며 최종 사용자에게 IDE 분할 / 구조화 방법에 대한 유연성을 제공합니다.

혼란 스럽습니다. 맨 아래, 오른쪽, 왼쪽 또는 전체 화면에 이미 하나의 터미널이있을 수 있습니다.

맨 아래, 오른쪽, 왼쪽 또는 전체 화면에 이미 하나의 터미널이있을 수 있습니다.

우리는하다? 왼쪽에 터미널을 생성하려면 어떻게합니까? 지금은 아래쪽 또는 오른쪽 만 볼 수 있습니다.

당신은 떠날 수 없지만 여전히이 GIF에 혼란 스럽습니다. ㅋㅋ

Atom 플러그인에 대해 잘 모르겠지만 (사용했다고 말할 수는 없지만) 여러 터미널을 열 수 있다고 가정하고 모두 개별 탭으로 처리됩니다.

가장 중요한 것은 일반 편집기 탭과 동일하게 작동한다는 것입니다. 코드가있는 곳과 동일한 위치로 이동할 수 있습니다. 웹 IDE Cloud9는 이와 매우 유사한 작업을 수행합니다. 원하는만큼 터미널을 열 수 있으며 분할 화면 + 탭 레이아웃 내의 작업 공간에서 원하는 위치에 자유롭게 배치 할 수 있습니다.

아마도 제가 그 우려를 오해하고 있을지 모르지만 기본적으로 UX 디자이너는 서로 다른 종류의 탭 간의 혼동에 대해 걱정하고 있습니다.

기본적으로 탭 막대를 숨기고 1 개의 "탭"이 표시됩니다. 드롭 다운 물건을 유지하십시오.

그런 다음 새 터미널이 실행되면 사용자가 옵션을 설정하면 드롭 다운을 제거하고 탭 막대를 표시합니다.

내가 뭔가를 놓치고 있습니까?

다른 편집기 탭과 마찬가지로 터미널을 탭으로 만들고 사용자가 창을 배치 할 방법을 결정하도록하는 것이 가장 좋습니다.

이것은 위의 "혼란스러운"gif가 보여주는 것입니다.

예, gif가 더 혼란스러워했다면 미안하지만 이것은 기본적으로 내가 도달하려는 전제입니다.

UX 디자이너가 혼란에 대해 걱정하는 점에서 터미널을 열면 당신이 무엇을하고 있는지 알 수 있고 전혀 혼란스럽지 않을 것이라고 생각합니다.

일종의 해결 방법으로 다음 키보드 단축키를 설정했습니다.

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious"
}

마우스와 그 추악한 선택기를 사용하지 않고도 터미널간에 빠르게 전환 할 수 있습니다.

@vedmant 당신은 그것이 또한 바람직한 경우 터미널에 초점을 맞출 때만 작동하도록 조정할 수 있습니다.

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
}

이와 같은 것이 이미 제안 된 경우 (댓글 만 훑어 봤음) 미안하거나이 문제를 새로운 문제로 만들어야합니다. 어느 쪽이든 알려주세요.

문제 # 14909에 대한 진행 상황을 감안할 때. 다른 탭과 동일하게 위치 관점에서 취급되는 일반 탭에 터미널을 넣을 수있는 옵션이 있습니까? 이것은 사용자가 터미널을보고 싶은 방식에 대해 많은 유연성을 제공합니다. 일반 탭을보고 정렬하는 방법에 대한 유연성이 이제 (또는 곧) 터미널이 비교에 의해 매우 제한됩니다.

@Tyriar workbench.action.terminal.focusPrevious 가 작동하지 않는 것 같습니다.

Defaults Kebindings에서 사용하는 방식이므로 workbench.action.terminal.focusPreviousPane 도 시도했지만 작동하지 않습니다 ( workbench.action.terminal.focuNextPane 도 작동하지 않음).

간단히 말해서 workbench.action.terminal.focusNext 작동합니다.

    {
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "cmd+pageup",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }

VSCode 버전

Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

운영체제 : lubuntu 18.04

확장없이 테스트 됨

편집하다

Tyriar에게 감사합니다. 위의 ctrl 대신 cmd 를 썼습니다.

@caub 도움 이 필요하면 새로운 문제를 만들어야합니다 (우분투 18에서는 항상 잘 작동했습니다).

최근에 단말기가있는 곳에 문제가 있음을 깨달았습니다. 문제 탭을 동시에 볼 수 없게됩니다.

여러 프로젝트가있는 작업 공간이있는 것 같습니다. 당신이 할 수있는 일은 프로젝트 당 하나의 터미널을 가지고 편집기의 포커스 된 파일 (및 그것이 속한 프로젝트)을 기반으로 해당 터미널에 대한 확장 포커스를 갖는 것입니다.

특정 문제를 해결하지는 못하지만 쉽게 전환하고 문제를 파악할 수 있습니다.

터미널 선택이 실제로 실용적이지 않다는 데 동의합니다. 1: bash , 2: bash , .. 폴더 basename을 표시하는 것이 훨씬 낫습니다.

@caub 참조 https://github.com/Microsoft/vscode/issues/29816

더 많은 연습을 통해이 탭 제안이 가장 좋은 방법이라는 것을 깨달았습니다. + 1 :, 현재 나는 여전히 VSCode와 독립적으로 내 OS 터미널을 사용합니다.

또한 터미널이 그리드 레이아웃의 일부로 살 수 있다면이 문제가 잘 해결 될 수 있고 모든 것이 어디에서나 스냅 될 수있는 UX 관점에서 훨씬 더 의미가있을 것이라고 생각합니다.

@mrmckeb 동의합니다. 탭과 분할을 모두 처리 할 수있는 방법은 모르겠지만 가능합니다. Tmux가 그것을합니다.

이미 매우 유연하게 텍스트 편집기 창에서도 터미널을 도킹 할 수 있기를 바랍니다.

나는이 문제를 꽤 오랫동안 지켜 왔고 여전히 이것이 구현되기를 바라고 있습니다. 비슷한 문제가 다소 정기적으로 열리는 것을 봅니다. 바라건대 정확히 무엇을 요구하고 왜 (적어도 내 관점에서) 요약 할 수 있습니다.

뭐

기본적으로 내가 바라는 것은 새 터미널이 _ 선택적으로 _ _ 편집기 탭 _으로 생성되어 기본적으로이 Atom 확장 의 동작을 복제 할 수 있다는 것입니다 (Atom에서 VSCode로 전환 한 이후로 놓친 것입니다). 새 터미널 탭이 생성되면 편집기 탭과 동일한 방식으로 처리되고 편집기 그룹에 배치됩니다. 터미널 탭은 UI에서 편집기 탭과 동일하게 처리됩니다.

시작하기 위해 터미널 탭을 패널의 터미널과 교환 할 필요가 없습니다. 피드백을 수집하기 위해 처음에는 완전히 별개의 엔티티로 생성 될 수 있습니다.

왜

나는 실제로 터미널에 살고 있으며 이러한 방식으로 터미널 탭을 사용하면 다음과 같은 모든 문제와 사용 사례를 해결할 수 있습니다.

• 두 개 이상의 터미널을 동시에보고 사용합니다. 3 개 이상의 터미널을 배열하여 쉽게 할 수 있지만 에디터 그리드에서 좋아합니다.
• 터미널 탭만있는 VSCode 창을 열어 VSCode를 유일한 터미널 에뮬레이터로 사용합니다.
• 동시에 여러 터미널을 열어 두었지만 지금은보고 싶지 않습니다.

터미널 탭의 세계에서도 편집자 그룹과 구별되는 패널의 존재가 유용하다는 것을 알게 될 것이며 패널 분배를 옹호하지 않을 것입니다. 패널은 내가 함께 일하고있는 _ 기본 콘텐츠 _와는 다른 보조 정보를 배치하는 것이 합리적입니다. 제가보기에 핵심은 터미널이 보통 보조 콘텐츠가 아니라 _ ​​일급 콘텐츠 _라는 것입니다. 이러한 관점에서 터미널이 편집자와 함께 사는 것은 완전히 자연스러운 일입니다.

@sagebind 패널 내 에서 터미널 탭을 활성화하는 첫 번째 단계는 드롭 다운을 덜 끔찍한 것으로 바꾸는 것입니다. 그러면 다음과 같은 방식으로 구축 할 수 있습니다.

1. 패널을보다 유연하게 배치 할 수 있습니다. https://github.com/Microsoft/vscode/issues/57029 , https://github.com/Microsoft/vscode/issues/50984 , https://github.com/Microsoft/ vscode / issues / 37877 , https://github.com/Microsoft/vscode/issues/10121
2. 개별 터미널이 패널에서 "분리"되고 얘기하는대로 편집기 그리드에 배치되도록 허용하는 방법을 조사하십시오 (이 문제에서 추적 한 종류). UX, 명령, 키 바인딩 및 확장 API에 미치는 영향을 파악하려면 약간의 작업이 필요합니다.

또한 @sagebind ,

구식 게이머라면 진동 스타일 드롭 다운 (Ctrl + ~)이 있습니다. 그래서 내 모든 termals는 갈 시간이 될 때까지 숨겨져 있습니다.

이 확장 프로그램은 탭을 깔끔하게 만드는 방법을 보여줍니다.

https://marketplace.visualstudio.com/items?itemName=Tyriar.terminal-tabs

@PauloDanielCarneiro That Extension은 실제로 VSCode 자체의 수석 개발자 중 한 명 (@Tyriar)이 제작했습니다.

나는이 문제가 오래되었다는 것을 알고 있지만 이것은 놀랍습니다.

이는 모든 SysAdmin이 ISE에서 VSCode로 완전히 이동할 수 없도록하는 기능이 누락되었습니다.

SysAdmin으로서 저는 대부분의 시간을 여러 컴퓨터에서 동시에 작업합니다.

CTRL + SHIFT + R을 사용하여 원격 컴퓨터에 연결합니다.
연결된 컴퓨터 이름으로 명명 된 새 터미널 탭이 열립니다.
그리고 모든 터미널 탭은 아래의 하나 또는 여러 스크립트 탭에 연결됩니다.
CTRL + R을 사용하여 스크립트 탭에서 터미널 탭으로 또는 그 반대로 전환합니다.

매우 쉽고 편리하며 강력합니다 ...

이 기능을 고려 중입니까?

대체품은 아니지만 cmd-\ 를 사용하여 터미널을 분할 할 수 있습니다.

감사합니다 @ Hum4n01d 그게 더 낫습니다.

@ Hum4n01d 제 경우에는 Ctrl+] 터미널을 분할하거나, 아이콘을 클릭하여 터미널 창 오른쪽 상단의 Kill Terminal 옵션 옆에있는 터미널을 분할 할 수 있습니다.

2 개 또는 3 개의 터미널 만 필요한 경우이 기능이 매우 유용하다고 생각합니다 (터미널을보기 위해 탭에서 다른 탭으로 전환 할 필요가 없기 때문에 탭보다 더 좋습니다).

여러 터미널이 필요한 경우에만 이것이 해결책이 아닐 수 있지만 탭도 (그 자체로) 아닐 수도 있지만 대신 탭 + 부동 창 (https://github.com/Microsoft/vscode)이 필요합니다. / issues / 10121).

나는 여전히 여기에서 가장 좋은 접근 방식은 Atom 팀이 코드 탭과 교환 할 수있는 터미널을 사용하는 것입니다. 이러한 방식으로 사용자는 모듈 방식으로 원하는 작업 공간을 만들 수 있습니다.

터미널 영역의 탭은 멋지지만 코드 탭이 터미널 인스턴스를 래핑하는 데 시간을 할애 할 수 있는데 왜 그렇게하는 데 투자할까요?

안녕하세요. 나는 내가 가지고있는 문제에 대해 검색하러 갔고 결국 여기까지 왔습니다.

제가하고 싶은 것은 터미널 을 일반 편집기 탭으로 사용하는 것뿐입니다.

내 15 인치 노트북 디스플레이는 빌드 출력 섹션 패널에 꽉 채워진 작은 터미널을 엉망으로 만들기에 충분하지 않습니다. 빌드에서는 잘 작동하지만 터미널 사용에는 부적절 할 수 있습니다.

실제로 작업 할 수 있도록 Panel의 크기를 크게 조정하면 갑자기 빌드 출력 팝업이 너무 커지는 것이 의미가 없습니다. 그리고 빌드 출력에 적합하도록 작게 만들면 터미널 작업에 사용할 수 없습니다. 이러한 UI 개념은 함께 섞이지 않고 탭 바에 추가하면 더 이상 광기가 있습니다.

말 그대로 터미널에서 수행하는 작업이 작업을 실행할 때 탭 사이를 전환하는 패널의 일부가되는 것을 원하지 않으면 어떻게합니까? 아니면 동적으로 위아래로 튀어 나오나요? 그래서 빌드 할 때마다 다른 탭 시스템에서 탭

패널을 경쟁 관용구가있는 병렬 UI 시스템으로 바꾸는 것은 나쁜 생각입니다. 다양한 사람들이 확장 기능에서 열악한 해킹과 해결 방법으로이 작업을 수행하려고합니다. 따라서 Microsoft가 문제를 수정하여 상황을 제어하면 좋을 것입니다.

@Zyrsha- 이 경우 왜 VS Code를 사용하고 있습니까? 여러 탭이있는 운영 체제와 함께 제공되는 실제 터미널을 직접 사용하여 더 많은 가치를 얻을 수있는 것처럼 들립니다. 정직한 질문 / 매우 혼란스러운 독자.

BTW vscode는 터미널을 사용하는 최초이자 유일한 IDE입니다. 제 13 형 노트북에서는 잘 작동합니다. eclipse 또는 webstorm과 같은 다른 IDE의 경우 빠른 전환 및 창 주문을 위해 Awesome WM 을 사용하게되어 매우 기쁩니다.

터미널 (또는 다른 "창")을 일반 탭으로 사용하는 것이 좋으며 이클립스에서 작동한다고 생각합니다. 그러나 터미널은 적어도 저에게는 약간 다른 작업 흐름을 가지고 있습니다. "오른쪽"터미널로 빠르게 전환 할 수있는 가능성이 필요합니다. 다른 사람들과 마찬가지로 터미널 탭 을 사용합니다.

불행히도 이와 같은 문제 때문에 완벽하지 않습니다. 게다가, 왜 vsc에 정교한 터미널이 내장되어서는 안되는지 이해할 수 없습니다.

@ shane-smith

여러 개의 탭이있는 운영 체제와 함께 제공되는 실제 터미널.

Windows와 함께 제공되는 콘솔 응용 프로그램에는 AFAIK를 지원하는 탭이 없습니다. 그래서 끝났습니다. 그리고 Linux에는 터미널 에뮬레이터 자체가 포함되어 있지 않습니다 (배포판의 경우). 원하는 것을 선택해야합니다. 이 경우 @Zyrsha 가 좋아하는 것이 VS Code 인 것 같습니다.

쫑끼리

이 경우 @Zyrsha 가 좋아하는 것이 VS Code 인 것 같습니다.

오, 동의합니다-VS Code의 터미널은 굉장합니다. 개선의 여지가 있다는 데 동의하기 때문에이 문제에 대해 언급하고 있습니다.

내가 혼란스러워하는 부분은 다른 사람이 터미널을 사용하여 모든 파일을 편집하려는 것 같다는 것입니다. 따라서 실제로 내장 기능을 사용하지 않는 경우 VS Code를 사용하는 이유가 궁금합니다. 파일 편집기? 그들의 의견을 다시 읽으면 아마도 나는 결론에 도달했고 그들은 터미널에서 _some_ 파일 만 편집하고 싶어합니다.

안녕하세요.

내가 혼란스러워하는 부분은 다른 사람이 터미널을 사용하여 모든 파일을 편집하려는 것 같다는 것입니다. 따라서 실제로 내장 기능을 사용하지 않는 경우 VS Code를 사용하는 이유가 궁금합니다. 파일 편집기? 그들의 의견을 다시 읽으면 아마도 나는 결론에 도달했고 그들은 터미널에서 _some_ 파일 만 편집하고 싶어합니다.

아니요, 그들은 편집기 탭과 같은 터미널 탭을 원합니다. Cloud9, Atom 및 일부 다른 편집기 (Vim 및 Emacs 포함)에있는 것과 정확히 같습니다. Mac 또는 Linux를 사용하는 사람들의 경우 창 위쪽에 편집기가 있고 아래쪽에 일부 터미널 탭이있는 것이 당연합니다.

Theia-IDE조차도 여러 터미널 탭을 가질 수 있으며 VSCode의 일부를 기반으로합니다.

이 스크린 샷을 살펴보면 다음을 이해할 수 있습니다.

https://discourse-cdn-sjc1.com/business5/uploads/trydiscourse4/optimized/2X/a/a6c21ba006e249a65bb0c4c2ecf94296d6daad20_1_666x500.png

https://lh3.googleusercontent.com/eI50dceQrsPJDhqQmM_QMjd4rkORHRRd_Y3rbnD1M6KYbKulXI72PFC-A0y-SDraVJAXhGTFcg=w640-h400-e365

좋습니다. 잠시 이유를 무시하고 방법에 집중하겠습니다.

이것이 어떻게 구현 될까요? 터미널이 현재 위치에있는 구조적인 이유가 있습니까?

플러그인이 탭에서 터미널을 제공하도록하는 것이 효율적인 방법으로 가능할까요?

      Ok, let's ignore the why for a moment and focus on the how:

이것이 어떻게 구현 될까요? 터미널이 현재 위치에있는 구조적인 이유가 있습니까?
플러그인이 탭에서 터미널을 제공하도록하는 것이 효율적인 방법으로 가능할까요?

아키텍처 측면에서 :

• VSCode에는 하나의 단일 콘솔 (PowerShell 통합 콘솔)에 연결된 많은 스크립팅 탭이있어 하나의 단일 시스템에서 여러 스크립트 를
  처음에 VSCode는 개발자를 위해 개발자가 작성했습니다.

• ISE는 반대 방식으로 구축되었습니다. 여러 콘솔을 열고 각 콘솔에 여러 스크립팅 탭을 연결할 수 있습니다 (여러 컴퓨터에서 동시에 작업하는 데 매우 좋습니다).
  우리는 서로 다른 컴퓨터에서 동시에 여러 스크립트를 작성하고 실행합니다 .
  처음에 ISE는 SysAdmins를 위해 설계되었습니다.

다행히도 ISE 방식 (콘솔 탭에 연결된 스크립팅 탭)은 개발자에게도 작동합니다.
그러나 현재 VSCode 방식 ( "하나의 단일"스크립팅 탭에 연결된 콘솔 탭)은 SysAdmin에 적합하지 않습니다.
(콘솔에 연결된 스크립트에서 스크립트에 연결된 콘솔로) 방식을 바꾸고 싶지 않거나 바꿀 수 없다면 적어도 각 스크립팅 탭을 연결할 콘솔 탭을 선택할 수 있어야합니다.

나는 ISE에 대해 아무것도 모르지만 화면 하단에 영구적으로 부착하기보다는 자체 탭이나 창에 터미널을 가질 수 있기를 원합니다. 코드 파일에서 터미널로 앞뒤로 전환하기 위해 높이를 조정할 필요가 없습니다.

또한 터미널 탭은 _ 두 개 이상의 터미널을 활성화하려는 문제를 _does_ 해결하지만 UX 관점에서 볼 때 파일에 사용되는 동일한 탭에 터미널을 두는 것이 더 좋습니다. 이렇게하면 두 개의 표준이 아닌 탭 전환을위한 두 개의 표준 키 바인딩과 터미널 탭에 대한 두 개의 표준 키 바인딩이 있습니다 (특정 터미널 탭으로 전환하기위한 숫자 키 바인딩은 포함되지 않음). 이러한 탭을 사용하여 편집기를 분할하거나 탭을 다른 VS Code 창으로 이동하거나 탭으로 할 수있는 다른 작업을위한 워크 플로는 동일하며 표준 UX를 생성합니다. 현재로서는 두 가지 다른 UX 워크 플로가 있으며 두 가지를 사용하여 많은 것을 얻지 못합니다.

나는 왜이 시점까지 수행되지 않았는지, 또는 해결 방법으로 터미널 탭을 사용하는 이유를 이해하지만 편집기 탭 / 버퍼 / Emacs, Atom 등에서 전반적으로 수행되는 터미널은 표준으로 VS Code에서보고 싶은 UX 경험.

Nuclide가 더 이상 사용되지 않으므로 VS Code로 전환하고 싶지만 터미널에서 모든 빌드 출력을 읽을 수 있기를 정말 좋아합니다. VS Code에서는 매우 어렵습니다. 터미널을 특정 지점으로 강제 이동해야하고 다른 모든 탭 / 창과 동일하게 취급되지 않는 이유는 무엇입니까?

저에게 가장 큰 문제는 마우스 없이는 내가 몇 개의 터미널을 열 었는지 알 수 없다는 것입니다. 그리고 임의로 자전거를 타지 않고 특정 터미널에 가려면 어느 방향으로 가야하는지 알 수있는 방법이 없습니다. 탭은 내 첫 생각 이었지만이 문제를 해결하는 다른 방법이 있다고 생각합니다. 예를 들어 선택적으로 활성 터미널이 강조 표시된 상태로 탐색 표시 줄에 활성 터미널을 표시 할 수 있습니다.

이것이 어떻게 구현 될까요?

리눅스의 경우 좀 더 일반적인 접근 방식의 특별한 경우로 구현할 수 있습니다. 사용자 정의 명령을 실행하고 새 탭의 X 창 식별자를 제공합니다. 그런 다음 터미널에 대해 xterm … -into $VSCODE_TAB … 를 실행할 수 있지만 다른 항목도 매우 쉽게 통합 할 수 있습니다. 프로젝트 디렉터리 (명령이 실행 된 작업 디렉터리의 기본값)로 VSCode 인스턴스를 검색하고 해당 인스턴스에서 탭을 열고 stdout에 X win id를 인쇄하는 CLI 명령이 있으면 좋을 것입니다.다른 경우 VSCode의 $DISPLAY 따라서 모든 외부 유틸리티는 VSCode의 GUI에 참여할 수 있습니다.

편집 2 : 실제로 터미널에 관한 것이 아니기 때문에 그 아이디어에 대한 새 티켓을 열 것입니다.

아니 !!! 탭은 UI를 나쁘게 보이게합니다 ....

안녕하세요.

아니 !!! 탭은 UI를 나쁘게 보이게합니다 ....

나는 그들을 비활성화하거나 숨기는 것이 쉬울 것이라고 매우 낙관적입니다.

드롭 다운을 버튼으로 변환하고 기본 편집기의 탭과 동일한 스타일을 지정하기 만하면됩니다.

명확하게 말하면 탭이 다른 모든 탭 (예 : 소스 코드 탭)과 상호 교환이 가능하기를 원합니다. Atom에있는 것처럼.

그냥 명확하게하기 위해, 나는 OPS는 2016 년부터 주목 갔다 요청 주어진 하나 @andraz의 또는 @floydnoel의 솔루션을 취할 것입니다

@kitsirota 주목을 @Tyriar 에 더 많은 정보가있을 수 있습니다.

나는 이것이 수요 때문에 곧 주목을받을 것으로 기대한다. 나도 그것을 정말로 원한다. 또한 @jaxspades가 언급했듯이 로드맵에 있습니다.

VSCode를 사용하기 시작한 첫날부터이 창과 부동 창을 기다립니다. 현재 ConEmu를 사용하고 있습니다. 현재 부착되고 드롭 다운 된 터미널은 편리하지 않습니다.

ConEmu를 계속 사용하고 있다면 Windows Terminal을 사용해보고 싶을 수도 있습니다.

아직도 이것을 기다리고 있습니다 :)

"출력"과 "디버그 콘솔"을 동시에보고 싶습니다.

꼭 탭이 필요하지는 않지만 문제와 터미널을 동시에보고 싶습니다. 그러나 어떤 종류의 레이블 없이는 구별하기 어려울 수 있으므로 탭이 가장 좋습니다. 따라서 터미널 용 분할 패널을 제거하고 모든 패널 유형 (문제, 출력, 터미널 등)에 대해 추가 탭을 허용해야한다고 생각합니다. 여러 "출력"또는 "문제"탭이 필요한지 실제로는 알 수 없습니다. 데이터는 동일합니다. 따라서 새 탭을 추가하고 추가 할 유형을 선택할 때 문제가 이미 열려 있으면 회색으로 표시되고 두 번째 탭을 추가 할 수 없으며 터미널 만 여러 번 사용할 수 있습니다. 또한 상태 표시 줄의 문제 및 경고 표시기를 클릭하면 새 문제 탭이 자동으로 열리고 이미 열려있는 경우 제거됩니다.

데이터가 동일하기 때문에 여러 "출력"또는 "문제"탭이 필요한지 실제로는 알 수 없습니다.

• 화면 / 키보드 / 입력 초점을 사용자에 대한 고전적인 1 : 1 매핑을 넘어선 창의적인 다중 사용자 집합.
• 단일 사용자가 여러 화면 또는 화면 영역에 문제 해결에 사용되는 도구를 배포합니다. 이 경우 각 문제 / 출력 패널에 대해 독립적 인 필터 설정, 스크롤 위치 등을 갖는 것이 유용합니다.
• 스크린 캐스팅 소프트웨어에서 이국적인 버그 / 누락 된 기능을 해결합니다.

@Tyriar @jaxspades 는 1754 : +1 : 및 187 : heart : 충분하지 않습니까? 그리고 34 : rocket :? 얼마 여야합니까?

아직 열려있어?!

크라우드 펀딩이 도움이 될까요? 돈은 어디에 두나요?

@Bessonov 터미널 탭을 원하지만 Microsoft가 아니기 때문에 할 말이 없습니다. 하지만 화면 하단의 작은 창이 아니라 편집자 역할을하고 싶습니다. 따라서 버전 1.43은 검색 편집기와 함께 제공되었으므로 터미널이 곧 출시되기를 바랍니다. @Tyriar , 검색 편집기가 터미널 탭 / 편집기에 가까워지는 데 도움이됩니까?

편집 : 검색 편집자 문제에 대한 링크 추가.

23931

다시 말하지만, 이것은 로드맵에 있으며 제 시간에 일어날 것입니다. 당신은 나에게 말할 필요가 없습니다. 나는 여기있는 모든 사람들보다 더 원할 것입니다. 그리고 그것이 두 번째로 가장 많이 득표 된 문제라는 것을 잘 알고 있습니다. 그러나 표면에서 볼 수있는 것처럼 사소한 작업은 아닙니다. 유연한 워크 벤치 레이아웃에 적극적으로 투자하고 있습니다.

• 패널에서 검색
• 편집기에서 검색
• 모든 패널 및 뷰렛보기는 상호 교환 가능

이러한 모든 노력은이 문제가 궁극적으로 어떻게 해결 될지에 영향을 미치고 터미널에서 작업을 크게 차단합니다. 패널보기와는 다릅니다.

하지만 화면 하단의 작은 창이 아니라 편집자 역할을하고 싶습니다.

오래 전에 개념을 별개의 문제로 분리하려고 시도했지만이 문제는 지금 몇 가지를 다룹니다. 터미널 패널 내의 탭, 편집기의 터미널 탭 및 둘 사이에서 드래그 할 수있는 터미널 탭.

@Tyriar 업데이트에 감사드립니다. 훌륭하게 들립니다.이 모든 문제를 함께 해결하는 것은 많은 의미가 있습니다. 사용자 테스트 기회가 있으면 알려주십시오.

이 아이디어가 언급되었는지 확실하지 않지만 전체 의견을 검토했습니다.
모양 때문이 아니라 현재 모든 편집기 탭이 동일한 터미널에 연결되어 있기 때문에 터미널 탭이 필요합니다.

현재 다른 터미널에서 편집기 실행을 출력하려면 새 VS Code 콘솔을 열어야합니다.

편집기 창을 다른 터미널에 연결할 수있는 기능은 다른 컴퓨터에 대해 다른 편집기 창 코드를 실행하려는 경우 특히 유용합니다. ISE를 사용하면 동일한 콘솔에서이 작업을 수행 할 수 있습니다.
현재 VS Code를 사용하면 편집기 코드를 실행하려는 컴퓨터 수만큼 콘솔을 열어야합니다.

@Tyriar ,
메모와 함께 "문제"와 "터미널"창을 동시에 나란히 볼 수 있기를 바랍니다. 그것도 가능하기를 바랍니다.
감사

@ fullenw1 아직 들어 보지

@ggedde 우리는 이것이 UX 회의에서 어떻게 작동하는지 적극적으로 논의하고 있습니다.

문제 # 10121이 해결되면 이것은 결코 좋은 기능이

터미널 패널에는 일종의 제목이 필요합니다 ..

여러 명의 관찰자가있을 때 어떤 패널이 어떤 경로인지 알 수 없습니다.

@IceSentry 나는 문제가 있었지만 @Tyriar 는 이것이 이것의 중복이라고 말했습니다. @Tyriar 가 이것을 찬성하여 내 폐쇄했기 때문에 관련이 있다고 생각했습니다 .. 아니 나는 6 년 동안의 대화를 읽지 않았습니다. :)

아직 누군가가 이것을 지적했는지는 모르겠지만, UI에서 편집기 탭으로 교체 가능한 터미널 탭과 고정 UI 콘솔은 모두 Cloud9 IDE의 기능입니다. d 이것이 작동 할 것으로 기대합니다. 이전 터미널 창을 제거 할 필요도 없습니다. 숨길 수 있고 (현재 상태 그대로) 터미널 탭이 포함 된 일반 "편집기"창으로 교체 할 수 있습니다.

Cloud9의 터미널에 대한 또 다른 좋은 점은 직접 터미널이 아닌 (IIRC) tmux 인스턴스에 연결되었다는 것입니다. 이를 통해 프런트 엔드는 터미널 프로세스를 잃지 않고 다시 확장 (즉, 종료)하고 새 클라이언트 (클라우드 VS Code 사용자에게 매우 유용한 기능)에 원활하게 연결하고 클라이언트 터미널 인스턴스를 다른 사용자 (하이퍼 바이저)와 공유 할 수도 있습니다. 수준) 사용자.

내장 VS 코드 터미널에 대해이를 수행하는 확장이 있지만 터미널에 대한 추상화를 찾고 있다면 dtach 또는 abduco 으로 번들링하는 것이 좋습니다 .

편집기 탭이있는 UI에서 상호 교환 가능한 터미널 탭

이것은 단지 훌륭합니다.

하단 콘솔을 제거하고 모든 창 (Problems, Output, Debug 콘솔 및 모든 터미널)을 필요에 따라 열 수있는 일반 편집기 탭으로 전환 할 수 있으며 각 창 유형에는 특정 아이콘이 있습니다.

참고로 확장 정보 페이지, 설정 UI, 키보드 바로 가기 및 기타 항목은 이미 사용자 지정 아이콘이있는 일반 편집기 탭으로 이러한 방식으로 처리됩니다.

이를 통해 사람들은 편집기 탭을 분할하고 정렬하는 기존 기능을 사용하여 원하는대로 터미널을 분할하고 정렬 할 수 있습니다.

물론 터미널은 각 편집기 탭을 닫은 후에도 백그라운드에서 계속 실행되어야하며 필요에 따라 다시 열 수 있습니다. tmux 또는 dtach 를 사용하여 VSCode 다시 시작시 터미널 세션을 계속 실행하라는 추가 제안도 좋은 생각이지만 다른 문제에 속합니다.

새로운 webview api를 사용하면 이미 어느 시점까지 할 수 있습니다.
그러나 이는 모든 launch.json 처리를 직접 작성해야 함을 의미하며 이는 이상적이지 않습니다.

그러나 편집기 탭에는 Serialize / Deserialize 핸들러가있을 수 있으므로 편집기 '탭'으로 만 만드는 이점이 있습니다.
따라서 터미널에 저장 및 복원 동작을 제공 할 수 있습니다. (예 : tmux 세션 ID를 저장하고 복원시 다시 연결)

POC : https://github.com/mmis1000/Vscode-terminal-tab

@ mmis1000 지금은 확실히 webview API로 빌드 할 수 있지만 모든 통합, 명령, 링크 처리와 같은 기능, 확장 API 액세스가 누락되고 일반적으로 별도의 역할을합니다.

저장 및 복원 기능은 https://github.com/microsoft/vscode/issues/20013 에서 추적됩니다.

@Tyriar 실제로는 Terminal 인스턴스를 대신 생성하고 기본 pty 인스턴스로 사용하므로 최소한 git 통합과 같은 작업이 작동합니다 (환경을 터미널에 전달해야하는 것처럼 보입니다).

그러나 노출 된 api vscode는 너무 제한적입니다. 기본 pty 프로세스를 노출하지 않았을뿐만 아니라 stdio 및 pty resize와 같은 터미널 기능도 노출하지 않았습니다. pty 소스로 사용하는 것이 완전히 불가능합니다. 그래서 나는 스스로 pty를 스폰시켜야했다.

POC : https://github.com/mmis1000/Vscode-terminal-tab

안녕하세요 @ mmis1000 몇 가지 설치 지침을 추가 할 수 있다면 좋을 것입니다. 정말 갖고 싶어요.

@ mmis1000 이것은 핵심 제품의 일부 여야하므로 디자인에 의해 제한되며, window.onDidWriteTerminalData 이벤트에도 성능 문제가 있으므로 제안에 갇혀 있습니다. 이러한 종류의 확장은 임시 솔루션으로 유용 할 수 있지만 편집기 영역 내에서 터미널이 작동하게되면 사용자의 잠재적 인 롱테일에 대해 걱정합니다. 타격을 입을 수있는 또 다른 문제는 vscode의 일부로 제공되는 node-pty에 의존하는 것입니다. 이것은 소비를위한 공용 API가 아니며 향후 확장을 중단 할 가능성이 높습니다.

@Tyriar cloud9 사용자로서 (현재는 여전히 cloud9 사용자 임).

화면 영역을 터미널로 사용하고 tmux가 지원하는 세션을 지속적으로 사용하는 것이 유용합니다.

저는 주로 VPS를 제어하는 ​​웹 터미널로 cloud9를 사용합니다. (그리고 이것이 내가 지금도 그것을 사용하는 유일한 이유입니다. Becuase vscode는 터미널에 대해 정말로 잘못되었습니다. 실수로 터미널을 잃어버린 것은 매번 다시 여는 것은 엄청난 고통입니다).

Cloud9는 어제 브라우저를 닫기 전에 본 것과 동일한 창, 동일한 편집기, 동일한 터미널 및 동일한 세션을 항상 동일한 위치에 표시합니다. 세션을 찾을 수없는 경우 (서버가 재부팅되었을 수 있음) 최소한 동일한 환경으로 새 세션을 다시 엽니 다.

다른 온라인 편집기 서비스 (즉, 브라우저에서 열기)를 사용하려는 경우 브라우저를 닫지 않을 가능성이 낮기 때문에 (또는 적어도 확장 프로그램으로 달성 할 수있는) 이러한 서비스를 즉시 지원할 것으로 기대합니다 ( 의도적 또는 우연으로) 전혀.

(또한 cloud9이 몇 년 전에했기 때문에 이것이 기술적 인 문제라고 생각하지 않습니다)

제공된 터미널 경험 vscode는 솔직히 말해서 나에게 최신 세대 제품처럼 보이지 않습니다.

@ mmis1000 몇 가지 설치 지침을 추가해 주시겠습니까?

https://github.com/mmis1000/Vscode-terminal-tab 리포지토리에는 자체 문제 추적기가 있습니다. 그 프로젝트에 대해 물어볼 필요가 있다고 느끼는 사람은 그곳에서 물어보세요.

원격 ide / 브라우저 기반 ide에서 볼 것으로 예상되는 터미널에 대한 데모입니다.
어제 닫을 때 탭 위치 / 터미널 세션을 복원하기를 기대합니다.
It will kill the all the important tasks I am running instantly because I accidentally close the the browser / the browser crashed / the computer BSOD 대신.

그것은 또 다른 문제입니다 https://github.com/microsoft/vscode-remote-release/issues/3096 .

@xgdgsc 는 가능성이 있지만 그렇지 않습니다.

내가 기대하는 것은 로컬 vscode 인스턴스에서도 보편적으로 사용할 수있는 터미널 지속성입니다. (적어도 iterm2가하는 지점까지)
왜 이러한 유용한 기능이 원격 연결로 제한되어야합니까?

그리고 ssh 연결도 유지하지 않았고 터미널 멀티플렉서를 연결하고 거기에서 작업을 실행했습니다.

@ mmis1000 은 https://github.com/microsoft/vscode/issues/20013 에서 추적됩니다. 최신 정보는 거기에서

다음 반복에서 이것을 가질 기회가 있습니까?

일반 편집기 페이지 탭으로 터미널을 여는 것은 저에게 훌륭한 아이디어이며 이것이 매우 필요합니다.