שכתוב הגדרות עבור neovim 0.5

ב2017 עברתי מ VIM לפרויקט חדש (יחסית) בשם neovim אשר שם לו למטרה לבצע refactoring ב VIM ולהסיר קוד ישן, לתקן קוד קיים בעייתי, בו בעת להמשיך את VIM והתפתחות שלו.

למיטב זכרוני, הפרויקט הוקם לאחר שהמתכנת הראשי של neovim פשוט סורב ל Patch בתוך VIM שתיקן בעיה קריטית. הצורה לסירוב כפי שהבנתי לא היתה ממש "יפה" וזה הוביל לפרויקט חדש הלוקח את קוד המקור של VIM וממשיך משם.

לאחרונה שוחררה גרסה 0.5 ל neovim אשר מביאה המון חידושים ותוספות.
בין היתר גם:

• חלון Popup.
• תמיכה מלאה ב Lua כשפה first class (ביחד עם VimL).
• תמיכה ב LSP.
• תמיכה ב tree-sitter.
• תוספות UI (למשל ל Popup message).

ועוד.

השינויים שלי

בחודשים האחרונים עברתי לעבוד עם coc.nvim אשר מנסה לספק השלמה אוטומטית, תמיכה ב LSP, תמיכה ב Linting ואפילו Fuzzy Finder, וכל זה בשימוש של תוספים המבוססים על Visual Studio Code וכתוב ב node.js.

הבעיות שלי עם coc.nvim שיש לי איתו צרות של CPU גבוה מאוד ובנוסף זיכרון שמתמלא כאשר אני עובד עם קבצים של אלפי שורות קוד שכולם פתוחים ב buffer כי אני עובר בין אחד לשני הרבה.
בנוסף לזה, הייתי מוצא מספר process של LSP שונים לאותה שפה (בפורטים שונים) עם הודעות שגיאה ב messages כשהוא מנסה להעלות אותם ונכשל (עד שמוצא פורט פנוי).

לאחר השחרור של 0.5 הבנתי כי אני צריך לשנות גישה והתחלתי לחשוב מחדש מה התוספות שאני רוצה להשתמש בהם וכיצד לכוון את nvim שיעבוד נכון עבורי והצרכים שלי.

nvim הנוכחי שלי

אז נכון לכתיבת שורות אלו, הצלחתי להתקבע על סט כלים חדש, אחרי ניסיונות של מספר רב של תוספים וכלים, בהם:

• שימוש ב tree-sitter
• שימוש בכלים המשתמשים ב nvim-lsp
• שימוש ב ddc.vim אם dino קיים במערכת וdeoplete במידה ולא.
• שימוש ב telescope.nvim
• שימוש רב ב text objects הנוספים על הקיימים.

אלו הטכנולוגיות העיקריות שאני משתמש בהם.

השינוי מאפשר לי להתאים כלים עבור neovim עם היכולות שלו ולמעשה אני מסיר תוספים לא נדרשים שהייתי צריך אותם ב vim 7 כי לvim עצמו לא היתה תמיכה בדברים.

עבור צביעת התחביר בחרתי לעבור לשימוש ב tree-sitter, תוסף שאמור לספק תמיכה מדוייקת יותר מאשר הצביעה ה"רגילה" המשתמשת בregex, אשר נמצא בשימוש אף הוא אצלי, במידת הצורך.

השימוש שלי ב nvim-lsp מאפשרת לי לקבל הגדרות ברירת מחדל (שאני יכול לעקוף) למנועים מוסימים ובכך אני לא זקוק ל ALE לדעת על בעיות מצד אחד, ומצד שני אין לי צורך ב coc להשלמה.
זה מאפשר לי גם לספק כלי חדש לראות symbols שונים עם LSP בנוסף ל ctags למשל, ולכן אני משתמש ב vista.vim במקום Tagbar.

להצגת קבצים עברתי ל nvim-tree הכתוב ב lua. יש לתוסף כמה יכולות ממש נחמדות בברירת המחדל, וזה במקום NerdTree עם תוספות.
כחלק מהיכולות של התוסף, זו יכולת מעקוב אחרי יצירת קבצים בזמן עבודה מתוך nvim ולרפרש אותם אוטומטית. ובנוסף הוא יודע להבין סטטוס של git ללא תוספות, ולדעת מתי לא לסמן יותר אם מתוך nvim עשיתי commit.

