Re: Local Variables question: c-file-style and c-doc-comment-style

[Daniel <daniel@warum-ada.de>]

Thank you, Kevin!
(Please see below for my comments on your suggestions.)


Kevin Rodgers wrote:

> Daniel Rubin wrote:
>> (I'm new here, so first of all: Best greetings to everyone!)
> 
> Welcome!
> 
>> I have a problem concerning local variables in files (set by a
>> "Local Variables:" block at the end of a file).
>>
>> Here's what I'm trying to achieve:
>>
>> In C++ files, I'd like to set the indentation style (stroustrup),
>> apply some customizations (indentation inside namespace blocks),
>> and turn on a specific documentation comment style (javadoc).  I
>> currently do it like this:
>>
>>> // Local Variables:
>>> // c-file-style:"stroustrup"
>>> // c-file-offsets:((innamespace . 0))
>>> // c-doc-comment-style:javadoc
>>> // End:
>>
>>
>> Setting the indentation style and changing the indentation inside
>> namespaces works fine, but the doc-comment style is NOT set.
>>
>> Looking at variable c-doc-comment-style, it tells me that it's
>> local within that buffer and having a setting different from the
>> global default:
>>
>>> c-doc-comment-style's value is ((java-mode . javadoc)
>>>  (pike-mode . autodoc))
>>>
>>> Local in buffer EadesLinSmythProgression.hpp; global value is 
>>> ((c++-mode . javadoc)
>>>  (java-mode . javadoc)
>>>  (pike-mode . autodoc))
>>
>>
>> The documentation on c-file-style says that having a non-zero
>> value for this variable automatically makes all style variables
>> local, so I guess that's the problem.
>>
>> How do I manage to set the doc-comment style?
>>
>> Defining an own style (in my personal Emacs config) including that
>> setting is not an option, as other people (with other config
>> files) should be able to work with these files without nuking the
>> indentation.
>>
>> emacs-version: 21.4.1
>> mode: c++-mode (CC Mode version 5.30.9) (Semantic version 2.0pre3)
>> OS: Linux (Fedora Core 4)
> 
> I don't know if any of this applies to Emacs 21.4, but the CC Mode
> manual distributed with Emacs 22.0.92 says the following:
> 
> ,----
> |      The default value for `c-doc-comment-style' is
> |      `((java-mode . javadoc) (pike-mode . autodoc) (c-mode . gtkdoc))'.
> |
> |      Note that CC Mode uses this variable to set other variables that
> |      handle fontification etc.  That's done at mode initialization or
> |      when you switch to a style which sets this variable.  Thus, if you
> |      change it in some other way, e.g. interactively in a CC Mode
> |      buffer, you will need to do `M-x java-mode' (or whatever mode
> |      you're currently using) to reinitialize.
> |
> |      Note also that when CC Mode starts up, the other variables are
> |      modified before the mode hooks are run.  If you change this
> |      variable in a mode hook, you'll have to call
> |      `c-setup-doc-comment-style' afterwards to redo that work.
> `----
> 
> These are just guesses, but you could try forcing a call to
> c-setup-doc-comment-style in the Local Variables block (after you
> set c-doc-comment-style):
> 
>     eval: (c-setup-doc-comment-style)
> 
> or via the mode hook (in your ~/.emacs):
> 
>     (add-hook 'c++-mode-hook 'c-setup-doc-comment-style)
> 

Yes, you're right, this part is in the documentation of my version 
of Emacs, too.  Unfortunately, the `eval:' line has no effect. 
Indeed, the variable `c-doc-comment-style' doesn't even have the 
value I set it to by the file variables after opening the c++-file 
anymore.  So I think the call to `c-setup-doc-comment-style' comes 
too late.  (Same situation no matter whether I use `eval:' or 
`c++-mode-hook'.)
Hmm...

I just noticed that the problem went away completely in CC Mode 
version 5.31.3. :-)

Another thing I found out is that on at least one machine that 
other users will most probably work on when doing changes to my 
source files has only ancient CC Mode version 5.28 installed, 
which doesn't even know about `c-doc-comment-style'. :-(

So I think I'll just stick with the solution that works in the 
recent CC Mode version (and is clean) and live with whatever might 
happen to my sources.

Thanks again, Kevin.  You didn't solve my problem but helped me to 
look at it in another way, discovering it wasn't that critical at 
all.  I'm quite happy with what I've got now.

Have fun
----Daniel