Merge pull request #1841 from h-east/change-style-to-normal_debug

Change style to normal: debug.jax

doc/debug.jax

@@ -6,169 +6,165 @@
 
 Vim のデバッグ						*debug-vim*
 
-Vim のデバッグ方法についての説明です。
-Vim script や関数などのデバッグについては、|debug-scripts| を参照してください。
+これは、Vim 自体が正しく動作しない場合にデバッグするためのものである。
+Vim script や関数などのデバッグについては、|debug-scripts| を参照。
 
 1. gcc と gdb を使ってクラッシュの場所を特定する	|debug-gcc|
-2. メモリリークの検出					|debug-leaks|
+2. メモリリークの特定					|debug-leaks|
 3. Windows でのバグレポート				|debug-win32|
 
 ==============================================================================
 
 1. gcc と gdb を使ってクラッシュの場所を特定する	*debug-gcc* *gdb*
 
-テストファイルで Vim がクラッシュした場合、gcc を使っているなら、以下の方法で
-場所を特定できます。MinGW でも同じようにできます。
+Vim がテストファイルの 1 つでクラッシュし、コンパイルに gcc を使用している場
+合、Vim がどこでクラッシュするかを正確に見つけるためにできることがある。これは
+MingW ツールを使用している場合にも当てはまる。
 
 1. "-g" オプション付きで Vim をコンパイル (src/Makefile にそのための行があるの
-   で、それをコメントアウトしてください)。さらに "strip" を無効化 (strip をイ
-   ンストールしないか、"STRIP = /bin/true" の行を使う)。
+   で、それをコメントアウトする)。さらに "strip" を無効化する (strip をインス
+   トールしないか、"STRIP = /bin/true" の行を使う)。
 
-2. 次のコマンドを実行 ("11" の所を失敗したテストの番号に変えてください): >
+2. 次のコマンドを実行する ("11" の所を失敗したテストの番号に変える): >
 	cd testdir
 	gdb ../vim
 	run -u unix.vim -U NONE -s dotest.in test11.in
 
-3. Vim のクラッシュを確認。gdb がメッセージを表示します。
+3. Vim のクラッシュを確認する。gdb は関連するメッセージを表示するはずである。
 
-4. 次のコマンドでスタックトレースを表示できます: >
+4. 次のコマンドでスタックトレースを表示できる: >
 	where
-<  次のコマンドで別の場所のスタックトレースを表示できます: >
+<  次のコマンドで別の場所のスタックトレースを表示できる: >
 	frame 3
-<  "3" のところにスタックトレースの番号を指定してください。
+<  "3" をスタックトレース内の番号の 1 つに置き換える。
 
 ==============================================================================
 
-2. メモリリークの検出				*debug-leaks* *valgrind*
+2. メモリリークの特定				*debug-leaks* *valgrind*
 
-もし Vim がメモリリークを起こしているような感じがして、そしてあなたが Linux を
-使っているなら、valgrind ツールを使うことでメモリリークをピンポイントで検出す
-ることができます。
+Linux を使っていて Vim がメモリリークしていると思われる場合は、メモリリークを
+正確に特定するのに valgrind ツールが非常に役立つ。
 
-まず、Vim を EXITFREE の定義付きでビルドします。MAKEFILE を検索して該当行のコ
-メントを外してください。
+まず、EXITFREE を定義して Vim をビルドする。MAKEFILE でこれを検索して、行のコ
+メントを外す。
 
-次のコマンドで Vim を起動してください:
+次のコマンドで Vim を起動する:
 >
 	valgrind --log-file=valgrind.log --leak-check=full ./vim
 
-Note: Vim の実行はとても遅くなります。.vimrc が大きかったり多くのプラグインを
-入れていたりすると起動にとても時間がかかるので、その場合は "--clean" 引数を指
-定して起動してみてください。
+Note: Vim の実行はとても遅くなる。.vimrc が大きかったり多くのプラグインを入れ
+ていたりすると起動にとても時間がかかるので、その場合は "--clean" 引数を指定し
+て起動する。
 
-ライブラリがメモリリークを起こしている場合もあります。例えば getpwuid() や
-XtVaAppCreateShell() などです。それらを避けることはできません。リークしている
-バイト数は数キロバイト以下のはずです。
+ライブラリがメモリリークを起こしている場合もよくある。例えば getpwuid() や
+XtVaAppCreateShell() など。それらを避けることはできない。リークしているバイト
+数は数キロバイト以下のはずである。
 
 ==============================================================================
 
 3. Windows でのバグレポート				*debug-win32*
 
 Windows版の Vim が再現可能な手段でクラッシュした場合、次の方法で有用なバグレ
