Bug 102022 - defaults.el buglets
defaults.el buglets
Product: Red Hat Raw Hide
Classification: Retired
Component: xemacs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2003-08-08 18:33 EDT by Ville Skyttä
Modified: 2015-01-07 19:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-09-12 11:36:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix for newline-related defcustom defaults (866 bytes, patch)
2003-08-08 18:34 EDT, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2003-08-08 18:33:36 EDT
The following settings in defaults.el xemacs-21.4.13-4 don't seem to do anything:

  (defvar require-final-newline t)
  (defvar next-line-add-newlines nil)

If those are changed to setq or setq-default instead of defvar, they take
effect, but XEmacs becomes antisocial and won't allow users to change them via
customization menus.

I believe the correct way of assigning default values to defcustom variables is
to do setq-default in site-start.el.  That way the defaults are as specified
there, and users can override the settigs via the custmization menus (ie. their

Other values in default.el look fine to me and seem to work, because they're not

Will attach a patch to fix this.
Comment 1 Ville Skyttä 2003-08-08 18:34:24 EDT
Created attachment 93540 [details]
Fix for newline-related defcustom defaults
Comment 2 Jens Petersen 2003-09-02 03:22:44 EDT
Actually I noticed that next-line-add-newlines defaults to nil in XEmacs
is that is probably not necessary.  I have mixed feelings about the
require-final-newline setting (perhaps 'ask is a friendlier default,
though it becomes a little more verbose).

Agreed that these shouldn't have been in "default.el", thanks for spotting
that.  I guess setq-default is ok, but isn't setq sufficient?  I just wonder
if setq-default might not confuse users more than setq.  "I setq'd
require-final-newline in my init file and the value is still..."?
Well not such a big deal either way.
Comment 3 Ville Skyttä 2003-09-02 13:33:43 EDT
My personal feeling about require-final-newline is that it is good have on by
default.  If people haven't complained, why change it? :)  I'm sure that people
would be annoyed by 'ask.

Setting next-line-add-newlines to nil is redundant, you're right.  It also
defaults to nil in XEmacs 21.5 and the documentation strongly suggests that it
won't change (see C-h v next-line-add-newlines :)

Regarding the setq vs setq-default issue, I believe you and I have the same goal
wrt. site-start.el: to set a good system default and to allow users to override
it in via customize in custom.el or manually in init.el.  I don't see any
difference whether setq or setq-default is used in site-start.el, I can still
customize the setting as a user just as I like.

But IMO setq-default is exactly what we want to do: to set the default value
(setq-default) instead of unconditionally setting it to a specified value at
some point of time (setq).  I'm not 100% confident that I understand the
semantics of setq-default though, but it seems The Right Thing To Do to me.

While I'm at it, new Sumo packages are out... and they contain at least one
annoying bug in rpm-spec-mode for us Epoch: 0 enthusiasts, fix at
Comment 4 Ville Skyttä 2003-09-06 12:02:10 EDT
FWIW, I tried out setting require-final-newline to 'ask, but it drives me crazy
in about 2 minute.  I suspect there are lots of users around that feel the same,
especially beginners.  Please consider setq-default'ing it to t as it has been a
long time default...
Comment 5 Ville Skyttä 2003-09-07 05:35:32 EDT
FYI: if you're planning an update soon, 21.4.14 is out...
Comment 6 Jens Petersen 2003-09-07 23:08:56 EDT
require-final-newline will default to t in 21.4.14-1.
Comment 7 Ville Skyttä 2003-09-12 11:36:09 EDT

Note You need to log in before you can comment on or make changes to this bug.