On Mon, Apr 13, 2020 at 12:28 PM Tom Lane wrote:
> Corey Huinker writes:
> > I was thinking that there were references that included parameters, but
> I'm
> > not finding any with actual parameter values, so at most we'd lose the
> "()"
> > of a reference.
>
> We could possibly stick the parens
Corey Huinker writes:
> I was thinking that there were references that included parameters, but I'm
> not finding any with actual parameter values, so at most we'd lose the "()"
> of a reference.
We could possibly stick the parens into the indexterm text. Arguably
that's an improvement on its
>
>
> I did a quick check by adding id tags to all 700-or-so s in
> func.sgml (don't get excited, it was a perl one-liner that just added
> random id strings).
I did, actually, get excited for a second.
> The runtime difference for building the HTML docs
> seems to be under 1%, and negligible
Corey Huinker writes:
> On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote:
>> Don't have a strong opinion about that, but it'd sure be a lot of new
>> anchors.
> So I can't speak to any scalability issues for adding a bunch of refs,
I did a quick check by adding id tags to all 700-or-so s in
On Sun, Apr 12, 2020 at 8:38 PM Tom Lane wrote:
> Corey Huinker writes:
> > On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote:
> >> Is that going to be a problem for the docs toolchain? If
> >> the anchors are attached to individual function names rather than
> >> sections or paragraphs, do they
Corey Huinker writes:
> On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote:
>> Is that going to be a problem for the docs toolchain? If
>> the anchors are attached to individual function names rather than
>> sections or paragraphs, do they actually work well as link references?
>> (I'm particularly
Alexander Lakhin writes:
> 12.04.2020 20:33, Tom Lane wrote:
>> I educated myself a teensy bit about XSL, and unless I'm missing
>> something, this is really pretty darn trivial; the attached seems
>> to do the trick.
> I've come to almost the same solution simultaneously. I think this
> should
Hello Tom,
12.04.2020 20:33, Tom Lane wrote:
> I wrote:
>> So if we can get to both insert a right arrow and switch the
>> font to match 's choice, this would work more or less decently, and
>> it's probably cleaner than the bare-entity-reference approach I posted
>> before. I don't have the XSL
I wrote:
> So if we can get to both insert a right arrow and switch the
> font to match 's choice, this would work more or less decently, and
> it's probably cleaner than the bare-entity-reference approach I posted
> before. I don't have the XSL skills to get that to work though.
> Anyone want
On 11.04.20 22:51, Tom Lane wrote:
Yet another possibility is to use the docbook tags:
func()
int.
Then we can define the desired formatting for such markup (similar to
..).
I looked into this. It appears that is fairly tightly tied
to C function declaration syntax, plus it sounds like
On Sat, Apr 11, 2020 at 6:41 PM Tom Lane wrote:
> Corey Huinker writes:
> > If it's ok to work on doc patches during the feature freeze, and if we're
> > already tweaking function documentation, would it be possible to add in
> > anchor ids to function definitions so that we could reference
Corey Huinker writes:
> If it's ok to work on doc patches during the feature freeze, and if we're
> already tweaking function documentation, would it be possible to add in
> anchor ids to function definitions so that we could reference specific
> functions (or rather the family of functions that
On Sat, Apr 11, 2020 at 4:51 PM Tom Lane wrote:
> I set this idea aside during the final v13 commitfest, but I figure that
> it's fine to work on documentation improvements during feature freeze,
> so I'm going to try to push it forward over the next few weeks.
If it's ok to work on doc
I set this idea aside during the final v13 commitfest, but I figure that
it's fine to work on documentation improvements during feature freeze,
so I'm going to try to push it forward over the next few weeks.
Barring objections, I want to commit more or less what I posted at [1],
verify that it
Hello Tom,
> 16.02.2020 23:07, Tom Lane wrote:
>
>
> I poked at this a little bit, and found that I could get a pretty
> decent-looking result if I hacked the .fo file to contain
> "→" rather than a bare
> right arrow. (See attached screenshot, wherein the last rightarrow
> was fixed this way but
Alvaro Herrera writes:
> On 2020-Feb-13, Alexander Lakhin wrote:
>> Third (minor) issue is with translation - when I will see some break in
>> the English source, e.g. "split_part('abc~@~def~@~ghi', '~@~',
>> 2)", should I leave the break in the same place, or it's better to move
>> it because
On 2020-Feb-13, Alexander Lakhin wrote:
> Yes, I was starting with manual insertions into the translation,
> but later I reduced such insertions just to several dozens. (For
> example, we still have "3.14159265358979323846" in the translation.)
> The main issue of the manual approach was that I
12.02.2020 23:58, Tom Lane wrote:
> Alexander Lakhin writes:
>> Please look at a less invasive approach that we use at Postgres Pro for
>> some time (mainly for improving the translated documentation, but it
>> works for the original one too). The idea is to add zero-width spaces
>> after/before
Alvaro Herrera writes:
> On 2020-Feb-12, Tom Lane wrote:
>> I also attached a screenshot of a segment of Table 9-31, to show
>> what that layout proposal looks like. It's a little busier, but
>> it does have the advantage that it's clearer how to apply that
>> format to operator tables. The
On 2020-Feb-12, Tom Lane wrote:
> For amusement's sake, attached is a screenshot of what Table 9-33
> looks like in A4 format, with my one-row-per-example patch of
> yesterday plus a few manually-added zero-width spaces to break up
> the examples. This is the first PDF rendering of that table
Hello Tom,
12.02.2020 00:51, Tom Lane wrote:
> The crummy formatting of our tables of functions and operators has
> been an issue for a long time. To my mind, there are several things
> that need to be addressed:
>
> * The layout is completely unfriendly to function descriptions that
> run to
The crummy formatting of our tables of functions and operators has
been an issue for a long time. To my mind, there are several things
that need to be addressed:
* The layout is completely unfriendly to function descriptions that
run to more than a few words.
* It's not very practical to have
22 matches
Mail list logo
