Make links work again inside tips

Author: philrz

docs/commands/super-db.md

@@ -15,7 +15,8 @@ title: super db
 
 <p id="status"></p>
 
-{{< tip "Status" >}}
+{{% tip "Status" %}}
+
 While [`super`](super.md) and its accompanying [formats](../formats/_index.md)
 are production quality, the SuperDB data lake is still fairly early in development
 and alpha quality.
@@ -25,7 +26,8 @@ is deployed to manage the lake's data layout via the
 [lake API](../lake/api.md).
 
 Enhanced scalability with self-tuning configuration is under development.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ## The Lake Model
 
@@ -153,7 +155,8 @@ running any `super db` lake command all pointing at the same storage endpoint
 and the lake's data footprint will always remain consistent as the endpoints
 all adhere to the consistency semantics of the lake.
 
-{{< tip "Caveat" >}}
+{{% tip "Caveat" %}}
+
 Data consistency is not fully implemented yet for
 the S3 endpoint so only single-node access to S3 is available right now,
 though support for multi-node access is forthcoming.
@@ -164,7 +167,8 @@ access to a local file system has been thoroughly tested and should be
 deemed reliable, i.e., you can run a direct-access instance of `super db` alongside
 a server instance of `super db` on the same file system and data consistency will
 be maintained.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ### Locating the Lake
 
@@ -206,11 +210,13 @@ Each commit object is assigned a global ID.
 Similar to Git, commit objects are arranged into a tree and
 represent the entire commit history of the lake.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 Technically speaking, Git can merge from multiple parents and thus
 Git commits form a directed acyclic graph instead of a tree;
 SuperDB does not currently support multiple parents in the commit object history.
-{{< /tip >}}
+
+{{% /tip %}}
 
 A branch is simply a named pointer to a commit object in the lake
 and like a pool, a branch name can be any valid UTF-8 string.
@@ -272,10 +278,12 @@ key.  For example, on a pool with pool key `ts`, the query `ts == 100`
 will be optimized to scan only the data objects where the value `100` could be
 present.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 The pool key will also serve as the primary key for the forthcoming
 CRUD semantics.
-{{< /tip >}}
+
+{{% /tip %}}
 
 A pool also has a configured sort order, either ascending or descending
 and data is organized in the pool in accordance with this order.
@@ -325,9 +333,11 @@ using that pool's "branches log" in a similar fashion, then its corresponding
 commit object can be used to construct the data of that branch at that
 past point in time.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 Time travel using timestamps is a forthcoming feature.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ## `super db` Commands
 
