bug#14591: New keyword :local for defcustom

bug#14591: New keyword :local for defcustom

[Juanma Barranquero]

Package: emacs
Version: 24.3.50
Severity: wishlist
Tags: patch



This patch adds a new keyword :local to defcustom, to simplify cases like

(defcustom some-var some-val
   "A very long description
filling many lines
...
...
..."
  ;; some keywords)
(make-variable-buffer-local 'some-var)

i.e., it tries to solve the same problem (non-locality) for
customization variables that the new macro defvar-local solves for
defvars.

As designed, it accepts values 'local (which means make the symbol
automatically buffer-local), 'permanent (which makes the symbol
permanent-local), and t which does both.

OK to the idea, the interface, comments...?

    Juanma




2013-06-11  Juanma Barranquero  <lekktu@gmail.com>

* custom.el (custom-declare-variable): Accept new keyword :local.
(defcustom): Document it.

=== modified file 'etc/NEWS'
--- etc/NEWS 2013-06-07 03:23:57 +0000
+++ etc/NEWS 2013-06-11 17:04:53 +0000
@@ -544,6 +544,9 @@
 and functions should be separated by two hyphens if the symbol is not
 meant to be used by other packages.

+** defcustom now has a new keyword :local to mark the variable as
+automatically buffer-local and/or permanent-local.
+

 * Changes in Emacs 24.4 on Non-Free Operating Systems


