[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dima Kogan
Subject: Re: Can we expand the valid location of "Local Variables" ?
Date: Tue, 10 Mar 2020 16:44:44 -0700
User-agent: mu4e 1.2.0; emacs 28.0.50

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]