Rebbe Malachi: 2025

Friday, November 21, 2025

Re: inoremap and typing pace?

Hi Marc,

On Thu, 17 Apr 2025 10:07:41 +0200 Marc Chantreux wrote:

> hi Steven,
>
> I just realized I haven't replied this one. I read it but I'm in rush
> time for the moment so I'll investigate later.

It has been a few months, so I thought I should probably ask again.
Did you you have the time to have a look at this?

Thank you.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/20251121134614.7947149d%40localhost.

Thursday, November 20, 2025

vim regexps and ERE and viml syntax

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

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aR7PjvlSStF3-I-I%40prometheus.

Wednesday, November 19, 2025

Re: sort in .tsv file

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

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/459bf14d-697e-41dc-926b-d1f0535cb5c7%40localhost.

Tuesday, November 18, 2025

Re: Re: Re: :sort in .tsv file

Subject: Re: :sort in .tsv file
On Mo, 17 Nov 2025, 'c.willis111 ' via vim_use wrote: > the /pattern/ feature of sort doesn't work if the recognized filetype is > .tsv (which gives alternate colours for successive fields). What exactly do you mean by this? Thanks, Christian --

Hi Christian

I have the .csv plugin.

When I use the pattern in the vim :sort command, it does not work as expected.

I was mistaken in an earlier message. I am sure this is due to the plugin. If I copy the file I am working on to a, so that the plugin no longer recognizes it as a .tsv, the sort works as I had expected originally. I then have to copy my result back to the .tsv file.

The question was, is there a neater way of using the vim sort.

regards - Chris

Hi Christian

it seems that if I type

:filetype plugin off

before my sort command, the sort works, despite the screen still showing the plugin layout. (Despite the fact that I still need to use the letter keys for extending the line visual area, rather than the cursor keys).

regards - Chris

Re: sort in .tsv file

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

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aRxo1dPs8qFisgy3%40prometheus.

Re: Re: :sort in .tsv file

------ Original Message ------
From: cblists@256bit.org
To: vim_use@googlegroups.com
Sent: Tuesday, November 18th 2025, 10:24
Subject: Re: :sort in .tsv file
On Mo, 17 Nov 2025, 'c.willis111 ' via vim_use wrote: > the /pattern/ feature of sort doesn't work if the recognized filetype is > .tsv (which gives alternate colours for successive fields). What exactly do you mean by this? Thanks, Christian --

Hi Christian

I have the .csv plugin.

When I use the pattern in the vim :sort command, it does not work as expected.

I was mistaken in an earlier message. I am sure this is due to the plugin. If I copy the file I am working on to a, so that the plugin no longer recognizes it as a .tsv, the sort works as I had expected originally. I then have to copy my result back to the .tsv file.

The question was, is there a neater way of using the vim sort.

regards - Chris

Re: :sort in .tsv file

On Mo, 17 Nov 2025, 'c.willis111 ' via vim_use wrote:

> the /pattern/ feature of sort doesn't work if the recognized filetype is
> .tsv (which gives alternate colours for successive fields).

What exactly do you mean by this?

Thanks,
Christian
--
"We are on the verge: Today our program proved Fermat's next-to-last theorem."
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aRxJK/MFm9DODaAV%40256bit.org.

Re: sort in .tsv file

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!

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aRxI8MVq6IY5B%2ByL%40256bit.org.

Re: Re: sort in .tsv file

------ Original Message ------
From: vim_use@googlegroups.com
To: vim_use@googlegroups.com
Sent: Tuesday, November 18th 2025, 01:42
Subject: Re: sort in .tsv file

On 17.11.25 19:13, Tim Chase wrote:

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

>

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

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

Monday, November 17, 2025

Re: sort in .tsv file

On 17.11.25 19:13, Tim Chase wrote:

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

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

Re: sort in .tsv file

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

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aRvIQ6-0LjfdRQB7%40thechases.com.

Re: sort in .tsv file

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

Re: :sort in .tsv file

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

So I'm uncertain what you're seeing or how you're sorting that differs.

-tim
--

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aRuwJ25oNYdDa9at%40thechases.com.

:sort in .tsv file

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?

regards - Chris

Sign in to your Google Account

rebbe.malachi.mailfeed@blogger.com

You're receiving this message because your Google Account has not been used in at least 8 months.

To keep your Google Account active, take a moment now to sign in.

If your Google Account is not used within a 2-year period, Google may delete your Google Account and its activity and data.

