NOISSUE rebrand vim to MNV's not Vim

Signed-off-by: Mehmet Samet Duman <yongdohyun@projecttick.org>

1 files changed, 35 insertions, 35 deletions

diff --git a/uvim/runtime/doc/debug.txt b/uvim/runtime/doc/debug.txt
index 17280db77b..1464632a1d 100644
--- a/uvim/runtime/doc/debug.txt
+++ b/uvim/runtime/doc/debug.txt
@@ -1,13 +1,13 @@
-*debug.txt*	For Vim version 9.2.  Last change: 2026 Feb 14
+*debug.txt*	For MNV version 9.2.  Last change: 2026 Feb 14
 
 
-		  VIM REFERENCE MANUAL	  by Bram Moolenaar
+		  MNV REFERENCE MANUAL	  by Bram Moolenaar
 
 
-Debugging Vim						*debug-vim*
+Debugging MNV						*debug-mnv*
 
-This is for debugging Vim itself, when it doesn't work properly.
-For debugging Vim scripts, functions, etc. see |debug-scripts|
+This is for debugging MNV itself, when it doesn't work properly.
+For debugging MNV scripts, functions, etc. see |debug-scripts|
 
 1. Location of a crash, using gcc and gdb	|debug-gcc|
 2. Locating memory leaks			|debug-leaks|
@@ -17,20 +17,20 @@ For debugging Vim scripts, functions, etc. see |debug-scripts|
 
 1. Location of a crash, using gcc and gdb		*debug-gcc* *gdb*
 
-When Vim crashes in one of the test files, and you are using gcc for
-compilation, here is what you can do to find out exactly where Vim crashes.
+When MNV crashes in one of the test files, and you are using gcc for
+compilation, here is what you can do to find out exactly where MNV crashes.
 This also applies when using the MingW tools.
 
