Update by original

Author: h-east

doc/develop.jax

@@ -1,4 +1,4 @@
-*develop.txt*   For Vim バージョン 9.1.  Last change: 2025 Sep 04
+*develop.txt*   For Vim バージョン 9.1.  Last change: 2025 Sep 07
 
 
 		  VIMリファレンスマニュアル    by Bram Moolenaar

en/develop.txt

@@ -1,4 +1,4 @@
-*develop.txt*   For Vim version 9.1.  Last change: 2025 Sep 04
+*develop.txt*   For Vim version 9.1.  Last change: 2025 Sep 07
 
 
 		  VIM REFERENCE MANUAL    by Bram Moolenaar
@@ -448,13 +448,13 @@ For everything else use: >
 
 INDENTATION						*style-indentation*
 
-We use 4 space to indent the code. If you are using Vim to edit the source,
+We use 4 space to indent the code.  If you are using Vim to edit the source,
 you don't need to do anything due to the |modeline|.
 
 For other editors an `.editorconfig` is provided at the root of the repo.
 
 For the source files `sign.c` and `sound.c` and any new file use only spaces,
-no tabs. In addition, any new file must include a modeline with `set et` to
+no tabs.  In addition, any new file must include a modeline with `set et` to
 pass the indentation test.
 
 
@@ -539,7 +539,7 @@ Wrong: >
 
 TYPES							    *style-types*
 
-Use descriptive types. These are defined in src/vim.h, src/structs.h etc.
+Use descriptive types.  These are defined in src/vim.h, src/structs.h etc.
 Note that all custom types are postfixed with "_T"
 
 Example: >
@@ -739,7 +739,7 @@ number in order to reference each specific patch release.  A typical
 development release cycle may last several years and accumulate about 1500 -
 2500 patch numbers.
 
-Before a release is made, a stability period will be announced. During this
+Before a release is made, a stability period will be announced.  During this
 time, only clear bug fixes, security fixes, documentation changes, translation
 updates and runtime file updates will be accepted (provided they do not
 introduce backwards-incompatible changes), concentrating on polishing up the
@@ -755,8 +755,8 @@ preserve compatibility for the C core of Vim.  Runtime files are handled a bit
 more flexibly to give runtime files maintainers a chance to change old
 behaviour.
 
-Within a development cycle, features may be marked as deprecated. Deprecated
-features can be disabled at compile time through an appropriate switch. After
+Within a development cycle, features may be marked as deprecated.  Deprecated
+features can be disabled at compile time through an appropriate switch.  After
 a new release, deprecated features may be removed completely in a following
 cycle.