Learn more about the Inactive Google Account policy

You received this email to let you know about important changes to your Google Account and services.

Sunday, November 16, 2025

Re: VIM remote and Wayland

Op zaterdag 15 november 2025 om 18:57:04 UTC+1 schreef Christian Brabandt:

On Sa, 15 Nov 2025, Erik Slagter wrote:
> For some time now, I fear from the moment I switched to Wayland, my vim (either
> vim or gvim) do not create a "server" anymore. So --remote-tab doesn't work.
> Vim --serverlist returns no servers when I have a running gvim instance. This
> has been working for absolutely years!
>
> gvim --remote-tab says "E247: No registered server named "GVIM": Send failed.
> Trying to execute locally" as a result, always.
>
> gaia $ vim --serverlist
> gaia $ echo $DISPLAY
> :0
> gaia $ xhost
> access control disabled, clients can connect from any host
>
> Anyone, please?

Recent Vims have support for using a socketserver. That should make it
work under Wayland I think.

So you're saying this is a known issue? I couldn't find anything on this when googling.

I guess I have a "recent" vim, so I'll will look into it, thanks!

> It helps if you tell us what kind of Vim you are using, so we can offer better help. You still did not

> mention 🙂 I am not sure the socketserver feature will help, but it sounds like it should, so please

> read up on this feature. See :h socketserver-clientserver

Not necessary, I already have it working, thanks! So, indeed, vim does not play nicely with Wayland regarding the "server" part. My vim version (from Fedora) is compiled with both X11 and Wayland support, which is nice, but for "server" use, it still chooses X11, which doesn't work (apparently).

This is the approach that works:

gaia erik: $ type vi
vi is an alias for /usr/bin/gvim --clientserver socket -f --remote-tab-silent

It would be nice if it could be a setting in the .vimrc file, but I don't think there is one.

Saturday, November 15, 2025

Re: VIM remote and Wayland

On Sa, 15 Nov 2025, Erik Slagter wrote:

> Hi there,
>
> For some time now, I fear from the moment I switched to Wayland, my vim (either
> vim or gvim) do not create a "server" anymore. So --remote-tab doesn't work.
> Vim --serverlist returns no servers when I have a running gvim instance. This
> has been working for absolutely years!
>
> gvim --remote-tab says "E247: No registered server named "GVIM": Send failed.
> Trying to execute locally" as a result, always.
>
> gaia $ vim --serverlist
> gaia $ echo $DISPLAY
> :0
> gaia $ xhost
> access control disabled, clients can connect from any host
>
> Anyone, please?

Recent Vims have support for using a socketserver. That should make it
work under Wayland I think.

Thanks,
Christian
--
You first parents of the human race... who ruined yourself for an apple,
what might you have done for a truffled turkey?
-- Brillat-savarin, "Physiologie du Gout"

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/aRi%2Bzf4iKAwbdJae%40256bit.org.

VIM remote and Wayland

Hi there,

For some time now, I fear from the moment I switched to Wayland, my vim (either vim or gvim) do not create a "server" anymore. So --remote-tab doesn't work. Vim --serverlist returns no servers when I have a running gvim instance. This has been working for absolutely years!

gvim --remote-tab says "E247: No registered server named "GVIM": Send failed. Trying to execute locally" as a result, always.

gaia $ vim --serverlist
gaia $ echo $DISPLAY
:0
gaia $ xhost
access control disabled, clients can connect from any host

Anyone, please?

Monday, November 10, 2025

Re: Filtering and stderr

Hello

The ! is the shell escape. It will be using the shell, and redirecting can be done via shell redirects.

You can write a wrapper script that might take a file (or not) that will generate the file you want. In that shell script you might use shell redirects.

Or write/rewrite the utility that you will be using with !. That will create a file using stderr.

If you want to redirect to a buffer you can use the above again. But you might need to write a vim function, command and/or define mappings, based on your requirements.

Regards

On Mon, Nov 10, 2025, 20:16 BPJ <bpj@melroch.se> wrote:

Can I get stderr directed to another file or buffer with `:!` (other than using shell redirects)? I'm sure there is an option but I can't find it! :-)

/bpj

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CADAJKhC1oJcpONmCfq4wAUP_otVTskw%2B_9Wk%2BQR-S1-bFq%2B2pg%40mail.gmail.com.

Re: Filtering and stderr

Regrettably, the short answer is no.

