File:  [Local Repository] / gnujdoc / emacs-20.6 / trouble-ja.texi
Revision 1.1: download - view: text, annotated - select for diffs
Wed Apr 26 06:42:35 2000 UTC (20 years, 6 months ago) by hayashi
Branches: MAIN
CVS tags: HEAD
New files

    1: @c =============================================================
    2: @c = 元 翻 訳: 久野靖@大塚.筑波大学
    3: @c = 加筆修正: 大木敦雄@大塚.筑波大学 = 1998/11/25
    4: @c = 20.4改訂: 大木敦雄@大塚.筑波大学 = 1999/09/12
    5: @c = 20.6改訂: 大木敦雄@大塚.筑波大学 = 2000/03/03
    6: @c =============================================================
    7: @c This is part of the Emacs manual.
    8: @c Copyright (C) 1985, 86, 87, 93, 94, 95, 1997 Free Software Foundation, Inc.
    9: @c See file emacs.texi for copying conditions.
   10: @iftex
   11: @c @chapter Dealing with Common Problems
   12: @chapter よくある問題への対処
   13: 
   14: @c   If you type an Emacs command you did not intend, the results are often
   15: @c mysterious.  This chapter tells what you can do to cancel your mistake or
   16: @c recover from a mysterious situation.  Emacs bugs and system crashes are
   17: @c also considered.
   18: 意図してないEmacsコマンドを打つと、
   19: その結果はわけのわからないものになりがちです。
   20: 本章では、まちがいを取り消したり、
   21: わけのわからない状況から復帰する手段について説明します。
   22: また、Emacsのバグやシステムクラッシュについても説明します。
   23: @end iftex
   24: 
   25: @node Quitting, Lossage, Customization, Top
   26: @c @section Quitting and Aborting
   27: @c @cindex quitting
   28: @section 中断とアボート
   29: @cindex 中断
   30: 
   31: @table @kbd
   32: @item C-g
   33: @c @itemx C-@key{BREAK} (MS-DOS)
   34: @itemx C-@key{BREAK}(MS-DOS)
   35: @c Quit.  Cancel running or partially typed command.
   36: 中断する。
   37: 動作中のコマンドや打鍵途中のコマンドを取り消す。
   38: @item C-]
   39: @c Abort innermost recursive editing level and cancel the command which
   40: @c invoked it (@code{abort-recursive-edit}).
   41: アボートする。
   42: いちばん内側の再帰編集レベルを強制的に終了し、
   43: その再帰編集レベルを起動したコマンドを取り消す
   44: (@code{abort-recursive-edit})。
   45: @item @key{ESC} @key{ESC} @key{ESC}
   46: @c Either quit or abort, whichever makes sense (@code{keyboard-escape-quit}).
   47: 中断かアボートのいずれか意味のあるほうを実行する
   48: (@code{keyboard-escape-quit})。
   49: @item M-x top-level
   50: @c Abort all recursive editing levels that are currently executing.
   51: 現在実行中のすべての再帰編集レベルを強制的に終了する。
   52: @item C-x u
   53: @c Cancel a previously made change in the buffer contents (@code{undo}).
   54: バッファの内容に対して行った直前の変更を取り消す(@code{undo})。
   55: @end table
   56: 
   57: @c   There are two ways of canceling commands which are not finished
   58: @c executing: @dfn{quitting} with @kbd{C-g}, and @dfn{aborting} with
   59: @c @kbd{C-]} or @kbd{M-x top-level}.  Quitting cancels a partially typed
   60: @c command or one which is already running.  Aborting exits a recursive
   61: @c editing level and cancels the command that invoked the recursive edit.
   62: @c (@xref{Recursive Edit}.)
   63: 実行を完了していないコマンドを取り消すには、2つの方法があります。 
   64: 1つは@kbd{C-g}で@dfn{中断}すること、
   65: もう1つは@kbd{C-]}や@kbd{M-x top-level}で
   66: @dfn{アボート}することです。
   67: 中断とは、打鍵途中のコマンドや動作中のコマンドを取り消すことをいいます。
   68: アボートとは、再帰編集レベルから抜け出し、かつ、
   69: その再帰編集レベルを起動したコマンドを取り消すことをいいます
   70: (@pxref{Recursive Edit})。
   71: 
   72: @c @cindex quitting
   73: @cindex 中断
   74: @kindex C-g
   75: @c   Quitting with @kbd{C-g} is used for getting rid of a partially typed
   76: @c command, or a numeric argument that you don't want.  It also stops a
   77: @c running command in the middle in a relatively safe way, so you can use
   78: @c it if you accidentally give a command which takes a long time.  In
   79: @c particular, it is safe to quit out of killing; either your text will
   80: @c @emph{all} still be in the buffer, or it will @emph{all} be in the kill
   81: @c ring (or maybe both).  Quitting an incremental search does special
   82: @c things documented under searching; in general, it may take two
   83: @c successive @kbd{C-g} characters to get out of a search
   84: @c (@pxref{Incremental Search}).
   85: @kbd{C-g}での中断は、打鍵途中のコマンドや
   86: 不要な数引数を打ってしまったときにとりやめるのに使います。
   87: また、実行途中のコマンドを比較的安全な方法で止めますから、
   88: 長時間かかるコマンドをうっかり始めてしまったときにも使えます。
   89: 特に、キル操作を中断しても安全です。
   90: テキストは、まだ@emph{すべて}バッファ内にあるか、
   91: または、@emph{すべて}キルリングに入っている
   92: (あるいは、その両方に入っている)からです。
   93: なお、インクリメンタルサーチを中断する場合には、
   94: 文字列探索のところで説明してあるように、特別な動作を行います。
   95: 一般には、サーチから抜け出すには@kbd{C-g}を2回連打する必要があります
   96: (@pxref{Incremental Search})。
   97: 
   98: @c   On MS-DOS, the character @kbd{C-@key{BREAK}} serves as a quit character
   99: @c like @kbd{C-g}.  The reason is that it is not feasible, on MS-DOS, to
  100: @c recognize @kbd{C-g} while a command is running, between interactions
  101: @c with the user.  By contrast, it @emph{is} feasible to recognize
  102: @c @kbd{C-@key{BREAK}} at all times.  @xref{MS-DOS Input}.
  103: MS-DOSでは、@kbd{C-@key{BREAK}}は@kbd{C-g}と同様に中断として働きます。
  104: MS-DOSでは、コマンドの実行中にユーザーとのやりとりを行う状態にないときには、
  105: @kbd{C-g}を検出できないからです。
  106: これに対して、@kbd{C-@key{BREAK}}はつねに認識@emph{でき}ます。
  107: @xref{MS-DOS Input}。
  108: 
  109: @c   @kbd{C-g} works by setting the variable @code{quit-flag} to @code{t}
  110: @c the instant @kbd{C-g} is typed; Emacs Lisp checks this variable
  111: @c frequently and quits if it is non-@code{nil}.  @kbd{C-g} is only
  112: @c actually executed as a command if you type it while Emacs is waiting for
  113: @c input.
  114: @kbd{C-g}はつぎのように動作します。
  115: @kbd{C-g}が打鍵されると変数@code{quit-flag}に@code{t}が設定されます。
  116: Emacs Lispはこの変数を頻繁に調べ、値が@code{nil}以外だと中断処理を行います。
  117: @kbd{C-g}が実際にコマンドとして実行されるのは、
  118: Emacsが入力待ち状態にあるときに@kbd{C-g}を打った場合だけです。
  119: 
  120: @c   If you quit with @kbd{C-g} a second time before the first @kbd{C-g} is
  121: @c recognized, you activate the ``emergency escape'' feature and return to
  122: @c the shell.  @xref{Emergency Escape}.
  123: 最初の@kbd{C-g}が認識されないうちに2つめの@kbd{C-g}を打って中断すると、
  124: 『緊急脱出』機能を発動したことになりシェルに戻ります。
  125: @xref{Emergency Escape}。
  126: 
  127: @c @cindex NFS and quitting
  128: @cindex NFSと中断
  129: @c   There may be times when you cannot quit.  When Emacs is waiting for
  130: @c the operating system to do something, quitting is impossible unless
  131: @c special pains are taken for the particular system call within Emacs
  132: @c where the waiting occurs.  We have done this for the system calls that
  133: @c users are likely to want to quit from, but it's possible you will find
  134: @c another.  In one very common case---waiting for file input or output
  135: @c using NFS---Emacs itself knows how to quit, but most NFS implementations
  136: @c simply do not allow user programs to stop waiting for NFS when the NFS
  137: @c server is hung.
  138: 中断できない場合もありえます。
  139: Emacsがオペレーティングシステムに何かを頼んで待っているときには、
  140: 待ち状態を起こしたシステムコールを使ったEmacs側で特別な手当てをしない限り
  141: 中断できません。
  142: Emacsでは、ユーザーが中断しそうなシステムコールには
  143: 手当てを施してありますが、手当てしていない場所を叩く可能性はあります。
  144: よくあるのは、NFS経由の入出力を待っているときです。
  145: Emacs側ではこれを中断する方法はわかっているのですが、
  146: 多くのNFSの実装では、NFSサーバーが固まったときにユーザープログラムが
  147: NFSの待ちを中断することを許していないのです。
  148: 
  149: @c @cindex aborting recursive edit
  150: @cindex 再帰編集をアボートする
  151: @findex abort-recursive-edit
  152: @kindex C-]
  153: @c   Aborting with @kbd{C-]} (@code{abort-recursive-edit}) is used to get
  154: @c out of a recursive editing level and cancel the command which invoked
  155: @c it.  Quitting with @kbd{C-g} does not do this, and could not do this,
  156: @c because it is used to cancel a partially typed command @emph{within} the
  157: @c recursive editing level.  Both operations are useful.  For example, if
  158: @c you are in a recursive edit and type @kbd{C-u 8} to enter a numeric
  159: @c argument, you can cancel that argument with @kbd{C-g} and remain in the
  160: @c recursive edit.
  161: @kbd{C-]}によるアボート(@code{abort-recursive-edit})は、
  162: 再帰編集レベルから脱出し、かつ、その再帰編集レベルを
  163: 起動したコマンドを取り消すのに使います。
  164: @kbd{C-g}による中断はこのような目的には使えませんし、
  165: このようなことはできません。
  166: というのは、@kbd{C-g}は、ある再帰編集レベルの@emph{中で}
  167: 打ちかけたコマンドを取り消すのに使うからです。
  168: どちらの操作も必要なものです。
  169: たとえば、再帰編集中に数引数を入力しようとして@kbd{C-u 8}と打鍵した場合、
  170: @kbd{C-g}で数引数を取り消しても再帰編集に留まったままです。
  171: 
  172: @findex keyboard-escape-quit
  173: @kindex ESC ESC ESC
  174: @c   The command @kbd{@key{ESC} @key{ESC} @key{ESC}}
  175: @c (@code{keyboard-escape-quit}) can either quit or abort.  This key was
  176: @c defined because @key{ESC} is used to ``get out'' in many PC programs.
  177: @c It can cancel a prefix argument, clear a selected region, or get out of
  178: @c a Query Replace, like @kbd{C-g}.  It can get out of the minibuffer or a
  179: @c recursive edit, like @kbd{C-]}.  It can also get out of splitting the
  180: @c frame into multiple windows, like @kbd{C-x 1}.  One thing it cannot do,
  181: @c however, is stop a command that is running.  That's because it executes
  182: @c as an ordinary command, and Emacs doesn't notice it until it is ready
  183: @c for a command.
  184: コマンド@kbd{@key{ESC} @key{ESC} @key{ESC}}
  185: (@code{keyboard-escape-quit})は、中断かアボートのいずれかを行います。
  186: このキーを使うのは、多くのPCのソフトで@key{ESC}が
  187: 『抜け出す』の意味に使われているからです。
  188: @kbd{C-g}と同様に、数引数を取り消したり、
  189: 選択したリージョンをクリアしたり、問い合わせ型置換操作から抜け出します。
  190: @kbd{C-]}と同様に、ミニバッファや再帰編集から抜け出します。
  191: また、@kbd{C-x 1}のように、フレームを複数ウィンドウに分割しているのを
  192: やめることもできます。
  193: しかしながら、実行中のコマンドを止めることはできません。
  194: なぜなら、このコマンドは普通のコマンドとして実行されるので、
  195: Emacsがコマンドを読み込む状態にならないとこのコマンドを認識しないからです。
  196: 
  197: @findex top-level
  198: @c   The command @kbd{M-x top-level} is equivalent to ``enough'' @kbd{C-]}
  199: @c commands to get you out of all the levels of recursive edits that you
  200: @c are in.  @kbd{C-]} gets you out one level at a time, but @kbd{M-x
  201: @c top-level} goes out all levels at once.  Both @kbd{C-]} and @kbd{M-x
  202: @c top-level} are like all other commands, and unlike @kbd{C-g}, in that
  203: @c they take effect only when Emacs is ready for a command.  @kbd{C-]} is
  204: @c an ordinary key and has its meaning only because of its binding in the
  205: @c keymap.  @xref{Recursive Edit}.
  206: コマンド@kbd{M-x top-level}は、現在入っているすべての再帰編集レベルから
  207: 抜け出すのに『十分な』数の@kbd{C-]}と同等です。
  208: @kbd{C-]}は一度に1レベルだけ抜け出すのに対し、
  209: @kbd{M-x top-level}はすべてのレベルを一気に抜け出します。
  210: @kbd{C-]}も@kbd{M-x top-level}も他のコマンドと同様の普通のコマンドですから、
  211: @kbd{C-g}とは違って、Emacsがコマンドを受け付ける状態のときだけ動作します。
  212: @kbd{C-]}は普通のキーであり、キーマップにそのバインディングがあるので
  213: そのように動作するのです。
  214: @xref{Recursive Edit}。
  215: 
  216: @c   @kbd{C-x u} (@code{undo}) is not strictly speaking a way of canceling
  217: @c a command, but you can think of it as canceling a command that already
  218: @c finished executing.  @xref{Undo}.
  219: @kbd{C-x u}(@code{undo})は、正確にいえばコマンドを
  220: 取り消すわけではありませんが、
  221: 動作を完了してしまったコマンドを取り消すものと考えることができます。
  222: @xref{Undo}。
  223: 
  224: @node Lossage, Bugs, Quitting, Top
  225: @c @section Dealing with Emacs Trouble
  226: @section Emacsのトラブルに対する対処
  227: 
  228: @c   This section describes various conditions in which Emacs fails to work
  229: @c normally, and how to recognize them and correct them.
  230: 本節では、Emacsが正常に動作し損なうさまざまな条件と、それらの見分け方、
  231: 直し方について説明します。
  232: 
  233: @menu
  234: * DEL Gets Help::       What to do if @key{DEL} doesn't delete.
  235: * Stuck Recursive::     `[...]' in mode line around the parentheses.
  236: * Screen Garbled::      Garbage on the screen.
  237: * Text Garbled::        Garbage in the text.
  238: * Unasked-for Search::  Spontaneous entry to incremental search.
  239: * Memory Full::         How to cope when you run out of memory.
  240: * After a Crash::       Recovering editing in an Emacs session that crashed.
  241: * Emergency Escape::    Emergency escape---
  242:                           What to do if Emacs stops responding.
  243: * Total Frustration::   When you are at your wits' end.
  244: @end menu
  245: 
  246: @node DEL Gets Help, Stuck Recursive, , Lossage
  247: @c @subsection If @key{DEL} Fails to Delete
  248: @subsection @key{DEL}で削除できない
  249: 
  250: @c   If you find that @key{DEL} enters Help like @kbd{Control-h} instead of
  251: @c deleting a character, your terminal is sending the wrong code for
  252: @c @key{DEL}.  You can work around this problem by changing the keyboard
  253: @c translation table (@pxref{Keyboard Translations}).
  254: @key{DEL}が文字を削除するかわりに@kbd{Control-h}のように
  255: ヘルプに入ってしまう場合には、
  256: 使っている端末が@key{DEL}に対してまちがった文字コードを送出しています。
  257: この問題に対処するには、キーボード変換表を変更します
  258: (@pxref{Keyboard Translations})。
  259: 
  260: @node Stuck Recursive, Screen Garbled, DEL Gets Help, Lossage
  261: @c @subsection Recursive Editing Levels
  262: @subsection 再帰編集レベル
  263: 
  264: @c   Recursive editing levels are important and useful features of Emacs, but
  265: @c they can seem like malfunctions to the user who does not understand them.
  266: 再帰編集レベルはEmacsの重要で有用な機能ですが、
  267: それについて理解していない人にとっては、誤動作に見える可能性があります。
  268: 
  269: @c   If the mode line has square brackets @samp{[@dots{}]} around the parentheses
  270: @c that contain the names of the major and minor modes, you have entered a
  271: @c recursive editing level.  If you did not do this on purpose, or if you
  272: @c don't understand what that means, you should just get out of the recursive
  273: @c editing level.  To do so, type @kbd{M-x top-level}.  This is called getting
  274: @c back to top level.  @xref{Recursive Edit}.
  275: モード行のメジャー/マイナモード名を囲む丸括弧の周囲に中括弧
  276: @samp{[@dots{}]}が表示されているときは、再帰編集レベルに入っています。
  277: 意図してそうしたのでなかったり、
  278: 再帰編集レベルの意味を理解していないのであれば、
  279: 再帰編集レベルから抜け出すべきです。
  280: それには@kbd{M-x top-level}と打ちます。
  281: これをトップレベルへの抜け出しと呼びます。
  282: @xref{Recursive Edit}。
  283: 
  284: @node Screen Garbled, Text Garbled, Stuck Recursive, Lossage
  285: @c @subsection Garbage on the Screen
  286: @subsection 画面上のゴミ
  287: 
  288: @c   If the data on the screen looks wrong, the first thing to do is see
  289: @c whether the text is really wrong.  Type @kbd{C-l}, to redisplay the
  290: @c entire screen.  If the screen appears correct after this, the problem
  291: @c was entirely in the previous screen update.  (Otherwise, see @ref{Text
  292: @c Garbled}.)
  293: 画面上のデータがまちがっているように見えたら、まず最初にすべきことは、
  294: テキストが本当にまちがっているのかどうか調べることです。
  295: @kbd{C-l}と打って画面全体を再描画します。
  296: これで画面が正しそうになるのなら、問題は画面更新にあったのです。
  297: (そうでない場合は、@pxref{Text Garbled})。
  298: 
  299: @c   Display updating problems often result from an incorrect termcap entry
  300: @c for the terminal you are using.  The file @file{etc/TERMS} in the Emacs
  301: @c distribution gives the fixes for known problems of this sort.
  302: @c @file{INSTALL} contains general advice for these problems in one of its
  303: @c sections.  Very likely there is simply insufficient padding for certain
  304: @c display operations.  To investigate the possibility that you have this sort
  305: @c of problem, try Emacs on another terminal made by a different manufacturer.
  306: @c If problems happen frequently on one kind of terminal but not another kind,
  307: @c it is likely to be a bad termcap entry, though it could also be due to a
  308: @c bug in Emacs that appears for terminals that have or that lack specific
  309: @c features.
  310: 画面更新の問題は、
  311: 使っている端末に対応するtermcapの定義がまちがっている場合が多いです。
  312: Emacsの配布に含まれるファイル@file{etc/TERMS}には、
  313: この種の問題で既知のものに対する修正が入っています。
  314: ファイル@file{INSTALL}には、
  315: この種の問題に対する一般的なアドバイスの節があります。
  316: いちばんありがちなのは、
  317: ある種の画面操作に対するパディング
  318: @footnote{【訳注】端末にとっては無意味で無害な文字を、
  319: (動作が完了するまでの)時間稼ぎのために送出すること。}
  320: が不足している場合です。
  321: この種の問題があるかどうか調べるには、
  322: 他のメーカ製の別の端末でEmacsを動かしてみてください。
  323: ある機種の端末では頻繁に問題が起きるのに別の機種の端末では問題がないなら、
  324: termcapの定義がまちがっている可能性があります。
  325: しかし、ある種の機能を有するか欠如している端末で現れる
  326: Emacsのバグである可能性もあります。
  327: 
  328: @node Text Garbled, Unasked-for Search, Screen Garbled, Lossage
  329: @c @subsection Garbage in the Text
  330: @subsection テキスト内のゴミ
  331: 
  332: @c   If @kbd{C-l} shows that the text is wrong, try undoing the changes to it
  333: @c using @kbd{C-x u} until it gets back to a state you consider correct.  Also
  334: @c try @kbd{C-h l} to find out what command you typed to produce the observed
  335: @c results.
  336: @kbd{C-l}を実行してもテキストが変ならば、
  337: 正しいと思われる状態になるまで、
  338: @kbd{C-x u}を使って変更をもとに戻してみてください。
  339: また、どのコマンドで変になったのか調べるために、
  340: @kbd{C-h l}を試してみてください。
  341: 
  342: @c   If a large portion of text appears to be missing at the beginning or
  343: @c end of the buffer, check for the word @samp{Narrow} in the mode line.
  344: @c If it appears, the text you don't see is probably still present, but
  345: @c temporarily off-limits.  To make it accessible again, type @kbd{C-x n
  346: @c w}.  @xref{Narrowing}.
  347: バッファの先頭や末尾で大量のテキストが失われているようなら、
  348: モード行に単語@samp{Narrow}が表示されていないか確認してください。
  349: もしそうなら、おそらくテキストは失われているのではなく、
  350: 一時的に見えなくなっているのでしょう。
  351: 見えるようにするには、@kbd{C-x n w}と打ってください。
  352: @xref{Narrowing}。
  353: 
  354: @node Unasked-for Search, Memory Full, Text Garbled, Lossage
  355: @c @subsection Spontaneous Entry to Incremental Search
  356: @subsection 自発的なインクリメンタルサーチの開始
  357: 
  358: @c   If Emacs spontaneously displays @samp{I-search:} at the bottom of the
  359: @c screen, it means that the terminal is sending @kbd{C-s} and @kbd{C-q}
  360: @c according to the poorly designed xon/xoff ``flow control'' protocol.
  361: Emacsが画面の最下行に自発的に@samp{I-search:}と表示するようなら、
  362: 劣悪なxon/xoffの『フロー制御プロトコル』に従って
  363: 端末が@kbd{C-s}と@kbd{C-q}を送っているためでしょう。
  364: 
  365: @c   If this happens to you, your best recourse is to put the terminal in a
  366: @c mode where it will not use flow control, or give it so much padding that
  367: @c it will never send a @kbd{C-s}.  (One way to increase the amount of
  368: @c padding is to set the variable @code{baud-rate} to a larger value.  Its
  369: @c value is the terminal output speed, measured in the conventional units
  370: @c of baud.)
  371: もしこの状態が起きたら、もっともよいのは端末をフロー制御なしに設定するか、
  372: または、パディングを十分に増やして端末がけっして@kbd{C-s}を
  373: 送らないようにすることです。
  374: (パディングを増やす1つの方法は、
  375: より大きい値を変数@code{baud-rate}に設定すること。
  376: この値はボーという単位で表した端末の出力速度。)
  377: 
  378: @c @cindex flow control
  379: @cindex フロー制御
  380: @cindex xon-xoff
  381: @findex enable-flow-control
  382: @c   If you don't succeed in turning off flow control, the next best thing
  383: @c is to tell Emacs to cope with it.  To do this, call the function
  384: @c @code{enable-flow-control}.
  385: フロー制御を止められない場合の次善の策は、
  386: Emacsにフロー制御を処理させることです。
  387: それには、関数@code{enable-flow-control}を呼び出してください。
  388: 
  389: @findex enable-flow-control-on
  390: @c   Typically there are particular terminal types with which you must use
  391: @c flow control.  You can conveniently ask for flow control on those
  392: @c terminal types only, using @code{enable-flow-control-on}.  For example,
  393: @c if you find you must use flow control on VT-100 and H19 terminals, put
  394: @c the following in your @file{.emacs} file:
  395: 典型的な場合、
  396: ある種の端末タイプに限ってフロー制御を使う必要があります。
  397: @code{enable-flow-control-on}を使って、
  398: そのような種類の端末に限ってフロー制御を行うようにできます。
  399: たとえば、VT-100端末とH19端末にはフロー制御を行う必要があるのなら、
  400: ファイル@file{.emacs}につぎのものを入れます。
  401: 
  402: @example
  403: (enable-flow-control-on "vt100" "h19")
  404: @end example
  405: 
  406: @c   When flow control is enabled, you must type @kbd{C-\} to get the
  407: @c effect of a @kbd{C-s}, and type @kbd{C-^} to get the effect of a
  408: @c @kbd{C-q}.  (These aliases work by means of keyboard translations; see
  409: @c @ref{Keyboard Translations}.)
  410: フロー制御を使っている場合には、@kbd{C-s}のかわりに@kbd{C-\}、
  411: @kbd{C-q}のかわりに@kbd{C-^}を使う必要があります。
  412: (これらの割り当てはキーボード変換によって行われる。
  413: @pxref{Keyboard Translations}。)
  414: 
  415: @node Memory Full, After a Crash, Unasked-for Search, Lossage
  416: @c @subsection Running out of Memory
  417: @c @cindex memory full
  418: @c @cindex out of memory
  419: @subsection メモリ不足
  420: @cindex メモリ不足
  421: 
  422: @c   If you get the error message @samp{Virtual memory exceeded}, save your
  423: @c modified buffers with @kbd{C-x s}.  This method of saving them has the
  424: @c smallest need for additional memory.  Emacs keeps a reserve of memory
  425: @c which it makes available when this error happens; that should be enough
  426: @c to enable @kbd{C-x s} to complete its work.
  427: @samp{Virtual memory exceeded}というエラーメッセージが出たら、
  428: 変更したバッファを@kbd{C-x s}で保存してください。
  429: この方法で保存する場合、必要なメモリは最小限ですみます。
  430: Emacsは上記のエラーが起きたときでも使える予備のメモリを確保していますから、
  431: @kbd{C-x s}を完了するのには十分なはずです。
  432: 
  433: @c   Once you have saved your modified buffers, you can exit this Emacs job
  434: @c and start another, or you can use @kbd{M-x kill-some-buffers} to free
  435: @c space in the current Emacs job.  If you kill buffers containing a
  436: @c substantial amount of text, you can safely go on editing.  Emacs refills
  437: @c its memory reserve automatically when it sees sufficient free space
  438: @c available, in case you run out of memory another time.
  439: 変更済みのバッファを保存したら、
  440: Emacsを終了して別のEmacsを起動してもよいですし、
  441: @kbd{M-x kill-some-buffer}を使って
  442: 現在動いているEmacsのメモリを解放してもよいです。
  443: 大量のテキストが入っているバッファを消せば、
  444: 安全に編集を続行できます。
  445: 空きメモリが十分な量になると予備のメモリを自動的に確保し直し、
  446: 再度メモリ不足になったときに備えます。
  447: 
  448: @c   Do not use @kbd{M-x buffer-menu} to save or kill buffers when you run
  449: @c out of memory, because the buffer menu needs a fair amount memory
  450: @c itself, and the reserve supply may not be enough.
  451: メモリ不足になったときには、@kbd{M-x buffer-menu}を使って
  452: バッファを保存したり消したりしないでください。
  453: このコマンドはけっこうメモリを必要とするので、
  454: 確保した予備のメモリだけでは十分でない可能性があるからです。
  455: 
  456: @node After a Crash, Emergency Escape, Memory Full, Lossage
  457: @c @subsection Recovery After a Crash
  458: @subsection クラッシュからの回復
  459: 
  460: @c   If Emacs or the computer crashes, you can recover the files you were
  461: @c editing at the time of the crash from their auto-save files.  To do
  462: @c this, start Emacs again and type the command @kbd{M-x recover-session}.
  463: Emacsやコンピュータがクラッシュしても、
  464: クラッシュ時に編集していたファイルは自動保存ファイルから回復できます。
  465: それには、Emacsを再度起動してから、コマンド@kbd{M-x recover-session}を
  466: 入力してください。
  467: 
  468: @c   This command initially displays a buffer which lists interrupted
  469: @c session files, each with its date.  You must choose which session to
  470: @c recover from.  Typically the one you want is the most recent one.  Move
  471: @c point to the one you choose, and type @kbd{C-c C-c}.
  472: このコマンドは、まず、中断されたセッションファイルの一覧を日付とともに
  473: バッファに表示します。
  474: その中からどのセッションを回復するか選んでください。
  475: 通常は、最新のセッションを選べばよいでしょう。
  476: 望みのセッションの行にポイントを動かして、@kbd{C-c C-c}と打ちます。
  477: 
  478: @c   Then @code{recover-session} asks about each of the files that you were
  479: @c editing during that session; it asks whether to recover that file.  If
  480: @c you answer @kbd{y} for a file, it shows the dates of that file and its
  481: @c auto-save file, then asks once again whether to recover that file.  For
  482: @c the second question, you must confirm with @kbd{yes}.  If you do, Emacs
  483: @c visits the file but gets the text from the auto-save file.
  484: すると、@code{recover-session}は、そのセッションで編集中だった
  485: 各ファイルについて回復するかどうか問い合わせてきます。
  486: @kbd{y}と答えると、そのファイルと自動保存ファイルの日付を表示してから、
  487: 回復するかどうか再度問い合わせてきます。
  488: 再問い合わせに対しては@kbd{yes}で答える必要があります。
  489: そうすると、Emacsはそのファイルを訪れますが、
  490: テキストは自動保存ファイルから持ってきます。
  491: 
  492: @c   When @code{recover-session} is done, the files you've chosen to
  493: @c recover are present in Emacs buffers.  You should then save them.  Only
  494: @c this---saving them---updates the files themselves.
  495: @code{recover-session}が完了すると、
  496: 回復を指定したファイルはEmacsバッファに入っています。
  497: そうしたらこれらのバッファを保存してください。
  498: 保存して始めてもとのファイルが更新されます。
  499: 
  500: @node Emergency Escape, Total Frustration, After a Crash, Lossage
  501: @c @subsection Emergency Escape
  502: @subsection 緊急脱出
  503: 
  504: @c   Because at times there have been bugs causing Emacs to loop without
  505: @c checking @code{quit-flag}, a special feature causes Emacs to be suspended
  506: @c immediately if you type a second @kbd{C-g} while the flag is already set,
  507: @c so you can always get out of GNU Emacs.  Normally Emacs recognizes and
  508: @c clears @code{quit-flag} (and quits!) quickly enough to prevent this from
  509: @c happening.  (On MS-DOS and compatible systems, type @kbd{C-@key{BREAK}}
  510: @c twice.)
  511: バグのために、Emacsが@code{quit-flag}を検査しないループに入ってしまうことも
  512: ありえます。
  513: このため、このフラグが設定されている状態で再度@kbd{C-g}が打たれると
  514: ただちに実行を休止する特別な機能がEmacsにはあり、
  515: いつでもGNU Emacsから抜け出すことができます。
  516: 通常、Emacsはすみやかに@code{quit-flag}を認識し(中断し)ますから、
  517: この特別な機能が使われることはまずありません。
  518: (MS-DOSや互換システムでは、@kbd{C-@key{BREAK}}を2回連打する。)
  519: 
  520: @c   When you resume Emacs after a suspension caused by multiple @kbd{C-g}, it
  521: @c asks two questions before going back to what it had been doing:
  522: @kbd{C-g}の連打によって休止したEmacsを再開すると、
  523: Emacsは休止直前に実行していた動作に戻るまえに、
  524: つぎの2つの質問をしてきます。
  525: 
  526: @example
  527: Auto-save? (y or n)
  528: Abort (and dump core)? (y or n)
  529: @end example
  530: 
  531: @noindent
  532: @c Answer each one with @kbd{y} or @kbd{n} followed by @key{RET}.
  533: それぞれの質問に対し、@kbd{y}か@kbd{n}に続けて@key{RET}で答えてください。
  534: 
  535: @c   Saying @kbd{y} to @samp{Auto-save?} causes immediate auto-saving of all
  536: @c modified buffers in which auto-saving is enabled.
  537: @samp{Auto-save?}に@kbd{y}と答えると、
  538: 自動保存を行う設定になっている変更されたバッファすべてに対して
  539: ただちに自動保存を実行します。
  540: 
  541: @c   Saying @kbd{y} to @samp{Abort (and dump core)?} causes an illegal instruction to be
  542: @c executed, dumping core.  This is to enable a wizard to figure out why Emacs
  543: @c was failing to quit in the first place.  Execution does not continue
  544: @c after a core dump.  If you answer @kbd{n}, execution does continue.  With
  545: @c luck, GNU Emacs will ultimately check @code{quit-flag} and quit normally.
  546: @c If not, and you type another @kbd{C-g}, it is suspended again.
  547: @samp{Abort (and dump core)?}に@kbd{y}と答えると、
  548: Emacsは不正命令を実行してコアダンプを作ります。
  549: コアダンプがあると、Emacsが中断できなかった理由をウィザード
  550: @footnote{【訳注】「名人、熟練者、魔術師」の意味だが、
  551: 特定のコンピュータや(特に)ソフトウェアに精通した人を指す。}
  552: が追究できます。
  553: コアダンプを作り終えるとEmacsの実行は終了します。
  554: @kbd{n}と答えると実行は継続します。
  555: 運がよければ、Emacsが最終的には@code{quit-flag}を検査して
  556: 正常に中断できるでしょう。
  557: 運が悪ければ、またループに入ったままになりますから、
  558: 再度@kbd{C-g}を打ってEmacsをまた休止します。
  559: 
  560: @c   If Emacs is not really hung, just slow, you may invoke the double
  561: @c @kbd{C-g} feature without really meaning to.  Then just resume and answer
  562: @c @kbd{n} to both questions, and you will arrive at your former state.
  563: @c Presumably the quit you requested will happen soon.
  564: 本当はEmacsが固まったのではなく単に遅いだけの場合には、
  565: 意図せずに@kbd{C-g}を連打してしまうことがあります。
  566: その場合には、再開して2つの質問に@kbd{n}と答えればもとの状態に戻れます。
  567: 中断要求はすぐに受け付けられるでしょう。
  568: 
  569: @c   The double-@kbd{C-g} feature is turned off when Emacs is running under
  570: @c the X Window System, since you can use the window manager to kill Emacs
  571: @c or to create another window and run another program.
  572: XウィンドウシステムのもとでEmacsが動作している場合には、
  573: @kbd{C-g}連打の機能は切ってあります。
  574: というのは、ウィンドウマネージャを使ってEmacsを終了させたり、
  575: 別のウィンドウを開いて別のプログラムを動かせるからです。
  576: 
  577: @c   On MS-DOS and compatible systems, the emergency escape feature is
  578: @c sometimes unavailable, even if you press @kbd{C-@key{BREAK}} twice, when
  579: @c some system call (MS-DOS or BIOS) hangs, or when Emacs is stuck in a
  580: @c very tight endless loop (in C code, @strong{not} in Lisp code).
  581: MS-DOSや互換システムでは、
  582: (MS-DOSやBIOSの)システムコールが固まっている場合や
  583: Emacsが非常にきつい(Lispコードでは@strong{なく}Cのコードで)
  584: 無限ループに入っている場合には、
  585: @kbd{C-@key{BREAK}}を2回打っても緊急脱出の機能を使えない場合があります。
  586: 
  587: @node Total Frustration,  , Emergency Escape, Lossage
  588: @c @subsection Help for Total Frustration
  589: @subsection いらいらしたら…
  590: @cindex Eliza
  591: @cindex doctor
  592: 
  593: @c   If using Emacs (or something else) becomes terribly frustrating and none
  594: @c of the techniques described above solve the problem, Emacs can still help
  595: @c you.
  596: Emacsを使うこと(や、その他のこと)がきわめて不愉快になったり、
  597: ここまでにあげたどの方法でも問題が解決しない場合でも、
  598: Emacsはまだ手助けができます。
  599: 
  600: @c   First, if the Emacs you are using is not responding to commands, type
  601: @c @kbd{C-g C-g} to get out of it and then start a new one.
  602: まず、Emacsがコマンドに応答しないようなら、
  603: @kbd{C-g C-g}と打ってEmacsから抜け出し、
  604: 新たに別のEmacsを起動してください。
  605: 
  606: @findex doctor
  607: @c   Second, type @kbd{M-x doctor @key{RET}}.
  608: つぎに、@kbd{M-x doctor @key{RET}}と打ってください。
  609: 
  610: @c   The doctor will help you feel better.  Each time you say something to
  611: @c the doctor, you must end it by typing @key{RET} @key{RET}.  This lets
  612: @c the doctor know you are finished.
  613: doctorプログラムがあなたのいらいらを鎮めてくれるでしょう。
  614: doctorに何かを話すときには、@key{RET} @key{RET}と打っていい終える
  615: 必要があります。
  616: こうすると、doctorは患者が話し終えたことを認識します。
  617: 
  618: @node Bugs, Contributing, Lossage, Top
  619: @c @section Reporting Bugs
  620: @section バグの報告
  621: 
  622: @c @cindex bugs
  623: @cindex バグ
  624: @c   Sometimes you will encounter a bug in Emacs.  Although we cannot
  625: @c promise we can or will fix the bug, and we might not even agree that it
  626: @c is a bug, we want to hear about problems you encounter.  Often we agree
  627: @c they are bugs and want to fix them.
  628: Emacsのバグに出会うこともあるでしょう。
  629: バグを修正する/できるとは約束できませんし、
  630: そもそもバグだと認めないかもしれませんが、
  631: 読者が遭遇した問題については知らせてほしいと考えています。
  632: たしかにそれをバグだと認めて修正しようということになる場合も多いのです。
  633: 
  634: @c   To make it possible for us to fix a bug, you must report it.  In order
  635: @c to do so effectively, you must know when and how to do it.
  636: バグを修正するには、まず、報告してもらう必要があります。
  637: 効果的に報告してもらうためには、報告の仕方を知っていただく必要があります。
  638: 
  639: @menu
  640: * Criteria:  Bug Criteria.	 Have you really found a bug?
  641: * Understanding Bug Reporting::	 How to report a bug effectively.
  642: * Checklist::			 Steps to follow for a good bug report.
  643: * Sending Patches::		 How to send a patch for GNU Emacs.
  644: @end menu
  645: 
  646: @node Bug Criteria, Understanding Bug Reporting, , Bugs
  647: @c @subsection When Is There a Bug
  648: @subsection バグの発生時期
  649: 
  650: @c   If Emacs executes an illegal instruction, or dies with an operating
  651: @c system error message that indicates a problem in the program (as opposed to
  652: @c something like ``disk full''), then it is certainly a bug.
  653: Emacsが不正命令を実行したり、
  654: (『ディスクが満杯』などの外部の問題ではなく)プログラムに問題が
  655: あるというオペレーティングシステムのメッセージを表示して止まった場合には、
  656: たしかにバグがあるといえます。
  657: 
  658: @c   If Emacs updates the display in a way that does not correspond to what is
  659: @c in the buffer, then it is certainly a bug.  If a command seems to do the
  660: @c wrong thing but the problem corrects itself if you type @kbd{C-l}, it is a
  661: @c case of incorrect display updating.
  662: Emacsの画面の更新結果がバッファの内容に対応していないなら、
  663: それもたしかにバグです。
  664: コマンドの実行が思わしくなくても@kbd{C-l}で再表示させると正しくなる場合には、
  665: 画面更新がまちがっているのです。
  666: 
  667: @c   Taking forever to complete a command can be a bug, but you must make
  668: @c certain that it was really Emacs's fault.  Some commands simply take a
  669: @c long time.  Type @kbd{C-g} (@kbd{C-@key{BREAK}} on MS-DOS) and then @kbd{C-h l}
  670: @c to see whether the input Emacs received was what you intended to type;
  671: @c if the input was such that you @emph{know} it should have been processed
  672: @c quickly, report a bug.  If you don't know whether the command should
  673: @c take a long time, find out by looking in the manual or by asking for
  674: @c assistance.
  675: あるコマンドを実行するのに無限に時間がかかるというのはバグの可能性が
  676: ありますが、たしかにEmacsの責任かどうかを確認する必要があります。
  677: コマンドによってはとても時間がかかるものもあります。
  678: @kbd{C-g}(MS-DOSでは@kbd{C-@key{BREAK}})を打ってから
  679: @kbd{C-h l}を打つことで、Emacsが受け付けた入力がたしかに
  680: 読者が意図したものだったかどうか確認できます。
  681: すぐに処理されるコマンドだという@emph{確信}があるなら、
  682: バグを報告してください。
  683: そのコマンドがすごく時間のかかるものかどうかわからないなら、
  684: マニュアルで調べるか知っている人に聞いてください。
  685: 
  686: @c   If a command you are familiar with causes an Emacs error message in a
  687: @c case where its usual definition ought to be reasonable, it is probably a
  688: @c bug.
  689: よく知っているコマンドであって、普通なら問題なく結果が得られるはずなのに、
  690: かわりにEmacsがエラーメッセージを出すようなら、恐らくそれはバグでしょう。
  691: 
  692: @c   If a command does the wrong thing, that is a bug.  But be sure you know
  693: @c for certain what it ought to have done.  If you aren't familiar with the
  694: @c command, or don't know for certain how the command is supposed to work,
  695: @c then it might actually be working right.  Rather than jumping to
  696: @c conclusions, show the problem to someone who knows for certain.
  697: コマンドが正しくない動作をするのなら、それはバグです。
  698: ただし、コマンドが本当は何をするのが正しいか確認してください。
  699: そのコマンドに馴染みがないとか、
  700: そのコマンドがどう動作するはずなのか確信が持てない場合は、
  701: コマンドは実際には正しく動作しているのかもしれません。
  702: バグという結論に飛びつくまえに、よく知っている人に見てもらってください。
  703: 
  704: @c   Finally, a command's intended definition may not be best for editing
  705: @c with.  This is a very important sort of problem, but it is also a matter of
  706: @c judgment.  Also, it is easy to come to such a conclusion out of ignorance
  707: @c of some of the existing features.  It is probably best not to complain
  708: @c about such a problem until you have checked the documentation in the usual
  709: @c ways, feel confident that you understand it, and know for certain that what
  710: @c you want is not available.  If you are not sure what the command is
  711: @c supposed to do after a careful reading of the manual, check the index and
  712: @c glossary for any terms that may be unclear.
  713: 最後に、コマンドの意図された定義が編集操作に対して最良でない可能性があります。
  714: これは重要な問題ではありますが、ユーザーがどう判断するかの問題でもあります。
  715: 既存の機能について無知なために、
  716: まちがっていると結論を出してしまうのも簡単です。
  717: まずドキュメントをひととおり調べて、十分に納得し、
  718: それでもなお自分にとって必要な機能がない、と断言できるまでは、
  719: コマンドの定義が悪いなどとはいわないほうがよいでしょう。
  720: マニュアルを熟読してもコマンドが何をするのかよくわからなければ、
  721: 索引や用語集を活用してよくわからない単語について調べましょう。
  722: 
  723: @c   If after careful rereading of the manual you still do not understand
  724: @c what the command should do, that indicates a bug in the manual, which
  725: @c you should report.  The manual's job is to make everything clear to
  726: @c people who are not Emacs experts---including you.  It is just as
  727: @c important to report documentation bugs as program bugs.
  728: 十分熟読しても、なおコマンドが何をするのかわからないなら、
  729: それは「マニュアルのバグ」として報告すべきでしょう。
  730: マニュアルは、読者を含めて、Emacsの専門家でない人が読んでも
  731: すべてのことが明らかになるようなものであるべきです。
  732: ドキュメントのバグを報告することも、
  733: プログラムのバグを報告することと同じくらい重要なことです。
  734: 
  735: @c   If the on-line documentation string of a function or variable disagrees
  736: @c with the manual, one of them must be wrong; that is a bug.
  737: 関数や変数のオンラインの説明文がマニュアルと一致しない場合は、
  738: どちらかがまちがっていますから、これもバグです。
  739: 
  740: @node Understanding Bug Reporting, Checklist, Bug Criteria, Bugs
  741: @c @subsection Understanding Bug Reporting
  742: @subsection バグの報告とは
  743: 
  744: @findex emacs-version
  745: @c   When you decide that there is a bug, it is important to report it and to
  746: @c report it in a way which is useful.  What is most useful is an exact
  747: @c description of what commands you type, starting with the shell command to
  748: @c run Emacs, until the problem happens.
  749: バグがあると確信したら、それを報告すること、
  750: しかも、役立つ形で報告することが重要です。
  751: もっとも有用なのは、どのようなコマンドを打ち込んだかを、
  752: Emacsを起動するシェルのコマンドから始めて
  753: 問題が起きるところまですべて正確に記述することです。
  754: 
  755: @c   The most important principle in reporting a bug is to report
  756: @c @emph{facts}.  Hypotheses and verbal descriptions are no substitute for
  757: @c the detailed raw data.  Reporting the facts is straightforward, but many
  758: @c people strain to posit explanations and report them instead of the
  759: @c facts.  If the explanations are based on guesses about how Emacs is
  760: @c implemented, they will be useless; meanwhile, lacking the facts, we will
  761: @c have no real information about the bug.
  762: バグを報告するときもっとも重要なことは@emph{事実}を報告することです。
  763: 仮説や口頭説明は、詳細な生データのかわりにはなりません。
  764: 事実を報告することは単純なはずなのに、
  765: 多くの人はかわりに説明をでっちあげてそれを報告したがります。
  766: その説明がEmacsの実装方式の想像に基づいたものであるならば、
  767: その説明はまったく役に立たないでしょう。
  768: 事実が欠けていたらバグに関する真の情報を得られません。
  769: 
  770: @c   For example, suppose that you type @kbd{C-x C-f /glorp/baz.ugh
  771: @c @key{RET}}, visiting a file which (you know) happens to be rather large,
  772: @c and Emacs displayed @samp{I feel pretty today}.  The best way to report
  773: @c the bug is with a sentence like the preceding one, because it gives all
  774: @c the facts.
  775: たとえば、ユーザーがとても大きなファイルを訪れるために
  776: @kbd{C-x C-f /glorp/baz.ugh @key{RET}}と打ち込んだら、
  777: Emacsが@samp{I feel pretty today}と表示したとしましょう。
  778: もっともよいバグレポートは、まさにこの文のように報告することです。
  779: すべての事実だけを報告できるからです。
  780: 
  781: @c   A bad way would be to assume that the problem is due to the size of
  782: @c the file and say, ``I visited a large file, and Emacs displayed @samp{I
  783: @c feel pretty today}.''  This is what we mean by ``guessing
  784: @c explanations.''  The problem is just as likely to be due to the fact
  785: @c that there is a @samp{z} in the file name.  If this is so, then when we
  786: @c got your report, we would try out the problem with some ``large file,''
  787: @c probably with no @samp{z} in its name, and not see any problem.  There
  788: @c is no way in the world that we could guess that we should try visiting a
  789: @c file with a @samp{z} in its name.
  790: 問題はファイルの大きさにあると仮定して、
  791: 「大きなファイルを訪問したら、Emacsが@samp{I feel pretty today}と表示した」
  792: などと書いてはいけません。
  793: これが『説明をでっちあげた』報告です。
  794: 問題はファイル名に@samp{z}が含まれていたために生じたのかもしれないのです。
  795: もしそうだとしたら、報告に基づいて適当な「大きなファイル」を訪問してみても、
  796: そのファイル名に@samp{z}が含まれていなければ何も悪いところが
  797: みつからないでしょう。
  798: 報告の文面からは、名前に@samp{z}を含んだファイルを
  799: 試しに訪問してみるべきだとはわかりません。
  800: 
  801: @c   Alternatively, the problem might be due to the fact that the file starts
  802: @c with exactly 25 spaces.  For this reason, you should make sure that you
  803: @c inform us of the exact contents of any file that is needed to reproduce the
  804: @c bug.  What if the problem only occurs when you have typed the @kbd{C-x C-a}
  805: @c command previously?  This is why we ask you to give the exact sequence of
  806: @c characters you typed since starting the Emacs session.
  807: あるいは、ファイルがちょうど25個の空白文字で始まっているために
  808: 問題が起きたのかもしれません。
  809: ですから、報告に際しては、そのバグを再現させるのに必要なファイルがあれば、
  810: それらのファイルの正確な内容も教えてください。
  811: その問題は、たまたま、@kbd{C-x C-a}と打った直後にのみ
  812: 発生するのだとしたらどうでしょう?@code{ }
  813: ですから、Emacsを起動してから問題に遭遇するまでに
  814: 打ち込んだものすべてを教えてほしいのです。
  815: 
  816: @c   You should not even say ``visit a file'' instead of @kbd{C-x C-f} unless
  817: @c you @emph{know} that it makes no difference which visiting command is used.
  818: @c Similarly, rather than saying ``if I have three characters on the line,''
  819: @c say ``after I type @kbd{@key{RET} A B C @key{RET} C-p},'' if that is
  820: @c the way you entered the text.@refill
  821: どの訪問コマンドを使っても同じように問題が発生すると@emph{知っている}
  822: のでない限り、@kbd{C-x C-f}と打ったと報告するかわりに
  823: 「ファイルを訪問した」というのさえいけません。
  824: 同様に、「1行に3文字入っているとき」ではなく、
  825: 「@kbd{@key{RET} A B C @key{RET} C-p}と打ち込んだあとで」のように、
  826: あなたがテキストを入れたやり方そのものを報告してください。
  827: 
  828: @c   So please don't guess any explanations when you report a bug.  If you
  829: @c want to actually @emph{debug} the problem, and report explanations that
  830: @c are more than guesses, that is useful---but please include the facts as
  831: @c well.
  832: このように、バグを報告するときには、いかなる説明も推測しないでください。
  833: 問題を実際に@emph{デバッグ}して憶測ではない説明を報告してもらえるなら、
  834: それは有益ですが、事実も含めてください。
  835: 
  836: @node Checklist, Sending Patches, Understanding Bug Reporting, Bugs
  837: @c @subsection Checklist for Bug Reports
  838: @subsection バグレポートのチェックリスト
  839: 
  840: @c @cindex reporting bugs
  841: @cindex バグを報告する
  842: @c   The best way to send a bug report is to mail it electronically to the
  843: @c Emacs maintainers at @samp{bug-gnu-emacs@@gnu.org}.  (If you
  844: @c want to suggest a change as an improvement, use the same address.)
  845: バグレポートを送る最良の方法は、電子メイルでEmacs保守チーム
  846: @samp{bug-gnu-emacs@@gnu.org}に送ることです。
  847: (重要な改良の提案などもここに送ってください)。
  848: 
  849: @c   If you'd like to read the bug reports, you can find them on the
  850: @c newsgroup @samp{gnu.emacs.bug}; keep in mind, however, that as a
  851: @c spectator you should not criticize anything about what you see there.
  852: @c The purpose of bug reports is to give information to the Emacs
  853: @c maintainers.  Spectators are welcome only as long as they do not
  854: @c interfere with this.  In particular, some bug reports contain large
  855: @c amounts of data; spectators should not complain about this.
  856: 他から出されたバグレポートが読みたければ、
  857: ニュースグループ@samp{gnu.emacs.bug}で読めます。
  858: ただし、傍観者として見る場合には、見たものについて批判するべきではない、
  859: ということを承知しておいてください。
  860: バグレポートの目的はEmacs保守チームに情報を提供することです。
  861: 傍観者は、この目的に干渉しない限りは、歓迎します。
  862: 特に、大量のデータが添付されているバグレポートもありますので、
  863: 傍観者はそのことを非難すべきではありません。
  864: 
  865: @c   Please do not post bug reports using netnews; mail is more reliable
  866: @c than netnews about reporting your correct address, which we may need in
  867: @c order to ask you for more information.
  868: ネットニュース経由でバグレポートを投稿しないでください。
  869: ネットニュースよりもメイルのほうが送り手のメイルアドレスが確実にわかり
  870: 信頼できます。
  871: もっと情報が必要なときには、メイルで問い合わせる必要があるかも知れません。
  872: 
  873: @c   If you can't send electronic mail, then mail the bug report on paper
  874: @c or machine-readable media to this address:
  875: 電子メイルを送れない場合には、
  876: 紙や他の機械可読な媒体で下記へ送ってください。
  877: 
  878: @format
  879: GNU Emacs Bugs
  880: Free Software Foundation
  881: 59 Temple Place, Suite 330
  882: Boston, MA 02111-1307 USA
  883: @end format
  884: 
  885: @c   We do not promise to fix the bug; but if the bug is serious,
  886: @c or ugly, or easy to fix, chances are we will want to.
  887: バグを修正するとは約束できません。
  888: しかし、重大なバグや、醜いバグや、簡単に直せるバグなら、直したいと思います。
  889: 
  890: @findex report-emacs-bug
  891: @c   A convenient way to send a bug report for Emacs is to use the command
  892: @c @kbd{M-x report-emacs-bug}.  This sets up a mail buffer (@pxref{Sending
  893: @c Mail}) and automatically inserts @emph{some} of the essential
  894: @c information.  However, it cannot supply all the necessary information;
  895: @c you should still read and follow the guidelines below, so you can enter
  896: @c the other crucial information by hand before you send the message.
  897: Emacsのバグレポートを送るのに便利な方法の1つは、
  898: コマンド@kbd{M-x report-emacs-bugs}を使うことです。
  899: このコマンドはメイルバッファ(@pxref{Sending Mail})を開いて、
  900: 自動的に重要な情報@emph{の一部}を書き込みます。
  901: しかし、必要な情報をすべて入れられるわけではありませんから、
  902: 以下の指針を読んでそれに従い、
  903: メッセージを送るまえに重要な情報を自分で打ち込んでください。
  904: 
  905: @c   To enable maintainers to investigate a bug, your report
  906: @c should include all these things:
  907: 保守チームがバグの調査を開始するためには、
  908: 以下のすべてがバグレポートに含まれている必要があります。
  909: 
  910: @itemize @bullet
  911: @item
  912: @c The version number of Emacs.  Without this, we won't know whether there
  913: @c is any point in looking for the bug in the current version of GNU
  914: @c Emacs.
  915: Emacsのバージョン番号。
  916: これがないと、GNU Emacsの最新版でバグを探すべきかどうか判断できない。
  917: 
  918: @c You can get the version number by typing @kbd{M-x emacs-version
  919: @c @key{RET}}.  If that command does not work, you probably have something
  920: @c other than GNU Emacs, so you will have to report the bug somewhere
  921: @c else.
  922: バージョン番号を調べるには、@kbd{M-x emacs-version @key{RET}}と打つ。
  923: このコマンドが動作しないようなら、
  924: GNU Emacsではないエディタを使っているようなので、
  925: どこか別のところへバグを報告する。
  926: 
  927: @item
  928: @c The type of machine you are using, and the operating system name and
  929: @c version number.  @kbd{M-x emacs-version @key{RET}} provides this
  930: @c information too.  Copy its output from the @samp{*Messages*} buffer, so
  931: @c that you get it all and get it accurately.
  932: 使っているマシンの種類、オペレーティングシステムの名前とバージョン。
  933: @kbd{M-x emacs-version @key{RET}}でこれらの情報も表示される。
  934: @samp{*Messages*}バッファからその出力をコピーすれば、
  935: すべての情報をまちがいなく送れる。
  936: 
  937: @item
  938: @c The operands given to the @code{configure} command when Emacs was
  939: @c installed.
  940: Emacsをインストールしたときの@code{configure}コマンドの引数。
  941: 
  942: @item
  943: @c A complete list of any modifications you have made to the Emacs source.
  944: @c (We may not have time to investigate the bug unless it happens in an
  945: @c unmodified Emacs.  But if you've made modifications and you don't tell
  946: @c us, you are sending us on a wild goose chase.)
  947: Emacsソースに変更を加えた場合は、そのすべてのリスト。
  948: (ソースを修正したEmacsで起きたバグまでも調査する時間はない。
  949: しかし、修正を加えたのにそれを教えてくれなければ、
  950: 厄介ごとを他人に押し付けているだけ。)
  951: 
  952: @c Be precise about these changes.  A description in English is not
  953: @c enough---send a context diff for them.
  954: これらの変更については正確に記してほしい。
  955: 英語での説明では不十分。
  956: ソースのコンテキストdiffを送ること。
  957: 
  958: @c Adding files of your own, or porting to another machine, is a
  959: @c modification of the source.
  960: 独自のファイルを追加したり、別のマシンに移植するのも、
  961: ソースの変更にあたる。
  962: 
  963: @item
  964: @c Details of any other deviations from the standard procedure for installing
  965: @c GNU Emacs.
  966: その他、GNU Emacsの標準のインストール手順と違っているところがあれば、
  967: すべて詳しく記述する。
  968: 
  969: @item
  970: @c The complete text of any files needed to reproduce the bug.
  971: そのバグを再現するために必要なすべてのファイルの内容。
  972: 
  973: @c   If you can tell us a way to cause the problem without visiting any files,
  974: @c please do so.  This makes it much easier to debug.  If you do need files,
  975: @c make sure you arrange for us to see their exact contents.  For example, it
  976: @c can often matter whether there are spaces at the ends of lines, or a
  977: @c newline after the last line in the buffer (nothing ought to care whether
  978: @c the last line is terminated, but try telling the bugs that).
  979: ファイルをまったく訪問せずに問題が再現可能なら、ぜひ教えてほしい。
  980: そのほうがデバッグがずっと楽になる。
  981: どうしてもファイルが必要なら、必ずその内容が正確にわかるようにすること。
  982: たとえば、行末に空白文字が付いているかどうかとか、
  983: バッファの最終行に改行文字があるかどうかが
  984: 問題になることは頻繁にある
  985: (最終行に改行があるかどうかで何か違いがあるべきではないのだが、
  986: もし違いが生じるようならそれもバグといえる)。
  987: 
  988: @item
  989: @c The precise commands we need to type to reproduce the bug.
  990: バグを再現させるために打ち込む正確なコマンド列。
  991: 
  992: @findex open-dribble-file
  993: @c @cindex dribble file
  994: @cindex ドリブルファイル
  995: @c   The easy way to record the input to Emacs precisely is to write a
  996: @c dribble file.  To start the file, execute the Lisp expression
  997: Emacsへの入力を正確に記録する簡単な方法は、
  998: ドリブルファイルに書くことである。
  999: ドリブルファイルを開始するには、
 1000: Emacsを実行開始した直後に、@kbd{M-:}か
 1001: バッファ@samp{*scratch*}でつぎのLisp式を実行する。
 1002: 
 1003: @example
 1004: (open-dribble-file "~/dribble")
 1005: @end example
 1006: 
 1007: @noindent
 1008: @c using @kbd{M-:} or from the @samp{*scratch*} buffer just after
 1009: @c starting Emacs.  From then on, Emacs copies all your input to the
 1010: @c specified dribble file until the Emacs process is killed.
 1011: それ以降はEmacsプロセスが終了するまで、
 1012: Emacsはすべての入力をドリブルファイルにコピーする。
 1013: 
 1014: @item
 1015: @findex open-termscript
 1016: @c @cindex termscript file
 1017: @c @cindex @code{TERM} environment variable
 1018: @cindex termscriptファイル
 1019: @cindex 環境変数@code{TERM}
 1020: @cindex @code{TERM}(環境変数)
 1021: @c For possible display bugs, the terminal type (the value of environment
 1022: @c variable @code{TERM}), the complete termcap entry for the terminal from
 1023: @c @file{/etc/termcap} (since that file is not identical on all machines),
 1024: @c and the output that Emacs actually sent to the terminal.
 1025: 表示に関するバグの可能性がある場合には、
 1026: 端末種別(環境変数@code{TERM}の値)、
 1027: (すべてのマシンで同じとは限らないので)
 1028: @file{/etc/termcap}ファイル中の当該端末のtermcapの定義すべて、
 1029: および、Emacsが実際に端末に送った出力。
 1030: 
 1031: @c The way to collect the terminal output is to execute the Lisp expression
 1032: 端末への出力を収集するには、Emacsを実行開始した直後に、@kbd{M-:}か
 1033: バッファ@samp{*scratch*}でつぎのLisp式を実行する。
 1034: 
 1035: @example
 1036: (open-termscript "~/termscript")
 1037: @end example
 1038: 
 1039: @noindent
 1040: @c using @kbd{M-:} or from the @samp{*scratch*} buffer just after
 1041: @c starting Emacs.  From then on, Emacs copies all terminal output to the
 1042: @c specified termscript file as well, until the Emacs process is killed.
 1043: @c If the problem happens when Emacs starts up, put this expression into
 1044: @c your @file{.emacs} file so that the termscript file will be open when
 1045: @c Emacs displays the screen for the first time.
 1046: それ以降、Emacsはプロセスが終了するまでのすべての端末出力の写しを
 1047: 指定されたtermscriptファイルに書き出す。
 1048: Emacsが起動するときに問題が起きるのなら、
 1049: 上の式を@file{.emacs}ファイルに入れて、
 1050: Emacsが最初に画面を開くときに一緒にtermscriptファイルも
 1051: 書き始めるようにする。
 1052: 
 1053: @c Be warned: it is often difficult, and sometimes impossible, to fix a
 1054: @c terminal-dependent bug without access to a terminal of the type that
 1055: @c stimulates the bug.@refill
 1056: ただし、端末に依存したバグは、
 1057: そのバグの出る端末なしで直すことは難しいことが多く、
 1058: ときとして不可能であることも承知しておいてほしい。
 1059: 
 1060: @item
 1061: @c A description of what behavior you observe that you believe is
 1062: @c incorrect.  For example, ``The Emacs process gets a fatal signal,'' or,
 1063: @c ``The resulting text is as follows, which I think is wrong.''
 1064: 正しくないと結論したことがどう正しくないのか記述する。
 1065: たとえば、「Emacsプロセスが致命的なシグナルを受け取る」とか
 1066: 「最終的なテキストはつぎのようになるが、これは正しくない。」など。
 1067: 
 1068: @c Of course, if the bug is that Emacs gets a fatal signal, then one can't
 1069: @c miss it.  But if the bug is incorrect text, the maintainer might fail to
 1070: @c notice what is wrong.  Why leave it to chance?
 1071: もちろん、Emacsが致命的なシグナルを受け取るのなら、それは誰にでもわかる。
 1072: しかし、バグが正しくないテキストだとすると、
 1073: 保守チームにはどこが正しくないのかわからない可能性がある。
 1074: そういう可能性のある書き方はやめてほしい。
 1075: 
 1076: @c Even if the problem you experience is a fatal signal, you should still
 1077: @c say so explicitly.  Suppose something strange is going on, such as, your
 1078: @c copy of the source is out of sync, or you have encountered a bug in the
 1079: @c C library on your system.  (This has happened!)  Your copy might crash
 1080: @c and the copy here might not.  If you @emph{said} to expect a crash, then
 1081: @c when Emacs here fails to crash, we would know that the bug was not
 1082: @c happening.  If you don't say to expect a crash, then we would not know
 1083: @c whether the bug was happening---we would not be able to draw any
 1084: @c conclusion from our observations.
 1085: 遭遇する問題が致命的なシグナルだとしても、はっきりとそう書くべきである。
 1086: たとえば、Emacsのソースが一部違っている版だったとか、
 1087: システムのCライブラリのバグに遭遇したといった
 1088: 奇妙なことに出会ったとしよう(実話!)。
 1089: あなたが使っているEmacsはクラッシュするが、保守チームのほうでは何ともない。
 1090: クラッシュすると@emph{いって}もらえれば、
 1091: 保守チームのほうで実行してクラッシュしなければバグが再現しないとわかる。
 1092: しかしそういってもらえないと、
 1093: バグが再現したのかどうかさえわからずに、
 1094: 試してみた結果からは何の結論も得られない。
 1095: 
 1096: @item
 1097: @c If the manifestation of the bug is an Emacs error message, it is
 1098: @c important to report the precise text of the error message, and a
 1099: @c backtrace showing how the Lisp program in Emacs arrived at the error.
 1100: バグの結果がEmacsのエラーメッセージであれば、
 1101: そのエラーメッセージの文面を正確に報告することと、
 1102: Emacs中のLispプログラムがどうやってそのエラーの箇所に
 1103: 到達したかを示すバックトレースを報告することが重要。
 1104: 
 1105: @c To get the error message text accurately, copy it from the
 1106: @c @samp{*Messages*} buffer into the bug report.  Copy all of it, not just
 1107: @c part.
 1108: エラーメッセージの文面を正確に報告するには、
 1109: @samp{*Message*}バッファからメッセージをバグレポートにコピーする。
 1110: 一部ではなく、全体をコピーしてほしい。
 1111: 
 1112: @c To make a backtrace for the error, evaluate the Lisp expression
 1113: @c @code{(setq @w{debug-on-error t})} before the error happens (that is to
 1114: @c say, you must execute that expression and then make the bug happen).
 1115: @c This causes the error to run the Lisp debugger, which shows you a
 1116: @c backtrace.  Copy the text of the debugger's backtrace into the bug
 1117: @c report.
 1118: エラーのバックトレースを取得するには、エラーが発生するよりまえにLisp式
 1119: @code{(setq @w{debug-on-error t})}を評価する
 1120: (つまり、まずこのLisp式を実行して、それからエラーを再現させる)。
 1121: すると、エラーが起きたときにLispデバッガが実行され、
 1122: デバッガがバックトレースを表示する。
 1123: このデバッガのバックトレース出力を、バグレポートにコピーする。
 1124: 
 1125: @c This use of the debugger is possible only if you know how to make the
 1126: @c bug happen again.  If you can't make it happen again, at least copy
 1127: @c the whole error message.
 1128: このやり方は、バグを再現できるときだけ使える。
 1129: 再現できない場合は、最低限、エラーメッセージだけでもすべてコピーする。
 1130: 
 1131: @item
 1132: @c Check whether any programs you have loaded into the Lisp world,
 1133: @c including your @file{.emacs} file, set any variables that may affect the
 1134: @c functioning of Emacs.  Also, see whether the problem happens in a
 1135: @c freshly started Emacs without loading your @file{.emacs} file (start
 1136: @c Emacs with the @code{-q} switch to prevent loading the init file).  If
 1137: @c the problem does @emph{not} occur then, you must report the precise
 1138: @c contents of any programs that you must load into the Lisp world in order
 1139: @c to cause the problem to occur.
 1140: 個人のファイル@file{.emacs}を含めてロードしたLispコードのどれかが、
 1141: Emacsの動作に影響するような変数設定を行っていないか確認する。
 1142: また、(オプション@code{-q}を指定して初期化ファイルのロードを抑制して)
 1143: 個人のファイル@file{.emacs}をロードせずに起動したEmacsでも
 1144: エラーが再現するかどうか調べる。
 1145: これでエラーが再現@emph{しない}なら、
 1146: エラーの再現に必要なので、ロードしたすべてのプログラムの内容を正確に報告する。
 1147: 
 1148: @item
 1149: @c If the problem does depend on an init file or other Lisp programs that
 1150: @c are not part of the standard Emacs system, then you should make sure it
 1151: @c is not a bug in those programs by complaining to their maintainers
 1152: @c first.  After they verify that they are using Emacs in a way that is
 1153: @c supposed to work, they should report the bug.
 1154: 問題が初期設定ファイルや標準のEmacsシステムに含まれないLispプログラムに
 1155: 依存するなら、まずそれらを保守している人に相談して、
 1156: それらのプログラムの問題ではないことを確認する。
 1157: その人たちが、そのコードはEmacsの正しい使い方をしていると確認したうえで、
 1158: その人たちがバグを報告するべきである。
 1159: 
 1160: @item
 1161: @c If you wish to mention something in the GNU Emacs source, show the line
 1162: @c of code with a few lines of context.  Don't just give a line number.
 1163: GNU Emacsのソースに関して何かコメントしたいなら、
 1164: その部分のコードを前後数行を含めて示したうえでコメントする。
 1165: 行番号だけ書くというのはやめてほしい。
 1166: 
 1167: @c The line numbers in the development sources don't match those in your
 1168: @c sources.  It would take extra work for the maintainers to determine what
 1169: @c code is in your version at a given line number, and we could not be
 1170: @c certain.
 1171: 開発中のソースの行番号とユーザーが入手するソースの行番号とは同じではない。
 1172: あなたが使っているバージョンのソースの何行目が、
 1173: 開発中のソースの何行目に対応しているか調べるのは余分な手間であり、
 1174: 正確にはわからないかもしれない。
 1175: 
 1176: @item
 1177: @c Additional information from a C debugger such as GDB might enable
 1178: @c someone to find a problem on a machine which he does not have available.
 1179: @c If you don't know how to use GDB, please read the GDB manual---it is not
 1180: @c very long, and using GDB is easy.  You can find the GDB distribution,
 1181: @c including the GDB manual in online form, in most of the same places you
 1182: @c can find the Emacs distribution.  To run Emacs under GDB, you should
 1183: @c switch to the @file{src} subdirectory in which Emacs was compiled, then
 1184: @c do @samp{gdb emacs}.  It is important for the directory @file{src} to be
 1185: @c current so that GDB will read the @file{.gdbinit} file in this
 1186: @c directory.
 1187: GDBなどのC言語用のデバッガからの追加情報があると、
 1188: 保守チームの手元にないマシンでもバグの原因がわかることもある。
 1189: もしGDBの使い方がわからないようなら、GDBのマニュアルをぜひ読んでほしい。
 1190: たいして長くないし、GDBを使うのは簡単。
 1191: GDBのオンライン形式のマニュアルを含むGDBの配布は、
 1192: たいていはEmacsの配布と同じ場所に置いてある。
 1193: GDBを用いてEmacsを実行するには、
 1194: Emacsをコンパイルしたサブディレクトリ@file{src}に移動してから、
 1195: @samp{gdb emacs}を行う必要がある。
 1196: GDBがディレクトリ@file{src}にあるファイル@file{.gdbinit}を読めるように、
 1197: このディレクトリがカレントディレクトリであることが重要。
 1198: 
 1199: @c However, you need to think when you collect the additional information
 1200: @c if you want it to show what causes the bug.
 1201: ただし、バグの原因を示すために追加情報を集める場合には、
 1202: 追加情報をいつ集めるかをよく考える必要がある。
 1203: 
 1204: @c @cindex backtrace for bug reports
 1205: @cindex バグレポート用のバックトレース
 1206: @c For example, many people send just a backtrace, but that is not very
 1207: @c useful by itself.  A simple backtrace with arguments often conveys
 1208: @c little about what is happening inside GNU Emacs, because most of the
 1209: @c arguments listed in the backtrace are pointers to Lisp objects.  The
 1210: @c numeric values of these pointers have no significance whatever; all that
 1211: @c matters is the contents of the objects they point to (and most of the
 1212: @c contents are themselves pointers).
 1213: たとえば、多くの人はバックトレースだけを送ってくるが、
 1214: それ単体ではあまり役に立たない。
 1215: 引数の記録つきの単純なバックトレースでは、
 1216: GNU Emacsの内部で何が起きているかについての情報はほとんどない。
 1217: というのは、バックトレースに表示される引数のほとんどは
 1218: Lispオブジェクトへのポインタだから。
 1219: それらのポインタの値そのものは、なんら重要ではない。
 1220: 重要なのは、ポインタが指している先のオブジェクトの内容
 1221: (そしてその内容もまたポインタであることが多い)。
 1222: 
 1223: @findex debug_print
 1224: @c To provide useful information, you need to show the values of Lisp
 1225: @c objects in Lisp notation.  Do this for each variable which is a Lisp
 1226: @c object, in several stack frames near the bottom of the stack.  Look at
 1227: @c the source to see which variables are Lisp objects, because the debugger
 1228: @c thinks of them as integers.
 1229: 役に立つ情報を提供するには、
 1230: Lispオブジェクトの値をLispの記法で示す必要がある。
 1231: スタックの底付近にある数個のフレームについて、
 1232: Lispオブジェクトであるような各変数に対してこれを行ってほしい。
 1233: デバッガは単なる整数だと思うので、
 1234: どの変数がLispオブジェクトであるかはソースを見てほしい。
 1235: 
 1236: @c To show a variable's value in Lisp syntax, first print its value, then
 1237: @c use the user-defined GDB command @code{pr} to print the Lisp object in
 1238: @c Lisp syntax.  (If you must use another debugger, call the function
 1239: @c @code{debug_print} with the object as an argument.)  The @code{pr}
 1240: @c command is defined by the file @file{.gdbinit}, and it works only if you
 1241: @c are debugging a running process (not with a core dump).
 1242: 変数の値をLispの記法で示すには、まず、その値をプリントしてから、
 1243: GDBのユーザー定義コマンド@code{pr}を使ってLispオブジェクトをLispの記法で
 1244: 表示させる。
 1245: (別のデバッガを使わなければならない場合は、
 1246: オブジェクトを引数として関数@code{debug_print}を呼び出す)。
 1247: コマンド@code{pr}は、ファイル@file{.gdbinit}で定義されており、
 1248: (コアダンプではなく)実行中のプロセスをデバッグするときだけ使える。
 1249: 
 1250: @c To make Lisp errors stop Emacs and return to GDB, put a breakpoint at
 1251: @c @code{Fsignal}.
 1252: Lispでエラーが発生したときにEmacsを中断してGDBに戻るようにするには、
 1253: @code{Fsignal}にブレークポイントを設定する。
 1254: 
 1255: @c For a short listing of Lisp functions running, type the GDB
 1256: @c command @code{xbacktrace}.  
 1257: 実行中のLisp関数の簡素な一覧を表示するには、
 1258: GDBのコマンド@code{xbacktrace}を打つ。
 1259: 
 1260: @c If you want to examine Lisp function arguments, move up the stack, and
 1261: @c each time you get to a frame for the function @code{Ffuncall}, type
 1262: @c these GDB commands:
 1263: Lisp関数の引数を調べたい場合には、
 1264: スタック上を上に移動していき関数@code{Ffuncall}のフレームに到達するごとに、
 1265: つぎのようなGDBコマンドを打つ。
 1266: 
 1267: @example
 1268: p *args
 1269: pr
 1270: @end example
 1271: 
 1272: @noindent
 1273: @c To print the first argument that the function received, use these
 1274: @c commands:
 1275: 関数が受け取った最初の引数を出力するには、つぎのようにする。
 1276: 
 1277: @example
 1278: p args[1]
 1279: pr
 1280: @end example
 1281: 
 1282: @noindent
 1283: @c You can print the other arguments likewise.  The argument @code{nargs}
 1284: @c of @code{Ffuncall} says how many arguments @code{Ffuncall} received;
 1285: @c these include the Lisp function itself and the arguments for that
 1286: @c function.
 1287: 2番目以降の引数でも同様に出力できる。
 1288: @code{Ffuncall}の引数@code{nargs}は、
 1289: @code{Ffuncall}が受け取った引数の個数を表す。
 1290: この個数は、Lisp関数自身とその関数に対する引数とを合わせた数。
 1291: 
 1292: @c The file @file{.gdbinit} defines several other commands that are useful
 1293: @c for examining the data types and contents of Lisp objects.  Their names
 1294: @c begin with @samp{x}.  These commands work at a lower level than
 1295: @c @code{pr}, and are less convenient, but they may work even when
 1296: @c @code{pr} does not, such as when debugging a core dump or when Emacs has
 1297: @c had a fatal signal.
 1298: ファイル@file{.gdbinit}は、
 1299: データタイプやLispオブジェクトの中身を調べるのに役立つコマンド類を定義する。
 1300: それらのコマンドの名前は@samp{x}で始まる。
 1301: これらのコマンドは@code{pr}より下位のレベルで動作し使い難いが、
 1302: コアダンプをデバックしたり、
 1303: Emacsが致命的なシグナルを受理したときのように
 1304: @code{pr}がうまく動かないときでも使える。
 1305: 
 1306: @item
 1307: @c If the symptom of the bug is that Emacs fails to respond, don't assume
 1308: @c Emacs is ``hung''---it may instead be in an infinite loop.  To find out
 1309: @c which, make the problem happen under GDB and stop Emacs once it is not
 1310: @c responding.  (If Emacs is using X Windows directly, you can stop Emacs
 1311: @c by typing @kbd{C-z} at the GDB job.)  Then try stepping with
 1312: @c @samp{step}.  If Emacs is hung, the @samp{step} command won't return.
 1313: @c If it is looping, @samp{step} will return.
 1314: バグの症状がEmacsが応答しなくなるというものでも、
 1315: Emacsが『ハング』した(固まった)と考えてはいけない。
 1316: 無限ループに入っているのかもしれない。
 1317: どちらであるかを調べるには、
 1318: GDBのもとでバグを再現させ、応答しなくなったところでEmacsを止める。
 1319: (EmacsがXウィンドウシステムを直接使っている場合は、
 1320: GDBのジョブに対して@kbd{C-z}を打てばEmacsを止められる)。
 1321: そして、コマンド@samp{step}で1ステップずつ実行を試みる。
 1322: 固まっているのならコマンド@samp{step}から戻ってこない。
 1323: ループしているなら@samp{step}から戻ってくる。
 1324: 
 1325: @c If this shows Emacs is hung in a system call, stop it again and examine
 1326: @c the arguments of the call.  In your bug report, state exactly where in
 1327: @c the source the system call is, and what the arguments are.
 1328: こうして調べた結果、Emacsがシステムコールの中で固まっているとわかったら、
 1329: Emacsを再度止めて、システムコールの引数を調べる。
 1330: そしてバグレポートには、ソース中でのシステムコールの正確な位置と、
 1331: 引数が何だったかを正確に記入する。
 1332: 
 1333: @c If Emacs is in an infinite loop, please determine where the loop starts
 1334: @c and ends.  The easiest way to do this is to use the GDB command
 1335: @c @samp{finish}.  Each time you use it, Emacs resumes execution until it
 1336: @c exits one stack frame.  Keep typing @samp{finish} until it doesn't
 1337: @c return---that means the infinite loop is in the stack frame which you
 1338: @c just tried to finish.
 1339: Emacsが無限ループしているのなら、ループの始まりと終りを調べる。
 1340: もっとも簡単にこれを調べるには、GDBのコマンド@samp{finish}を使う。
 1341: このコマンドを使うたびに、1つのスタックフレームから抜けるまで
 1342: Emacsは実行を継続する。
 1343: 戻ってこなくなるまで、繰り返し@samp{finish}を打つ。
 1344: 戻ってこないのは、そのフレームで無限ループが起こっているからである。
 1345: 
 1346: @c Stop Emacs again, and use @samp{finish} repeatedly again until you get
 1347: @c @emph{back to} that frame.  Then use @samp{next} to step through that
 1348: @c frame.  By stepping, you will see where the loop starts and ends.  Also
 1349: @c please examine the data being used in the loop and try to determine why
 1350: @c the loop does not exit when it should.  Include all of this information
 1351: @c in your bug report.
 1352: ここでEmacsを再度停止し、
 1353: 戻ってこなくなったフレームに@emph{ちょうど戻る}まで、
 1354: 繰り返し@samp{finish}を使う。
 1355: つぎに、@samp{next}を使ってそのフレーム内で1ステップずつ実行する。
 1356: こうすれば、ループがどこで始まりどこで終るかわかる。
 1357: さらに、ループ内で使われているデータを調べて、
 1358: ループが終るべきところでなぜ終らないかを追求してみてほしい。
 1359: これらの情報すべてを、バグレポートに含める。
 1360: @end itemize
 1361: 
 1362: @c Here are some things that are not necessary in a bug report:
 1363: 以下には、バグレポートに必要ないものをあげておきます。
 1364: 
 1365: @itemize @bullet
 1366: @item
 1367: @c A description of the envelope of the bug---this is not necessary for a
 1368: @c reproducible bug.
 1369: バグの生起条件に関する記述。
 1370: 再現可能なバグに対しては不要。
 1371: 
 1372: @c Often people who encounter a bug spend a lot of time investigating
 1373: @c which changes to the input file will make the bug go away and which
 1374: @c changes will not affect it.
 1375: バグに出会った人はしばしば、入力をどう変えるとバグが出なくなるとか、
 1376: あるいは、相変わらず出るといったことを探求するのに時間をかける。
 1377: 
 1378: @c This is often time-consuming and not very useful, because the way we
 1379: @c will find the bug is by running a single example under the debugger with
 1380: @c breakpoints, not by pure deduction from a series of examples.  You might
 1381: @c as well save time by not searching for additional examples.
 1382: これは時間がかかるわりには、役に立たない。
 1383: というのは、保守チームがデバッグを行うときには、
 1384: デバッガのもとでブレークポイントを設定しながらバグの出る1つの例を
 1385: 実行するのであって、何通りもの例から帰納的に推論するわけではない。
 1386: だから、別の例を探すのに時間をかけたりしないでほしい。
 1387: 
 1388: @c Of course, if you can find a simpler example to report @emph{instead} of
 1389: @c the original one, that is a convenience.  Errors in the output will be
 1390: @c easier to spot, running under the debugger will take less time, etc.
 1391: もちろん、もとの例の@emph{かわりに}使えるもっと簡単な例がみつかれば、
 1392: それは役に立つ。
 1393: 簡単な例なら、出力中のエラーもみつけやすくなり、
 1394: デバッガを使って実行するにも短い時間ですむ。
 1395: 
 1396: @c However, simplification is not vital; if you can't do this or don't have
 1397: @c time to try, please report the bug with your original test case.
 1398: ただし、単純化は必須ではない。
 1399: もし単純化できなかったり、単純化する時間がなければ、
 1400: もとの例のままでよいので、バグレポートを出してほしい。
 1401: 
 1402: @item
 1403: @c A system-call trace of Emacs execution.
 1404: Emacs実行のシステムコールトレース
 1405: 
 1406: @c System-call traces are very useful for certain special kinds of
 1407: @c debugging, but in most cases they give little useful information.  It is
 1408: @c therefore strange that many people seem to think that @emph{the} way to
 1409: @c report information about a crash is to send a system-call trace.  Perhaps
 1410: @c this is a habit formed from experience debugging programs that don't
 1411: @c have source code or debugging symbols.
 1412: ある特別な種類のバグについては、システムコールトレースは非常に役立つが、
 1413: 多くの場合はほとんど有用な情報は得られない。
 1414: したがって、多くの人がシステムコールのトレースこそクラッシュに
 1415: 関する情報を報告するのに欠かせないものだと思っているらしいのは、
 1416: 不思議である。
 1417: これはたぶん、ソースコードやデバッグ用シンボルのないプログラムを
 1418: デバッグした経験から生まれた習慣だろう。
 1419: 
 1420: @c In most programs, a backtrace is normally far, far more informative than
 1421: @c a system-call trace.  Even in Emacs, a simple backtrace is generally
 1422: @c more informative, though to give full information you should supplement
 1423: @c the backtrace by displaying variable values and printing them as Lisp
 1424: @c objects with @code{pr} (see above).
 1425: ほとんどのプログラムでは、システムコールのトレースより、
 1426: バックトレースのほうがずっとずっと役に立つ。
 1427: Emacsでさえ、単純なバックトレースのほうが有用である。
 1428: しかし、十分な情報を提供するには、バックトレースの補記として、
 1429: 変数の値を表示し@code{pr}でLispオブジェクトとしても表示する(上記参照)。
 1430: 
 1431: @item
 1432: @c A patch for the bug.
 1433: バグに対する修正。
 1434: 
 1435: @c A patch for the bug is useful if it is a good one.  But don't omit the
 1436: @c other information that a bug report needs, such as the test case, on the
 1437: @c assumption that a patch is sufficient.  We might see problems with your
 1438: @c patch and decide to fix the problem another way, or we might not
 1439: @c understand it at all.  And if we can't understand what bug you are
 1440: @c trying to fix, or why your patch should be an improvement, we mustn't
 1441: @c install it.
 1442: バグに対する修正は、よい品質のものなら有用である。
 1443: しかし、修正が正しいことを示すテスト例などの
 1444: バグレポートに必要な情報を省かないでほしい。
 1445: 修正に問題があるとわかって別のやり方でバグをつぶすかもしれないし、
 1446: 報告された修正がまったく理解できないこともありえる。
 1447: そして、どんなバグを修正しようとしているのかわからない、あるいは、
 1448: その修正がなぜ改良になるのかわからなければ、
 1449: その修正を採用するわけにいかない。
 1450: 
 1451: @ifinfo
 1452: @c @xref{Sending Patches}, for guidelines on how to make it easy for us to
 1453: @c understand and install your patches.
 1454: 我々にとって、読者のパッチが理解しやすく、
 1455: インストールしやすくするための指針については、
 1456: @pxref{Sending Patches}。
 1457: @end ifinfo
 1458: 
 1459: @item
 1460: @c A guess about what the bug is or what it depends on.
 1461: バグが何であるか、また何に依存しているかについての予想。
 1462: 
 1463: @c Such guesses are usually wrong.  Even experts can't guess right about
 1464: @c such things without first using the debugger to find the facts.
 1465: こういう予想は、たいていはまちがっている。
 1466: 専門家でさえ、まずデバッガで事実を調べない限り、正しい予想はできない。
 1467: @end itemize
 1468: 
 1469: @node Sending Patches,  , Checklist, Bugs
 1470: @c @subsection Sending Patches for GNU Emacs
 1471: @subsection GNU Emacsに対する修正を送る
 1472: 
 1473: @c @cindex sending patches for GNU Emacs
 1474: @c @cindex patches, sending
 1475: @cindex GNU Emacsに対する修正を送る
 1476: @cindex 修正を送る
 1477: @c   If you would like to write bug fixes or improvements for GNU Emacs,
 1478: @c that is very helpful.  When you send your changes, please follow these
 1479: @c guidelines to make it easy for the maintainers to use them.  If you
 1480: @c don't follow these guidelines, your information might still be useful,
 1481: @c but using it will take extra work.  Maintaining GNU Emacs is a lot of
 1482: @c work in the best of circumstances, and we can't keep up unless you do
 1483: @c your best to help.
 1484: GNU Emacsに対する改良や虫取りのための修正を送ろうということであれば、
 1485: おおいに助かります。
 1486: 修正を送るにあたっては、保守チームがそれを役立てやすいように、
 1487: 以下の指針に従ってください。
 1488: さもないと、送られた情報は有用であっても、
 1489: 役立てるには余分な作業が必要になります。
 1490: GNU Emacsの保守は最善の環境でやっても手間のかかる仕事ですから、
 1491: 手助けしていただくにしても十分な配慮が必要なのです。
 1492: 
 1493: @itemize @bullet
 1494: @item
 1495: @c Send an explanation with your changes of what problem they fix or what
 1496: @c improvement they bring about.  For a bug fix, just include a copy of the
 1497: @c bug report, and explain why the change fixes the bug.
 1498: その修正がどのような問題を解決するものか、
 1499: またはどのような改善をもたらすものなのかの説明を送ってほしい。
 1500: バグに対する修正の場合は、バグレポートのコピーと、
 1501: なぜこの修正でバグが取れるのかの説明を含める。
 1502: 
 1503: @c (Referring to a bug report is not as good as including it, because then
 1504: @c we will have to look it up, and we have probably already deleted it if
 1505: @c we've already fixed the bug.)
 1506: (バグレポートへのポインタを示すよりも、
 1507: バグレポートのコピーを含めるほうが望ましい。
 1508: というのは、ポインタだとバグレポートを探す必要があるし、
 1509: そのバグを直し終えていると、バグレポートを消してしまっているかもしれない。)
 1510: 
 1511: @item
 1512: @c Always include a proper bug report for the problem you think you have
 1513: @c fixed.  We need to convince ourselves that the change is right before
 1514: @c installing it.  Even if it is correct, we might have trouble
 1515: @c understanding it if we don't have a way to reproduce the problem.
 1516: 修正したと思う問題に対応した適切なバグレポート全体をつねに含めてほしい。
 1517: 保守チームのほうでも修正を適用するまえにその変更が適切なものであることを
 1518: 確信する必要がある。
 1519: たとえ修正が正しいものであっても、もとの問題を再現する方法がないと、
 1520: 修正内容を正しく理解できないかもしれない。
 1521: 
 1522: @item
 1523: @c Include all the comments that are appropriate to help people reading the
 1524: @c source in the future understand why this change was needed.
 1525: 将来そのソースを読むすべての人に、その変更がなぜ必要だったか
 1526: 理解するのを助けるに足るだけのコメントをソースに入れる。
 1527: 
 1528: @item
 1529: @c Don't mix together changes made for different reasons.
 1530: @c Send them @emph{individually}.
 1531: 異なる理由に基づく変更を混ぜない。
 1532: あくまでも@emph{別々に}送る。
 1533: 
 1534: @c If you make two changes for separate reasons, then we might not want to
 1535: @c install them both.  We might want to install just one.  If you send them
 1536: @c all jumbled together in a single set of diffs, we have to do extra work
 1537: @c to disentangle them---to figure out which parts of the change serve
 1538: @c which purpose.  If we don't have time for this, we might have to ignore
 1539: @c your changes entirely.
 1540: 異なる理由に基づいて2つの変更を行った場合、
 1541: その両方を採用することはないだろう。
 1542: どちらか一方だけを採用するかもしれない。
 1543: もしそれらをいっしょくたに1つのdiffにしてしまうと、
 1544: それを分離するために余計な作業が必要になる。
 1545: どの部分の変更がどちらの目的に対応しているのか調べる必要がある。
 1546: その時間を割けないと、その変更をまったく
 1547: 採用しないということにもなりかねない。
 1548: 
 1549: @c If you send each change as soon as you have written it, with its own
 1550: @c explanation, then two changes never get tangled up, and we can consider
 1551: @c each one properly without any extra work to disentangle them.
 1552: それぞれの変更を行ってすぐに、別個に、説明を付けて送ってもらえれば、
 1553: 2つの変更が一緒になるなどということはないし、
 1554: それぞれの変更を分離するなどの余計な作業をせずに適切に考慮できる。
 1555: 
 1556: @item
 1557: @c Send each change as soon as that change is finished.  Sometimes people
 1558: @c think they are helping us by accumulating many changes to send them all
 1559: @c together.  As explained above, this is absolutely the worst thing you
 1560: @c could do.
 1561: それぞれの変更は完成したらすぐに送ってほしい。
 1562: ときどき、多くの変更を溜めておいてまとめて送ったほうが
 1563: いいと思っている人に出会う。
 1564: 上で説明したように、それは最悪のやり方。
 1565: 
 1566: @c Since you should send each change separately, you might as well send it
 1567: @c right away.  That gives us the option of installing it immediately if it
 1568: @c is important.
 1569: それぞれの変更は別個に送るべきなので、変更を行ったらすぐに送れるはず。
 1570: そうすれば、保守チームのほうでその変更が重要なものだと
 1571: 判断したらすぐ取り入れることができる。
 1572: 
 1573: @item
 1574: @c Use @samp{diff -c} to make your diffs.  Diffs without context are hard
 1575: @c to install reliably.  More than that, they are hard to study; we must
 1576: @c always study a patch to decide whether we want to install it.  Unidiff
 1577: @c format is better than contextless diffs, but not as easy to read as
 1578: @c @samp{-c} format.
 1579: diffファイルを作るときには、@samp{diff -c}を使う。
 1580: コンテキストdiffでないdiffファイルは正しく適用するのが難しい。
 1581: それ以上に、調べるのもたいへん。
 1582: 必ず保守チームの人間が修正を適用するかどうか検討する。
 1583: @samp{-u}形式は行番号だけのdiffよりはましだが、
 1584: いちばん読みやすいのは@samp{-c}形式。
 1585: 
 1586: @c If you have GNU diff, use @samp{diff -c -F'^[_a-zA-Z0-9$]+ *('} when
 1587: @c making diffs of C code.  This shows the name of the function that each
 1588: @c change occurs in.
 1589: もしGNU diffを使っているのなら、Cのコードのdiffを作るときには
 1590: @samp{diff -c -F'^[_a-zA-Z0-9$]+ *('}を使う。
 1591: こうすると、変更される各関数の名前が一緒に表示される。
 1592: 
 1593: @item
 1594: @c Avoid any ambiguity as to which is the old version and which is the new.
 1595: @c Please make the old version the first argument to diff, and the new
 1596: @c version the second argument.  And please give one version or the other a
 1597: @c name that indicates whether it is the old version or your new changed
 1598: @c one.
 1599: どっちが古い版でどっちが新しい版か曖昧さがないようにする。
 1600: diffコマンドの第1引数に古いファイル、第2引数に新しいファイルを指定して
 1601: diffファイルを作成する。
 1602: そして、それぞれのファイル名を見ればどっちが古い版でどっちが
 1603: 新しい版かわかるようにファイル名を付ける。
 1604: 
 1605: @item
 1606: @c Write the change log entries for your changes.  This is both to save us
 1607: @c the extra work of writing them, and to help explain your changes so we
 1608: @c can understand them.
 1609: 変更に対する変更記録を書く。
 1610: そうしてあれば、保守チームのほうで書く時間が節約でき、
 1611: 保守チームが変更内容を理解する手助けにもなる。
 1612: 
 1613: @c The purpose of the change log is to show people where to find what was
 1614: @c changed.  So you need to be specific about what functions you changed;
 1615: @c in large functions, it's often helpful to indicate where within the
 1616: @c function the change was.
 1617: 変更記録の目的は、人が読んでどこが変わったかわかるようにすること。
 1618: だから、どの関数を変更したか具体的に書く。
 1619: 大きい関数の場合は、関数の中のどの箇所を変更したかも書いてあると助かる。
 1620: 
 1621: @c On the other hand, once you have shown people where to find the change,
 1622: @c you need not explain its purpose in the change log.  Thus, if you add a
 1623: @c new function, all you need to say about it is that it is new.  If you
 1624: @c feel that the purpose needs explaining, it probably does---but put the
 1625: @c explanation in comments in the code.  It will be more useful there.
 1626: その反面、どこが変更されたかわかるようにさえなっていれば、
 1627: 変更の目的は変更記録で説明する必要はない。
 1628: たとえば、新しい関数を追加したのであれば、
 1629: その関数が新しいということだけを書けば十分。
 1630: 目的を説明したほうがよいと感じるなら、たぶんそのとおりだろう。
 1631: しかし、説明はコード中のコメントに書く。
 1632: そのほうが役に立つ。
 1633: 
 1634: @c Please read the @file{ChangeLog} files in the @file{src} and @file{lisp}
 1635: @c directories to see what sorts of information to put in, and to learn the
 1636: @c style that we use.  If you would like your name to appear in the header
 1637: @c line, showing who made the change, send us the header line.
 1638: @c @xref{Change Log}.
 1639: ディレクトリ@file{src}とディレクトリ@file{lisp}の
 1640: ファイル@file{ChangeLog}を眺めて、どのような情報を入れるかとか、
 1641: どのようなスタイルで書くかの参考にしてほしい。
 1642: 誰が変更したかわかるように自分の名前をヘッダの行に記録したいなら、
 1643: ヘッダ行も送ること。
 1644: 
 1645: @item
 1646: @c When you write the fix, keep in mind that we can't install a change that
 1647: @c would break other systems.  Please think about what effect your change
 1648: @c will have if compiled on another type of system.
 1649: 修正を行うにあたっては、他のシステムで動かなくなるような変更は
 1650: 採用できないということを承知しておいてほしい。
 1651: 自分が行う変更が、他の種類のシステムにおいては
 1652: どのような影響をもたらすかについて熟慮してほしい。
 1653: 
 1654: @c Sometimes people send fixes that @emph{might} be an improvement in
 1655: @c general---but it is hard to be sure of this.  It's hard to install
 1656: @c such changes because we have to study them very carefully.  Of course,
 1657: @c a good explanation of the reasoning by which you concluded the change
 1658: @c was correct can help convince us.
 1659: ときどき、おおむね改良になる@emph{かも}しれないが、
 1660: はっきり改良だとはいいがたいような変更を送ってくる人がいる。
 1661: そのような変更は、きわめて慎重に検討しなければならないので、
 1662: 採用するのは難しい。
 1663: もちろん、あなたがどのような理由でその変更が正しいのかよい説明を
 1664: 書いてくれれば、保守チームがそれを理解する助けになる。
 1665: 
 1666: @c The safest changes are changes to the configuration files for a
 1667: @c particular machine.  These are safe because they can't create new bugs
 1668: @c on other machines.
 1669: もっとも安全な変更は、特定のマシンの構成ファイルに対する変更。
 1670: それが安全だという理由は、
 1671: その変更が他のマシンにおいて問題を引き起こすことはありえないから。
 1672: 
 1673: @c Please help us keep up with the workload by designing the patch in a
 1674: @c form that is clearly safe to install.
 1675: 修正を採用しても安全だとはっきりわかる形に設計することで、
 1676: 保守チームの労力を軽減できる。
 1677: @end itemize
 1678: 
 1679: @node Contributing, Service, Bugs, Top
 1680: @c @section Contributing to Emacs Development
 1681: @section Emacsの開発に貢献するには
 1682: 
 1683: @c If you would like to help pretest Emacs releases to assure they work
 1684: @c well, or if you would like to work on improving Emacs, please contact
 1685: @c the maintainers at @code{bug-gnu-emacs@@gnu.org}.  A pretester
 1686: @c should be prepared to investigate bugs as well as report them.  If you'd
 1687: @c like to work on improving Emacs, please ask for suggested projects or
 1688: @c suggest your own ideas.
 1689: Emacsのプレテスト版が正しく動作することの確認を手助けしたかったり、
 1690: Emacsの改良作業に加わりたければ、
 1691: @code{bug-gun-emacs@@gnu.org}の保守チームに連絡してください。
 1692: プレテスト参加者は、バグを報告するだけでなく、バグを探すことも要求されます。
 1693: Emacsの改良に加わりたければ、保守チームにプロジェクトの示唆を求めるか、
 1694: あなたのアイデアを提案してください。
 1695: 
 1696: @c If you have already written an improvement, please tell us about it.  If
 1697: @c you have not yet started work, it is useful to contact
 1698: @c @code{bug-gnu-emacs@@gnu.org} before you start; it might be
 1699: @c possible to suggest ways to make your extension fit in better with the
 1700: @c rest of Emacs.
 1701: すでに改良したコードを書いてしまったのなら、それについて教えてください。
 1702: まだ作業を始めていないのなら、始めるまえに
 1703: @code{bug-gnu-emacs@@gnu.org}に連絡したほうがよいです。
 1704: そうすれば、Emacsの残りの部分とよく適合する形で
 1705: 拡張を行うにはどうしたらよいかのヒントがもらえるでしょう。
 1706: 
 1707: @node Service, Command Arguments, Contributing, Top
 1708: @c @section How To Get Help with GNU Emacs
 1709: @section GNU Emacsに関する助言を得るには
 1710: 
 1711: @c If you need help installing, using or changing GNU Emacs, there are two
 1712: @c ways to find it:
 1713: GNU Emacsをインストールしたり、使ったり、変更したりするうえで手助けが必要なら、
 1714: 2つの方法があります。
 1715: 
 1716: @itemize @bullet
 1717: @item
 1718: @c Send a message to the mailing list
 1719: @c @code{help-gnu-emacs@@gnu.org}, or post your request on
 1720: @c newsgroup @code{gnu.emacs.help}.  (This mailing list and newsgroup
 1721: @c interconnect, so it does not matter which one you use.)
 1722: メイリングリスト@code{help-gnu-emacs@@gnu.org}にメッセージを送るか、
 1723: ニュースグループ@code{gnu.emacs.help}に投稿する。
 1724: (これらのメイリングリストとニュースグループは相互乗り入れしているので、
 1725: どちらを使ってもかまわない。)
 1726: 
 1727: @item
 1728: @c Look in the service directory for someone who might help you for a fee.
 1729: @c The service directory is found in the file named @file{etc/SERVICE} in the
 1730: @c Emacs distribution.
 1731: サービスディレクトリで、有償で手助けしてくれるような人を探す。
 1732: サービスディレクトリは、Emacs配布物の中の
 1733: ファイル@file{etc/SERVICE}にある。
 1734: @end itemize

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>