[HN Gopher] I Made an Extended Version of Vimtutor - Introducing...
___________________________________________________________________
I Made an Extended Version of Vimtutor - Introducing Vimtutor
Sequel
Author : micahkepe
Score : 176 points
Date : 2024-08-03 05:29 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| micahkepe wrote:
| Hey everyone,
|
| It looks like my submission redirected to the GitHub repo instead
| of displaying the full context. Here's the detailed information
| about Vimtutor Sequel:
|
| ---
|
| Hey Hacker News community,
|
| I'm excited to share something I've been working on - Vimtutor
| Sequel!
|
| After going through the original vimtutor, I felt there was a
| need for an extended tutorial for some more advanced topics not
| covered in the original tutor program.
|
| What's Vimtutor Sequel?
|
| Vimtutor Sequel picks up where the original vimtutor left off.
| It's designed for those who already know the basics and are ready
| to dive into more advanced Vim features and commands.
|
| Key Features:
|
| - Advanced Topics: Dive into splits, spellcheck, advanced search
| and replace, macros, Vim scripting, plugins, sessions, and
| registers. - Step-by-Step Tutorials: Hands-on lessons that
| encourage you to practice commands as you learn. - Custom Vim
| Configuration: Comes with a custom vimrc to ensure a consistent
| learning experience and mimic the original vimtutor.
|
| How to Install:
|
| For Mac: To get started, install Vimtutor Sequel using Homebrew:
|
| ```bash brew tap micahkepe/vimtutor-sequel brew install vimtutor-
| sequel ```
|
| Then you can run with: ```bash vimtutor-sequel ```
|
| For Windows/Linux:
|
| 1. Clone the repository: ```bash git clone
| https://github.com/micahkepe/vimtutor-sequel.git ``` 2. Navigate
| to the repository: ```bash cd vimtutor-sequel ```
|
| 3. Make a Copy of the Tutorial: ```bash cp vimtutor-sequel.txt
| vimtutor-sequel-copy.txt ```
|
| 4. Run Vim with the Custom Configuration: ```bash vim -u
| vimtutor-sequel.vimrc vimtutor-sequel-copy.txt ```
|
| Looking for Feedback!
|
| I'd love to hear what you think! Whether you spot any bugs, have
| suggestions for new lessons, or just want to share your thoughts,
| your feedback is really appreciated. Feel free to contribute or
| open issues on the GitHub repo.
|
| Links:
|
| GitHub Repository: https://github.com/micahkepe/vimtutor-sequel
| Issues & Feedback: https://github.com/micahkepe/vimtutor-
| sequel/issues Thanks for checking it out, and I hope you find it
| useful in your Vim journey. Happy Vimming!
| mettamage wrote:
| Awesome! When someone on HN years ago pointed me to vimtutor to
| oearn vim it was like magic!
|
| After many false starts, I now was able to use vim!
|
| I've never learned more than that as I am a casual user.
| Because of that tutorial I am happy to say that I can be a user
| at all.
|
| I'm stoked for a follow up :D
| abrenuntio wrote:
| I'm looking forward to going through this... thank you so much!
| 3abiton wrote:
| As a long time vim user, respect.
| e12e wrote:
| > It looks like my submission redirected to the GitHub repo
| instead of displaying the full context.
|
| Did you start the submission title with: "Show HN:"?
| micahkepe wrote:
| No sorry I didn't this is actually my first post on here so
| still learning the platform.
| globular-toast wrote:
| Learning vim was what convinced me that it's worth your time to
| learn tools. Far too many tools present themselves as "no manual
| required". It would almost be laughable for a phone app to
| require reading a manual, for example. But even developers these
| days refuse to read and just expect it to be obvious. What you
| end up with is VS Code, some of the good parts of vim, but still
| so far from what's possible if you spend the time to really learn
| your tools.
|
| After learning this valuable lesson, I proceeded to learn to use
| Emacs.
| imiric wrote:
| For me it's not so much about the process of learning itself.
| To be honest, I'd rather avoid having to learn how a tool works
| to use it. Software that prioritizes ease of use and
| friendliness has a much broader appeal--and, consequently, user
| base--than those that don't. There's value in that.
|
| I chose to learn Vim, Emacs and other tools with a steep
| learning curve primarily because of their return on investment.
| They have great extensibility, so I can customize them exactly
| to my liking. I know that they won't radically change, or
| worse, disappear in a few years, as a lot of software does. So
| taking the time to learn how to use them is purely a selfish
| endeavor. I even put up with their quirks and shortcomings
| because of this, even though there might be alternatives that
| do feature X better, are faster, etc. Using these tools simply
| minimizes the chances I'll have to re-learn something else
| every few years. I'd rather avoid that.
| SanderNL wrote:
| Developer productivity is not and never was bottlenecked by
| their tools.
|
| One snap of the fingers in one of the many layers above us
| and million dollar projects succeed or fail. We are always a
| fancy dinner or business relation gone sour away from success
| or failure.
|
| Vim or emacs come into play at layer 245 in the system and
| their impact on the final business reality is approximately
| 0,003%.
| globular-toast wrote:
| > Vim or emacs come into play at layer 245 in the system
| and their impact on the final business reality is
| approximately 0,003%.
|
| Who cares? One fire or war and a carpenter's work all comes
| crumbling down. Should he then not care about his work or
| his tools or materials and nail any old shit together? Life
| is what happens when you're busy making other plans.
| SanderNL wrote:
| Who cares? Those who measure actual impact instead of
| showing off.
|
| Focus on what matters is my only advice. Hint: it's not
| your editor.
| layer8 wrote:
| For many, the editor is the software that they spend the
| most time using. It certainly matters knowing how to use
| it well.
| freedomben wrote:
| Sure, sometimes higher layers end up killing a project
| before it ships. But there is still a lot of code that
| ships. For that code, the editor choice may have
| mattered. I have shipped a lot of code in my day, and
| since learning vim I have been much more productive.
| There are projects that may not have even existed were it
| not for Vim, because I would not have had time to get it
| done in the tight deadline needed.
|
| But more importantly, I like Vim. It makes me enjoy the
| process much more. I do carpentry in my spare time, and I
| think of them much like I do my favorite carpentry tools.
| While they do enable some projects that otherwise
| couldn't have happened, most of the time their impact is
| just improving my experience and quality of output. That
| matters a great deal to me, regardless of whether it
| matters several layers up.
| globular-toast wrote:
| You can talk all day about high-level actions and wishes
| but, at the end of the day, someone needs to write some
| code. That's me. That's what I do. It matters.
| fragmede wrote:
| just because the project got cancelled and won't ship
| doesn't reduce the rate of developer productivity on the
| project though. it sucks when your code won't ship, but the
| craftwork imbued in the source is still there.
| worldsayshi wrote:
| I am now learning vim but I postponed it for the longest time
| because learning Emacs thought me the opposite lesson. For me
| learning Emacs, although it was often enjoyable, did not feel
| worth it in the long run because I kept running into
| configuration hell. Switching back to an IDE made me realize
| that I'd rather not waste half my time getting my environment
| to work.
|
| But I'm giving neovim a chance now. I feel one part excitement
| for upgrading my developer UX and one part dread of getting
| stuck in endless rabbit holes.
| christophilus wrote:
| Keep your config minimal and learn the built in way of doing
| things first. If you do that, you don't end up spending too
| much time on rabbit trails. I use the default color scheme,
| telescope, and an autocomplete plugin. That's about it, and
| it's great. My config is a single file.
| karolist wrote:
| I think the problem is due to people coming to Vim after
| they've used an IDE and want an IDE like experience, that's
| how you end up with Lua module tracelogs when you open nvim
| and spend time fighting the tools rather than using them. I
| too went though that phase but in the end I realized that I
| actually just enjoy vim motions, if I have them in my IDE
| it's already good. I'm back to Intellij with ideavim plugin
| and it's been great so far. I know things like lazyvim made
| the setup more manageable but I've never tried it.
| pbronez wrote:
| I've started using VIM because the key bindings are available
| in many other places. I'm not leaning into advanced
| configuration, just muscle memory for core actions.
| robinsonrc wrote:
| Helix is definitely worth a look if you'd like to minimise
| the time you spend configuring things. It's not as ubiquitous
| as Vim et al of course but that may not be an issue for you
| (it certainly isn't for me)
| cfiggers wrote:
| I often see people disparage VS Code while championing
| vim/Neovim as editors that reward the effort invested to
| "really learn." I wonder how many have taken the time to
| "really learn" VS Code. It also is a tool, which means like any
| other it too rewards R'ing TF(riendly)M.
|
| I use both VS Code and Neovim, more or less interchangeably.
| I'm at a level now with VS Code where if a feature isn't
| exactly what I want or doesn't exist for a given language, I
| can roll a bespoke extension that scratches that random itch
| given ~45 minutes (for straight-forward stuff, longer the more
| involved things get). I'm not quite there (yet) with
| Neovim/Lua, so weirdly _for me_ VS Code is the more easily
| malleable of the two.
| micahkepe wrote:
| I fully agree, at the end of the day whichever tool makes you
| the most efficient/excited to code is the best tool for you.
| I am still transitioning from VSCode to Neovim and I can
| definitely relate to VS Code feeling more easily malleable.
| zaidhaan wrote:
| I too share your sentiment about VS Code. Its extension
| API[0] is extensive and approachable, often with examples[1]
| for each API.
|
| Just a small anecdote: At work, I found it frustrating not
| being able to quickly locate where views for Django API
| endpoints were, so I wrote a simple extension that took the
| output of django-extensions' show_urls, parsed it, and
| displayed a quick pick list of all API endpoints, upon which
| selecting an endpoint would open the file and reveal the
| exact line in which the view for it was defined.
|
| Implementing this did not take much effort (in fact,
| TypeScript and JSDoc make everything a lot simpler as it's
| clear to see what each function in the API does and what
| arguments they accept), and now this is something I use
| almost every day and greatly improves my satisfaction when
| navigating the codebase if not my productivity in general.
|
| I have tried looking into implementing something similar in
| Neovim and came across the API for telescope.nvim[2], but
| found it a lot less intuitive to use. I do think Vim/Neovim
| shines when it comes to text manipulation and extensions
| built around it, but when it comes to more complex UI that
| often deals a lot more with graphical elements (e.g. tree
| views, hover text, notifications), it's hard to beat VS Code.
|
| [0]: https://code.visualstudio.com/api/references/vscode-api
|
| [1]: https://github.com/microsoft/vscode-extension-samples
|
| [2]: https://github.com/nvim-
| telescope/telescope.nvim/blob/master...
| weaksauce wrote:
| there is a vscode extension for neovim... works quite well
| simonmysun wrote:
| I had exactly the same experience: I learned vim and started
| enjoying reading the manual, and then I started to use emacs.
| Unfortunately, the number of emacs users around me is fewer and
| fewer. To be precise, there is no one using emacs in my daily
| social circle anymore. I no longer hear people arguing whether
| vim or emacs is better, and have to solve any problem I met in
| emacs myself.
|
| Apps nowadays don't need a manual because they have very low
| density of information and very low density of functions.
| Engineers who refuse to maneuver anything without reading the
| manual first becomes rare. This is not completely bad because
| it means the living condition of engineers improved.
| alabhyajindal wrote:
| Very well done! Congrats!
| micahkepe wrote:
| Thank you so much I appreciate it!
| nodra wrote:
| Will definitely try this. Thank you!
| sourcepluck wrote:
| Does anyone know of something similar for Emacs - a sequel to the
| Emacs tutorial? I have flirted mentally with the idea of doing
| one, even spun up a few notes planning it out.
|
| This looks very cool! Vimtutor was great fun when I did it.
| Thanks to the author.
___________________________________________________________________
(page generated 2024-08-03 23:00 UTC)