On 2025-11-10 12:16, BPJ wrote:

Can I get stderr directed to another file or buffer with `:!` (other than using shell redirects)? I'm sure there is an option but I can't find it! :-)

/bpj

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CADAJKhC1oJcpONmCfq4wAUP_otVTskw%2B_9Wk%2BQR-S1-bFq%2B2pg%40mail.gmail.com.

Filtering and stderr

Can I get stderr directed to another file or buffer with `:!` (other than using shell redirects)? I'm sure there is an option but I can't find it! :-)

/bpj

Tuesday, October 28, 2025

Re: vim diff - only display differences in lines

There isn't an easy way to sort the diff lines like so. Keep in mind that Vim does not know or care that the user lines are "sorted" nor is it immediately obvious to a diff algorithm how to do what you are showing because it's very dependent on the user intent. All Vim sees from the diff algorithm is "remove user2/user4 on the left, add user1/user3 on the right". Generally diff algorithms do not care about whether the contents are sorted or not.

Even if a feature is added to forcefully break the lines apart it would look like this rather than what you want (keep in mind that this feature does not exist and I simulated this by manually setting diff anchors):

Meanwhile if the inline highlight is distracting to you you can just turn off inline diff (set diffopt+=inline:none), which at least prevents Vim from doing the highlighting on the digits:

As I mentioned above, you can force Vim to show the diff however you want with diff anchors. It's not automatic though, as diff anchors are more designed to give you control over which lines to align where, when the algorithm does not do what you want. Say if you really want it to show up the way you want, with some manual fiddling to help visualize it, you can do it and get it to show up like this (see :help diff-anchors to see how to do this):

Diff anchor does have a bit of a learning curve especially if you need such granular controls, and it isn't a good fit if you want everything to be done automatically for you. FWIW the command I got to show the above is:

set diffopt+=anchor
setlocal diffanchors=1,2,2
setlocal diffanchors=2,2,3

On Tue, Oct 28, 2025 at 5:37 AM Igor <igor2x@gmail.com> wrote:

Hi,
1. I have two list of users like in file1:
user1
user3

and in file2:
user2
user4

2. I open first file:
:e file1

2. Open second file
:vsp file2

3. Do the diff between files
:windo diffthis

Diff is displayed as differences between files:

But I would like diff to be displayed as "line is missing" principle like this:

Both list of users are sorted, so it should be visible which user is missing on which user list.

How to force vim to display diff in "line missing" principle?
Thanks

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/ca29905e-da22-4bac-a8b2-ffe44ab4cb34n%40googlegroups.com.

vim diff - only display differences in lines

Hi,

1. I have two list of users like in file1:

user1

user3

and in file2:

user2

user4

2. I open first file:

:e file1

2. Open second file

:vsp file2

3. Do the diff between files

:windo diffthis

Diff is displayed as differences between files:

But I would like diff to be displayed as "line is missing" principle like this:

Both list of users are sorted, so it should be visible which user is missing on which user list.

How to force vim to display diff in "line missing" principle?

Thanks

Monday, October 13, 2025

Re: Scrolling behavior when using gj and gk is jumpy

> I understand that, but my main point is that positioning the cursor serves as a way to scroll in basically every other text editor on earth and it would be nice if it did here, too.

Moving the cursor and scrolling are two different things, with the former _sometimes_ causing the latter.

Doing the former in order to obtain the latter is, well… not a very efficient use of your tools.

Especially when a) there is a whole set of commands and widgets for doing the latter (<C-e>/<C-y>/etc., scrollbars, mousewheel, trackpad…) and b) it doesn't work particularly well to begin with.

It is the same side effect at play in every text editor and every multi-line text input widget on every platform, Vim included: you are moving the cursor to a line that is outside the viewport so the viewport is moved to include that line.

Where Vim's behavior might be different from other editors in that case is how it handles wrapped lines.

And how it does it makes perfect sense given the actual purpose of jkgjgk: the full _line_ is displayed so that you can _edit_ it comfortably.

> Plus, even if I scroll with ctl-e etc, the second I move my cursor into the "paragraph," it'll do that jerky jump.

Not with :set smoothscroll.

If you want to _scroll_, use scrolling commands (in Vim and elsewhere).

They exist for that specific purpose and they will always be better than unrelated commands that may or may not cause scrolling.

If you want pixel-perfect scrolling, use a modern non-terminal based editor.