@@ -407,11 +417,13 @@ the [special value `this`](../language/pipeline-model.md#the-special-value-this)
 
 A newly created pool is initialized with a branch called `main`.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 Lakes can be used without thinking about branches.  When referencing a pool without
 a branch, the tooling presumes the "main" branch as the default, and everything
 can be done on main without having to think about branching.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ### Delete
 ```
@@ -582,9 +594,11 @@ that is stored in the commit journal for reference.  These values may
 be specified as options to the [`load`](#load) command, and are also available in the
 [lake API](../lake/api.md) for automation.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 The branchlog meta-query source is not yet implemented.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ### Ls
 ```

docs/commands/super.md

@@ -187,13 +187,15 @@ not desirable because (1) the Super JSON parser is not particularly performant a
 (2) all JSON numbers are floating point but the Super JSON parser will parse as
 JSON any number that appears without a decimal point as an integer type.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 The reason `super` is not particularly performant for Super JSON is that the [Super Binary](../formats/bsup.md) or
 [Super Columnar](../formats/csup.md) formats are semantically equivalent to Super JSON but much more efficient and
 the design intent is that these efficient binary formats should be used in
 use cases where performance matters.  Super JSON is typically used only when
 data needs to be human-readable in interactive settings or in automated tests.
-{{< /tip >}}
+
+{{% /tip %}}
 
 To this end, `super` uses a heuristic to select between Super JSON and plain JSON when the
 `-i` option is not specified. Specifically, plain JSON is selected when the first values

docs/formats/bsup.md

@@ -130,7 +130,8 @@ size decompression buffers in advance of decoding.
 Values for the `format` byte are defined in the
 [Super Binary compression format specification](./compression.md).
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 This arrangement of frames separating types and values allows
 for efficient scanning and parallelization.  In general, values depend
 on type definitions but as long as all of the types are known when
@@ -143,7 +144,8 @@ heuristics, e.g., knowing a filtering predicate can't be true based on a
 quick scan of the data perhaps using the Boyer-Moore algorithm to determine
 that a comparison with a string constant would not work for any
 value in the buffer.
-{{< /tip >}}
+
+{{% /tip %}}
 
 Whether the payload was originally uncompressed or was decompressed, it is
 then interpreted according to the `T` bits of the frame code as a
@@ -211,12 +213,14 @@ is further encoded as a "counted string", which is the `uvarint` encoding
 of the length of the string followed by that many bytes of UTF-8 encoded
 string data.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 As defined by [Super JSON](jsup.md), a field name can be any valid UTF-8 string much like JSON
 objects can be indexed with arbitrary string keys (via index operator)
 even if the field names available to the dot operator are restricted
 by language syntax for identifiers.
-{{< /tip >}}
+
+{{% /tip %}}
 
 The type ID follows the field name and is encoded as a `uvarint`.
 

docs/formats/csup.md

@@ -64,12 +64,14 @@ then write the metadata into the reassembly section along with the trailer
 at the end.  This allows a stream to be converted to a Super Columnar file
 in a single pass.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 That said, the layout is
 flexible enough that an implementation may optimize the data layout with
 additional passes or by writing the output to multiple files then
 merging them together (or even leaving the Super Columnar entity as separate files).
-{{< /tip >}}
+
+{{% /tip %}}
 
 ### The Data Section
 
@@ -85,17 +87,20 @@ There is no information in the data section for how segments relate
 to one another or how they are reconstructed into columns.  They are just
 blobs of Super Binary data.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 Unlike Parquet, there is no explicit arrangement of the column chunks into
 row groups but rather they are allowed to grow at different rates so a
 high-volume column might be comprised of many segments while a low-volume
 column must just be one or several.  This allows scans of low-volume record types
 (the "mice") to perform well amongst high-volume record types (the "elephants"),
 i.e., there are not a bunch of seeks with tiny reads of mice data interspersed
 throughout the elephants.
-{{< /tip >}}
 
-{{< tip "TBD" >}}
+{{% /tip %}}
+
+{{% tip "TBD" %}}
+
 The mice/elephants model creates an interesting and challenging layout
 problem.  If you let the row indexes get too far apart (call this "skew"), then
 you have to buffer very large amounts of data to keep the column data aligned.
@@ -109,15 +114,17 @@ if you use lots of buffering on ingest, you can write the mice in front of the
 elephants so the read path requires less buffering to align columns.  Or you can
 do two passes where you store segments in separate files then merge them at close
 according to an optimization plan.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ### The Reassembly Section
 
 The reassembly section provides the information needed to reconstruct
 column streams from segments, and in turn, to reconstruct the original values
 from column streams, i.e., to map columns back to composite values.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 Of course, the reassembly section also provides the ability to extract just subsets of columns
 to be read and searched efficiently without ever needing to reconstruct
 the original rows.  How well this performs is up to any particular
@@ -127,7 +134,8 @@ Also, the reassembly section is in general vastly smaller than the data section
 so the goal here isn't to express information in cute and obscure compact forms
 but rather to represent data in an easy-to-digest, programmer-friendly form that
 leverages Super Binary.
-{{< /tip >}}
+
+{{% /tip %}}
 
 The reassembly section is a Super Binary stream.  Unlike Parquet,
 which uses an externally described schema
@@ -147,9 +155,11 @@ A super type's integer position in this sequence defines its identifier
 encoded in the [super column](#the-super-column).  This identifier is called
 the super ID.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 Change the first N values to type values instead of nulls?
-{{< /tip >}}
+
+{{% /tip %}}
 
 The next N+1 records contain reassembly information for each of the N super types
 where each record defines the column streams needed to reconstruct the original
@@ -171,11 +181,13 @@ type signature:
 In the rest of this document, we will refer to this type as `<segmap>` for
 shorthand and refer to the concept as a "segmap".
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 We use the type name "segmap" to emphasize that this information represents
 a set of byte ranges where data is stored and must be read from *rather than*
 the data itself.
-{{< /tip >}}
+
+{{% /tip %}}
 
 #### The Super Column
 
@@ -216,11 +228,13 @@ This simple top-down arrangement, along with the definition of the other
 column structures below, is all that is needed to reconstruct all of the
 original data.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 Each row reassembly record has its own layout of columnar
 values and there is no attempt made to store like-typed columns from different
 schemas in the same physical column.
-{{< /tip >}}
+
+{{% /tip %}}
 
 The notation `<any_column>` refers to any instance of the five column types:
 * [`<record_column>`](#record-column),
@@ -296,9 +310,11 @@ in the same column order implied by the union type, and
 * `tags` is a column of `int32` values where each subsequent value encodes
 the tag of the union type indicating which column the value falls within.
 
-{{< tip "TBD" >}}
+{{% tip "TBD" %}}
+
 Change code to conform to columns array instead of record{c0,c1,...}
-{{< /tip >}}
+
+{{% /tip %}}
 
 The number of times each value of `tags` appears must equal the number of values
 in each respective column.
@@ -350,14 +366,16 @@ data in the file,
 it will typically fit comfortably in memory and it can be very fast to scan the
 entire reassembly structure for any purpose.
 
-{{< tip "Example" >}}
+{{% tip "Example" %}}
+
 For a given query, a "scan planner" could traverse all the
 reassembly records to figure out which segments will be needed, then construct
 an intelligent plan for reading the needed segments and attempt to read them
 in mostly sequential order, which could serve as
 an optimizing intermediary between any underlying storage API and the
 Super Columnar decoding logic.
-{{< /tip >}}
+
+{{% /tip %}}
 
 To decode the "next" row, its schema index is read from the root reassembly
 column stream.

docs/install.md

@@ -40,11 +40,13 @@ This installs the `super` binary in your `$GOPATH/bin`.
 
 Once installed, run a [quick test](#quick-tests).
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 If you don't have Go installed, download and install it from the
 [Go install page](https://golang.org/doc/install). Go 1.23 or later is
 required.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ## Quick Tests
 

docs/integrations/amazon-s3.md

@@ -16,11 +16,13 @@ You must specify an AWS region via one of the following:
 You can create `~/.aws/config` by installing the
 [AWS CLI](https://aws.amazon.com/cli/) and running `aws configure`.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 If using S3-compatible storage that does not recognize the concept of regions,
 a region must still be specified, e.g., by providing a dummy value for
 `AWS_REGION`.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ## Credentials
 

docs/integrations/fluentd.md

@@ -81,13 +81,15 @@ The default settings when running `zed create` set the
 field and sort the stored data in descending order by that key. This
 configuration is ideal for Zeek log data.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 The [Zui](https://zui.brimdata.io/) desktop application automatically starts a
 Zed lake service when it launches. Therefore if you are using Zui you can
 skip the first set of commands shown above. The pool can be created from Zui
 by clicking **+**, selecting **New Pool**, then entering `ts` for the
 [pool key](../commands/super-db.md#pool-key).
-{{< /tip >}}
+
+{{% /tip %}}
 
 ### Fluentd
 
@@ -366,15 +368,17 @@ leverage, you can reduce the lake's storage footprint by periodically running
 storage that contain the granular commits that have already been rolled into
 larger objects by compaction.
 
-{{< tip "Note" >}}
+{{% tip "Note" %}}
+
 As described in issue [super/4934](https://github.com/brimdata/super/issues/4934),
 even after running `zed vacuum`, some files related to commit history are
 currently still left behind below the lake storage path. The issue describes
 manual steps that can be taken to remove these files safely, if desired.
 However, if you find yourself needing to take these steps in your environment,
 please [contact us](#contact-us) as it will allow us to boost the priority
 of addressing the issue.
-{{< /tip >}}
+
+{{% /tip %}}
 
 ## Ideas For Enhancement