Bug 915905 - xemacs: Buffer *scratch* is not a CC Mode buffer
Summary: xemacs: Buffer *scratch* is not a CC Mode buffer
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: xemacs-packages-extra
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Jerry James
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-26 18:35 UTC by Robert Peterson
Modified: 2013-02-26 23:26 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-02-26 23:26:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
My .emacs file that's always worked propely in the past (2.32 KB, application/octet-stream)
2013-02-26 18:35 UTC, Robert Peterson
no flags Details

Description Robert Peterson 2013-02-26 18:35:24 UTC
Created attachment 703058 [details]
My .emacs file that's always worked propely in the past

Description of problem:

I've used the same ~/.emacs file for 6 years without a problem.
When I recently did a yum update of Fedora 17, my xemacs started
giving me this error every time I try to edit a file:

Buffer *scratch* is not a CC Mode buffer

This is highly annoying because I have to get rid of the error
split-window with <ctrl-x>1, and it no longer accepts my
proper indenting style that's worked for many years.

I since upgraded my desktop to Fedora-18. Same problem.

Version-Release number of selected component (if applicable):
[root@vishnu /home/bob]# rpm -qa |grep emacs
xemacs-common-21.5.33-4.fc18.x86_64
xemacs-21.5.33-4.fc18.x86_64
xemacs-packages-extra-20130208-3.fc18.noarch
emacs-filesystem-24.2-6.fc18.noarch
xemacs-packages-base-20121228-1.fc18.noarch
xemacs-filesystem-21.5.33-4.fc18.noarch

How reproducible:
Always

Steps to Reproduce:
1. xemacs anything.c &
2.
3.
  
Actual results:
Buffer *scratch* is not a CC Mode buffer

Expected results:
No errors should be flagged, and my source code editing should work
as it has the last six+ years.

Additional info:

Comment 1 Jerry James 2013-02-26 19:16:11 UTC
I recently updated the XEmacs packages because a number of bugs were fixed.  This included an update to the cc-mode package.  It was rather a large jump forward in cc-mode version numbers.  I should not have pushed that change to F17,
sorry.  I did it because of all the bug fixes in other packages, and didn't realize what a big change in cc-mode it contained.

Let's see if we can get your setup working, again.  The new CC Mode uses a different way of setting up styles.  See http://cc-mode.sourceforge.net/changes-526.php for information on that.

Does adding (setq c-old-style-variable-behavior t) to your .emacs fix things for you?  If not, I'm happy to figure out how to adapt your .emacs for you.  Send it to me in private email if you would like me to do so.

Comment 2 Robert Peterson 2013-02-26 19:41:03 UTC
Hi Jerry,

Adding that line does NOT seem to help. My ~/.emacs is already
attached to the bugzilla. :)

Comment 3 Jerry James 2013-02-26 22:15:13 UTC
(In reply to comment #2)
> Adding that line does NOT seem to help. My ~/.emacs is already
> attached to the bugzilla. :)

Oh, oops.  That's what I get for reading too quickly.  Okay, I'll investigate what needs to be done to get things working for you again.  Sorry for the trouble.

Comment 4 Jerry James 2013-02-26 23:12:51 UTC
Replace the top-level call to c-set-style (the one right above the defuns) with this:

(setq c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "K&R")))

The java-mode and awk-mode settings are just to preserve the defaults.  If you never edit Java or awk code, then you can drop those elements.

Comment 5 Jerry James 2013-02-26 23:17:43 UTC
Incidentally, there is now a "linux" style for CC Mode, so you may be able to replace your linux-c-mode function with this:

(c-set-style "linux")

Comment 6 Robert Peterson 2013-02-26 23:23:22 UTC
Thanks, Jerry. Your suggestion in comment #4 worked perfectly.

Comment 7 Jerry James 2013-02-26 23:26:20 UTC
Excellent, I'll close this bug then.


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