Re: Can we expand the valid location of "Local Variables" ?

[Dima Kogan]

Stefan Monnier <address@hidden> writes:

>> Probably we'd want to make this into a variable? And the default maybe
>> should be higher than 3000?
>
> I don't like having this 3000 hard-coded everywhere, so making
> a variable makes sense.
>
> But encouraging large "Local Variables" blocks is a bad idea, IMO, so
> I'd keep it at 3000 and I wouldn't care to document the var either.
> I'd even be happy with a "--" in its name.

OK. I can write such a patch. Is there an upside to not documenting it?
If we REALLY don't want people touching this variable, then why not
leave the hardcoded 3000?


>> The use case where I hit this was in an .org file that was defining a
>> presentation where I needed to control the export with an eval: (progn
>> ...) block. Org wasn't doing quite what I needed it to, so the block had
>> some advice definitions in it, and that pushed the thing over the 3000
>> byte limit.
>
> Of course, you can use a short
>
>     eval: (progn (re-search-backward "^(progn ;;local-config") (eval (read 
> (current-buffer))))
>
> and then put an arbitrarily long Elisp chunk anywhere else in the buffer
> with a leading `(progn ;;local-config`.

Oof. I COULD do that, but that feels like it makes an already-ugly thing
even uglier. I sent a separate email to the org mailing list about maybe
upstreaming some of the advices, but the general idea doesn't seem
unreasonable to me: we already allow a block to define some custom
variables, so customizing the behavior of some functions doesn't seem
crazy.