Re: cc-vars.el

[Kenichi Handa]

In article <address@hidden>, Dave Love <address@hidden> writes:
> Richard Stallman <address@hidden> writes:
>>      + 2002-11-14  Kenichi Handa  <address@hidden>
>>      + 
>>      +       * progmodes/cc-vars.el: Don't cc-bytecomp-defun char-table-p.
>>      + 
>>  
>>  I think that is the right fix--this cc-bytecomp-defun is a bad kludge.
>>  I am thinking that maybe we should get rid of it because it is so
>>  risky.
>>  
>>  I had undone Dave's change in set-buffer-file-coding-system to fix this,
>>  but I restored that change today after concluding that cc-bytecomp-defun
>>  is the real culprit.

> What's all this about?  I haven't intentionally touched anything
> related to cc-mode.

Dave, there's nothing wrong with your change.  It just
revealed a bug of cc-bytecomp-defun.

That bug is just fixed by Martin in HEAD as below:

2002-11-16  Martin Stjernholm  <address@hidden>

        * progmodes/cc-bytecomp.el (cc-bytecomp-defun): Fixed bug that
        caused existing function definitions to be overridden by
        phonies when the bytecomp environment is restored.

So, I've just undone my change to cc-vars.el.  I confirmed
that it is surely fixed now by doing bootstrap.

But, Richard is against cc-bytecomp-defun.  He wrote:

Richard Stallman <address@hidden> writes:
>     + 2002-11-14  Kenichi Handa  <address@hidden>
>     + 
>     +         * progmodes/cc-vars.el: Don't cc-bytecomp-defun char-table-p.
>     + 

> I think that is the right fix--this cc-bytecomp-defun is a bad kludge.
> I am thinking that maybe we should get rid of it because it is so
> risky.

> I had undone Dave's change in set-buffer-file-coding-system to fix this,
> but I restored that change today after concluding that cc-bytecomp-defun
> is the real culprit.

Martin, could you discuss this issue with Richard from now
on.  I don't have any strong opinion on this issue.

---
Ken'ichi HANDA
address@hidden