GNU bug report logs -
#27348
24.5; [PATCH] let defvars benefit from defcustom keywords and persistence
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Mon, 12 Jun 2017 21:35:02 UTC
Severity: wishlist
Tags: patch, wontfix
Found in version 24.5
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27348 in the body.
You can then email your comments to 27348 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27348
; Package
emacs
.
(Mon, 12 Jun 2017 21:35:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 12 Jun 2017 21:35:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This is an enhancement request, with a patch.
[NOTE: I suggested this enhancement to emacs-devel in 2009. There was
exactly one reply, with only this text: "YAGNI".
http://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html
http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg01481.html]
The ability to type-check, provide :set and :initialize trigger
functions, automatically :require libraries, add links to doc, associate
with one or more :groups, etc. - these are useful things to be able to
do with at least some defvars, not just with defcustoms. Similarly, the
ability to persist non-option variables in a user's custom file can be
useful.
In sum, this enhancement makes it possible to uncouple interactive
customization from the other features that `custom.el' offers, in
particular, type-checking and persistence, and to provide the latter for
non-option variables.
Patch description:
1. New `defcustom' keyword `:not-custom-var'. If non-nil, the variable
does not satisfy `custom-variable-p'. This means that users cannot
customize it interactively, and it is not available for other
interactive use (completion, `set-variable', inclusion in
`apropos-user-option' output, etc.).
Anyone and any code can still use `custom*' and other functions that
do not check `custom-variable-p', to treat such a variable as a
defcustom. Similarly, users can still use `M-:', `C-x C-e' etc. to
customize it. See also #5, below.
2. New `defcustom' keyword `:not-custom-var'. It causes property
`not-custom-var' to be put on the variable symbol. This property is
what governs the behavior of `custom-variable-p'.
3. New macro `defvarc'. It just invokes `defcustom', passing non-nil
`:not-custom-var'. The idea is to have a macro with a name similar
to `defvar'. Using it can make the non-customizable nature more
apparent than using `defcustom' with explicit `:not-custom-var'.
[Another possibility would be to directly modify `defvar', so that it
optionally accepts `defcustom' keywords etc., but maybe that would
not be acceptable immediately. (For one thing, the cases of no
initial value and no doc, `(defvar foo)' and `(defvar foo 4)', would
still need to be supported.)]
4. `custom-variable-p' respects not only whether the variable has a
non-nil `not-custom-var' property but also whether (new) global
variable `custom-vars-all-customizable' is non-nil. If either is
true then the variable is not customizable (the predicate returns
nil).
5. New macro `with-user-vars'. It temporarily allows a set of variables
to be customizable. It takes as its first argument either a list of
variables or the symbol `all', meaning all variables. For `all', it
just binds `custom-vars-all-customizable' to `t'. For a list of
variables, it sets property `not-custom-var' to `t' for each one.
(The original property values are restored when done.)
I'm open as to how such a feature gets implemented. That includes names
of things (`defvarc', for example) and whether or not to include this or
that part. And I'm open to changes to the particular code in the patch.
There might be better ways to realize such a feature - what I came up
with is a pretty simple, naive approach.
FWIW: I haven't understood why apparently no one else has thought this
kind of thing could improve Emacs. I've long thought that the power of
defcustom keywords and persistence should be freed from their coupling
with interactive customizing. That combination is great, of course, but
it should not be obligatory - I see no reason why a non-user variable
should not take advantage of defcustom features.
In GNU Emacs 24.5.1 (i686-pc-mingw32)
of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/usr --host=i686-pc-mingw32'
[custom-2017-06-12.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27348
; Package
emacs
.
(Mon, 24 Jun 2019 16:36:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 27348 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> The ability to type-check, provide :set and :initialize trigger
> functions, automatically :require libraries, add links to doc, associate
> with one or more :groups, etc. - these are useful things to be able to
> do with at least some defvars, not just with defcustoms. Similarly, the
> ability to persist non-option variables in a user's custom file can be
> useful.
I think this is an interesting idea, but perhaps a bug report isn't the
right venue for it? Did you take this up on emacs-devel?
(And here's my two pennies on the subject after considering it for about
60 seconds: I'm not sure this sort of extension of the type system is
that useful... If we want a more expressive type system in Emacs, this
is the wrong place to start.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27348
; Package
emacs
.
(Mon, 24 Jun 2019 18:05:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 27348 <at> debbugs.gnu.org (full text, mbox):
> > The ability to type-check, provide :set and :initialize trigger
> > functions, automatically :require libraries, add links to doc, associate
> > with one or more :groups, etc. - these are useful things to be able to
> > do with at least some defvars, not just with defcustoms. Similarly, the
> > ability to persist non-option variables in a user's custom file can be
> > useful.
>
> I think this is an interesting idea, but perhaps a bug report isn't the
> right venue for it? Did you take this up on emacs-devel?
>
> (And here's my two pennies on the subject after considering it for about
> 60 seconds: I'm not sure this sort of extension of the type system is
> that useful... If we want a more expressive type system in Emacs, this
> is the wrong place to start.)
It's an enhancement request. This is the place for that.
And yes, I brought it up on emacs-devel some time ago.
(Probably was told to file an enhancement request. ;-))
This is not an "extension of the [Lisp] type system".
It simply gives Lisp programmers the ability to use
some `defcustom' features for variables that users
do not change using Customize.
It separates such features, which are useful for
programmers, from the use of Customize.
Added tag(s) patch.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Mon, 04 May 2020 11:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#27348
; Package
emacs
.
(Mon, 10 Aug 2020 15:05:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 27348 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> This is an enhancement request, with a patch.
>
> [NOTE: I suggested this enhancement to emacs-devel in 2009. There was
> exactly one reply, with only this text: "YAGNI".
> http://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html
> http://lists.gnu.org/archive/html/emacs-devel/2015-10/msg01481.html]
>
> The ability to type-check, provide :set and :initialize trigger
> functions, automatically :require libraries, add links to doc, associate
> with one or more :groups, etc. - these are useful things to be able to
> do with at least some defvars, not just with defcustoms. Similarly, the
> ability to persist non-option variables in a user's custom file can be
> useful.
So this has been brought up several times, and nobody seems to be
enthusiastic about the idea. (I'm not either -- if we're extending
Emacs Lisp to support static typing, I think this would be starting in
at the wrong end.)
So I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 10 Aug 2020 15:05:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
27348 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 10 Aug 2020 15:05:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 08 Sep 2020 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 230 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.