On Monday, October 13, 2025 at 3:23:32 PM UTC+2 Marc Adler wrote:

I understand that, but my main point is that positioning the cursor serves as a way to scroll in basically every other text editor on earth and it would be nice if it did here, too.

Plus, even if I scroll with ctl-e etc, the second I move my cursor into the "paragraph," it'll do that jerky jump.

On Sunday, October 12, 2025 at 1:47:22 AM UTC-5 Romain Lafourcade wrote:
The purpose of j, k, gj, and gk is to _position the cursor_ for the next editing command.

They might also move the buffer up or down relative to the viewport, but that is only a _side effect_ of having the cursor at the top or bottom of the window.

:help 'smoothscroll' works perfectly, but _for actual "scrolling" commands_, which j, k, gj, and gk are not.

Use Ctrl-E, Ctrl-Y, etc. to _scroll_.

See :help scrolling.

On Saturday, October 11, 2025 at 11:25:03 AM UTC+2 Yee Cheng Chin wrote:
I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

Re: Scrolling behavior when using gj and gk is jumpy

I understand that, but my main point is that positioning the cursor serves as a way to scroll in basically every other text editor on earth and it would be nice if it did here, too.

Plus, even if I scroll with ctl-e etc, the second I move my cursor into the "paragraph," it'll do that jerky jump.

On Sunday, October 12, 2025 at 1:47:22 AM UTC-5 Romain Lafourcade wrote:

The purpose of j, k, gj, and gk is to _position the cursor_ for the next editing command.

They might also move the buffer up or down relative to the viewport, but that is only a _side effect_ of having the cursor at the top or bottom of the window.

:help 'smoothscroll' works perfectly, but _for actual "scrolling" commands_, which j, k, gj, and gk are not.

Use Ctrl-E, Ctrl-Y, etc. to _scroll_.

See :help scrolling.

On Saturday, October 11, 2025 at 11:25:03 AM UTC+2 Yee Cheng Chin wrote:
I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

Re: Scrolling behavior when using gj and gk is jumpy

"You could of course file an issue to Vim to see if there will be an appetite to add this as an option."

I just found the vim dev group. I'll post there. It's a little weird that Vim is the only text editor that has this behavior.

On Saturday, October 11, 2025 at 4:25:03 AM UTC-5 Yee Cheng Chin wrote:

I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

Saturday, October 11, 2025

Re: Scrolling behavior when using gj and gk is jumpy

The purpose of j, k, gj, and gk is to _position the cursor_ for the next editing command.

They might also move the buffer up or down relative to the viewport, but that is only a _side effect_ of having the cursor at the top or bottom of the window.

:help 'smoothscroll' works perfectly, but _for actual "scrolling" commands_, which j, k, gj, and gk are not.

Use Ctrl-E, Ctrl-Y, etc. to _scroll_.

See :help scrolling.

On Saturday, October 11, 2025 at 11:25:03 AM UTC+2 Yee Cheng Chin wrote:

I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc....@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

Friday, October 10, 2025

Re: Scrolling behavior when using gj and gk is jumpy

I don't think the issue is asymmetric as you claimed? gj/gk exhibits
the same jumping behavior both up and down (which is also shown in
your video). When you go to a new line, Vim tries to fit the entire
wrapped line with the cursor in the whole screen which is why it feels
jumpy. I don't think there is a builtin way to fix this. You could
write a script to re-scroll the text using Ctrl-E/Ctrl-Y when you do
gj/gk to get around this issue though. You could of course file an
issue to Vim to see if there will be an appetite to add this as an
option.

On Fri, Oct 10, 2025 at 2:38 PM Marc Adler <marc.adler@gmail.com> wrote:
>
> I use Vim to write text, ie prose with paragraphs.
>
>
> Vim interprets a paragraph as a single line, but it's good at displaying line breaks anyway.
>
>
> The problem is that it skips up and down by paragraph when you scroll up and down with gj and gk, making the text jerky and difficult to read.
>
>
> Smoothscroll fixes this, but only when you're scrolling down.
>
>
> Is there a way to make it work when scrolling up?
>
>
> Here's an example of what I'm talking about. The first is Vim (Neovim) and the second is VSCode. The VSCode behavior is what you see in every other text editor.
>
>
> Vim:
>
> https://imgur.com/a/u83V2TA
>
>
> VSCode:
>
> https://imgur.com/a/8dhcXo1
>
>
> Is there a way to fix this? Like I said, this behavior is unique to Vim.
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/vim_use/6ac646eb-a298-4540-be5f-5e5b884a1803n%40googlegroups.com.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAHTeOx_iK55vy2xeOk7UCy%3DK-eeC%2B%2BVU_24Ri5zZLUKqMFg%3D5A%40mail.gmail.com.

