[기능 요청] 설명 편집

묘사

지정된 요청에 대한 의견을 보고 편집하며 작성하는 데 유용합니다.
이 특성을 검토하기 시작했습니다hub. 명령행은 열린 PRs와 이러한 PRs의 주석을 나열할 수 있도록 합니다.명령이 JSON으로 돌아갑니다.
나는 vim Squisite가 이 기능에 관심이 있는지 궁금하다. 관심이 있으면 그것을 운행하도록 노력해라.저는vim스크립트의 초보자이지만 계획이 있다면 필요한 일을 하고 싶습니다. 왜냐하면vim에서 직접 코드 심사를 하는 것이 매우 좋기 때문입니다.
이 기능의 주요 차이점은 API 요구 사항과 hub 명령을 의존 항목으로 사용하는 것입니다.일정 시간 내에 최신 논평을 얻기 위해 퀴즈 메커니즘이 더 필요하다고 가정하자.
니들 생각 좀 알려줘.

토론 #1

도주범은 이 문제에 대해 절대 흥미를 느끼지 않지만 대황은 흥미를 느낄 것이다.이미 존재하는 JSON API는 허브가 의존항 없이 할 수 있는 동일한 작업을 상당 부분 수행할 수 있다고 본다.

토론 #2

@tpop 죄송합니다. 문제가 이동되었는지 모르겠습니다.
vim rhubarb에 퀴즈api 업데이트 방법이 있습니까?

토론 #셋

이를 실현하는 방법은 특수한 URL 버퍼를 만드는 것이다. fugitive://... 버퍼와 유사할 수 있지만 rhurbab://를 가지고 있어 문제와 주석 목록, 그리고 각 주석의 추가 URL을 불러오는 데 사용된다.버퍼에서 호출 :edit 을 사용하면 다시 불러올 것입니다. 유사 nnoremap <buffer> r :edit<CR> 의 맵을 선택할 수 있습니다.
나는 투표가 좋은 생각인지 아닌지 확실하지 않다.그러나 이것이 우주에서 가장 좋은 생각이라고 해도 기본 지식이 도착하기 전에 나는 그것에 대해 진일보한 토론을 하지 않을 것이다.

토론 #4

@tpope
이 기능 요청에서 나는 요청 기간의 평론을 끌어당기는 것이지 문제의 평론을 끌어당기는 것이 아니다.
Github API에서는 이 요청의 모든 주석을 사용하여 요청 번호를 지정해야 합니다.JSON 객체에는 파일 이름 세부 사항과 큰 블록 세부 사항이 있습니다.
만약 이 기능이 Vim의 코드 심사를 지원하기 위해서라면, 나는 처음에 이 과정의 상호작용성을 상상했다. 새로운 PR 주석을 만들 때 Vim에 표시해야 한다.비록 그렇긴 하지만, 나는 비엠 스크립트 작성에 익숙하지 않다. 나는 당신의 '최선의 방식' 에 따라 이 점을 실현할 것이다.
URL 버퍼에 대한 설명은 끌어오기 요청을 지켜보는 경우에도 유효합니까?
"remotes"를 발견하고 적절한 remote를 사용하여GitHub API를 호출하여 비행 중의 정확한 인출 요청을 표시해야 합니다.

토론 #5

나는 간단한 평론을 생각했다. 문제에 대한 평론과 같지만 진정으로 다른 평론을 고려하지 않았다.이것은 듣기에 더욱 유용하지만, 나에게 있어서, 그것은 어떻게 일을 해야 하는지도 그다지 뚜렷하지 않다.그것은 어떻게 일해야 합니까?

토론 #6

나는 최초의 두뇌 폭풍을 버릴 것이다. 분명히 공백을 메울 것이다.
예를 들어 GitComments Toggle이라고 하는 고급vim 명령을 등록했습니다.
트리거하면 출력 git remote show origin 을 분석하고 (다른 원격 장치는 잠시 무시) 소유자/repo 조합을 가져와 API에 사용할 수 있습니다.
API 호출을 통해 실행 중을 나열하는 잡아당기기 요청을 호출한 다음 의견을 로드할 PR을 "선택"하는 형식의 사용자 입력을 가져올 수 있습니다.
API 호출은 이 PR에 대한 모든 주석을 가져오는 데 사용됩니다. 주석 객체에는 몇 가지 주요 필드가 있습니다(내 프로젝트의 예제 PR 주석).

"diff_hunk": "@@ -47,25 +45,19 @@ func Test_Matcher_Integration(t *testing.T) {\n \tctx, cancel := context.WithTimeout(ctx, 2*time.Minute)\n \tdefer cancel()\n \tup.Update(ctx)\n-\n \tpath := filepath.Join(\"testdata\", \"indexreport-buster-jackson-databind.json\")\n \tf, err := os.Open(path)\n \tif err != nil {\n \t\tt.Fatalf(\"%v\", err)\n \t}\n \n-\tvar sr claircore.IndexReport\n-\terr = json.NewDecoder(f).Decode(&sr)\n+\tvar ir claircore.IndexReport",
"path": "debian/matcher_integration_test.go",
"position": 42,
"original_position": 42,
"body": "renamed to ir",
"created_at": "2019-12-28T02:35:24Z",
"updated_at": "2019-12-28T02:35:25Z",