עבור מערכת ה Fuzzy Finding החלטתי לעבוד עם Telescope. התוסף מכוון אצלי לעבוד עם ripgrep בברירת מחדל, אבל יש לי גם תמיכה ל fzf במידת הצורך.

יכולות telescope

השלמה אוטומטית שלי היא כאמור באמצעות ddc.vim אשר משתמש בdino, ולמעט באג בהשלמה של zsh (אשר ביטלתי את התוסף), החתימה שלו מאוד קטנה בזיכרון וב cpu שלי, ומצד שני קל מאוד לקינפוג, אבל רק אחרי שמבינים את הגישה שלו (אשר לא אינטואיטיבית).

השלמה אוטומטית, פלוס הדפסת הcommit האחרון (שלא קיים) בשורה שאני עומד עליה

בנוסף, ל snippets שהייתי עובד איתם בצורה רגילה, החלטתי להוסיף לשם שינוי גם snippets לbolier plate שאני עושה המון בשפות שונות ואין לי snippets עבורם. החיבור עם ddc עובד ממש יפה לרוב.
מערכת ה Snippets שבחרתי היא UltiSnips.

יש תמיכה ממש טובה ב git גם הצגה של מה נוסף/שונה/נחמק וכו'. ואפילו blame על השורה שאני עומד בה.

הצגת שגיאות מבסיס LSP

סיכום

נכון לכתיבת פוסט זה רוב הדברים שאני זקוק להם קיימים, אך לא מושלם.
נשאר לי לשנות readme לגמרי, ולהעביר את זה ליציבות מלאה.

חלק מהעץ הראשיחלק מהעץ הראשיחלק מהעץ הראשיבמידה ואתם מעוניינים להשתמש בהגדרות שלי, תוכלו למצוא אותם כרגע כאן ובסוף זה יהיה כחלק מהעץ הראשי (במידה והקישור הקודם כבר אינו עובד).

לשחק עם כובש ההשלמות

אני עובד עם vim כבר המון שנים, ובשלוש שנים האחרונות עם neovim.
עד לאחרונה עבדתי עם מנהל השלמות בשם deoplete, אשר עשה עבודה מדהימה, אבל גרם לי להתקין המון תלויות.

החלטתי בהמלצת מאיר לנסות את coc – שפירושו הוא Conquer of Completion .
התוסף הוא בפני עצמו מאוד מעניין. הוא משתמש מאחורי הקלעים בחלק מכובד של תוספים המגיעים מ Visual Studio Code של מיקרוסופט, בנוסף לשימוש ב LanguageServer.
הוא מחזיק בתמיכה של "חלונות צפים" שנכנס לשימוש ב neovim רק לאחרונה:

רואים את התיעוד של הפונקציה Errorf? זה חלון צף ב neovim, לפחות סגנון אחד שלו.עוד השלמה שהוא מכניס:

כלומר בכל נושא של השלמה התוסף מספק יכולת לקבל תיעוד, לדעת לפי תוכן מה להשלים ואיך, ולעקוב אחרי.

וזהו, זה כל תפקיד הכלי, ובזכותו קיבלתי חצי מיכולות של IDE בסיסי.
בנוסף, אני משתמש ב ALE אשר יודע לתת לי חיווי של שגיאות באמצעות תמיכה בlinters, ואף לנסות לתקן דברים אם יש לו כלים לזה.

עד כאן הכל טוב

אבל, שמתי לב למספר בעיות חדשות שצצו לי במערכת. למשל בגלל שcoc משתמש ב node, הוא שוקל יחסית הרבה בזמן ריצה על ה cpu ולא רק על הזיכרון.

יש לו המון אופציות להגדרות, אבל חסרים לי כמה יכולות בסיסיות שהיו לי ב deoplete.
הפשוטה שבהם היא היכולת להשלים רק מה שחסר בטקסט.
למשל יש פונקציה בשם Write, ואני רוצה לבחור ב Fwrite במקום. עם Deoplete הוא ידע להחליף את מה שצריך.
אף ב coc אקבל את FwriteWrite במקום בזמן השלמה.

שורה תחתונה

אחרי חודש וחצי של משחקים, אני חייב לציין שאני מאוד אוהב את coc, וחושב לייצב אותו יותר ב"הפצה" שלי של vim.

הקוד שאתם רואים בתמונה הוא חלק מפרוייקט שפתחתי בגיטהאב שכולכם יכולים להנות ממנו – תמיכה בספקי SMS שונים על ידי יצירת SDK עם בסיס קוד אחיד (go/golang interface).
נכון לכתיבת שורות אלו, יש תמיכה במספר ספקיות ישראליות וזה יתרחב.

 

