[정보] neovim 플러그인을 직접 작성해보자 (튜토리얼)

[익명(37.120)]

마크다운으로 작성된 문서인데 디시가 똥구데기라 HTML로 변환하면 코드블럭이 전부 깨져서 불가피하게 이미지로 올림;;
가독성이 많이 떨어져서 읽을 사람이 얼마나 있을진 모르겠지만 궁금한건 질문하면 알려드림

[전자책가방(precede5148)]

setup을 entrypoint로 두는건 바람직하지 않음. 진짜 필요한 경우가 아닌 이상, config 수정 api로만 구현하고, 플러그인 실행은 plugin 폴더를 통해 직접 구현하는게 바람직함
내부적으로 lazy-loading이 일어나고 있다면 entrypoint를 따로 api로 제공할 이유가 없지
lazy.nvim 말고 rocks.nvim도 있고, 다 만들었으면 luarocks에 배포하자. 설치와 의존성 관리가 훨씬 쉬워짐 (lazy.nvim도 최근에 luarocks 지원을 시작했음)
플러그인 개발시 참고:
https://github.com/nvim-neorocks/nvim-best-practices

[익명(37.120)]

딱히 권위에 기대고 싶진 않은데 플러그인 개발로만 깃허브 스타를 5만개 받은 folke도 setup을 entrypoint로 두고 개발하고 있고 가장 중요한건 lazy.nvim에서 모듈에 있는 init.lua의 setup 함수를 자동으로 찾아서 호출하는 opts = {} 기능을 만들어 두었기에 아무런 문제가 없음. 분명히 글을 쓸때 kickstart를 기준으로 한다고 했고 kickstart에서 lazy.nvim을 쓰고 있는건 알테고 lazy.nvim으로 개발해봤으면 opts = {}를 모를 수가 없을텐데? 플러그인쪽이 팬덤 장사라 좀만 흥해도 스타 수천개 받는건 일도 아닌 곳에서 200개짜리 스타 받은 문서가지고 오는건 좀..

[전자책가방(precede5148)]

저 글의 내용 대부분은 lazy.nvim을 타겟팅하고 있는 플러그인들에도 해당됨. 특히 UserCommand 같은건 되게 괜찮은 조언이잖아 플러그인이 자체적으로 lazy-loading을 구현하는게 가장 바람직하고, 그게 안돼서 나온게 lazy.nvim임. lazy.nvim 쓰는 입장에선 setup이 있든 없든 사용자 입장에선 별 차이가 없고, 오히려 플러그인단에서 lazy-loading이 이뤄지니까 사용자가 ft, cmd, keymap 등의 lazy-loading을 직접 설정할 필요가 없어서 config가 더 간결해지지

[전자책가방(precede5148)]

kickstart.nvim을 베이스로 한다니 lazy.nvim을 예시로 쓰는건 알겠는데, lazy.nvim이 알아서 처리해준다고 lazy-loading을 아예 신경끄고 setup()을 entrypoint로 하겠다는건 바람직하지 않단 얘기였음

[익명(37.120)]

1. 지금 너가 말하는 내용이 이 글과 관련이 있다고 생각함? 아니면 최소한 너가 말하는게 이 글을 읽고 플러그인을 작성해볼까 생각하는 사람들에게 도움이 단 1이라도 된다고 생각함? 2. 플러그인 개발해본 적은 있음? 아니면 플러그인 깃허브를 둘러본 적이라도? 응애들을 위한 글을 썼는데 너처럼 '엄근진'하면 neovim 커뮤니티에 대한 평가만 안 좋아질뿐이지..

[전자책가방(precede5148)]

좋은 글에 참고하면 내용 좀 덧붙였는데 왜그렇게 싫어하냐. 1) setup을 entrypoint로 쓰는건 바람직하지 않다. 옵션 설정 목적으로만 쓰는게 좋음. 2) luarocks를 통한 플러그인 배포도 가능하다. 의존성 관리에 편리함 이것만 말하고 싶었던건데 말을 좀 오해할 수 있게 썼나보네

[익명(37.120)]

일단 너의 말에서 플러그인 개발을 한번도 안 해본 티가 남. 앵무새처럼 다른 사람이 한 말을 그냥 읊는 느낌만 든다고 해야할까. 너처럼 노빠꾸로 '너가 쓴 내용은 틀렸고 내가 맞아' 식으로 글을 쓰는데 어느 누가 좋아하겠음? 여러번 언급한 folke가 그렇게 했어도 기분나쁠 정도라 생각해 너의 말투는.

[익명(211.36)]

흠그정돈가

[익명(121.140)]

vim추

[black7375(221.168)]

멋지구만