Subject: bug#6241: Please make buffer-offer-save permanent local

From: MON KEY <[email-masked]>
Date: Thu, 27 May 2010 17:56:07 -0400

On Wed, May 26, 2010 at 9:35 PM, Lennart Borgman
<[email-masked]> 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\