Re: more i18n/l10n issues - Mailing list pgsql-hackers
From | Peter Eisentraut |
---|---|
Subject | Re: more i18n/l10n issues |
Date | |
Msg-id | Pine.LNX.4.44.0310122343470.27310-100000@peter.localdomain Whole thread Raw |
In response to | Re: more i18n/l10n issues (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
Tom Lane writes: > -m and -M > > The utility we designed and possibly any other that wants to process the > output will find it easier to process a more regularly formed output > instead of one that was embellished for human viewing. The reason for > having one with and one without headings is that in some circumstances > the utility designer may want to use the headers to make her/his table > headers and others may prefer to have pre-defined table headers. The > guy who wrote our window used -M while I would have liked him to use -m > (but -M was faster to do and he was on a hurry). But the headers output by -m are not useful for human viewing. Also, we don't have any ideas what "utility designers" may want, we only know what your tool wants. So unless you need both -m and -M, I propose that we remove the option with headers and make -m output the list without headers. > -G > > The -G (using the Unix convention of negating things with capital > letters) is what we use. This option is probably what will be used for > generating the postgresql.conf default file automatically. > As we were not adding a facility for our use but for other tool > developers as well and we thought that some may want to process it in > different ways we made it an option. We don't object making it a side > effect of using -m or -M. If you aren't using the group-by-category option, then I propose that we remove it. We haven't heard any proposals about generating postgresql.conf, or about any other tool developers, so it's pure fantasy at this point. I don't like comitting to features based on fantasies. > > Also, --help-config 'foo' outputs all parameters matching 'foo' somewhere > > in the string, not only 'foo'. I think that is a misdesign. > > > > It works like locate (or slocate). I believe some other Unix utilities > do the same. Unix commands are mostly 'misdesigned' I admit. If I enter "ls foo", it shows me only foo. If I enter "rm foo", it only removes foo. Works perfectly well. If you want a wildcarding behavior, it should be explicit. Also note that locate provides a way to make the search string anchored, whereas your design does not. How does you tool work if the user wants to take a look at the option "geqo"? It will then show all options that contain "geqo". There is no way to look at only one option and that seems wrong. So I propose that the match-anywhere behavior be removed. > > Also, in many cases where there is a long description, it was copied out > > of the documentation, with the short description being the first sentence > > and the long description being the rest. The result is that in some cases > > the long description doesn't make sense in isolation. I would like that > > to be clarified. > > > > This is a GNU trick to avoid repeating the same text (from the short > description) in the long description. I believe it is from Richard > Stallman's time. It is used in several GNU tools, for instance the GNU > GDB debugger (which uses just one field and makes the first sentence or > line the short description). The idea is that the long description is > formed by the concatenation of the two. If you want to pull tricks like that, you need to tell us about it. Right now, some of that doesn't work anymore, because some of the short and long descriptions had to be reworked to make sense in isolation. I think what I would like to do for the next release is to rip out all of this and store the information about the configuration parameters in some external file and generate code, documentation, and help from that. Then we can have a short and a long description without any tricks. -- Peter Eisentraut peter_e@gmx.net
pgsql-hackers by date: