Better Docstrings in Godot: GDScript LSP and BBCode to Markdown

Why this matters more than it first appears

Documentation comments are not just notes for humans reading raw source files. In a modern editor pipeline, they become part of the interface. Hover information, signature help, class reference excerpts, and other language-server features rely on that text being converted correctly. Once formatting breaks, the editor starts feeling less trustworthy even when the underlying code still works.

What the PR is fixing

The discussion around PR #113099 explains that the older conversion approach had important coverage gaps. It handled BBCode through relatively simple pattern replacement, but did not account for all documented tags and missed some cases that users now expect to render properly across tools.

The rework extends support to the BBCode tags documented in the GDScript documentation comments page, adds handling for special codeblock syntax across multiple languages, and backs the behavior with unit tests. That combination matters because formatting code without tests tends to regress in subtle ways.

Why Markdown conversion is the right bridge

Many tools in the broader editor ecosystem already understand Markdown better than engine-specific BBCode. Converting Godot-style doc comments into Markdown gives the language server a more portable and editor-friendly representation. That improves how comments survive across different clients and extensions without forcing every consumer to reimplement Godot-specific rendering rules from scratch.

The editor-quality angle

This is the kind of change that makes a language feel more complete. The core scripting system does not become faster because of it, but the workflow becomes smoother. Better docs in hover popups, cleaner formatting in tooltips, and more reliable code block rendering all reduce friction when moving through unfamiliar APIs or reviewing code you wrote months earlier.

Why the tests are not a side detail

String conversion features usually fail at the boundaries: nested tags, unexpected tag order, incomplete formatting, or edge cases in fenced code. Unit tests are what keep those cases from quietly breaking later. In this PR, the tests signal that the feature is being treated as part of tooling quality rather than as a one-off patch.

The bigger takeaway

Strong engines do not only improve rendering, physics, or platform support. They also improve how ideas move from code to the editor surface. PR #113099 matters because it tightens that path. Better conversion means better tooling, and better tooling changes how pleasant an engine feels every day.