New update time.  Let's see what I've been up to.

You can now add links to web-based repository sites like GitHub to your documentation.  After you do, whenever you hover over a prototype a tab will pop up with a link to its source code:

It works for class prototypes too:

But what if more than one file defines something, like how C++ has header and source files?  I got you:

You can see it working live on Natural Docs' own documentation.

To add this to your project, edit Project.txt and add "[Site Name] Repository: [Project URL]" under the Source Folder heading.  If you have multiple Source Folder lines they would each need their own:

Source Folder: C:\My Project\src

   GitHub Repository: https://github.com/MyUserName/MyProject/

If you're using GitHub, Codeberg, or Gitea that's all you need.  If you're using GitLab or you want links to go to a specific branch, add the line "Branch: [Branch Name]" underneath it.  (GitLab doesn't have a way to link to the trunk without knowing its name, so you have to specify whether it's "master" or "main".)

If you use a different site you have to tell Natural Docs how to link to source files.  Add a "Link Template: [URL]" line underneath with {File} and {LineNumber} used to represent where the file path and line number should go.  For example:

Source Folder: C:\My Project\src

   Repository: https://mysite.com/repo
      Link Template: https://mysite.com/repo/src/{File}#L{LineNumber}

The repository name and project link aren't otherwise used yet, but they'll probably be added to the menu somewhere in a later release.

Are there any other major repository sites you use?  Building in support would mean people wouldn't have to define the link template manually.  I know there are others like Azure Repos but I couldn't find public projects to test them out.  E-mail me if you use one; there's only three or four questions I would need answered and they're pretty straightforward.

So... I may have undersold the speed increase of moving to native binaries when I announced development release 1.  I only tested macOS, and the source and output folders were on network shares which muted the results.  I ran them again with everything local and, well, Natural Docs 2.4 DR1 actually cuts 73% off the run time when doing a full rebuild.  Yes, running a native binary on Apple silicon without Mono and Rosetta removes almost three quarters of the run time.

It's faster on Windows too!  Running a native x64 binary cuts 41% off the run time versus running it through the .NET Framework.

Things were tweaked a bit further for development release 2.  I moved from .NET 8 to .NET 10, which has new compiler optimizations, and I made a customized build of SQLite that cut out a bunch of things I don't use.  The results are a tiny additional speed bump over DR1, most pronounced on Windows.

The only tradeoff is that Natural Docs now requires macOS 12 Monterey.  Development release 1 supported back to macOS 10.15 Catalina, but the move from .NET 8 to .NET 10 bumped up the requirements.

So yeah, if you aren't already using the development releases I would highly recommend doing so!

As I mentioned last time, I was thinking about requiring Javadoc or XML comment symbols for quick documentation, since that would prevent it from being triggered accidentally.  It's only one extra character, and it more clearly shows that the comment is intended to be documentation.  It's been implemented, so now you use it like this:

/* Enum: Colors
 */
public enum Colors {
   Red,   /// The color of apples
   Green, /// The color of grass, but also some apples
   Blue } /** The color of the sky, but not apples */

Note that this is only for the comment symbols, meaning you have to use /// or /** and */.  It does not mean you have to format the comment contents in Javadoc or XML, so you can still use Natural Docs formatting like *bold* and <links>.

• C# has minor parser fixes, now supporting nullable appearing after array brackets like "int[]?", a comma trailing the last value in an enum like "enum X { A, B, C, }", and using enums with the Documented Only setting.

• PowerShell function prototype formatting has been fixed.  It also detects types like [string].

• PowerShell now supports <# #> block comments.

• Prototype parameters that have multiple metadata blocks get formatted better, breaking them out into their own lines.  This is useful for PowerShell where each parameter can potentially have several modifiers, but it can happen in other languages as well.

• Other smaller fixes and improvements.