On 09.03.2022 at 20:43, Brar Piening wrote:
Attached is a pretty huge patch that adds ids to all sections and all
the varlistentries where the containing variablelist already had at
least one id (plus a few additional ones that I stumbled upon and
deemed useful). It also adds html links next to
On 02.03.2022 at 18:54, Chapman Flack wrote:
Perhaps there are a bunch of variablelists where no one cares about
linking to any of the entries.
So maybe a useful non-terminating message to add eventually would
be one that identifies any varlistentry lacking an id, with a
variablelist where at
On 03/02/22 12:46, Brar Piening wrote:
> With regard to varlistentry I'd suggest to decide whether to add ids or
> not on a case by case base. I already offered to add ids to long lists
> upon request but I wouldn't want to blindly add ~4k ids that nobody
Perhaps there are a bunch of
On 02.03.2022 at 10:37, Peter Eisentraut wrote:
I have applied the part of your patch that adds the id's. The
discussion about the formatting aspect can continue.
Thank you!
I've generated some data by outputting the element name whenever a
section or varlistentry lacks an id. That's how the
On 01.03.22 18:27, Brar Piening wrote:
Also I'm not sure how well the autogenerated ids are reproducible over
time/versions/builds, and if it is wise to use them as targets to link
to from somewhere else.
Autogenerated ids are stable across builds of the same source. They
would change if the
On 01.03.22 20:50, Brar Piening wrote:
Patch is attached. I don't think it should get applied this way, though.
The fact that you only get links for section headers that have manually
assigned ids would be pretty surprising for users of the docs and in
some files (e.g. protocol-flow.html) only
On 03/01/22 14:50, Brar Piening wrote:
> TBH I don't like the visual representation of the unicode link symbol
> (U+1F517) in my browser. It's a bold black fat thing that doesn't
> inherit colors. I've tried to soften it by decreasing the size but that
> doesn't really solve it for me. Font
On Mar 01, 2022 at 18:27, Brar Piening wrote:
On Feb 28, 2022 at 21:06, Chapman Flack wrote:
I think that in other recent examples I've seen, there might be
(something like a) consensus forming around the Unicode LINK SYMBOL
rather than # as the symbol for such things.
I intentionally opted
On Feb 28, 2022 at 21:06, Chapman Flack wrote:
I think that in other recent examples I've seen, there might be
(something like a) consensus forming around the Unicode LINK SYMBOL
rather than # as the symbol for such things.
I intentionally opted for an ASCII character as that definitely won't
On 02/28/22 14:41, Brar Piening wrote:
> Attached is an extended version of the patch that changes the XSL and
> CSS stylesheets to add links to the ids that are visible when hovering.
That works nicely over here.
I think that in other recent examples I've seen, there might be
(something like a)
On Feb 25, 2022 at 06:36, Brar Piening wrote:
The major problem in that regard would probably be my lack of
XSLT/docbook skills but if no one can jump in here, I can see if I can
make it work.
Ok, I've figured it out.
Attached is an extended version of the patch that changes the XSL and
CSS
On 28.02.2022 at 10:24, Peter Eisentraut wrote:
On 28.02.22 09:41, Brar Piening wrote:
On Feb 25, 2022 at 14:31, Peter Eisentraut wrote:
I think that kind of stuff would be added in via the web site
stylesheets, so you wouldn't have to deal with XSLT at all.
True for the CSS but adding the
On 28.02.22 09:41, Brar Piening wrote:
On Feb 25, 2022 at 14:31, Peter Eisentraut wrote:
I think that kind of stuff would be added in via the web site
stylesheets, so you wouldn't have to deal with XSLT at all.
True for the CSS but adding the HTML (#)
will need either XSLT or Javascript.
On Feb 25, 2022 at 14:31, Peter Eisentraut wrote:
I think that kind of stuff would be added in via the web site
stylesheets, so you wouldn't have to deal with XSLT at all.
True for the CSS but adding the HTML (#)
will need either XSLT or Javascript.
On 25.02.22 06:36, Brar Piening wrote:
Yes, that would be possible. In fact appending a link and optionally
adding a tiny bit of CSS like I show below does the trick.
The major problem in that regard would probably be my lack of
XSLT/docbook skills but if no one can jump in here, I can see if I
On 24.02.2022 at 17:07, Brar Piening wrote:
On 24.02.2022 at 16:46, Alvaro Herrera wrote:
Would it be possible to create such anchor links as part of the XSL
stylesheets for HTML?
I'll investiogate our options and report back.
Yes, that would be possible. In fact appending a link and
On Thu, Feb 24, 2022, 16:52 Kyotaro Horiguchi
wrote:
> At Tue, 21 Dec 2021 08:47:27 +0100, Brar Piening wrote in
> > On 20.12.2021 at 16:09, Robert Haas wrote:
> > > As a data point, this is something I have also wanted to do, from time
> > > to time. I am generally of the opinion that any
On 02/24/22 19:52, Kyotaro Horiguchi wrote:
> FWIW in that perspecive, there's no requirement from me that it should
> be human-readable. I'm fine with automatically-generated ids.
One thing I would be −many on, though, would be automatically-generated ids
that are not, somehow, stable. I've
At Tue, 21 Dec 2021 08:47:27 +0100, Brar Piening wrote in
> On 20.12.2021 at 16:09, Robert Haas wrote:
> > As a data point, this is something I have also wanted to do, from time
> > to time. I am generally of the opinion that any place the
+1 from me. When I put an URL in the answer for
On 24.02.2022 at 16:46, Alvaro Herrera wrote:
On 2022-Feb-24, Dagfinn Ilmari Mannsåker wrote:
Peter Eisentraut writes:
Is there a way to obtain those URLs other than going into the HTML
sources and checking if there is an anchor near where you want go?
I use the jump-to-anchor extension:
On 2022-Feb-24, Dagfinn Ilmari Mannsåker wrote:
> Peter Eisentraut writes:
> > Is there a way to obtain those URLs other than going into the HTML
> > sources and checking if there is an anchor near where you want go?
>
> I use the jump-to-anchor extension:
Peter Eisentraut writes:
> On 18.12.21 00:53, Brar Piening wrote:
>> The purpose is that you can directly link to the id in the public html
>> docs which still gets generated (e. g.
>> https://www.postgresql.org/docs/14/protocol-replication.html#PROTOCOL-REPLICATION-BASE-BACKUP).
>>
>>
On 18.12.21 00:53, Brar Piening wrote:
The purpose is that you can directly link to the id in the public html
docs which still gets generated (e. g.
https://www.postgresql.org/docs/14/protocol-replication.html#PROTOCOL-REPLICATION-BASE-BACKUP).
Essentially it gives people discussing the
On 20.12.2021 at 16:09, Robert Haas wrote:
As a data point, this is something I have also wanted to do, from time
to time. I am generally of the opinion that any place the
documentation has a long list of things, which should add ids, so that
people can link to the particular thing in the list
On Fri, Dec 17, 2021 at 6:54 PM Brar Piening wrote:
> The purpose is that you can directly link to the id in the public html
> docs which still gets generated (e. g.
> https://www.postgresql.org/docs/14/protocol-replication.html#PROTOCOL-REPLICATION-BASE-BACKUP).
>
> Essentially it gives people
On Dec 17, 2021 at 08:13, Peter Eisentraut wrote:
On 15.12.21 16:59, Brar Piening wrote:
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor of
On 15.12.21 16:59, Brar Piening wrote:
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor of adding more, I
will remove them from my current
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor of adding more, I
will remove them from my current patch but leave the existing ones
intact.
On 2021-Dec-15, Brar Piening wrote:
> On Dec 14, 2021 at 20:47, Alvaro Herrera wrote:
> >
> > Hmm, I think we tend to avoid xreflabels; see
> > https://www.postgresql.org/message-id/8315c0ca-7758-8823-fcb6-f37f9413e...@2ndquadrant.com
>
> Ok, thank you for the hint.
> I added them because
On Dec 14, 2021 at 20:47, Alvaro Herrera wrote:
Hmm, I think we tend to avoid xreflabels; see
https://www.postgresql.org/message-id/8315c0ca-7758-8823-fcb6-f37f9413e...@2ndquadrant.com
Ok, thank you for the hint.
I added them because doesn't automatically generate
labels and they were
On 2021-Dec-05, Brar Piening wrote:
> When working with the Frontend/Backend Protocol implementation in Npgsql
> and discussing things with the team, I often struggle with the fact that
> you can't set deep links to individual message formats in the somewhat
> lengthy html docs pages.
>
> The
On Sun, Dec 5, 2021 at 11:15 AM Daniel Gustafsson wrote:
> > On 5 Dec 2021, at 16:51, Brar Piening wrote:
>
> > The attached patch adds id's to various elements in protocol.sgml to
> > make them more accesssible via the public html documentation interface.
>
> Off the cuff without having
> On 5 Dec 2021, at 16:51, Brar Piening wrote:
> The attached patch adds id's to various elements in protocol.sgml to
> make them more accesssible via the public html documentation interface.
Off the cuff without having checked the compiled results yet, it seems like a
good idea.
—
Daniel
When working with the Frontend/Backend Protocol implementation in Npgsql
and discussing things with the team, I often struggle with the fact that
you can't set deep links to individual message formats in the somewhat
lengthy html docs pages.
The attached patch adds id's to various elements in
34 matches
Mail list logo
