bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#57003: 28.1.90; Can local variables be loaded before loading major m


From: Stefan Monnier
Subject: bug#57003: 28.1.90; Can local variables be loaded before loading major mode?
Date: Sat, 29 Oct 2022 23:43:21 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>>> However, pretty much all the BODY in Org major mode definition will need
>>> to go into the hook. It feels awkward.
>> The body of a major mode should usually be limited to setting some
>> variables.  All the font-lock highlighting, the imenu scanning, the
>> syntax-propertizing, etc... is done afterwards (the later the better).
> One issue I envision is when unsafe variable dialogue is being
> displayed. If font-locking is not setup prior to that, Emacs will try to
> fontify the visible part of buffer when displaying the dialogue and
> later font-lock settings may not fully apply.
>
> See https://list.orgmode.org/orgmode/878ro8kqwv.fsf@localhost/T/#u

I didn't quite understand the problem from that thread.

Your description above isn't very clear either  On the one hand you say
"font-locking is not setup prior to that" but on the other you say
"Emacs will try to fontify the visible part of buffer" which only
happens if font-lock is setup, AFAIK.

I suggest you open a bug report to get to the bottom of this.

>> The act of folding is not part of "defining" the major mode in my
>> book :-)
> Indeed.  However, a lot more things in Org mode depend on user
> customizations.  For example, buffer-invisibility-spec may be changed
> depending on user settings, including settings defined in file-local
> variables.

I don't see a problem with postpone that to `hack-local-variables-hook', no.
[ Other approaches exist, of course, such as monitoring those config
  vars and updating the other pieces of data that depend on them
  whenever needed.  ]

>>> Will moving the whole major mode definition into
>>> `hack-local-variables-hook' be safe?
>> Define "safe".  I'm sure it'll cause problems in corner cases.
>> If those problems come down to the fact that `hack-local-variables-hook'
>> doesn't fit the bill, then we can look at fixing that.
> I was mostly asking if you are aware about any gotchas.

Not really, no.  I have no doubt that there are various (in addition to
the one you mention above).


        Stefan






reply via email to

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