Item — HN Reader

> sorting and reversing over motion

Vim can run shell commands as filters over selections as well.

Although vim does provide its own `:sort`, you can also sort the current selection like

  v{motion}!sort

Which uses the external sort command (coreutils)

For reversing,

  v{motion}!tac

Which uses `tac` to reverse the order of the lines.

This general concept is quite useful in many other ways, since it is quite universal - selection goes to stdin of arbitrary program, stdout of that program replaces selection.

For example, if you want to quickly test a function that takes a json string, and you're in a language where instantiating good mock objects and serialising it takes quite a bit of code, you can quickly make a mock by writing JS code within the string quotes and have the code console.log json and then `vi'!node` will replace it there.

3 comments

This is very powerful. Unfortunately, as an Ex command, `!` only works on full lines. One can of course also teach vim to operate `!` over any motion (or visual selection), whether it is part of a line, a full line, or a block https://vi.stackexchange.com/a/46304/48750.

I also have a plugin that has commands for this https://github.com/robenkleene/partshell.vim?tab=readme-ov-f...

There's `Psh` that pipes part of a line through a shell command, and `P` which takes any `ex` command and does the same (this means `P !` is the same as `Psh` but the latter supports tab completion for shell commands).

It always infuriates me how well nano handles this out of the box as opposed to vim. I don't see any reason why this shouldn't be the default. If you're in visual mode and want the whole-line behavior, it takes just 1 extra key press (V).

What if those external utilities are not available? Which might very well be the case if you run Vim on Windows.

It is better to have atleast some fall back capabilities(for searching across files, searching within files, sorting etc) build in.

I don’t think that effort is necessary.

The author likely has git, which provides a userland. And she/he is talking about gvim.exe, so is not restricted in what she/he can choose to install, and by now, might be using nvim-qt.exe.

https://www.msys2.org/

Edit: just realized it always posed itself as a “building platform”, lol. It really is a full-blown GNU system that works on windows. As in GNU/Linux, but there’s no linux kernel. All the /usr/bin tools are there, including pacman as a package manager (from Arch). You can install virtually everything from there.

Now you need a whole userland to get basic functionality of the editor. Who will vett the correctness and suitability and efficiency of the 3rd party user-land?

Notwithstanding that the third party userland is possibly not necessarily, since the windows userland most likely has all the features needed for Vim to make these functionalities work.

Since the editor is intended to be a multi-plaform product, it is better if atleast a windows userland based mechanism could be provided on windows platform, if the mechanisms could not be achieved through an inbuilt platform-agnostic manner.

What if you need a "portable" ( in the windows sense of the term, it means that the program can be used without need for an installation process) version of the editor?

I think it all is a huge time sink on the end user, who would instead get some usefull progress done on their projects.

Agreed, ideally a multi-platform editor should include all the features an OS might have, or at least use a compatibility layer that equalizes all functionality and paradigms over all supported platforms.

If you do dev on windows you should mostly use WSL.

I think experienced windows devs would use and recommend windows libs/userland over WSL.

May because WSL becomes a huge dependency and many windows boxes don't have it installed, whereas windows userland is always available.

I'm a Linux guy. Have had that as my primary OS for over twenty years.

At work, though, I've been doing dev work primarily in Windows for over a decade.

Never needed WSL.

(Maybe because I use Emacs? I dunno)

Emacs suffers some on windows too, because it also depends on external utilities for some functionality. For example grep-find depends on external grep program which is not bundles in, and on windows, the operation will simply fail.

I use `:'<,'>!html-to-m` to convert arbitrary html snippets into mithril.js m() hyperscript.