הגדרות שגויות לnvim

כמו כל סיפור טוב בעולם הטכני, גם הסיפור הזה מתחיל עם באג.

מזה זמן רב, שאני כמעט ולא נוגע בGo, והפוקוס העיקרי שלי הוא על רובי. שם הכל עובד אצלי כמו שצריך (למעט solargraph).

איזה סופ"ש אחד החלטתי לפתוח קוד Go שלי ולהמשיך ולעבוד עליו.
פתאום קיבלתי המון שגיאות לא קשורות לקוד שלי, אלא לvim-go.
אמנם עברו 3 חודשים מאז שהתחלתי לכתוב את הקוד בזמני הפרטי, אבל מה השתנה?!
הלכתי לפי הודעות השגיאה (בvim/nvim זה ‎:messages), וגיליתי שפונקציה לא קיימת עבור nvim. הלכתי לספריה ש vim-plug מתקין לי תוספים עבור nvim, ועם rg‏ (ripgrep) חיפשתי את הפונקציה ומצאתי אותה. מסתבר שקובץ חדש בשם config.vim לא נטען. אמממ, אבל הוא קיים בספריה.

פתחתי באג בנושא, כמו כל איש קוד פתוח טוב 🙂 הוצע לי לבדוק אם הקובץ קיים, דבר שהוא כן.
ואז החלטתי להתחיל בבדיקה של nvim וונילי, בעקבות תגובה של faith (הכותב העיקרי של התוסף).

התשובה היא שבהגדרות נקיות, הכל עובד גם עבורי. אז זה לא התוסף עצמו.
הלכתי לקובץ init.vim של neovim, שהוא ההתחלה ששם הוא טוען את כל הסקריפטים (הvimrc של neovim), ומקריאה ראשונית מצאתי משהו שיכול לשמש כבעיה:

set runtimepath+=~/.vim,~/.vim/after
set packpath+=~/.vim
source ~/.vimrc

הקוד טוען למעשה ועובד בכלל עם ספריית ה vim שלי, בעוד שהיא לא השתנתה כשנה, למעט ההגדרות שלי, הכל נלקח משם. עכשיו הבעיה יותר ברורה.

החלטתי לעשות מהלך שעד עכשיו נמנעתי ממנו. לשים את ה"הפצת" vim שלי תחת nvim, ולעשות שינוי ל init.vim שלי. הוא כבר לא מתעניין ב vim בכלל. הכל נעשה דרכו, כולל הצבעה נכונה לספריות שונות.

לאחר ביצוע פעולה כזו, הכל עבד חלק 🙂

אני עד עכשיו לא מבין איך זה עבד עד עכשיו, כי חלק מהתוספים נלקחו נכון, אבל לא כולם. ועכשיו אין זכר ל vim כאשר אני מריץ neovim. שניהם מסוגלים לחיות זה לצד זה בהפצה שלי עכשיו.

במידה וגם אתם חווים בעיות בסגנון, אני מקווה כי הפוסט יעזור לכם לפתור אותם.

על שימוש ב VIM ו OCD

ב2003 החלטתי ללמוד vim כמו שצריך, אז עשיתי את כל מה שבן אדם שפוי עושה – יוצר מדריך בעברית המלמד עבודה בסיסית עם vim.

כאשר התחלתי לגעת ביוניקס, מצאתי את עצמי כמו כולם, עובד עם vi, או nvi, ו…נמצא בחדר בריחה. כאשר מצאתי את הקוד הנכון לצאת, חשבתי לעצמי "מי לעזאזל מתכנן מערכת כל כך מסובכת?! מה רע בעורך טקסט שפשוט כותבים בו טקסט?!".

כמה טעיתי בחשיבה הזו. מה שאני לא הבנתי לגבי vi או vim, וכיום neovim שאיתו אני עובד בעיקר, זה עד כמה אני לא מבין מה המטרה של עורכי טקסט.

כבר הסברתי את זה הרבה פעמים בעבר, אבל אחפור גם כאן על זה – אנחנו כמתכנתים (למשל), קוראים המון קוד, מחפשים המון מידע על המתרחש, ויחסית לכל הפעולות שאנו עושים, דווקא כתיבת טקסט היא פחות העיקר. אבל עריכת טקסט והתמודדות איתו, ובכן היא משהו שאנו עושים הרבה.

