From: Carsten Dominik <carsten.dominik@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [RFC] Change some defcustoms into defcont
Date: Mon, 21 Oct 2013 13:56:10 +0200 [thread overview]
Message-ID: <7839A647-8D17-47A9-A65D-5FD7110ED082@gmail.com> (raw)
In-Reply-To: <87a9i2522c.fsf@gmail.com>
Hi Nicolas,
On 21.10.2013, at 12:51, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On 21.10.2013, at 10:56, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>
>>> That's exactly the point of the defconst: you can still modify the
>>> variable, but it sends a strong message to the user. Also, it's not
>>> about deprecation: code base should still rely on these variables.
>>
>> This is where I disagree. I think the Emacs implementation of defconst
>> is broken, and retained in this way only for backward compatibility.
>
> I won't judge Elisp implementation. AFAIC, defining a variable as
> a defconst means : "change it at your own risk", which is exactly my
> point.
The documentation of defconst says:
> Define SYMBOL as a constant variable.
> This declares that neither programs nor users should ever change the
> value. This constancy is not actually enforced by Emacs Lisp, but
> SYMBOL is marked as a special variable so that it is never lexically
> bound.
So it is pretty clear about the intent of such a definition, which is
to never change it - even though it does not enforce it.
As you have said, we still want to allow users in principle to change
these variables. They have been defcustoms in the past, some people will
have changed them. Their setup will break when they switch to a new
version. That is why I object to changing their status. I think it
causes unnecessary breakage, and we can prevent this by keeping them
defcustom. Nothing is really gained by changing their status.
- Carsten
>
> Anyway, FWIW, even a defvar would suffice.
>
>> If we still allow users to edit this in principle,
>
> We have no way to prevent them from modifying it. In principle, they
> mustn't be changed, but it's Free software.
>
>> I do not think we should make these variables defconst. If editing is
>> not even depreciated, there is even less reason to make this change.
>> How about we add a sentence like this:
>>
>> Changing this variable may cause compatibility problems with other users
>> trying to edit your file in Emacs.
>
> It's not only about compatibility problems. As I pointed out, modifying
> these variable can break your own Org.
>
> Using a defcustom is ambiguous here. On the one hand, we say "You can
> modify this variable, we even help you to do so" and on the other hand
> "Upon changing this variable, horrible things can happen".
>
> Let's, at least, not help users shoot themselves in the foot.
>
>
> Regards,
>
> --
> Nicolas Goaziou
next prev parent reply other threads:[~2013-10-21 11:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-20 8:47 [RFC] Change some defcustoms into defcont Nicolas Goaziou
2013-10-20 18:23 ` Carsten Dominik
2013-10-21 8:56 ` Nicolas Goaziou
2013-10-21 10:26 ` Carsten Dominik
2013-10-21 10:51 ` Nicolas Goaziou
2013-10-21 11:56 ` Carsten Dominik [this message]
2013-10-21 15:15 ` Nicolas Goaziou
2013-10-22 7:50 ` Carsten Dominik
2013-10-22 9:52 ` Nicolas Goaziou
2013-10-22 10:34 ` Carsten Dominik
2013-10-22 18:28 ` Torsten Wagner
2013-10-22 20:00 ` Florian Beck
2013-10-23 8:56 ` Nicolas Goaziou
2013-10-23 13:25 ` Carsten Dominik
2013-10-29 14:04 ` Nicolas Goaziou
2013-10-29 14:11 ` Nicolas Goaziou
2013-11-16 20:25 ` Nicolas Goaziou
2013-11-16 23:55 ` Carsten Dominik
2013-10-21 8:17 ` Sebastien Vauban
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7839A647-8D17-47A9-A65D-5FD7110ED082@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).