이 경로 정보와 줄 번호가 있으면 파일의 버퍼가 열려 있는지 확인하고 슬롯에 문자를 만들거나, 주석이 줄에 있음을 표시하기 위해 들보를 건너는 것처럼 표시기를 만들 수 있습니다.그리고 내 머릿속에 부동 창에 주석을 표시할 수 있지만 이것은vim버전/세부 사항을 실현하는 것입니다.
이렇게 하면 우리는 평론을 표시할 수 있다.논평을 발표하려면 커서를 특정 줄 번호의 버퍼에 놓고 논평의 본문이 있는 버퍼를 열고 POST api 호출을 해야 합니다. 호출된 세부 사항은 위에서 발표한 응답과 유사합니다.

토론 #7

3단계는 우리가 특정 PR의 지점에 있다는 것을 의미한다. 1단계는 열려 있는 모든 PR 목록에서 PR을 선택하도록 한다.정확한 홍보가 있다. 만약 우리가 다른 홍보를 선택한다면, 우리는 무효의 결과를 얻을 것이다.제발...잘 생각해봐.
설령 고치기 쉬운 소홀함을 겪었다 하더라도 나는 너의 업무 절차를 이해하지 못하겠다.만약 당신이 홍보를 심사하고 있다면, 당신은 무작위 파일을 보는 것이 아니라, 차이를 보는 것이다. 아마도 추가 배경을 얻기 위해 파일에 잠입할 것이다.만약 당신이 심사된 PR을 해결하고 있다면, 아마도 평론에서 시작해서 그들이 인용한 문서로 넘어가려고 할 것입니다.만약 당신이 이미 연 파일에 로고와 부동 창을 한 무더기 뿌린다면, 이 두 가지 방법은 특별한 도움이 되지 않을 것이다.

토론 #8

공관이 일치하지 않는 문제를 잘 잡았다.나는 잘못된 뜻을 없애기 위해 더 좋은 절차를 생각해 낼 수 있다.
그러나 업무 절차에 있어서는...
나의 관점은 정반대이다.이것이 바로 GitHub UI에서 코드 검사를 수행하는 방식입니다. 범위는 특정한 블록 집합입니다. 전체 파일 보기를 얻기 위해 더 많은 발굴을 해야 합니다.만약 어떤 이유로 차이 이외의 파일을 훑어보고 싶다면...너는 가서 윌을 열어라.
Vim에서 코드 검토를 하는 이유 중 하나는 Vim 네이티브 체험이 있어야 하기 때문이다.관련되지 않은 파일을 열 수 있도록 지원하고 필요하기 전에 댓글을 보지 마십시오.Vim Survival의 diff UI 와 같이 Vim 장면을 많이 개편했기 때문에 Vim 장면을 사용하지 않으려고 합니다.
예를 들어, 나는 홍보가 일부 인터페이스를 바꾸었다.이 인터페이스의 변경은 PR에서 차이가 없는 파일에 영향을 줄 수 있습니다. 만약 코드 심사가 Vim에서만 진행된다면, 나는git diff를 사용하여 변경된 내용을 찾을 수 있습니다. 이 블록으로 이동해서 멋진 남자의 주석을 볼 수 있고, 현재는 PR 이외의 다른 파일로 이동해서 내가 보고 있는 변경이 정확하다는 것을 확인할 수 있습니다.

토론 #9

I would argue the opposite. That is how you perform a code review in the GitHub UI, you are scoped to particular set of chunks, and have to dig further to get the full file view... and if you for some reason want to browse a file outside of the diffs... well you go open VIM.

만약 당신이 완전한 파일 보기를 얻기 위해 더 많은 발굴을 한다면, 논평을 보지 못할 것이다.전체 파일 보기에 주석을 표시하는 것을 권장하는 것으로 알고 있습니다.따라서 GitHub UI에서 코드 검토를 수행하는 방법과는 거리가 멀어집니다.거의 겹치지 않아요.

I'd like to avoid a scenario with Vim is adapted heavily for the purpose (like the diff UI in vim-fugitive).

너는 투표와 부동 창구를 제의하는데, 이것이 사람들로 하여금 '적응도가 매우 높다' 고 비명을 지르게 할 것이라고 생각하지 않니?

If code review was happening solely in Vim, I could still use git diff to find what changed,

이게 무슨 뜻이죠?콘솔에서 호출git diff common-ancestor?이것은 첫걸음이자 가장 중요한 걸음이니, 너는 그것을 이미 해결된 문제로 처리해라.

go to that block,

어떻게 써요?나는 네 뜻이 :Git diff common-ancestor에서 뛰는 것이라고 추측하지만, 이것은 현재 지지를 받지 못한다.

see any comments for that hunk,

왜 지금 이러지?차이점을 왜 안 봐요?너는 그것의 가식에 대해 아무것도 모르고 온전한 문서에 평론을 표시하는 데 너무 열중했다.

토론 #10

당신들의 몇 가지 관점을 고려하여 디자인을 다시 생각해 보겠습니다.내가 생각을 너무 빨리 밀었나봐.나는 다시 한 번 보았는데, 만약 무슨 결과가 있다면, 나는 돌아올 것이다.