Re: sort in .tsv file

[dva...@internode.on.net]

On 17.11.25 17:30, Tim Chase wrote:

> On 2025-11-17 21:54, Vim Users wrote:

> > the /pattern/ feature of sort doesn't work if the recognized filetype

> > is .tsv (which gives alternate colours for successive fields).

> >

> > Is there a workaround, apart from copying it to a plain file and

> > working on it there?

>

> I'm not sure if you have some plugin interfering, but when I open a TSV

> file with the following contents:

>

>     $ cat test.tsv

>     h1 h2 h3 h4 h5

>     d  c  b  a  1

>     c  d  a  b  30

>     b  a  d  c  4

>     a  b  c  d  200

>

> I can issue the following commands to sort by the various columns:

>

>   :2,$sort  " sort by the first column

>   :2,$sor /[^^I]*^I/   " sort by the second column

>   :2,$sor /\([^^I]*^I\)\{2}/ " sort by third column

>   :2,$sor /\([^^I]*^I\)\{3}/ " sort by the fourth column

>   :2,$sor n /\([^^I]*^I\)\{4}/ " sort numerically by the fifth column

>

Despite having used Vim for several decades now, I'm still allergic to the effort to make Vim into Emacs, by doing stuff in-house in cases where it's much easier to just use what's already provided on any *nix distro. To perform those four sorts in Vim, with fewer keystrokes, this works for me:

Place the cursor on the first line after the column headings, then:

!}sort -k 1

Then hit 'u' for Vim undo, and:

!}sort -k 3

or whatever field you now want.

And without the undo, we've done a compound sort.

The "sort" manpage describes the various available sort criteria: dictionary, numeric, month, etc.

A "man -k sort" in another shell reveals alternative sorts you might have on hand.

Equally important, I feel, is that only one sort syntax and behaviour needs to be learnt for all common uses on the computer, whether in Vim, in commandline pipes, or shell scripts. Why buy into unnecessary brain fragmentation?

Erik

[Tim Chase]

On 2025-11-18 00:32, Vim Users wrote:
> On 17.11.25 17:30, Tim Chase wrote:

> >???? :2,$sort?? " sort by the first column
> >???? :2,$sor /[^^I]*^I/???? " sort by the second column
> >???? :2,$sor /\([^^I]*^I\)\{2}/ " sort by third column
> >???? :2,$sor /\([^^I]*^I\)\{3}/ " sort by the fourth column
> >???? :2,$sor n /\([^^I]*^I\)\{4}/ " sort numerically by the fifth column
>
> !}sort -k 1

Even better! At least as long as you're on a Unix-like system where
sort(1) is competent (its availability on Windows is a bit less useful)

-tim
--

[dva...@internode.on.net]

Hi Tim,

That's what I suspected, but having not used the MS OS or their other products in 30 years in IT, or privately this last half century, I didn't feel competent to comment there. My suggestions are, though, hopefully unixversal.  ;-)

Erik

[c.willis111]

-- 
Thanks for the responses.

 

Tim, I think it is the ,csv plugin that is interfering. Also, I don't understand the significance of your "^|". Though it is reminiscent of the | that the .csv plugin inserts for the tabs (in the screen view).

 

