[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
crazy.
- Can we expand the valid location of "Local Variables" ?, Dima Kogan, 2020/03/10
- Re: Can we expand the valid location of "Local Variables" ?, Stefan Monnier, 2020/03/10
- Re: Can we expand the valid location of "Local Variables" ?,
Dima Kogan <=
- Re: Can we expand the valid location of "Local Variables" ?, Dima Kogan, 2020/03/22
- Re: Can we expand the valid location of "Local Variables" ?, Robert Pluim, 2020/03/23
- Re: Can we expand the valid location of "Local Variables" ?, Eli Zaretskii, 2020/03/23
- Re: Can we expand the valid location of "Local Variables" ?, Robert Pluim, 2020/03/23
- Re: Can we expand the valid location of "Local Variables" ?, Eli Zaretskii, 2020/03/23
- Re: Can we expand the valid location of "Local Variables" ?, Dima Kogan, 2020/03/23
- Re: Can we expand the valid location of "Local Variables" ?, Stefan Monnier, 2020/03/23
- Re: Can we expand the valid location of "Local Variables" ?, Richard Stallman, 2020/03/23
Re: Can we expand the valid location of "Local Variables" ?, Richard Stallman, 2020/03/11