GNU bug report logs - #14591
New keyword :local for defcustom

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14591 in the body.
You can then email your comments to 14591 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: New keyword :local for defcustom
Date: Tue, 11 Jun 2013 19:18:54 +0200

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 <at> 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.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Tue, 11 Jun 2013 17:01:04 -0400

On Tue, 11 Jun 2013 19:18:54 +0200 Juanma Barranquero <lekktu <at> 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

Message #11 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Wed, 12 Jun 2013 13:27:32 -0400

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?)

Message #14 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Wed, 12 Jun 2013 14:56:28 -0400

> 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

Message #17 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Thu, 13 Jun 2013 03:57:14 +0200

On Wed, Jun 12, 2013 at 7:27 PM, Glenn Morris <rgm <at> 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

Message #20 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Thu, 13 Jun 2013 04:01:26 +0200

On Wed, Jun 12, 2013 at 8:56 PM, Stefan Monnier
<monnier <at> 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

Message #23 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Thu, 13 Jun 2013 10:16:29 -0400

> 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

Message #26 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Glenn Morris <rgm <at> gnu.org>, 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Thu, 13 Jun 2013 16:25:04 +0200

> 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

Message #29 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Thu, 13 Jun 2013 15:53:01 -0400

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

No.


        Stefan

Message #32 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Fri, 14 Jun 2013 15:03:16 +0200

On Wed, Jun 12, 2013 at 7:27 PM, Glenn Morris <rgm <at> 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

Message #35 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Fri, 14 Jun 2013 15:06:06 +0200

> 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.

Message #38 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Thu, 27 Jun 2019 13:28:02 +0200

Juanma Barranquero <lekktu <at> 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

Message #45 received at 14591 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 14591 <at> debbugs.gnu.org
Subject: Re: bug#14591: New keyword :local for defcustom
Date: Fri, 28 Jun 2019 13:04:17 +0200

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.