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!
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
Did you start the submission title with: "Show HN:"?
After learning this valuable lesson, I proceeded to learn to use Emacs.
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.
Why is that? If a tool is so simple that you don't need to learn anything about why does it matter how many people use it? There won't be a community for it because there's nothing to say. That would be learning about said tool which is the very thing we're trying to avoid.
Perhaps you were thinking ubiquity. But, in fact, the most ubiquitous text editor is probably vi/vim!
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%.
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.
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...
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.
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.
This looks very cool! Vimtutor was great fun when I did it. Thanks to the author.
