Vim ਅਤੇ Bram Moolenaar ਦੇ ਪ੍ਰਭਾਵ ਦੀ ਖੋਜ: ਮੋਡਲ ਐਡਿਟਿੰਗ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਵਰਕਫਲੋ ਅਤੇ ਉਹ ਕਮਿਊਨਿਟੀ ਆਦਤਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਡੈਵਲਪਰ ਉਤਪਾਦਕਤਾ ਨੂੰ ਦਹਾਕਿਆਂ ਤੱਕ ਆਕਾਰ ਦਿੱਤਾ।

Bram Moolenaar ਨੇ Vim ਬਣਾਇਆ ਸੀ ਤਾਂ ਜੋ vi ਦੇ ਕਲਾਸਿਕ ਸੰਪਾਦਕ ਤੋਂ ਇੱਕ ਸੁਧਾਰ ਹੋਵੇ, ਪਰ Vim ਦੀ ਦਹਾਕਿਆਂ ਤੱਕ ਟਿਕਾਊਤਾ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਕਾਰਨਾਂ ਮੁਤਾਬਕ਼ ਨਹੀਂ ਸੀ. Vim ਇੱਕ ਸਾਂਝਾ ਕੰਮ ਕਰਨ ਦਾ ਤਰੀਕਾ ਬਣ ਗਿਆ—ਪਾਠ ਲਿਖਣ ਅਤੇ ਸੋਧਣ ਦਾ ਇੱਕ ਅਭਿਗਮ ਜੋ ਟੀਮਾਂ, ਟਿਊਟੋਰਿਯਲਸ ਅਤੇ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਰਾਹੀਂ ਫੈਲਿਆ. Bram ਦੇ ਦੇਹਾਂਤ ਤੋਂ ਬਾਅਦ, ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ਰਧਾਂਸ਼ੂਰੇਆਂ ਨੇ ਇਹੀ ਗੱਲ ਉੱਪਰ ਜ਼ੋਰ ਦਿੱਤਾ: Vim ਸਿਰਫ਼ ਕੋਈ ਸੌਫਟਵੇਅਰ ਨਹੀਂ ਸੀ ਜੋ ਲੋਕ ਵਰਤਦੇ ਸਨ; ਇਹ ਕੁਝ ਸੀ ਜੋ ਲੋਕ ਸਿੱਖਦੇ ਅਤੇ ਆਪਣੇ ਰੋਜ਼ਾਨਾ ਹੁਨਰ ਵਿਚ ਲਿਆਉਂਦੇ ਸਨ.
ਜਦੋਂ ਡੈਵਲਪਰ "editor culture" ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਵੱਲ-ਵੱਖ ਪਸੰਦੀਦੀਆਂ ਨਾਲੋਂ ਵੱਧ ਬਿਆਨ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ. ਇਹ ਉਸ ਟੂਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਣ ਵਾਲੀਆਂ ਆਦਤਾਂ ਅਤੇ ਨਿਯਮਾਂ ਦਾ ਸੈੱਟ ਹੈ:
ਇਹ ਸਭਿਆਚਾਰ ਅਹੰਕਾਰਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਰਤਾਰੇ ਨੂੰ ਆਕਾਰ ਦਿੰਦਾ ਹੈ. ਦੋ ਲੋਕ ਇੱਕੋ ਫਾਈਲ ਅਤੇ ਇੱਕੋ ਸੰਪਾਦਕ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ ਪਰ ਬਿਲਕੁਲ ਵੱਖਰੇ ਗਤੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ—ਟੈਲੈਂਟ ਦੇ ਕਾਰਨ ਨਹੀਂ, ਬਲਕਿ ਅਭਿਆਸਤ ਆਦਤਾਂ ਦੇ ਕਾਰਨ।
ਇਹ ਕੋਈ ਕਮਾਂਡ ਇਨਸਾਇਕਲੋਪੀਡੀਆ ਨਹੀਂ ਹੈ. ਇਸ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਉਹ ਵਰਕਫਲੋ ਪੈਟਰਨ ਸਿੱਖੋਗੇ ਜੋ Vimਨੇ ਪ੍ਰਸਿੱਧ ਕੀਤੇ: ਲੋਕ ਕਿਸ ਤਰ੍ਹਾਂ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਸੰਪਾਦਨ ਰੁਟੀਨਾਂ ਬਣਾਉਂਦੇ ਹਨ, ਛੋਟੇ ਬਦਲਾਵਾਂ ਦੌਰਾਨ ਰੋੜਾ ਘਟਾਉਂਦੇ ਹਨ, ਅਤੇ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਸੁਚਿੱਤ ਰਹਿੰਦੇ ਹਨ.
ਤੁਹਾਨੂੰ "Vim ਦਾ ਵਿਅਕਤੀ" ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ; ਅਤੇ ਤੁਹਾਨੂੰ ਤਕਨੀਕੀ ਪਿਛੋਕੜ ਦੀ ਲੋੜ ਵੀ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਅਗੇ ਵਧ ਸਕੋ. ਅਸੀਂ jargon ਘੱਟ ਰੱਖਾਂਗੇ, ਵਿਚਾਰ ਸਾਦੇ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਵਾਂਗੇ, ਅਤੇ ਇਸ 'ਤੇ ਧਿਆਨ ਦਿਆਂਗੇ ਕਿ ਆਦਤਾਂ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ — ਭਾਵੇਂ ਤੁਸੀਂ ਅੱਜ ਕਿਸੇ ਹੋਰ ਸੰਪਾਦਕ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ.
Bram Moolenaar (1961–2023) Vim ਦੀ ਪਛਾਣ ਤੋਂ ਅਵਿਨਾਭਵੀ ਹਨ — ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਕਿ Vim ਕੋਈ ਇੱਕ ਵਿਅਕਤੀ ਦਾ ਪ੍ਰੋਜੈਕਟ ਸੀ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਏਕਸਥਿਰ ਸਹਿਯੋਗ ਦਿੱਤਾ ਜਿਸ ਨਾਲ ਇੱਕ ਵਲੰਟੀਅਰ-ਚਲਤ ਟੂਲ ਦਹਾਕਿਆਂ ਤਕ ਸुसੰਗਤ ਰਹਿ ਸਕਿਆ.
Vim ਦੀਆਂ ਜੜ੍ਹਾਂ vi ਸੰਪਾਦਕ ਰਿਵਾਇਤ ਵਿੱਚ ਹਨ. Bram ਨੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ 1980s ਦੇ ਆਖਰੀ ਹਿੱਸੇ ਵਿੱਚ ਕੀਤੀ, ਜਦੋਂ ਉਹ Commodore Amiga 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਸਨ, ਮੁਲਾਂਕਣ ਵਜੋਂ ਇੱਕ ਮੌਜੂਦਾ vi-ਸਮਰੂਪ ਸੰਪਾਦਕ 'ਤੇ ਸੁਧਾਰ ਕਰਨ ਲਈ. ਉੱਥੋਂ ਤੋਂ Vim ਤੇਜ਼ੀ ਨਾਲ ਆਪਣੀਆਂ ਜੜ੍ਹਾਂ ਤੋਂ ਅੱਗੇ ਵਧਿਆ: 1990s ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਰਿਲੀਜ਼ਾਂ ਨੇ ਫੀਚਰ ਅਤੇ ਪੋਰਟੇਬਿਲਟੀ ਵਧਾਈ, ਅਤੇ ਜਦੋਂ Unix, Windows, ਅਤੇ ਬਾਅਦ ਵਿੱਚ macOS ਤੇ Linux ਆਮ ਵਿਕਾਸਕਾਰ ਵਾਤਾਵਰਣ ਬਣੇ, Vim ਲਗਭਗ ਹਰ ਜਗ੍ਹਾ ਮਿਲਿਆ.
ਇਹ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਪਹੁੰਚ ਮਹੱਤਵਪੂਰਨ ਸੀ. ਇੱਕ ਟੂਲ ਜੋ ਘਰੇਲੂ ਮਸ਼ੀਨਾਂ, ਯੂਨੀਵਰਸਿਟੀ ਲੈਬ ਅਤੇ ਕੰਮ ਵਾਲੇ ਸਰਵਰਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹਾ ਵਰਤਿਆ ਜਾਂਦਾ, ਉਸਨੇ ਭਰੋਸਾ ਜਤਾਇਆ — ਅਤੇ ਇਹ ਭਰੋਸਾ Vim ਨੂੰ ਪੇਸ਼ੇਵਰਾਂ ਅਤੇ ਸ਼ੌਕੀਨਾਂ ਦੋਹਾਂ ਲਈ ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਦਾ ਡਿਫਾਲਟ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋਇਆ.
ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਅਕਸਰ ਮੁੱਢੇ-ਮੁੱਢੇ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤਾਲਮੇਲ ਕੋਡਿੰਗ ਨਾਲੋਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ. Bram ਦਾ ਮੁੱਖ ਯੋਗਦਾਨ Maintenance ਨੂੰ ਇੱਕ ਕਲ੍ਹੀਪਟਿਠ ਵਜੋਂ ਦੇਖਣਾ ਸੀ: ਪੈਚ ਦੀ ਸਮੀਖਿਆ ਕਰਨਾ, ਰਿਲੀਜ਼ਾਂ ਦਾ ਰਹਿਨੁਮਾ ਕਰਨਾ, ਦਸਤਾਵੇਜ਼ ਅਤੇ ਵਿਹਾਰ ਨੂੰ ਇਕਸਾਰ ਰੱਖਣਾ, ਅਤੇ ਮਿਲਕੇ ਕੰਮ ਕਰਨ ਦੇ ਨਿਯਮਾਂ ਸਥਾਪਤ ਕਰਨਾ. ਬਹੁਤ ਸਾਰੇ ਯੋਗਦਾਨਦਾਤਾ Vim ਨੂੰ ਸੁਧਾਰਿਆ, ਪਰ ਸੰਪਾਦਕ ਇੱਕ ਜਾਣ ਪਛਾਣ ਵਾਲਾ "ਅਹਿਸਾਸ" ਰੱਖਦਾ ਰਿਹਾ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਤਾਲਮੇਲ ਵਿੱਚ ਰੱਖਿਆ.
Vim ਨੂੰ "charityware" ਵਜੋਂ ਵੀ ਜਾਣਿਆ ਗਿਆ. ਸਰਲ ਤਰੀਕੇ ਨਾਲ ਸੋਚ ਇਹ ਸੀ: ਜੇ ਤੁਸੀਂ Vim ਨੂੰ ਲਾਭਦਾਇਕ ਪਾਉਂਦੇ ਹੋ, ਤਾਂ Bram ਜਿਹੜੀਆਂ ਚਰਿਟੀ ਕਾਰਨ ਪ੍ਰਚਾਰ ਕਰਦੇ ਸਨ ਉਹਨਾਂ ਨੂੰ ਦਾਨ ਕਰਨ ਬਾਰੇ ਸੋਚੋ. ਇਹ ਕੋਈ ਪੇਵਾਲ ਨਹੀਂ ਸੀ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਲਈ ਲਾਜ਼ਮੀ ਨਹੀਂ ਸੀ; ਇਹ ਵਾਪਸ ਦੇਣ ਵੱਲ ਇੱਕ ਨਰਮ ਪ੍ਰੇਰਣਾ ਸੀ — ਇਸ ਗੱਲ ਦਾ ਪਹਿਲਾ ਸੰਕੇਤ ਕਿ ਸੌਫਟਵੇਅਰ ਸਭਿਆਚਾਰ ਵਿੱਚ ਉਦਾਰਤਾ ਵੀ ਸ਼ਾਮਲ ਹੋ ਸਕਦੀ ਹੈ, ਸਿਰਫ਼ ਕੁਸ਼ਲਤਾ ਨਹੀਂ.
Vim ਦੀ ਲੰਮੀ ਯਾਤਰਾ ਆਖ਼ਿਰਕਾਰ ਇਕਤਾ ਬਾਰੇ ਹੈ: ਇੱਕ ਐਸਾ ਸੰਪਾਦਕ ਜੋ ਰੁਝਾਨਾਂ ਦੇ ਪਿੱਛੇ ਦੌੜਨ ਦੇ ਬਦਲੇ ਧੀਰੇ-ਧੀਰੇ ਵਿਕਸਿਤ ਹੋਇਆ ਅਤੇ ਆਪਣੀ ਕਮਿਊਨਿਟੀ ਅਤੇ ਮੁੱਲਾਂ ਨੂੰ ਅਟੁਟ ਰੱਖਿਆ।
Vim ਦਾ ਸਭ ਤੋਂ ਵਿਲੱਖਣ ਵਿਚਾਰ ਮੋਡਾਂ ਹਨ: ਇੱਕੋ ਹੀ ਕੀਜ਼ ਵੱਖ-ਵੱਖ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹੋ. ਇਹ ajeeb ਲੱਗ ਸਕਦਾ ਹੈ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਸਮਝਦੇ ਨਹੀਂ ਕਿ ਇਹ ਉਸ ਤਰੀਕੇ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦੇ ਹੋ — ਕਈ ਵਾਰ ਤੁਸੀਂ ਸੋਚ ਰਹੇ ਹੋ ਬਦਲਾਅ ਬਾਰੇ, ਅਤੇ ਕਈ ਵਾਰ ਤੁਸੀਂ ਨਵਾਂ ਟੈਕਸਟ ਟਾਈਪ ਕਰ ਰਹੇ ਹੋ.
Normal mode ਸੋਧ ਕਾਰਵਾਈਆਂ ਲਈ ਹੈ: ਘੁੰਮਣਾ, ਮਿਟਾਉਣਾ, ਬਦਲਣਾ, ਖੋਜ. ਤੁਸੀਂ ਲਿਖ ਨਹੀਂ ਰਹੇ; ਤੁਸੀਂ ਨਿਰਦੇਸ਼ ਦੇ ਰਹੇ ਹੋ.
Insert mode ਅੱਖਰ ਟਾਈਪ ਕਰਨ ਲਈ ਹੈ — ਜੋ ਜ਼ਿਆਦातर ਸੰਪਾਦਕ ਡਿਫਾਲਟ ਮੰਨਦੇ ਹਨ.
Visual mode ਟੈਕਸਟ ਚੁਣਨ ਲਈ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸ 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਸਕੋ (indent, delete, change, copy).
ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ:
dd ਦਬਾ ਕੇ ਪੂਰੀ ਲਾਈਨ ਹਟਾਓ.i ਦਬਾ ਕੇ Insert mode ਵਿੱਚ ਜਾਓ ਅਤੇ ਨਵਾਂ ਸਮੱਗਰੀ ਲਿਖੋ.Esc ਦਬਾ ਕੇ Normal mode ਵਿੱਚ ਵਾਪਸ ਆਓ.v ਦਬਾ ਕੇ Visual mode ਸ਼ੁਰੂ ਕਰੋ, ਚਲੋ ਚੁਣੋ, ਫਿਰ d ਦਬਾ ਕੇ ਚੁਣੀ ਹੋਈ ਭਾਗ ਹਟਾਓ.ਜਦੋਂ ਹਰ ਚੀਜ਼ ਹਮੇਸ਼ਾਂ ਟਾਈਪ ਕਰਨ ਵਾਲੀ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਵੱਖ ਕੰਮ ਮਿਲਾ ਬੈਠਦੇ ਹੋ: ਬਣਾਵਟ ਅਤੇ ਸੋਧਨ. ਮੋਡਲ ਸੰਪਾਦਨ ਉਹਨਾਂ ਨੂੰ ਅਲੱਗ ਕਰਦਾ ਹੈ.
Normal mode ਵਿੱਚ, ਤੁਹਾਡੇ ਹੱਥ ਅਕਸਮਾਤੀ ਤੌਰ 'ਤੇ ਅੱਖਰ ਘੁਸਾਉਣ ਲਈ "ਸਰਿ ਗਏ" ਨਹੀਂ ਹੁੰਦੇ. ਇਸ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਯੋਜਨਾਬੱਧ ਰਹਿੰਦੇ ਹੋ: ਮੈਂ ਕਿੜਾ ਬਦਲਣਾ ਚਾਹੁੰਦਾ ਹਾਂ? ਇਸ ਨੂੰ ਮਿਟਾਓ, ਉਥੇ ਬਦਲੋ, ਉੱਥੇ ਜਾਓ, ਦੁਹਰਾਓ. Insert mode ਇੱਕ ਕੇਂਦਰਤ ਲਹਿਰ ਬਣ ਜਾਂਦੀ ਹੈ: ਹੁਣ ਮੈਂ ਟੈਕਸਟ ਜੁੜ ਰਿਹਾ ਹਾਂ.
ਵੇਲੇ ਦੇ ਨਾਲ, ਇਹ ਲੱਗਦਾ ਹੈ ਜਿਵੇਂ ਸੰਪਾਦਕ ਨਾਲ ਲੜਨਾ ਘੱਟ ਹੋ ਗਿਆ ਅਤੇ ਹੋਰ ਸਪਸ਼ਟ, ਛੋਟੇ ਨਿਰਦੇਸ਼ ਦੇ ਰਹੇ ਹੋ.
ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੀਆਂ ਤਕਲੀਫਾਂ ਪਹਿਲਾਂ ਹੀ ਪੇਸ਼ ਆਉਂਦੀਆਂ ਹਨ:
x ਜਾਂ dd ਵਰਗਾ ਕਮਾਂਡ ਮਾਰ ਦਿੱਤਾ.)i ਦਬਾਓ.)ਮੋਡਾਂ ਨੂੰ ਇਰਾਦੇ ਦੀਆਂ ਹਾਲਤਾਂ ਵਜੋਂ ਵਿਆਖਿਆ ਕਰੋ. Normal mode "ਕਾਮ ਨਹੀਂ ਕਰ ਰਿਹਾ" ਨਹੀਂ ਹੈ—ਇਹ ਉਹ ਮੋਡ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਜਾਣ-ਬੂਝ ਕੇ ਸੋਧ ਕਰਦੇ ਹੋ. ਇਹ ਆਦਤ ਮੋਡਲ ਸੰਪਾਦਨ ਸਿਖਾਂਦਾ ਹੈ: ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਬਦਲਾਅ, ਫਿਰ ਟਾਈਪਿੰਗ.
Vim ਦੀ “ਸੁਪਰਪਾਵਰ” ਕੋਈ ਵੱਡਾ ਮੈਨੂ ਨਹੀਂ — ਇਹ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਛੋਟੀ-ਛੋਟੀ ਕਮਾਂਡਜ਼ ਇਕੱਠੇ ਮਿਲਦੀਆਂ ਹਨ. ਹਰ ਸਥਿਤੀ ਲਈ ਵੱਖ shortcut ਯਾਦ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੁਝ ਨਿਰਮਾਣ ਖੰਦਾਂ ਸਿੱਖਦੇ ਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜਦੇ ਹੋ.
ਸੰਪਾਦਨ ਨੂੰ ਸੋਚੋ ਜਿਵੇਂ ਇੱਕ ਕਿਰਿਆ ਨੂੰ ਟੈਕਸਟ ਦੇ ਇੱਕ ਟੁਕੜੇ 'ਤੇ ਲਾਗੂ ਕਰਨਾ.
Vim ਭਾਸ਼ਾ ਵਿੱਚ, ਕਿਰਿਆਆਂ ਨੂੰ operators ਕਹਿੰਦੇ ਹਨ (ਜਿਵੇਂ d delete ਲਈ, c change ਲਈ), ਅਤੇ ਵਸਤੂਆਂ ਨੂੰ motions/text objects ਕਹਿੰਦੇ ਹਨ (ਜਿਵੇਂ w ਸ਼ਬਦ ਲਈ, ) ਵਾਕ ਲਈ, i\" quotes ਦੇ ਅੰਦਰ ਲਈ).
ਕੁਝ ਜੋੜੇ ਵੇਖੋ:
cw — “change” + “word”. ਪਹਿਲਾਂ select ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਸੀਂ ਆਪਣੀ ਮੁਰਾਦ ਬਿਆਨ ਕਰਦੇ ਹੋ.di\" — “delete” + “inside quotes”. ਇਹ quotes ਨੂੰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਸਮੱਗਰੀ ਹਟਾਉਂਦਾ ਹੈ.v ਫਿਰ ਕੁਝ ਜਿਵੇਂ i{ — visual select + “inside braces” ਤਾ ਕਿ { ... } ਬਲੌਕ ਨੂੰ ਪਕੜ ਸਕੋ.ਮਕਸਦ ಚಿತ್ರਾਂ ਇਕਠੇ ਕਰਨਾ ਨਹੀਂ ਹੈ. ਮਕਸਦ ਇੱਕ ਮਾਨਸਿਕ ਮਾਡਲ ਬਣਾਉਣਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕਮਾਂਡ ਭਵਿੱਖ-ਬਾਣੀਯੋਗ ਹੋਂਦੀਆਂ ਹਨ.
Composability ਸਹੀ ਅਤੇ ਇਕਸਾਰਤਾ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀ ਹੈ. ਜਦੋਂ ਇੱਕੋ ਹੀ ਕਿਰਿਆ ਕਈ ਵਸਤੂਆਂ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ, ਤੁਸੀਂ ਘੱਟ "ਸੰਪਾਦਨੀ ਅਨੁਮਾਨ" ਲਗਾਉਂਦੇ ਹੋ, ਘੱਟ undo ਕਰਦੇ ਹੋ, ਅਤੇ ਅਣਜਾਣ ਫਾਈਲਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਅਧਿਕ ਸ਼ਾਂਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ. ਤੇਜ਼ੀ ਅਕਸਰ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੀ ਹੈ — ਨਾ ਇਹ ਸੋਚ ਕੇ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਪਰ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨੂੰ ਦੁਹਰਾ ਰਹੇ ਹੋ.
Vim ਦਾ ਇੱਕ ਸਭ ਤੋਂ ਪ੍ਰਾਇਕਟਿਕ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਸੰਪਾਦਨ ਇਕ ਇਕ-ਵਾਰੋਂ ਪ੍ਰਦਰਸ਼ਨ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ. ਜੇ ਤੁਸੀਂ ਇੱਕ ਸੋਧ ਨੂੰ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹ ਦੁਹਰਾਉਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ — ਅਗਲੀ ਲਾਈਨ, ਅਗਲਾ ਪੈਰਾ, ਜਾਂ ਅਗਲੀ ਫਾਈਲ 'ਤੇ. ਇੱਥੇ ਹੀ "ਤੇਜ਼ੀ" ਲਿਖਣ ਦੀ ਬਜਾਏ ਫੈਸਲੇ ਦੀ ਥਕਾਵਟ ਘਟਾਉਣ ਬਾਰੇ ਹੁੰਦੀ ਹੈ.
dot (.) ਤੁਹਾਡੀ ਆਖਰੀ ਸੋਧ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ. ਇਹ ਛੋਟਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਸੁੱਧ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਚੰਕਾਂ ਵਿੱਚ ਸੋਧ ਕਰਨ ਦੀ ਹੌਸਲਾ афਜ਼ਾਈ ਕਰਦਾ ਹੈ.
ਉਦਾਹਰਣ: ਤੁਸੀਂ ਇੱਕ ਲਾਈਨ 'ਤੇ foo ਨੂੰ foo() ਕਰ ਰਹੇ ਹੋ। ਬਾਅਦ ਵਾਲੀਆਂ ਥਾਵਾਂ 'ਤੇ, ਤੁਸੀਂ ਅਕਸਰ ਕੇਵਲ ਕਰਸਰ ਨੂੰ ਸਹੀ ਥਾਂ 'ਤੇ ਲਾ ਕੇ . ਦਬਾ ਦੇ ਸਕਦੇ ਹੋ ਬਜਾਏ ਫਿਰ ਉਹੀ ਇਨਸਰਟ ਦੁਹਰਾਉਣ ਦੇ.
Macros ਤੁਹਾਨੂੰ ਕੀਸੇ ਕ੍ਰਮ ਦੇ ਕੀ-ਸਟ੍ਰੋਕਸ ਰਿਕਾਰਡ ਕਰਨ ਅਤੇ ਮੁੜ ਚਲਾਉਣ ਦਿੰਦੇ ਹਨ. ਸੰਕਲਪਕ ਤੌਰ 'ਤੇ, ਇਹ ਐਡਜ਼ ਕੀਤਾ ਹੋਇਆ ਹੈ: "ਜਦੋਂ ਤੁਹਾਨੂੰ ਇਹ ਪੈਟਰਨ ਮਿਲੇ, ਇਹ ਕਦਮ ਲਗਾਓ." ਇੱਕ ਸੁਰੱਖਿਅਤ, ਸਧਾਰਣ ਵਰਤੋਂ ਤੇ ਤਾਲਿਕਾ ਫਾਰਮੈਟਿੰਗ ਲਈ ਹੋ ਸਕਦੀ ਹੈ:
- ਜੋੜੋਜਦੋਂ ਟੈਕਸਟ ਇਕਸਾਰ ਨਾ ਹੋਵੇ ਤਾਂ ਓਵਰ-ਆਟੋਮੇਸ਼ਨ ਤੋਂ ਬਚੋ. ਜੇ ਹਰ ਲਾਈਨ ਲਈ ਵੱਖਰਾ ਫੈਸਲਾ ਲੈਣਾ ਪੈਂਦਾ ਹੈ ("ਕਦੇ ਸ਼ਾਮਿਲ ਕਰੋ, ਕਦੇ ਹਟਾਓ"), ਤਾਂ macro ਛੁਪੀਆਂ ਗਲਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ.
Search ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਨੈਵੀਗੇਸ਼ਨ ਟੂਲ ਹੈ; substitution ਖੋਜ ਅਤੇ ਕੰਮ ਜੋੜਦਾ ਹੈ. ਸਧਾਰਨ ਸੋਚੋ: "ਇਸ ਸਟਰਿੰਗ ਨੂੰ ਲੱਭੋ, ਉਸਦੇ ਨਾਲ ਇਹ ਬਦਲੋ," ਜਿਵੇਂ temp ਨੂੰ draft ਨਾਲ ਫਾਈਲ ਵਿੱਚ ਨਾਂ ਬਦਲਣਾ. ਜੇ ਬਦਲਾਵ ਅਣਜਾਣ ਟੈਕਸਟ 'ਤੇ ਵੀ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਹਰ ਰੀਪਲੇਸਮੈਂਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਬਿਨਾਂ ਅੰਨ-ਚਾਪ ਦੇ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ.
ਵੱਡਾ ਸਬਕ: ਆਮ ਸੋਧਾਂ ਲਈ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਨੁਸਖੇ ਬਣਾਓ. ਸਮੇਂ ਦੇ ਨਾਲ, ਤੁਹਾਡਾ ਵਰਕਫਲੋ ਛੋਟੇ, ਭਰੋਸੇਯੋਗ ਕਦਮਾਂ ਦੀ ਲਾਇਬ੍ਰੇਰੀ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਅਨੁਸ਼ਾਸਨ-ਰਹਿਤ fixes ਦਾ ਸਟ੍ਰੀਮ.
Vim ਦੀ ਕੀਬੋਰਡ-ਪਹਿਲੀ ਸ਼ੈਲੀ ਕੋਈ ਪਿਆਰ-ਪਰੀਖਿਆ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਕਿਸੇ ਨੂੰ "ਵਧੀਆ" ਡੈਵਲਪਰ ਨਹੀਂ ਬਣਾਉਂਦੀ. ਮਕਸਦ ਸਾਂਝਾ ਹੈ: ਹਰ ਵਾਰੀ ਜਦੋਂ ਤੁਸੀਂ ਮਾਊਸ ਜਾਂ ਟ੍ਰੈਕਪੈਡ ਦੀ ਔਖੀ ਪਹੁੰਚ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਧਿਆਨ ਚੱਕਰ ਤੋੜਦੇ ਹੋ—ਹੱਥ ਹੋਮ ਰੋ ਤੋਂ ਹਟਦੇ ਹਨ, ਅੱਖਾਂ ਕਰਸਰ ਲਈ ਖੋਜਦੀਆਂ ਹਨ, ਅਤੇ ਦਿਮਾਗ਼ "ਕੀ" ਤੋਂ "ਕਿੱਥੇ" ਤੇ context-switch ਕਰਦਾ ਹੈ. ਇਹ ਰੁਕਾਵਟਾਂ ਘਟਾਉਣ ਨਾਲ ਤੁਸੀਂ ਜਿਸ ਸਮੱਸਿਆ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਉਸ 'ਤੇ ਬਣੇ ਰਹਿਣਾ ਆਸਾਨ ਹੋ ਜਾਉਂਦਾ ਹੈ.
Vim ਤੁਹਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਟੈਕਸਟ ਵਿਚ ਨੈਵੀਗੇਟ ਕਰਨ ਲਈ ਉਤਸਾਹਿਤ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ:
w, b, e, )), ਜਦੋਂ ਤੁਸੀਂ prose ਜਾਂ identifiers ਦੀ ਸ਼ਕਲ ਬਣਾ ਰਹੇ ਹੋ0, ^, $, gg, G), ਜਦੋਂ ਢਾਂਚਾ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ/, ?, n, N), ਜਦੋਂ ਤੁਸੀਂ ਨੀਅਤ ਖੋਜ ਰਹੇ ਹੋ:e, :b, tags/LSP jumps), ਜਦੋਂ ਬਦਲਾਵ ਕੋਡਬੇਸ ਵਿੱਚ ਫੈਲਾ ਹੋਸਮੇਂ ਦੇ ਨਾਲ, "ਉਸ ਚੀਜ਼ 'ਤੇ ਜਾਓ" ਇੱਕ ਰਿਫਲੈਕਸ ਬਣ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਹਰ ਵਾਰੀ ਇੱਕ ਨਿਰੀਣ.
ਅਸਲ ਫਾਇਦਾ ਮਿਲੀ-ਸਕੀਕਣ ਸਕਿੰਟਾਂ ਘਟਾਉਣਾ ਨਹੀਂ; ਇਹ ਹੇਜ਼-ਹੇਜ਼ ਰੁਕਾਵਟਾਂ ਹਟਾਉਣਾ ਹੈ. ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ motions — ਜਿਵੇਂ "quotes ਦੇ ਅੰਦਰ ਬਦਲਣਾ" ਜਾਂ "ਅੱਗੇ ਦੀ ਕੌਮਾ ਤੱਕ ਮਿਟਾਉਣਾ" — ਆਮ ਸੋਧਾਂ ਲਈ ਫਿਨਕਾਰੀਆਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ. ਜਦੋਂ ਉਹ ਪੈਟਰਨ ਮਾਸਪੇਸ਼ੀ ਯਾਦ ਵਿੱਚ ਠਹਿਰਦੇ ਹਨ, ਤੁਸੀਂ ਸੰਪਾਦਕ ਚਲਾਉਣ 'ਤੇ ਘੱਟ ਮਨੋ-ਛਕੜਾ ਖਰਚਦੇ ਹੋ ਅਤੇ ਵਧੇਰੇ ਸੋਚ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹੋ.
ਕੀਬੋਰਡ-ਚਲਿਤ ਵਰਕਫਲੋ ਕੁਝ ਲੋਕਾਂ ਲਈ writs travel ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਹੋਰਾਂ ਲਈ ਉੰਗਲਾਂ 'ਤੇ ਭਾਰ ਵਧਾ ਸਕਦੀ ਹੈ. ਆਰਾਮਿਕ ਲਾਭ ਵਿਅਕਤੀ, ਕੀਬੋਰਡ ਲੇਆਉਟ, ਅਤੇ ਕਮਾਂਡ ਚੋਣਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ. Vim ਦੀ customization ਦੀ ਸੰਸਕ੍ਰਿਤੀ ਇੱਥੇ ਮਦਦਗਾਰ ਹੈ: awkward keys remap ਕਰੋ, ਵਰਤੋਂ ਦੀ ਰਫਤਾਰ ਸਮਤਲ ਰੱਖੋ, ਅਤੇ ਸਿਧਾਂਤ ਨਹੀਂ, ਆਰਾਮ ਨੂੰ ਤਰਜੀਹ ਦਿਓ. ਮਕਸਦ ਸਥਾਈ ਧਿਆਨ ਹੈ, ਨਾ ਕਿ ਸਹਿਣਸ਼ਕਤੀ.
Vim ਹਮੇਸ਼ਾ ਮਾਲਕੀਅਤ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਆਇਆ ਹੈ. ਸੰਪਾਦਕ ਨੂੰ ਇੱਕ ਸੀਲਡ ਉਤਪਾਦ ਵਜੋਂ ਦੇਖਣ ਦੀ ਥਾਂ, ਇਹ ਇਸਨੂੰ ਇੱਕ ਵਰਕਬੈਂਚ ਵਜੋਂ ਵੇਖਦਾ ਹੈ — ਕੁਝ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਸੋਚ ਦੇ ਅਨੁਸਾਰ ਸੁਧਾਰਦੇ ਹੋ.
A vimrc Vim ਦੀ configuration ਫਾਈਲ ਹੈ. ਇੱਥੇ ਤੁਸੀਂ ਆਪਣੇ defaults ਸੈੱਟ ਕਰਦੇ ਹੋ: tabs ਕਿਵੇਂ ਚੱਲਣ, ਲਾਈਨਾਂ wrap ਹੋਣ ਜਾਂ ਨਹੀਂ, status line ਕੀ ਦਿਖਾਏ, ਆਦਿ. ਸਮੇਂ ਦੇ ਨਾਲ, ਕਈ ਡੈਵਲਪਰ ਇਹ settings version control ਵਿੱਚ ਰੱਖਦੇ ਹਨ ਆਪਣੇ "dotfiles" ਦੇ ਹਿੱਸੇ ਵਜੋਂ, ਤਾਂ ਜੋ ਉਨ੍ਹਾਂ ਦਾ ਸੰਪਾਦਕ ਕਿਸੇ ਵੀ ਮਸ਼ੀਨ 'ਤੇ ਜਾਣ-ਪਛਾਣ ਵਾਲਾ ਮਹਿਸੂਸ ਹੋਵੇ.
ਇਹ ਸਿਰਫ਼ personalization ਲਈ ਨਹੀਂ ਹੈ. ਇਹ ਇੱਕ ਸਭਿਆਚਾਰਕ ਨਿਯਮ ਹੈ ਕਿਉਂਕਿ ਛੋਟੇ defaults ਮਿਲ ਕੇ ਵੱਡੇ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ: ਘੱਟ friction, ਘੱਟ ਹੈਰਾਨੀ, ਅਤੇ ਘੱਟ "Vim ਇਹ ਕਿਉਂ ਕਰ ਰਿਹਾ ਹੈ?" ਵਾਲੇ ਮੋਮੈਂਟ.
ਬਿਹਤਰ ਤਰੀਕਾ ਜੀਹੜਾ ਗੰਦਾ ਸੈਟਅਪ ਬਣਾਉਂਦਾ ਹੈ ਉਹ ਹੈ ਬਿਨਾਂ ਸਮਝੇ ਦੱਸ plugins ਇੰਸਟਾਲ ਕਰਨਾ. ਇੱਕ ਸਿਹਤਮੰਦ ਰਵੱਈਆ:
ਆਪਣੇ vimrc ਨੂੰ ਇੱਕ ਵਰਕਸ਼ਾਪ ਲੋਗਬੁੱਕ ਵਜੋਂ ਰੱਖੋ, ਨਾ ਕਿ ਇਕ ਜੰਕ ਡਰੌਰ ਵਜੋਂ.
A mapping ਇੱਕ ਸ਼ਾਰਟਕੱਟ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਕੀ-ਕੰਬੋ ਦਬਾਉਂਦੇ ਹੋ ਅਤੇ Vim ਲੰਬੀ ਕਮਾਂਡ ਸਿਰੇ ਕਰ ਦਿੰਦਾ ਹੈ. ਚੰਗੀਆਂ mappings ਦੁਹਰਾਅ ਘਟਾਉਂਦੀਆਂ ਹਨ; ਮਾੜੀਆਂ mappings Vim ਨੂੰ inconsistent ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀਆਂ ਹਨ.
A plugin ਫੀਚਰ ਜੋੜਦਾ ਹੈ: file pickers, Git ਮਦਦਗਾਰ, ਬਿਹਤਰ ਭਾਸ਼ਾ ਸਮਰਥਨ. Plugins ਵਧੀਆ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਵੀ ਹਿਲਦੇ-ਡੁਲਦੇ ਹਿੱਸੇ, startup ਸਮਾਂ, ਅਤੇ ਨਵੀਆਂ ਵਿਹਾਰਾਂ ਜੋੜਦੇ ਹਨ ਜੋ ਸਿੱਖਣ ਲੱਗਦੀਆਂ ਹਨ.
ਅਤਿ-ਵੱਧ extras ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ, ਕੁਝ defaults ਨਾਲ ਆਰਾਮ ਮਹਿਸੂਸ ਕਰੋ:
ਜਦੋਂ ਉਹ ਬੇਸਲਾਈਨ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਹੋਵੇ, plugins ਇੱਕ ਸੋਚ-ਸਮਝ ਕੇ ਕੀਤਾ ਹੋਇਆ ਉਨਗ੍ਰੇਡ ਬਣਦੇ ਹਨ — ਨਾ ਕਿ Vim ਸਿੱਖਣ ਦੀ ਜਗ੍ਹਾ।
Vim ਦੀ ਸਭਿਆਚਾਰ plugins ਜਾਂ hotkeys ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੀ — ਇਹ ਸਿੱਖਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ. Bram Moolenaar ਨੇ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਮੰਨਿਆ, ਅਤੇ ਇਹ ਰਵੱਈਆ ਇਹ ਨਿਰਧਾਰਤ ਕੀਤਾ ਕਿ ਲੋਕ Vim ਨੂੰ ਚੁੱਪ-ਚਾਪ ਗੁਪਤ ਰਾਜ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਹੁਨਰ ਵਜੋਂ ਸਿੱਖਾਉਂਦੇ ਹਨ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕਦਮ ਦਰ ਕਦਮ ਵਧਾ ਸਕਦੇ ਹੋ.
Vim ਦਾ :help ਇੱਕ ਸੋਚ-ਵਿਚਾਰ ਨਾ ਹੋ ਕੇ ਇੱਕ ਨਕਸ਼ਾ ਹੈ. ਇਹ ਕੌਮਾਂਤਰੀ ਧਰੋਹ ਨਾਲ ciekaviy ਢੰਗ ਨਾਲ ਇਨਾਮ ਦਿੰਦਾ ਹੈ—ਟਾਪਿਕਸ, cross-references, ਅਤੇ ਉਦਾਹਰਣ ਜਿਹੜੇ ਤੁਹਾਡੇ ਤਲਾਸ਼ ਕਰਨ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹਨ.
ਕੁਝ ਛੋਟੀਆਂ ਆਦਤਾਂ ਜਿਹੜੀਆਂ "ਮੈਂ ਫਸ ਗਿਆ" ਨੂੰ "ਮੈਂ ਲੱਭ ਲਿਆ" ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ:
:help {topic} (ਜਾਂ :h) ਨਾਲ ਕਿਸੇ ਧਾਰਣਾ 'ਤੇ ਸਿੱਧਾ ਜਾਓ, ਜਿਵੇਂ :h motion ਜਾਂ :h visual-modeCTRL-] help ਵਿੱਚ ਲਿੰਕ ਫਾਲੋ ਕਰਨ ਲਈ, ਅਤੇ CTRL-T ਵਾਪਸ ਜਾਣ ਲਈ:helpgrep {word} ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਹੀ ਸ਼ਬਦ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਤਾਂ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਖੋਜ ਕਰਨ ਲਈਇਹ ਮਾਡਲ ਸਕੇਲ ਕਰਦਾ ਹੈ: ਜਦੋਂ ਤੁਸੀਂ edit ਨੂੰ ਸ਼ੋਧਣ ਲਈ editor ਨੂੰ ਸਵਾਲ ਪੁੱਛਣਾ ਸਿੱਖ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਘੱਟ ਨਿਰਭਰ ਹੋ ਜਾਦਾ ਹੋ ਖਾਸ ਤੌਰ 'ਤੇ ਯਾਦ ਰੱਖਣ 'ਤੇ.
Vim mentorship ਅਕਸਰ ਛੋਟੇ, ਇਜ਼ਤਦਾਰ ਹਸਤਖੇਪ ਵਰਗਾ ਦਿਸਦਾ ਹੈ: ਇੱਕ mapping, ਇੱਕ motion, ਇੱਕ workflow ਸੁਧਾਰ. ਲਿਖਤੀ ਬਾਤ ਦਾ ਅਣਾ-ਲਿਖਾ ਨਿਯਮ "ਲੋਕਾਂ ਨੂੰ ਉਹਥੇ ਮਿਲੋ ਜਿੱਥੇ ਉਹ ਹਨ" ਹੈ. ਅਕਸਰ ਇੱਕ ਸੁਝਾਅ ਸਾਂਝਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, "ਜੇ ਤੁਹਾਡਾ ਸੰਪਾਦਕ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਲਈ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਠੀਕ ਹੈ."
ਹੋਰ ਨਿਯਮ ਵੀ ਪ੍ਰਯੋਗਸ਼ੀਲ ਹਨ:
Vim ਗਿਆਨ ਹਲਕੇ-ਫੁਲਕੇ ਆਈਟਮਾਂ ਰਾਹੀਂ ਫੈਲਦਾ ਹੈ: cheat sheets, lightning talks, dotfile templates, ਅਤੇ ਛੋਟੇ "starter" repos. ਸਭ ਤੋਂ ਵਧੀਆ ਉਹ ਹਨ ਜੋ ਇਹ ਦੱਸਦੇ ਹਨ ਕਿ ਇੱਕ ਆਦਤ ਕਿਉਂ ਮਦਦ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ ਕੇਵਲ ਕੀ ਟਾਈਪ ਕਰਨਾ ਹੈ.
ਕੁਝ ਲੋਕ ਸਿਰਫ़ SSH 'ਤੇ ਤੁਰੰਤ ਸੋਧਾਂ ਲਈ Vim ਦੀ ਲੋੜ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ; ਹੋਰ ਲੋਕ ਦਿਨ ਭਰ ਦਾ ਮਹੱਤਵਪੂਰਨ ਵਾਤਾਵਰਣ ਉਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ. Vim ਦੀ ਸਭਿਆਚਾਰ ਦੁਹਾਂ ਨੂੰ ਕਬੂਲ ਕਰਦੀ ਹੈ ਅਤੇ ਦੋਨਾਂ ਰਸਤੇ ਦਰਮਿਆਨ ਰਸਤਾ ਸੂਝਵਾਂਦਾਰ ਰੱਖਦੀ ਹੈ.
Vim ਦੀ ਸਾਖ ਅਕਸਰ "ਪਾਵਰ" 'ਤੇ ਬਣਦੀ ਹੈ, ਪਰ ਇਸਦੀ ਅਸਲ ਕੀਮਤ ਸਧਾਰਨ ਪਲਾਂ ਵਿੱਚ ਵੇਖਣ ਨੂੰ ਮਿਲਦੀ ਹੈ: ਇੱਕ commit message ਜੋ ਸਾਫ਼ ਹੋਣਾ ਚਾਹੀਦਾ, ਇੱਕ production config ਫਾਈਲ ਜਿਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਾ ਹੋਵੇ, ਜਾਂ ਇੱਕ pairing session ਜਿਥੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸੋਧ ਸਪਸ਼ਟ ਤੇ ਆਸਾਨੀ ਨਾਲ ਸਮਝਾਵਾਂ ਜਾਣ.
Commit ਸੰਪਾਦਨ: ਕਈ ਡੈਵਲਪਰ Git ਨੂੰ Vim ਖੋਲ੍ਹਣ ਲਈ ਸੈੱਟ ਕਰਦੇ ਹਨ commit messages ਅਤੇ interactive rebases ਲਈ. ਮੋਡਲ ਸੰਪਾਦਨ ਇੱਥੇ ਫਿਟ ਬੈਠਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਵਧੀਕ ਸਮਾਂ ਪੜ੍ਹਨ ਅਤੇ ਟੈਕਸਟ ਨੂੰ ਦੁਬਾਰਾ ਤਰਤੀਬ ਦੇਣ ਵਿੱਚ ਬਿਤਾਉਂਦੇ ਹੋ, ਨਾ ਕਿ ਨਵਾਂ ਟਾਈਪ ਕਰਨ ਵਿੱਚ. Normal mode ਇਕ ਸਮੀਖਿਆ ਮੋਡ ਬਣ ਜਾਂਦਾ ਹੈ: ਵਾਕਾਂ ਵਿਚਕਾਰ ਉੱਡੋ, ਲਾਈਨਾਂ reorder ਕਰੋ, ਅਤੇ ਛੋਟੇ fixes ਕਰੋ ਬਿਨਾਂ ਮਾਊਸ ਲਈ.
ਤੁਰੰਤ ਸਰਵਰ fixes: ਜਦੋਂ ਤੁਸੀਂ SSH ਕਰਕੇ ਕਿਸੇ ਮਸ਼ੀਨ 'ਤੇ ਜਾ ਕੇ config patch ਕਰਨਾ ਹੋਵੇ, Vim ਅਮੂਮਨ ਪਹਿਲਾਂ ਹੀ ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ. ਮਕਸਦ customization ਨਹੀਂ—ਮਤਲਬ ਭਰੋਸਾ: ਸਹੀ stanza ਤਲਾਸ਼ੋ, ਸਿਰਫ਼ ਉਹੀ ਬਦਲੋ ਜਿਸਦੀ ਇਰਾਦਾ ਹੈ, ਸੇਵ ਕਰੋ, ਅਤੇ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਨਿਕਲੋ.
Pairing: Vim ਅਚanak surprising ਤੌਰ 'ਤੇ "pair-friendly" ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਕਦਮ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ. "ਇਸ ਪੈਰਾ ਮਿਟਾਓ" ਜਾਂ "quotes ਦੇ ਅੰਦਰ ਬਦਲੋ" ਕਹਿਣਾ ਸਾਫ਼ ਕਮਾਂਡਜ਼ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਸਾਥੀ ਦੇਖ ਕੇ ਸਿੱਖ ਸਕਦਾ ਹੈ.
Vim ਉਸ ਵੇਲੇ ਚਮਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਨੂੰ ਇੱਕ ਚੇਨ ਵਿੱਚ ਇੱਕ ਟੂਲ ਮੰਨਦੇ ਹੋ. ਤੁਸੀਂ ripgrep/grep ਨਾਲ ਖੋਜ ਕਰਕੇ ਨਤੀਜੇ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਅਤੇ ਨਿਸ਼ਾਨੇ ਸੰਪਾਦਨ ਕਰ ਸਕਦੇ ਹੋ—ਬਿਨਾਂ ਸੰਪਾਦਕ ਨੂੰ ਪੂਰੇ IDE ਵਿੱਚ ਬਦਲੇ.
ਉਦਾਹਰਣ ਲਈ, ਇੱਕ ਆਮ ਲੂਪ ਹੈ: ਟਰਮੀਨਲ ਵਿੱਚ search ਚਲਾਓ, ਫਾਈਲ ਨੂੰ ਮੈਚ 'ਤੇ ਖੋਲ੍ਹੋ, ਸੋਧ ਕਰੋ, ਫਿਰ ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਓ. ਇਹ "ਇੱਕ ਚੀਜ਼ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰੋ" ਦੇ ਰੁਜ਼ਾਨਾ ਕੰਮ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਟਰਮੀਨਲ ਲੱਭਦਾ ਹੈ; Vim ਸੋਧਦਾ ਹੈ; ਤੁਹਾਡਾ ਟੈਸਟ ਰਨਰ ਵੈਰੀਫਾਇ ਕਰਦਾ ਹੈ.
git config --global core.editor "vim"ਇਸ ਤਰ੍ਹਾਂ Vim ਸਕੇਲ ਕਰਦਾ ਹੈ: ਜਟਿਲਤਾ ਜੋੜਨ ਦੁਆਰਾ ਨਹੀਂ, ਬਲਕਿ ਆਮ ਸੋਧਾਂ ਨੂੰ ਤੇਜ਼, ਵਾਪਸਯੋਗ, ਅਤੇ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਇਕਸਾਰ ਬਣਾਕੇ.
Vim ਦੇ ਅਸਲ ਫਾਇਦੇ ਹਨ—ਪਰ ਇਹ ਮਿਥ ਵੀ ਇਕੱਠੇ ਕਰਦਾ ਹੈ. ਕੁਝ ਸ਼ੋਰਲੀਆਂ ਰਾਇਆਂ ਉਹਨਾਂ ਲੋਕਾਂ ਵੱਲੋਂ ਆਂਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਇਸਨੂੰ ਇੱਕ weekend ਲਈ ਟਰਾਇ ਕੀਤਾ, ਜਾਂ ਉਹਨਾਂ fanatics ਵੱਲੋਂ ਜੋ ਇਸਨੂੰ ਇਕ ਪਹਿਚਾਨੀ ਨਿਸ਼ਾਨੇ ਵੱਜੋਂ ਲੈਂਦੇ ਹਨ. ਇੱਕ ਵਧੀਆ ਸੋਚ ਇਹ ਹੈ: Vim ਕੁਝ ਇੰਟਰੈਕਸ਼ਨ-ਵਿੱਚਾਰਾਂ ਦਾ ਸੈੱਟ ਹੈ (ਖਾਸ ਕਰਕੇ modal editing) ਜੋ ਕਈ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਹਰ ਵਿਅਕਤੀ ਜਾਂ ਟੀਮ ਲਈ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਚੋਣ ਨਹੀਂ ਹੈ.
"Learning curve ਬਹੁਤ ਤੇਖੀ ਹੈ."
ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਠੀਕ ਹੈ ਕਿਉਂਕਿ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਵੱਖ-ਵੱਖ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ: ਮੋਡ, operator + motion, ਅਤੇ ਐਡਿਟਿੰਗ "ਕਿਰਿਆਵਾਂ" ਤੇ ਜ਼ੋਰ. ਮਾਡ ਢਲਣ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇੱਕ ਛੋਟਾ ਕੋਰ ਸਿੱਖੋ ਅਤੇ ਰੋਜ਼ਾਨਾ ਵਰਤੋਂ ਕਰੋ; ਪਰ ਜੇ ਤੁਸੀਂ ਕੇਵਲ ਕਦੇ-ਕਦੇ Vim ਖੋਲ੍ਹਦੇ ਹੋ, ਮਾਸਪੇਸ਼ੀ ਯਾਦ ਕਦੇ ਨਹੀਂ ਬਣਦੀ.
"ਇਹ discoverable ਨਹੀਂ ਹੈ."
ਇਹ ਕਰੀਬ-ਕਰੀਬ ਸੱਚ ਹੈ. Vim :help ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਹਉਸਲਾ ਅਫਜ਼ਾਈ ਕਰਦਾ ਹੈ, ਪਰ ਇੰਟਰਫੇਸ ਹਮੇਸ਼ਾ ਫੀਚਰਾਂ ਦਾ ਪ੍ਰਚਾਰ ਨਹੀਂ ਕਰਦਾ. Discoverability ਮੌਜੂਦ ਹੈ—ਸਿਰਫ਼ ਵੱਖ ਜਗ੍ਹਾ 'ਤੇ: help ਟਾਪਿਕਸ, built-in tutorials, ਅਤੇ ਅਦਾਂ-ਬਦਾਂ ਇੱਕ-ਦੂਜੇ ਨਾਲ patterns ਸਾਂਝੇ ਕਰਨ ਦੀ ਸਭਿਆਚਾਰ.
"ਹਰ Vim ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ."
ਇਹ ਵੀ ਸਚ ਹੈ. ਕਨਫਿਗਰੇਸ਼ਨ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ, plugins ਵਿਹਾਰ ਬਦਲ ਸਕਦੇ ਹਨ, ਅਤੇ यहाँ ਤੱਕ ਕਿ ਡਿਫਾਲਟ ਸੈਟਿੰਗਾਂ ਵੀ ਵਾਤਾਵਰਣਾਂ 'ਤੇ ਫਰਕ ਕਰਦੀਆਂ ਹਨ. ਇਹ pairing ਜਾਂ ਮਸ਼ੀਨ-ਚੇਂਜ ਦੇ ਦੌਰਾਨ ਨਰਾਸ਼ ਕਰਨ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ. ਟੀਮ ਆਮਤੌਰ 'ਤੇ ਇਹ ਸਲਾਹ ਦਿੰਦੀ ਹੈ ਕਿ ਨਿਯੂਨਤਮ ਸਾਂਝੇ defaults ਰੱਖੋ (ਯਾ "vanilla Vim" ਉਮੀਦਾਂ ਉੱਤੇ ਸਹਿਮਤ ਹੋਵੋ) ਨਾ ਕਿ ਹਰ ਚੀਜ਼ ਨੂੰ ਇੱਕਸਾਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ.
Vim ਇੱਕ ਨੁਕਸਾਨਦਿਹ ਮੈਚ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਟੀਮ ਦੀਆਂ ਲੋੜਾਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ IDE ਵਰਕਫਲੋ ਨੂੰ ਮੰਗਦੀਆਂ ਹਨ, ਜਦੋਂ onboarding ਲਈ ਸਮਾਂ ਘੱਟ ਹੋਵੇ, ਜਾਂ ਜਦੋਂ accessibility ਦੀਆਂ ਲੋੜਾਂ ਕੁਝ key-heavy ਇੰਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਅਸੁਵੀਕਾਰਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ. ਵਿਅਕਤਿਗਤ ਪਸੰਦਾਂ ਵੀ ਮਾਇਨੇ ਰਖਦੀਆਂ ਹਨ: ਕੁਝ ਲੋਕ ਦ੍ਰਿਸ਼ਯ UI ਵਿੱਚ ਬਿਹਤਰ ਸੋਚਦੇ ਹਨ ਅਤੇ ਉੱਥੇ ਉਹ ਆਪਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਨਗੇ.
ਅਮਲੀ ਰਵੱਈਆ ਇਹ ਹੈ ਕਿ ਉਹ ਟੂਲ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਅਸਲ ਕੰਮ ਨੂੰ ਸਹਾਰਦਾ ਹੋ: SSH 'ਤੇ ਤੇਜ਼ fixes, config ਫਾਈਲਾਂ ਸੰਪਾਦਨ, ਦਿਨ-ਭਰ ਕੋਡ ਲਿਖਣਾ, ਜਾਂ ਇੱਕ ਸਥਿਰ ਬਹਿਬੰਧੀ ਵਾਤਾਵਰਣ ਵਿੱਚ ਮਿਲਕੇ ਕੰਮ ਕਰਨਾ.
ਦੋ ਫੰਦੇ ਪ੍ਰੇਰਿਤ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਫਸਾ ਲੈਂਦੇ ਹਨ:
ਪਹਿਲਾ, ਅਨੰਤ tweaking — plugins ਨੂੰ tune ਕਰਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸਮਾਂ ਗੁਜ਼ਾਰਨਾ ਬਜਾਏ ਸੰਪਾਦਕ ਵਰਤਣ. ਦੂਜਾ, shortcut chasing — commands ਇਕੱਠੇ ਕਰ ਲੈਣਾ ਬਿਨਾਂ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੀਆਂ ਆਦਤਾਂ ਬਣਾਏ. ਜੇ ਤੁਸੀਂ Vim ਨੂੰ ਤੇਜ਼ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਉਹੀ ਵਰਕਫਲੋ ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਤੁਸੀਂ ਹਫ਼ਤੇ ਵਿੱਚ ਦੁਹਰਾਉਂਦੇ ਹੋ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ automate ਕਰੋ ਜੋ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਾਂ ਦੇ ਸਕਦੇ ਹੋ.
ਇੱਕ ਸਿਹਤਮੰਦ ਨਿਯਮ: ਜੇਕਰ ਕੋਈ ਬਦਲਾਅ ਅਗਲੇ ਹਫ਼ਤੇ ਸਮਾਂ ਬਚਾਉਂਦਾ ਜਾਂ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ ਤੁਰੰਤ ਨਾ ਕਰੋ.
Vim ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਇਹ ਤੁਹਾਨੂੰ flow ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਇਰਾਦੇ ਨਾਲ ਸੋਧ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪੈਟਰਨ ਬਣਾਉਂਦਾ ਹੈ. ਜੇ ਕੋਈ ਹੋਰ ਸੰਪਾਦਕ ਤੁਹਾਡੇ ਲਈ ਜਾਂ ਤੁਹਾਡੇ ਟੀਮ ਲਈ ਇਹ ਕੰਮ ਬਿਹਤਰ ਕਰਦਾ ਹੈ — ਨਿਰਦੋਸ਼ਤਾ ਨਾਲ ਉਸਨੂੰ ਚੁਣੋ. ਮਕਸਦ "Vim ਵਰਤੋਂ" ਨਹੀਂ; ਮਕਸਦ ਘੱਟ friction ਨਾਲ ਚੰਗਾ ਕੰਮ ਨਿਕਲਣਾ ਹੈ.
Vim ਸਿੱਖਣਾ ਤਦੋਂ ਟਿਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਕੁਝ ਭਰੋਸੇਯੋਗ ਆਦਤਾਂ ਬਣਾਉਣ ਵਜੋਂ ਲੈਂਦੇ ਹੋ — ਨਾ ਕਿ ਅਜਿਹੇ commands ਇਕੱਠਾ ਕਰਨ ਵਜੋਂ ਜੋ ਦੀਰਘਕਾਲ ਲਈ ਯਾਦ ਨਹੀ ਰਹਿੰਦੇ. ਲਕਸ਼੍ਯ ਇਹ ਹੈ ਕਿ ਸੰਪਾਦਨ ਕਰਨ ਵੇਲੇ ਸ਼ਾਂਤ ਅਤੇ ਸਮਰੱਥ ਮਹਿਸੂਸ ਕਰੋ, ਭਾਵੇਂ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ "ਤੇਜ਼" ਮਹਿਸੂਸ ਨਾ ਹੋਵੇ.
ਹਰ ਦਿਨ 10–15 ਮਿੰਟ ਦਿਓ, ਅਤੇ Vim ਨੂੰ ਇੱਕ ਅਸਲੀ ਕੰਮ ਲਈ ਵਰਤੋ (ਇੱਕ ਛੋਟਾ ਕੰਮ ਵੀ ਚੰਗਾ ਹੈ). ਨੋਟ ਲਵੋ ਕਿ ਕੀ ਅਜੀਬ ਲੱਗਿਆ ਅਤੇ ਕੀ ਠੀਕ ਮਹਿਸੂਸ ਹੋਇਆ.
Week 1: Comfort ਅਤੇ safety
ਫੋਕਸ ਫਸਣ ਤੋਂ ਬਚਣ 'ਤੇ. ਫਾਈਲ ਖੋਲ੍ਹਨਾ, ਸੇਵ, ਬੰਦ, ਅਤੇ undo ਕਰਨਾ ਅਭਿਆਸ ਕਰੋ.
Week 2: Navigation ਅਤੇ search
ਵੱਡੀਆਂ ਛਲਾਂ ਵਿੱਚ ਹਿਲਣਾ ਸਿੱਖੋ ਅਤੇ search 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਕਿਤੇ ਵੀ ਪਹੁੰਚੋ.
Weeks 3–4: Editing workflows
ਛੋਟੇ "edit + repeat" ਪੈਟਰਨ ਜੋੜੋ: change/delete/yank, . ਨਾਲ ਦੁਹਰਾਉ, ਅਤੇ ਇੱਕ ਬੁਨਿਆਦੀ macro ਉਸ ਚੀਜ਼ ਲਈ ਜੋ ਤੁਸੀਂ ਅਕਸਰ ਕਰਦੇ ਹੋ.
:w, :q, :wq, :q!, ਨਾਲ u (undo) ਅਤੇ \u003cC-r\u003e (redo)w, b, e, 0, $, gg, G, ਅਤੇ ਥੋੜ੍ਹਾ f{char}/pattern, n / N, ਅਤੇ :%s/old/new/g (ਪਹਿਲਾਂ flags ਬਿਨਾਂ ਅਜ਼ਮਾਓ)README ਠੀਕ ਕਰੋ: headings ਠੀਕ ਕਰੋ, bullet points reorder ਕਰੋ, ਅਤੇ ਇੱਕ paragraph ਬਿਨਾਂ ਮਾਊਸ ਦੇ ਦੁਬਾਰਾ ਲਿਖੋ.
ਇੱਕ ਛੋਟੇ ਫਾਈਲ ਨੂੰ refactor ਕਰੋ: ਇੱਕ variable rename ਕਰੋ search + replace ਨਾਲ, ਕੁਝ ਲਾਈਨਾਂ ਅਲੱਗ ਕਰੋ, ਅਤੇ re-indent ਕਰੋ.
Vim ਵਿੱਚ ਦਿਨਾਨੁਸ਼ਾਸਨ: ਹਰ ਰੋਜ਼ ਇੱਕ ਛੋਟੀ entry ਕਰੋ. ਦੁਹਰਾਉਣ ਸਿੱਖਣ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ.
"ਆਰਾਮ" (ਘੱਟ panic) ਅਤੇ "Consistency" (ਘੱਟ context switches) ਨੂੰ ਨਾਪੋ, ਸਿਰਫ਼ speed ਨੂੰ ਨਹੀਂ. ਜੇ ਤੁਸੀਂ ਅਣੁਮਾਨ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਕਮਾਂਡ ਕੀ ਕਰੇਗੀ — ਅਤੇ ਗਲਤ ਹੋਣ ਤੇ recover ਕਰ ਸਕਦੇ ਹੋ — ਤਾਂ ਤੁਸੀਂ ਉਹ ਹਿੱਸਾ ਸਿੱਖ ਰਹੇ ਹੋ ਜੋ ਲੰਮਾ ਚੱਲਦਾ ਹੈ.
Bram Moolenaar ਦਾ ਟਿਕਾਊ ਪ੍ਰਭਾਵ ਸਿਰਫ਼ ਇਹ ਨਹੀਂ ਕਿ ਉਸਨੇ Vim ਬਣਾਇਆ—ਬਲਕਿ ਉਸਨੇ ਇਹ ਮਾਡਲ ਕੀਤਾ ਕਿ ਧੀਰਜ ਨਾਲ stewardship ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਦਹਾਕਿਆਂ ਲਈ ਉਸਨੇ ਪੈਚ ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ, ਰਿਲੀਜ਼ਾਂ ਨੂੰ curated ਕੀਤਾ, ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੱਤਾ, ਅਤੇ ਇੱਕ ਸਾਫ਼ "ਅਹਿਸਾਸ" ਨੂੰ ਬਣਾਏ ਰੱਖਿਆ: ਕੁਸ਼ਲ, consistent, ਅਤੇ ਮਾਫ਼ੀ-ਯੋਗ ਜਦੋਂ ਤੁਸੀਂ ਇਸ ਦੀ ਗ੍ਰਾਮਰ ਸਿੱਖ ਲੈਂਦੇ ਹੋ.
Vim ਛੋਟੀਆਂ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ. ਵੱਡਾ ਸਬਕ ਕੋਈ ਖਾਸ ਕਮਾਂਡ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਮਨੋਭਾਵ ਹੈ: ਉਹ ਆਦਤਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰੋ ਜੋ friction ਘਟਾਉਂਦੀਆਂ ਹਨ. ਇੱਕ ਸੋਧ 'ਤੇ ਕੁਝ ਸਕਿੰਟ ਬਚਾਉਣਾ ਥੋੜਾ ਲੱਗਦਾ ਹੈ — ਜਦ ਤੱਕ ਉਹ ਡੀਫੋਲਟ ਤਰੀਕੇ ਨਾਲ ਸੋਚ ਬਣਦੀ ਨਾ ਹੋਵੇ. ਸਮੇਂ ਦੇ ਨਾਲ, ਸੰਪਾਦਕ ਉਸ ਚੀਜ਼ ਤੋਂ ਵੱਧ ਨਹੀਂ ਰਹਿੰਦਾ ਜੋ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ; ਇਹ ਉਹ ਮਾਧਿਅਮ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸ ਰਾਹੀਂ ਤੁਸੀਂ ਕੰਮ ਕਰਦੇ ਹੋ.
ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ "ਇਰਾਦਾ-ਪਹਿਲਾ" ਮਨੋਭਾਵ ਨਵੇਂ ਵਰਕਫਲੋਜ਼ 'ਤੇ ਵੀ ਵਧੀਆ ਟ੍ਰਾਂਸਫਰ ਹੁੰਦਾ ਹੈ. ਜੇ ਤੁਸੀਂ chat ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਸੌਫਟਵੇਅਰ ਬਣਾਉਂਦੇ ਹੋ — ਜਿਵੇਂ Koder.ai ਦੇ vibe-coding ਅਭਿਗਮ — ਉਸੇ ਆਦਤਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ: ਆਪਣਾ ਬਦਲਾਅ ਇੱਕ ਸਪਸ਼ਟ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਹੁਕਮ ਵਜੋਂ ਦਿਓ, ਛੋਟੇ ਟੁਕੜੇ ਵਿੱਚ ਇਤਰੈਟ ਕਰੋ, ਅਤੇ safety nets (ਉਦਾਹਰਨ ਲਈ snapshots ਅਤੇ rollback) 'ਤੇ ਨਿਰਭਰ ਕਰੋ ਨਾ ਕਿ ਇੱਕ ਵੱਡੇ ਖਤਰਨਾਕ rewrite 'ਤੇ.
Vim ਸਾਨੂੰ ਸੋਸ਼ਲ ਕਲਾ ਵੀ ਸਿਖਾਉਂਦਾ: ਪਬਲਿਕ ਵਿੱਚ ਸਿੱਖੋ, dotfiles ਸੋਝੀਦਾਰੀ ਨਾਲ ਸਾਂਝੇ ਕਰੋ, ਸਾਫ bug reports ਲਿਖੋ, ਅਤੇ ਨਵੇਂ ਆਏ ਲੋਕਾਂ ਨਾਲ ਧੀਰਜ ਰੱਖੋ. ਸਿਹਤਮੰਦ ਨਿਯਮ ਇਕ "ਕਠਿਨ" ਟੂਲ ਨੂੰ ਵੱਧ ਦੋਸਤਾਨਾ ਬਣਾਉਂਦੇ ਹਨ. ਜੇ ਤੁਸੀਂ ਹੋਰ ਗਹਿਰਾਈ ਵਿਚ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ built-in help ਅਤੇ community resources ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਹਨ, ਨਾਂ ਕਿ ਐਡ-ਆਨ.
ਇਸ ਲੇਖ ਨੂੰ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਵਰਕਫਲੋ ਬਦਲਾਅ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਇਸ ਹਫ਼ਤੇ ਕੋਸ਼ਿਸ ਕਰੋਗੇ: ਇੱਕ ਉਹ key remap ਕਰੋ ਜੋ ਤੁਸੀਂ ਬਾਰ-ਬਾਰ ਛੂਹਦੇ ਹੋ, ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਸੰਪਾਦਨ ਪੈਟਰਨ ਅਭਿਆਸ ਕਰੋ, ਜਾਂ ਆਪਣੇ vimrc ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਨਿੱਜੀ default ਲਿਖੋ.
ਅਖੀਰਤੋਂ, ਇੱਕ ਇਜ਼ਤਦਾਰ ਨੋਟ: ਓਪਨ-ਸੋਰਸ ਕਮਿਊਨਿਟੀਆਂ ਜਿਉਂਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ ਜਦੋਂ ਯੂਜ਼ਰ ਸਹਾਇਕ ਬਣਦੇ ਹਨ—ਦਾਨ, ਦਸਤਾਵੇਜ਼, ਧਿਆਨਪੂਰਕ issues, ਕੋਡ ਸਮੀਖਿਆ, ਜਾਂ ਸਿਰਫ਼ ਧੰਨਵਾਦ ਕਰਨ ਦੇ ਰਾਹੀਂ. Bram ਦੀ ਵਿਰਾਸਤ ਇਹ ਯਾਦ ਦਿਲਾਉਂਦੀ ਹੈ ਕਿ ਸਾਡੀਆਂ ਯੰਤਰਾਂ ਦੀ dekhbhaal ਕਰਨ ਵਾਲੇ ਲੋਕ ਟੂਲਾਂ ਤੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ।
ਐਡੀਟਰ ਸਭਿਆਚਾਰ ਉਹ ਸਾਂਝੀ ਆਦਤਾਂ, ਵਿਚਾਰਧਾਰਾਂ, ਸ਼ਾਰਟਕੱਟਸ ਅਤੇ mentorship ਰਿਵਾਜ ਹਨ ਜੋ ਕਿਸੇ ਟੂਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਦੇ ਹਨ.
Vim ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਸ ਵਿੱਚ "operator + motion" ਸੋਚ, pairing ਦੌਰਾਨ ਟਿਪਸ ਵੰਝਾਉਣਾ, ਅਤੇ configuration (ਜਿਵੇਂ vimrc) ਨੂੰ ਤੁਹਾਡੇ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਮੰਨਣਾ ਸ਼ਾਮਲ ਹੈ — ਨਾ ਕਿ ਕੋਈ ਬਾਕੀ ਚੀਜ਼।
ਮੋਡਲ ਸੰਪਾਦਨ ਦਿਓੜੀਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ: ਇਹ ਵੱਖ-ਵੱਖ ਅਰਾਦਿਆਂ ਨੂੰ ਅਲੱਗ ਰਾਜਾਂ ਵਜੋਂ ਵੇਖਦਾ ਹੈ।
ਇਸ ਨਾਲ ਅਕਸਮਾਤੀ ਸੋਧਾਂ ਘਟਦੀਆਂ ਹਨ ਅਤੇ ਬਦਲਾਵ ਉਸ ਵੇਲੇ ਹੀ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵੇਲੇ ਤੁਸੀਂ ਉਸਦਾ ਇਰਾਦਾ ਰੱਖਦੇ ਹੋ।
Vim ਦੀ “ਵਿਆਕਰਣ” ਕਮਾਂਡਾਂ ਨੂੰ ਭਵਿੱਖਬਾਣੀਯੋਗ ਬਣਾਉਂਦੀ ਹੈ: ਇੱਕ ਕਿਰਿਆ (ਜਿਵੇਂ delete/change/yank) ਨੂੰ ਇੱਕ ਨਿਸ਼ਾਨੇ (ਸ਼ਬਦ, ਵਾਕ, ਕਵੋਟਾਂ ਦੇ ਅੰਦਰ) 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.
Examples:
cw = ਇੱਕ ਸ਼ਬਦ ਬਦਲੋdi\" = ਕਵੋਟਾਂ ਦੇ ਅੰਦਰ ਹਟਾਓਤੁਸੀਂ ਕੁਝ ਮੂਲ ਧਾਰਨਾਵਾਂ ਸਿੱਖਦੇ ਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕਈ ਸਥਿਤੀਆਂ ਵਿੱਚ ਦੁਹਰਾਉਂਦੇ ਹੋ — ਹਰ ਸਥਿਤੀ ਲਈ ਅਲੱਗ-ਅਲੱਗ ਸ਼ਾਰਟਕੱਟ ਯਾਦ ਕਰਨ ਦੀ ਥਾਂ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕੋ ਕਿਸਮ ਦਾ ਬਦਲਾਵ ਵਾਰ-ਵਾਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ . ਵਰਤੋ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਵਰਕਫਲੋ:
. ਦਬਾਓ ਤा ਕਿ ਉਹੀ ਸੋਧ ਦੁਹਰਾਈ ਜਾਵੇ।ਇਹ ਤੁਹਾਨੂੰ ਸੋਧਾਂ ਨੂੰ ਸਾਫ਼, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ "ਚੰਕ" ਵਿੱਚ ਤਿਆਰ ਕਰਨ ਦੀ ਆਦਤ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜੋ ਅਕਸਰ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਹੈ।
Macros ਉਸ ਵੇਲੇ ਲਾਭਕਾਰੀ ਹਨ ਜਦੋਂ ਟੈਕਸਟ ਇਕਸਾਰ ਹੋਵੇ ਅਤੇ ਕਦਮ ਮਕੈਨੀਕਲ ਹੋਣ — ਉਦਾਹਰਣ ਵਜੋਂ ਇਕ prefix ਜੋੜਨਾ ਜਾਂ ਇੱਕੋ ਕਿਸਮ ਦੀ ਫਾਰਮੇਟਿੰਗ ਲਗਾਉਣਾ.
ਖ਼ਤਰਨਾਕ ਤਰ੍ਹਾਂ ਵਰਤੋਂ ਉਹ ਹੈ ਜਦੋਂ ਹਰ ਲਾਈਨ ਵਿੱਚ ਫੈਸਲੇ ਦੀ ਲੋੜ ਹੋਵੇ; macros ਤੇਜ਼ੀ ਨਾਲ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਸੌਖੇ ਨਾਲ ਨਜ਼ਰ ਨਹੀਂ ਆਉਂਦੀਆਂ. ਐਸੇ ਮਾਮਲਿਆਂ ਵਿੱਚ search + confirm ਜਾਂ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਦੁਹਰਾਅ ਵਰਤੋ।
vimrc Vim ਦੀ configuration ਫਾਈਲ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਆਪਣੇ defaults ਸੈਟ ਕਰਦੇ ਹੋ (indentation, ਲਾਈਨ-ਨੰਬਰ, search ਵਿਹਾਰ ਆਦਿ).
ਨਵੀਂਆਂ ਲਈ ਇੱਕ ਪ੍ਰਾਇਜਿਕਲ ਰਵੱਈਆ:
ਇਸਨੂੰ ਇੱਕ ਛੋਟੀ, ਪੋਰਟੇਬਲ "workbench" ਵਜੋਂ ਰੱਖੋ, نہ ਕਿ ਯਾਦ-ਅਣਯਾਦ tweaks ਦਾ ਇਕ ਢੇਰ।
ਇੱਕ ਸਧਾਰਨ ਬੇਸਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (indentation, search settings, line numbers, readable colors)। ਫਿਰ plugins ਓਦੋਂ ਜੋੜੋ ਜਦੋਂ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰ ਸਕੋ ਕਿ ਉਹ ਕਿਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ.
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇਕਰ ਕੋਈ plugin ਇਸ ਹਫ਼ਤੇ ਸਮਾਂ ਬਚਾਉਂਦਾ ਜਾਂ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਨਹੀ, ਤਾਂ ਉਸਨੂੰ ਅਗਲੇ ਹਫ਼ਤੇ ਲਈ ਰੱਖੋ। ਇਹ "config churn" ਨੂੰ ਅਸਲ ਸਿੱਖਣ ਅਤੇ ਉਤਪਾਦਕ ਆਦਤਾਂ ਦੀ ਥਾਂ ਬਦਲਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
SSH ਰਾਹੀਂ ਕਦੇ-ਕਦੇ ਵਰਤੋਂ ਲਈ ਇੱਕ ਛੋਟਾ "survival kit" ਬਹੁਤ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ:
Vim ਅਕਸਰ commit messages ਅਤੇ interactive rebases ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇੱਥੇ ਤੁਸੀਂ ਵਧੇਰੇ ਸਮਾਂ ਪੜ੍ਹਨ ਅਤੇ ਲਾਈਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਤਰਤੀਬ ਦੇਣ ਵਿੱਚ ਬਿਤਾਉਂਦੇ ਹੋ.
ਸਧਾਰਨ ਸੈਟਅਪ ਸਟੈਪ:
git config --global core.editor "vim"ਮੂਲ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ search commit ਟੈਕਸਟ ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਸੁਧਾਰ ਨੂੰ ਜ਼ਿਆਦਾ ਨਿਯੰਤਰਿਤ ਬਣਾਉਂਦੇ ਹਨ, ਬਿਨਾਂ ਮਾਊਸ ਦੇ।
Vim ਕੁਝ ਲੋਕਾਂ ਲਈ ਅਰਾਮਦੇਹ ਹੋ ਸਕਦਾ ਹੈ (ਘੱਟ ਮਾਊਸ ਯਾਤਰਾ), ਪਰ ਇਹ ਕਿਸੇ ਲਈ ਫਿੰਗਰਾਂ 'ਤੇ ਵੱਧ ਭਾਰ ਵੀ ਪਾ ਸਕਦਾ ਹੈ—ਹੱਥਾਂ, ਕੀਬੋਰਡ ਲੇਆਉਟ ਅਤੇ ਆਦਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.
ਸਥਾਈ ਵਰਤੋਂ ਲਈ:
ਸਭ ਤੋਂ ਵਧੀਆ ਵਰਕਫਲੋ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਦਰਦ ਤੋਂ ਬਿਨਾਂ ਜਾਰੀ ਰੱਖ ਸਕੋ।
i, Esc, :w, :q, :wq, :q!u, Ctrl-r/pattern, ਫਿਰ n/Nਮਕਸਦ ਭਰੋਸਾ ਅਤੇ ਵਾਪਸੀ ਯੋਗਤਾ ਹੈ, ਨਾ ਕਿ ਪੂਰਾ custom setup।