From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: a few minor issues with manuals ... Date: Sat, 03 Mar 2007 23:16:19 +0100 Message-ID: <45E9F3B3.1000904@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1172960492 32281 80.91.229.12 (3 Mar 2007 22:21:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 3 Mar 2007 22:21:32 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 03 23:21:25 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HNcbU-00073u-EV for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 23:21:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNcbT-0004S6-Sc for ged-emacs-devel@m.gmane.org; Sat, 03 Mar 2007 17:21:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HNcbJ-0004Ry-9H for emacs-devel@gnu.org; Sat, 03 Mar 2007 17:21:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HNcbE-0004Rg-Mz for emacs-devel@gnu.org; Sat, 03 Mar 2007 17:21:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HNcbE-0004Rc-Hr for emacs-devel@gnu.org; Sat, 03 Mar 2007 17:21:08 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.52) id 1HNcbE-0001Bg-3G for emacs-devel@gnu.org; Sat, 03 Mar 2007 17:21:08 -0500 Original-Received: (qmail invoked by alias); 03 Mar 2007 22:21:05 -0000 X-Provags-ID: V01U2FsdGVkX19EZ7F9pLtE7zA2JVZllJ6RPlPFHmRRKEVpeIu4IW uzbZdOzimBOitl User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en X-Y-GMX-Trusted: 0 X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:67273 Archived-At: (1) Elisp manual section 6.1 "Sequences" has in its first paragraph the following sentence: This section describes functions that accept any kind of sequence. In the same section you find the following description: -- Function: string-bytes string This function returns the number of bytes in STRING. If STRING is a multibyte string, this is greater than `(length STRING)'. I consider this contradictory and either the sentence above should be changed appropriately or `string-bytes' moved to section 4 (where I'd expect to find it in the first place). (2) Elisp manual section 16.5 "Evaluation During Compilation" contains the following sentence: They can be defined while compiling, but then not needed when executing. Either the formulation is wrong or I fail to understand this. (3) Elisp manual section 35.6.5 "Parameters to Control Parsing" has -- User Option: parse-sexp-ignore-comments If the value is non-`nil', then comments are treated as whitespace by the functions in this section and by `forward-sexp'. which is slightly misleading. I'd rewrite the last line as by `scan-lists', `scan-sexps', and `forward-sexp'. (4) Elisp manual section 38.9.3 "Searching for Overlays" contains the following example: (defun find-overlay-prop (prop) (save-excursion (while (and (not (eobp)) (not (get-char-property (point) prop))) (goto-char (min (next-overlay-change (point)) (next-single-property-change (point) prop)))) (point))) This example is misleading since to search for the next change of a text or overlay property `next-single-char-property-change' is far superior. `find-overlay-prop' may render execution time proportional to two times the size of the buffer. (5) Emacs manual section 58.3.4.2 "Safety of File Variables" contains the sentence: The default is `maybe', which is neither `t' nor `nil', so normally Emacs does ask for confirmation about processes `eval' variables. Presumably "processes" should be "processing" here.