Re: Setting file-local list variables

[Mark Elston]

adamsonj@email.unc.edu (Joel J. Adamson) wrote in
news:mailman.12007.1211462109.18990.help-gnu-emacs@gnu.org: 

> Mark Elston <M.Elston@RemoveAdvantest-ardRemove.com> writes:
> 
>> * Joel J. Adamson wrote (on 5/21/2008 6:36 AM):
> ...
>
>>> @someone-who-knows: Does this just come up when a new variable is
>>> introduced in a local variables list?
>>> 
>>> @OP: If so, what's wrong with marking the variables as safe and
>>> applying them in the future (!)?
>>
>> I tried that, too.  It didn't work either.
>
> What do you mean it didn't work?  Did you enter "!" when prompted? 
> From the *Help* you show, it seems that it did "work" as far as
> setting the variable. 
> 

It didn't apply these variables to the buffer as it was loaded.  Rather,
it didn't result in the proper faces being applied to the appropriate
regions.
 
>> I wonder if this is an AucTeX thing.  The AucTeX manual says that
>> this 
>>variable controls the verbatim-like environments.  However, in the
>>help for the variable it says:
>>

It turns out it *is* an AucTeX thing.  See below.

> ... 
> Hmmmm...what is it you're trying to accomplish?  Refresh my memory.
> 

I'm trying to set a list variable in a buffer so that AucTeX can apply
the proper faces to verbatim-like regions in my text.  I wound up with
the following:

%%% eval: (eval-after-load "latex" '(progn (add-to-list 'LaTeX-verbatim-
environments "CodeListing")(add-to-list 'LaTeX-verbatim-environments 
"OldCodeListing")(add-to-list 'LaTeX-verbatim-environments 
"NewCodeListing")))

Unfortunately, this still isn't quite right since it applies the 
changes *globally* and doesn't affect the *first* load of a file with
this line in it (I have to close the file and reopen it to get the
changes applied).

It turns out that these environments are created only for one LaTeX
file I am working with so I don't want to put this in my custom.el
forever.  Other files may have other verbatim-like environments to
make use of so I want this on a file-by-file basis.

Sigh.  Still looking for the best answer.

Mark


> Glad to help, if only for discussion's sake :)
> 
> Joel
>