From: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Bastien <bzg@gnu.org>, emacs-orgmode@gnu.org
Subject: Re: Setting org-todo-keywords through directory-local variables
Date: Sun, 30 Oct 2022 15:35:51 +0100 [thread overview]
Message-ID: <875yg1craw.fsf@gmail.com> (raw)
In-Reply-To: <87leoyatwu.fsf@localhost> (Ihor Radchenko's message of "Sun, 30 Oct 2022 03:10:09 +0000")
Ihor Radchenko <yantar92@posteo.net> writes:
> [sending to Org ML in-reply to the relevant thread]
[Thanks!]
> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003
> 28.1.90; Can local variables be loaded before loading major mode?
>
>> … reminded me of a patch I submitted to the Org ML… some time ago 😣
>> (sorry for not following up) to set TODO keywords via .dir-locals.el:
>>
>> https://list.orgmode.org/87a70stkmv.fsf@gmail.com/
>
> Your patch is not listed on https://updates.orgmode.org/
> It is also not in my records (I am only following patches closely since
> the beginning of this year).
> So, it slipped through the cracks.
(Right, that's entirely on me, I posted it knowing that an Org release
was pending and figuring I'd come back later… well, better late than
never)
>> * could do so piecemeal, adding support for variables one at a time as
>> people chime in the ML to express a need.
>
>> E.g. my patch only added support for org-todo-keywords and
>> org-todo-keyword-faces, but it laid the foundation for adding support
>> for other variables later.
>
> I'd prefer to solve it once and for all. I tried early loading of
> file-local variables in the past, but had to revert the commit because
> of major issues. See
> https://list.orgmode.org/87r11wkmew.fsf@ucl.ac.uk/T/#mab6359ed2107d5515c6bb6b266551f0c5049ceca
>
> Maybe the hook approach can work better. But I'd prefer to discuss all
> the possible caveats first.
My reasoning for keeping the current initialization code untouched and
_re_computing stuff in hack-local-variables-hook hinged on…
* refactoring being fraught; since Org already has a "blessed" way to do
more or less what file/dir-locals do (SETUPFILEs), I figured it wasn't
worth rocking everyone's boat for the benefit of the few,
* the prior art in other markup modes (markdown-handle-local-variables,
font-latex-after-hacking-local-variables).
>> Also to try to reduce the risk of breakage, it went for "compute Org
>> settings normally; then selectively recompute some if relevant variables
>> are found in dir/file-locals". That way "regular" Org users who rely
>> rather on SETUPFILEs wouldn't be impacted, only "early adopters" of
>> dir/file-locals might shoot themselves in the foot.
>
> I am not sure what is the problem with SETUPFILE.
> We can simply load it in the hook.
I wasn't suggesting there's a problem with SETUPFILEs; my point was that
I considered two categories of users:
* those who are happy with SETUPFILEs: my implementation goal was to
"guarantee" that my patch would have zero impact on them,
* those who want to play with dir/file-locals (👋): conversely, I wanted
to make sure that only them would get to "pick up the pieces" when
something would inevitably break.
This patch might have been my first foray into Org's init code, so it
felt too risky to go with any approach other than "keep the
implementation for the established features _exactly_ _as_ _now_; stuff
all the experimental stuff in hack-local-variables-hook".
> Though the priority of SETUPFILE vs.
> local variables should be discussed. Probably, local variables should
> take precedence to keep things consistent with the rest of Emacs.
No strong opinions there. I'm not even sure how my patch handled that?
🤔
> +(defun org--process-local-variables ()
> + "Refresh settings affected by file-local or directory-local variables."
> + (when
> + (let ((local-vars (mapcar #'car file-local-variables-alist)))
> + (or (memq 'org-todo-keywords local-vars)
> + (memq 'org-todo-keyword-faces local-vars)))
> + (org-set-regexps-and-options)
> + (org-set-font-lock-defaults)))
IIUC the logic goes org-set-regexps-and-options ⇒ org-collect-keywords ⇒
org--collect-keywords-1, and that's where SETUPFILE is processed? So
currently the SETUPFILE would have priority 🙃 (unless I'm misreading
the code)
next prev parent reply other threads:[~2022-10-30 14:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 21:12 Setting org-todo-keywords through directory-local variables Kévin Le Gouguec
2020-05-21 23:12 ` Kévin Le Gouguec
2020-05-22 15:11 ` Nicolas Goaziou
2020-05-23 12:58 ` Kévin Le Gouguec
2020-06-24 17:54 ` Kévin Le Gouguec
2020-09-05 15:39 ` Bastien
2022-10-30 3:10 ` Ihor Radchenko
2022-10-30 14:35 ` Kévin Le Gouguec [this message]
2022-10-31 3:00 ` Ihor Radchenko
2020-05-22 8:42 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875yg1craw.fsf@gmail.com \
--to=kevin.legouguec@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).