Bug 7371 - Emacs M-x customize subsytem failing
Emacs M-x customize subsytem failing
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-27 00:08 EST by Jack Lloyd
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-16 18:48:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jack Lloyd 1999-11-27 00:08:28 EST
I was trying to configure emacs with the M-x customize system, specifically
for C/C++ code, but it fails to work correctly. This bug does not appear on
a RH 5.2 system with emacs 20.3 (which means I'm probably (hopefully!) not
just doing something stupid). My install is very generic, and I haven't
done anything funky with the emacs configuration. Here are the steps to
reproduce this problem:

Start emacs
M-x customize
Click on the following groups: Programming -> Languages -> C
Edit the "C Basic Offset" field (in my case, I chose 3)
Click on "State"
Choose 1 (Save for Future Sessions)

At this point, I get the following error:

Scan error: "Containing expression ends prematurely", 4144, 4145

The exact numbers seem to vary; I've seen from about 4000 to 91000-ish (so
it's not the pid, which was my first thought). However, I'm not an emacs
guru and would not care to guess as to the true meaning of this message

I have a feeling this may be a generic emacs error... it seems that there
were significant updates made to the customize system between 20.3 and
20.4, and probably something broke in the meantime.

Regards,

Jack
Comment 1 Anonymous 2000-02-03 21:53:59 EST
Here's a way of tracking down the problem:  Before you press the 'State' button in the custom buffer, type M-; and then enter:

(setq debug-on-error t)

Then you will be placed in a debugger buffer when the error would normally happen.  Capture the contents of that buffer and enter them in Bugzilla.  Then I'll take a look.

Personally, my tests had a different result:  In the absence of an .emacs file in the home directory, Emacs tried in vain to write to the /usr/share/emacs/20.4/lisp/term/linux.el file, which I don't have write access to.  I'll spend some time tracking this problem down.
Comment 2 Anonymous 2000-02-03 22:09:59 EST
I should add that when there *was* an .emacs file in my home directory, the procedure described in this bug report worked fine.
Comment 3 Cristian Gafton 2000-02-16 18:48:59 EST
This works for me too.

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