I have a field that always (in the area I am interested in, starts with 1, so I was using the pattern /\t1/. I did try /.*\t1/ which failed the same.

 

Dvalin - at present, (but not for long) on windows. The vim sort seems to do the job properly whereas the Windows sort case ignores regardless, and doesn't have the unix flexibility.

 

thanks both - Chris

[Christian Brabandt]

On Di, 18 Nov 2025, dvalin via vim_use wrote:

> Despite having used Vim for several decades now, I'm still allergic to
> the effort to make Vim into Emacs, by doing stuff in-house in cases
> where it's much easier to just use what's already provided on any *nix
> distro. To perform those four sorts in Vim, with fewer keystrokes,
> this works for me:

While that is true, it doesn't help anybody who doesn't have GNU
coreutils installed. That's the reason the :sort command was added to
Vim.

Thanks,
Christian
--
Microbiology Lab: Staph Only!

[Marc Chantreux]

hello,

On Tue, Nov 18, 2025 at 11:22:40AM +0100, Christian Brabandt wrote:
> On Di, 18 Nov 2025, dvalin via vim_use wrote:
> > Despite having used Vim for several decades now, I'm still allergic to
> > the effort to make Vim into Emacs, by doing stuff in-house in cases
> > where it's much easier to just use what's already provided on any *nix
> > distro. To perform those four sorts in Vim, with fewer keystrokes,
> > this works for me

that's why vim9 is so important: ! ( <range>! , w! r! ...), jobs and
channels, system(), libcall() and the ed inspiration remaining in the
vim9script with the new braces driven :command syntax is wonderful.
those make vim the only modern editor with the unix philosophy roots
(with others instead of becoming fat)

that's the main difference with neovim (the emacs of the ones who
started with vim). a better neovim is emacs over racket + a viper mode
that takes vim ergonomy (text objects and so on) more seriously but they
ends with vim+lua.

> While that is true, it doesn't help anybody who doesn't have GNU
> coreutils installed.

that's untrue: BSD tools (also available on macos), sbase, 9base,
busybox are that capable too. Yes, windows people are screwed but they
chosen their destiny :)

also: zsh (also default on macos too) is a much much better bash which
is really easy to combine with vim because of details like the twigil
for expansions (so you don't have to quote things when you !).

once you add your suffixes aliases in your ~/.zshenv, you can use
:!<cfile> or :!<cWORD> to open urls and files. at home I have

@ (
{fr,de,com,org,net,re,ninja}=url_opener
{git,gh}=git:latest
{wad,pk3}=wador
{png,gif,jpg,jpeg,bmp,tiff,tga,webp}=feh
{docx,xlsx,odt}=libreoffice
{html,svg}=chromium
{xcf}=gimp
{1..8}{,posix,plan9,p}=man
{ps,eps,pdf,djvu}='(){
>> ~/.was-read realpath "$@"
zathura "$@"
}'
{wav,mp3,ogg,flac,opus,mp4,mkv,webm}='(){
>> ~/.was-play realpath "$@"
vlc "$@"
}'
) alias -s $it

most of my "plugins" are just thin wrappers over tools I wrote to be
used outside vim so vim is just another environement to interact with a
global workflow

> That's the reason the :sort command was added to Vim.

And that makes the codebase bigger, more maintainance to do, more
possible vulnerabilities.

will you also implement awk ? I hope not and it doesn't stops me to have
a plugin that make vim looks like a spreadsheet

https://git.unistra.fr/mc/dot/-/blob/main/vim/pack/_/start/tsv/ftplugin/tsv.vim

based on few lines of viml + an awk script

https://git.unistra.fr/mc/dot/-/blob/main/vim/r/setvts.vim
https://git.unistra.fr/mc/dot/-/blame/main/bin/tsveverything?ref_type=heads#L190

not to mention :so now support ranges \o/

Actually I think vim does too much things and The *only* feature I miss
today is a global PreSystem autocommand so you can setup environement
variables.

au SystemPre {
$cf = expand("<cfile>")
$cF = expand("<cFILE>")
$cf = expand("<cword>")
$cF = expand("<cWORD>")
}

so I have to prefix ! and system() calls myself.

Again (because it was the goal of this mail): vim, in its actual
philosophy, is super important! Thanks a lot for maintaining it.

Marc

--
Marc Chantreux

[dva...@internode.on.net]

On 18.11.25 13:38, Marc Chantreux wrote:

> And that makes the codebase bigger, more maintainance to do, more

> possible vulnerabilities.

>

> will you also implement awk ? I hope not and it doesn't stops me to have

> a plugin that make vim looks like a spreadsheet

>

> https://git.unistra.fr/mc/dot/-/blob/main/vim/pack/_/start/tsv/ftplugin/tsv.vim

>

> based on few lines of viml + an awk script

>

> https://git.unistra.fr/mc/dot/-/blob/main/vim/r/setvts.vim

> https://git.unistra.fr/mc/dot/-/blame/main/bin/tsveverything?ref_type=heads#L190

