Improve codespell setup for direct usage and CI

Running `codespell` directly in a terminal at the project root now
acts identical to CI, making local runs faster and easier.

This also removes the redundant `codespell-ignore-lines.txt`
which had no effect anymore, as the original image it was referencing
was renamed or removed.

Some redundant ignore entries were also removed.

.pre-commit-config.yaml

@@ -6,7 +6,6 @@ repos:
     rev: v2.3.0
     hooks:
       - id: codespell
-        files: ^(about|community|engine_details|getting_started|tutorials)/.*\.rst$
         additional_dependencies: [tomli]
 
   - repo: https://github.com/pre-commit/pre-commit-hooks

_tools/codespell-ignore-lines.txt

@@ -1 +0,0 @@
-.. image:: img/expres.png

_tools/codespell-ignore.txt

@@ -1,8 +1,5 @@
 doubleclick
-dof
 lod
-que
-raison
 uint
 implementors
 thirdparty

pyproject.toml

@@ -4,5 +4,13 @@ line-length = 120
 [tool.codespell]
 dictionary = ["_tools/codespell-dict.txt", "-"]
 ignore-words = "_tools/codespell-ignore.txt"
-exclude-file = "_tools/codespell-ignore-lines.txt"
-skip = "tutorials/i18n/locales.rst"
+skip = [
+    "_build/*",
+    "_static/*",
+    "_styleguides/*",
+    "classes/*",
+    ".github/*",
+    "tutorials/i18n/locales.rst",
+    "AUTHORS.md",
+    "LICENSE.txt",
+]

tutorials/3d/global_illumination/using_lightmap_gi.rst

@@ -125,7 +125,7 @@ their UV2 maps properly generated.
 .. warning::
 
     When reusing a mesh within a scene, keep in mind that UVs will be generated
-    for the first instance found. If the mesh is re-used with different scales
+    for the first instance found. If the mesh is reused with different scales
     (and the scales are wildly different, more than half or twice), this will
     result in inefficient lightmaps. To avoid this, adjust the **Lightmap
     Scale** property in the GeometryInstance3D section of a MeshInstance3D node.

tutorials/3d/procedural_geometry/meshdatatool.rst

@@ -14,7 +14,7 @@ for certain mesh algorithms. If you do not need this extra information then it m
 .. note:: MeshDataTool can only be used on Meshes that use the PrimitiveType ``Mesh.PRIMITIVE_TRIANGLES``.
 
 We initialize the MeshDataTool from an ArrayMesh by calling :ref:`create_from_surface() <class_meshdatatool_method_create_from_surface>`. If there is already data initialized in the MeshDataTool,
-calling ``create_from_surface()`` will clear it for you. Alternatively, you can call :ref:`clear() <class_meshdatatool_method_clear>` yourself before re-using the MeshDataTool.
+calling ``create_from_surface()`` will clear it for you. Alternatively, you can call :ref:`clear() <class_meshdatatool_method_clear>` yourself before reusing the MeshDataTool.
 
 In the examples below, assume an ArrayMesh called ``mesh`` has already been created. See :ref:`ArrayMesh tutorial <doc_arraymesh>` for an example of mesh generation.
 

tutorials/best_practices/scene_organization.rst

@@ -17,7 +17,7 @@ They create their first scene and fill it with content only to eventually end
 up saving branches of their scene into separate scenes as the nagging feeling
 that they should split things up starts to accumulate. However, they then
 notice that the hard references they were able to rely on before are no longer
-possible. Re-using the scene in multiple places creates issues because the
+possible. Reusing the scene in multiple places creates issues because the
 node paths do not find their targets and signal connections established in the
 editor break.
 

tutorials/best_practices/scenes_versus_scripts.rst

@@ -196,7 +196,7 @@ Conclusion
 
 In the end, the best approach is to consider the following:
 
-- If one wishes to create a basic tool that is going to be re-used in several
+- If one wishes to create a basic tool that is going to be reused in several
   different projects and which people of all skill levels will likely use
   (including those who don't label themselves as "programmers"), then chances
   are that it should probably be a script, likely one with a custom name/icon.

tutorials/xr/a_better_xr_start_script.rst

@@ -246,7 +246,7 @@ Not matching the physics update rate will cause stuttering as frames are rendere
 
         # Now match our physics rate
         Engine.physics_ticks_per_second = current_refresh_rate
- 
+
     ...
 
   .. code-tab:: csharp
@@ -342,7 +342,7 @@ If you haven't, you can connect a method to the signal that performs additional
             get_tree().paused = true
 
             emit_signal("focus_lost")
- 
+
     ...
 
   .. code-tab:: csharp
@@ -506,6 +506,6 @@ Often it is enough to call :ref:`center_on_hmd() <class_XRServer_method_center_o
         }
     }
 
-And that finished our script. It was written so that it can be re-used over multiple projects.
+And that finished our script. It was written so that it can be reused over multiple projects.
 Just add it as the script on your main node (and extend it if needed)
 or add it on a child node specific for this script.