From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ilya N. Golubev" Newsgroups: gmane.emacs.bugs Subject: bug reports vs manuals [Re: shell completion documentation] Date: Sat, 16 Dec 2006 02:48:26 +0300 Message-ID: <17odq47mb9.fsf_-_@mo.msk.ru> References: <16k64g20tu.fsf@mo.msk.ru> <59ejumjzz2.fsf@mo.msk.ru> <843bazvd1b.fsf@mo.msk.ru> <82odq9aswt.fsf@mo.msk.ru> <87slflasys.fsf@mo.msk.ru> <91mz5ql61p.fsf_-_@mo.msk.ru> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1166263187 4907 80.91.229.10 (16 Dec 2006 09:59:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2006 09:59:47 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 16 10:59:45 2006 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GvWKR-0003wr-Qr for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Dec 2006 10:59:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GvWKR-0001Y6-Bm for geb-bug-gnu-emacs@m.gmane.org; Sat, 16 Dec 2006 04:59:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GvMn3-0003ow-4F for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2006 18:48:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GvMn0-0003oU-MK for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2006 18:48:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GvMn0-0003oR-J3 for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2006 18:48:30 -0500 Original-Received: from [62.213.85.9] (helo=d-fens.mopniei.ru) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GvMmz-0003f1-7Q; Fri, 15 Dec 2006 18:48:30 -0500 Original-Received: from d-fens.mopniei.ru (localhost.localdomain [127.0.0.1]) by d-fens.mopniei.ru (8.13.7/8.13.7) with ESMTP id kBFNmQlJ021270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Dec 2006 02:48:26 +0300 Original-Received: (from gin@localhost) by d-fens.mopniei.ru (8.13.7/8.13.7/Submit) id kBFNmQP3021269; Sat, 16 Dec 2006 02:48:26 +0300 X-Authentication-Warning: d-fens.mopniei.ru: gin set sender to gin@mo.msk.ru using -f Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Fri, 15 Dec 2006 16:24:46 -0500") User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (linux) X-Mailman-Approved-At: Sat, 16 Dec 2006 04:58:48 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:15467 Archived-At: > Bug reports and manuals are not comparable. Only partially. After all, they describe the related things, the incorrect / correct behaviors of some tool. And to state that the behavior is incorrect, one has to have a definition of correct behavior, which is normally supposed to be in documentation. So bug report normally relies on documentation. > details; if they make the > bug report hard to read, we just have to roll up our sleeves and read > it anyway. If something it hard to read, writing it is generally even harder. And if something is hard to read even for maintainers, how can one expect user to write that? > there is no obligation to make the manual so hard to read, Only in sense of no obligations for this program at all, as described by C-h C-w. Still one would normally expect documentation to answer which behavior is correct and which is not. > and it would be counterproductive to do so. What is the alternative? Not to document the correct behavior once and forever, perhaps in some appendix, but instead to have users in every discussion of software, bug reports or other, describe it again and again. Do you call this ? Anyway, for this particular issue, comint commands when `inhibit-field-text-motion', have already described which behavior is desired and why.