Now, if vimscript were mostly awk, then we'd have the ultimate editor. :-) (My spreadsheeting has not yet gone beyond including a line of awk in a data table file, then executing that with a Vim-mapped keystroke, or e.g. for rainfall, doing the awk monthly totalling in the shell-aliased editing command, so it runs on exit.)

> not to mention :so now support ranges \o/

>

> Actually I think vim does too much things and The *only* feature I miss

> today is a global PreSystem autocommand so you can setup environement

> variables.

>

>  au SystemPre {

>     $cf = expand("<cfile>")

>     $cF = expand("<cFILE>")

>     $cf = expand("<cword>")

>     $cF = expand("<cWORD>")

>  }

>

> so I have to prefix ! and system() calls myself.

>

> Again (because it was the goal of this mail): vim, in its actual

> philosophy, is super important! Thanks a lot for maintaining it.

Enthusiastically seconded. There's nothing else as good. All the folding methods are brilliant, for example. A .vimrc tweaked over a number of decades makes life so much easier. (My only remaining wish would be Posix ERE regexes - the existing mish-mash of alternatives in Vim seems a lot of work and confusion, without quite getting there. Admittedly, \v comes close. And one just shells out to awk, when serious, anyway.)

Erik

[Marc Chantreux]

hello,

On Thu, Nov 20, 2025 at 05:24:20AM +0000, dvalin via vim_use wrote:
> [3]https://git.unistra.fr/mc/dot/-/blame/main/bin/tsveverything?ref_type=heads#L190

> Now, if vimscript were mostly awk, then we'd have the ultimate editor. :-)

Actually not :) awk is cool but

* its built in functions can be called with, user defined functions need parenthesis
* ithas no lambdas
* its array subscripts and datastructures are really limited
* it as no do (like in lisp or perl)
* ...

The viml of my dream is a mix of Raku (https://raku.org/) and viml itself.
the reason I wouldn't use neovim at all is because of the vim commands
you can directly use in viml like

:1
'a,34d

The problem is: Raku is huge. Maybe it's tunable enought to include vim
commands as slang (https://docs.raku.org/language/slangs)? IDK

but a raku+viml alien +

> > not to mention :so now support ranges \o/

would be the ultimate scripting langage (or maybe not: people from the APL
world have things to say about concision and readability. https://www.uiua.org/
seems impressive but I have no time to practice).

> > Again (because it was the goal of this mail): vim, in its actual
> > philosophy, is super important! Thanks a lot for maintaining it.

"actual" wasn't the good word: the *current* philosophy.

> decades makes life so much easier. (My only remaining wish would be Posix
> ERE regexes - the existing mish-mash of alternatives in Vim seems a lot of
> work and confusion, without quite getting there. Admittedly, \v comes
> close. And one just shells out to awk, when serious, anyway.)

Vim needs its own regexp engine because of patterns like

|/\%V| \%V \%V inside Visual area |/zero-width|
|/\%#| \%# \%# cursor position |/zero-width|
|/\%'m| \%'m \%'m mark m position |/zero-width|
|/\%l| \%23l \%23l in line 23 |/zero-width|
|/\%c| \%23c \%23c in column 23 |/zero-width|
|/\%v| \%23v \%23v in virtual column 23 |/zero-width|

I made my time to be confortable with it but now I'm really happy about
the vim regexp system now (I don't know how huge it is to maintain). I can
compare with grep: RE is the default but

ERE litteral insensitive
grep -E -F -i
vim \v \M \c

so I have

nnoremap / /\v
nnoremap ? ?\v

because

* most of the time, I want \v but sometimes I <del>M
* easier to remove \v (to come back to normal) than to type \v

to learn the basics of the syntax (when you have previous regexp
pexperience):

:h perl-patterns
:h /magic # the array comparing the syntaxes is very useful
:h /ordinary-atom

coming from perl and raku, I am sometimes frustrated (mostly because
there is no \x (like the //x) so we can write much more maintainable
regexps but things like M %% S (list of Ms separated by S) is also
really useful) but vim has some gems too like

\zs and \ze to start/end the match
\%[] : a sequence of optionally matched atoms

regards

--
Marc Chantreux