-ポートを作成できます。
+ポートを作成できる。
 
 3.1 一般事項 ~
 
-実行可能ファイルに対応したデバッグシンボルファイル (PDB) を用意してください。
-gvim.exe には gvim.pdb、vim.exe には vim.pdb が必要です。あなたが実行可能ファ
-イルを入手したのと同じ場所に用意されているはずです。EXE に対応した (同じ日付の)
-PDB でなければいけません。
+実行可能ファイルに対応したデバッグシンボルファイル (PDB) を取得する必要がある。
+gvim.exe には gvim.pdb、vim.exe には vim.pdb が必要である。あなたが実行可能ファ
+イルを入手したのと同じ場所に用意されているはずである。EXE に対応した (同じ日付
+の) PDB でなければならない。
 
 Microsoft Visual C++ コンパイラを使って自分で実行可能ファイルを作成した場合は、
-PDB は EXE といっしょに作成されています。
+PDB は EXE と一緒に作成されている。
 
-Visual Studio を持っている場合はそれを使ってください。VC Toolkit と WinDbg は
-必要ありません。
+Visual Studio を持っている場合、VC Toolkit と WinDbg の代わりにそれを使用する。
 
-他のコンパイラを使っている場合は、それぞれ適切なデバッガを使ってください。
-Cygwin または MinGW のコンパイラなら gdb を使ってください (上記参照
-|debug-gcc|)。
+他のコンパイラを使っている場合は、それぞれ適切なデバッガを使用する必要がある。
+Cygwin または MinGW のコンパイラ用の gdb (上記参照 |debug-gcc|) など。
 
 
 								*debug-vs2005*
 3.2 Visual Studio 2005/Visual C++ 2005 Express で Vim をデバッグする ~
 
-vim.exe か gvim.exe を起動し、Visual Studio を起動してください。(Visual Studio
+最初に、vim.exe か gvim.exe を起動し、Visual Studio を起動する。(Visual Studio
 を持っていない場合は、|get-ms-debuggers| の説明に従って、無料の Visual C++
-2005 Express Edition を入手してください。)
+2005 Express Edition を入手する。)
 
-メニューから「ツール/プロセスにアタッチ」を選択し、Vim のプロセスを選択します。
+メニューから「ツール/プロセスにアタッチ」を選択し、Vim のプロセスを選択する。
 
-そして、Vim を操作してクラッシュを再現します。「ハンドルされていない例外が発生
-しました」という Visual Studio のダイアログが表示されるので、中断ボタンをク
-リックしてプロセスを中断してください。
+そして、Vim を操作してクラッシュを再現する。「ハンドルされていない例外が発生し
+ました」という Visual Studio のダイアログが表示されるので、中断ボタンをクリッ
+クしてプロセスを中断する。
 
-シンボルが読み込めず、ソースコードを表示できなかったときは、もう一つダイアログ
-が表示されます。OK をクリックしてください。
+シンボルが読み込めず、ソースコードを表示できなかったときは、もう 1 つダイアロ
+グが表示される。OK をクリックする。
 
-ウィンドウがいくつか開きます。呼び出し履歴ウィンドウの右クリックメニューから
-「シンボルの読み込み」を選択してください。シンボル検索ダイアログが開くので、
-(g)vim.pdb のあるディレクトリを選択してください。
+ウィンドウがいくつか開く。呼び出し履歴ウィンドウの右クリックメニューから「シン
+ボルの読み込み」を選択する。シンボル検索ダイアログが開くので、(g)vim.pdb のあ
+るディレクトリを選択する。
 
 このとき、呼び出し履歴ウィンドウには Vim の関数名や行番号が表示されているはず
-です。どれかをダブルクリックするとソースの検索ダイアログが表示されます。Vim の
-ソースがあるディレクトリを選択してください (もしソースがあるなら)。
+である。どれかをダブルクリックするとソースの検索ダイアログが表示される。Vim の
+ソースがあるディレクトリを選択する (ソースがあれば)。
 
 さらに詳しくデバッグする方法が分からないときは、":help bug-reports" の説明に
-従ってください。バグレポートに呼び出し履歴を貼り付けてください。
+従う。バグレポートに呼び出し履歴を貼り付ける。
 
 有料版の Visual Studio を使っている場合は、デバッグメニューから minidump を保
