Skip to content

Java, Kotlin, Scala(docs): Write the core type directories - #166

Open
tony wants to merge 3 commits into
masterfrom
docs/api-directory
Open

tony wants to merge 3 commits into
masterfrom
docs/api-directory

Conversation

@tony

@tony tony commented Nov 14, 2026

Copy link
Copy Markdown
Contributor

Summary

Java Server and Session, Kotlin Server and Scala Server open with a task directory on libtmux.org. This writes the missing ones: Java Window and Pane, and Kotlin and Scala Session, Window and Pane, each in the shape that port's existing directory uses.

Changes

  • Java, Window.java and Pane.java class Javadoc: <p><strong> rows, then a {@link #x} paragraph or a Label: list.
  • Kotlin, Session.kt, Window.kt and Pane.kt KDoc. Extension functions are written [kill][Session.kill], since several types share names such as kill, refresh and expand.
  • Scala, the doc comment of each scaladsl opaque type in Session.scala, Window.scala and Pane.scala, where the Server directory lives, with [[Type.name]] references.
  • Session rows: Reading the capture; Windows and panes; Changing the session; Options, environment, and hooks; Formats and refreshing.
  • Window rows: Reading the capture; Panes; Layout and size; Moving and linking; Changing the window; Options and hooks; Formats and refreshing.
  • Pane rows: Reading the capture; Sending input; Reading output; Running and waiting; Splitting and arranging; Modes; Changing the pane; Options and hooks; Formats and refreshing.

Review notes

  • Kotlin has no watchText, currentPathText, info or Session context equivalents, and Scala has no watchText; each directory lists only what its port has.
  • Scala references such as [[Pane.kill]] point at extension methods, as the Server directory's [[Session.windows]] does; whether Scaladoc resolves them is unconfirmed.

Test plan

  • The libtmux.org parser (parseApiProse and groupDirectory from libtmux/docs, after this port's doc parser) folds each new doc comment into a directory
  • Every Java {@link #x} names a method in its file
  • Every Kotlin and Scala reference names a member in the hand-written source or the generated operations
  • No added line passes the 120-column limit
  • Gradle Javadoc, Dokka and Scaladoc builds
  • Docs workflow build on this branch
  • The directories render on libtmux.org once the docs model is regenerated from this branch

tony added 3 commits November 14, 2026 16:25
why: libtmux.org draws a "What is on here" table on the Java Server and
Session pages, and the Window and Pane pages had none, so a reader had
to scan every member to find how to split, send input or read output.
The site folds a bold-led paragraph followed by a references paragraph
or a `Label: refs` list into a row, and draws a table from three rows.

what:
- Add a "What is on here" section to the Window class doc with rows for
  reading the capture, panes, layout and size, moving and linking,
  changing the window, options and hooks, and formats and refreshing
- Add one to the Pane class doc with rows for reading the capture,
  sending input, reading output, running and waiting, splitting and
  arranging, modes, changing the pane, options and hooks, and formats
  and refreshing
- State per row what throws and what is a pure read of the capture,
  taken from each method's own doc and body
why: libtmux.org draws a "What is on here" table on the Kotlin Server
page only. Session, Window and Pane hold most of the operations a
reader looks for, and most of those are `suspend` extensions that the
member list shows apart from the type.

what:
- Add a "What is on here" section to the Session, Window and Pane KDoc,
  in the shape of the Server one: bold-led rows, each followed by a
  paragraph of references
- Link extension functions as `[name][Type.name]`, since several types
  share names such as kill, refresh and expand
- State that a property or plain function reads the capture and every
  `suspend` extension asks tmux, and that Pane's waits take their own
  dispatcher
why: libtmux.org shows the Scala Server directory on the scaladsl
Server page, which is an opaque type, and the Session, Window and Pane
pages had none. Their operations are extensions, so the member list
does not group them by job.

what:
- Add a "What is on here" section to the doc comment of the Session,
  Window and Pane opaque types, where the Server one lives
- Link every operation as `[[Type.name]]`, as the Server directory does
  for the operations of the other types
- State that an operation beyond a pure read of the capture blocks the
  calling thread, that results are `Vector` and `Option`, and that
  Pane's waits are cancelled by interrupting the thread

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant