From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Change `customize-save-variable' to work under "emacs -Q"? Date: Thu, 14 Jul 2011 09:46:19 +1000 Message-ID: References: <877h7ok9cd.fsf@stupidchicken.com> <87d3hgprjb.fsf@stupidchicken.com> <87r55wtget.fsf@uwakimon.sk.tsukuba.ac.jp> <87ipr8t9w9.fsf@uwakimon.sk.tsukuba.ac.jp> <87ei1vt40t.fsf@uwakimon.sk.tsukuba.ac.jp> <874o2qtpdi.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1310600807 25604 80.91.229.12 (13 Jul 2011 23:46:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 23:46:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 14 01:46:43 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qh98d-0003Ya-DY for ged-emacs-devel@m.gmane.org; Thu, 14 Jul 2011 01:46:43 +0200 Original-Received: from localhost ([::1]:48781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qh98c-0008Rm-Ev for ged-emacs-devel@m.gmane.org; Wed, 13 Jul 2011 19:46:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qh98L-0008Rf-B6 for emacs-devel@gnu.org; Wed, 13 Jul 2011 19:46:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qh98H-0007Wa-4o for emacs-devel@gnu.org; Wed, 13 Jul 2011 19:46:25 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:51053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qh98H-0007WH-0E for emacs-devel@gnu.org; Wed, 13 Jul 2011 19:46:21 -0400 Original-Received: by iyl8 with SMTP id 8so7010014iyl.0 for ; Wed, 13 Jul 2011 16:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ImR61MR2z/giRQ2eUtGGeLgO4IG/PAUATyImkAT+6Eg=; b=fgkZFzjIyNWfEryX2ons9xt0QSLWr2qg94n7xO2VKAVmW4+ZW4pLYrqTHBVpOrpZGl Jsmx9YZL3jjUfM085COioasNn6jx9pf2VbkM9wnUlvMnUwQ5x2zhTzPhfbed22JPLpU5 jtx8u9IkafGz8FxuNw+qyCTJMy8WUFfMmeOFE= Original-Received: by 10.231.121.140 with SMTP id h12mr1483371ibr.101.1310600780046; Wed, 13 Jul 2011 16:46:20 -0700 (PDT) Original-Received: by 10.231.15.3 with HTTP; Wed, 13 Jul 2011 16:46:19 -0700 (PDT) In-Reply-To: <874o2qtpdi.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142017 Archived-At: On Wed, Jul 13, 2011 at 9:02 PM, Stephen J. Turnbull w= rote: > =A0> whether we are better off leaving -Q to mean EVERYTHING at its > =A0> default state and doing something else, like having the custom > =A0> functions do something other than raise an error when code tries to > =A0> save custom values under -Q > > Of course that's what it means. =A0So the problem is what do you do when > what you need to do *requires* changing state? =A0I think it's plausible > that almost anything to do with mail will *require* changes to the -Q > state before you get useful behavior. > Agree, but perhaps disagree on how those changes occur. I would prefer that the individual has to explicitly (even manually) make those changes rather than have emacs attempt to anticipate what the user may need when running under a -Q environment. Of course, the downside with this approach is that those who are less comfortable/familiar with emacs will find this difficult. > Note that saving custom values does not change the -Q environment. > It's just that you're unlikely to bother saving in the virgin -Q > environment (you can always reproduce that with -Q!), so an attempt to > save pretty much implies you've already changed state in a significant > way. > I guess your saying that saving and setting are different operations and saving without setting would not affect the current environment? What I'm not clear about is where you would save the values to. The default location I gues swould be the users .emacs file. However, quite a few users also customize this and have the custom variable stuff in a different file because they don't want it mixed up with other stuff in .emacs. Now we have a problem. The -Q switch does not read the .emacs file and therefore we cannot tell which aproach this user prefers and therefore, don't know where we should save these values to. This is why I don't understand what 'save' means in this context or how it would work. Worse yet would be a situation where the user becomes confused when they believe they have saved settings while under -Q, but then next time they run emacs (with or without -Q) their changes have not been saved. To some extent, I would guess this is primarily why you would argue for an error rather than a warning - making it very clear to the user their save action has failed? > =A0> (maybe a warning they are not saved rather than an error) or > =A0> perhaps it al> Tim Cross writes: > > > I *think* I agree, though am not clear what 'saving' means compared to > > 'setting' within the context of the -Q switch > > I think it should mean an error, while the maintainers seem to be (and > Lars clearly is) happy with a warning. Nobody *wants* silence. > I'm divided on error v's warning. On one hand, an error is good as it grabs user attention and makes it clear the values have not been saved - avoiding later confusion. The downside is that it can make the code more complex for developers when -Q is invoked. On the other hand, it could be argued that as this is a known and understood situation, a warning is sufficient. The advantage is that some code would become less complex. The downside is that users may easily overlook the error and then get confused when their settings don't seem to be persisting over sessions etc. I personally think an error is better. However, I also don't fully understand how often package maintainers run into problems initializing their packages when they are run under -Q. If this problem is relatively rare and really only comes up when you would like a package to have some level of functionality under -Q and that can only be achieved by setting values, then an error would certainly seem to be the right choice. However, if this is a frequent issue and an error is resulting in frequently more complex initialization code, then there could be a case to downgrade it to a warning. On the other hand, I would be tempted to look at refactoring how defaults and custom work as this would indicate a deeper design issue IMO. > > OK, but that does not affect my point regarding the importance of -Q > > representing a standard, well defined and consistent configuration. > > Right. I think there is consensus on that. My point is simply that > in many cases, -Q will not be a useful environment. Lars proposes to > make it somewhat more useful, at the cost of complexifying the > behavior of custom-save-variable, and making pollution of the -Q > environment a bit less painful. Yes - I worry about it becoming easier to pollute the -Q environment and whether this will reuslt in -Q becoming less useful over time. I think it is reasonable to expect the -Q environment to be less 'useful' than the standard environment. It is a special purpose environment and losing some functionality in such an environment is acceptable - especially if the lost functionality is functionality that depends on local configuration. > > My position is that the code needs refactoring, because I don't like > the idea of facilitating exceptions here, and I think that changing > `custom-save-variable' will make doing customizations in the -Q > environment more attractive. =A0But that doesn't seem to be the position > of the maintainers. > It would seem we are of similar opinions. I too am concerned that making it easier for code to change custom variables under -Q environments will result in -Q losing its important quality of representing a standard default environment. The suggested changes to custom functions certainly feels wrong in the sense that it seems to be muddying their definition and making matters more complex than desirable. I also suspect that the desire to make -Q more functional may be misplaced. I guess we will have to wait and see what evolves. Tim