I went through the beginnings of Vim to give you a starting point and some basics in the event you have no experience in the Vim world. One would assume that since you\u2019re on a Puppet\/Dev-Ops-y sort of page, all this is old news, but we do have completely \u201cgreen\u201d readers from time to time, and I didn\u2019t want to leave them out.<\/p>\n\n\n\n
The main goal in getting Vim in the picture was to bring you to the point where we start looking at our code and knowing what we\u2019re dealing with at a glance. As you begin to work in the field, whether coding in Perl, Python, Shell, or the Puppet DSL, there are some conventions out there all designed to help you and smooth your workflow. Of these is syntax highlighting in code editors in general, but (for our purposes) in Vim specifically.<\/em><\/p>\n\n\n\n Take a look at this screen:<\/p>\n\n\n\n While the code is well formatted and everything seems ok, were there any issues in this document, you\u2019d never know it. From syntax issues to missing elements, none of this is automatically highlighted to you in any way. Enter syntax highlighting\u2026 Look again:<\/p>\n\n\n\n Much nicer, no? Were there any missing elements, you\u2019d see something amiss in the document. The colors would not be organized according to element type, and odd things would be displayed in the page. Let me \u201cbreak\u201d the file for you\u2026<\/p>\n\n\n\n You\u2019ll notice that on line 4 something is amiss. If you compare the two colored instances, you\u2019ll see that your eye is drawn to where things begin to be different. Best part for quick and easy glancing is that the entirety of the file after that one mistake now looks \u201cwrong\u201d. Ease of view.<\/p>\n\n\n\n How Can This Help With Puppet?<\/strong><\/p>\n\n\n\n As luck would have it, Vim has a plugin engine that allows you to have pre-built templates that syntax highlight code for you in a predetermined way. It \u201crecognizes\u201d your code type, and highlights accordingly. The basic plugin structure for vim lives in your home directory and in the \u201chidden\u201d .vim directory. Under this directory you can have a number of wide and varied add ons to vim. We\u2019re just going to talk about plugins.<\/p>\n\n\n\n By default, you don\u2019t have anything in this directory. You usually have a .vimrc file and a .vim directory in your home directory location, but that\u2019s about it. The \u201cmagic\u201d happens, though, when you add a few pieces. Those would include a \u201c.vimrc\u201d file which will turn on syntax highlighting, and then a Puppet vim plugin that sorts all the language elements and colorizes them for you.<\/p>\n\n\n\n In your home directory, if it doesn\u2019t already exist, create a .vimrc file with a single entry:<\/p>\n\n\n\n syntax on<\/strong><\/p>\n\n\n\n This will instruct vim to syntax highlight, and to be aware of any highlighting plugins that may live in the .vim plugin folder. Next, place this file<\/a> into your .vim plugin directory. If it does not yet exist, create it. It lives in ~\/.vim\/plugin. Once you load up new puppet manifests, it will recognize the type and begin to highlight the code according to the defined convention from the puppet.vim file you just downloaded. If you have any issues, look at the vim plugin reference here<\/a>.<\/p>\n\n\n\n Now you\u2019re ready to work with Puppet files like a pro!<\/p>\n","protected":false},"excerpt":{"rendered":" As we move on through the last post on Vim, you may ask yourself why I\u2019m remediating all the way back to text editors. Well, as you\u2019ll see over time, this is all about workflow; Building yourself a detailed workflow by which you can write code, syntax check, commit to revision control, deploy to your […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[6],"tags":[],"class_list":["post-262","post","type-post","status-publish","format-standard","hentry","category-technology"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/comments?post=262"}],"version-history":[{"count":1,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/262\/revisions"}],"predecessor-version":[{"id":263,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/posts\/262\/revisions\/263"}],"wp:attachment":[{"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/media?parent=262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/categories?post=262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/questy.org\/index.php\/wp-json\/wp\/v2\/tags?post=262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/i0.wp.com\/questy.org\/wp-content\/uploads\/2024\/08\/nosyn.png?resize=900%2C679&ssl=1\")
<\/figure>\n\n\n\n<\/figure>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/questy.org\/wp-content\/uploads\/2024\/08\/broke.png?resize=900%2C679&ssl=1\")
<\/figure>\n\n\n\n