אז יצאו להם שני גישות בעולם, גישה של emacs וגישה של vi.
על רגל אחת:
הגישה של emacs אומרת שהפוקוס הוא קודם כל על כתיבת טקסט, וכל דבר אחר הוא משני.
הגישה של vi אומרת שהפוקוס הוא על הcontext של הטקסט וכתיבת טקסט היא דבר משני.

כאשר אנחנו רוצים לגשת למילה השנייה במשפט השלישי בשורה שאנו נמצאים, הגישה של emacs אומרת שאנחנו חייבים ללכת עם החצים עכשיו עד לשם ואז להחליף. אם יש תמיכה בעכבר נעשה את זה בעזרתו.

אבל הגישה של vi היא שונה כאן. אם כל משפט נגמר בנקודה, אפשר להתחיל בגישה הבאה:
בואו נלחץ על ‏ 2f.‎ (כלומר הספרה שתיים האות f ואז נקודה) ונגלה כי אנחנו מגיעים לנקודה השלישית הנמצאת בשורה שלנו. עכשיו ניתן להקיש 2w ו… הגענו למיקום הנכון. מכאן נלחץ על cw ונשנה את המילה הרצויה.

עכשיו מתחיל ה OCD שלי לפעול. אתם מבינים? ב vim תמיד צריך לחפש את הדרך הקצרה ביותר לעשות דברים, ובעיני הדרך הזו מעט ארוכה. אמנם קצרה יותר מemacs זה בטוח, אבל ארוכה.

כאשר אני רואה אנשים עובדים קשה מידי להשיג דברים שאפשר להשיג בפחות מאמץ, אני מרגיש שזה ממש כואב לי לראות את זה

תנו לי לנסות את זה שוב. אולי אעשה את זה כך: ‎ 2‎)‎ ואז על w ואקנח ב cw.  טוב זה פחות הקלדות.
ועכשיו נשאלת השאלה – האם אני עדיין יכול לקצר את התהליך. אמנם במקום 7 תווים ירדתי ל5, עדיין זה הרבה בעיני.

אז מה השלב הבא? ובכן חשבתי להשתמש ב search and replace, אבל ב Neovim זה לא עבד כמצופה. אז עכשיו  האם אני ארים ידיים?
ובכן לא! אמשיך לחפש דרכים טובות לעשות את זה, אבל בשוטף, ולא בעבודה הנוכחית, כי כרגע זה מספיק טוב עד למציאת הדרך הקצרה יותר הבאה שכמעט תמיד מסתתרת בפינה חשוכה ומחכה לפנס שלי להאיר לה את הדרך.

אני יודע מה הרבה חושבים, שזה מאוד קטנוני למצוא דרכים קלות יותר, אבל יש לזה מספר משמעויות גדולות יותר מזה.

כל פעולה אשר אני מבצע ב vim, יכולה להישמר כמקרו, וגם כפונקציה. במידה ואני יוצר מאקרו או פונקציה vim ידע לחזור על הפעולות מספר פעמים.
יותר מזה, גם לזיכרון התנועתי שלנו כבני אדם תהיה יכולת להתרכז בפחות פעולות לביצוע דברים, כך שאפילו אין לי צורך לזכור בראש את הפעולות, אלא רק האצבעות שלי במצב מסוים יבצעו דברים.

היכולת במינימום פעולות לבצע המון פעולות מאפשרת לי לשרשר המון פעולות במקביל, למשל בגישה שלינוקס/יוניקס עובדים, ובכך ניתן להיות מאוד אפקטיביים בעבודה בלי להשקיע הרבה אנרגיה בעריכה עצמה.

זו הסיבה שה OCD שלי נכנס לפעולה, אני כל הזמן מחפש את הדרך הקלה והפשוטה יותר לעשות דברים, וכמה שפחות פעולות בשביל להשיג את אותה המטרה כאשר מדובר בvim, או לינוקס.

vim, neovim ו javascript

אני נחשב למתכנת מסוג full stack מסתבר, ככה לפחות הגדירו אותי אחרים.
אני מוצא את עצמי נמצא רוב הזמן כאשר אני מתכנת לפחות, משתמש בvim, כל עוד לפחות, לא מדובר בשפת Javascript, על שלל ספריותיה, כדוגמת React או Vue אשר איתן אני עובד לרוב.

