: Gwrite에 쓰기 위해 파일을 열 수 없습니다.

묘사

:Gwrite에서 dp로 들어간 버퍼에서 :Gstatus 연산을 했을 때 이 결과를 얻었습니다.

Error detected while processing function <SNR>28_Write:
line   77:
"~/Source/projectf/00000gn/T/vGfJnpY/114" E212: Can't open file for writing
fugitive: fatal: Could not switch to '/Users/name/Source/projectf/00000gn/T/vGfJnpY/': No such file or directory

내 파일은 다음과 같습니다.https://github.com/aaronjensen/vimfiles
내가 뭘 잘못했나?

토론 #1

unset TMPDIRvim에 들어가기 전에 고정시킨다.그것이 도대체 어디에서 왔는지 알고 싶다.

토론 #2

약간의 발굴을 거친 후 s:buffer_path의 경로를 통해 리포 디렉터리의 길이를 버퍼 경로에서 벗겨내는 것 같다.나는 버퍼링 구역에 도주범 접두사가 있어야 한다고 추측하지만, 어떤 이유로 그것이 없습니까?여전히 이 코드에 익숙해...

토론 #셋

무엇을 설정했습니까?만약 그것이 공간이나 다른 물건이 있다면, 그것은 외피의 탈출 문제일 수도 있다.$TMPDIR

토론 #4

공간이 없다.보아하니 /var/folders/76/4hcxz2cx1297y49qh3z5n_d00000gn/T/ 의 코드가 내 환매 디렉터리에 있다고 가정하면, 이것은 정확하지 않다.나는 코드를 보지 못했는데, 코드를 제외하고는 아무것도 할 수 없었다.일부 상황에서 작동하는 유일한 이유는 임시 폴더의 길이가 보통 Repo dir보다 짧기 때문에 s:buffer_path 최종적으로 빈 문자열을 되돌려줍니다.s:buffer_path 이것은 OSX의 표준 임시 디렉터리입니다. 가능할 것입니다.
네가 옳다.

토론 #5

에는 추가적인 보호가 있어야 하지만, 이것은 내가 OS X에서 일하는 데 매우 좋아서 다른 일들이 진행 중이다.버퍼에 어떤 경로가 있습니까?네, 그럼 진단이 정확합니다.배제의 첫 번째 가능성은
추가 플러그 인.
2012년 12월 8일 토요일 오전 11:39, 앨런 젠슨[email protected]:

/private/var/folders/76/4hcxz2cx1297y49qh3z5n_d00000gn/T/vAWMncv/2

— Reply to this email directly or view it on GitHubhttps://github.com/tpope/vim-fugitive/issues/278#issuecomment-11160388.

s:buffer_path에서 모든 플러그인을 삭제했지만 vundle과 Survious는 여전히 Repros입니다.:echo expand('%')도 저의vimrc를 차단했습니다. vundle 불러오는 것 외에도 리프로스

토론 #6

입니다./여기서 어찌할 바를 모르겠습니다.분명히 나는 복구할 수 있다 /private/var/folders/76/4hcxz2cx1297y49qh3z5n_d00000gn/T/vAWMncv/2. 그러나 이것은 단지 하나의 증상일 뿐이다.만약

토론 #7

라면, 당신은 모든 것이 정상이라고 확신합니까?아니면 묵묵히 실패한 것일까?

토론 #8

그의 행동은 정상이다.제가 echom의

토론 #9

랑...

    let rev = self.spec()[strlen(self.repo().tree()) : -1]

토론 #10

비율s:buffer_path보다 길기 때문에 unset TMPDIR이 ""(으)로 끝납니다.
그것은 실제로 어떻게 일을 해야 합니까?그것은

토론 #11

경로여야 합니까?s:buffer_path 내가'행동이 정확하다'는 뜻을 알고 있음을 확보하기 위해 이렇게 할 것이다.
버퍼를 닫고 차이점이 있는 파일로 바꿉니다.Gstatus 버퍼로 돌아가서 rev를 클릭하면 파일이 표시됩니다.
내가 이 점을 언급한 것은 내가 이런 행위가 좀 놀랍다는 것을 발견했기 때문이다.나는 그것이 Gstatus로 돌아가 자동으로 리셋되기를 바란다.self.repo().tree() 나는 self.spec()를 보았고 네가 그것으로 fugitive:// 중의 단계적인 변화를 진행하고 있다는 결론을 얻었다.제 잘못입니다.나는 지금 이 문제를 재현할 수 있다.시험

토론 #12

분지.통합하기 전에 Windows에서 시험적으로 사용해야 합니다.
참고로 R 디프에서 한 행동은 기록이 없습니다. 이것은 기본적으로 당신의 기대에 부합되기 때문에 매우 성공적인 DWIM 시도입니다.

토론 #13

효과가 있는 것 같습니다. 감사합니다!사실 나는 도움말 텍스트에서 이 생각을 얻었는데, 그것은 여전히 사람을 곤혹스럽게 한다. 왜냐하면 그것은 다음과 같이 말하기 때문이다.

  dp    |:Git!| diff (p for patch; use :Gw to apply)

나는 dp가 무엇을 가리키는지 확실하지 않다. :Gdiff 다른 곳처럼 붙인다.buffer_path 수평 균열이 아닌 수직 균열로 어떻게 열어야 합니까?:Gwrite는 기호입니다.

토론 #14

헤어지지 않아서 나는 너의 문제를 이해하지 못한다.p 무슨 뜻인지 모르겠지만 Gstatus 창에서 수평으로 분할된 dp를 가리키는 것 같습니다.그 이후로 나는 이렇게 많은 것을 써 본 적이 없다. 네가 최초의 문제를 복구했기 때문에 나는 끝났다.감사합니다!