Re: Vimdiff counting dark blue lines

What is a "unique" line in your example? All the lines in each diff block are different. That's why they are in the diff to begin with. The "dark blue" lines are just the lines that are extra compared to the other side in this example. Vim doesn't by default do line similarity tests, and it doesn't know that "Bookmarks" and "Bookmarks Toolbar" are similar lines. Maybe I don't understand what you are asking here.

Note: I said Vim doesn't do line similarity tests by default because if you do "diffopt+=linematch:100" it does do that but I don't think you are using that.

On Tue, Oct 7, 2025 at 11:24 PM Ben Yip <yebenmy@gmail.com> wrote:

`git diff --numstat A B` is a bit easier.

On Mon, Oct 6, 2025, 17:26 K otgc <konthegoldcoast@gmail.com> wrote:
'Tis not so simple as sideX minus sideY.
Out of screenshot, Bookmarks1 indeed has unique added lines that Bookmarks2 doesn't have.
However Bookmarks2 also has unique added lines that Bookmarks1 doesn't have.

I solved this 3 ways:
1:
manual count

2.
$ diff Bookmarks1 Bookmarks2 | grep '^<' | wc -l 42 $ diff Bookmarks1 Bookmarks2 | grep '^>' | wc -l 22

3.
$ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^>' | wc -l 21 $ diff <(sed '1,2d' Bookmarks1) <(sed '1,2d' Bookmarks2) | grep '^<' | wc -l 41

On Sunday, 5 October 2025 at 08:54:15 UTC+2 Yee Cheng Chin wrote:
I'm imagining your diffopt does not have "inline:char" or "inline:word" right? In this case, the "dark blue lines" are basically "added lines" that are just the number of lines on the left minus the number of lines on the right. You just need to subtract them.

In order to count number of added/changed lines, you need some way of querying them using Vimscript, and currently Vim has pretty limited APIs for querying the diff structures. The one that you may want to use is `diff_hlID`. For example you can use diff_hlID(4321, 1)->synIDattr("name") and check if it's non-empty and count the lines between two sides. It requires a bit of scripting to work. There isn't a simple command to count this. I think it's more helpful if you explain exactly why you need to count these lines to begin with though.

On Fri, Oct 3, 2025 at 4:07 AM K otgc <kontheg...@gmail.com> wrote:
So not simply adding numbers to lines/rows, but totalling the unique added lines on the left and the right windows.

On Thursday, 2 October 2025 at 09:19:07 UTC+2 K otgc wrote:
The dark blue lines would be unique added lines.

On Tuesday, 30 September 2025 at 18:43:47 UTC+2 K otgc wrote:
Hello,
would there be a command to count the dark blue lines on the vimdiff Bookmarks1 and Bookmarks2 please?

Once I figured out how many extra lines there are, I can then work on some type of merge.

At the bottom of the vimdiff Bookmarks1 and Bookmarks2, there's some information showing:
Bookmarks1 4675,1 Bot and Bookmarks2 4655,1 Bot
I guess this means Bookmarks1 has 20 more lines thank Bookmark2.
However this isn't much help.
What I really need is Bookmarks1 has these dark blue lines for lines of data which isn't in Bookmarks2.
Vice versa too.

Then the fun bit merging or manually diffget and diffput each and every single line, which might be out of the question if too many.

Many thanks for any suggestions.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/4302280d-2e8f-45d9-bcda-7b0f7100490en%40googlegroups.com.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/187336f2-b018-447f-88c5-63e23021f940n%40googlegroups.com.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/CAOhRes8hePMRdkzgO1n25hAbY4TQ4j8GOyi2xr7OeoX1MQncgg%40mail.gmail.com.

Friday, November 21, 2025

Thursday, November 20, 2025

Wednesday, November 19, 2025

Tuesday, November 18, 2025

Monday, November 17, 2025

Sunday, November 16, 2025

Saturday, November 15, 2025

Monday, November 10, 2025

Tuesday, October 28, 2025

Monday, October 13, 2025

Saturday, October 11, 2025

Friday, October 10, 2025

Blog Archive

About Me