Bug 7371 - Emacs M-x customize subsytem failing
Summary: Emacs M-x customize subsytem failing
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-27 05:08 UTC by Jack Lloyd
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-16 23:48:17 UTC
Embargoed:


Attachments (Terms of Use)

Description Jack Lloyd 1999-11-27 05:08:28 UTC
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-04 02:53:59 UTC
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-04 03:09:59 UTC
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 23:48:59 UTC
This works for me too.


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