I sent this out a week ago, but I guess the email didn't make it for
some reason (I don't see it in the list archives, and nobody replied).
Apologies if you get this twice.



Stefan Monnier <monnier@iro.umontreal.ca> 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.
>
>> 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`.

Thanks for the suggestions, everyone. For my personal usage I think both
including files to eval and specifying custom look-back-distance
variables is a bit overkill. I think that

1. We should put the 3000 into a variable so that this isn't hard-coded.
   I'm attaching a patch. The name of the variable could probably be
   better, and it's not in the right file. I don't know where else to
   put it. Suggestions? And we need a NEWS entry, but I didn't want to
   write one before we talked about it.

2. As workarounds go, I think Stefan's suggestion above is the nicest.
   No custom variables or included files; just a directive to search
   backwards, and execute what it finds. I'll use that. Thanks for the
   pointer

dima