Re: Using vim for developing porstres wiki article

From: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: James Coleman <jtc331(at)gmail(dot)com>
Subject: Re: Using vim for developing porstres wiki article
Date: 2019-01-03 11:53:04
Message-ID: 32919930.C2XfPPQ2iN@x200m
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

В письме от среда, 2 января 2019 г. 8:59:13 MSK пользователь James Coleman
написал:

> > So I decided to write it down to a wiki article, while I am restoring the
> > configuration so I do not have to remember them for the third time, if I
> > loose .vimrc again. :-)
>
> I like expanding the small section in the Developer FAQ into a more
> detailed article.
>
> But the new article is missing several things relative to the old
> instructions, and I don't think the changes should have been made to
> that page until this was more fully baked.

Actually I've kept most of the old instructions in "Old staff" section. So all
data is available as it id (I've just removed filestyle paragraph, form the
FAQ, as I added it there myself, and it is properly described in a new
article). So nothing is lost, only new info is added.

>
> A few specific thoughts:
>
> 1. The new article makes it more difficult to get started since every
> setting would need to be copied separately. I think there should be a
> cohesive block of options that we recommend for copy/paste along with
> inline comments explaining what each one does.
As far as I can understand wiki is first of all for explaining, not for ready
recipes. So I explained.
We have a better place for ready recipe, but nobody uses it.
It is src/tools/editors/vim.samples so it you want to make ready recipe, I
would suggest to but it there, and just tell about it in the wiki.

> 2. There's a bit of conflation between general Vim setup and Postgres
> specific development. The old section I think was mostly geared toward
> someone who uses Vim but wants the Postgres-specific parts, and that's
> a valuable use case. Perhaps we could split the article into a section
> on general Vim setup (for example, turning on syntax) and a section on
> "if you also already use Vim, there's a way to do project-specific
> settings and the ones you should use".
I've been thinking about it. My idea was: an experienced vim user knows better
what he really wants, he does not need any advises. And even less he needs
ready recipes.

A vim beginner needs understanding first of all. He can copy ready recipe, but
it gives him nothing. So every options needs an explanation.

So I'd keep article style as it is, just allow experienced user to scan it and
choose tips he really wants. And let the beginner get what understanding he
can get.

> 3. Several of the old specified options didn't make it into the new
> article's details and are a loss. I noticed this particularly since
> since just 2 or 3 days ago I myself had edited this section to add the
> softtabstop=0 option (the Vim default) so that if soft tabs are
> enabled in someone's general Vim config then hitting the tab key won't
> result in inserting 2 spaces while working in the Postgres source.

As far as I said above, I've kept old example. So if you have some expertise
in options I've omitted, you can join explaining them.

As for softtabstop. From what I've heard, I'd just ignored this option. If
user did something in a global config, then he is an experienced user, and
needs no advises from us, he knows what he is doing. And for beginner this is
information is useless, overriding default value with the same value is a
strange thing. It is not the thing should think abut when he is starting

But it you think it is important, you can add an abstract about softtabstop, I
do not mind. Different people sees importance in different things.

PS. I am beginner in vim, and for me config example in FAQ was totally useless.
So I tried to create an article that would be useful for me, and tried not to
destroy information that exists.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-01-03 11:56:58 Re: log bind parameter values on error
Previous Message Peter Eisentraut 2019-01-03 11:52:36 Re: [PATCH] check for ctags utility in make_ctags