From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12314: 24.2.50; `add-to-history': use `setq' with `delete' Date: Sat, 8 Sep 2012 09:25:08 -0700 Message-ID: References: <7602D24B74DE42CF9901322634B85CA2@us.oracle.com> <87sjas4mc2.fsf@gnu.org> <83ipbomv6e.fsf@gnu.org> <2C45207ADF0E46BC98AF1B486695F632@us.oracle.com> <83fw6smti6.fsf@gnu.org> <9A8F619FD7584123A6319BD089E444E4@us.oracle.com> <83bohgmrdv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1347121544 27029 80.91.229.3 (8 Sep 2012 16:25:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Sep 2012 16:25:44 +0000 (UTC) Cc: 12314@debbugs.gnu.org, cyd@gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 08 18:25:46 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TANqr-0004Q2-UU for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Sep 2012 18:25:46 +0200 Original-Received: from localhost ([::1]:50892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TANqo-00004s-90 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Sep 2012 12:25:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TANql-0008WI-AY for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 12:25:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TANqk-0001k6-7g for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 12:25:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TANqk-0001k2-41 for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 12:25:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TANr7-0006wx-SY for bug-gnu-emacs@gnu.org; Sat, 08 Sep 2012 12:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Sep 2012 16:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12314 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12314-submit@debbugs.gnu.org id=B12314.134712154826697 (code B ref 12314); Sat, 08 Sep 2012 16:26:01 +0000 Original-Received: (at 12314) by debbugs.gnu.org; 8 Sep 2012 16:25:48 +0000 Original-Received: from localhost ([127.0.0.1]:48837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANqu-0006wX-9L for submit@debbugs.gnu.org; Sat, 08 Sep 2012 12:25:48 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:40116) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TANqr-0006wQ-Nw for 12314@debbugs.gnu.org; Sat, 08 Sep 2012 12:25:46 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q88GPIsl020659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Sep 2012 16:25:19 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q88GPGMj002283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 16:25:18 GMT Original-Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q88GPGsm014423; Sat, 8 Sep 2012 11:25:16 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Sep 2012 09:25:16 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83bohgmrdv.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac2N28/2PSEZZ0SVQcSP8j8TS5JvAAAACXQw X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63953 Archived-At: > > It is not enough, if you need the variable to reflect the > > updated list contents. > > Then the manual should be corrected to state that much more explicitly > than it does now. Perhaps it shouldn't even talk about destructive > removal, as that will surely spread confusion. For me "destructive" > means "in-place", and no amount of describing how 'delete' works > internally will ever be able to countermand that. Besides, if all I > need is a quick reminder about the semantics, I'm unlikely to read all > the verbiage, let alone go up to read more under 'delq'. So the most > important facts should be right there at the beginning, not hidden > away under "note that" etc. Go for it. I suggest mentioning something like this in node `Modifying Lists' (and then cross-ref'ing that node from other nodes about functions that are destructive of list structure): Typically, you want a variable whose value is a list to reflect the result of any destructive operation on that list. To achieve that, set the variable value to the value returned by that operation. The reason for this is that operations that modify list structure do not also update any variables that might point to such structure. They are concerned only with changing list structure. Then give the `delq' example as an illustration of this. Point out why the variable's value no longer reflects the updated list content. (Perhaps even use a cons-cell diagram to illustrate.) When `delq' deletes elements from the front of the list, it does so simply by advancing down the list and returning a sublist that starts after those elements: (setq sample-list '(a b c (4))) => (a b c (4)) (delq 'a sample-list) => (b c (4)) sample-list => (a b c (4)) Mention explicitly that the same thing is involved with *ALL* list-modification operations. The only things guaranteed by such operations are (a) the modification of the list structure takes place as advertised, and (b) the return value reflects the modified list structure correctly. So if you want a variable to reflect the list correctly as modified then set its value to the return value of the modification function.