GNU bug report logs - #21695
25.0.50; Change most occurrences of `setq' in Emacs manual to `customize-set-variable'

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 21695 <at> debbugs.gnu.org, hmelman <at> gmail.com, rms <at> gnu.org
Subject: bug#21695: 25.0.50; Change most occurrences of `setq' in Emacs manual to `customize-set-variable'? Really?
Date: Mon, 13 Sep 2021 13:00:15 +0000

>> That being said, I would say that using (setq latin1-display t) when 
>> latin1-display has a :set is always a bug, in the init file, 
>> interactively, or in built-in code (bytecompiled or not), and that (set 
>> 'latin1-display t) should be used instead.  WDYT?
>
> I have not studied the code -- I just picked a variable at random.  The 
> point is that code in a package will commonly use setq on the user 
> options to implement the code, and this is how it should be.
>

My point is that code that sets a user option that has a :set should set 
it with (set 'foo val) instead of (setq foo val).

I just checked: on the current trunk, there are 331 defcustoms with a 
:set.  Out of these, only 49 are set with setq, 33 only at one place, and 
16 more than once.  That would require changing 85 setq's into set's.

>
> (Also note that your patch will issue a bunch of warnings if the user 
> does an `eval-buffer' after loading .emacs into a buffer and then 
> evaling it (in a running Emacs).)
>

There are not that many custom variables that will behave differently when 
the init file is first loaded and when it is eval-buffer'd.  AFAICS this 
will only happen for variables whose files have been loaded in the 
meantime after they have been setq'd.

Previous Next

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