"유일한 하드코어" 스타일로 일하는 사람들이 있습니다. 그들 중 소수가 있으며 다른 사람들에게 자신의 것을 강요하지 않고 단순히 공유합니다. 나 자신은 직장에서 (오랫동안) Linux를 사용해 왔습니다. 그런데 MT 언더와인에 문제가 많아서 골을 넣었다. 이제 많은 문제가 해결되었지만 돌아가고 싶지 않습니다.
사람들이 일하고 설명하게 하면 다른 사람들에게 도움이 될 것입니다. 물론 이 모든 것은 아마추어다.
때때로 "모든 것을 버리고 Linux로 전환할 것"이라고 생각하게 만드는 유일한 문제는 Windows의 영원한 문제입니다. 업데이트 곡선 및 MS의 예측 불가능성.
IMHO, 보여지는 대부분은 엉덩이를 통해 편도선을 자르는 것을 연상시킵니다) 예, 카피라이터에게는 유용할 수 있지만 프로그래머에게는 텍스트 입력 속도가 중요한 요소가 아닙니다. MQL 코드 작업 프로세스, 컴파일, 오류 탐색 등을 보는 것이 더 흥미로울 것입니다.
대부분의 경우 프로그래머는 코드 입력, 사소한(입력 오류 수정) 및 주요 코드 편집(즉, 리팩토링)과 같은 어리석은 활동으로 바쁘다. 컴파일 및 탐색 오류는 아주 작은 일입니다. 이것은 물론 "하기 전에 생각하기" 과정을 제외합니다 :-)
언어와 환경이 친숙하면 구문 오류가 거의 없이 즉시 작성됩니다. code-complete는 도움이 되지만 때때로 방해가 됩니다. 도대체 왜 MTEditor는 int가 인터페이스로 확장되어야 한다고 결정했을까요? VIM 또는 EMac에서는 여전히 목발을 조정할 수 있지만 일반 편집기에서는 극복할 수 없습니다. 스포츠 로또에 쓰기만 하면 됩니다.
디버깅 다른 노래와 함께 - 디버거는 어떻게 든 편집기에서 vpendyuren하지만 그는 그렇지 않습니다. 따라서 인쇄물과 로그는 우리의 전부입니다 :-)
IMHO, 보여지는 대부분은 엉덩이를 통해 편도선을 자르는 것을 연상시킵니다) 예, 카피라이터에게는 유용할 수 있지만 프로그래머에게는 텍스트 입력 속도가 중요한 요소가 아닙니다. MQL 코드 작업 프로세스, 컴파일, 오류 탐색 등을 보는 것이 더 흥미로울 것입니다.
글쎄, 개인적으로 나는 "일반 편집자"에 짜증이 난다. 손가락은 이미 vim 조합을 자동으로 누른다. 나는 메타에디터에서 편안함을 느끼지 못한다.
그건 그렇고, 입력할 때 Wim에 자동 구문 검사가 있습니까? 맹목적으로 오류 없이 코드를 작성하는 것은 매우 드문 성공입니다)
당연히 메타에디터의 표준보다 훨씬 낫습니다. clangd(lsp 서버)가 이를 담당합니다. vim coc(lsp 클라이언트)에서는 복잡한 매크로나 템플릿이 이를 혼동하지 않습니다. 그리고 배열을 전달할 때 앰퍼샌드가 방출되고 올바른 역참조 덕분에 코드가 거의 십자형이 되어 clang의 프롬프트 기능에 긍정적인 영향을 미쳤습니다. 음, 정의로의 전환도 있습니다.
플러그인이 없습니다. (글꼴과 coc만) 모든 취향에 맞게 넣을 수 있습니다. 예를 들어 왼쪽에 있는 파일의 "내비게이터"입니다.
그러나 vim은 준비가 필요합니다. 첫 페이지에 명령어 도움말에 대한 링크를 만들었는데 익숙해지는데 시간이 걸립니다.
커서를 복사/삭제/붙여넣기/이동하기 위해 화살표/마우스에서 손가락이 떼지 않을 때 코드를 작성하는 것이 얼마나 더 빠를지 상상할 수 있습니까? 물론 이것은 전체 무리 중 하나의 예일 뿐입니다.
가능성을 시각적으로 보여주는 몇 개의 비디오를 녹화하십시오. 고맙습니다.
가능성을 시각적으로 보여주는 몇 개의 비디오를 녹화하십시오. 고맙습니다.
예, 이미 있습니다
기본은 있습니다.
확실히 그런 방식은 아닙니다. 첫 번째는 프로그래머이며 소수입니다. 후자는 일반적으로 코더라고 불리며 군단입니다.
어디서, 누구에 의해, 언제?
vim이 무엇인지 묻고 싶었습니다 ...
"유일한 하드코어" 스타일로 일하는 사람들이 있습니다. 그들 중 소수가 있으며 다른 사람들에게 자신의 것을 강요하지 않고 단순히 공유합니다. 나 자신은 직장에서 (오랫동안) Linux를 사용해 왔습니다. 그런데 MT 언더와인에 문제가 많아서 골을 넣었다. 이제 많은 문제가 해결되었지만 돌아가고 싶지 않습니다.
사람들이 일하고 설명하게 하면 다른 사람들에게 도움이 될 것입니다. 물론 이 모든 것은 아마추어다.
때때로 "모든 것을 버리고 Linux로 전환할 것"이라고 생각하게 만드는 유일한 문제는 Windows의 영원한 문제입니다. 업데이트 곡선 및 MS의 예측 불가능성.
예, 이미 있습니다
기본은 있습니다.
IMHO, 보여지는 대부분은 엉덩이를 통해 편도선을 자르는 것을 연상시킵니다) 예, 카피라이터에게는 유용할 수 있지만 프로그래머에게는 텍스트 입력 속도가 중요한 요소가 아닙니다. MQL 코드 작업 프로세스, 컴파일, 오류 탐색 등을 보는 것이 더 흥미로울 것입니다.
IMHO, 보여지는 대부분은 엉덩이를 통해 편도선을 자르는 것을 연상시킵니다) 예, 카피라이터에게는 유용할 수 있지만 프로그래머에게는 텍스트 입력 속도가 중요한 요소가 아닙니다. MQL 코드 작업 프로세스, 컴파일, 오류 탐색 등을 보는 것이 더 흥미로울 것입니다.
대부분의 경우 프로그래머는 코드 입력, 사소한(입력 오류 수정) 및 주요 코드 편집(즉, 리팩토링)과 같은 어리석은 활동으로 바쁘다. 컴파일 및 탐색 오류는 아주 작은 일입니다.
이것은 물론 "하기 전에 생각하기" 과정을 제외합니다 :-)
언어와 환경이 친숙하면 구문 오류가 거의 없이 즉시 작성됩니다. code-complete는 도움이 되지만 때때로 방해가 됩니다. 도대체 왜 MTEditor는 int가 인터페이스로 확장되어야 한다고 결정했을까요? VIM 또는 EMac에서는 여전히 목발을 조정할 수 있지만 일반 편집기에서는 극복할 수 없습니다. 스포츠 로또에 쓰기만 하면 됩니다.
디버깅 다른 노래와 함께 - 디버거는 어떻게 든 편집기에서 vpendyuren하지만 그는 그렇지 않습니다. 따라서 인쇄물과 로그는 우리의 전부입니다 :-)
코드 완성은 도움이 되지만 때로는 방해가 됩니다.
99%의 경우에 도움이 됩니다. 따라서 모든 MQL 함수 및 유형은 헤더 파일에 선언되어야 합니다. vim.mqh 파일에서 내가 볼 수 있듯이 지금까지 함수의 작은 부분만 선언되었습니다.
언어와 환경이 익숙할 때 구문 오류가 거의 없이 즉시 작성
그건 그렇고, 입력할 때 Wim에 자동 구문 검사가 있습니까? 맹목적으로 오류 없이 코드를 작성하는 것은 매우 드문 성공입니다)
IMHO, 보여지는 대부분은 엉덩이를 통해 편도선을 자르는 것을 연상시킵니다) 예, 카피라이터에게는 유용할 수 있지만 프로그래머에게는 텍스트 입력 속도가 중요한 요소가 아닙니다. MQL 코드 작업 프로세스, 컴파일, 오류 탐색 등을 보는 것이 더 흥미로울 것입니다.
글쎄, 개인적으로 나는 "일반 편집자"에 짜증이 난다. 손가락은 이미 vim 조합을 자동으로 누른다. 나는 메타에디터에서 편안함을 느끼지 못한다.
그건 그렇고, 입력할 때 Wim에 자동 구문 검사가 있습니까? 맹목적으로 오류 없이 코드를 작성하는 것은 매우 드문 성공입니다)
당연히 메타에디터의 표준보다 훨씬 낫습니다. clangd(lsp 서버)가 이를 담당합니다. vim coc(lsp 클라이언트)에서는 복잡한 매크로나 템플릿이 이를 혼동하지 않습니다. 그리고 배열을 전달할 때 앰퍼샌드가 방출되고 올바른 역참조 덕분에 코드가 거의 십자형이 되어 clang의 프롬프트 기능에 긍정적인 영향을 미쳤습니다. 음, 정의로의 전환도 있습니다.
플러그인이 없습니다. (글꼴과 coc만) 모든 취향에 맞게 넣을 수 있습니다. 예를 들어 왼쪽에 있는 파일의 "내비게이터"입니다.
그러나 vim은 준비가 필요합니다. 첫 페이지에 명령어 도움말에 대한 링크를 만들었는데 익숙해지는데 시간이 걸립니다.