（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=41144843

标题：“VimTutor Sequel：高级 Vim 用户的扩展学习资源” 这篇文章介绍了 VimTutor Sequel，这是一个为熟悉基本操作的文本编辑软件 Vim 用户提供的补充学习资源。此附加材料旨在教授更高级的功能，例如拆分、拼写检查、高级搜索和替换、宏创建、Vim 脚本编写、插件安装、会话管理和寄存器使用。 VimTutor Sequel 包含分步教程，鼓励在学习概念时进行实际应用。定制的 Vim 配置可确保学习过程中的一致性，并反映初始 VimTutor 学习环境。要在 macOS 上安装 VimTutor Sequel，用户必须首先通过 Homebrew 输入帖子中提供的特定命令行来安装它。或者，Windows 和 Linux 上的用户可以克隆 VimTutor-Sequel GitHub 存储库，创建课程材料的副本，并使用自定义设置配置 Vim。我们鼓励反馈，无论是错误报告、改进建议还是一般评论的形式，因为建设性的意见有助于完善和改进教育内容。感兴趣的各方还可以通过相关的 GitHub 页面贡献或打开问题来参与该项目。最后，提供了主 GitHub 存储库和问题跟踪器/反馈论坛的链接。

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!

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

> 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:"?

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.

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.

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%.

> 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.

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.

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.

> 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.

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!

> If a tool is so simple that you don't need to learn anything about why does it matter how many people use it?

Are you saying there is no value in a tool having a large user base? The web and mobile app revolutions happened largely _because_ the software was accessible. If people needed to read manuals to learn how to use Facebook or TikTok, those projects never would've become popular. Microsoft and Apple built their empires on making operating systems easy to use. Obviously this is very valuable to many people.

If a tool is popular, it is more likely to be a sustainable income source for its authors, and thus more likely to continue to exist. Everyone benefits from that.

> 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.

A community doesn't just exist to discuss how to use a piece of software. It may consist of enthusiasts, discussions about program features or changes, value added services, etc. Besides, a community about the software itself is not required for it to be successful. Software can be popular just because people enjoy using it, and what it allows them to do.

> Perhaps you were thinking ubiquity.

No, I wasn't. I'm just saying that accessibility and ease of use are large factors in how popular a piece of software can be. Vi(m) had very humble beginnings and its growth was gradual over several decades. Yet it still pales in popularity compared to something like VS Code (see the Stack Overflow Developer Survey). Why do you think that is? Do you think Vim or Emacs will ever make it to the top of that list? What would need to happen for that to happen?

I'm not saying that chasing that metric is important. But there's safety in numbers.

Not following your argument. You start by talking about tools with a network effect which is totally irrelevant for something like a text editor (assuming it supports common formats like utf-8). Then you talk about tools being simple to use making them popular, which I never disputed.

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.

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...

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.

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.

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.

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.

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)

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.

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.

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.

I feel like vim is one of those things that requires dedicated time investment: "learn by doing" << "learn then do" in this case. I say this as I have been in the former category for too long. I'll definitely bookmark this link.

（评论） (comments)

（评论）
(comments)