From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.bugs Subject: bug#6241: Please make buffer-offer-save permanent local Date: Thu, 27 May 2010 17:56:07 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1275001718 7499 80.91.229.12 (27 May 2010 23:08:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 May 2010 23:08:38 +0000 (UTC) Cc: Juanma Barranquero , 6241@debbugs.gnu.org To: Lennart Borgman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 28 01:08:36 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OHmBn-0005Ul-N5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 May 2010 01:08:36 +0200 Original-Received: from localhost ([127.0.0.1]:50390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHmBn-0007qQ-7V for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 May 2010 19:08:35 -0400 Original-Received: from [140.186.70.92] (port=35111 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHl4y-0007Vb-9B for bug-gnu-emacs@gnu.org; Thu, 27 May 2010 17:57:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHl4v-00076d-TC for bug-gnu-emacs@gnu.org; Thu, 27 May 2010 17:57:27 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56296) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHl4v-00076R-QR for bug-gnu-emacs@gnu.org; Thu, 27 May 2010 17:57:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OHl4X-000832-Jl; Thu, 27 May 2010 17:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: MON KEY Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 May 2010 21:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6241 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6241-submit@debbugs.gnu.org id=B6241.127499737530920 (code B ref 6241); Thu, 27 May 2010 21:57:01 +0000 Original-Received: (at 6241) by debbugs.gnu.org; 27 May 2010 21:56:15 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHl3m-00082f-Gf for submit@debbugs.gnu.org; Thu, 27 May 2010 17:56:14 -0400 Original-Received: from mail-yw0-f172.google.com ([209.85.211.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHl3k-00082a-QO for 6241@debbugs.gnu.org; Thu, 27 May 2010 17:56:13 -0400 Original-Received: by ywh2 with SMTP id 2so159597ywh.0 for <6241@debbugs.gnu.org>; Thu, 27 May 2010 14:56:08 -0700 (PDT) Original-Received: by 10.150.193.18 with SMTP id q18mr748218ybf.129.1274997368117; Thu, 27 May 2010 14:56:08 -0700 (PDT) Original-Received: by 10.151.143.21 with HTTP; Thu, 27 May 2010 14:56:07 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: m7agsI0q7ArKPA8LY0Y0j9xouyY X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 27 May 2010 17:57:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , 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:37347 Archived-At: On Wed, May 26, 2010 at 9:35 PM, Lennart Borgman wrote: > It seems like you are misunderstanding what > > (put 'buffer-offer-save 'permanent-local t) > > means. I well understand what it means. It seems you are being hasty in your zeal to initiate this change. > There is no problem still killing the local variable. You can > do that with > > (kill-local-variable 'buffer-offer-save) > > just as before. Likewise, just as it can be killed. You/your code can just as easily put the varibabe on the buffer. What exactly is the big deal about having to set the variable with an explicit: (put 'buffer-offer-save 'permanent-local t) > The only difference is that it is not killed when you > change major mode in the buffer. This is what I understood your request to pertain to. It is potentially problematcic. ,---- (documentation 'kill-all-local-variables) | { ... } | | As a special exception, local variables whose names have a non-nil | `permanent-local' property are not eliminated by this function. | | The first thing this function does is run the normal hook | `change-major-mode-hook'. `---- Many major mode hooks run `kill-all-local-variables' implicilty. What you may have missed is that a good deal of them also invoke it _explicitly_ when switching. IMHO locals like this _should_ be killed when changing major mode. Judging by the number of explicit calls to `kill-all-local-variables' in lisp/progmodes/* it would seem that many major-mode package authors may think similiarly (one can't know without asking each of them). Lennart, why do you think `buffer-local-variables' such as `buffer-offer-save' should not be killed with `kill-all-local-variables' as they are now. FWIW my impression is that _you_ need this variable to be permanent-local w/re mumamo. However, to the extent to which that package (and corrolary/dependent features) are often extensively kludged/advised I'm certainly not comfortable with extending this variable just to accomodate that morass. Understand I intend no offense here -- its impressive what you've been able to accomplish w/re mumamo etc. given Emacs' limitations in this area :-) Regardless, to the extent that this is your motivation for making the request it is most definitely not the NTRT. If you're unhappy with the means with which you are required to set/unset this variable, write a macro and be done with it, but please don't just request change of a very important (albeit generally overlooked) routine that will affect _every_ major-mode just because it impedes your coding of mumamo et al. FWIW it seems that if you can just holdout awhile longer for full incorporation of lexical-bind a good deal of your challenges w/re mumamo could be addressed by taking advantage of the first-class closures it will allow. > > What burden do you see here? > What burden did you fail to take into account in your haste? Now whenever user code, older third-party packages, major-modes etc. call `kill-all-local-variables' any non-nil settings of buffer-offer-save won't go away. Users will now be required to explicitly remove it. Following is an enumration of the 35 files and the ~50 functions which explicitly call to `kill-all-local-variables' in Emacs 23.2's lisp/progmodes: cc-mode.el.gz -> `c-mode', `c++-mode', `objc-mode', `java-mode', `idl-mode', `pike-mode', `awk-mode', ebrowse.el.gz -> `ebrowse-tree-mode', `ebrowse-electric-list-mode', `ebrowse-member-mode' `ebrowse-electric-position-mode', etags.el.gz -> `next-file' This one is quite interesting. gdb-ui.el.gz -> `gdb-breakpoints-mode', `gdb-frames-mode', `gdb-threads-mode, `gdb-memory-mode', `gdb-registers-mode', `gdb-locals-mode', `gdb-assembler-mode' idlwave.el.gz -> `idlwave-mode', `idlwave-display-user-catalog-widget', idlw-shell.el.gz -> Note this comment in `idlwave-shell-mode' source: ,---- | We don't do `kill-all-local-variables' here, because this is | done by comint. `---- ada-mode.el.gz -> `ada-mode' antlr-mode.el.gz -> `antlr-mode' asm-mode.el.gz -> `asm-mode' autoconf.el.gz -> `autoconf-mode' compile.el.gz -> `compilation-mode' cperl-mode.el.gz -> `cperl-mode' cpp.el.gz -> `cpp-edit-mode' dcl-mode.el.gz -> `dcl-mode' delphi.el.gz -> `delphi-mode' f90.el.gz -> `f90-mode' fortran.el.gz -> `fortran-mode' icon.el.gz -> icon-mode idlw-help.el.gz -> `idlwave-help-mode' m4-mode.el.gz -> `m4-mode' make-mode.el.gz -> `makefile-mode' meta-mode.el.gz -> `meta-common-initialization' modula2.el.gz -> `modula-2-mode' octave-mod.el.gz -> `octave-mode' pascal.el.gz -> `pascal-mode' perl-mode.el.gz -> `perl-mode' prolog.el.gz -> `prolog-mode' ruby-mode.el.gz -> `ruby-mode' scheme.el.gz -> `scheme-mode' sh-script.el.gz -> `sh-mode' sql.el.gz -> `sql-mode' vera-mode.el.gz -> `vera-mode' verilog-mode.el.gz -> `verilog-mode' vhdl-mode.el.gz -> `vhdl-mode' xscheme.el.gz -> `scheme-interaction-mode' I also suspect that there are (or will be) modes which take advantage of asynchrous processing in conjunction with a major-mode which will now have to worry about unsetting this variable regardless of whether the results of the asynchrounous process succeed or not... Explicit calls to kill-all-local-variables In Emacs 23.2's /lisp/net: dig.elc eudc.el.gz eudc-hotlist.el.gz mairix.el.gz newst-plainview.elc newst-treeview.el.gz quickurl.el.gz rcirc.el.gz snmp-mode.el.gz xesam.el.gz Likewise, I imagine there are some immediate corner cases where tramp'd buffers wouldn't appreciate buffer-offer-save being permanent local. I'm tiring of this enumeration... I'm sure there are many more usage instances of `kill-all-local-variables' in lisp/* which _may_ expect that buffer-offer-save is _not_ affected in the manner which you propose. This doesn't even begin to take into account third party code... Should you insist that this change be made please ask on emacs-devel before asserting that: "I think everyone expects that." I don't. -- /s_P\