הבעיה שלי עם Javascript וכל הספריות שלו, שהתחביר נתמך, אבל לקבל linter ולקבל יכולות כמו זיהוי טוב של מבנה, ואפילו Refactoring לא תמיד עובד נכון, גם כאשר אני עובד עם כלים כדוגמת eslint.

כאשר אני מתכנת בשפות כדוגמת Golang, רובי או פיתון, יש לי כלים ממש איכותיים לנושא עבור vim, גם כאשר אני נוגע למשל בתסריטי teraform, אני עדיין מקבל תמיכה יחסית טובה, אבל כאשר מדובר ב JS, זו כבר בעיה. אני חושב שהסיבות הן שיש הרבה תקנים שהם עדיין במצב של offer ו draft וככה es6 וכיוב', יוצרים אתגרים מעניינים.

בשנה האחרונה, התחלתי מאפס ליצור vimrc משלי, וביחד עם dotfiles שלי, מנסה לענות טוב יותר על בעיות שונות.
אך עדיין איכשהו JS או Ecmascript אם להיות יותר קורקטיים, מתחמקת ממני.

לאחרונה אפילו עברתי ל neovim, אשר דווקא עושה עבודה מדהימה, עם כמה בעיות ממש קטנות, הוא מספק לי כלי מעט טוב יותר מvim עצמו, הוא אפילו מכיל כמה כלים שלפעמים נדמה ש tmux קצת מיותר (למרות שאני עדיין לא משתמש בו), למשל היכולת לקבל מסוף מובנה עם ‎:terminal אשר עדיין מקבל תוכנות של vim בתוכו.

אני כבר הרבה זמן מנסה לגרום לvim לעבוד עם Javascript, והתחלתי לקרוא מאמרים שונים, כדוגמת המאמר הבא, אשר מסביר קצת יותר לעומק איך להגדיר את JS, והנה אני כבר בשלבים להתחיל לזנוח את Atom, ולגרום ל neovim להיות עורך הטקסט כמעט היחידי שלי.

 

אני עדיין בשלבים של הגדרות ה vim, אבל כבר פחות ופחות אני מוצא את עצמי עם צורך לשנות אותם. אשמח לקבל פידבק מאחרים לגבי העובדה בשביל שאוכל לשפר ולהשתפר, וכמובן שכולם מוזמנים לעבוד עם ההגדרות שלי.

שבוע עם Atom

כשעורך הטקסט של github הנקרא Atom רק יצא, והיה בגרסאות די נמוכות של פיתוח, החלטתי לקחת אותו לסיבוב, וראיתי שהוא צעיר מידי, אבל עם המון פוטנציאל.

Atom מציע כלום כמעט, למעט אוסף של תוספים, כאשר ישנם תוספים שמגיעים ברירת מחדל, וכאלו שצריך להתקין.

העורך משתמש בחלקים של כרומיום, ב node.js, ומשתמש גם ב coffeescript עבור התצוגה של דברים (הנעשים בcss).

הבעיה העיקרית שהיתה לי עם עורך הטקסט, היא שעורך הטקסט מבזבז כרוני של משאבי מחשב, ושכל הזמן היו עדכונים מאסיביים. אז הפסקתי להשתמש בו די מהר.

גרסה 1.0 יצאה, והחלטתי לקחת אותה לסיבוב ולראות מה השתנה בגרסה הזו מכל שאר הגרסאות.
ובכן בראש ובראשונה היא לוקחת ממני פחות משאבים.
דבר שני, יש טכנולוגיות שהיא טובה בהם יותר וטכנולוגיות שהיא טובה בהם פחות.
למשל עם go, יש לה תוספים מדהימים, אבל עם PHP, ובכן, אני לא רואה שהתוספים מאפשרים לי לעבוד כמו שצריך.

העניין הוא ש 1.0 קרוב להיות משהו טוב, אבל ישנם מספר דברים שעדיין לא אפויים מספיק:

• היכולת להגדיר מה הוא API תקין מבחינת תוספות ולא לאפשר תוספות שאינן כאלו
• היכולת להגדיר תוספים על בסיס מה שאני עובד כרגע
• קבלת תוספים איכותיים מבית github לשפות שונות, כדוגמת PHP, רובי וכיוב', מעבר למה שמגיע כברירת מחדל.

בשורה התחתונה, במידה ויש תוספים שאתם צריכים ועובדים כמו שצריך, הוא יכול להיות מצויין עבורכם, אבל במידה וזה לא המצב, עדיין צריך לחכות, אבל אני בהחלט ממליץ לכם לנסות.