-1. Compile Vim with the "-g" option (there is a line in the src/Makefile for
+1. Compile MNV with the "-g" option (there is a line in the src/Makefile for
    this, which you can uncomment).  Also make sure "strip" is disabled (do not
    install it, or use the line "STRIP = /bin/true").
 
 2. Execute these commands (replace "11" with the test that fails): >
 	cd testdir
-	gdb ../vim
-	run -u unix.vim -U NONE -s dotest.in test11.in
+	gdb ../mnv
+	run -u unix.mnv -U NONE -s dotest.in test11.in
 
-3. Check where Vim crashes, gdb should give a message for this.
+3. Check where MNV crashes, gdb should give a message for this.
 
 4. Get a stack trace from gdb with this command: >
 	where
@@ -42,17 +42,17 @@ This also applies when using the MingW tools.
 
 2. Locating memory leaks			*debug-leaks* *valgrind*
 
-If you suspect Vim is leaking memory and you are using Linux, the valgrind
+If you suspect MNV is leaking memory and you are using Linux, the valgrind
 tool is very useful to pinpoint memory leaks.
 
-First of all, build Vim with EXITFREE defined.  Search for this in MAKEFILE
+First of all, build MNV with EXITFREE defined.  Search for this in MAKEFILE
 and uncomment the line.
 
-Use this command to start Vim:
+Use this command to start MNV:
 >
-	valgrind --log-file=valgrind.log --leak-check=full ./vim
+	valgrind --log-file=valgrind.log --leak-check=full ./mnv
 
-Note: Vim will run much slower.  If your .vimrc is big or you have several
+Note: MNV will run much slower.  If your .mnvrc is big or you have several
 plugins you need to be patient for startup, or run with the "--clean"
 argument.
 
@@ -64,14 +64,14 @@ very small a Kbyte or less.
 
 3. Windows Bug Reporting				*debug-win32*
 
-If the Windows version of Vim crashes in a reproducible manner, you can take
+If the Windows version of MNV crashes in a reproducible manner, you can take
 some steps to provide a useful bug report.
 
 
 3.1 GENERIC ~
 
-You must obtain the debugger symbols (PDB) file for your executable: gvim.pdb
-for gvim.exe, or vim.pdb for vim.exe.  The PDB should be available from the
+You must obtain the debugger symbols (PDB) file for your executable: gmnv.pdb
+for gmnv.exe, or mnv.pdb for mnv.exe.  The PDB should be available from the
 same place that you obtained the executable.  Be sure to use the PDB that
 matches the EXE (same date).
 
@@ -85,28 +85,28 @@ For other compilers, you should always use the corresponding debugger: gdb
 
 
 								*debug-vs2005*
-3.2 Debugging Vim crashes with Visual Studio 2005/Visual C++ 2005 Express ~
+3.2 Debugging MNV crashes with Visual Studio 2005/Visual C++ 2005 Express ~
 
-First launch vim.exe or gvim.exe and then launch Visual Studio.  (If you don't
+First launch mnv.exe or gmnv.exe and then launch Visual Studio.  (If you don't
 have Visual Studio, follow the instructions at |get-ms-debuggers| to obtain a
 free copy of Visual C++ 2005 Express Edition.)
 
-On the Tools menu, click Attach to Process.  Choose the Vim process.
+On the Tools menu, click Attach to Process.  Choose the MNV process.
 
-In Vim, reproduce the crash.  A dialog will appear in Visual Studio, telling
-you about the unhandled exception in the Vim process.  Click Break to break
+In MNV, reproduce the crash.  A dialog will appear in Visual Studio, telling
+you about the unhandled exception in the MNV process.  Click Break to break
 into the process.
 
 Visual Studio will pop up another dialog, telling you that no symbols are
 loaded and that the source code cannot be displayed.  Click OK.
 
 Several windows will open.  Right-click in the Call Stack window.  Choose Load
-Symbols.  The Find Symbols dialog will open, looking for (g)vim.pdb.  Navigate
+Symbols.  The Find Symbols dialog will open, looking for (g)mnv.pdb.  Navigate
 to the directory where you have the PDB file and click Open.
 
-At this point, you should have a full call stack with vim function names and
+At this point, you should have a full call stack with mnv function names and
 line numbers.  Double-click one of the lines and the Find Source dialog will
-appear.  Navigate to the directory where the Vim source is (if you have it.)
+appear.  Navigate to the directory where the MNV source is (if you have it.)
 
 If you don't know how to debug this any further, follow the instructions
 at ":help bug-reports".  Paste the call stack into the bug report.
@@ -119,30 +119,30 @@ installed as a just-in-time debugger.  Use WinDbg, |debug-windbg|, if you
 need to save minidumps or you want a just-in-time (postmortem) debugger.
 
 								*debug-windbg*
-3.3 Debugging Vim crashes with WinDbg ~
+3.3 Debugging MNV crashes with WinDbg ~
 
 See |get-ms-debuggers| to obtain a copy of WinDbg.
 
-As with the Visual Studio IDE, you can attach WinDbg to a running Vim process.
+As with the Visual Studio IDE, you can attach WinDbg to a running MNV process.
 You can also have your system automatically invoke WinDbg as a postmortem
 debugger.  To set WinDbg as your postmortem debugger, run "windbg -I".
 
-To attach WinDbg to a running Vim process, launch WinDbg.  On the File menu,
-choose Attach to a Process.  Select the Vim process and click OK.
+To attach WinDbg to a running MNV process, launch WinDbg.  On the File menu,
+choose Attach to a Process.  Select the MNV process and click OK.
 
 At this point, choose Symbol File Path on the File menu, and add the folder
-containing your Vim PDB to the sympath.  If you have Vim source available,
+containing your MNV PDB to the sympath.  If you have MNV source available,
 use Source File Path on the File menu.  You can now open source files in
 WinDbg and set breakpoints, if you like.  Reproduce your crash.  WinDbg should
 open the source file at the point of the crash.  Using the View menu, you can
 examine the call stack, local variables, watch windows, and so on.
 
 If WinDbg is your postmortem debugger, you do not need to attach WinDbg to
-your Vim process.  Simply reproduce the crash and WinDbg will launch
+your MNV process.  Simply reproduce the crash and WinDbg will launch
 automatically.  As above, set the Symbol File Path and the Source File Path.
 
 To save a minidump, type the following at the WinDbg command line: >
-        .dump vim.dmp
+        .dump mnv.dmp
 <
 							*debug-minidump*
 3.4 Opening a Minidump ~
@@ -167,4 +167,4 @@ Visual C++ 2005 Express Edition can be downloaded for free from:
     https://visualstudio.microsoft.com/
 
 =========================================================================
- vim:tw=78:ts=8:noet:ft=help:norl:
+ mnv:tw=78:ts=8:noet:ft=help:norl: