Cleanup: spelling

3 files changed, 22 insertions, 25 deletions

diff --git a/intern/ghost/intern/GHOST_SystemX11.cpp b/intern/ghost/intern/GHOST_SystemX11.cpp
index 2b1069f9acc..c5564e9880e 100644
--- a/intern/ghost/intern/GHOST_SystemX11.cpp
+++ b/intern/ghost/intern/GHOST_SystemX11.cpp
@@ -1044,33 +1044,30 @@ void GHOST_SystemX11::processEvent(XEvent *xe)
       GHOST_TKey gkey;
 
 #ifdef USE_NON_LATIN_KB_WORKAROUND
-      /* XXX Code below is kinda awfully convoluted... Issues are:
-       *
-       *     - In keyboards like latin ones, numbers need a 'Shift' to be accessed but key_sym
-       *       is unmodified (or anyone swapping the keys with xmodmap).
-       *
-       *     - XLookupKeysym seems to always use first defined keymap (see T47228), which generates
-       *       keycodes unusable by ghost_key_from_keysym for non-Latin-compatible keymaps.
+      /* XXX: Code below is kinda awfully convoluted... Issues are:
+       * - In keyboards like latin ones, numbers need a 'Shift' to be accessed but key_sym
+       *   is unmodified (or anyone swapping the keys with `xmodmap`).
+       * - #XLookupKeysym seems to always use first defined key-map (see T47228), which generates
+       *   key-codes unusable by ghost_key_from_keysym for non-Latin-compatible key-maps.
        *
        * To address this, we:
-       *
-       *     - Try to get a 'number' key_sym using XLookupKeysym (with virtual shift modifier),
-       *       in a very restrictive set of cases.
-       *     - Fallback to XLookupString to get a key_sym from active user-defined keymap.
+       * - Try to get a 'number' key_sym using #XLookupKeysym (with virtual shift modifier),
+       *   in a very restrictive set of cases.
+       * - Fallback to #XLookupString to get a key_sym from active user-defined key-map.
        *
        * Note that:
-       *     - This effectively 'lock' main number keys to always output number events
-       *       (except when using alt-gr).
-       *     - This enforces users to use an ASCII-compatible keymap with Blender -
-       *       but at least it gives predictable and consistent results.
+       * - This effectively 'lock' main number keys to always output number events
+       *   (except when using alt-gr).
+       * - This enforces users to use an ASCII-compatible key-map with Blender -
+       *   but at least it gives predictable and consistent results.
        *
        * Also, note that nothing in XLib sources [1] makes it obvious why those two functions give
-       * different key_sym results...
+       * different key_sym results.
        *
        * [1] http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/KeyBind.c
        */
       KeySym key_sym_str;
-      /* Mode_switch 'modifier' is AltGr - when this one or Shift are enabled,
+      /* Mode_switch 'modifier' is `AltGr` - when this one or Shift are enabled,
        * we do not want to apply that 'forced number' hack. */
       const unsigned int mode_switch_mask = XkbKeysymToModifiers(xke->display, XK_Mode_switch);
       const unsigned int number_hack_forbidden_kmods_mask = mode_switch_mask | ShiftMask;
diff --git a/intern/ghost/intern/GHOST_WindowWin32.cpp b/intern/ghost/intern/GHOST_WindowWin32.cpp
index 4f85e2ea8d0..1b73b765b49 100644
--- a/intern/ghost/intern/GHOST_WindowWin32.cpp
+++ b/intern/ghost/intern/GHOST_WindowWin32.cpp
@@ -136,7 +136,7 @@ GHOST_WindowWin32::GHOST_WindowWin32(GHOST_SystemWin32 *system,
 
   RegisterTouchWindow(m_hWnd, 0);
 
-  /* Register as droptarget. OleInitialize(0) required first, done in GHOST_SystemWin32. */
+  /* Register as drop-target. #OleInitialize(0) required first, done in GHOST_SystemWin32. */
   m_dropTarget = new GHOST_DropTargetWin32(this, m_system);
   ::RegisterDragDrop(m_hWnd, m_dropTarget);
 
diff --git a/source/blender/blenkernel/intern/mesh_normals.c b/source/blender/blenkernel/intern/mesh_normals.c
index 02f21cf1b24..9f09ce46e11 100644
--- a/source/blender/blenkernel/intern/mesh_normals.c
+++ b/source/blender/blenkernel/intern/mesh_normals.c
@@ -715,7 +715,7 @@ void BKE_lnor_space_custom_normal_to_data(MLoopNorSpace *lnor_space,
                                           const float custom_lnor[3],
                                           short r_clnor_data[2])
 {
-  /* We use null vector as NOP custom normal (can be simpler than giving autocomputed lnor...). */
+  /* We use null vector as NOP custom normal (can be simpler than giving auto-computed `lnor`). */
   if (is_zero_v3(custom_lnor) || compare_v3v3(lnor_space->vec_lnor, custom_lnor, 1e-4f)) {
     r_clnor_data[0] = r_clnor_data[1] = 0;
     return;
@@ -768,7 +768,7 @@ void BKE_lnor_space_custom_normal_to_data(MLoopNorSpace *lnor_space,
 typedef struct LoopSplitTaskData {
   /* Specific to each instance (each task). */
 
-  /** We have to create those outside of tasks, since afaik memarena is not threadsafe. */
+  /** We have to create those outside of tasks, since #MemArena is not thread-safe. */
   MLoopNorSpace *lnor_space;
   float (*lnor)[3];
   const MLoop *ml_curr;
@@ -924,7 +924,7 @@ static void mesh_edges_sharp_tag(LoopSplitTaskDataCommon *data,
  * Define sharp edges as needed to mimic 'autosmooth' from angle threshold.
  *
  * Used when defining an empty custom loop normals data layer,
- * to keep same shading as with autosmooth!
+ * to keep same shading as with auto-smooth!
  */
 void BKE_edges_sharp_from_angle_set(const struct MVert *mverts,
                                     const int UNUSED(numVerts),
@@ -1481,11 +1481,11 @@ static void loop_split_generator(TaskPool *pool, LoopSplitTaskDataCommon *common
        * If we find a new, never-processed cyclic smooth fan, we can do it now using that loop/edge
        * as 'entry point', otherwise we can skip it. */
 
-      /* Note: In theory, we could make loop_split_generator_check_cyclic_smooth_fan() store
+      /* Note: In theory, we could make #loop_split_generator_check_cyclic_smooth_fan() store
        * mlfan_vert_index'es and edge indexes in two stacks, to avoid having to fan again around
-       * the vert during actual computation of clnor & clnorspace. However, this would complicate
-       * the code, add more memory usage, and despite its logical complexity,
-       * loop_manifold_fan_around_vert_next() is quite cheap in term of CPU cycles,
+       * the vert during actual computation of `clnor` & `clnorspace`.
+       * However, this would complicate the code, add more memory usage, and despite its logical
+       * complexity, #loop_manifold_fan_around_vert_next() is quite cheap in term of CPU cycles,
        * so really think it's not worth it. */
       if (!IS_EDGE_SHARP(e2l_curr) && (BLI_BITMAP_TEST(skip_loops, ml_curr_index) ||
                                        !loop_split_generator_check_cyclic_smooth_fan(mloops,