From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: RE: 23.0.50; savehist save invalid syntax Date: Mon, 10 Sep 2007 16:42:46 -0700 Message-ID: References: <38272.128.165.123.18.1189461547.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1189471574 17858 80.91.229.12 (11 Sep 2007 00:46:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 Sep 2007 00:46:14 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 11 10:46:01 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 1IV0PR-0003MH-Jb for ged-emacs-devel@m.gmane.org; Tue, 11 Sep 2007 09:43:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUsv4-0007OP-Rs for ged-emacs-devel@m.gmane.org; Mon, 10 Sep 2007 19:43:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUsuW-0007C2-SF for emacs-devel@gnu.org; Mon, 10 Sep 2007 19:43:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUsuT-0007BU-E1 for emacs-devel@gnu.org; Mon, 10 Sep 2007 19:43:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUsuT-0007BR-84 for emacs-devel@gnu.org; Mon, 10 Sep 2007 19:43:17 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUsuS-0004tE-U2 for emacs-devel@gnu.org; Mon, 10 Sep 2007 19:43:17 -0400 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUsu5-0000T5-F4 for emacs-pretest-bug@gnu.org; Mon, 10 Sep 2007 19:42:53 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1IUsuO-0004sO-To for emacs-pretest-bug@gnu.org; Mon, 10 Sep 2007 19:43:16 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IUsuO-0004s5-He for emacs-pretest-bug@gnu.org; Mon, 10 Sep 2007 19:43:12 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l8ANhAfx019135 for ; Mon, 10 Sep 2007 18:43:10 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l89H9Pht029963 for ; Mon, 10 Sep 2007 17:43:09 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-203.us.oracle.com by acsmt351.oracle.com with ESMTP id 3200656811189467766; Mon, 10 Sep 2007 16:42:46 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <38272.128.165.123.18.1189461547.squirrel@webmail.lanl.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 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:78530 gmane.emacs.pretest.bugs:19835 Archived-At: > You're right, of course; I fixed some parentheses, but obviously didn't > find all of the problems. But there was a reason for the newline: all > elements but the first will start at the beginning of a line, so I thought > it best that the first do so as well. I've adjusted my own copy > appropriately, for when I find the time to write up the patch > documentation. The newlines are not necessary, unless you're thinking of someone viewing .emacs-history. That is, any whitespace will do. I used a space, but a newline is OK too. > > 5. I don't see how the condition-case in `savehist-prin1-readable' can > > work. > > How would an `invalid-read-syntax' error ever be raised here? Isn't it > > only > > the Lisp reader that raises that error? I think the error type should be > > just `error'. > > The applicability of the error symbol may be questionable, but there is no > bug: with my patch to print.c (and `print-unreadable-function' bound to > t), the Lisp printer raises that error if the Lisp reader -would- raise it. I see. I didn't look at your C-source change, and I didn't build Emacs just to test the Lisp change. Sorry for not understanding the C change. In that case, you might want to comment the Lisp code to that effect. It's not very obvious that a Lisp reader error could be raised by `prin1'. And I think it's probably still better to leave the general `error' handler. I have a (very slightly) modified version of savehist.el (savehist-20+.el) that works also with older Emacs versions (20, 21, 22). I will keep the Lisp-level `read' in that version. If, as you say, it is superfluous now for new Emacs builds, so much the better. In that case, I'll test something in savehist-20+.el and skip the `read' for the Emacs versions that have your C change. What Lisp value can I test for that? It's obviously not `emacs-major-version' >= 22. Is there a featurep or fboundp or boundp I can test? If not, is there a minor version I can test? If I can't find something to test, then I'll have to leave the `read' in for new Emacs versions also, which is obviously a waste. > > 6. In keeping with the doc string, I replaced octal 600 with decimal 384 > > as the default value of `savehist-file-modes'. > > The doc string has to explain the variable's appearance to the user; in > the code it's probably best to use the octal constant since that shows > what's meant. I question why the docstring should mention its own default > value, except perhaps to say that 384==0600 in case that happens to be its > value. Do as you think best. The doc string suggests that a decimal value is used, so I used one. Also, I think decimal is what will be used by most users in Customize. That is, even if one can enter #o600 in the Customize editable field, I doubt that most users will think to do that. To me, the doc string helps in this regard, and a decimal default value helps. I don't see a real benefit in using octal here, but that's just my opinion. [FWIW, I also use decimal as the value in my own version of the library because that is required for older Emacs versions.] > > 7. I wrapped a condition-case around the body of `savehist-autosave'. I > > added this long ago to my version, but I cannot recall exactly > why it was > > needed. > > I can't see why that function should be particularly likely to throw, > unless `savehist-minibuffer-history-variables' contained unprintable > objects (and it should contain only symbols). If it does, it is > presumably a bug to fix, yes? OK. As I say, I don't recall the specific need. I do recall that it was preventing one from quitting Emacs, because `savehist-autosave' is in `kill-emacs-hook' (as well as on a timer). That is, if, for any reason, it has a problem, then it gets in the way of exiting. That was what was happening, but perhaps that problem will never arise in the future ;-).