-存できるので、それをバグレポートに添付してください。minidump は 100KB 以下の小
-さなファイルで、Vim のプロセスに関する情報が入っています。
-Visual C++ 2005 Express Edition では minidump を保存できません。just-in-time
-デバッガ (クラッシュを検出して自動的に起動されるデバッガ) もインストールされま
-せん。それらが必要なときは WinDbg (|debug-windbg|) を使ってください。
+存できるので、それをバグレポートに添付する。minidump は 100KB 以下の小さなファ
+イルで、Vim のプロセスに関する情報が入っている。
+Visual C++ 2005 Express Edition では minidump を保存できない。just-in-time デ
+バッガ (クラッシュを検出して自動的に起動されるデバッガ) もインストールされな
+い。それらが必要なときは WinDbg (|debug-windbg|) を使う。
 
 								*debug-windbg*
 3.3 WinDbg を使って Vim をデバッグする ~
 
-WinDbg の入手方法は |get-ms-debuggers| を参照してください。
+WinDbg の入手方法は |get-ms-debuggers| を参照。
 
 Visual Studio IDE を使うのと同じように、WinDbg から Vim のプロセスにアタッチで
-きます。プログラムがクラッシュしたときに、事後分析デバッガ (postmortem
-debugger) として、WinDebug を自動的に起動することができます。事後分析デバッガ
-として WinDeb を設定するには "windbg -I" を実行してください。
+きる。プログラムがクラッシュしたときに、事後分析デバッガ (postmortem debugger)
+として、WinDebug を自動的に起動することができる。事後分析デバッガとして WinDeb
+を設定するには "windbg -I" を実行する。
 
 WinDbg から、実行中の Vim のプロセスにアタッチするには、WinDeb を起動し、File
 メニューから「プロセスにアタッチ」を選択し、Vim のプロセスを選択して OK をク
-リックします。
+リックする。
 
 メニューから「File->Symbol File Path」を選択し、Vim PDB の入っているフォルダを
-symbolpath に追加してください。Vim のソースファイルもある場合は、File メニュー
-のSource File Path を使ってください。WinDbg でソースファイルを開いたり、ブレー
-クポイントを設定したりできます。Vim をクラッシュさせると、クラッシュした場所の
-ソースファイルが WinDbg で開かれます。View メニューを使って、コールスタック、
-ローカル変数、ウォッチウィンドウなどを見ることができます。
+symbolpath に追加する。Vim のソースファイルもある場合は、File メニューの
+Source File Path を使う。WinDbg でソースファイルを開いたり、ブレークポイントを
+設定したりできる。Vim をクラッシュさせると、クラッシュした場所のソースファイル
+が WinDbg で開かれる。View メニューを使って、コールスタック、ローカル変数、
+ウォッチウィンドウなどを見ることができる。
 
 事後分析デバッガとして WinDbg を使っている場合、WinDbg から Vim のプロセスにア
-タッチする必要はありません。Vim をクラッシュさせるだけで WinDbg が自動的に起動
-します。上述のように、シンボルファイルパスとソースファイルパスを設定してくださ
-い。
+タッチする必要はない。Vim をクラッシュさせるだけで WinDbg が自動的に起動する。
+上述のように、シンボルファイルパスとソースファイルパスを設定する。
 
-minidump を保存するには、WinDbg コマンドラインで次のコマンドを入力します: >
+minidump を保存するには、WinDbg コマンドラインで次のコマンドを入力する: >
         .dump vim.dmp
 <
 							*debug-minidump*
 3.4 Minidump を開く ~
 
-Visual Studio か WinDbg を使って minidump を開くことができます。
+Visual Studio か WinDbg を使って minidump を開くことができる。
 
 Visual Studio 2005 の場合: メニューから「ファイル->開く->プロジェクト/ソリュー
-ション」選択し、.dmp ファイルを開いてください。F5 キーを押してデバッガを起動し
-ます。Symbol File Path の設定について |debug-vs2005| の説明も参照してくださ
-い。
+ション」選択し、.dmp ファイルを開く。F5 キーを押してデバッガを起動する。
+|debug-vs2005| の指示に従って Symbol File Path を設定する。
 
-WinDbg の場合: メニューから「File->Open Crash Dump」を選択します。Symbol File
-Pathの設定について |debug-windbg| の説明も参照してください。
+WinDbg の場合: メニューから「File->Open Crash Dump」を選択する。|debug-windbg|
+の指示に従って Symbol File Path を設定する。
 
 							*get-ms-debuggers*
 3.5 Microsoft デバッグツールの入手方法 ~
 
-Windows 用のデバッグツールは次の場所からダウンロードできます
+Windows 用のデバッグツールは次の場所からダウンロードできる
     https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
-これには WinDbg デバッガが含まれています。
+これには WinDbg デバッガが含まれている。
 
-Visual C++ 2005 Express Edition は次の場所からダウンロードできます。無料です。
+Visual C++ 2005 Express Edition は次の場所から無料でダウンロードできる。
     http://msdn.microsoft.com/vstudio/express/visualC/default.aspx
 
 =========================================================================