More docstring tweaking.

src/controller/facade.rs

@@ -1,7 +1,8 @@
-//! This module bundles up the public-facing interface of the controller for ease
-//! of import into the bridge. It's the Rust equivalent of the helpers class over
-//! on the C++ side. It can include any logic that doesn't demand the controller.
-//! In particular, it includes a lot of support for papyrus functions.
+//! This module bundles up the public-facing interface of the controller for
+//! ease of import into the bridge. It's the Rust equivalent of the helpers
+//! class over on the C++ side. It can directly implement any logic that doesn't
+//! demand the controller. In particular, it implements some support for
+//! papyrus functions.
 
 use cxx::CxxVector;
 
@@ -136,7 +137,7 @@ pub fn cycle_loaded_from_cosave(bytes: &CxxVector<u8>, version: u32) {
         ctrl.refresh_after_load();
         log::info!("Cycles loaded and ready to rock.");
     } else {
-        log::warn!("Cosave load failed. Defaulting to fresh start.");
+        log::warn!("Cosave load failed. Defaulting to fresh start. Is your save corrupt?");
     }
 }
 

src/controller/settings.rs

@@ -1,7 +1,7 @@
-//! User-controlled settings. Reads the INI file written by MCM.
-//! Provides an interface for all settings data to C++ and Rust both.
-//! Does some data validation and some translation from older versions,
-//! but this file is otherwise all fairly predictable.
+//! User-controlled settings. Reads the INI file written by MCM. Provides an
+//! interface for all settings data to C++ and Rust both. Does some data
+//! validation and some translation from older versions, but this file is
+//! otherwise all fairly predictable.
 
 use std::sync::Mutex;
 

src/images/icons.rs

@@ -1,24 +1,24 @@
 //! All usable icons are defined here as enum variants.
 //!
-//! To add a new icon, you must add a variant name here AND add the
-//! variant to `fallback()`, so the HUD renders something if the file
-//! is missing (e.g., an icon pack dose not include it). If the icon is
-//! added to the core set in the main mod, it is its own fallback and can
-//! be a fallback target. (A test validates that all fallbacks are valid.)
+//! To add a new icon, you must add a variant name here AND add the variant to
+//! `fallback()`, so the HUD renders something if the file is missing (e.g., an
+//! icon pack dose not include it). If the icon is added to the core set in the
+//! main mod, it is its own fallback and can be a fallback target. (A test
+//! validates that all fallbacks are valid.)
 //!
-//! You should then add a file for the icon in one of the icon packs or the
-//! core set. The name of the file *must* be the enum variation name in
-//! snake_case. That is, an icon variant named `SnakeCase` maps to `snake_case.svg`.
+//! You should then add a file for the icon in one of the icon packs or the core
+//! set. The name of the file *must* be the enum variation name in snake_case.
+//! That is, an icon variant named `SnakeCase` maps to `snake_case.svg`.
 //!
 //! When naming icons, follow the principle of most general -> most specific.
 //! For example `ArmorLightHands` starts with the general category of armor,
-//! then narrows it down to light armor, then picks out hands specifically.
-//! This approach makes related icons sort together, which makes them easier
-//! to edit or preview in groups.
+//! then narrows it down to light armor, then picks out hands specifically. This
+//! approach makes related icons sort together, which makes them easier to edit
+//! or preview in groups.
 //!
-//! Top-level icon name categories sort of match data types in the data/ submodule.
-//! Ammo, Armor, Food (Drink also categorized here), Potion, Power, Shout, Spell,
-//! Weapon. This could be tidier.
+//! Top-level icon name categories sort of match data types in the data/
+//! submodule. Ammo, Armor, Food (Drink also categorized here), Potion, Power,
+//! Shout, Spell, Weapon. This could be tidier.
 
 use strum::{Display, EnumString, EnumVariantNames};
 

src/images/svg.rs

@@ -1,8 +1,9 @@
-//! Rasterize svgs and provide them to the C++ side. C++ controls whether the svgs
-//! are preloaded or lazily loaded. This uses the `resvg` crate which supports
-//! nearly all of the svg standard, with the notable exception of animation. This
-//! module also maintains a mapping of icon key to the icon file found for that
-//! path after fallbacks, so icon data is loaded at most once.
+//! Rasterize svgs and provide them to the C++ side. C++ controls whether the
+//! svgs are preloaded or lazily loaded. This uses the `resvg` crate which
+//! supports nearly all of the svg standard, with the notable exception of
+//! animation. This module also maintains a mapping of icon key to the icon file
+//! found for that path after fallbacks, so icon data is loaded at most once.
+
 use std::collections::HashMap;
 use std::path::PathBuf;
 use std::str::FromStr;

src/layouts/layout_v1.rs

@@ -1,7 +1,7 @@
 //! The layout for the HUD is read from a TOML file. This data is shared between
 //! languages the same way that the user settings are. The Rust side reads the
-//! toml; the C++ side uses the data in layout. The majority of the implementation
-//! is filing in defaults.
+//! toml; the C++ side uses the data in layout. The majority of the
+//! implementation is filing in defaults.
 
 #![allow(non_snake_case, non_camel_case_types)]
 

src/layouts/layout_v2.rs

@@ -1,3 +1,6 @@
+//! Version 2 of the layout schema. This version is the only one that gets
+//! new features-- v1 is to be retired gently over time.
+
 use eyre::{Context, Result};
 use serde::{Deserialize, Serialize};
 

src/layouts/shared.rs

@@ -1,3 +1,6 @@
+//! Types shared by all layout variations, including implementations on
+//! types defined in lib.rs.
+
 use std::fmt::Display;
 
 use serde::de::{Deserializer, Error};