=== modified file 'lisp/custom.el'
--- lisp/custom.el 2013-01-02 16:13:04 +0000
+++ lisp/custom.el 2013-06-11 16:44:11 +0000
@@ -173,6 +173,11 @@
  (put symbol 'risky-local-variable value))
  ((eq keyword :safe)
  (put symbol 'safe-local-variable value))
+                ((eq keyword :local)
+                 (when (memq value '(t local))
+                   (make-variable-buffer-local symbol))
+                 (when (memq value '(t permanent))
+                   (put symbol 'permanent-local t)))
  ((eq keyword :type)
  (put symbol 'custom-type (purecopy value)))
  ((eq keyword :options)
@@ -246,6 +251,9 @@
 :risky Set SYMBOL's `risky-local-variable' property to VALUE.
 :safe Set SYMBOL's `safe-local-variable' property to VALUE.
         See Info node `(elisp) File Local Variables'.
+:local  VALUE should be t, `local' or `permanent'.
+        If t or `local', mark SYMBOL as automatically buffer-local.
+        If t or `permanent', set SYMBOL's `permanent-local' property to t.

 The following common keywords are also meaningful.

bug#14591: New keyword :local for defcustom

[Ted Zlatanov]

On Tue, 11 Jun 2013 19:18:54 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> This patch adds a new keyword :local to defcustom, to simplify cases like

JB> (defcustom some-var some-val
JB>    "A very long description
JB> filling many lines
JB> ...
JB> ...
JB> ..."
JB>   ;; some keywords)
JB> (make-variable-buffer-local 'some-var)

JB> i.e., it tries to solve the same problem (non-locality) for
JB> customization variables that the new macro defvar-local solves for
JB> defvars.

JB> As designed, it accepts values 'local (which means make the symbol
JB> automatically buffer-local), 'permanent (which makes the symbol
JB> permanent-local), and t which does both.

JB> OK to the idea, the interface, comments...?

I like it.  Also we have `defvoo' in Gnus which is along the same lines
but more aimed at the server data structure than defcustoms.

The interface makes perfect sense to me.

Ted

bug#14591: New keyword :local for defcustom

[Glenn Morris]

FWIW, seems fine to me, although defcustom + buffer-local tends not to
be terribly useful, so I don't know if it is good to advertise it more
by adding an easier way to get it?

Juanma Barranquero wrote:

> As designed, it accepts values 'local (which means make the symbol
> automatically buffer-local), 'permanent (which makes the symbol
> permanent-local), and t which does both.

t for buffer-local (most common case, I imagine) and 'permanent for
buffer-local+permanent-local seems more intuitive to me. (Do you ever
want to make something permanent-local but not buffer-local?)

bug#14591: New keyword :local for defcustom

[Stefan Monnier]

> This patch adds a new keyword :local to defcustom, to simplify cases like

> (defcustom some-var some-val
>    "A very long description
> filling many lines
> ...
> ...
> ..."
>   ;; some keywords)
> (make-variable-buffer-local 'some-var)

Problem is: most/all of those are in themselves problematic, because
Customize handles buffer-local variables very poorly.


        Stefan

bug#14591: New keyword :local for defcustom

[Juanma Barranquero]

On Wed, Jun 12, 2013 at 7:27 PM, Glenn Morris <rgm@gnu.org> wrote:

> t for buffer-local (most common case, I imagine) and 'permanent for
> buffer-local+permanent-local seems more intuitive to me. (Do you ever
> want to make something permanent-local but not buffer-local?)

My first idea was identical to what you propose, but there are a few
variables in the source (though not defcustoms) that are
permanent-local but not automatically buffer-local.

That said, either interface is fine to me.

   J

bug#14591: New keyword :local for defcustom

[Juanma Barranquero]

On Wed, Jun 12, 2013 at 8:56 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> Problem is: most/all of those are in themselves problematic, because
> Customize handles buffer-local variables very poorly.

Well, yes, but a defcustom is just a fancy variable declaration plus
an even fancier interface to setting it. Whether it makes sense for
the variable to be automatically buffer-local or not is independent of
it being a defcustom, as witnessed by the fact that there are already
automatically buffer-local defcustom'ized variables in the sources.

In other words: that customize handles poorly these kind of variables
is a bug in Customize (and so, something to fix some day), not an
intrinsic feature of these variables.

    J

bug#14591: New keyword :local for defcustom

[Stefan Monnier]

> My first idea was identical to what you propose, but there are a few
> variables in the source (though not defcustoms) that are
> permanent-local but not automatically buffer-local.

But: is it important for those to be "not automatically buffer-local",
or would it be OK for them to be automatically buffer-local.


        Stefan

bug#14591: New keyword :local for defcustom

[Juanma Barranquero]

> But: is it important for those to be "not automatically buffer-local",
> or would it be OK for them to be automatically buffer-local.

Well, that's a good question.

The first example I can think of is one variable I'm really puzzled is
not automatically buffer-local, because it is *always* used as so (I
checked), revert-buffer-function. The only case in the sources where
it is not assigned with (set (make-local-variable
'revert-buffer-function) ...) is in dired-x.el, and that because at
that point is already guaranteed that dired-mode.el made it a-b-l.

So, it's important for revert-buffer-function to be "not automatically
buffer-local"? Does it even make sense that it is not? :-)

   J

bug#14591: New keyword :local for defcustom

[Stefan Monnier]

> So, it's important for revert-buffer-function to be "not automatically
> buffer-local"?

No.


        Stefan

bug#14591: New keyword :local for defcustom

[Juanma Barranquero]

On Wed, Jun 12, 2013 at 7:27 PM, Glenn Morris <rgm@gnu.org> wrote:

> (Do you ever
> want to make something permanent-local but not buffer-local?)

69 variables are so marked on lisp/**

Of these, 8 are really minor modes (so they are always used as buffer-local).

2 are defcustoms:

  2C-separator
  backup-by-copying-when-mismatch

The rest:

  archive-superior-buffer
  backup-inhibited
  buffer-auto-save-file-format
  buffer-file-format
  comint-input-autoexpand
  comint-input-filter-functions
  comint-input-ring
  comint-input-ring-index
  comint-move-point-for-output
  comint-output-filter-functions
  comint-preoutput-filter-functions
  comint-ptyp
  comint-save-input-ring-index
  comint-scroll-show-maximum-output
  comint-scroll-to-bottom-on-input
  custom-local-buffer
  cvs-buffer
  cvs-edit-log-files
  enable-character-translation
  epa-file-encrypt-to
  find-file-literally
  gud-find-file
  gud-marker-filter
  input-method-function
  plstore-encoded
  plstore-encrypt-to
  rcirc-urls
  revert-buffer-function
  revert-buffer-insert-file-contents-function
  rmail-buffer
  rmail-current-message
  rmail-deleted-vector
  rmail-inbox-list
  rmail-last-regexp
  rmail-message-vector
  rmail-mime-decoded
  rmail-msgref-vector
  rmail-old-headers
  rmail-old-pruned
  rmail-overlay-list
  rmail-seriously-modified
  rmail-summary-buffer
  rmail-summary-overlay
  rmail-summary-vector
  rmail-total-messages
  rmail-was-converted
  tar-superior-buffer
  tar-superior-descriptor
  term-input-autoexpand
  term-input-filter-functions
  term-input-ring
  term-input-ring-index
  term-ptyp
  term-scroll-show-maximum-output
  term-scroll-to-bottom-on-output
  vc-log-view-type
  vc-parent-buffer
  vc-parent-buffer-name
  write-file-functions

Of course, some (perhaps most) of these are made buffer-local when
used. But there are a few which are not, in a not-making-sense way.
One of them that I already mentioned is revert-buffer-function, but
backup-inhibited is even more ridiculous, because its docstring says:

  This variable is intended for use by making it local to a buffer.
  But it is local only if you make it local.

So we have a variable which is permanent local, *intended* to be used
as buffer-local, yet very explicitly and (apparently) purposefully not
made automatically buffer-local.

Color me puzzled,

   Juanma

bug#14591: New keyword :local for defcustom

[Juanma Barranquero]

> No.

Well, there are only two defcustom permanent-locals which are not
automatically buffer-local, and I wouldn't be surprised to discover
that they should, in fact, be. In any case, it's a corner case not
worth catering to.


=== modified file 'lisp/custom.el'
--- lisp/custom.el 2013-01-02 16:13:04 +0000
+++ lisp/custom.el 2013-06-14 12:10:30 +0000
@@ -173,6 +173,11 @@
  (put symbol 'risky-local-variable value))
  ((eq keyword :safe)
  (put symbol 'safe-local-variable value))
+                ((eq keyword :local)
+                 (when (memq value '(t permanent))
+                   (make-variable-buffer-local symbol))
+                 (when (eq value 'permanent)
+                   (put symbol 'permanent-local t)))
  ((eq keyword :type)
  (put symbol 'custom-type (purecopy value)))
  ((eq keyword :options)
@@ -246,6 +251,9 @@
 :risky Set SYMBOL's `risky-local-variable' property to VALUE.
 :safe Set SYMBOL's `safe-local-variable' property to VALUE.
         See Info node `(elisp) File Local Variables'.
+:local  If VALUE is t, mark SYMBOL as automatically buffer-local.
+        If VALUE is `permanent', also set SYMBOL's `permanent-local'
+        property to t.

 The following common keywords are also meaningful.

bug#14591: New keyword :local for defcustom

[Lars Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> Well, there are only two defcustom permanent-locals which are not
> automatically buffer-local, and I wouldn't be surprised to discover
> that they should, in fact, be. In any case, it's a corner case not
> worth catering to.

I've now applied your patch to the trunk -- it seemed like most people
was in favour of it, but it may be controversial.  Please revert if it's
decided not to go ahead with :local.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14591: New keyword :local for defcustom

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

It was so long ago that I didn't even remember proposing it. Not sure
whether I would do it today (likely not).

Anyway, it's installed. If someone complains, out it goes.

Thanks.

[-- Attachment #2: Type: text/html, Size: 222 bytes --]