Re: run pgindent on a regular basis / scripted manner
От | Andrew Dunstan |
---|---|
Тема | Re: run pgindent on a regular basis / scripted manner |
Дата | |
Msg-id | e11b008e-e5f9-b31d-adbb-33ee66b49748@dunslane.net обсуждение исходный текст |
Ответ на | Re: run pgindent on a regular basis / scripted manner (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: run pgindent on a regular basis / scripted manner
|
Список | pgsql-hackers |
On 2023-04-22 Sa 11:37, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:On 2023-04-22 Sa 10:39, Tom Lane wrote:Another obstacle in the way of (1) is that there was some discussion of changing perltidy version and/or options. But I don't believe we have a final proposal on that, much less committed code.Well, I posted a fairly concrete suggestion with an example patch upthread at <https://www.postgresql.org/message-id/47011581-ddec-1a87-6828-6edfabe6b7b6%40dunslane.net> I still think that's worth doing.OK, so plan is (a) update perltidyrc to add --valign-exclusion-list, (b) adjust pgindent/README to recommend perltidy version 20221112. Questions: * I see that there's now a 20230309 release, should we consider that instead?
A test I just ran gave identical results to those from 20221112
* emacs.samples provides pgsql-perl-style that claims to match perltidy's rules. Does that need any adjustment? I don't see anything in it that looks relevant, but I'm not terribly familiar with emacs' Perl formatting options.
At least w.r.t. the vertical alignment issue, AFAICT the emacs style does not attempt to align anything vertically except the first non-space thing on the line. So if anything, by abandoning a lot of vertical alignment it would actually be closer to what the sample emacs style does.
The great advantage of not doing this alignment is that there is far less danger of perltidy trying to realign lines that have not in fact changed, because some nearby line has changed. So we'd have a good deal less pointless churn.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: